「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が迷わないレベルまで要件を言語化する作業」や、事後の「AIが出力したコードやテストが正しいかを監査・検証する作業」に、圧倒的な工数（コスト）を積んでいます。
「製造に何日かかるか」ではなく、「AIへの指示と出力の検証にどれだけの工数をかけるべきか」。これが、これからのWBSの基本形になります。
ブラックボックスを制御する：新しい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の違いと、次世代のキャリア戦略
