以前、遅れ気味のプロジェクトをリードしていたことがあります。アーキテクチャに問題があることも、締め切りに間に合わないことも分かっていました。それなのに、誰かに聞かれるまで黙っていたんです。

3週間後、ようやく聞かれました。その頃にはもう手の付けられない状態でした。

このとき学んだことはシンプルです。こちらから状況を伝えない限り、周りは「順調なんだろう」と思い込む。そして問題が表面化した瞬間、「なぜもっと早く言わなかったのか」と言われる。

「聞かれたら答える」の落とし穴

#

多くの人のコミュニケーションは受け身です。メールが来たら返信する。進捗を聞かれたら答える。バグ報告が来たら直す。

一見、効率的に思えます。余計な情報で誰の時間も奪っていないわけですから。

でも実際には、「情報が欲しければ自分を追いかけてくれ」と周囲に教え込んでいるようなものです。マネージャーはプロジェクトの状況をわざわざ聞きに来なければならない。他のチームは自分たちへの影響を自分で確かめなければならない。経営層はリスクの有無を掘り起こさなければならない。

優秀なエンジニアほど、ここでつまずくのを見てきました。素晴らしいシステムを作っても、何かが壊れるまで誰にも知られない。難しい問題を解決しても、誰かが騒いだ後になってから。

あるシニア開発者が、重要な決済システムのリファクタリングに2週間かけたことがあります。美しいコードで、処理時間は半分になりました。ところが半年後、別の調査の途中で偶然見つかるまで、誰もその存在を知りませんでした。あれだけの仕事が、完全に見えないままだったんです。

一方、同じチームの別のエンジニアは、何かをリリースするたびに短い報告を送っていました。「APIのレイテンシを200ms削減しました。方法はこちら」。5文程度、たまにグラフが1枚。何をしているか、全員が知っていました。昇進したのはどちらだと思いますか？

差がついたのはスキルではなく、伝えるタイミングでした。

黙っているとどうなるか

#

「聞かれるまで待つ」が現場でどうなるか、具体的に書きます。

2日と見積もったタスクの3日目。あと3日はかかりそうだと分かっている。今すぐ言いますか？　それとも明日のスタンドアップで聞かれるまで待ちますか？

待った場合はこうなります。マネージャーは今日終わる前提で計画を組んでいる。QAチームは明日テストを予定している。プロダクトマネージャーは顧客に「金曜リリース」と伝えている。「思ったより時間がかかっています」の一言に使う30秒を惜しんだせいで、全員が慌てて調整するはめになります。

あるいは、認証の仕組みを変更しているとします。モバイルアプリがトークンの形式に依存していることも知っている。今すぐモバイルチームに連絡しますか？　それとも気づくかどうか様子を見ますか？

黙っていれば、来週アプリがデプロイされ、本番で壊れます。相手は何時間もデバッグした末に、ようやくこちらの変更にたどり着く。こうして「予告なしに本番を壊した人」の出来上がりです。

こういうことは日常的に起きています。原因はいつも同じ。誰かが知っていたのに、言わなかった。

では、どうするか

#

聞かれる前に伝える。全部ではなく、相手に必要なことだけです。

私が「先に言う」と決めている場面は、だいたいこのあたりです。

スケジュールが遅れそうなとき。 5日の見積もりで3日経過、進捗はせいぜい30%。今すぐ連絡します。「思ったより時間がかかっています。5日ではなく8〜10日になりそうです。スコープを削りますか、それとも期限を延ばしますか？」

スタンドアップを待たない。聞かれるのを待たない。分かった瞬間に伝えます。

技術的な判断をしたとき。 MySQLではなくPostgresを選んだ。GraphQLではなくRESTにした。APIに必須フィールドを追加した。

決めた本人にはローカルな判断に見えても、誰かがそこに依存しています。短いメモで十分です。「ユーザーエンドポイントでメール検証を必須にします。木曜に反映予定です。影響がありそうなら教えてください」

リスクに気づいたとき。 データベースの伸びが想定より速い。負荷がかかるとAPIが遅くなってきた。新機能は動くけれど、コードが荒れていて保守が大変そう。

問題になるまで待たず、直せる余裕があるうちに旗を上げます。「検索エンドポイントのレスポンスタイムがじわじわ悪化しています。まだ急ぎではありませんが、次のスプリントでキャッシュ追加を検討したほうがよさそうです」

定期的な報告。 私は毎週金曜、関係者にメールを送っています。所要時間は10分。今週リリースしたもの、来週やること、気になっていること、の3点だけ。

ほとんどの週は退屈な内容です。それでいいんです。退屈ということは、サプライズがないということ。いざ何か起きたときも、ずっと共有し続けてきたおかげで、相手はすでに文脈を知っています。

報告先がいくつもあるプロジェクトでは、誰にどの報告を、どのくらいの頻度で、誰から届けるかを、1ページのプロジェクトのコミュニケーション計画に書き出しています。

なぜみんなやらないのか

#

言い訳なら全部知っています。私自身、ほとんど使ってきましたから。

「邪魔をしたくない」。邪魔ではありません。むしろ、相手がこちらに聞きに来る手間を省いています。マネージャーにとっては、状況確認のミーティングを設定するより、2文の報告を読むほうがずっと楽です。

「間違っていたらどうしよう」。訂正を送ればいいだけです。「8日かかると言った件、6日で終わりました。予定どおりに戻っています」。良い知らせに怒る人はいません。

「無能だと思われたくない」。実際は逆です。予告なしに締め切りを落とすほうが、よほど無能に見えます。遅延を早めに知らせる人は、リスクを管理できる人に見えます。

「忙しくて」。3文のメールを書けないほど忙しい人はいません。もし本当にそう思うなら、報告を怠った結果の後始末をする余裕は、なおさらないはずです。

先に言わない本当の理由は、気まずいからです。黙って、うまくいくことを祈るほうが楽。でも祈りは計画ではないし、沈黙はプロの仕事ではありません。

「即応」でいい場面

#

何もかも事前に伝えられるわけではありません。予告より即応が求められる場面もあります。

障害対応中は、まず直す。対応状況の共有はしますが、完璧なポストモーテムを書き上げるまで止血を待つ必要はありません。

コードレビュー待ちで誰かが詰まっているなら、さっさとレビューする。相手に必要なのは週報ではなく、1時間以内のアンブロックです。

Slackで急ぎの質問が来たら、答える。金曜のまとめまで待たせない。

要するに、目の前の急ぎの用件にはリアクティブに応え、それ以外はプロアクティブに先に伝える、ということです。

続けてみて変わったこと

#

これを習慣にしてから、実際に変わったことを挙げます。

まず会議が減りました。状況がすでに伝わっていれば、確認のための会議は開かれません。私のカレンダーは週25時間超の会議から15時間程度になりました。

サプライズも減りました。問題を早めに知らせておくと、それは「問題」ではなく「管理されている事柄」として扱われます。2週間前に共有済みのリスクで慌てる人はいません。

そして何より、信頼されるようになりました。聞かれなくても状況を伝え続けていると、「この人に任せておけば大丈夫」と思ってもらえるようになります。結果として、より大きな責任と、より面白い仕事が回ってきます。

先ほどの昇進の話も、仕事の出来はもちろんですが、それ以上に「良い仕事を、掘り起こされなくても然るべき人に届けていた」ことが大きかったと思っています。

まず何から始めるか

#

今週取り組んでいる仕事をひとつ選んで、聞かれる前に短い報告を送ってみてください。

マネージャー宛なら。「APIリファクタリング、順調です。半分ほど終わっていて、週末までに完了見込みです」

他チーム宛なら。「ユーザーセッションの扱いを変更しました。影響はないはずですが、認証まわりで変な挙動があれば教えてください」

自チーム宛なら。「本番のあのバグ、修正しました。原因はキャッシュ層の競合状態です。再発しないようテストを追加済みです」

2〜3文書いて、送信するだけです。

結果はだいたい次のどちらかです。

1. 感謝される。そして自分も、情報を抱え込む不安から解放される
2. 返信は来ない。それでも相手はもう知っているので、心配しなくていい

何度かやれば習慣になります。何かを終えたら関係者に伝える。問題を見つけたら旗を上げる。決めたことは共有する。

数週間もすると、誰も状況を聞いてこなくなります。もう知っているからです。そうなってから、いろいろなことが楽になります。