ダッシュボードはおそらく必要なフィードバックを提供していない
ダッシュボードを持っている。エラー率、応答時間、失敗したリクエストが表示される。グラフはリアルタイムで更新される。色は緑、黄、赤だ。可視性があるように感じる。
しかし、自分に問いかけてほしい。そのデータを実際に誰が読んでいるのか？いつ読んでいるのか？そして読んだ後、何をしているのか？
多くのチームは、見た目は印象的だが、ほとんど実用的なアクションを生み出さないダッシュボードを持っている。問題はデータではない。問題は、データが適切なタイミングで適切な形式で適切な人に届いていないことだ。ダッシュボードは表示装置である。フィードバックシステムは、チームの働き方を変えるものである。
フィードバックは行動できる人に届かなければならない
デプロイ後にエラー率が急上昇したとき、誰が最初に気づくのか？デプロイしたばかりのチームか、それたまたまオンコールだった別のチームか？
多くの組織では、デプロイしたチームがアラートを受け取るわけではない。アラートは別の運用チームや、何が変わったのか全く知らないローテーションのオンコールエンジニアに送られる。彼らは何が起こったのかを把握するために最初の20分を費やす。Slackの履歴を確認する。デプロイログを見る。周りに聞いて回る。状況を理解した頃には、デプロイしたチームはすでに帰宅している。
これは壊れたフィードバックループである。
デプロイを実行したチームが、そのデプロイに関するフィードバックの最初の受信者であるべきだ。彼らは何が変わったのかを知っている。なぜ変わったのかを知っている。ロールバックするか、前方修正するか、そのままにするかを判断できる。フィードバックを最初に他の誰かに送ることは、レイテンシと混乱を増やすだけである。
すべてのフィードバックにページャーアラートが必要なわけではない
チームはしばしば、すべてのフィードバックを同じように扱うという間違いを犯す。すべてのメトリクスにしきい値が設定される。すべてのしきい値が通知をトリガーする。すべての通知が同じチャンネルに送られる。結果はノイズ、疲労、そして最終的には人々がアラートを完全に無視することになる。
フィードバックはコンテキストに一致する必要がある。
緊急を要するフィードバックもある。デプロイ中に失敗したリクエストが1%から30%に跳ね上がった場合、それは即座の注意を必要とする。誰かがページングされるべきだ。誰かが今すぐ画面を見ているべきだ。
他のフィードバックは遅く、累積的である。2週間かけてエラー率が徐々に増加するのは緊急事態ではない。それは何かが劣化しているというシグナルである。それは日次レポートや週次レビューに属する。午前2時に誰かを起こす必要はない。
遅いフィードバックを緊急フィードバックのように扱うと、チームはほとんどのアラートが誤報であることを学習する。彼らは応答しなくなる。そして本当の緊急事態が発生したとき、誰も気づかない。
何を見るかだけでなく、どう対応するかを定義する
よくあるパターンは、チームがダッシュボードを構築してそこで止まってしまうことだ。データが見えれば誰かが何をすべきか分かるだろうと想定する。その想定はほぼ常に間違っている。
フィードバックが届いたとき、チームには明確な対応パターンが必要である。最初のステップは非難ではない。最初のステップは理解である。この問題は以前に発生したことがあるか？それを説明できる最近の変更はあるか？ロールバックできるか、それとも前方修正が必要か？
フィードバックをうまく処理するチームにはシンプルな習慣がある。確認し、行動し、記録する。フィードバックが何を伝えているかを確認する。知っていることに基づいて行動する。学んだことを記録し、次回同じパターンが現れたときに、より早く認識できるようにする。
これは明白に聞こえるが、ほとんどのチームは記録のステップをスキップする。問題を修正して次に進む。3ヶ月後、同じ問題が再発し、前回どのように解決したかを誰も覚えていない。
最も価値のあるフィードバックはシステムの外部から来ることが多い
ダッシュボードは、測定しようと決めたものを測定する。考えもしなかったものは測定しない。
時々、ユーザーが機能が遅いと報告するが、すべての技術的メトリクスは正常な数値を示している。時々、サポートチームがどのダッシュボードにも現れない苦情を受け取る。問題が特定のデバイスやネットワーク条件でのみ発生するからである。
フィードバックシステムに自動化されたデータのみが含まれている場合、これらのシグナルを見逃すことになる。ユーザーとサポートチームは、意図して設計したかどうかに関わらず、フィードバックシステムの一部である。問題は、彼らの声に耳を傾けるかどうかである。
ユーザーが問題を報告しやすくする。サポートがパターンをエスカレーションしやすくする。ユーザーの苦情をエラー率の急上昇と同じくらい真剣に扱う。ユーザーは、監視では見えないことを教えてくれている。
フィードバックシステムにもメンテナンスが必要
フィードバックシステムの最初のバージョンは正しくないだろう。しきい値は間違っているだろう。アラートは間違った人に送られるだろう。レポートにはノイズが多すぎるか、シグナルが少なすぎるだろう。
それは正常である。重要なのは、フィードバックシステム自体もフィードバックを必要とするものとして扱うことである。
チームがアラートに対応するたびに、次のことを問いかける。このアラートは適切なタイミングで届いたか？役に立ったか？適切な人に届いたか？答えが「いいえ」なら、変更する。しきい値を調整する。受信者を変更する。フォーマットを簡素化する。アクションに繋がらないアラートは完全に削除する。
優れたフィードバックシステムは、一度設計して放置されるものではない。チームが何が重要で何が重要でないかを学ぶにつれて、成長していく。
実用的な簡易チェックリスト
フィードバックシステムが実際に機能しているかどうかを確認したい場合、次の質問をチェックしてみてほしい。
- デプロイ後の最初のアラートを受け取るのは誰か？デプロイしたチームか？
- 緊急アラートは、遅く累積的なシグナルから分離されているか？
- フィードバックが届いたとき、チームは明確な対応パターンを持っているか？
- ユーザーやサポートがシステムにフィードバックを返す方法はあるか？
- フィードバックシステムは、チームが学んだことに基づいて過去1ヶ月以内に調整されたか？
これらのいずれかに「いいえ」と答えた場合、改善を始める場所がある。
本当の要点
誰も行動しないダッシュボードはフィードバックではない。それは飾りである。フィードバックは、意思決定できる人に、使える形式で、まだ意味があるタイミングで届いたときにのみ存在する。この原則に基づいてフィードバックシステムを構築すれば、デプロイは不安の種ではなくなり、学習の源になるだろう。