プロジェクトのコミュニケーション計画書：ソフトウェア開発チーム向けのテンプレートとサンプル

プロジェクトのコミュニケーション計画とは、プロジェクトについて誰が何を知っておく必要があるのか、それをどのくらいの頻度で、どのチャネルで、誰が責任を持って伝えるのかをまとめた短い表のことです。私のものは1ページに収まっていて、開発チームからCEOまで、伝える相手ごとに1行ずつ並べています。以下は、ソフトウェア開発のプロジェクトを始めるなら私が最初に用意する計画と、プロジェクトのコミュニケーションを本当に機能させるために書き溜めてきたメモです。

これまで巻き込まれてきたプロジェクトの混乱は、ひどいコードが原因だったことはほとんどありません。必要な情報が、手遅れになるまで必要な人に届かなかった——原因はたいていこれです。仕事でプロジェクトリードを任されるようになってから、「もし自分がCTOの席に座ることになったら、コミュニケーションをどう回すか」というメモを書き溜めています。今回はそれを公開してみます。

誰に何を知らせるかを決める

#

地味ですが土台になるのはコミュニケーション計画です。誰に知らせる必要があるのか、どんな情報を、どのくらいの頻度で、どのチャネルで届けるのか。プロジェクトの開始時に必ず作り、担当者の名前まで入れておくべきだと思っています。「全員の仕事」になったコミュニケーションは、結局誰の仕事でもなくなりますから。ステークホルダーも同じです。誰が本当にこのプロジェクトを気にかけているのかを整理し、それぞれが好む報告のされ方を把握しておく。CEOに、開発チャンネルと同じ内容の報告を送ってはいけません。それから、明文化したルールをいくつか。返信の目安時間、何を「緊急」と呼ぶか、どのチャネルを何に使うか。「コミュニケーションの問題」の正体は、口に出していない期待のすれ違いであることがほとんどです。

ソフトウェア開発プロジェクトのコミュニケーション計画サンプル

#

私ならまずこれを用意して、プロジェクトに合わせて手を入れていきます。行は会議ごとではなく、伝える相手ごとに分けています。

表の下には、先ほどの明文化したルールを、できるだけ平易に書き添えます。「緊急」とはリリースか顧客を止めてしまうもののことで、そのときはメッセージではなく電話する。質問はチャットに、決定事項はトラッカーに。返信は1営業日以内。意思決定ログには意思決定文書を使っていて、作業のすぐ隣に置けるようにGitHub Issuesで管理しています。

この手の計画がうまく回るかどうかは、2つの点で決まります。どの行にも最後の列に必ず誰かの名前が入っていること。そして経営層への報告を口頭ではなく文章にすること。文章なら、そのまま転送しても何も抜け落ちません。

ツールとリズム

#

ツールは、世間で議論されているほど重要ではありません。チャットはSlack、タスク管理はTrello、顔を見て話したいときはZoom。チームに合うものを選んだら、さっさと先へ進めばいい。それより大事なのはリズムです。アジャイルなら毎日のスタンドアップ、サイクルが長いなら週次の報告。そして決めたリズムをちゃんと守ること。あとは、書き残すことです。決定事項、変更、アクションアイテムをNotionやJiraへ、後付けの作業ではなくプロセスの一部として記録する。半年後、みんなの記憶に残っているのはドキュメントだけです。

柔らかい部分こそ難しい

#

ここまでは仕組みの話です。難しいのはその先で、今のコミュニケーションが本当に機能しているかをチームに聞き、機能していなければ変えること。メンバーの育成もそうです。チームにはいろいろなバックグラウンドの人がいて、うまく回っているプロジェクトを見たことがない人もいます。話す順番を待つのではなく、きちんと聴くこと。衝突は小さいうちに早めに扱うこと。しかも、この手の問題は一度解決したら終わり、にはなりません。前の四半期にうまくいっていたやり方が、いつの間にか効かなくなる。定期的に見直すしかありません。

分散・非同期の開発チームで働くということ

#

リモートや非同期中心のチームなら、このトークは観る価値があります。

自分がこの全部を完璧にできているかというと、そんなことはありません。誰にもできないでしょう。ただ、これまでスムーズに進んだプロジェクトはこの大半が揃っていて、痛い目を見たプロジェクトは少なくとも3つは欠けていました。