大規模プロジェクトにおけるプロジェクトマネジメント　「コミュニケーション計画」がプロジェクトの成否を決める！

クライアントや制作チーム、第三者といった多数のステークホルダーと「効率的」かつ「確実」にコミュニケーションをとっていくための「コミュニケーション計画」をいかに立てるかということが、ステークホルダーが多くなればなるほど重要になってきます。

コミュニケーション計画の設計が甘かったがためにコミュニケーションロスが発生し、プロジェクト全体の進行に影響を及ぼすということが少なくありません。あらかじめ設計しておくことで防げる問題は防いでおくにこしたことはないでしょう。

なお、今回のポイントはコミュニケーションの「取り方」ではありません。コミュニケーションの取り方は人それぞれです。話術に長けた人、淡々と物事を取り決めていく人、それこそプロジェクトマネージャー自身の個性が発揮される部分でしょう。

しかしどんなにコミュニケーションの取り方に長けた人であっても、その長所が効果的に発揮できないと意味がありません。今回は、その個性を最大限発揮するために、使用するツールや枠組みをどのように設計していくか、というところに絞ってお話をしていきたいと思います。

そう、コミュニケーションにも「設計」が必要なのです。

ミーティング

□ 直接顔をあわせて話ができるので、細かいニュアンスを把握しやすい
□ ブレスト、議論、交渉に向いている
□ 心理的に「きちんとコミュニケーションがとれている」という実感・安心感を得やすい
■ 移動も含め、必要以上に長時間になることが多い

電話／Skypeなど

□ 相手の声を聞くことができるので、感触を把握しやすい
□ 簡単な連絡、相談、交渉に向いている
□ 心理的に「きちんとコミュニケーションがとれている」という実感・安心感を得やすい
■ 電話だけでは、後々問題が起こった際に「言った／言わない」の議論になりやすい

メール／メーリングリスト

□ 一度に多数の人と情報を共有することができる
□ 重要な連絡、相談、交渉に向いている
□ 履歴が文章で残るため、後々の誤解を生みにくい
■ ニュアンスや雰囲気を伝えづらい
■ 話題が多い場合、管理が煩雑になる／放置される可能性がある

パワーポイントやエクセルなどのドキュメント

□ 図や表など視覚的に情報を伝えることができる
□ 提案などに向いている
■ バージョン管理が煩雑になる

オンライン共有ツール（Wiki や オンラインストレージなど）

□ 一度に多数の人と情報を共有することができる
□ デザインやドキュメントなどの確認、ステータス把握などに向いている
□ 情報の一元管理ができる
■ ステークホルダーのリテラシーを考慮する必要がある
■ ステークホルダーのセキュリティポリシーなどによっては利用が制限される場合がある

従って、この期間中は「ミーティング」をメインにコミュニケーションを設計するのが効果的です。週ごとの「定例会」を設定するなどの対応が必要な時期になります。

このフェーズで有効なコミュニケーションツール
　- 定例会（隔週　○曜日　○時から1時間程度）
　- メーリングリスト（情報共有用）
　- オンラインスペース（ドキュメント共有用）

「承認者は誰なのか」「クライアント社内での承認プロセスはどのようになっているのか」を確認しながらあらかじめ「プロジェクト内での承認プロセス」を明確化しておきましょう。

例えば上記のプロジェクトの場合、直接やり取りをするステークホルダーはみな担当者レベルなので、承認の際にはさらにその上長がいるはずです。その存在を認識しておくことで、「最終的に承認をとるべき相手」が明確になりますので、より承認をとりやすい提案を行うことができますし、あらかじめその期間をスケジュールに反映させておくこともできます。

また、話題がより詳細に移っていくことになりますので、ステークホルダー全員が集まってのミーティングの開催頻度は下げ、分科会のようなミーティングの開催頻度を上げることが必要になってきます。

ただしその分科会での決定事項は、そこに出席していないメンバーとも必ず共有できる手段を設けておくことが必要です。共有の手段はさまざまですが、このケースの場合はクライアントのプロジェクトへの参加意識が高いという点から、メーリングリストを使用するのがよいかもしれません。

もしメーリングリストでは見逃されて埋もれる可能性が高いのであれば、ドキュメント共有用のオンラインスペースなどを別途用意して、毎回そこを見てもらうようにするという方法でもよいかもしれません。

このフェーズで有効なコミュニケーションツール
　- 定例会（隔週　○曜日　○時から1時間程度）
　- デザイン分科会（毎週　○曜日　○時から1.5時間程度）
　- システム分科会（毎週　○曜日　○時から1時間程度）
　- メーリングリスト（情報共有用）
　- オンラインスペース（ドキュメント共有用）

変更が入ること自体は悪いことではありません。その変更がそのプロジェクトをよりよい成功に導くのであれば、むしろ積極的に変更をしていくべきでしょう。

ただ、とはいえなんでもすべて変更していけばよいというものでもありません。変更要望が発生した際には以下のフローが必ず必要です。

○ 変更要望の受理
↓
○ 変更を適用した際のインパクト分析（工数／技術的な制約など）
↓
○ 変更要望を容れるべきか否かの判定
↓
○【OKの場合】変更の適用／実行
●【NGの場合】変更要望の差し戻し

また上記には、どのようなツールを使用してどのようなフローで行うかをあらかじめ設定しておきステークホルダー間で認識をそろえてく必要があります。

ロフトワークでは通常、その変更要望が一覧でき、しかもその要望への対応のステータス管理ができるようなオンラインスペースを使用するようにしています。エクセルなどで管理していくことも可能ですが、バージョン管理やステータス管理が煩雑になるため、一元管理できる方法を使用した方が情報の共有はしやすいと思います。

このフェーズで有効なコミュニケーションツール
　- 定例会（隔週　○曜日　○時から1時間程度）
　- メーリングリスト（情報共有用）
　- オンラインスペース（変更管理用／ドキュメント共有用）

※オンラインスペースについては、諏訪のコラム「情報同期の重要性」で詳しく解説しています。

コミュニケーション計画については、途中で変更が入ってももちろんかまいませんし、むしろそのときそのときの状況にあわせて柔軟に設計を変えていくべき点でもあります。

ただしその場合にはかならずコミュニケーション計画を規定したドキュメントをアップデートしそれをステークホルダー間で共有することが必要です。

今回ご説明したコミュニケーション計画はあくまで例にすぎません。実際はもっと複雑な要因が絡んでくる場合もあるでしょうし、一度決めたとおりにそのまま進むこともめったにありません。ただ、コミュニケーションにも計画／設計が必要なのだということを意識してプロジェクトを進め、それをドキュメント化して共有することでその後のコミュニケーションロスを減らせる、ということはぜひ覚えておいていただければと思います。

HTML5がやってきた！ Vol.3

2010/09/02　クリエイティブディレクター 　橋本　洋平

【 Webサイト 】 【 Webアプリケーション 】