テスターのスキルマップの作り方｜兼任チームの物差し

2026 8/27

2026年8月27日 2026年8月27日

「このテストは誰に任せればよいか」「この人には次に何を覚えてもらうか」。少人数・兼任中心のテスト体制では、こうした判断が担当者の勘や記憶に頼りがちです。

テスターのスキルマップは、メンバーの「できること・できないこと」を一枚の表に可視化し、アサインの根拠・育成の地図・体制を説明する材料へと変える道具です。

「少人数だから全員の顔が見えている、わざわざ表にするまでもない」と感じる方もいるはずです。ですが人数が少ないほど、一人の離脱や稼働超過がそのまま案件停止に直結します。頭の中の把握を、引き継げる形に外へ出す価値はむしろ小さなチームでこそ大きいのです。

本記事では、最小限から始める作り方と、形骸化させない使い方を、受託開発の現場目線で解説します。専任のQA組織を持たないチームでも、今日から着手できる進め方に絞ってまとめました。

テスト担当者の「できる・できない」が見えないと何が起きるか

まず、兼任中心の体制でスキルが見えないと何が起きるかを整理します。ここが曖昧なままだと、アサインも育成もその場しのぎになります。

少人数運用では、テスト担当者一人ひとりが何をどこまでできるのかが、明文化されていないことがほとんどです。判断材料は「前の案件でうまくやってくれた」という記憶や印象に偏ります。

その結果、誰に何を任せ、誰に何を教えるかが、すべてリーダーの勘で決まっていきます。勘が当たっているうちは問題が表面化しませんが、外れたときに一気にリスクが顕在化します。

スキルが見えないと、アサインの失敗も育成の停滞も「たまたま」で片づけられ、原因が組織に蓄積されません。

複数案件を同時に進める体制では、この問題がさらに複雑になります。同じ人に負荷が集中したり、逆に特定の観点が誰にも割り当てられず抜け落ちたりします。

見えないことで起きがちな症状を挙げます。

特定の人にしか任せられない領域が生まれ、その人が休むと案件が止まる
新しく入ったメンバーに何から教えればよいか決められない
「テストできる人が足りない」と感じるが、何のスキルが足りないのか説明できない
上長やクライアントに体制を説明するとき、人数以外の根拠を示せない
案件ごとに必要なスキルがずれても、同じ顔ぶれで同じように回してしまう

たとえば、ある画面のテストを長く担当してきた人が急に抜けたとします。残ったメンバーは操作こそできても、どの入力で過去に事故が起きたかという勘所までは引き継げていません。見えていなかったのは作業手順ではなく、その人の頭の中にしかなかった観点だったと、抜けて初めて気づくのです。

ここで押さえたいのは、スキルマップは「評価表」ではないという点です。誰が優秀で誰が劣っているかを格付けする道具ではありません。

あくまで、チームの現在地を見えるようにする「可視化の道具」です。査定と結びつけた瞬間に、後述するとおり自己申告が正直に出なくなり、道具そのものが機能しなくなります。

見えない状態を放置すると、属人化という形で問題が固定化します。誰か一人にスキルが集中していること自体は、可視化しない限り気づけません。可視化して初めて、偏りを是正する打ち手が検討できるようになります。

テスターのスキルマップとは何か（構造：スキル項目 × 習熟レベル）

ここからは道具の構造を説明します。兼任チームでも扱えるよう、この道具は突き詰めると「スキル項目」と「習熟レベル」を掛け合わせた表にすぎません。

縦軸に、テストに必要なスキル項目を並べます。テスト観点の洗い出し、テストケース設計、不具合の切り分けといった、業務を構成する要素です。

横軸に、それぞれの項目をどこまでできるかという習熟レベルを置きます。「教われば出来る」から「仕組みを作れる」まで、段階で表現します。

1つのマス（項目×レベル）が、そのままアサインの判断材料であり、育成の目標になります。

たとえば「Aさんは不具合の切り分けは独力でできるが、テスト観点の洗い出しはまだ教われば出来る段階」といった現在地が、表を見れば一目で分かります。この一目で分かる状態こそが、この道具の価値です。

イメージをつかむため、ごく小さな一部を表にすると次のようになります。

スキル項目＼メンバー	Aさん	Bさん	Cさん
テスト観点の洗い出し	教われば出来る	独力でできる	教えられる
テストケース設計	独力でできる	独力でできる	教われば出来る
不具合の切り分け・報告	独力でできる	教えられる	教われば出来る

この表を眺めるだけで、観点の洗い出しはCさんが強くAさんが弱い、といった分布が見えてきます。

大切なのは、これは「一度作って完成させる表」ではないということです。案件や人の成長に応じて中身は変わり続けます。

完璧な項目を最初から揃えようとするより、更新し続ける「物差し」として運用するほうが実用的です。物差しは目盛りがあれば使えます。精密である必要はありません。

どんなスキル項目を並べるか（技法・分析・ドメイン知識）

次に、縦軸に並べる項目を考えます。多くのチームがつまずくのは、項目を細かくしすぎたり、自動化やツールの習熟だけに寄せてしまったりする点です。

ここで押さえたいのは、性質の異なる2種類のスキルを混同しないことです。案件を超えて持ち越せる「テスト技法・普遍スキル」と、案件ごとに再取得が必要な「ドメイン・プロダクト知識」は、直交する別軸として扱います。

技法は一度身につけば次の案件でも使えますが、業務ドメインの知識は案件が変わるたびに評価し直すのが前提です。

James Bach は、探索的テストを場当たり的なテスト（ad-hoc）と区別し、テスト設計とテスト実行を同時並行で行う学習活動だと位置づけています（Lee Copeland『はじめて学ぶソフトウェアのテスト技法』での言及）。観点を立て仮説を検証する力は、明確なスキル項目として扱う価値があります。

項目は、いくつかの軸に分けて考えると整理しやすくなります。軸の定義を一行ずつ添えます。

軸	軸の定義	主なスキル項目
機能軸	何を確認すべきかを導く力	テスト観点の洗い出し／テストケース設計
技法軸（普遍スキル）	案件を超えて持ち越せる設計技法	同値分割・境界値分析／デシジョンテーブル・状態遷移／探索的テスト
分析軸	不具合を切り分け再現・報告する力	不具合の切り分け・報告
ドメイン軸（案件知識）	案件ごとに再取得が必要な業務知識	業務フローの理解／優先度判断
協働軸	人と認識を合わせる力	開発者・顧客とのコミュニケーション・調整
技術軸	ツールで効率化する力	自動化・ツール

技法軸を独立させておく利点は、成果物で客観的に判定できることです。同値分割や境界値分析、状態遷移といった技法は、テストケースや観点表という成果物を見れば、身についているかを事実で確かめられます。

自動化やツールの習熟は独立した技術軸に置きます。それ「だけ」を重視すると、何をテストすべきかを考える力が評価から抜け落ちます。

軸に分けておくもう一つの利点は、偏りに気づきやすくなることです。チーム全体が機能軸に強く協働軸が弱いといった傾向が見えれば、育成や採用の方針に反映できます。

特に見落とされやすいのがドメイン軸です。テスト技法は熱心に育てても、業務の前提や優先順位の判断は「そのうち覚える」で放置されがちです。しかし受託開発では、案件ごとに業務が入れ替わります。技法が高くてもドメイン理解が浅いままだと、仕様どおりでも業務的にはおかしい挙動を見逃してしまいます。軸として明示しておくことで、案件開始時に何を補うべきかが見えてきます。

項目を作るときの注意点を挙げます。

細かくしすぎない。最初は各軸から1〜2項目に絞る
案件で実際に使うスキルから選ぶ。使わない項目は当面入れない
ツール名で項目を作らない（「Selenium」ではなく「自動化・ツール」とする）
技法は「同値分割ができる」のように、成果物で判定できる粒度で書く
抽象的すぎる項目（「テスト力」など）は避け、行動で説明できる粒度にする

特に「テスト観点の洗い出し」は、実力差が出やすく、育成効果も大きい項目です。どんな観点をどう洗い出すかは、テスト観点の洗い出し手順を解説した記事も参考にしながら、自チームの項目を具体化してみてください。

スキルの体系を外部の基準で確かめたいときは、JSTQB認定テスト技術者資格のシラバスが役立ちます。テスト技術者に求められる知識領域が体系化されており、項目の抜け漏れをチェックする物差しになります。

習熟レベルをどう定義するか（3〜4段階の物差し）

教われば出来る・独力・教えられる・仕組みを作れるの習熟レベル4段階を階段で示した図

横軸の習熟レベルは、兼任チームでのスキルマップの使い勝手を大きく左右します。ここが曖昧だと、記入する人によって基準がぶれ、比較できなくなります。

レベルは「知っている・詳しい」といった知識量ではなく、「何ができるか」という行動で定義するのがコツです。行動で書けば、記入も判断もぶれにくくなります。

段階は、多くのチームで3〜4段階が扱いやすい水準です。段階を増やしすぎると、レベル2とレベル3の違いが説明できなくなり、記入が止まります。

4段階で定義する場合の例を示します。

レベル	呼び方	行動の目安
L1	教われば出来る	手順や観点を示してもらえば作業できる
L2	独力でできる	指示がなくても一人で完了できる
L3	教えられる	他のメンバーに手順や勘所を教えられる
L4	仕組みを作れる	チームで再現できる手順やテンプレートを整備できる

「教えられる（L3）」に達している人が複数いる項目は、その領域が組織に定着している証拠です。

このように行動で定義しておくと、レベルの判定に迷いが減ります。「一人で最後までできたか」「他人に教えられたか」という事実で判断できるためです。

また、レベルは人ではなく項目ごとに付く点も押さえておきます。同じ人でも、テストケース設計はL3、自動化はL1というように、項目によって現在地は変わります。「あの人は優秀」といった人単位の評価に丸めず、項目ごとに見るからこそ、次に伸ばす一点が具体的に定まります。

技法軸のように成果物で確かめられる項目は、判定の裏取りがしやすくなります。直近のテストケースやバグ票、観点表を一緒に見れば、自己申告と実態のズレを補正できます。

判定で迷いやすいのが、L2とL3の境目です。一人で最後まで完了できる人は多くても、勘所を言葉にして他人へ渡せる人は限られます。迷ったときは「そのスキルを新人に半日で教えられるか」を基準にすると切り分けやすくなります。手順と注意点を説明できればL3、自分ではできるが説明が曖昧ならL2にとどめる、という運用です。

同じ発想で、L4は「個人ができる」の一段上に置きます。自分の勘所をチェックリストやテンプレートに落とし込み、他の人が同じ品質を再現できる状態を作れて初めてL4です。属人的な熟練を、チームの資産に変換できるかどうかが分かれ目になります。

レベル定義を作るときの注意点をまとめます。

各レベルを「〜できる」という行動文で書く
段階は3〜4に抑える。5段階以上は運用が重くなる
「頑張れば」「たぶん」といった曖昧な条件を混ぜない
全項目で同じレベル定義を使い回し、項目ごとに基準を変えない

スキルの可視化と人材育成を、より公的な枠組みで裏づけたい場合は、IPAが公開するスキル標準の考え方が参考になります。職務に必要なスキルを段階で定義し育成につなげる発想は、この道具と同じ方向を向いています。

こうした外部の基準をそのまま持ち込む必要はありません。自チームの言葉に翻訳し、現場で使えるレベル定義に落とし込むことが大切です。

テスターのスキルマップの作り方（棚卸し→現状記入→ギャップ可視化）

構造と項目が決まったら、実際に作ります。兼任チームでの作り方は、大きく3つのステップに分かれます。全部を一度に完璧にしようとせず、動くものを先に作るのが成功のコツです。

最初から全スキルを網羅しようとすると、作る前に力尽きます。まず「今の案件で必要なスキル」だけに絞ってください。

ステップ1：案件で必要なスキルから項目を絞る

進行中の案件を思い浮かべ、そこで実際に使うスキルを書き出します。理想の項目一覧ではなく、目の前の案件が求めるものから選びます。

この段階で項目を数個に絞れれば十分です。使っていない項目は、必要になったときに足せばよいと考えます。

ステップ2：メンバーごとに現状レベルを記入する

絞った項目に対して、メンバー一人ひとりの現在のレベルを記入します。自己申告だけ、あるいはリーダーの印象だけで決めず、両方を突き合わせます。

その際、直近の成果物を必ず横に置きます。テストケース・バグ票・観点表といった実物を見れば、「独力でできる」の申告が実態と合っているかを裏取りできます。

ここで重要なのが、記入を評価・査定と切り離すことです。査定に使われると身構えると、人は自分を高めに申告したり、逆に守りに入ったりします。

ドメイン知識の項目は、案件が変わったら評価し直します。前の案件で高かった業務理解も、新しいドメインでは一から取り直しになるためです。

ステップ3：案件が求める水準とのギャップを可視化する

各項目について、案件が求めるレベルと現状を並べ、差を見ます。この差が、アサインで注意すべき点であり、育成の対象でもあります。

作成手順をチェックリストにまとめます。着手前に確認してみてください。

[ ] 対象は「今の案件で使うスキル」に絞ったか
[ ] 項目は各軸から1〜2個、無理のない数か
[ ] レベル定義は行動で書かれ、全項目共通か
[ ] 記入は自己申告とリーダー認識を突き合わせ、直近の成果物で裏取りしたか
[ ] ドメイン知識は今の案件基準で評価し直したか
[ ] 記入は査定と切り離すことをメンバーに明言したか
[ ] 案件が求める水準を項目ごとに決め、ギャップを一目で見えるようにしたか

自己申告が正直に出る前提を守れるかどうかが、スキルマップが機能するか否かの分かれ目です。

査定と切り離す約束は、建前で終わらせないことが肝心です。実績ベースで本人と一緒に埋める、査定シートとは物理的に別ファイルで管理する、といった運用の工夫で担保します。

なお作成コスト自体は大きくありません。数項目 × 数名の小さな表なら、記入そのものは30分程度で当たりが付きます。表計算ソフトの一枚のシートで十分です。

テスターのスキルマップの使い方（アサイン・育成・1on1・体制説明）

スキルマップの可視化からアサイン・育成・1on1・体制説明の4用途へ分岐する活用フロー図

作ったスキルマップは、使ってこそ意味があります。兼任中心の運用で効く4つの使い方を紹介します。この表を使えば、勘で回していた判断を根拠のある判断に変えられます。

アサインの根拠にする

案件が求めるスキルと、各メンバーの現在地を突き合わせれば、誰をどの役割に置くかが説明できます。「なんとなくこの人」ではなく、項目とレベルで裏づけられます。

案件が求めるスキル	要求レベル	満たすメンバー	補い方
テスト観点の洗い出し	教えられる	Cさん	Cさんがリード、Aさんが同席して学ぶ
テストケース設計	独力でできる	Aさん・Bさん	2名で分担
不具合の切り分け	独力でできる	Bさん	Cさんがバックアップ

この突き合わせは、要求レベルに満たないマスへの手当てもセットで考えられる点が優れています。上の表のように、教える側と学ぶ側を同じ案件に組み込めば、アサインと育成を一度に進められます。人が足りないなかで品質と納期を両立するには、こうした一石二鳥の配置が欠かせません。

こうした突き合わせは、アサインを最適化する考え方そのものです。役割分担をさらに掘り下げたい方は、テストチームのアサインを最適化する考え方をまとめた記事もあわせてご覧ください。

育成の地図にする

現状と目標レベルの差が、そのまま育成計画になります。次に誰に何を、どの順で覚えてもらうかが、表の上で決められます。

育成は「気づいたら成長していた」ではなく、ギャップを埋める具体的な行動として設計できます。

可視化の次の一手も、マップと紐づけて具体化できます。「できる人が1人しかいない」項目に対し、誰の何レベルを1段上げれば単一障害点が外れるかを考えます。たとえば観点の洗い出しをAさんがL2からL3へ上げれば、Cさん一人依存が解けます。

育てる順番も大切です。案件で今すぐ必要な項目から埋め、余力があれば将来に効く技法軸へ広げます。全員を同時に底上げしようとせず、単一障害点になっている項目を一つずつ解消する順で進めると、限られた工数でも体制が目に見えて安定します。

すぐに育てられない場合は、どのマスを一時的に外部で補うかもマップ上で判断できます。埋まらないマスが見えれば、外部に任せる範囲も具体的に線引きできます。

1on1・面談の共通言語にする

面談でスキルマップを開けば、「次はこの項目をL2からL3へ」といった具体的な会話ができます。抽象的な「もっと頑張ろう」から抜け出せます。

ただし、ここでも査定とは分けて使います。育成の道具として実績を一緒に振り返る形にすることで、本人も前向きに現在地を認められます。

スキルの偏りと体制を説明する

重要スキルごとに、一定レベル以上を保有する人数を数えてみます。その人数が実質的なバス係数、つまり属人化の深さを表します。一人しか担えない項目は、その人が抜けると業務が止まるリスクです。

この偏りは、属人化という形で現れます。スキルが一人に集中している構造をどうほぐすかは、属人化を4つの層で解きほぐす対処法の記事で具体的に整理しているので、あわせて参考にしてください。

さらに、上長への費用対効果の説明にも使えます。可視化の前後を比べると効果が伝わります。

観点	可視化する前	可視化した後
アサイン判断	リーダーの記憶と勘	項目×レベルの事実で説明
単一障害点	特定案件を1人しか回せず残業が常態化	別メンバーへ計画的に移譲し停止リスクを解消
体制説明	人数しか示せない	どのスキルがどれだけ揃うかを提示

数項目の表を記入する30分程度の手間で、単一障害点の解消と体制説明の材料が同時に手に入ります。作る工数に見合うことは、この前後比較で上長にも説明できます。

スキルマップを形骸化させない運用と、まず作るミニマム版

最後に、作ったスキルマップを兼任チームで生かし続けるための運用です。多くのスキルマップは、作った直後がピークで、あとは更新されずに埋もれていきます。

形骸化には典型的なパターンがあります。防ぎ方とセットで押さえておきましょう。

形骸化のパターン	起きる理由	防ぎ方
作って満足	完成をゴールにしてしまう	「更新し続ける物差し」と最初に位置づける
更新されない	見直すきっかけがない	案件の区切りなど更新トリガーを運用に埋める
項目過多	網羅を目指して肥大化	使わない項目を定期的に削る

更新のトリガーを「気が向いたとき」にせず、案件の節目やリリース後の振り返りに紐づけるのが継続のコツです。

更新トリガーの例を挙げます。仕組みに埋め込めば、意志の力に頼らず続きます。

案件が一区切りしたタイミングで、メンバーのレベルを見直す
新しいメンバーが加わったとき、項目とレベルを記入する
新しい案件が始まったら、ドメイン知識の項目を評価し直す
新しいスキルが必要になった案件で、項目を追加する
半期に一度など、時期を決めて棚卸しする

更新を続けるうえで意外と重要なのが、誰が管理するかを決めておくことです。担当者を決めずに「みんなで更新」とすると、結局誰も手を付けません。リーダーが棚卸しの号令をかけ、記入自体は各メンバーが担う、といった役割分担を最初に決めておきます。更新を1on1や振り返りの議題に組み込めば、忘れられずに回り続けます。

運用の中では、足りないスキルにどう対処するかという判断も出てきます。育成には時間がかかるため、短期的には外部の力を借りる選択肢も現実的です。

社内で育てるか、一時的に外部で補うかは、案件の緊急度とスキルの重要度で決まります。どちらが得かは状況次第であり、判断材料はテストの内製と外注を比較した記事で中立的に整理しています。

そして、これから始める方に最も伝えたいのは、ミニマム版から始めることです。数項目 × 4レベルの小さな表で十分に機能します。

完璧な一枚を目指すより、小さく作って更新し続けるほうが、はるかに実用的で長続きします。

まず今の案件で使う数項目を書き出し、メンバーの現在地を埋める。それだけで、アサインと育成の会話は具体的になります。テスターのスキルマップは、その最初の一枚から育てていくものです。