はじめに
顧客影響を伴う事象が本番環境において発生した場合、エンジニアは下記のような計画外の火消し業務に追われる。
- インフラ系
- SLO違反などを原因としたPager発報などに端を発するインフラ周りの復旧改善対応。
- サービス系
- サービスのユーザー、あるいは社内（開発チーム、QAチーム、CSチーム、etc）によるサービス不具合報告に端を発する復旧改善対応。
本稿では、B2Bサービス不具合発生時における問合せ対応に焦点を絞り、その質上げを目的とした取り組みや考え方について説明する。分量が大きくなりそうなので、準備編（本稿）と対応編（予定）に分割記載する。
事前に備える
不具合問合せは当然計画外対応となり、顧客影響の程度によっては対応緊急度が高く、割り当てられる（人的、時間的）リソースもタイトになる。ゆえに、問合せ発生時に効率的に動くための事前準備が対応の質に直結する。
問合せ対応時の役割
問合せにおいて、エンジニアは技術的立場から問題解決に取り組むことになる。チームが機能的に動くため、役割に応じた動き方を意識すると良い。
指揮者
指揮者の責務は問題の着地点を定め、合意形成し、実際に着地させることだ。指揮者には以下の能力が求められる。
- 不具合特定のために技術観点から仮説を立てられる技術力
- プロダクトの仕様やドメイン知識、直近の本番環境に対する変更などの知見
- 目先の状況だけでなく数手先までを見通し、複数の着地点を想定して対応を前進させるディレクション力
- 作業者（後述）およびビジネスサイドに事実をヒアリングし、不具合についての仮説やアプローチ、着地に向かうための方針や計画を説明できる力
チームリーダーやテックリードを担うシニアエンジニアはこれらを能力を（きっと）有しているはずだ。責任感の高さも加わり、特に人的リソースが不足している場合は彼らが指揮者の役割を率先して引き受けることが多いと思う。
しかしこの状態が定常化すると属人化が進行してしまい、特定の人だけに問合せ指揮の知見が蓄積し、チームとしての問合せ対応力が向上しない。特定のエンジニアへの作業集中やトラックナンバー1を避けるため、指揮者はエンジニア間で持ち回るのが望ましい。
指揮者は調整役（交通整理役）ではない。問合せに関する意思決定責任を有し、判断根拠を各方面に説明できなければならない。
作業者
指揮者のディレクションのもとで、作業者は下記のようなタスクを担う。
- 不具合事象の特定、再現手順の確認
- 原因調査、コード改修およびレビュー
- hotfixやrevertを目的とした緊急リリース作業
作業者のアサイン方法は手上げ、指揮者による任命など様々だ。しかし、指揮者は後述する不具合トリアージ結果や顧客の温度感を念頭に置いた上で、誰に何をしてもらうのが良いか、対応中は常に考え続ける必要がある。問題の切り分けが進むことで、調査や改修作業のバトンタッチもありうる。
手を動かす以外にも、作業者は自身の作業目的や内容を明らかにした上で進捗や結果を共有する責務がある。「画面からのリクエスト失敗してないか確認するためServerのログ見ます」「じゃあ自分は検証環境で再現ためしてみます」程度の共有で十分である。後から対応経緯が追えるように、誰（WHO）が何（WHAT）をどう（HOW）したかテキストベース（Slackのスレッドなど）でも共有することをおすすめする。
書記
書記は問い合わせに関する情報を書き出す役割である。指揮者がディレクションしながら兼務しても良いし、作業者が交代しながら担っても良い（勿論専任者を立てても良い。人的リソースに余裕があればの話だが）。
口頭（対面やZoomなど）で行われた共有や仮説検討、各作業者の作業状況、ネクストアクションについての情報などはテキストベースで随時共有し、後から参加した作業者やビジネスサイドに対して対応状況が可視化するよう努めるべきである。後日、振り返りがしやすくなるメリットもある。
ただし、問合せ対応時はトライアンドエラーによる手戻りや、発散段階の仮説などふわっとした情報が錯綜するため、書くべき情報の見極めや整理する能力、またレスポンスの速さがある程度求められる。
不具合トリアージの基準を定めておく
不具合の大きさに対応する基準を事前設定し、実際の対応時にある程度機械的に意思決定根拠を示せる準備をする。 （無論、マージナルな不具合は存在するし、ビジネスインパクトによって最終的な対応緊急度は上下する。あくまで判断根拠の軸であり絶対的原則ではない）。
一例として、下記のように基準が設けられる（表記例なのでMECEな書き方はしていない）。
- High
- 性質：セキュリティリスクやユーザー権限機能に関わる不具合
- 影響範囲：全顧客
- Middle
- 性質：基幹機能が利用できない不具合
- 影響範囲：全顧客
- Low
- 性質：ユーザーが運用回避できる不具合
- 影響範囲：一部の顧客
基準設定の根拠には不具合の性質や影響範囲など、ビジネスインパクトに結びつく要素をビジネスサイドと目線合わせした上で列挙すべきである。また、本基準はエンジニアだけでなく、ビジネスサイドやボードメンバーなど、不具合発生時にエンジニア側から説明を行う相手と事前共有しておかなければならない。
問合せ対応時の情報共有場所を定めておく
リモートメンバーとオフィスメンバーが混在する状況で情報を分散させないためには、有事の際の情報共有ルールをある程度定めておく必要がある。
たとえば、問合せ対応時にグループ通話する場合は常にSlackハドルのXX部屋に集まる、などである。平時から社内で複数の類似ツールを利用している場合、有事は社内利用率が最も高く、かつ同時接続数が多くても部屋が安定しているツールの利用をおすすめする。
普段からリリース内容やインフラの変更を把握しておく
本番環境に加えられる変更について敏感であるべきだ。 リリース共有会やデイリースクラム、Slackでのパブリックな共有を通じて各種変更をキャッチアップしておくことで、不具合が直近の本番変更による影響下にあるかどうか見当をつける材料にできる。revertによる切り戻しか、改修をhotfixする前進対策かの意思決定を早めるためにも重要である。
おわりに
半分は不出来な自分に噛んで含めるように、マニフェストのつもりで書いた。
「弊社はこんな施策をしてるよ」「うちはXXな理由でそうしてないよ」などフィードバックお待ちしております。Twitterとかで教えて下さい:bow:
