PM障害対応の私的心構え・すゝめ

アドベントカレンダーを書いていると迫り来る年末を実感します。我が家はパートナー共々のお仕事する族なので、デザイナーのパートナーと「アドベントカレンダーが書けてなくて….！え、何日担当？」なんて会話が増えて参りました。バタバタ。

という事で、地味PM一期生（自称）として 地味PM Advent Calendar 2022の15日目にエントリー書いていきたいと思います！

adventar.org

何書こうかなと思い、「PMしてる時の地味なこだわり集」と接戦になった結果、障害対応について書こうかな、と思います。私は過去メディア・PRのお仕事に変わる事が多かった人間なのですが、そういった方面からも近年では障害対応に関しての知見が必要になってきているように感じる事もあります。

まず前提として、障害は起こさないのが一番です。ただ、どうしても発生してしまう事態に直面してしまう事もあります。良いトピックスではないので、なかなか語りにくい障害対応はナレッジもなかなか目にしないなぁというIssueを感じて、このテーマにしました。

私も完璧ではないですが、誰かの役に立てば……という気持ちで、改めて過去どうやって動いてきたかな、を言語化してまとめておくためにも、書いておこうと思います。

障害対応といっても種類は様々

まず、障害対応とひとくちに言っても種類は様々。システムが原因のものもあれば、人起因のもの、自社原因で発生するもの、自社以外の原因で発生するのもの、想定していない事象で起こるものなどもあります。

昔むかしでは、サイトが表示されなくなり、情報収集した結果、AWSが全面停止になって1日メディアが表示されないぜ……！汗（もはや2010年台前半の話）なんて事もありました。

私は基本的にPM（もしくは兼任以外でも準ずる仕事）をしている場合、種類が開発かそうでないかに関わらず、”プロダクトに関わる事”として共通して対応するようにしています。

障害時の心構え

障害時は心構えが特に大事。やはり人間、不測の事態には焦ってしまうので、心構えの基準を持つようにしています。

ユーザーファースト

なんと言ってもユーザーファーストです。いまご迷惑をかけている方のケアや影響範囲の最小化、ユーザーの安心に努めます。

焦らない・焦らせない

もはや鉄則なのですが、あれ、もしかして何か起きているかも……？という時には、まず焦らない。周りで焦っている人がいたら、交通整理をしてあげる事に徹しています。焦って動くと再度障害を広げる事になるので、早期対応や迅速対応は大切にしつつ、事実確認をするようにします。

非難しない・落ち着かせる

あれ、もしかして障害かも…..？という時に地味に意識しているのが、チームを落ち着かせる状況づくり、非難が起こりにくい状況づくりです。障害が発生しはじめた時のザワザワの伝播感って独特で、不安や心配が自然と組織内に広がっていく感じがあるなぁと思います。なので、あれ？もしかして？と思ったら対応人員をまず決め・確認して、第一報をなるべく早く打つようにしています。

対応ポジションの人が集中できる環境づくりに徹する

特にエンジニアや顧客対応関連のメンバーが対応に集中できる環境づくりを意識しています。情報共有や統制、対応メンバー以外への現状周知などや部署間のコネクトを具体ではやる事が多いです。タイムリーな中でコミュニケーションコストがかさんでしまったり、多方面からエンジニアor フロントメンバー宛に質問がきてしまうといっぱいいっぱいになるので拾ってあげたり、窓口対応したり、という事をしてます。

時間の意識

急いでいる時も動きや何か起こった時に時間を記録するようにしています・見返した時に事実の整理がしやすいです。何時、と記録するのが大変な場合は時間記録がされるチャットツールにいちいち投稿するようにしています。

障害時によくしている動き

過去いくつかのサービスやプロダクトチームの経験を踏まえて、どんな動きをしてみたかなぁ、の振り返りです。今回は組織でどう、というよりも、PMポジションの時の私がどう動く事が多いか、の目線になります。

1. とにかく早く察知して初動を早くする

もうこれは意識レベル・なるべくの話にはなってしまうのですが、ちょっと怪しそうだな、いつもと違うな、という違和感があれば、早めに確認に動きます。事象に対してタイムライン整理・事象や発生頻度の確認・顧客影響をヒアリングや調査で確認し、顧客影響が少しでも発生している・発生し得る場合には、障害対応ルートでの対応を決めます。

2.事実情報を共有する

これは障害として対応しなければならない、となったものに関しては、組織内で情報共有します。情報共有の順序としては、まず部署・チームの監督者1人ずつに個別コミュニケーション⇨組織全体周知という内容です。先に管理者に連絡する理由としては、全体共有を流した後のメンバー対応を監督者がスムーズにできるようになるからです。現状わかっている事実・わかっていない事実・やってほしい事（もしくは続報を待ってほしい事）・対応をしている人や内容・問い合わせ先 を第一報として周知します。

3.具体対応する

認識合わせの一次対応後は、具体的な対応をしているチームに合流して橋渡ししています。基本的には顧客対応部門・広報部門・開発部門の連携が多く、それぞれのチームがない規模のフェーズの際は代替します。

顧客対応部門の非常時オペレーションの策定や対応工数に対しての工数のヒアリング、対応しきれるかなどを確認して、足りない場合は他から借りてくる人員調整をしたりもします。

上記が終わったら開発部門に言って、顧客状況を伝達し、原因解明のキャッチアップや補助をして、作業の現場にいく、というのを繰り返します。

得た情報は経営メンバーや顧客周知・広報の対応中メンバーに提供します。（ちなみにこのフェーズはオフィスのあちこちを行き来している事が多い）

4.原因究明と対応後第二報

原因が見つかって対応策が打てたら、第二報の社内周知を行います。内容発生した事・日時・顧客影響・対象範囲・実施した対応・再発可能性等です。復旧が確認できていれば、復旧宣言も同時にします。

5.その後の対応・コミュニケーションのための連携

その後も社内外へしっかりとコミュニケーション、場合によって周知するために、各ポジションの方への情報共有や対応補助をします。やはり体力も使うので対応メンバーの疲労具合なども気にしながら進めます。

不要に心配をかけたり、物事を大きくする必要はないですが、顧客が小さくて気にならないものだったとしても、影響があるものに関しては最小限にできるように対応練って実行していきます。

地道に守る障害対応

自分がどうしてたかな、を書きながら振り返って、身の引き締まる思いになりました。地味PM仲間のさとじゅんさん（@junsamu22）が別で障害対応のお話されてましたが、地味で出にくい話でもあるかなぁと思うので誰かの一例の参考にでもなれば幸いです。

障害レベルを定めてレベルに応じたオペレーションを定めていたり、アラート・エラー検知に尽力されていたり、障害想定訓令をしていたり、と障害発生予防や発生時の迅速な対応に努めている企業や開発チームの皆様もたくさんいます。

課題を解決しよう！という世の中の素敵なサービスが、ユーザーとの信頼関係や安心を守っていけるようにこの分野も開拓されていくといいなぁ、と思います！