進捗報告は隠れた税金 — 必要なのは認知のしくみ

今日は木曜日の午後。チームの3人は、何も価値を創造していない。作業について、ただ書いている。週次の進捗報告をまとめているのだ。金曜の朝には10人が会議に参加し、ただレポートを読み上げるだけに1時間を費やす。

管理者はこの儀式が必要だと考えている。しかし誰もが、内心では無駄だと感じている。会議が終わっても、理解が深まった、問題が解決した、という実感はない。同じ質問が来週もまた浮上する。実際にダメージを与えるリスクは、いつだってスライド資料やスプレッドシートには載っていないものだ。

さて、ここからが居心地の悪い話だ。

レポートや会議は、単なる時間の無駄ではない。ある一線を越えると、本来築くべきものを蝕んでいく。チームが共有する知識や理解が崩壊する。このテーマについてはすでに研究されており、スライド資料よりも優れたツールが存在する。

連携の隠れたコスト

当たり前に聞こえるのに、真剣に検討すると世界が変わる発見から始めたい。2004年、軍の指揮チームを研究していた人間工学の研究者グループが、それに名前を与えた。コミュニケーション・オーバーヘッド——チーム認知の隠れたコスト（MacMillan, Entin & Serfaty）である。

彼らの主張はこうだ。チームは単一の情報処理ユニットとして動かなければならない。そのためにメンバーは情報を交換し続け、全員が状況について共通の像を保つ必要がある。だが、その情報交換はタダではない。時間がかかり、認知の帯域（人々が実際に仕事をするために必要な、有限の注意リソース）を消費する。

コミュニケーションをより不要に、あるいはより効率的にできる範囲において、チームのパフォーマンスは向上する、という主張である。これは直感や常識をひっくり返す。

プロジェクトが混乱していると感じると、反射的にコミュニケーションを足したくなる。もう一本のレポート、朝会の後の昼会、進捗報告の追加。だが、この類のコミュニケーションはコストであって、解決策ではない。秩序を求めてむやみにコミュニケーションを増やすのは、すきま風を直すために暖房を強めるようなものだ。

まとめると、次のようになる。

• 理想像は、仕事の内容を明確に理解・共有していて、何度も説明し直す必要が生じないチーム。
• 会議は、その理想像を築くための投資であり、形骸化したコストではない。
• 壊れた進捗報告の文化とは、理想像は決して手に入らず、情報共有の儀式だけが残る組織構造である。

チームが本当に共有しようとしているもの

では、この共有される理想像とは何なのか。組織心理学の2つの考え方がそれを言い当てている。そしてこの2つこそ、本稿の核心だ。

1. 共有メンタルモデル

要は「こうすれば、こうなる」というモノサシや基準を共有している状態である。

この分野で最も引用される研究（Mathieuら, 2000）は、チームメイトが収束した「課題についての、そしてチームの動き方についてのモデル」を持つとき、連携がうまくいき、成果も上がることを示した。

重要なのは、その効果が連携を通じて働く点だ。共有された理解は魔法のように成果を改善しない。確認し続ける代わりに、互いの動きを予測できるようにすることで成果を改善する。

後年の研究（Van den Bosscheら, 2010）は、こうしたモデルが実際にどう築かれるかを示した。基準を一方的に発信することではなく、共同構築と建設的対立を通じて成される。人々が1つの問題に共に取り組み、解決することによって、モデルとして精錬されるのだ。

共有メンタルモデルの精錬は、まさに組織文化の種と言える。

2. 連携メモリ（トランザクティブ・メモリ）システム

シンプルに「誰が何を知っているかの索引を共有し、高速検索できる」状態である。

データベースのインデックスのような「誰が何を知っているか」という共通認識である。健全なチームでは、誰もすべてを抱えてはいない。しかし、知識がどこにあるかは全員が知っている。決済連携はテックリードの担当、なぜ移行が見送られたかはプロジェクトマネジャーが覚えている、デプロイの課題はプラットフォームチームのNotionに書かれている、というように。

連携メモリは、集合知への索引（インデックス）であり、チームのパフォーマンスを安定して予測する。最近では、病院の外傷救急チームのような、一刻を争う現場でも実証された（Argoteら, 2025）。そこでは何かを説明し直す時間などなく、チームは誰が何をするかをただ知っていなければならない。

肥大化したレポート文化は、共有メンタルモデルと連携メモリにどう影響するのだろうか。

共有メンタルモデルは、問題に共に取り組むことで築かれる。1人が9人に向けて進捗を読み上げる会議は、共同構築の対極にある。それは一方通行の放送に近い。

そして連携メモリは、知識（ノウハウ）がどこにあるかを皆が知っていることに依存している。だが、知識が先週の進捗の一行としてレポートや議事録に書かれるだけでは、個人の記憶に依存した状態になり、誰かが異動すれば文脈・背景ごと消えてしまう。

形骸化したレポートと進捗報告の文化は、本物の集合知が築かれたはずの時間を食い尽くす機会費用である。

これは典型的なPMO問題である

PMOの典型的な失敗は「自動化なき成熟」といえる。

ガバナンスを足すよう求められる。より多くの監督、より多くの保証、より多くの報告ライン。それぞれ単体では理にかなっている。だが、どれも同じ労力とコストが必要になる。人が物事を書き留め、人が会議に参加するコストである。その結果が、PMOのベテランなら誰もが見覚えのあるパターンだ。

報告書が増え、会議が増え、エクセル資料が増え、結果は変わらない。オフィスはより忙しくなり、プロジェクトはいっこうに明瞭にならない。

コミュニケーション・オーバーヘッドという税金が、必須な投資のように振る舞っている。PMOはプロジェクト群についての共有情報、集合知、理想像を組織にもたらすために生まれた。だが、進捗を手作業で集約することでしかその使命を全うできないのであれば、全リソースを形骸化したコミュニケーションに費やし、情報の資産化に回すリソースは残らない。

本当の問いは「どうすれば効率の良い会議ができるか」ではない。チームの共通認識を維持するために、レポートや属人化した記憶よりも優れた方法はないのか？という論点である。

なぜ会議で効果的な意思決定ができないのか

もう1つだけ研究を引用したい。良い会議でさえなぜ効果的でないかを説明する研究である。Sheaら（2014）は、共有された課題に取り組む2人以上の思考を調和させることの重要性に言及した。

彼らはこれを超個人的な認知制御と呼ぶ。あなたの確信を共有し、それをグループとしてどう扱うか重要なのだ。そして研究は、人々がその確信度を共有し、調整された声に大きな重みを与える（単に最も声が大きい、あるいは最も役職が上の声にではなく）とき、共同の意思決定が測定可能なほど良くなることを示している。

会議では、この調整された判断は一度だけ、声に出して交わされ、そして蒸発する。検証可能な成果物やフォーマットとして再利用可能になっていない。あとから誰も「あの見積もりは何に基づいていたのか」「前の四半期、私たちの意思決定は適切だったか」とは問えない。

チームが生み出す最も価値ある認知の産物（不確実性を付したその推論）には、永続する保管場所がない。それは空気中に発せられ、失われる。そしてまた会議を開いてそれを再構成し、また税金を払う。多重課税である。

Cognition as Code——より良いツール

意思決定のロジックをコードに変える。これが本当の解決策になる。コードが賢いからではない。コードは、文書や会議よりもはるかに優れたチーム認知の保管場所だからだ。先の3つの考え方に当てはめてみよう。

誰もが「使える」共有メンタルモデル

チームがスケジュールを予測する方法、2つの選択肢を比較する方法、プロジェクトの健全性を読む方法が、開かれた実行可能な関数——モンテカルロ・シミュレーション、総所有コスト（TCO）モデル、アーンドバリュー計算——として書かれているとき、その手法はもはや1人の専門家の頭に閉じ込められたり、会議のたびに蒸し返されたりしない。全員が同じモデルを、同じやり方で計算された姿で見ている。

辞めない、消えない、連携メモリ

「この種の案件では認証まわりのタスクはだいたい3割超過する」が、1人のベテランの直感の中に住むのではなく調整パラメータとして符号化されているとき、それは揮発性の短期記憶ではなくなる。チームが苦労して得た「誰が何を知っているか」は「システムがそれを知っていて、その根拠も示す」になる。専門知への索引が、人の入れ替わりを生き延びる。

検証可能なメタ認知

これが最も鋭い点だ。モンテカルロ予測は、ただ日付を返すのではない。確信度を付した日付を返す。「85%の確率でここまでに収まる」というように。ベイズ補正は、ただ見積もりを調整するのではない。どれだけ確信しているかを報告し、実データがそれに見合うぶんだけ分布を狭めていく。

それはまさに、良い集団の意思決定がそれに基づいて回るとSheaの研究が言う、調整され発信可能な確信度だ。ただし今や、それは書き留められ、検証でき、そして持続する。モデルに何を仮定したかを問える。来四半期、判断が良かったかを確かめられる。チームの最も価値ある認知の産物が、ついに永続する保管場所を得て、複利で積み上がっていく。

そしてここで、AIがその保管場所に配置される。

誰も手作業でやるべきでない仕事——進捗を集約し、指標を計算し、本物の不確実性がどこにあるかを浮かび上がらせること——は、まさによく設計されたエージェントが継続的に、安価にこなす仕事だ。人間の対話を置き換えるためではない。オーバーヘッドを肩代わりし、意思決定そのものについて対話できるようにするためだ。

人とAIのチームに関する近年の研究は、こうした連携の仕事を引き受けるエージェントが、生産性の高さと結びついていることを示唆している。会議はデータ読み上げの儀式であることをやめ、本来あるべき姿になる。システムがすでに組み立てた理想像をめぐって、人間がしっかりと対話する場に変化する。

ユースケースで考える、コード化の利点

中規模のPMOが12のプログラムを統括していると仮定する。木曜から金曜にかけての儀式は、控えめに見積もっても週にアナリスト2人日分の時間に加え、時間の大半を「そもそも数字が何を意味するのか」を確認するガバナンス会議のコストがかかる。本物の意思決定——どこに資金を動かすか、どのリスクに優先して対応するか——には、全員が疲れ切った最後の10分しか残らない。

必要なのは「会議をやめる」ことではない。共有された理想像を、資料から検証可能なロジックへ移すことだ。

スケジュールの確信度は、ひとつの楽観的な日付ではなく、その幅を示すシミュレーションから得る。コストの比較は、誰もが監査できる共有モデルを通す。見積もりの偏りは、誰も発言しない会議で蒸し返すのではなく、完了した仕事から自動的に学習されるようにする。

そうなると、アナリストは単なる書き起こし係ではなくなる。システムとして稼働する共通認識のキュレーターとして活動を始める。ガバナンス会議は、共有モデルがすでに画面に映った状態で始まる。時にそれはインテリジェンス・コミュニティ的な「動的な分析モデル」として、リアルタイムに値を変えながら議論する場になる。

本当に人間が価値を生み出すことに1時間を使う。コミュニケーション・オーバーヘッドは下がる。共有された理解はシステム上にモデルとして追加され、資産化される。

利点だけでなく、課題も存在する

3つ指摘がある。研究もまた、この3点については明確だ。

すべてを符号化することはできないし、しようとすべきでもない。暗黙的で文脈に富む判断——ステークホルダーの本当の意図を読む、チームの士気を感じ取る——は、無理に型にはめれば壊れてしまう。符号化できる部分（数式、指標）はコードに属し、本当に暗黙的な部分は人に属する。適材適所は残るということであり、すべてをAIが代替するわけではない。PMOの仕事が奪われるわけではないのだ。

会議は敵ではない。人々が難しい問題に、本当に収束するまで取り組むことこそ、共有メンタルモデルが築かれる方法であり、それには（本物の）対話が必要になる。目標は会議をゼロにすることではない。進捗の読み上げから解放され、本当にそれを必要とする収束の作業ができる会議にすることだ。

そして共有モデルは硬直しうる。不自然に完全合意したチームは、自分たちの理想像を疑うのをやめてしまう。コードやロジックは改訂可能であり続けねばならない。硬直マインドセットより、実際の結果によって更新されるモデルのほうが大切だ。共有モデルが資産でいられるのは、更新の余地という成長可能性が残されている場合である。

来四半期にできる3つのこと

コミュニケーションにおける「多重課税」を解決するために、新しい高額なシステムを導入する必要はない。

1. 報告が実際に何のためにあるかを棚卸しする

1サイクルのあいだ、繰り返される報告と会議のそれぞれに、共有された理解を築いている（人々が問題に収束していく）か、進捗を垂れ流している（情報が一方向に流れる）かの印をつける。後者は純粋なオーバーヘッドであり、人の手から離して、ロジックを自動化し、システムへ統合すべきものだ。

2. 明日にも消えてしまいそうな知識を見つける

チームが知っているが、属人化している揮発性の記憶（メモリ）を5つ挙げる。「役員がいつも突っ込むのはこの論点だ」「認証はいつも開発が遅れる」「あのベンダーは催促が要る」の類だ。そのひとつひとつが連携メモリの単一障害点であり、記憶ではなくシステム化もしくは自動化の対象だ。

3. 重要な数字ひとつに確信度を付ける

最も重要な予測をひとつだけ取り上げ、単一の数字として報告するのをやめる。予測を点ではなく面・幅として報告し、その確信の論拠を書き留める。あなたはたった今、良い意思決定に必要だと研究が言う、共有され検証可能で調整された判断へと変えたことになる。そして来四半期、それが正しかったかを確かめられる。

次回予告

ここまでのすべては、ひとつの動きにかかっている。意思決定のロジックを文書と会議から取り出し、エージェントが計算し、求めに応じて差し出せる何かへと移すことだ。だが、エージェントが役に立つのは、あなたの仕事が実際に息づく場所——アシスタント、計画ツール、リポジトリ——にアクセスできる場合だけだ。

その接続には、いまや標準がある。Model Context Protocol（MCP）だ。本シリーズの次稿では、pmo.runのMCPサーバーを紹介する。AIアシスタントがこれらの意思決定ツールを直接呼び出せるようにする層であり、共有する理想像をシステムとして組み上げられるように支援する。

本稿は、プロジェクトのデータを意思決定の知性へと変えることをめぐる pmo.run シリーズの一部である。その背後にあるアーキテクチャを描いた AIエージェントと共に進化する — Cognition as Code を土台にしている。ロジックモジュールは github.com/lemur47/logic でオープンソース公開中。

本稿が参照した研究：コミュニケーション・オーバーヘッドの概念は MacMillan, Entin & Serfaty（2004）, Communication overhead: The hidden cost of team cognition；共有メンタルモデルは Mathieu et al.（2000） と Van den Bossche et al.（2010）；行動チームにおける連携メモリは Argote et al.（2025）；確信度の共有が集団の意思決定の基盤であるという説明は Shea et al.（2014）（Bahrami et al.（2010）「Optimally interacting minds」, Science を踏まえている）。