テストを教えられる人がいない状態を抜け出す進め方

2026 8/27

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

新しいメンバーにテストを任せたいのに、テストを教えられる人がいない。案件は複数走り、テストは特定の誰かに集中し、その人が抜ければ品質が一気に不安定になる。多くの受託開発の現場で、こうした詰まりが静かに続いています。

「教えられる人がいないのは、うちに優秀な人材がいないからだ」と感じてしまいがちです。けれど、原因の多くは人の能力ではありません。教える仕組みが用意されていない、という構造の問題です。

この記事では、育成が回らなくなる構造を5つの要因に分解し、限られた人数のままでも育成を始めるための判断軸を整理します。範囲を絞る、暗黙知を教材に変える、段階で見る。明日から動かせる最初の一歩まで、順を追って解説します。

テストを教えられる人がいない、その詰まりは能力ではなく構造の問題

まず前提を整理します。この詰まりは、突然生まれるものではありません。日々の忙しさの中で、教える仕組みを後回しにし続けた結果として積み上がっていきます。

教える人が一人しかいない現場では、その人の時間がボトルネックになります。質問はすべてその人に集まり、レビューもその人が抱えます。案件が重なるほど教える余裕は削られ、結果として誰も育たないまま時間だけが過ぎていきます。

育たないのは個人の能力の問題ではなく、教える仕組みが用意されていないという構造の問題です。ここを取り違えると、対策が「もっと優秀な人を採る」方向に偏り、根本は変わりません。採用で一時的に人数が増えても、教える仕組みがなければ、新しい人もまた育たないまま同じ詰まりを繰り返すだけです。

一人に集中した現場で実際に起きていること

一人に負荷が集中した現場では、次のような連鎖が起こります。頭では分かっていても、忙しさの中では止めにくいのが厄介な点です。

質問対応で手が止まり、教える側の作業が進まない
教える時間がないので、結局自分でテストしてしまう
任せられないから経験が渡らず、いつまでも属人化が続く
その人が休むと、テストの判断そのものが止まる

この連鎖の怖いところは、どれも「善意」と「責任感」から生まれる点です。頼れる人ほど抱え込み、抱え込むほど周りは頼り、気づけば代わりのいない状態ができあがります。悪意も怠慢もないまま、静かに属人化が固まっていくのです。

抜け漏れと手戻りが属人化を深める悪循環をどう断つか

急いで任せると観点が渡りきらず、抜け漏れが起きます。抜け漏れはリリース後の不具合や手戻りにつながり、対応でまた特定の人の時間が奪われます。忙しさが増すほど教える余裕は減り、属人化はさらに深まります。

見落とされがちなのは、この詰まりが採用や定着にも波及する点です。教わる機会が乏しい職場では、若手は成長の実感を得にくく、早期の離職につながります。すると教える相手が入れ替わり続け、貯めかけた知見もそのつど振り出しに戻ります。属人化はテストの現場だけでなく、チームの定着そのものを蝕んでいきます。

この悪循環は、放っておいて自然に解けることはありません。どこか一点に、意図的にくさびを打ち込む必要があります。まずは、どこにくさびを打てるかを見極めることから始めます。

見て覚えろが通用しなくなっている背景

かつては「先輩の背中を見て覚える」やり方も、ある程度は機能しました。案件の数が限られ、同じシステムを長く担当できたからです。じっくり横で見続ける時間が、自然と確保できていました。

しかし今は、案件が短期で入れ替わり、扱う技術も広がり続けています。見て覚えるための時間そのものが確保できません。だからこそ、観点を言葉にして手渡す仕組みが、以前にも増して欠かせなくなっています。属人的な伝承に頼れない時代になった、という前提の変化を押さえておく必要があります。

この記事で持ち帰れること

本記事のゴールは、二つです。ひとつは、育成が詰まる構造を言葉で理解し、社内で共有できる状態にすること。もうひとつは、明日から踏み出せる小さな一歩を具体的に決めることです。

大がかりな研修制度を作る話ではありません。少人数の兼任中心の体制でも回せる、現実的な進め方に絞って扱います。

なぜテストの育成が回らないのか、詰まる5つの構造要因

テストの育成が詰まる5つの構造要因を、一人への集中を起点に悪循環として示した関係図

育成が回らない現場を分解すると、原因はいくつかの共通した構造に集約されます。個別の人や案件の問題に見えても、実は同じパターンが繰り返されていることが多いのです。

ここでは、詰まりを生む要因を5つに整理します。自分の現場にどれが当てはまるかを確かめながら読み進めてください。

要因	起きていること	見過ごされやすい理由
教える人への集中	質問もレビューも一人に集まる	「頼れる人」に見えて問題化しにくい
暗黙知のまま	判断基準が本人の頭の中だけにある	本人は説明できると思い込んでいる
地図がない	何をどの順で教えるか決まっていない	その場対応で回っているように見える
時間が原価外	教える時間が工数配分に入っていない	善意の持ち出しで表面化しない
即戦力志向	完成度を最初から求めすぎる	「できないと任せられない」が前提化する

どの要因も、単独で見れば「よくあること」に映ります。だからこそ放置され、複数が重なったときに初めて「誰も育たない」という結果として表面化します。以下では一つずつ、なぜそれが詰まりを生むのかを掘り下げていきます。

教える人が一人に集中し多忙になる

一つ目は、教える役割が特定の一人に固定されていることです。頼れる人がいるうちは問題が表面化しません。しかしその人の時間が尽きた瞬間、育成は止まります。

頼れる一人がいる状態は、実は最も属人化が進みやすい状態でもあります。その人が優秀であるほど周囲は任せきりになり、教える仕組みを作る動機そのものが失われていきます。

暗黙知が形式知化されていない

二つ目は、テストの判断基準が本人の頭の中にしかないことです。どこを重点的に見るか、どんな条件で不具合を疑うか。こうした観点は経験として蓄積されますが、言葉にされないまま残ります。

言語化されていない知識は、教材になりません。教える側は「見て覚えて」と言うしかなく、教わる側は再現できないまま時間が過ぎます。本人ですら「なぜそう判断したか」を後から説明できないことも多く、暗黙知は放っておくほど掘り起こしにくくなります。

育成の地図がない

三つ目は、何をどの順で教えるかという地図がないことです。地図がないと、教える内容はその日の案件しだいで場当たり的になります。教わる側も、自分が今どこにいて次に何を身につけるべきか分かりません。

その結果、同じことを何度も教え直したり、逆に肝心な基礎が抜け落ちたりします。順序が定まっていないだけで、教える手間は何倍にもふくらみます。

教える時間が原価に入らず教える側だけ損をする

四つ目は、教える時間が社内の工数配分に入っていないことです。育成は本来コストのかかる活動ですが、原価として見込まれないと「善意の持ち出し」になります。持ち出しは長続きせず、忙しくなれば真っ先に削られます。

即戦力を求めすぎて芽を摘む

五つ目は、最初から高い完成度を求めることです。任せてみて粗があると「やはり自分でやった方が早い」と引き取ってしまう。これを繰り返すと、経験を積む機会そのものが渡らなくなります。

この5つは独立しているようで、互いに絡み合っています。だからこそ、全部を一度に直そうとせず、ほどきやすい一本から着手するのが現実的です。

教える範囲を絞り、暗黙知を教材に変える

頭の中の暗黙知が業務中の一言メモを経て観点表・チェックリスト・バグ票の型へ変わる流れの図

最初の突破口は、教える範囲を欲張らないことです。テスト全体を一度に渡そうとするから、教える側も教わる側も苦しくなります。まずは範囲を絞り、そこだけを確実に渡します。

すべてを教えようとするのをやめ、まずは範囲を一つに絞ることが、育成を動かす最初のスイッチになります。

何から教えるか、範囲の絞り方

初めから探索的なテストを任せるのは無理があります。まずは、テスト観点の洗い出しと、手順が決まった定型的なケースの実行に絞りましょう。最初に教える型として向いているのは、同値分割・境界値分析・デシジョンテーブルです。

これらの技法は、入力の区切り方や条件の組み合わせ方に明確な型があります。型があるからこそ手順を言葉にしやすく、教材化もレビューもしやすい領域です。観点の出し方そのものに不安がある場合は、テスト観点の洗い出し手順を確認すると、教える順番を組み立てやすくなります。

三つの技法にも、教える順番があります。まずは同値分割で「入力をグループに分ける」感覚をつかみ、次に境界値分析でその境目を攻める視点を重ねます。最後にデシジョンテーブルで条件の組み合わせへと広げると、無理なく積み上がります。いきなり全部を渡さず、一つずつ手応えを確かめながら進めるのが定着の近道です。

暗黙知を副産物として貯める書き出し方

範囲を絞ったら、その範囲の暗黙知を紙に落とします。とはいえ、忙しい当人にゼロから教材を書き起こさせるのは本末転倒です。狙いは、通常業務の中で副産物的に少しずつ貯めることです。

テスト実施中に気づいた観点を、その場で一言だけメモする
不具合を見つけた画面キャプチャに、疑った理由を一言添える
判断に迷ったときの相談先と基準を、思い出したときに書き足す
一度で完成させず、案件ごとに追記して育てる

こうして貯めたメモは、後から観点表やチェックリストの形に整えるだけで教材になります。まとまった執筆時間を新たに取らずに済むのが利点です。完璧な体裁を目指すと手が止まるので、まずは箇条書きの断片で構いません。断片が集まってから並べ替えれば、教材の骨格は自然と見えてきます。

バグ票の型を教材にする

観点と並んで教材化しやすいのが、バグ票の型です。何をどう書けば伝わるバグ報告になるかは、実は経験に依存する暗黙知の塊です。型を一枚用意するだけで、教わる側の再現度は大きく上がります。

書き方の基準をそろえたいときは、伝わるバグ票の書き方を教材にするための型を下敷きにすると早く整います。再現手順・期待結果・実際の結果という枠が決まっているだけで、教わる側は「何を書けばいいか」で迷わなくなります。

教材化はレビューと引き継ぎも同時に軽くする

暗黙知を教材に変える効果は、育成だけにとどまりません。観点表やチェックリストがあれば、レビューの基準が共有され、指摘のばらつきが減ります。人が入れ替わるときの引き継ぎも、教材があれば口頭説明に頼らずに済みます。

教材化は、育成とレビューと引き継ぎという三つの負担を同時に軽くする投資です。一度作れば繰り返し効くため、最初にかけた手間は使うほど回収されていきます。

小さくOJTを回し、担当を広げる順序を地図にする

定型ケースから探索的テストへ担当を広げる順序と、自動化を別トラックに位置づけた地図

教材がそろってきたら、実務の中で小さく回します。いきなり案件全体を任せるのではなく、範囲を限った実践から始めるのがコツです。

一人しかいなくても始める最初のペアテスト

最初のOJTは、一つの機能や画面に絞ります。教える側が横につき、同じ対象を一緒にテストするペア形式にすると、観点の渡し方が具体的になります。狭い範囲で成功体験を作ることが、次の一歩の土台になります。

対象を一機能に限定し、範囲を明確にする
教える側が観点の理由を口に出しながら進める
気づいた観点はその場で観点表に追記する
終わったら良かった点と次の課題を短く振り返る

振り返りは、長い時間をかける必要はありません。テストが一区切りついたタイミングで、五分ほど「見つかった不具合」と「見逃しかけた観点」を口頭で共有するだけでも十分です。大切なのは、頻度を落とさず短く続けることです。間隔が空くと、せっかく渡した観点の記憶が薄れ、次の実践につながりにくくなります。

担当を広げる順序を地図にする

OJTを回すときは、担当をどの順で広げるかを地図にしておくと迷いません。これは「習熟の階段」ではなく、任せる範囲を型の明確なものから暗黙知に依存するものへと広げていく順序です。型がはっきりした領域ほど教材化しやすく、先に渡せます。

広げる順序	担当できるようになること	この順にする理由
定型ケースの実行	手順の決まったケースを回す	技法の型が明確で教材化しやすい
観点出し・ケース設計	観点からケースを起こす	型はあるが判断が入り始める
探索的テスト	実行しながら観点を立てる	暗黙知への依存が最も強い

ここでいう探索的テストとは、テストの設計・実行・学習を同時に進めるアプローチです。仕様書に明示されない挙動を、実際に動かしながら観点を立てて検証していきます。複雑な条件の網羅そのものは、デシジョンテーブルのような体系的技法の側で押さえる領域であり、探索的テストとは役割が異なります。

観点を言葉にする語彙をそろえたいときは、JSTQB認定テスト技術者資格のシラバスが参照先になります。資格のレベルを育成の段階に一対一で当てはめる必要はありません。用語と観点の共通言語として使うと、教える側と教わる側の会話がかみ合いやすくなります。

自動化は最上位ゴールではなく独立したトラック

ここで注意したいのは、自動化を育成の最上位ゴールに置かないことです。自動化は、探索的テストの延長線上にある「上がり」ではありません。観点理解とケース設計という同じ土台の上に立つ、別方向の独立したトラックです。

当面のゴールは、定型ケースと探索的なテストを一人で回せるところまでで十分です。自動化は、育成の体制が整った後に選ぶ任意の発展方向として、別枠で考えれば構いません。順序を取り違えて自動化を急ぐと、観点が固まらないままツールだけが増え、かえって手戻りを招きます。

当面の到達点は「一人で回せる」まで。自動化は体制が整った後の任意の発展方向です。

できる・できないでなく段階で見ると評価がぶれない

育成がうまくいかない現場では、評価が「できる人・できない人」の二分法になりがちです。二分法だと、少しの粗で「できない」に振れ、任せる機会が失われます。段階で見れば、「観点理解はできている、次はケース設計」と前向きに扱えます。

属人化そのものを構造から解きたい場合は、テスト業務の属人化を4層で解く視点を重ねると、どの段階に手を打つべきかが見えやすくなります。

教える時間を原価に織り込み、上司を説得する言葉を持つ

ここまでの打ち手は、時間という資源を前提にしています。ところが、教える時間が善意の持ち出しのままでは、どんな良い仕組みも続きません。育成を回すには、時間を正式なコストとして扱う必要があります。

育成が善意の持ち出しだと必ず止まる

教える時間がどこにも計上されていないと、育成は「余裕があるときにやること」に格下げされます。受託開発では余裕のある時期は稀で、結果としていつまでも後回しになります。善意に頼る運用は、忙しさの前で必ず崩れます。

教える時間を社内原価として工数配分に織り込む

対策はシンプルで、教える時間をあらかじめ社内の工数配分に織り込むことです。これは顧客への請求額に上乗せする話ではありません。育成にかかる時間を、案件の間接コスト、つまり社内原価としてあらかじめ見込んでおくという意味です。

育成担当分のレビューと指導の時間を、社内の工数計画に見込む
教材を副産物的に整える時間も、小さく計上しておく
案件を赤字にしないため、稼働の一定割合を上限に育成へ回すと決める
短期の割高を、属人化解消という中期の投資として位置づける

育成の時間は請求ではなく、稼働の一定割合を上限とした社内原価として先に配分する。これだけで、育成は「やって当然の業務」に位置づけ直せます。

費用対効果を1枚の簡易試算で示す

上司や経営を説得するには、感情論ではなく投資の言葉が要ります。定性的なフレーズだけでは弱いので、簡易な試算の型を一つ用意します。今の手戻りで失っている時間と、育成に充てる時間を、同じ物差しで並べるだけです。

項目	計算の型	自社の値を当てはめる
今の損失	手戻り工数 × 時間単価	（月あたりの手戻り時間）×（自社の時間単価）
育成コスト	指導・教材の時間 × 時間単価	（月あたりの育成時間）×（自社の時間単価）
比較	損失 − 育成コスト	差がプラスなら投資回収の見込み

具体的な金額は、自社の案件規模と時間単価を当てはめて出します。たとえば、手戻りに月20時間ほど費やしているなら、その一部を育成に振り向けても、数か月後には手戻り自体が減り、投資は回収に向かいます。

数字は大づかみで構いません。厳密な精度より、「今の損失」と「育成の投資」を同じ物差しに乗せて見せることに意味があります。並べて初めて、育成が費用ではなく投資だと伝わります。

テストやレビューに相応の工数がかかること自体は、IPAのソフトウェア開発分析データ集のような公開資料が、開発規模や工程配分の傾向として示しています。個別の数値を断定する材料ではありませんが、品質確保にコストがかかるという前提を経営と共有する材料になります。

育成の効果は遅れて表れると織り込む

教える時間を投資として扱うとき、もう一つ押さえたいのが、効果が表れるまでに時間差があることです。今月教えても、成果として手戻りが減るのは数か月先になります。すぐに数字が動かないのは、失敗ではなく仕込みの期間です。

この時間差を織り込まずに評価すると、「教えても変わらない」と早計に打ち切ってしまいます。四半期など、少し長い物差しで効果を見る前提を、あらかじめ関係者と合わせておきましょう。合意しておくだけで、途中で腰折れするリスクはぐっと下がります。

それでもテストを教えられる人がいないなら、外部の力の中立な使い方

打ち手を尽くしても、今この瞬間にテストを教えられる人がいないという現実は残ることがあります。そのときは、外部の力を選択肢に入れて構いません。大切なのは、丸投げではなく目的をはっきりさせて使うことです。

育つまでの品質と、育成そのものを分けて考える

外部の使い方を考えるとき、二つの目的を分けると判断がぶれません。ひとつは、社内が育つまでの間の品質を支えること。もうひとつは、外部の型を借りて社内の形式知化を早めることです。

目的	外部に期待すること	社内に残すこと
品質の下支え	当面のテスト実行を担保	判断と受け入れ基準
育成の加速	観点表や手順の型を提供	型を自社流に定着させる

全部外注ではなく、最小の使い方から試す

予算に制約があっても、外部の活用は「全部外注」である必要はありません。むしろ最小の使い方から試すのが現実的です。たとえば、育成が回り始めるまでの間だけ、負荷の高い一部の領域を短期・小ロットで頼む。それだけでも、教える側の時間に余白が生まれます。

生まれた余白を、そのまま教材づくりやOJTに回せば、外注が育成を止めるのではなく、むしろ後押しする形になります。

任せる領域と自分たちで持つ領域を線引きする

外部に任せる際は、線引きを最初に決めます。仕様の意図や受け入れの最終判断は、社内が持ち続けるべき領域です。反復的な実行や型づくりの支援は、外部に委ねやすい領域といえます。

線引きを決めておくと、外注先とのやり取りも締まります。曖昧なまま頼むと、判断まで相手任せになり、結局は社内に知見が残りません。逆に、実行は任せても観点表と受け入れ基準は自社が握ると決めておけば、外注は社内の型を試す機会にもなります。任せることと手放すことは、同じではありません。

内製と外注のどちらに寄せるか迷う場合は、内製と外注の判断基準を確認するための物差しを持っておくと、線引きの議論が具体的になります。

外注を社内の学びに変える受け取り方

外部に任せた成果物は、こなしてもらって終わりにしないことが肝心です。受け取ったテストケースや不具合報告は、そのまま社内の教材の下敷きになります。上手な報告ほど、社内の型を磨く見本として価値があります。

なぜその観点で見たのか、どう報告をまとめたのかを一度分解しておけば、外注は「代行」であると同時に「見本」にもなります。受け取り方を工夫するだけで、同じ費用から得られる学びが変わってきます。

外部の力は「育成の代わり」ではなく「育成を早める足場」として使うのが健全です。

よくある質問

最後に、現場から寄せられやすい疑問に答えます。どれも「今日から動けるか」に関わる問いです。迷ったときは、次の三つの原則に立ち返ると判断が軽くなります。

範囲は欲張らず、型の明確な領域から渡す
教材は作り込まず、業務の副産物として貯める
完成度より、任せて経験を渡すことを優先する

共通するのは「小さく始めて、続けられる形にする」という一点です。

教える人が一人しかいなくても育成は始められますか

始められます。テストを教えられる人がいない状態でも、一機能に絞ったペアテストからなら一人でも回せます。教える範囲を欲張らず、定型ケースの実行という型の明確な領域から渡すのがコツです。全体を任せる前提を捨てるだけで、最初の一歩は驚くほど軽くなります。

何から手をつければいいですか

観点の書き出しから始めるのが最短です。ベテランがよく見る観点を、通常業務の中で気づいたときに一言ずつメモするだけで構いません。まとまった時間を取る必要はなく、実施中の副産物として貯めれば、それがそのまま最初の教材になります。書きためたメモは、月に一度ほど眺めて表に整えるだけで十分に育っていきます。

教える時間をどう確保すればいいですか

社内原価として先に配分するのが答えです。教える時間を善意の持ち出しにせず、稼働の一定割合を上限に育成へ回すと決めておきます。見込みを工数計画に一行入れておくだけで、忙しくても真っ先に削られる項目ではなくなります。

自動化まで教えないと一人前ではないのですか

そうではありません。当面のゴールは、定型ケースと探索的なテストを一人で回せるところまでで十分です。自動化は育成の最上位ゴールではなく、体制が整った後に選ぶ任意の発展方向です。身の丈の到達点を先に定めるほうが、育成は前に進みます。

まとめ、育成は絞って、型にして、段階で回す

最後に、ここまでの流れを一枚に整理します。この詰まりは、5つの構造要因と、それぞれの突破口の対応で捉え直せます。

詰まる要因	突破口
教える人への集中	範囲を絞り、教材で分散する
暗黙知のまま	観点表・チェックリスト・バグ票の型にする
地図がない	担当を広げる順序を地図にする
時間が原価外	教える時間を社内原価として配分する
即戦力志向	段階で評価し、任せる機会を作る

大切なのは、全部を一度に直そうとしないことです。どれか一本をほどけば、絡んだ他の要因も緩み始めます。育成は、絞って、型にして、段階で回す。この順番で十分に前へ進みます。

明日からの最初の一歩は、次の三つのうちどれか一つで構いません。