プロジェクトで情報が伝わらない現場のリアル
プロジェクトが炎上する原因の多くは、技術的な問題ではありません。私が10年以上PMOとして様々なプロジェクトを見てきた経験から言えば、最も多いのは「情報が伝わっていなかった」という単純な理由です。
「そんなこと聞いてない」「報告書に書いてあったはずですが」「会議で説明しましたよね」——こんなやり取りを何度目撃したか分かりません。情報は確かに発信されている。でも、受け手に届いていない。あるいは届いているけど理解されていない。これが現場のリアルなんですよね。
私はPMOとして10年以上、多国籍・多世代のチームでコミュニケーションマネジメントを担当してきました。特に印象的だったのは、日本と中国のメンバーが混在するプロジェクトです。当初、口頭でのやり取りに依存していたら『言った・言わない』のトラブルが頻発。文化や言語の違いで、微妙なニュアンスが伝わらないケースも多く発生しました。そこでコミュニケーション設計を全面見直しし、報告書の標準フォーマット、会議の運営ルール、チャットと議事録の使い分けを明確化しました。特に効いたのは『重要な決定は必ずテキストで残す』ルール。半年後、手戻りが大幅に減り、チームの生産性が向上しました。コミュニケーションマネジメントの本質は『情報を出す』ことではなく『必要な情報が必要な人に届く仕組みを設計する』ことだと、多国籍環境で身に染みて感じました。
この経験以来、私は「情報を出す」ことと「情報が伝わる」ことは全く別物だと痛感しています。報告書を作った、メールを送った、会議で説明した——それだけでは仕事は完結していないんです。相手がその情報を理解し、必要なアクションを取れる状態にして初めて、コミュニケーションは成功したと言えます。
特に中堅企業のプロジェクトでは、専任のPMOがいないケースも多く、プロジェクトマネージャーが片手間でコミュニケーション設計をしていることがあります。その結果、「とりあえず週次報告書を作る」「定例会議を開く」という形式だけが整っていて、肝心の情報伝達の仕組みが機能していないケースを頻繁に見かけます。
情報が伝わらないプロジェクトには、典型的なパターンがあります。まず、報告書が「書き手目線」で作られている。専門用語が並び、前提知識がないと理解できない内容になっている。次に、会議が「報告の場」になっていて、意思決定や合意形成の場になっていない。そして、情報共有ツールが乱立していて、どこを見れば最新情報があるのか誰も分からない状態です。
「伝えた」と「伝わった」の致命的な違い
私が担当したあるプロジェクトでは、開発チームが毎週きちんと進捗報告書を提出していました。フォーマットも整っていて、一見問題なさそうに見えます。ところが、プロジェクト終盤になって顧客から「こんな仕様になっているとは聞いていない」というクレームが発生しました。
調べてみると、該当の仕様変更は3ヶ月前の報告書にきちんと記載されていたんです。でも、顧客の担当者はその報告書を「受け取って保存していた」だけで、内容を理解していなかった。報告書は50ページ近い分量で、重要な変更点が埋もれていたんですよね。
これは極端な例かもしれませんが、似たような状況は日常的に起きています。情報は確かに存在する。でも、受け手がそれを認識できる形になっていない。これが「伝えた」と「伝わった」の致命的な違いです。
多層構造のプロジェクトで起きる情報の断絶
もう一つ、現場でよく見るのが「情報の多層構造問題」です。大きなプロジェクトでは、現場の開発メンバー、リーダー、PM、顧客の窓口担当、顧客の意思決定者という多層構造になっています。それぞれの層で必要な情報の粒度が違うんです。
現場のメンバーには技術的な詳細が必要ですが、顧客の意思決定者にはビジネスインパクトの要約が必要です。ところが、多くのプロジェクトでは同じ報告書を全員に配っている。結果として、現場メンバーには情報が足りず、意思決定者には情報が多すぎて読まれない、という事態が起きます。
私が関わった金融系のプロジェクトでは、開発側と業務側で使う用語が全く違うという問題がありました。開発側が「バッチ処理の遅延」と報告しても、業務側は「夜間処理」という言葉しか知らない。こういう小さな認識のズレが積み重なって、最終的に大きな手戻りにつながるんです。
なぜ情報は伝わらないのか——構造的な原因
30年近くこの業界にいて、様々なプロジェクトの成功と失敗を見てきましたが、情報が伝わらない原因には明確なパターンがあります。それは単なる「コミュニケーション不足」という精神論の問題ではなく、もっと構造的な問題なんです。
原因1:コミュニケーション設計が存在しない
多くのプロジェクトでは、スケジュール、予算、品質については詳細な計画を立てますが、コミュニケーションについては「適宜報告する」「定例会議で共有する」という曖昧な決め方しかしていません。これが最大の問題です。
PMBOKでは「コミュニケーションマネジメント計画書」という成果物を作ることになっていますが、実際に作っているプロジェクトは少数派です。誰が、誰に、いつ、何を、どの手段で伝えるのか——これを最初に設計していないプロジェクトは、情報伝達が属人的になり、重要な情報が抜け落ちます。
私がPJM-A(プロジェクトマネジメント・アソシエイト)の資格を取得した際に学んだことですが、コミュニケーション計画は単なる「報告書のテンプレート集」ではありません。ステークホルダーごとに必要な情報を分析し、最適な伝達手段と頻度を設計する、れっきとしたマネジメント活動なんです。
原因2:受け手の視点が欠落している
報告書や会議資料を作る際、多くの人は「自分が伝えたいこと」を起点に考えます。でも、コミュニケーションの本質は「相手が知りたいこと、理解できること」を起点にすべきなんです。
例えば、技術者が作る進捗報告書には「モジュールAの結合テストが完了」「データベースの正規化を実施」といった記述が並びます。でも、これを読む顧客の経営層が本当に知りたいのは「予定通り稼働できるのか」「追加コストは発生しないのか」という点です。
私が現場で見てきた優秀なPMは、必ず「この情報を受け取る人は、何のためにこれを読むのか」を考えてから資料を作ります。経営層向けには1ページのサマリー、現場向けには詳細な技術情報——同じプロジェクトでも、受け手によって資料を変えるんですよね。
原因3:フィードバックループが機能していない
情報伝達を一方通行にしてしまうと、伝わったかどうかを確認できません。報告書を送りっぱなし、会議で説明しっぱなし——これでは相手が理解したかどうか分からないんです。
効果的なコミュニケーションには、必ずフィードバックのループが必要です。「この報告書で分からない点はありますか」「今の説明で認識に齟齬はないですか」といった確認を入れる。または、相手に要約してもらう、次のアクションを確認する、といった双方向のやり取りが不可欠です。
私が関わったグローバルプロジェクトでは、日本側の「報告しました」と海外メンバーの「理解しました」の間に大きなギャップがありました。文化的な背景もあって、相手は理解していなくても「OK」と返事をすることがあるんです。だから、必ず「では、あなたの理解を説明してください」と確認するようにしていました。
現場で効くコミュニケーションの仕組みづくり
ここからは、私が実際に現場で使ってきた、情報が伝わる仕組みの作り方をお伝えします。教科書的なPMBOKの知識を、中堅企業のプロジェクトで使える形に翻訳した内容です。
報告書は「読ませる」のではなく「見せる」設計に
私が現場で使っているのは「3層構造の報告書」という考え方です。1ページ目にエグゼクティブサマリー(経営層向け)、2〜3ページ目に要点まとめ(PM・顧客窓口向け)、それ以降に詳細情報(現場メンバー向け)という構成にします。
忙しい経営層は1ページ目だけ読めば状況が分かる。現場の課題を深掘りしたい人は詳細まで読める。同じ文書でも、読み手によって読む深さを選べる設計にするんです。これだけで「報告書が読まれない」という問題の大半は解決します。
特に重要なのは、課題や遅延を「見える化」することです。私は信号機(赤・黄・青)のアイコンを使って、一目で状況が分かるようにしています。文章で「やや遅延気味ですが挽回可能です」と書くより、黄色信号のアイコン1つのほうが圧倒的に伝わりますよね。
会議は「情報共有の場」ではなく「意思決定の場」に
多くのプロジェクトで、定例会議が「報告を聞くだけの場」になっています。これは時間の無駄です。報告は事前に資料で共有し、会議では「判断が必要なこと」「合意が必要なこと」だけを議論する——これが私の基本方針です。
具体的には、会議の48時間前までに資料を配布し、参加者には事前に目を通してもらう。会議では「資料の内容で質問はありますか」から始めるのではなく、「今日決めるべきことは3点です」と宣言してから始めます。会議のゴールを明確にするだけで、時間の使い方が劇的に変わります。
また、会議では必ず議事録ではなく「アクションアイテムリスト」を作ります。誰が、何を、いつまでにやるのか——これだけを記録する。議事録のように「○○について議論した」という記述は要りません。次のアクションが明確になることが、会議の成果なんです。
ツールは「一元化」より「役割分担」を意識する
情報共有ツールについて、私が現場で使うなら「全ての情報を1つのツールに集約する」という発想はしません。むしろ、情報の性質によってツールを使い分けます。
Slackのようなチャットツールは、日常的な質問や軽い情報共有に使います。ここで重要なのは「フロー情報」として割り切ることです。チャットの過去ログを検索して情報を探す、という使い方はしません。重要な決定事項は必ず別の場所(後述のツール)に転記します。
Notionやconfluenceのようなドキュメント管理ツールは「ストック情報」の保管場所にします。プロジェクトの基本情報、設計書、議事録の要点、重要な意思決定の記録——後から参照する必要がある情報はここに集約します。私が現場で重視しているのは、誰でも同じ場所を見れば最新情報が分かる、というシンプルさです。
Backlogやjiraのようなタスク管理ツールは、作業の進捗状況を可視化するために使います。個人的にはBacklogのガントチャートとカンバンボードの組み合わせが、日本の中堅企業には使いやすいと感じています。Jiraは高機能ですが、IT専門ではない部門の人には少しハードルが高いんですよね。
ツール選定で私が30年の経験から強調したいのは、「高機能なツールより、全員が使えるツール」を選ぶべきだということです。PMだけが使いこなせるツールを導入しても、結局情報は属人化します。多少機能が劣っていても、プロジェクトメンバー全員が日常的に使えるツールのほうが、現場では圧倒的に効果を発揮します。
多国籍プロジェクトで学んだ「過剰なほど確認する」の価値
私が海外メンバーとのプロジェクトで学んだのは、「当たり前のことを当たり前に確認する」ことの重要性です。日本国内のプロジェクトでは「この程度は分かっているだろう」という前提で進めがちですが、それが伝達ミスの原因になります。
例えば、タスクの期限を「来週中」と伝えたとします。日本人同士なら「金曜日の終業時刻まで」という暗黙の理解がありますが、海外メンバーには通じません。「次の金曜日の17時(日本時間)まで」と明示する必要があります。面倒に思えますが、後で手戻りが発生するコストと比べれば、この確認コストは安いものです。
この「過剰なほど確認する」姿勢は、国内プロジェクトでも有効です。IT部門と業務部門、開発会社と発注会社——専門性や立場が違う人とのコミュニケーションでは、必ず認識のズレが生じます。それを前提に、重要な点は必ず言葉を変えて2回確認する、相手に要約してもらう、といった習慣をつけるだけで、伝達ミスは激減します。
30年現場にいた私が思うこと
PMBOKには「コミュニケーションマネジメント」という知識エリアがあり、立派な計画書のテンプレートも用意されています。でも、私が現場で30年近く見てきた実感として、教科書通りのコミュニケーション計画を作っているプロジェクトはほとんどありません。そして、それで構わないと思っています。
重要なのは、形式的な計画書を作ることではなく、「必要な情報が必要な人に届く」という本質を理解することです。私がPJM-A資格を取得したのも、PMBOKの知識を丸暗記したいからではなく、現場で使える形に翻訳するためでした。教科書は正しいことを言っていますが、そのまま使えることは稀なんですよね。
特に中堅企業のプロジェクトでは、大企業のような専任PMOを置く余裕がないことがほとんどです。だからこそ、シンプルで継続可能な仕組みが必要なんです。毎週50ページの報告書を作るより、1ページのサマリーを確実に作る。月次の大規模会議より、週次の15分ミーティングを確実に実施する。そういう「小さいが確実」なコミュニケーションの積み重ねが、結果的にプロジェクトを成功に導きます。
明日からできる小さな一歩
もしあなたがプロジェクトのコミュニケーションに課題を感じているなら、まず次の1つだけ試してみてください。次回の報告書や会議資料を作る前に、5分だけ時間を取って「この情報を受け取る人は何を知りたいのか」を箇条書きにしてみるんです。
たったこれだけで、資料の構成が変わります。専門用語の説明を追加するかもしれません。詳細な技術情報を削って、ビジネスインパクトの記述を増やすかもしれません。受け手の視点を意識する、この習慣だけで、あなたの情報伝達力は確実に向上します。
コミュニケーションマネジメントは、特別な才能やスキルが必要な領域ではありません。相手の立場で考える、伝わったかを確認する、継続できる仕組みを作る——この3つを意識するだけで、誰でも実践できます。そして、これが習慣になれば、あなたのプロジェクトから「そんなこと聞いてない」という言葉が消えていくはずです。
情報が伝わるプロジェクトは、不思議と人間関係も良好です。なぜなら、多くの対立や不信感は「情報の非対称性」から生まれるからです。全員が同じ情報を持ち、同じ理解のもとで動いている——そんなプロジェクトを、一緒に作っていきましょう。
コメント