コミュニケーションと文化

オンコールは技術的なスキルだけではありません。ストレスのかかる状況でも周囲と上手く連携することが求められます。このページでは、私たちがどのようにコミュニケーションを取り、どのような文化を築くかについて説明します。

非難しない文化

インシデント対応で最も重要なこと: 誰も責めない。

その意味するところ

インシデントが発生したとき:

「何が起きたか？」を問う。「誰がしくじったか？」は問わない
個人の問題ではなく、システムの問題を探る
インシデントから罰を与えるのではなく、学びを得る
誰もが恐れなくポストモーテムに参加できる

その重要性

もし人々が責任を問われることを恐れるなら:

エスカレーションすべきときにしなくなる
ミスを修正せず隠蔽するようになる
インシデントの解決に時間がかかるようになる
失敗から学ばなくなる

あなたの役割

インシデントが発生したとき:

責任を追及せず、修正に集中する
誰かがミスをしたとしてもそれは問題ない — 学びの機会だ
ポストモーテムでは、システムとして何を改善できるかを議論する
「知っているべきだった」「不注意だった」といった表現は避ける

例

悪い例: 「John が壊れた認証コードをデプロイした。テストすべきだった」

良い例: 「デプロイプロセスがこの認証の問題を検出できなかった。テストを改善したり、デプロイ前の検証を追加したりするにはどうすればよいか？」

インシデント中のコミュニケーション

明確に伝える

調査中に何かを発見したときは、明確に伝えましょう:

✅ 「セッションハンドラーの認証トークン期限切れの問題を発見した。午後4時のデプロイ後から始まっている」
❌ 「状況が悪い」

頻度

チームに定期的に報告しましょう:

開始時: 「調査中です」
5〜10分ごと: 「現在の状況はこうです」
変更を行うとき: 「認証サービスバージョン2.1.3をロールバックします」
解決時: 「問題は修正されました。安定性を監視中です」

エスカレーション時のコミュニケーション

エスカレーションするとき:

✅ 「20分間調査し、認証ログ、セッションメトリクス、最近のデプロイを確認しました。データベース接続の問題と思われます。データベースチームにエスカレーションします」
❌ 「どうすればいいかわかりません」

文脈を伝えましょう。次の人が何を試みたかを理解できるよう助けましょう。

過剰なコミュニケーションは問題ない

報告の頻度は少なすぎるより多すぎる方がよい。まだ調査中なのかどうかを誰もが確認できるよう、定期的に報告するほうが喜ばれます。

ドメインをまたぐコミュニケーション

SSCS は3つのドメイン（認証、認可、パイプラインセキュリティ）をカバーするため、明確なコミュニケーションが不可欠です:

問題が複数ドメインにまたがる場合

影響を受けているドメインを明確に特定する
他ドメインの関連チームメンバーを巻き込む
重複作業を避けるために調査を調整する
他のドメインに影響を与える可能性がある調査結果を共有する

ドメインをまたぐシナリオの例

「認証サービスが障害を起こしており、認可チェックがタイムアウトしています。私は認証側を調査しています。@AuthorizationEngineer、私が作業している間、認可サービスの状態を監視してもらえますか？」

インシデント中の Slack

Slack を効果的に使う

DM ではなくインシデントチャンネルに投稿する
スレッドを使って議論を整理する
重要な情報をピン留めする
@channel や @here は緊急時のみ使用する（スパム禁止）

インシデントチャンネルのルール

多くのチームでは以下のような標準があります:

少なくとも10分ごとに更新する
明確なステータス表示（調査中 / 緩和中 / 解決済み / 監視中）
担当者付きのアクションアイテム
役立つ場合はダッシュボードやログへのリンク

やってはいけないこと

❌ DM でサイドの会話を始める（コンテキストはチャンネルで保持する）
❌ 30分以上無言になる（常に進捗を報告する）
❌ 曖昧な言い方をする（「〜のようです」を証拠なしで使用する）
❌ 他者を責める

ページを受け取る前に: 関係を築く

良いチームメイトであること

経験の浅いエンジニアの質問に答える
インシデントから学んだことを共有する
他の人が学べるようにランブックを更新する
他の人の良い仕事を称える
認証、認可、パイプラインセキュリティチーム間で関係を構築する

エスカレーションのコミュニケーション

エスカレーションするタイミング

15分以上調査しても行き詰まっている
自分のドメインの専門知識を超えている
問題が緊急すぎて自分のペースでは対応できない
判断のサポートが必要
問題が複数の SSCS ドメインに影響している

エスカレーションの方法

Slack や Incident.io で:

理由: 「これは認可ポリシーの問題であり、認可チームの専門知識が必要です」
試みたこと: 「認証ログ、セッションメトリクス、最近のデプロイを確認しました。認証は正常に動作しています」
必要なこと: 「このユーザーロールの認可ポリシー評価を確認できる人が必要です」

エスカレーションを受けたとき

誰かがエスカレーションしてきたとき:

迅速に対応する
事前に調査してくれたことに感謝する
調査を引き継ぐ
状況をその人に共有し続ける

インシデント後のコミュニケーション

ポストモーテム

重大なインシデントの後、チームはポストモーテムを実施します:

何が起きたか？ — 一連のイベント
なぜ起きたか？ — 根本原因
何を学んだか？ — 教訓
何を改善できるか？ — アクションアイテム

参加

関与した全員が参加する
ミスについて正直に話す（責めることなく）
改善のアイデアを提供する
アクションアイテムをフォローアップする

非難しないポストモーテムの言葉遣い

ポストモーテム中は:

✅ 「デプロイプロセスがこの認証の問題を検出できなかった」
✅ 「この認可条件に対するモニタリングがなかった」
✅ 「このパイプラインセキュリティシナリオのステップがランブックになかった」

ではなく:

❌ 「X さんがミスをした」
❌ 「プロセスに従わなかった」

チームの規範と期待

応答時間

ページを受けてから15分以内に応答し、その後すぐにインシデント解決のために作業場所に着くこと

継続的に関与する

調査中は姿を消さないようにしましょう。行き詰まっていても:

「まだ調査中です。根本原因はまだ見つかっていません」
「専門知識の範囲を超えているためエスカレーションします」
「次のレベルの対応を待っています」

沈黙は不安を生みます。

プロとしての振る舞い

インシデント中は:

冷静を保つ
礼儀正しくする
知らないことは素直に認める
助けを求める
ストレスを無礼な態度に向けない

私たちは同じチームです。

問題が発生したとき

インシデント中に自分がミスをした

認める: 「ミスをしました。これを修正するために以下のことをしています」
修正する: 影響の解消に集中する
学ぶ: 次回どう防ぐか考える

責められることはありません。誰でもミスはします。

他の人がミスをした

公の場で指摘しない
問題の修正に集中する
ポストモーテムでは、システムとして何を改善できるかを議論する
非公開で、学びのサポートを申し出る

責任追及が起きたとき（あってはならないが）

ポストモーテムや Slack で責任追及の言葉を聞いたとき:

穏やかにリダイレクトする: 「個人のミスではなくシステムの改善に焦点を当てましょう」
マネージャーに伝える: 「非難しない文化と合っていない言葉が使われていると思います」

文化的な観察

良い兆候

インシデントがオープンに議論される
人々が恐れなくエスカレーションする
ミスが学びの機会として扱われる
ポストモーテムが人ではなくシステムに焦点を当てている
インシデント中に人々が感謝し合う
ドメインをまたいたコラボレーションがスムーズ

警戒すべき兆候

エスカレーションを恐れている
ポストモーテムで責任が追及される
ミスが隠蔽される
人々が防衛的になる
バーンアウトが多い
認証、認可、パイプラインセキュリティチーム間でサイロ化が起きている

警戒すべき兆候に気づいたら、マネージャーやローテーションリーダーに伝えましょう。

心理的安全性の構築

心理的安全性とは、リスクを取り、ミスを認め、質問することが安全だと感じられることです。

私たちがそれを構築する方法:

インシデントとポストモーテムにおける非難しない文化
経験豊富なエンジニアが経験の浅いエンジニアをメンタリング
質問を奨励する
エスカレーションを罰するのではなく評価する
学びと改善のための時間
ドメインをまたいた知識共有