プロジェクトとコミュニケーション計画
プロジェクトの計画段階で最も重要なスキル、それは
コミュニケーション
です。
少なくとも「最も重要なスキル」の１つであることは間違いありません。
これは計画の中身についてもそうですし、計画内容を共有する際にも適用できることです。どんなに優れた計画を立てても、その計画内容を共有できなければ誰も計画通りに行動してくれません。
その意味でも、コミュニケーションは計画の初期段階からとても重要なファクターと言ってもいいでしょう。
しかし、多くのプロジェクトにおいて「コミュニケーション」を重要視しているプロジェクトマネージャーというのは存在しません。いえ、口先だけで「重要だ」と言っている人はたくさんいます。「具体的にはどのようなコミュニケーション？」ときくと
三流であれば「会話」を多くすることを重要視するでしょう。
二流であれば「会議体」の定義について触れるのではないでしょうか。
なぜこれらが三流、二流と呼ばれるか。
「会話」を増やせばそのぶん生産活動の「時間」が減ります。
「会話」には発信者のボキャブラリや表現力、受信者の読解力や理解力によって齟齬が生じる可能性を絶対に回避できません。
たとえば「事実(fact)」と「意見(opinion)」の違いを理解できていない人というのはたくさんいますが、濫用されると聞く側は情報の取捨選択に迷うことになってしまい、発信者の意見（間違っているかもしれない情報）を信じてしまうと誤った判断や選択をしてしまいかねません。
また、「会議体」＝コミュニケーションと勘違いする人の多くはPMBOKなどをベースにしたどこかの例示に惑わされており、自らの考えで決めているわけではないかもしれません。
確かに会議体は重要ですが、それは会議体という手段が重要なわけではないのです。本当に重要なのは、
「ステークホルダーと情報を共有し、互いの認識を合わせて進めること」
であって、たまたまその機会として会議体が多くのシーンで用いられているにすぎません。実際、「会議体」のみが定義されていればコミュニケーションはほかに必要ないと言い切れるでしょうか。ここがコミュニケーションに対する理解の程度が二流以下といわれる所以です。
また、コミュニケーションとは話すスキルのことを指しているわけではありません。
コミュニケーションと聞くと"話す"ことが真っ先に思い浮かべてしまうのは日本人の悪い癖です（ＩＣＴ(Information and Communication Technology)にある"Ｃ"には話すという定義は一切ありません）。
コミュニケーションにおいて、最も重要なのは
・情報を適切に伝達する（伝えるではなく、伝わる）こと
・情報を共有する（し続ける）こと
の２点に限ります（"話す"ことは伝わるためのただの一手段です）。コミュニケーションが１人ではなく必ず複数人で成立させるものという制約がある以上、当然と言えば当然です。いやまぁ、中〇病なひとが多重人格で遊んでるのは「会話だ！」と言われてしまうと、「ｳﾝ､ﾏｧｲｲﾝｼﾞｬﾅｲ」と言ってしまうかもしれませんが。
たとえば、"計画内容や方針、手順をメンバやステークホルダに周知しない"と言うのは運動会のムカデ競争で「１，２！１，２！」と号令をかけないのと同じです。どうやってメンバーやステークホルダーたちは足並みを揃えることができるのでしょう？
たとえば、「WBSを作らない」「WBSの粒度が粗く、メンバが見ても作業が明確化できない」というのは、たとえば料理のレシピ本などに
1. 適切に下ごしらえをする
2. いい感じに煮込む
3. 適当に盛り付ける
と書かれた内容だけで「カレーを美味しく作れ」と言われているようなものです。
どうやってみんながみんな、安定して美味しく作ることができるでしょう？
情報の解像度やその使い方が適切でない限り、それが会話であっても、会議体であっても、文書であってもコミュニケーションとしては成立しないのです。
このように、計画段階は色々と定義／決定することも重要ですが、その定義したルールや基準をかかわる人たちにも理解できる形で伝達し、そして同じ情報・理解を共有することが必要になります。
これを怠るということは上記の例にあるように、
「わかった人間だけが何となく進めることができる」
「わかってない人間は一切進められない」
という傲慢で安定性の欠いたプロジェクトとなってしまいます。
こうした重要性や難しさは、プロジェクト規模に比例します。
「難しさ」については人の力量次第というところもあるので優秀な人たちのみでチームを構成すれば問題ないかもしれませんが、「重要性」が比例する以上は、規模が大きくなればなるほど確実に遂行できなければ即失敗につながるので気を付けましょう。
少なくとも
どんなコミュニケーションチャネル（媒体）を使用しているか。
各チャネルの用途は何か。
そのチャネルを選択した理由はなにか。メリデメは確認したか。対面でコミュニケーションとるべき場合と、メールなど非同期的なコミュニケーションが適切な場合は？
プロジェクトでの役割には何があるか？
役割に複数人いる場合は責任者はだれか？
プロジェクトマネージャー誰か？
プロジェクトチームのメンバーは誰か？
プロジェクトのステークホルダーは誰か？ステータス更新などの重要なプロジェクトの詳細を伝達する方法と頻度は？
等々といった、会議体以外にも考えなくてはならないことは多々あります。さらに言えばコミュニケーションチャネルのなかで書面などを作成する場合、その書面…ドキュメントの作成における書式やルール、用語・用字などについての制約などを設けておかないと本来のコミュニケーションが成立しないことも多々あります。
「設計書」や「議事録」などのフォーマットを用意しても、チームメンバーごとに記載粒度やその精度が大きく異なるプロジェクトは、プロジェクトマネージャーがコミュニケーションの本質やコミュニケーションプランを正しく理解していない証拠です。
ちなみに。
多くのシーンにおいて「大は小を兼ねる」傾向が強いと思いますので、大規模プロジェクトの手法を小規模プロジェクトで取り入れてもまず失敗することはしません（まぁあとは負担や時間との調整は必要でしょうけど）。
しかし、小規模プロジェクトの方法論を大規模プロジェクトでも同じように実施しようとする場合や、ある固有プロジェクトの方法をまったく毛色の異なるプロジェクトで実施しようとした場合には失敗確率は著しく上昇しますのでご注意ください。
たまに過去の実績を引っ提げて自信満々に他プロジェクトでも同じ方法を採用しようとする人がいますが、そういう人の多くは『プロジェクト』そのものの本質を理解していません。
当然ながらこうした「本質」を理解されていないということは、プロジェクトの不確実性についてもまったく視野に入っていないことでしょう。
でなければ、「過去と同じことを踏襲すれば、同じように成功するはず」という発想には至りません。過去の実績を自信にかえて参考にするのはいいでしょう。
しかし採用するかどうかは、「採用してもいい条件」を洗い出し、確認し、そのうえで
「条件が満たされている」
という保証ができてから行うものです。仮にそうする時間がないから、過去実績のある型にあてはめながら都度リスク予測／対策を講じていくというのであれば、綿密な効果測定ポイント…チェックポイントを定義していく必要があります。そしてそれは「なんとなく」で決めていいものではなく、手戻りが最小となるような仕組みに落とし込まなくてはなりません。
その実現にはやはりメンバーの協力は必要ですし、かといってメンバーに過剰な負荷を与えてもいけません。
ここでも重要なことは「コミュニケーション」によるチーム内の価値観の共有です。それぞれがそれぞれの思い通りに好き勝手ふるまっていてはプロジェクトは決して成功しません。
そのうえでもプロジェクトマネージャーが「重要」と定めるファクターの片隅には常にコミュニケーションの存在が不可欠といえるのではないでしょうか。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。