これまで巻き込まれてきたプロジェクトの混乱は、ひどいコードが原因だったことはほとんどありません。必要な情報が、手遅れになるまで必要な人に届かなかった——原因はたいていこれです。仕事でプロジェクトリードを任されるようになってから、「もし自分がCTOの席に座ることになったら、コミュニケーションをどう回すか」というメモを書き溜めています。今回はそれを公開してみます。
誰に何を知らせるかを決める#
地味ですが土台になるのはコミュニケーション計画です。誰に知らせる必要があるのか、どんな情報を、どのくらいの頻度で、どのチャネルで届けるのか。プロジェクトの開始時に必ず作り、担当者の名前まで入れておくべきだと思っています。「全員の仕事」になったコミュニケーションは、結局誰の仕事でもなくなりますから。ステークホルダーも同じです。誰が本当にこのプロジェクトを気にかけているのかを整理し、それぞれが好む報告のされ方を把握しておく。CEOに、開発チャンネルと同じ内容の報告を送ってはいけません。それから、明文化したルールをいくつか。返信の目安時間、何を「緊急」と呼ぶか、どのチャネルを何に使うか。「コミュニケーションの問題」の正体は、口に出していない期待のすれ違いであることがほとんどです。
ツールとリズム#
ツールは、世間で議論されているほど重要ではありません。チャットはSlack、タスク管理はTrello、顔を見て話したいときはZoom。チームに合うものを選んだら、さっさと先へ進めばいい。それより大事なのはリズムです。アジャイルなら毎日のスタンドアップ、サイクルが長いなら週次の報告。そして決めたリズムをちゃんと守ること。あとは、書き残すことです。決定事項、変更、アクションアイテムをNotionやJiraへ、後付けの作業ではなくプロセスの一部として記録する。半年後、みんなの記憶に残っているのはドキュメントだけです。
柔らかい部分こそ難しい#
ここまでは仕組みの話です。難しいのはその先で、今のコミュニケーションが本当に機能しているかをチームに聞き、機能していなければ変えること。メンバーの育成もそうです。チームにはいろいろなバックグラウンドの人がいて、うまく回っているプロジェクトを見たことがない人もいます。話す順番を待つのではなく、きちんと聴くこと。衝突は小さいうちに早めに扱うこと。しかも、この手の問題は一度解決したら終わり、にはなりません。前の四半期にうまくいっていたやり方が、いつの間にか効かなくなる。定期的に見直すしかありません。
分散・非同期の開発チームで働くということ#
リモートや非同期中心のチームなら、このトークは観る価値があります。
自分がこの全部を完璧にできているかというと、そんなことはありません。誰にもできないでしょう。ただ、これまでスムーズに進んだプロジェクトはこの大半が揃っていて、痛い目を見たプロジェクトは少なくとも3つは欠けていました。