「これ、最新版のファイルじゃないの？」というひと言に動揺する会議室。
ファイルサーバーに乱立する「最終版ファイル」の山──あなたのチームで、こんな現象が起こっていませんか？

こうした事態を、「単なる情報伝達ミス」と軽視するのは危険です。
なぜなら、チームに情報が十分に行き届いていない状況は、チームの信頼関係までをも根底から破壊することがあるからです。

今回は、そんなチーム崩壊の危険信号ともいえる「情報格差」がなぜ起こるのか、その原因を解明します。そして、プロジェクトを成功に導くPMOが実践する「誰も迷わない仕組みづくり」と、明日から使える改善ステップをわかりやすく解説します。

株式会社office Root（オフィスルート）
代表取締役社長
甲州　潤（こうしゅうじゅん）

国立高専卒業後、ソフトウェア開発企業でSEとして一連の開発業務を経験し、フリーランスに転身。国内大手SI企業の大規模プロジェクトに多数参画し、優秀な人材がいても開発が失敗することに疑問を抱く。PMOとして活動を開始し、多数プロジェクトを成功へ導く。企業との協業も増加し、2020年に法人化。さまざまな企業課題と向き合う日々。著書『DX時代の最強PMOになる方法』（‎ビジネス教育出版社）

なぜ情報格差が起きるのか──三つの構造的原因

まずは、私が実際に経験したプロジェクト定例会の風景を紹介しましょう。

どちらのケースも、「じゃあ、ファイルサーバーを確認しよう」となりましたが、サーバーには、以下のような「最終版」ファイルがいくつも乱立していました。

「プロジェクト計画書_最終版.xlsx」
「プロジェクト計画書_本当に最終.xlsx」
「プロジェクト計画書_20250115.xlsx」……

これでは、何が本当の最新ファイルなのか、誰も分かりませんね。
しかも、この状況が明らかになるまで、チームはそれぞれ違うゴールに向かって走り続けることになってしまうのです。

ここで「うちはExcel管理じゃないから関係ない」と思った方も注意が必要です。これはファイルサーバーやExcelだけの問題ではありません。Slackの検索結果に古い仕様書が混在していたり、Notionのどこに最新の決定事項があるか誰も即答できなかったりするなら、本質的には同じ「情報格差」という病に冒されています。

こうした情報格差は、以下の三つの構造的原因から生まれます。

【1】情報が散在

プロジェクト計画書はファイルサーバーに、議事録はメールに、タスク管理表はExcelに、進捗報告はチャットに……。 そんなふうに情報がバラバラな場所に保存されていると、「どこを見れば全体が分かるのか」が見えない状態に陥ります。

【2】 更新ルールがない

誰が、いつ、どのタイミングで更新するのか。 最新版はどうやって見分けるのか。 これらが決まっていないと「誰かが更新してくれるはず」という空気がメンバー間に流れ、当事者意識の欠如を生み出します。

【3】 「共有したつもり」文化

「メールで送ったから大丈夫」「チャットに書いたから見てるはず」といった意識はただの思い込みで、実際には伝わっていないことがほとんどです。さらに、相手が見たかどうかの確認もせず、「更新したつもり」「共有したつもり」が横行している状態は、多くのチームでよく見られます。

情報格差が引き起こす崩壊パターン

情報格差は、ただ最新ファイルがわからないというだけでなく、チームに連鎖的な悪影響を及ぼします。

まず、手戻りが増えます。
あなたが数日かけた作業も、「そのタスク、もう方針変わったから不要になったんだけど」という他メンバーのひと言で無駄になってしまうこともあるでしょう。

次に、チーム内での対立が激化します。
「そんなこと聞いてないです」「いや、共有したはずだよ」といった水掛け論が始まるかもしれません。誰が悪いわけでもないのに、責任のなすりつけ合いが生まれてしまうのです。

そして、最終的にモチベーションが低下します。
自分だけが古い情報で動いていたと気づいたとき、「なぜ私に教えてくれなかったのか」という不信感が生まれ、チームの一員としての意識が消えていくでしょう。また、「〇〇さんがきちんと共有していれば、こんなことにはならなかったのに」などと、責められた人も理不尽な思いを抱くに違いありません。

プロジェクトの途中で新メンバーが入ってきた場合、情報が整理されていないと正確なキャッチアップが不可能になります。さらに、途中参加のメンバーは、「どこを見れば今のプロジェクト状況が分かるんですか？」と質問した際、「えーっと……」と答えに詰まる既存メンバーを見て、このチームで仕事をしていくことを不安に思うでしょう。

このように、情報格差はチームの生産性だけでなく、信頼関係そのものを破壊していく可能性があるのです。

プロジェクト計画書をもとに情報を整備する

それでは、日々プロジェクト内で発生するさまざまな問題と向き合うPMOは、どのように情報格差を改善し、未然に防ぐ工夫をしているのでしょうか。

私の経験を踏まえてお伝えすれば、PMOはまず、プロジェクト計画書を軸に情報を整理します。

プロジェクト計画書には、目的、スコープ、スケジュール、体制、役割分担、コミュニケーション計画……と、プロジェクトの全体像が詰まっています。この計画書を「情報の中心」と位置づけ、そこから枝分かれする形で情報を整理していくのです。

ここで重要なのは、ドキュメント更新を「事務作業」ではなく、システムの「インターフェース設計」と同じだと捉え直すことです。

エンジニアがコードの可読性やAPIの整合性にこだわるのは、それがチームの生産性に直結すると知っているからです。情報共有も全く同じです。「プロジェクト計画書」というルートディレクトリを整備し、そこから各ドキュメントへのパス（別紙運用）を正しく通す。

例えば、詳細なタスク管理表は「別紙1」、技術仕様書は「別紙2」、議事録は「別紙3」というふうに、各タスクをプロジェクト計画書から参照できるようにします。

これは、チームという巨大なシステムの「情報の参照透過性」——つまり、いつ誰がアクセスしても、迷わず同じ正解にたどり着ける状態——を担保するアーキテクチャ設計そのものなのです。

プログラムコードの場合は、整合性がとれていないと動かずにエラーとなるため、すぐに気付けますが、情報共有の場合は、明確なエラーが発生しないため、意識して整備しましょう。

また、「一元管理」と「別紙運用」のバランスも重要です。

全ての情報を一つのファイルに詰め込むと、重くて扱いにくくなりますが、バラバラに管理するとまた散在してしまいます。

勝てるチームの情報共有・仕組み化ステップ

PMOが実践するこの「誰も迷わない仕組みづくり」のステップは 、具体的に以下の流れとなります。

ステップ1：棚卸し

まず、今プロジェクトで共有されている情報を全て洗い出します。 ファイルサーバー、メール、チャット、個人のPC……あらゆる場所を確認しましょう。

ステップ2：最新版の決定

複数のバージョンが存在する場合、「これが最新版」と明確に決めます。 そして古いバージョンは、アーカイブフォルダに移動します。
もし、古いバージョンが閲覧されていることがわかるのであれば、表紙やファイルの先頭などに、最新版のリンクを貼り、「最新版はこちら」と示すのも有効です。

ステップ3：更新ルールの設定

誰が、いつ、どのタイミングで更新するのかを決めます。たとえば、「毎週月曜日の定例会後、PMが更新する」というふうに明文化します。

ステップ4：途中参加者テスト

新しく参加したメンバーがいれば、「プロジェクトの現状を把握してください」と依頼してみてください。 10分以内に理解できなければ、情報整理が不十分だと判断できます。

ステップ5：定期見直し

月に一回、「情報共有の仕組みがうまく機能しているか」の振り返りミーティングを行います。 この時に使われていないドキュメントは削除し、必要な情報は追加します。

「誰が見ても分かる」の定義と心理的安全性の構築

情報を整備する際に重要なのは、「誰が見ても分かる」レベルに設定することです。

とはいえ、小学生でも分かるレベルの易しさを目指す必要はありません。
「プロジェクト関係者が理解できるレベル」で十分です。

ただし、共通言語をそろえることは必須です。
たとえば、「タスク」「課題」「リスク」といった言葉が、チーム内で同じ意味で使われているかを確認します。

そして何より大切なのは、「迷った時に聞ける雰囲気」を作ることです。
「こんなこと聞いたら恥ずかしい」と思わせない。
「分からないことは、いつでも聞いていい」という心理的安全性があってこそ、情報共有は機能するのです。

心理的安全性の構築については、本シリーズ第一回「沈黙する会議、表面的な議論……「崩壊チーム」の兆候を断つPMOの介入術」にて詳しく解説していますので、興味があればぜひ読んでみてください。

情報共有文化を育てる定例会と当事者意識を生む仕組み

さらに、PMOはプロジェクトの定例会の設計も工夫します。
ポイントとなるのは、「進捗報告」と「進め方アップデート」を分けて扱うことです。

「どういうこと？」と思われたかもしれません。
まず、進捗報告は、「今週何をやったか」を共有する時間です。
これは、基本的に淡々と報告すればOKでしょう。

しかし「進め方アップデート」は、もっと重要な時間です。

具体的に何をするかというと、以下のような「進め方の変更」を共有します。

「来週から、タスク管理の方法を変えます」
「新しいメンバーが加わるので、役割分担を見直します」

このような変更は、チーム全員が理解していないと後々混乱を招きます。
だからこそ、定例会では「進め方アップデート」の時間を設けることが大切なのです。

そして、プロジェクトの状況やチームメンバーは、時とともに変わっていくものです。
情報共有の仕組みを作っても、それが適宜アップデートされなければ、意味のないものになってしまうおそれがあります。

そこでPMOは、「アップデートのきっかけづくり」にも工夫をします。
ポイントは、「発言を”損”にしない」ことです。

発言者が損を感じるシーンとしては、たとえば以下のようなことがあります。

このような環境では、「発言しても意味がない」「間違った追記や更新がされてしまうかもしれない」などと感じてしまうでしょう。結局、「気になるけれど、発言しないでおこう」という意識が働き、問題が埋もれてしまうこともあるのです。

そこで、PMOが受け皿となり、「今の発言、重要ですね。私がドキュメントに追加しますので、後で確認してください」などと対応すれば、メンバーは気兼ねなく気づいた点を共有してくれるようになり、有意義なアップデートにつながるでしょう。

あるいは、「⚫︎⚫︎の情報に関しては、チーム内で▲▲さんが一番詳しいので、▲▲さんの実務ベースで更新をお願いします」のように、情報更新の適任者を見つけておき、その人に依頼すれば効率的に進められるケースもあります。

またプロジェクトにPMOがいない場合は、発言者と実際の更新をする人の「二人一組」で対応するのも一案です。
「更新してください」という一方通行では、更新されっぱなしで誰も見ない恐れがあり、「発言しても意味がない」状態に陥りがちです。

一方で、「更新したら、発言者など誰かが確認する」というサイクルを作る方が、意味のある更新となります。

その際、更新者はわかりやすい言葉選びや表示方法を意識し、確認者は「更新しているかどうか」ではなく、「初見でも理解できるか」という視点でチェックしましょう。

明日から使えるPMO流・情報共有チェックリスト

最後に、チーム内の情報格差を見つける五つの問いを紹介しましょう。

これらの問いに一つでも「No」があれば、そこに情報格差が潜んでいる可能性が高いです。情報格差はいずれチームを崩壊させる危険性がありますが、仕組みさえ備えていれば、確実に防ぐことができます。

明日からの一歩は、まずプロジェクト計画書を見直すことです。

「これを見れば、プロジェクトの全体像が分かる」状態になっているでしょうか？

なっていなければ、今すぐ整理しましょう。

書籍紹介

『DX時代の最強PMOになる方法』
著：甲州潤

▼こんなエンジニアはぜひお読みください。
・今の仕事に不満を持っていて、現状を変えたいと思っている
・給料をアップしたい
・エンジニアとしての将来が不安だ
・キャリアアップをしたいが、何をしたらいいかわからない
・PMOに興味がある
・PMOとして仕事をしたい

【目次】
第1章　一番稼げるIT人材は誰か
第2章　これからはPMOが1プロジェクトに1人必要
第3章　SEとPMOの仕事は何が違うか
第4章　稼ぐPMOになる７つのステップ
第5章　優秀なPMOとダメなPMOの見抜き方
第6章　PMOが最低限押さえておきたいシステム知識とスキル
第7章　システムは言われた通りに作ってはいけない
第8章　どんな時代でも生き残れる実力をつけよう

>>>詳細はこちら

【ご意見・ご要望はこちら】感想やご質問、今後取り上げてほしいテーマのリクエストなどをお待ちしています office-root.com