「テストケース、書けたら見せて」と新人に声をかけたあと、上がってきた表を見て言葉に詰まる。 正常系のパスばかりが並んでいて、異常系も境界値もユーザーの実利用シーンも抜け落ちている。指摘して書き直してもらうと、次のリリースでもまた同じ抜けが出る。
受託開発の現場で、こうした「テスト観点が出せない新人」をどう育てるかは、多くのリーダーが抱える地味で重い悩みです。テストケース表のフォーマットを渡しても、観点リストを共有しても、本人の頭の中で観点を生み出すスイッチが入らない限り、品質は安定しません。
この記事では、シニアやリーダーが指導の場で使える「観点を引き出す4つの問いかけ」と、それをチームに定着させる対話の流れを整理します。新人本人ではなく、教える側のあなたに向けた内容です。
なぜ「観点リストを渡す」だけでは育たないのか
新人がテスト観点を出せない原因を、本人の能力不足や経験不足だけに帰結させると、指導は手詰まりになります。実際には、教え方の構造に問題が潜んでいることが多いです。
観点リストは「結果」であって「思考の入口」ではない
ベテランが整理した観点一覧は、長年の事故と修正の積み重ねから出来上がった完成品です。新人にこれを渡しても、観点が並んでいる「理由」までは伝わりません。理由がわからないものは、別案件に応用できません。
テストケース表のフォーマットが思考を固定化する
最初にケース表のテンプレートを渡すと、新人は「表のマス目を埋める作業」としてテスト設計を捉えてしまいます。本来はその前に、対象機能から観点を発散させる工程があるはずですが、ここが省略されて見えなくなります。
「気づけよ」という指導が再現性を奪う
レビューで「ここの境界値が抜けてるよ」と指摘するのは早いのですが、なぜそこに気づけたのかという思考プロセスを言語化しないと、新人は「先輩は勘がいい」で終わってしまいます。次回また同じ抜けが出るのは、指導が暗黙知のままだからです。
観点を引き出す4つの問いかけ
ここからが本題です。テストケース表を渡す前、あるいはレビューの最初の5分で、新人に対して順番に投げる4つの問いを用意してください。難しいフレームワークではなく、対話で観点を発散させるためのシンプルな質問です。
問いかけ1：正常系（「うまくいくとき、何がどうなれば成功？」）
最初の問いは、機能の成功条件を新人自身の言葉で定義してもらうことです。 たとえば「申込フォームの送信ボタン」であれば、「メールが管理者に届く」「ユーザーに完了画面が表示される」「DBに登録される」など、複数の成功定義が並ぶはずです。
ここでよくあるのが、新人が「ボタンを押せること」だけを成功条件として答えてしまうケースです。それを否定せず、「他には？」「ユーザーから見た成功は？」「システムから見た成功は？」と視点を変えて聞き直していくと、新人の中で「成功は1つではない」という感覚が芽生えます。
問いかけ2：異常系（「うまくいかないとき、どんな失敗がある？」）
正常系を出したあとに、その裏返しとして異常系を引き出します。 「メールが届かなかったらどうなる？」「DBに書き込めなかったら画面はどうなる？」「ユーザーが2回連打したら？」という問いを重ねます。
ポイントは、新人が思いつかないときに正解を教えないことです。代わりに「もし通信が切れたら？」「もしサーバーが落ちていたら？」と仮想シナリオを与え、本人に展開させます。シナリオを与えるところまではこちらの仕事ですが、その先の異常パターン展開は本人にやらせます。これを繰り返すうちに、「機能のたびに異常シナリオを自分で立てる」癖がつきます。
問いかけ3：境界（「区切りはどこ？その内側と外側で何が変わる？」）
境界値テストは新人がもっとも苦手とする領域です。「文字数」「金額」「日付」「件数」など、機能の中にある区切りを一緒に列挙していきます。
「最大100文字までという制約があるけど、99文字・100文字・101文字でそれぞれどうなる？」と具体的に問うと、新人は「同じになると思います」と答えがちです。そのときに「実装担当に聞いたことある？」と返すのが効果的です。境界の挙動は仕様書だけでは決まらず、実装と仕様の境目にバグが潜んでいる、という現場感覚を伝える機会になります。
問いかけ4：ユーザー文脈（「実際に使う人は、どんな状況でこれを触る？」）
最後に、機能の利用シーンを言語化させます。「この申込フォーム、誰がいつ何のために使う？」「スマホ？PC？」「電車の中？オフィス？」「初めて？2回目以降？」といった問いです。
ここまで来ると、新人の中に「ユーザーが回線の弱い場所で送信ボタンを連打したら」「途中で画面を閉じて戻ってきたら」といったテストシナリオが自然に生まれます。仕様書には書かれていない観点が、文脈の問いから引き出されてきます。
テストケース表は最後に渡す。指導の基本フロー
4つの問いかけを実際の指導にどう組み込むかが、定着のカギです。受託開発の現場で使える基本フローを示します。
1. 機能の対象範囲を一緒に確認する（10分）
要件定義書や画面仕様書を開いて、対象機能の範囲と前提条件を口頭で確認します。ここで新人に「この機能は何のためにある？」「前提条件は何？」と聞き、要件の読み解き自体に不安があれば、テストの前にそちらを補強します。要件と前提が揺れているとテスト観点も揺れます。
2. 4つの問いかけで観点を発散する（20〜30分）
ホワイトボードや共有ドキュメントを開き、新人に観点を箇条書きで書かせながら4つの問いを順番に投げていきます。シニア側はファシリテーション役で、答えを書かない・正解を出さないことを徹底してください。
3. 観点を分類して優先度をつける（10分）
発散した観点を、リスクと頻度で分類します。「これは出るとまずい」「これは滅多に起きないけど致命的」「これはまれだが確認は不要」といった判断軸を新人と一緒に置いていきます。受入基準との突き合わせも、このタイミングで行うと効果的です。受入基準そのものの整理に課題がある場合は、受入基準で品質ゲートを設計する｜リリース延期を止める実務 も参考になります。
4. テストケース表に落とす（本人作業）
ここでようやくテストケース表のフォーマットを渡します。発散・分類が済んでいるので、表を埋める作業はメカニカルに進みます。新人にとって、テスト設計の本体は表の前段にあると体感できます。
5. レビューで「思考プロセス」をフィードバックする
成果物のレビューでは、観点の抜けを指摘するだけでなく、「自分はこういう問いから気づいた」という思考の経路を言語化して伝えます。これを繰り返すと、新人の頭の中で問いかけが内面化され、自分1人でも観点を発散できるようになります。バグ票の傾向を バグ票を改善につなげる｜不具合傾向の3軸読みで品質を立て直すPM実務 のように振り返って、観点漏れの傾向を本人と一緒に見るのも有効です。
よくある失敗とその回避
失敗1：問いを投げるはずがレクチャーになる
シニアが熱心であるほど、問いの形を取りながら結局答えを言ってしまいがちです。沈黙を恐れず、20秒待つだけでも新人は何か絞り出します。考える時間を奪わないでください。
失敗2：観点をベテラン基準で評価する
ベテランの観点リストと比べて「ここが足りない」と評価すると、新人は萎縮します。比較対象は「先週の自分」「前回の案件」に置くほうが、伸びが見えやすくなります。
失敗3：1回の指導で完結させようとする
4つの問いかけは1度で身につくものではありません。3〜5機能ぶん繰り返してようやく自走の兆しが見えます。短期で成果を求めず、案件をまたいで同じフローを回すことを前提に設計してください。
まとめ
新人のテスト観点を引き出す指導は、観点リストを共有することではなく、観点を生み出す「問いの流れ」を渡すことです。正常系・異常系・境界・ユーザー文脈の4つの問いかけを、テストケース表より先に置く。発散・分類・記述・レビューを5ステップに分けて回す。これだけで、抜けの再発はかなり減ります。
そのうえで、新人本人の自学には体系的な教材が必要です。テストレベルの全体像（単体・結合・システム・受入）や境界値・異常系の基本観点を一通り押さえてもらうと、現場での問いかけが本人の中で構造化されます。指導側の準備が整ったあとに渡す教材として、Udemy 公開予定の 【IT基礎】ソフトウェアテスト入門：料理の味見で学ぶテストと品質の基本（FEX-101） が向いています。要件定義の読み解きに不安があるメンバーには、合わせて 【IT基礎】要件定義の読み方入門：家を建てる設計図で学ぶ要件の構造（FEX-119） を渡すと、テストの前段である仕様の読み込みも整います。
最新の公開状況とコース内容の詳細は コース一覧（/courses/） から IT 基礎カテゴリを確認してください。指導者の問いかけと、新人本人の体系学習。この2つがそろってはじめて、観点漏れの再発が減り、手戻りの少ないチームに変わっていきます。