「AIに任せました」で炎上させない。ハイブリッドWBSとQAの再構築｜AI時代のPM生存戦略②
「AIで実装は終わりました！」 その一言で、安心したはずのプロジェクトが、数日後に炎上する。
そんな場面に、心当たりはないでしょうか。
画面は動いている。機能も一通り揃っている。それなのに・・・ テストは不十分、例外処理は抜け漏れだらけ。 気づけば、修正の連鎖でスケジュールは崩壊している。
問題は、AIではありません。AIに任せた後の管理の仕方が、従来のままだからです。
第1回でお伝えした通り、AIの登場によって「実装には時間がかかる」という前提は崩れました。 工数の本質は、「作業時間」から「意思決定と検証の時間」へと変わっています。
にもかかわらず、WBSもQAのルールも昔のままでは、 AIのスピードに管理が追いつかず、プロジェクトは簡単にコントロールを失います。
第2回の今回は、「AIに任せました」で炎上させないために、 PMが明日から使えるハイブリッドWBSと新しい品質保証の仕組みを具体的に解説します。
「作る」から「検証する」へ：ハイブリッドWBSの引き方
これまで私たちが慣れ親しんできた「基本設計 → 詳細設計 → 製造 → 単体テスト」という、きれいに工程を分けて進めるウォーターフォール型のタスク分割は、AI時代にはそのままではフィットしなくなっています。
なぜなら、実行型AIは、十分に具体化された要件さえあれば、実装からテストコードの生成までを一気通貫で実行できるためです。
これからのPMに求められるのは、どこまでをAIに任せ、どこを人間が「関所」としてチェックするかを、事前にWBS上で明確に定義しておくことです。
明日から使える「ハイブリッドWBS」テンプレ
では、具体的にどのようにタスクを分割し、工数を積めばよいのでしょうか。ここでは「ユーザー登録機能」を例に、新しいWBSの引き方（1行テンプレ）をご紹介します。
AIと人間が共存するWBSの例（ユーザー登録機能）
- 要件言語化（AI指示書作成）： 0.5人日 【人間】
- AI実装（コード生成）： 0.1人日 【AI＋人間】
- 設計ルール・基本構造の監査： 0.5人日 【人間】
- テスト設計レビュー： 0.5人日 【人間】
- テスト実行・結果確認： 0.5人日 【人間】
※工数配分はプロジェクト規模や難易度によって変わりますが、「実装＜言語化・検証」になる構造が重要です。
ご覧の通り、AIがコードを書く「実装」の工数（0.1人日）は大きく圧縮されています。その一方で、事前の要件を言語化する作業と、事後の出力結果を検証する作業に、より多くの工数を割り当てています。
これからは、「製造に何日かかるか」ではなく、「AIへの指示と、その出力をどう検証するか」に工数を積む時代です。
ブラックボックスを制御する：新しいQA（品質保証）の仕組み
WBSを引き直したら、次は品質の担保です。AIが数分で書き上げた数千行のコードを、人間が1行ずつ目視でレビューするのは現実的ではありません。
ここでPMがチームに徹底させるべきなのが、「コードの中身」ではなく「振る舞い（テスト）」をレビューの主軸に据えるというマネジメントです。
QAの関所：「AIが書いたテスト」を人間がテストする
最近のAIは、実装と同時にテストコードも書いてくれます。一見すると「これでテストも万全だ」と思いがちですが、ここに大きな落とし穴があります。
AI自身が作ったテストは、「AIが自分が実装した通りに動くか」を確認しているだけの自己満足なテストになりがちです。 特に、AIは正常系（うまくいくパターン）を過剰に最適化する傾向があり、異常系や境界値（極端な入力）の抜け漏れが頻繁に発生します。
また、特に性能やセキュリティといった非機能要件は、AIの標準出力だけでは担保されないため、人間の設計と検証が不可欠です。
したがって、人間（QA担当やシニアエンジニア）の最も重要な仕事は、コードの細かい書きっぷりを指摘することではありません。
「AIが書いたこのテストケースの網羅性は妥当か？」「このエッジケースがすっぽり抜けていないか？」
これを監査するプロセスを、品質保証（QA）の絶対的な関所として設定してください。テスト設計のレビューこそが、ブラックボックスを制御する最大の武器になります。
進捗管理の指標を変える：「完了率」の罠
WBSと品質保証のルールが変われば、当然、進捗の測り方も変わります。ここでPMが陥りがちなのが「AIによる実装完了＝進捗の大幅な前倒し」と錯覚してしまうことです。
「コードが動いた」時点では、体感的にはまだ20%程度
AIを使えば、画面が動き、一見完成したように見えるシステムがすぐにできあがります。
しかし、そこを進捗の基準（たとえば「実装が終わったから80%完了」）にしてしまうと、プロジェクト終盤で「セキュリティチェックが全く通らない」「データが増えたら性能要件を満たせない」といった大炎上が起きます。
厳しいようですが、「とりあえずコードが動いた」という状態は、システム開発全体から見れば、体感的にはまだ20%程度に過ぎません。むしろ、スタートラインに立った状態と言った方が近いでしょう。
「検証の消化率」をマイルストーンにする
では、どう進捗を管理すればいいのか。 これからの進捗管理は、「どれだけ作ったか」ではありません。 「どれだけ検証を通過したか」＝検証の消化率です。
❌ 誤った進捗指標：「コーディングが〇ファイル終わった」
⭕ 正しい進捗指標：「テストケースのレビューと承認が終わった」「セキュリティスキャンをパスした」
検証を軸に進捗を測ることで、プロジェクト終盤で発生する見えない手戻りという時限爆弾を、未然に防ぐことができます。
まとめ：AIを安全なエンジンに変える「検証」中心のマネジメント
第1回で述べた通り、これからの工数は作業時間ではなく、意思決定と検証の時間です。
AIツールの導入だけでは、プロジェクトは成功しません。むしろ、AIの出力スピードに管理が追いつかず、あっという間にコントロールを失います。
検証に工数を積むWBSを引き、テスト設計を監査するQAをルール化し、検証の消化率で進捗を測る。 この仕組みを変えて初めて、実行型AIはプロジェクトを推進する安全で強力なエンジンになります。
しかし、どんなに完璧なWBSやルールを作っても、それを実際に動かすメンバー（人）の意識が変わらなければ、現場は回りません。
次回（第3回）は、手を動かしてコードを書くことに固執するベテランや、AIにすべてを丸投げする若手をどう育て、どう評価すべきか。PMが直面する「メンバーのリスキリングと新しい評価基準」について解説します。
シリーズ：AI時代のPM生存戦略
【第1回】実行型AIで再定義されるシステム開発の3つの常識
【第2回】「AIに任せました」で炎上させない。ハイブリッドWBSとQAの再構築（本記事）
【第3回】AIでチームが壊れる理由｜「自分で書くベテラン」と「AI任せの若手」をどう動かすか
【第4回】AIに駆逐されるPM・無双するPMの違いと、次世代のキャリア戦略
