本サイトの学習用の分類・回答例です。実際の試験の公式正答や配点ではありません。回答例で補った期限や役割は、問題文の条件に合わせて見直してください。 教材の評価観点と前提
日常業務やプロジェクト運営に関する案件群。計画組織力と問題分析力で、リソース配分と進捗管理を構造化する判断が求められます。
エンジニアが最も経験のあるパターン。原因の切り分けを明示すると高評価。
プロジェクトの遅延や品質問題は、リリース直前という最も緊張の高い局面で提示されます。案件文には、残り期間、発見された不具合の件数、顧客への共有状況といった数値が含まれ、受験者に選択肢の比較を迫ります。技術的な背景を持つ受験者ほど原因究明に引き込まれますが、管理職に求められているのは原因の特定ではなく、限られた時間で誰に何を判断させるかの設計です。増員・スコープ縮退・期限再調整という三つの基本オプションを、コスト・品質・顧客影響の三軸で比較する型を持っているかどうかが、回答の説得力を決めます。
A優先となるのは、意思決定の遅れがそのまま選択肢の消滅を意味するためです。リリースまで二週間ある時点なら増員も期限交渉も可能ですが、一週間を切ると実質的にスコープ縮退しか残りません。つまり、この案件における時間は選択肢の在庫であり、判断を先送りするほど打てる手が減ります。さらに、顧客へ進捗を共有済みという条件が付いている場合、こちらから状況を伝える前に相手が異変に気づくと、隠蔽を疑われて信頼が損なわれます。技術問題としてはB相当でも、意思決定案件としては常にAで扱うのが定石です。
本日中にPMから、欠陥の重大度別件数、影響を受ける機能範囲、原因の仮説を三十分で報告させます。それをもとに、増員によるリカバリー、機能を絞った段階リリース、期限の再調整という三案を、追加コスト・品質リスク・顧客影響の三軸で比較した資料を明日午前までに作成させます。私は本日中に上長へ状況を一報し、顧客への説明方針について合意を得ます。顧客に対しては、事実と現時点での回復見通し、次回報告のタイミングを明日中に共有する段取りとし、隠蔽と受け取られる余地を残しません。並行して、テスト工程の見直しを再発防止課題として起票します。
増員、範囲の調整、期日の変更を同じ基準で比較しているかを確認します。増員に立ち上がり時間が必要な場合など、対策自体の制約も書けると判断の理由が明確になります。PMからの報告と顧客への説明を誰が担当するかを分け、既存の指揮系統を不用意に二重化しないようにします。原因が確定しない間にも、確認済みの影響と次の報告予定を伝えられるかを見直します。
技術的な問題の構造化が得意なはず。「原因を切り分ける」プロセスを明示すると高評価。