PMO支援を外部に頼む、という判断は珍しいものではなくなりました。人材紹介にもコンサルティング会社にもPMO支援のメニューが並び、大規模プロジェクトの多くに外部のPMOが入っています。その一方で、PMOが入っているのに結合テストで重大な欠陥が一斉に発覚するプロジェクトも、なくなっていません。本コラムの主張は二段です。前半では、この現象の構造を書きます。進捗報告とは成果物を人が要約したものであり、要約の過程で悪い情報は薄まるため、報告の確認だけを業務範囲とするPMOは、問題を検知できる時期が構造的に遅れます。よく参照される支援型・コントロール型・指揮型というPMOの分類は権限の強さの分類であって、この検知能力の軸——成果物を読むかどうか——が抜けています。後半では、AI駆動開発がこの限界を致命的にすることを書きます。生成が速くなった結果、書いた量や動く画面を根拠とする進捗率・消化率は、残作業の近似として機能しなくなりました。報告を確認するPMOは、読む材料そのものを失います。では成果物を読むPMOは何を読み、何を統制するのか。その各論までを、発注側がPMO支援を選ぶときの判断材料になる形で書きます。
PMO支援の標準的な業務範囲を並べると、進捗会議の運営、課題管理表とリスク一覧の整備、報告資料の作成、会議体の調整、といった項目になります。どれも必要な仕事です。ただし、この業務範囲には共通の性質があります。扱っているものがすべて、成果物そのものではなく、成果物について人が書いた要約だということです。
進捗報告がどう作られるかを追うと、こうなります。担当者は自分の作業状況を週報に書きます。このとき、遅れは「リカバリ可能」と書かれます。リーダーはチームの週報を取りまとめ、個別の遅れは「調整中」に丸められます。会議資料になる頃には「概ね順調(一部タスクに遅延、影響軽微)」です。誰も嘘をついていません。要約とは情報を捨てる操作であり、捨てられるのは決まって、書き手にとって都合の悪い情報です。この構造は、報告のフォーマットを精緻にしても変わりません。
報告と実物——設計書、コード、テスト——が初めて強制的に突き合わされるのは、結合テストです。順調と報告されてきたプロジェクトが結合テストで一斉に問題を吹き出すのは、そこで初めて、要約ではなく実物同士が突き合わされるからです。進捗率の数字を会議で問い詰めても、この構造は動きません。数字の元が要約である限り、問い詰めて精度が上がることはないからです。
進捗報告は成果物を人が要約したもので、要約が重なるたびに悪い情報は薄まる。座る場所が検知の時期を決める。
PMOが入っているのに検知が遅れるプロジェクトで起きているのは、多くの場合、能力の問題ではなくこの構造の問題です。報告の経路の終端に座っている限り、届く情報は薄まった後のものしかありません。
PMOの類型としてよく参照されるのが、支援型・コントロール型・指揮型という分類です。支援型は事務局としてプロジェクトを支え、コントロール型は基準への準拠を管理し、是正を求め、指揮型はプロジェクトの意思決定そのものに踏み込む。外部にPMO支援を頼むときも、この分類で「どこまでの権限を渡すか」を議論するのが一般的です。
この分類は間違ってはいませんが、軸が一本しかありません。測っているのは権限の強さだけです。そして前章の構造を踏まえると、権限の軸だけで選ぶことには明確な穴があります。扱う情報が報告のままなら、権限が強いほど、精度の低い情報で強い判断を下すことになるからです。指揮型のPMOが要約された報告をもとにプロジェクトの方向を決めるのは、権限の弱い支援型より、むしろ危険です。
抜けている軸は、一次情報——成果物——を読むかどうかです。
私たちはこの軸の右側を技術型PMOと呼んでいます。進捗・課題・リスクの管理という従来業務に加えて、次を業務範囲に含める形です。
これらは管理資料の整備ではなく、成果物を読む仕事です。読むためにはエンジニアリングの経験が要ります。PMO支援の外部委託で最初に確認すべきは、支援型かコントロール型かではなく、この業務範囲が入っているかどうかです。
軸の違いは、検知の時期の違いとして現れます。具体例を三つ挙げます。
テーブル定義の変更。実装の途中で、担当者が自分の機能の都合でカラムを足す、型を変える。担当者にとってこれは作業の一部であり、進捗報告には「実装中(順調)」としか書かれません。報告ベースのPMOがこれを知るのは、結合テストで他機能のデータ不整合として発覚したときです。成果物を読むPMOは、テーブル定義の差分を監視対象にしているため、変更されたその日に検知します。検知した時点で判断できます——この変更は承認するのか、差し戻すのか、影響する他機能はどれか。
テストの消化率90%。消化率は順調に見えます。しかしケース一覧を開くと、9割が正常系で、異常系と境界値がほとんどないことがあります。消化率という数字は、テストの網羅を測っていません。実行した件数を、書いた件数で割っているだけです。分母の質を読まない限り、この数字から品質は分かりません。ケース一覧を読むPMOは、テスト実行が始まる前——ケースが書かれた時点で、網羅の穴を指摘できます。
障害票の偏り。報告に載るのは件数の推移で、「今週の新規障害は12件、収束傾向」と書かれます。しかし12件の中身を読むと、8件が同じモジュールに集中していることがあります。これは12件の障害ではなく、一つの設計問題が8つの顔で現れている状態です。件数の推移からは収束に見え、分布を読むと構造問題が見えます。
三つに共通するのは、報告ベースの検知が結合テスト以降——手戻りが最も高くつく時期——になるのに対し、成果物ベースの検知は問題が作られた当日から数日以内になることです。従来、この差を埋められなかったのは、成果物を読む工数が高かったからです。すべての差分を人が読むことは、専任のレビュアーを置いても追いつきませんでした。この工数の前提が、AIで変わります。ただしその前に、同じAIが従来型のPMOに何をするかを見ておきます。
進捗率という指標が機能していたのには、前提がありました。書く速度が開発の律速であり、したがって書いた量が残作業のよい近似になっていたという前提です。工数見積りも消化率も出来高管理も、この上に成り立っていました。
AI駆動開発は、この前提を崩します。生成は数分で終わり、動くデモが初日にできます。書いた量も、動く画面も、進捗の証拠にならなくなりました。
「90%完了と報告されたまま、残り10%が終わらない」という現象は、プロジェクト管理の古典です。AIはこれを解消するのではなく、加速させました。従来は数週間かけて到達していた「見た目の90%」に、初日に到達するようになったからです。画面は動きます。デモは成功します。しかし、業務ルールの網羅、異常系、締め処理、権限の実態——検証されていないものの量は、見た目からは分かりません。生成された大量の差分は人間の読む速度を超えて積み上がり、レビュー待ちが新しいボトルネックになります(この構造はスペック駆動開発に疲れたのでConstitutional AIの思想で開発してみたに書いた通りです)。
消化率も同じ道をたどります。テストケース自体をAIが量産するようになると、分母が膨らみ、消化率は今まで以上に「実行の割合」でしかなくなります。
進捗率が機能していたのは、書いた量が残作業の近似になっていたからである。生成が速くなると、この近似が成立しなくなる。
ここで、報告を確認するPMOに何が残るかを考えると、答えは「ほとんど何も残らない」です。進捗率は進捗を測らず、消化率は品質を測らず、動くデモは完成を意味しない。要約された報告の確認という業務は、その報告が近似していたはずの実態が消えたことで、確認する対象を失いました。AI駆動開発においてPMO支援を従来の業務範囲のまま導入することは、機能しないことが最初から分かっている統制を買うことに近いと考えています。
では何を統制するのか。私たちが受託開発の統制基準として整理し、Claude Code プロジェクトパックとしてOSS公開している内容から、PMOの業務範囲に当たる部分を抜き出します。
進捗の定義を、成果物完了基準の0か100にします。「90%完了」という報告は受理しません。成果物ごとに完了の条件——テストが通る、レビューを通過する、正本と突き合わせ済み——を先に決め、条件を満たすか満たさないかだけを進捗として数えます。パーセントの中間値を認めた瞬間、見た目の進捗が数字に混入します。
生成と検証を分離します。実装したAI(あるいは人)に、その実装のテストを書かせない。自分の成果物を自分でレビューして「問題ありません」と報告させない。検証は必ず別の実行、別の担当が行います。分離されていない検証は、検証ではなく自己申告です。
正本を管理します。仕様書・テスト・評価基準のうち、どれを動かない正本とするかを決め、生成物の側から正本を書き替えさせません。テストが通らないときに直してよいのは実装であって、テストではない——この規律の運用がPMOの仕事になります(正本の設計自体は仕様駆動か、テスト駆動か、評価駆動かに整理しています)。
検収可能性を維持します。機能ID→受入基準→設計書項番→テスト番号を全成果物で連結し、断絶を検出します。「このコードは誰が書き、誰が検証し、どのテストで確認されたか」という監査の問いに、成果物のIDから辿って答えられる状態を保つ。AIの生成速度と、エンタープライズの検収・監査要件を両立させる背骨がこれです。
会議運営や報告資料ではなく、成果物の構造への統制である。成果物を読めるPMOにしか運用できない。
見ての通り、どれも会議運営や報告資料の話ではありません。成果物の構造に対する統制であり、成果物を読めるPMOにしか運用できません。そして第3章の終わりに書いた「読む工数」の問題は、ここで反転します。差分の要約、設計との乖離検出、テスト網羅の分析——読む作業の大部分は、AIがPMOの側の武器にもなるからです。AIは生成の速度で従来型PMOの前提を崩しましたが、同時に、成果物を読む型のPMOが全量を扱うことを初めて可能にしました。
成果物を読むPMOには、もう一つ守るべき規律があります。検知した問題を、指摘のまま現場に投げないことです。
指摘一件は、現場にとって作業一件です。「テーブル定義が設計と乖離しています」「異常系のテストが不足しています」——指摘だけを積み上げるPMOは、検知能力が高いほど現場の負荷になり、やがて情報が入ってこなくなります。統制は、現場からの情報の流れが止まった時点で機能を失います。
私たちが運用しているのは、検知した問題に修正案の下書きまで添えて持ち込む形です。テーブル定義の乖離なら、影響を受ける機能の一覧と、設計に戻す場合・変更を採用する場合それぞれの修正範囲。テストの網羅不足なら、不足しているケースの候補一覧。完成した解決策である必要はなく、判断の材料が揃った半解決の状態で十分です。現場に渡すものが「宿題」から「選択肢」に変わると、PMOと現場の関係が変わります。
これも、AIで工数の前提が変わった領域です。影響範囲の列挙も、修正パッチの下書きも、ケース候補の生成も、かつては指摘の何倍もの工数がかかる作業でした。いまは検知から数分で用意できます。修正案を添えない理由が、工数の面からは消えています。
整理します。
PMO支援の外部委託で最初に決めるべきは、支援型かコントロール型か、常駐か週次か、といった体制の話ではありません。報告を扱う業務を頼むのか、成果物を読む業務を頼むのかです。前者は会議と資料の運営であり、検知は結合テスト以降になります。後者は設計・コード・テストへの統制であり、検知は問題が作られた当日から数日です。そしてAI駆動開発が入ったプロジェクトでは、前者の確認対象である進捗率・消化率そのものが機能しなくなっているため、この選択は実質的に、統制が機能するかしないかの選択になります。
候補となる支援会社への質問は、次の三つで足ります。
成果物——設計書・コード・テストケース——を直接読むことは、業務範囲に入っていますか。
進捗率は何を根拠に算出しますか。「90%完了」という報告をどう扱いますか。
AIが生成した成果物の検証は、誰が行う設計になっていますか。
三つ目の質問は、ベンダー選定の記事(AI駆動開発の外注コスト)に書いた質問と同じ構造です。この語彙で会話が成立するかどうかで、報告の運営を売る会社か、成果物への統制を売る会社かは判別できます。
関与の形は、常駐だけではありません。統制点の設計と初期のレビュー基準づくりは厚めに、運用が回り始めたら設計・コードのレビューと定例での助言に絞る——技術顧問に近い少ない稼働の形でも、成果物を読む統制は成立します。私たちが大規模なアプリ刷新に発注側のPMOとして参画した例は、MaaSアプリ リニューアル・PMO支援に載せています。
Chapter Techでは、技術型PMOとしての参画、開発標準・レビュー基準の策定、AI駆動開発を前提とした統制設計までをエンタープライズDX & FDE支援サービスとして提供しています。いま入っているPMOの業務範囲がどちらの型か、という見立ての段階からで構いません。お問い合わせからご相談ください。