このシリーズは、私がこれまで経験したプロジェクトで培ったマネジメントノウハウを、PMBOKの知識体系に沿って、駆け出しPMの方々や新入社員向けの読み物的な位置づけでノウハウや考え方をまとめています。ぜひご覧ください。
コミュニケーションマネジメントにおける各プロセスは以下の通り。
コミュニケーションマネジメントは平たくいえば、報告の挙げ方に関する領域です。
誰から、誰に、どんな内容を、どの頻度で、どうやって報告するかを定義しておくことで、各プロジェクト関係者/ステークホルダーごとに漏れなく適切な情報を伝達することが目的です。
計画定義
コミュニケーションは人から人への情報伝達です。
その人が誰か、どのような人がいるかはステークホルダーマネジメントをもとに深堀し、探ることとします。
ここでは、よくあるプロジェクト計画書にあるコミュニケーション計画を具体例と共に記載しますので、参考にしていただければと思います。
１．ステアリングコミッティ
ステコミと呼ばれる、所謂偉い人たちによる意識決定会議のことです。
プロジェクトの進行に関わる重大な問題が発生した時の対応方法の検討や、利害関係者間の調整などを実施します。比較的軽いところであれば、要件定義の期間延伸などが挙げられます。
PMとしてはこのステコミを実施するタイミングのセンスが問われます。また、ステコミ実施に当たっては上長（プロジェクト最高責任者など）に対してプロジェクト状況を事前に報告しておきます。顧客に対してズバッと言ってほしいところはどこか、どういうスタンスの会議になるか、どういう結論にもっていきたいかを伝えておくと良いです（むしろやっておくべきです）。これによりステコミを慎ましく進行することに全力を注ぎます。考え方が古いかもしれませんが、ステコミは会議の前には既に勝敗がついていると考えておくべきです。
２．ゲートレビュー
工程完了判定といっても良いです。当工程の完了条件が満たされていることの確認、当工程の重要けって事項の振り返り、積み残し課題、次工程申し送り事項の確認を実施します。
ゲートレビューのうち本番リリース直前のレビューを、リリース承認会やリリース判定会と呼び、リリース内容の確認やテスト状況の確認を行うことも多いです。
３．月次報告 ４．週次報告
月次報告には顧客側のプロジェクトオーナーを招き、ベンダー側のPMと顧客側のPMからプロジェクトとしての報告を入れることがあります。オーナーの要請によってその実施の有無は判断されることもあります。
月次報告は実施しないことも多いですが、間違いなく週次報告は存在します。これは、ベンダーから顧客に対する報告です。この週次報告の内容を顧客側がまとめて、月次報告としてプロジェクトオーナーに報告してくれるとベンダーとしてはありがたいですね。
週次報告としては、今週の作業実績と課題、次週の作業予定を報告します。また、プロジェクト遂行上の課題があれば報告し、対応方法の検討と対応依頼を行います。
５．課題検討会議
４．週次報告の中で実施できれば不要です。しかし、プロジェクト規模が大きくなればなるほど週次報告ですべての課題に対しての検討はできなくなります。とはいえ、すべての課題に対して対応方法をいずれは実施していかなければいけないため、そのための作戦会議の場となります。
また、通称”ワイガヤ”（ワイワイガヤガヤ）と呼ばれるような場として、毎回の定型的な報告はせず、その場その場で検討が必要な事項を話題に挙げて議論、検討する場として設けることもあります。
結構、こうした”ワイガヤ”によって得られるものが多かったりもするので侮れないです。ただ、試用容量には要注意で、何のための会議なのか目的を見失った場合、惰性で行っている場合はすぐに辞める勇気も必要です。
６．仕様要件検討会議
週次報告や課題検討会議はあくまでプロジェクト遂行における課題について検討する場でした。しかし、開発対象のシステムに関する細かい要件を詰めていく必要もあります。
成果物レビューの場というのが最もわかりやすいですが、レビュー前の認識合わせ、合意形成としてこの会議をうまく使うことでプロジェクトはスムーズに進みます。そのため、PLやアプリケーションマネージャーはこの会議を使い倒さなければいけません。
７．週次リーダー会議
プロジェクト体制図上PM以外にPLが複数人いるような場合、PMとPL、PL同士の情報共有の場となります。所謂、ベンダー側のリーダ会議です。
８．日次会議
所謂朝会、夕会と呼ばれる会議です。私はあまり朝会、夕会がないプロジェクトには参画したことがないため、ほとんどの場合で存在すると思います。
朝会・夕会がなかった現場はその代わりに日報を記載して報告していたプロジェクトはありました。
ここまでで、例としてベンダー目線で、顧客とベンダーが関わる会議から、ベンダー内部の会議までを説明しました。しかし、顧客にベンダー内の会議体をわざわざ報告する必要はないです。そのため、プロジェクトキックオフ資料であれば、ベンダー内部は割愛することがほとんどです。
また、上記例では会議体ということですべて会議・打合せの形式をとっています。しかし、忙しいプロジェクトオーナーの場合は、メール・資料での報告でも良いかもしれないです。また、メンバに日報（メールor日報ドキュメント）を記載させる場合もあるかもしれないです。その場合、手段も明確にすることをお勧めします。
注意点
社内向け、社外向けを分けて定義したとしても、プロジェクト体制図と見比べながらステークホルダーマネジメントで登場するメンバは全員、いずれかの会議体には属するようにすることが大切です。
それにより、プロジェクトメンバ全員が当事者意識を持つことに繋がりますし、各プロジェクト関係者に対してそれぞれに必要な情報が適切に伝わる仕組みになっていることを一緒に確認することができます。
まとめ
今回は、コミュニケーション計画について考えてきました。
小規模案件であったり、上位層が参加しなくても済むような案件であれば計画するまでのものでもないかもしれないです。しかし、逆にいえば規模が大きくなるにつれて、コミュニケーションラインというものはしっかりと定義し、正しく情報が流れなければ、混乱を招きます。
ぜひ、ステークホルダーマネジメントと一緒にご覧いただければ幸いです。
参考文献
・情報処理教科書 プロジェクトマネージャ （三好康之著）
私は2019年度版を参考にしています。
・プロジェクトマネジメント実践講座 伊藤大輔（著）
コメント