を言葉にしてみようと思った。僕のいる場所での話。ステークホルダーに対する窓口としてプロデューサーがいて、僕が開発チームのリーダーをしてるようなとき。
## 状況を把握する
システムトラブルが発生すると場が混乱してることが多い。色んな情報が混ざるし、色んな人から問い合わせが来たりするし、窓口になってくれているプロデューサーからの説明も省略されていることが多い。このときに一番避けたいのは、ミスコミュニケーションによって本当の問題を見失って無駄な作業をしてしまうこと。
なので、まずは落ち着いて状況を正確に把握する。ちょっとでもはやく解決したいから、その断片的な情報を元に調査に入りたい気持ちになるけど、ぐっとこらえて全体像を把握する。
コミュニケーションで特に気をつけるのは、相手や自分の中にある思い込み。思い込みがあると喋るときには（当然分かってることだよね）と言葉を省略してしまうし、聞くときには曖昧な言葉を自分の思い込みで埋めて（つまりこういうことなんだろうな）と判断してしまって、認識のずれがおきやすい。
なので、喋るときにはできるだけ相手が推測しなくて済むように曖昧な表現を避けて、聞くときには相手の「事実」と「推測」を区別して認識する。「『ボタンをおしたらそうなるんです』というのは、ボタンを押したら実際にそうなったってことですか？それとも、ボタンを押したらそうなるんじゃないかと思っているということですか？」
## 緊急度を判断する
状況を把握したら、プロデューサーと一緒に緊急度を判断する。
プロデューサーはビジネス視点で、僕はエンジニア視点でお互いの意見を共有して判断する。今すぐ修正しないといけないものなのか、明日でもいいのか、来週でも大丈夫なのか。一般ユーザーに影響が出ているのか、社内ユーザーだけに影響がでているのか。
どんな問題だってできるだけ早く解決してほしいとステークホルダーは考えるし、エンジニアとしてもすぐ対応しなきゃと思ってしまうのだけど、問題のレベルに合わせて緊急度を判断することが大切。できるだけ落ち着いて通常の開発フローを通して修正できる方が、プロダクトの品質的にも、チームの健康のためにも良い。
「問題のレベル」については、その場で話をしても揉めるだけなので、事前にステークホルダーと話し合って定義しておく。
## 状況をチームに伝える
状況を把握して、緊急度が高いと判断したら、まずチームの全員がいるチャンネルに状況を共有する。
緊急度が高いからって共有する時間を惜しんで自分が調査に入っちゃうと、場が余計に混乱することが多い。自分が調査に集中してしまうと状況が他の人から見えなくなるし、１人で調査してる途中でメンバーの誰かに聞きたいことがあって突然質問しても相手も「え？何がおこってるの？」ってなるだけだから。
なので、チームの全員に状況を伝える。そうすると何人かのメンバーから「この辺が問題かも」「テストケースチェックしてみる」などの意見がもらえるし、全員がその問題に対して動き出してくれる。このとき、僕は自分では手を動かさないことが多いかな。エンジニアたちの情報をまとめて決断や報告をする役割をする必要があるから。
次に、Zoomを立ち上げて、何人かでそこに集まる（最近はリモートチームで仕事をしてることが多い）。そして根本原因の調査や対応方法の相談をする。対応方法に関しては、いくつかの選択肢があることが多い。その中で良い点や悪い点などを相談しながら、どの対応方法を選ぶかを決断する。
全員の意見がすぐにまとまる場合は良いのだけど、どの方法にもリスクがある場合、決断しきれないことも多い。そういうときは「この対応方法で進めましょう」とリーダーとして決めてしまう。
あとは「誰が何をやるか（何をやらないか）」を取りまとめるかな。それぞれのメンバーが目の前のタスクに集中できるように。
## 状況をプロデューサーに伝える
エンジニアたちの状況をプロデューサーに定期的に伝える。これがあるので、自分はできるだけ手を動かさないようにしている。
エンジニアたちのチャンネルに入ってもらえば全ての情報があるから、それを元に把握してくれたらいいじゃん。って言う人がたまにいるんだけど、それはプロデューサーには難しい。粒度が細かいし、内容が色んな場所に飛んでいったり戻ってきたりするから結局どうなったのかが外から見ただけだと把握できない。それに、プロデューサーは窓口になってステークホルダーとのやり取りをしているため、そこまで細かく追いかけられない。
なので、僕がエンジニアたちの状況をプロデューサーに伝える役割をする。このときに気をつけるのは、エンジニア視点で把握している情報を伝えるのではなく、プロデューサー視点で必要な情報を伝えるということ。「このモジュールのこの部分のコードに問題がありそうなので修正してプルリクエストを作っているところです」よりも「疑わしい部分を見つけたので20分以内にステージング環境で確認できるようになります。デプロイ後に一緒に確認をお願いしたいです」くらい。
それからプロデューサーからの質問で「いつ修正できそうですか？」に対して、まだ分かっていないときには「まだ分かりません」だけじゃなくて「まだ原因が分かっていないので調査中です。15分後に状況を再度共有します」みたいに、次にいつ情報を共有するか、まで伝えておくとプロデューサーも「まだ原因は分かっていませんか？それとももう修正を始めていますか？」みたいな質問をチームの様子を伺いながらする必要がないし、ステークホルダーにも説明しやすい。
## いま思いつくのは
だいたいそんなところ。
あとは、そのトラブルを引き起こしたバグを埋め込んでしまった人が申し訳ない気持ちになっていたりするので「気にしないでください。誰がこのコードを書いたかというのは全く問題ではないんです。チームとしてレビューをしてテストをして、それでも見つけられなかったということが問題なのです。チームの課題として認識して改善していきましょう」と言ったりするかな。
