【補足】公式なコミュニケーション, 非公式なコミュニケーション

昨日のプロジェクトの事例紹介の中で、コミュニケーションの手法を使い分けていることに触れました。

プロジェクトのトラブルの要因として、最も・・・とは言い切れないのですが、コミュニケーション不足によるトラブルは多く存在するのではないかと思っています。

コミュニケーションといっても難しく、むやみに会議体を増やした場合には、逆に生産性が落ちてしまいます。

PMBOKでは、コミュニケーション手法をテーマに、「公式なコミュニケーション」と「非公式なコミュニケーション」と分類し解説している部分があり、これらを知っているか、知らないかで、プロジェクトの成功・失敗が大きく別れると感じています。

そして、もっと言ってしまえば、トラブルプロジェクトの多くにおいて、公式なコミュニケーションに依存している、より具体的には、ステークホルダーの本音を引き出せていないことが一因となっていることも多いのではないでしょうか。

本記事では、公式なコミュニケーション、非公式なコミュニケーションについて、筆者の実例を交えながら解説していきます。
プロジェクトの情報をどのように伝達するかに関わる重要な概念です。まずは、以下にその違いを解説します。

1.公式なコミュニケーション

概要

プロジェクトのコミュニケーション管理計画に従い、構造化された情報伝達手段です。
例えば、ステークホルダーへの定期的な進捗報告、定例検討会議、中間報告会、最終報告会、時には、メールでの定期報告などもありますし、議事録や月次報告書といった文書類が含まれる場合もあります。

メリット

信頼性が高い
・　事前に計画された手順に従って実施されるため、信頼性が高い。
一貫性や正確性がある
・　一貫性や正確性を保ち、プロジェクトの進捗状況や課題管理、リスク管理を行うことができる。
記録に残る
・　議事録などで文書化され、意思決定や内容を含めて関係者全員に共有されることが多い。記録が残るため、後から確認できる。

デメリット

リソース消費が大きい
・　会議の準備や文書化に多くの時間とコストがかかる。
柔軟性に欠ける
・　計画に沿って進めるため、予期せぬ変更に迅速に対応しにくい。
コミュニケーション不足の要因
・　特定の時点でのみ行われるため、日々の小さな変更には対応しづらい。公式なコミュニケーションのみでは、コミュニケーション不足になりがち。

2.非公式なコミュニケーション

概要

プロジェクトチーム内で自然に発生する、柔軟で構造化されていないやり取り。
日常的な相談、助言など、比較的自由で柔軟な形で情報を共有します。
チャット、電話や立ち話によるカジュアルな会話、メール、メッセージアプリなどがあります。

メリット

迅速かつ柔軟
・　形式にとらわれないため、柔軟で迅速にコミュニケーションできる。
人間関係や信頼関係の構築
・　プロジェクトメンバー同士の信頼関係構築に役立つ。
イノベーションの促進
・　形式にとらわれないため、自由な発想が出やすく、プロジェクトの改善や新しいアイデアに繋がることがある。
問題の早期発見 
・　チームメンバー間の円滑なコミュニケーションの中で、潜在的な問題を早期に発見し、解決することがある。

デメリット

記録が残らない
・　記録に残らない場合があり、後で確認が必要な場合や証拠が必要な場合には対応できない。
情報の透明性
・　個別に情報が伝えられるため、情報が一部のメンバーに届かないなど伝わる範囲が限られ、認識のズレが生じる可能性がある　
誤解・誤認識
・　意図が伝わりにくい場合があり、解釈の違いが生じるリスクがある

3.具体的な活用事例

公式なコミュニケーションと非公式なコミュニケーションを使い分ける具体的な事例をいくつか挙げて説明します。

事例(公式) 1 : キックオフ・ミーティング

プロジェクト開始時には、ステークホルダーを集め、プロジェクトの目標、範囲、スケジュール、リソースなどを確認します。
キックオフミーティングの議事録やプロジェクト計画書は公式な文書として記録し、関係者全員に共有します。

実体験
プロジェクトの全体像や進め方を明確にしておくことで、全員が同じ目標に向かうための基盤ができます。これは、全てのプロジェクトで実施しておいて良かったと思っています。
特に、プロジェクトの価値、何の成果を求めるかという点について合意しておくことができれば、成果"物"が多少、柔軟に変わったところで、大きなクレームには発展しません。
ステークホルダーにもよりますが、やはり成果物に目が行きがちな担当者もいれば、それが何の役に立つのかといった考え方で、物事を見ていらっしゃる方も混ざっていますので、目線を揃えると言う観点では、最初のキックオフは非常に重要な位置づけです。

また、キックオフの段階になって、新たなステークホルダーが増えていることもありますし、スケジュールや内容が少し変えてほしいと言う要望が出てきたりします。

余談ですが、可能であれば、キックオフは対面で実施する方が良いと思っています。
お客様を含めたプロジェクトメンバーの顔を合わせることで、信頼関係が生まれたり、最初から良い雰囲気を作れると、そのまま最後まで良い雰囲気が続いたりします。

事例(公式) 2 : 定例会議による進捗・課題・リスクの報告

プロジェクト進行中は、週次や隔週などの頻度で定期的に進捗を報告します。
また、合わせて、課題管理やリスク管理も行います。

実体験
進捗報告については、遅延があれば、対応方針などを協議することもあります。
むしろ、それより重要だと感じているのは、先のタスクを見通すことです。よくある事なのですが、お客様側が、別の作業などにより、"遅れる見込みである" ということがよくあります。

遅れてから対応するのではなく、先を見越して遅れることを予想し、よりプロアクティブに対応方針を検討していくことができるようになると、プロジェクトが安定してきます。

課題管理やリスク管理については、誰がボールを持っているか、対応漏れがないか等の観点で確認を行っています。
また、お客様側でしばらく対応されていない課題が残っていれば、お客様が何か困っている兆候なので、後から個別に電話で会話し、様子を探るなど、プロジェクトのタスクを前に進めるアクションのきっかけになることもあります。

事例(公式) 3 : プロジェクト変更管理

プロジェクトのスコープやスケジュールに変更が必要な場合、変更が必要な理由や内容、影響などをまとめ、変更管理プロセスに従って承認を得ます。変更内容は文書化し記録することで、関係者全員が確認できるようにします。

実体験
個人的な体験ですが、多くのステークホルダーが集まり、大々的に変更管理が求められる場合には、その時点でもはや大きなトラブルに発展しており、仕方なく変更管理をせざるを得ない状況に陥っていることが多いと思います。

そして、多くの場合において、変更管理をしたらプロジェクトが落ち着くかと言うと、その場凌ぎになりがちであり、引き続きトラブルは続いていると言う展開が多い気がします。

改めて変更管理について考えてみると、直感的に必要性は分かるものの、あまり有り難味は感じていないと言うのが正直なところです。

中には、変更管理した数ヶ月後に、もう一度変更管理でスケジュールを遅らせると言ったプロジェクトもありました。
変更管理プロセスを1度回すにしても、大規模プロジェクトになってくると、影響の精査だけでも大変で、精査にかなりの工数が割かれ、そのせいで余計にタスクが遅延するような展開も見ています。

その意味では、PMBOK 第6版にある大々的な変更管理プロセスを使いこなすのは私も苦手ですし、うまく使いこなしている方がいらっしゃれば、ぜひコツやポイントを教えていただきたいと思います。

事例(非公式) 1 : チームメンバー同士のカジュアルな相談やアイデア出し

カジュアルな雰囲気の話合いにより前向きなアイデアや意見を出したり、メンバー間の距離を縮め、信頼関係を構築します。

実体験
ディスカッション形式のミーティングなどは、ファシリテーションに注意が必要ですが、慣れてくると非常に有効なコミュニケーション手法になります。
様々なステークホルダーからアイデアや意見を出していただき、成果に反映していくことができれば、より前向きにプロジェクトに関与してくれるようになる場合もありますし、個人的な価値観や想いを知ることもできます。

よりカジュアルな方法として、ランチやコーヒーブレイク中の雑談でお互いの経験や経歴、得意分野を知ることもあります。これにより、その後の作業の分担や協力がスムーズになることもあります。

また、個々の担当者が抱える課題をチームメンバーに軽く話すことで、解決の糸口が見つかり、問題を解消できることもあります。

事例(非公式) 2 : 成果物の初期段階でのフィードバック

成果物の初期段階でカジュアルにフィードバックを受けることで、最終確認までに必要な修正や改善をスピーディに行うことができます。

実体験

成果物の草案や初期バージョンの段階では、非公式なミーティングやチャットで軽いフィードバックをもらうこともあります。
例えば、チームメンバーに「ここをもう少し改善できる」といったアドバイスを非公式に得ることで、後の公式なレビューがスムーズに進むように準備できます。

コミュニケーションの観点とは少し異なりますが、早めに成果物の全体像を作成し、イメージのすり合わせができれば、その後の期待値のギャップが小さくなります。

また、成果物の内容についていくつか選択肢があり、悩んだ際には、事前にカジュアルに電話などで相談するといったこともあります。
内容によっては、お客様も決めかねる展開も多々ありますし、その場合には、まとまった時間をとってディスカッションを行うなど、次のアクションにつなげています。

逆に、あまりよろしくないのは、定例会議など公式なコミュニケーションの場において議論した結果、発散し、意思決定できず、そのまま遅延が生じるといったパターンです。

少なくとも、プロジェクトの中で悩ましい点があれば、事前に関係者に展開し、前もって検討できるようにするべきでしょう。

事例(非公式) 3 : クライアントとの日常的なやりとり

日常的にやりとりすることで、クライアントの期待やニーズを把握し、満足度を向上させます。メールや電話で、クライアントの細かい要望や意見を気軽に確認し、すぐに対応することもあります。

実体験

最初は、プロジェクトの内容に関する会話が中心になりますが、継続していくと、お客様と雑多な会話ができるようになってきます。
特に電話やSMS, Teams, Slackなどのカジュアルなコミュニケーションは、積極的に活用すると良いでしょう。

また、プロジェクトの内容以外にもお客様から相談をいただくのであれば、高い信頼を得ている証だと考えています。

私はベンダー側の立場ですので、それをきっかけに新たな案件を受注したりすることもありますし、後続のフェーズにつなげることもあります。

まとめ

公式なコミュニケーションは、正確性や責任の明確化が重要な場面では効果的ですが、柔軟性に欠け、リソースを消耗しがちです。
一方、非公式なコミュニケーションは、迅速さや柔軟性が必要な場面で有用ですが、記録が残りにくく、曖昧になってしまう可能性もあります。
プロジェクトマネージャーはこの両者を適切に使い分け、バランスを取ることで、円滑で効果的なプロジェクト運営を目指すことが重要と言えます。