～大規模PJで先輩を窮地に追い込んだ私の失敗と、顧客から信頼される報告術～

はじめまして！SENSYN ROBOTICS(センシンロボティクス)の高橋です。
私はエンジニアとしてキャリアをスタートし、いくつかの会社や職種を経て、現在はPMチームのマネジャーとして働いています。

※以下PMはプロジェクトマネージャー、プロダクトマネージャーを区別せず使用します

今回は1点、障害対応の進め方、特に初動対応の「報告」に絞って ひたすら書きました。
私はエンジニアだった新人時代に「報告」を怠ったことでプロジェクトに大きな損害を生み、先輩を処分に追い込んだ苦い失敗経験があります。
その経験での教訓に加え、今PMとして顧客と対峙するうえで「エンジニアにこう動いてほしい」と思うポイントを合わせ、まとめました。

基本的な内容が中心ですので、主に若手エンジニア向けの内容になります。

なお、ソフトウェア品質やより技術的な話はややこしくなるので、あえて触れていません。
それはまたの機会に。

1. 【失敗談】報告を怠り、数百万円の損失を出した新人時代の話

（※関係者が特定されないよう一部アレンジしています）

「直せる」という過信

社会人なりたての頃、当時在籍していた会社で、
ビルのワンフロア全てがプロジェクトルームになるような、
巨大プロジェクトに従事していた際の話です。

その日、私はテスト環境構築を担当していましたが、
ミドルウェアの不具合で環境構築に失敗しました。

「まずい、テスト開始に間に合わない」

焦った私は誰にも報告せず、復旧作業に没頭しました。

「あと少しで直るはず」

「迷惑をかけたくない」

今思えば、典型的なNG行動をトレースしていました。

沈黙の代償

テスト開始時刻を過ぎても環境は復旧せず、
テストチームからの一報で事態が表面化しました。

待機していたテスター：数十人
無駄になった時間：数時間×数十人
損害額：数百万円規模の人件費損失

もし早く報告していれば、テスト開始時間をずらしたり、別作業を割り当てる、日程を再調整する、といったビジネス的な回避策が取れたはずでした。

先輩への処分

結果、監督責任を問われた先輩は重い社内処分を受けました。
私を庇ってくれていた先輩の経歴に、私の沈黙が傷をつけてしまいました。

技術的なミスは取り返せます。
しかし、報告遅れによるビジネス損失は取り返せません。

2. マインドセット：障害は「信頼を失う場」ではなく「信頼を獲得する場」

障害発生時、

「やっちまった」
「怒られる、評価が落ちる」

と、どうしてもネガティブな気持ちになりがちです。
困っている人がいるので、後ろめたさがあるのは当然だと思います。
ですが、ここからの立ち振る舞いはその後の展開を大きく左右します。

とにかく報告を

トラブルが起きた時、顧客やPMはそのビジネスインパクトの重さだけでなく、
状況が分からないことに対して、不安を感じます。
彼らにも報告相手がいて、その相手に対して十分説明できるための情報を求めています。

そのため、障害発生時に一番やってはいけないのが、
事実を隠したり、報告を遅らせることです。

逆に言えば、

状況が見える
見通しが立つ
理由が分かる

この3点を押さえた報告ができれば、
「この人（このチーム）なら任せられる」という信頼を獲得できます。

ピンチはチャンス

シビアな状況下でどのように立ち振る舞うことができるのか、
真の能力が試される状況での行動は、顧客やPM、上司もよく見ています。
障害対応は、技術力だけでなく「プロとしての対応力」を証明する機会です。

プロジェクトにしても、プロダクトにしても、
障害を全くの0件に抑えることは、事実上不可能です。

また障害対応にあたっているエンジニアには、
直接の非が無いケースもあると思います。

にも関わらず、急かされたり、責められると、
正直イラっとすることはありますよね。

そんなピリピリの状況下でも感情を出さず、今できることに冷静に取り組む。
そんな人にいろんな仕事を頼みたくなりませんか。

3. PMが困るのは「沈黙」

PMの立場になって障害対応にあたる時、
最も困るのは何も情報が入ってこないことです。

障害対応中は、可能な限り事象の解決を優先し、
作業に集中したくなる気持ちは非常に良くわかります。
（それで私は失敗している・・・）

一方で障害発生時、PMは会社の看板を背負って、
顧客や関係各所への連絡・調整に奔走します。

特に障害発生直後、原因が判明するまでの間は、
少しでも情報を得て、顧客の不安を取り除きたいと考えます。

その際、エンジニアからのインプットが無いと、
具体的な報告をすることができず、ただ平謝りすることになります。

定期報告を徹底しよう

調査中でも、進捗ゼロでもOKなので、状況を発信しましょう。

❌ 悪い例
（半日無言 →）「直りました」

⭕ 良い例
「まだ原因特定できていません。ログを調査中です。次は1時間後に報告します」

これだけで、PMは顧客に
「現在、鋭意調査中です」
と自信を持って説明できます。
（いや、ほんとこれだけで全然違うんです！）

無理ない方法として、チームの中であらかじめ連絡役を決めておくことで、
調査に集中するメンバーを作ることができるので、お勧めです。

また調査状況をSlackに逐次流すといった方法であれば、
手間をミニマムにしつつ、情報発信を行うこともできます。

ただし技術的なログだけだと、PMが顧客へ説明する際に翻訳ミスが起きるリスクがあります。
区切りの良いタイミングで「つまりこういう状況」という要約を添えるのが良いと思います。

4. 【実践】必ず整理すべき4つの報告項目

最後に状況を整理するためのフォーマットとして、

事象
原因
暫定対応
恒久対応

の、4つの報告項目をご紹介します。
障害について報告する際、この4つを明確に意識してコミュニケーションができると良いです。

なお初めからこの4つを埋めることは難しく、障害対応を進めながら
徐々に埋めていくものだと捉えてください。

① 事象（Phenomenon）

何が起きているかを、非エンジニアでも分かる言葉で、
客観的に記載しましょう。

❌ NullPointerExceptionが発生
⭕ 購入ボタンを押すとエラーになり、購入できない

影響範囲も忘れずに記載できると良いです。

② 原因（Cause）

なぜ事象が発生したのか、同様に整理してください。
ポイントとして、事実 or 推測を明確に分ける必要があります。

例）
事実：DB接続数が上限に達している
推測：昨日リリースした新機能の影響の可能性が疑われる

原因がはっきりしないうちは、どうやって原因究明を進めているか、
途中経過と調査計画を報告できれば問題ありません。

なお原因がアプリケーションの不具合、バグの場合は
「なぜこのタイミングで見つかったのか（なぜ過去には見つからなかったのか）」
といった説明も合わせて準備できると、顧客の納得感が高まります。

③ 暫定対応（Workaround）

業務が止まるような事態に陥っている場合、
顧客が一番知りたいポイントはここです。

例）

機能を一時OFFにする
手動対応で回避する
メンテナンス画面に切り替える

「バグの修正は3日、でも止血は30分で可能」
これが言えると、PMは判断できます。

④ 恒久対応（Permanent Fix）

発生した障害が今後二度と起きないような是正処置の内容と、
そのリリース計画を整理します。
ここでは、単に発生した箇所のバグを直すだけでは不十分です。

「他にも同様の不具合が潜んでいないか（横展開）」

「仕組みで防ぐ方法はないか（再発防止）」

まで視野を広げて検討・報告してください。

例）
【修正内容】
お問い合わせフォームの「電話番号」項目の入力チェック処理を修正。

【横展開】

会員登録画面やプロフィール編集画面など、
電話番号入力がある他3画面も調査。
同様の不備が見つかった会員登録画面についても合わせて修正を実施。

【リリース計画】
全機能のテスト完了後、来週水曜日にリリース予定。

おわりに

いかがでしたでしょうか。
繰り返し述べてきたように、
障害対応は、技術力だけで評価される場ではありません。

報告によって状況を正しく伝え、被害を最小限に食い止めること。
ここまで含めて、エンジニアの仕事と思ってほしいです。

必要なのは

定期的な報告
報告の際には先に述べた4点を意識すること

それだけです。