- はじめに
- 課題：「気づいた人が見る」という性善説の限界
- アプローチ：プロジェクトではなく「委員会」という選択
- やったこと①：委員会内でのスモールスタート
- やったこと②：メンバーのアサイン
- やったこと③：初動マニュアルの作成
- 結果①：「何をすればいいかわからない」がなくなった
- 結果②：担当者を起点に、チームが動き始めた
- 次の課題：工数の可視化
- おわりに
はじめに
こんにちは、サーバーサイドエンジニアの中川（@tkdev0728）です。
プロダクト開発に携わるみなさまにとって切っても切り離せない関係の業務が不定期で発火するアラートではないでしょうか。
「アラートが来ても、詳しい人がいないと誰も動けない」
「見た人がなんとなく対応している」
こういった状況、エンジニアリングチームを運営していれば一度は直面したことがあると思います。弊社のチームも長らくこの問題を抱えていました。本記事では、アラート対応の属人化を解消するために取り組んだことと、実際にやってみてわかったことをお伝えします。
同じように属人化に悩むチームの助けになれば幸いです。
課題：「気づいた人が見る」という性善説の限界
以前の弊社のアラート対応は「気づいた人が見る」という性善説での運用でした。 あえて対応者を限定しないことでメンバーの知見獲得や柔軟な体制を組むことが狙いでした。 プロダクトやチームの規模が大きくないフェーズでは有効でしたが、それらが大きくなるにつれて以下のリスクが顕在化してきました。
リスク1：有識者がいないとわからない
弊社にはプッシュ通知基盤やデータ集計基盤など、かつてのプロジェクトとして積極的な機能開発を行っていましたが優先度の関係で現在は保守がメインとなっているサブシステムがいくつかあります。これらのアラートが発火しても、当時のメンバーでないと文脈がわからない。その人が会議中だったり、休暇中だったりすると、対応要否の判断が遅れてしまうリスクがありました。
リスク2：知見のブラックボックス化
対応するほど知見が貯まり、知見があるからまた対応する。この正のフィードバックが一部のメンバーにしか働かず、その他のメンバーは「参加する機会がない → 知見が貯まらない → 参加できない」という負のループに陥っていました。
結果として、「誰かがやってくれるから大丈夫」という、チームとして不健全な状態が続いていました。
この問題は、意欲的なメンバーにとっても他人事ではありませんでした。後に知ったのですが、メンバーからはこんな声もフィードバックとしていただきました。
- ドメイン知識がないと何もできません状態になってしまう。入りづらい
- アラートチャンネルがたくさんある中で、何に対応すればいいのかわからない
- New Relicを使ったことがなく、ログの見方からわからない
問題は属人化だけでなく、参加したくても参加できないという構造的な障壁も存在していたのです。
アプローチ：プロジェクトではなく「委員会」という選択
この問題を解決するため、私たちが選んだのは委員会という形式でした。
弊社ではメインプロジェクトほどの規模感ではないが何かしらの組織的な活動を推進したい時にサブプロジェクト的に編成 or 有志でメンバーを募ってチームを作り、活動するということがあり、これを委員会と呼んでいます。
「アラート対応の仕組みを変える」という目的に対して、プロジェクト化するほどの規模感ではないが、個人の努力に委ねたままにもしたくない。そのバランスを取る手段として委員会は有効でした。
また、委員会のゴールをあえて「委員会を解散すること」に設定したのもポイントです。全員が対応できる状態になれば、委員会は不要になるはず。仕組みを作って属人化を解消し、自分たちの役割をなくすことを最終目標にしました。 目的を達成すればすぐ解散できるというのもプロジェクトではなく委員会にしたことのメリットでした。
役割の定義も重要でした。委員会はアラート対応の代行をするプレイヤーではなく、あくまで交通整理役と位置付けました。メンバーに求めたのは「技術力より巻き込み力」です。詳しい人に「これ教えて」と聞きに行き、わからない人と詳しい人の橋渡しをする。そういうコミュニケーションが取れるメンバーが集まることを期待しました。
さらに、「ダラダラ続ける委員会」にならないよう、四半期の3ヶ月で解散することを目標に、フェーズごとに役割を明確にしました。
| フェーズ | 期間 | 委員会の役割 |
|---|---|---|
| 足場作り | 〜1ヶ月 | グルーピングと手順書の整備 |
| メンター | 1〜2ヶ月 | 実際の対応開始、初動のサポート |
| 監視者 | 2〜3ヶ月 | 放置アラートのウォッチ、解散に向けた障壁除去 |
なぜツールではなくチーム運用から始めたのか
昨今はAIを活用したアラート分析ツールや、自動トリアージの仕組みも充実しています。「なぜそこに頼らなかったのか」と思う方もいるかもしれません。
私たちがあえてチーム運用を起点にしたのは、属人化している状態でツールを導入しても、属人化そのものは解決しないと考えたからです。
ツールは手法を変えてくれますが、「誰がその手法を使うか」という問題には干渉しません。対応できる人だけがツールを活用し、そうでない人は引き続き蚊帳の外のまま、という状態は十分に起こり得ます。手法が変わっても、属人化の構造が変わらなければ意味がありません。
私たちが本当に解決したかったのは「特定の人に依存している」という構造そのものです。そのためにはまず、全員が等しく「アラート対応の痛み」を共有することが必要でした。全員が当事者として同じ困難に向き合うことで、初めて課題が共通認識になります。
その共通認識の上に、ツールや自動化を乗せていく。そういう順番が重要だと考えました。
やったこと①：委員会内でのスモールスタート
メンバー全員にアラート対応をお願いする前にまず委員会でアラート対応をやってみて課題を知ることから始めました。
すでにアラート対応を積極的に行っているメンバーにとって何が障壁なのかわからない。
今まで消極的なメンバーにとっては何をすればいいかわからない。
ここの差分が課題だと考え、まずは委員会メンバーの中から今まで積極的に行っていなかったメンバー数名に実際に対応を依頼し、週次の定例で感想を聞くことをやってみました。そこで以下のようなフィードバックをもらいました。
- そもそもアラートに気づいてなかったのでチャンネルの通知をONにしてみた
- 実際に発火した時にNewRelicのどこをみればいいかわからない
- このチャンネルのアラート誰もみてないけど本当に必要？
ここでのフィードバックは全体に展開するために必要な要素を含んでいたので大変有意義なものとなりました。
やったこと②：メンバーのアサイン
次に取り組んだのは、サーバーチーム全体（20人弱）をサブシステムごとに偏りなく割り当てることです。
私たちのチームにはプッシュ通知基盤、データ集計基盤、外部連携など複数のサブシステムが存在します。当然、人によって詳しい領域は異なります。以前はそれが「詳しい人に集中する」構造を生んでいたわけですが、今回はあえてそれを崩す方向でアサインを設計しました。
具体的には、各メンバーのドメイン知識を踏まえつつ、一人に負荷が偏らないようサブシステムへの担当を分散させました。「自分が詳しいから担当する」ではなく、「チームとして全域をカバーする」という発想への転換です。
グループのサイズは4〜5人に設定しました。大きすぎると「誰かがやるだろう」という意識が生まれ、小さすぎると一人あたりの負荷が高くなります。この人数は、責任の所在を持たせつつ負担を分散するバランスとして選びました。
当番の運用は、毎週月曜日の午前10時に自動でリマインダーが流れる仕組みにしました。「今週の担当は誰か」をその週の始まりに通知することで、担当者が意識を持ってアラートをウォッチする状態を作っています。カレンダーや当番表を自分で確認しに行く手間をなくし、仕組みとして自然に回るようにした点がポイントです。
詳しくないサブシステムを担当することへの不安は当然あります。ただ、それを解消するのが次のマニュアル整備とセットになっています。知識がなくても初動が踏み出せる仕組みがあれば、担当を広げることへのハードルは下がります。
やったこと③：初動マニュアルの作成
アサインの次に着手したのが「初動を迷わないマニュアル」の整備です。
アラート対応でつまずく最大のポイントは「最初に何をすればいいかわからない」という状態です。そこで、担当者が誰であっても同じ品質で初動できるよう、フローをドキュメント化しました。
ステップ1：ログの確認と共有
アラート通知に含まれるリンクから監視ツール上のログを確認し、スタックトレースをアラートスレッドに貼ります。まず「何が起きているか」をチームに見える化することを最初のアクションとして定義しました。
「誰かが見ているかもしれない」という状態をなくし、調査状況を可視化することで、無駄な重複対応も防げます。
また、ログを貼るだけであれば専門的なドメイン知識も不要なので、まずここをやってもらうことを目指しました。
ステップ2：過去の対応履歴を確認
次に、同じ事象が過去に起きていないかチャンネル内を検索します。ここで対応が2つに分岐します。
A. 過去に同じ事象があった場合
過去のスレッドを参考に調査を進めます。もし「対応不要」と判断できるものであれば、アラートの除外設定や閾値変更を行い、ノイズを積極的に減らします。
B. 初めて発生した事象の場合
次のステップの詳細調査へ進みます。
ステップ3：発生条件と顧客影響の特定
「何が原因か」と「誰にどんな影響があるか」を明確にします。
- 発生条件の特定: どの操作やバッチ処理のタイミングで発生しているか
- 顧客影響の確認: ユーザー視点で何ができなくなっているか
この2点を言語化することで、次のインシデント判定の精度が上がります。
ステップ4：重要度の判定と対応
社内で定めたインシデント重要度の基準を参照し、今回の事象がどのレベルに該当するかを判断します。
| 重要度 | 対応 |
|---|---|
| High 以上（重大な障害） | 専用のインシデントチャンネルで報告し、関係者を巻き込んだ対応フローへ移行 |
| Medium 以下 | アプリケーション改修が必要な場合はチケットを起票。改修不要かつ今後通知も不要なら除外設定を行う |
「迷ったら遠慮なく頼る」を明文化する
このマニュアルで意識的に入れたのが、「迷ったら遠慮なく助けを求める」 という一文です。
「これインシデントかな？」「このログの読み方がわからない」というとき、スレッドに「調査中ですが、ここの判断ができないのでヘルプをお願いします」と投げることを明示的に推奨しています。心理的安全性がなければ、マニュアルがあっても使われないからです。
完璧なドキュメントを目指さない
このマニュアルを作るうえで意識したのは、最初から完璧を目指さないことです。最初のスモールスタートの時のフィードバックで特に感じたのですが、課題と思うポイントやつまづくポイントは人それぞれなので、完璧を目指すよりも対応していく中での気づきを気づいた人が随時アップデートしていく方が合っていると考えたからです。 実際、この時作成したドキュメントは何度も他のメンバーによって編集されています。
結果①：「何をすればいいかわからない」がなくなった
委員会の活動を通じて、まず仕組みとしての変化が生まれました。
- 属人化の解消：特定のメンバーだけが対応するのではなく、当番制でローテーションできる体制が整った
- 初動のバラツキがなくなった：マニュアルがあることで、経験の浅いメンバーでも最初の一歩を踏み出せるようになった
- アラートの整理が進んだ：「対応不要なのに通知が来続けているアラート」を除外設定することで、ノイズが減り本当に重要なアラートが目に入りやすくなった
マニュアルがあるから、新しいメンバーでも恐れずに参加できる。参加するから知見が貯まる。以前の「参加できない → 知見が貯まらない」という負のループが、ポジティブな方向に転換しました。
結果②：担当者を起点に、チームが動き始めた
仕組みが定着してくると、もう一段階の変化が生まれました。担当者がアラートを確認しながら、チームメンバーに積極的に声をかける流れです。「このアラートみれる方いますか？」といった呼びかけがスレッド上で自然に起きるようになりました。 自分自身今まではすぐ調査できない場合は黙って静観してしまうこともありましたが、周りに頼りやすくなったのがいい変化でした。
以前は詳しい人が黙って対応して終わりだったものが、担当者を起点としたコミュニケーションが生まれ、知見が少しずつチームに広がっていく手応えを感じています。
次の課題：工数の可視化
仕組みとしては整ってきたものの、現状では誰がどのくらいの工数をアラート対応に使っているかが見えていません。
冗長化された次の課題は正しく工数を計測し、工数を削減することだと思っています。
別チームでメンバーごとの対応比率を可視化する仕組みがワークしているので、まずは同じように全体の割合に対して対応比率を可視化すること、メンバーに正しく工数をつけてもらうことから始めるつもりです。
おわりに
アラート対応の属人化は、多くのチームが抱える共通の課題だと思います。「プロジェクトにするほどでもないが、放置するには影響が大きすぎる」問題に対して、委員会という緩やかな形で有志を集め、仕組みとドキュメントを整備するアプローチは一定の効果がありました。
完璧な状態を目指すより、「今日から動ける状態」を少しずつ整えていく。その積み重ねが、最終的にチーム全体の底上げにつながると実感しています。
ヤプリに興味を持った方はぜひカジュアル面談にお越しください！
