uncategorized

なんとなくコミュニケーションは危険!PMに求められる”コミュニケーション計画”の手法

kreative junge leute in einer besprechung im büro

なんとなくコミュニケーションしてませんか?

プロジェクトが開始されると「定例会」の設置、「メーリングリスト」の作成などが行われます。名刺交換でプロジェクトメンバーのメールアドレスを把握したり、電話番号を知ったりすることでプロジェクト内のコミュニケーションチャネルが開かれていきます。こういうコミュニケーションをなんとなく始めていないでしょうか?振り返ってみてください。

ーなんのために「定例会」を行うことにしたのですか?
ーなんのためにメーリングリストを作成したのですか?

今ではSkypeやChatWorkなど多種多様なコミュニケーション・サービスが提供されているので、以前よりもコミュニケーションは雑多になってしまっています。

プロジェクトは人で出来ているのでコミュニケーションが大事

プロジェクトは”人”で構成されています。人は「言語」によって互いを理解し協働する生き物です。これを社会性などと言いますが、結局はコミュニケーションが大事なのです。そのコミュニケーションを”なんとなく”で始めていないでしょうか?

コミュニケーション・チャネルを計算してみる

世間には様々な場面で人との会話などで集団をまとめていく才能を持った人が居ます。”コミュ”力などと言っていますが、現実にはこういう才能だけではどうにもならないのがプロジェクトです。

プロジェクトにおけるコミュニケーション・チャネル(人と人のインターフェース、つまり会話にせよメールにせよメンバー間の組み合わせということですが)は人数nに対して、n*(n-1)/2で計算出来ます。

今、ここに7人のプロジェクトがあるとして、7*(7-1)/2=21となり21本のコミュニケーション・チャネルが開いていることになります。これが、複数の会社にまたがって受発注がある場合ですと、発注者側5人+受注者側7人という体制がすぐに出来上がります。(5+7)*(5+7-1)/2=66となり66本のコミュニケーションチャネルが出来上がる訳です。プロジェクトマネージャがこの全てのコミュニケーション・チャネルを管理することは物理的に無理です。

コミュニケーションを「計画」するということ

コミュニケーションを計画するにはプロジェクトメンバーの分析を行う必要があります。

先ほど受発注双方で12人のプロジェクトと言いましたが、実際には12人全員がお互いにコミュニケーションをする必要はありません。発注者側と受注者側で会社間でコミュニケーションを取る必要がある人は限られます。双方で2〜3名程度でしょう。すると、

1)発注者側の5人のコミュニケーションチャネル 5*(5-1)/2=10
2)受注者側の7人のコミュニケーションチャネル 7*(7-1)/2=21
3)受発注者混合の5人のコミュニケーションチャネル 5*(5-1)/2=10

の合計10+21+10=42となり、コミュニケーション・チャネルは2/3くらいになります。

更に、受注者側が企画2人+開発5人という構成になっていれば、企画と開発の間でのコミュニケーションは3名程度で事足りるでしょう。

1)発注者側の5人のコミュニケーションチャネル 5*(5-1)/2=10
2−1)受注者側企画の2人のコミュニケーションチャネル 2*(2-1)/2=1
2−2)受注者側開発の5人のコミュニケーションチャネル 5*(5-1)/2=10
2−3)受注者側企画・開発のコミュニケーションチャネル 3*(3-1)/2=3
3)受発注者混合の5人のコミュニケーションチャネル 5*(5-1)/2=10

で合計10+1+10+3+10=34と初めよりも半減します。

この様に、コミュニケーションの範囲はプロジェクト組織に沿って決まるので、組織を構成するというのが最初に必要になってきます。

コミュニケーションの種類と方法

プロジェクト内のコミュニケーションにはどういう種類があるでしょうか?それは大きく分けて3つに分類出来ます。

1)双方向・・・相互に意見交換を必要とする場合

要件や仕様を策定したり、スケジュールを協議するなどが考えられます

双方向のコミュニケーションは「記録」を残すことが重要です。議事録、議事メモなどを終了後に直ぐに発行して、双方で確認します。チャットなどを使っている場合、記録が残っているので大丈夫だと思われるかもしれませんが、チャットは情報が冗長になっているので、チャットの最後に決定事項の一覧を記すか、メールなどで記録として残せる様にする必要があります。

2)ブロードキャスト・・・全員に強制的に通知する必要がある場合

決定事項(要件、仕様、スケジュールなど)を全員に強制的に知らせるなどがあります

ブロードキャストは全体周知などのプロジェクトの公式の情報共有もありますが、定期的な進捗報告もブロードキャストです。開発チーム等では毎日進捗共有のスタンディングミーティングをする場合等もあります。

3)ピックアップ・・・必要な人が情報を取りにくる場合

コーディネート規約など、プロジェクトメンバーが必要に応じて参照しなければいけない情報が考えられます

ピックアップ情報はプロジェクト共有のwikiなどに整理して検索しやすくする工夫が必要です。議事録などもwikiで記録すると後からの検索で便利に使えます。

前に書いた様にプロジェクトは人で出来ていますので、計画されたコミュニケーションがないと混乱します。その意味ではコミュニケーション計画がプロジェクトの成否を分けるとも言えます。

SEKAI LAB TIMES(セカイラボタイムス)は、アプリ・Webサービス開発を世界中のエンジニアチームに依頼・発注できるグローバルソーシングプラットフォーム「セカイラボ」が運営しているブログメディアです。


KENTARO FURUKAWA / Project Manager
業務システムからスマホアプリ開発まで多様なシステム開発現場でプロジェクトマネージャをつとめる。ICタグシステム開発のベンチャーや物流会社の経営企画などで、事業開発や事業改善を主導。現在はフリーのプロ・プロジェクトマネージャとして活躍。