トラブル発生時にPMは何をやるべきか

いきなりのポエム

とあるところで「地味PM」っていう単語を耳にしまして。

「PM = プロジェクトマネジメント の仕事って、ロードマップ策定とかUXリサーチのように華やかそうな仕事で語られること多いけど、そんなのは氷山の一角で、実施の仕事の多くは地味なもんですよね。そういうのも含めてプロジェクトマネジメントだし、地味な部分をやっている人たちにもちゃんと日が当たるようにしていきたいですね。」

ってことを地味PMと表現したそうなんですが、個人的にはすごい共感しまして。まぁぶっちゃけ地味ですし。どこの世界線にいけば、もっとキラキラしたプロジェクトマネージャーになれるのだろうか…。と思わんこともないです。

そんなこんなで「地味PM」ってなんかいいなと思った勢いで、地味PM仕事のあれこれを残しておこうかと思った次第です。

概要

基本的な対応フローについては今回は説明しません。

この記事においては、

• そもそもどうやってトラブルに気づくか
• PMはトラブル対応でどういう役割を果たすか

的なことについて書きます。

そもそもどうやってトラブルに気づくか

トラブル対応の第一歩は、まずは検知するところからです。

とはいっても、PM が最初に検知するってことはほとんどなくて、プロジェクトの担当エンジニアメンバがセルフで異常を検知してくださって会話がスタートしているので、それを見つけてのぞきにいくパターンがほとんどかと思います。

例えば

• システムエラーなどが出てくるチャンネル
• 出てきたエラーを検知して、対応を行うときに使われるチャンネル
• ユーザー問い合わせ関連の質問や依頼が上がってくるチャンネル

こういったものを小まめにウォッチしておくことが重要です。
（ないのであれば、作って運用するのも良いでしょう）

基本的にはメンションが来たときだけ見ればいいとも言えるんですが、特に関係なさそうでも、なんとなく見ておくことで、似たような事象が発生した際に実は関連していた、といったことにすぐ気づくことができる場合があります。

気になるやり取りを見つけたら

そして、各チャンネルで気になる会話をチェックして、少しでもユーザー影響出ていそうなものがあったら、率先して「emergency のレポートしましょうか？」と聞いてみましょう。

影響出るような話が起きていたら、そもそも発見者の方がレポートしてくれることがほとんどだと思いますが、もしまだであれば…ということです。また、緊急性度の高いものである場合は、本人がテンパっており、そういった細々した作業を忘れていたり、冷静な判断ができない場合もあるため、助けになります。

emergency を上げるには微妙か…？と迷ったときでも、とりあえず上げちゃうのがおすすめです。結果的に不要な emergency を上げても別に怒られもしないですが、もしも emergency を上げるのが遅くなって、その分対応が遅くなるようなことがあったとしたら、それはユーザーさんへの影響を引き伸ばすことになるので絶対的に良くないです。

PMはトラブル対応でどういう役割を果たすか

トラブル対応のためにやること

トラブル対応で何よりも大事なことは、少しでも早くトラブルを収束させること = ユーザーさんへの影響を極力小さくすることです（外部要因で収束できない場合には、適切な周知を行うなども）。なのですが、早期解決のために PM が直接的にできることは、正直なにもありません。

逆に、PM 以外の職種の方でなければ出来ない仕事というのは明確です。

• ユーザー問い合わせ調査・問い合わせ回答・お知らせ作成/公開（主にカスタマーチーム）
• トラブルの原因調査・修正対応（主にエンジニアチーム）
• 影響調査・配信停止・キャンペーンの停止（主にビジネスチーム）

などです。逆に言えば上記の仕事以外は全部PMということになります。そういうと大げさな感じもしますが、大体のトラブルにおいて、実際にやることのパターンは決まっています。

• 起こっている事象について、非エンジニアメンバにも分かりやすく整理する
• ユーザー向けお知らせ方針をCSメンバと相談して決める
• エンジニアメンバから事象の原因をヒアリングしたり、対応方針について相談する
• エンジニアメンバからユーザー影響の大きさをヒアリングする
• ビジネスメンバーに影響調査をお願いする
• 上に向けに、情報を整理して報告する
• 状況にアップデートがあったら、とにかく情報更新を投げる

会社によってフローは違うと思うのであれですが、同じようなことは皆さんも行うのではないでしょうか？

各チームとのコミュニケーション

ざっくりやることは前述のとおりですが、もう少しだけ細かいところも記載しておきます。

- to エンジニアチーム

トラブル収束のためには、エンジニアメンバーの原因調査・修正対応をしてもらわねばなりません。まずはそこに集中してもらうことが考えるべきことなのですが、PM としては、状況を正しく把握して各所に情報を展開するという役割も担わないといけません。

• エンジニアメンバーの邪魔をしない
• エンジニアメンバーから原因や対応状況をヒアリングをする

というのは、基本的には相反することです。ここに関しては、適切にバランスを取って進めるとしか言いようがないので、上手いこと頑張ってください。

また、トラブルによっては「一時的にサービス全体をメンテモードにする」とか「一部機能を停止させる」といった判断が必要なケースもあります。責任者がすぐに判断を下せる状況であれば判断を任せてもいいのですが、常に即レスしてもらえない状況もあります。そういったときには、トラブル対応を担当している PM が判断を行うようにしましょう。

- to カスタマーチーム

CS さんとのやり取りすべきことについては、下記となります。

1. お知らせを出すかどうかの相談
2. （お知らせ出すときには）お知らせ文案作成のお願い
3. ユーザーからの問い合わせ調査のお願い

1, 2 については、トラブル発生中の周知だけが目的ではなく、収束した後に「こういうトラブルが発生していましたが今は収束済みです」という形で出すこともあります。トラブル対応が終わった後であっても、ちゃんと相談した上で、出す/出さないの判断をするようにしましょう。

なお、トラブル事象については、基本的に PM が一番把握しているはずです。情報は正確であるか、ユーザーさんへの伝え方として適切か、などの観点からチェックを行い、必要に応じて適宜修正依頼を出したり、問題なければ最終的な発出の判断を下すようにしましょう。

また、トラブル発生中であっても収束後であっても、基本的にお知らせ文面の中には、トラブル発生時間を記載することがほとんどです。いつ発生したか/いつ解消したかというのは、なるべくはっきりと記載できるよう、適切に把握できるようにしましょう。

3 については、トラブルの影響として何件の問い合わせが来ているかを把握するためにヒアリングすることが基本ですが、いつから発生している事象なのかを知るための手がかりとしてヒアリングすることもあります。

ユーザーさんとのコミュニケーションにおいては、CS の方々が中心的な役割を果たしていただくことになります。また、お知らせを作るには一定の時間もかかりますし、そのためには適切な情報を把握してもらう必要があります。いち早く CS さんとはコミュニケーションをとって、対応をお願いすることを心がけましょう。

- to ビスネスチーム

ビジネスチームとのやり取りすべきことについては、下記となります。

1. 予定施策への影響有無の確認
2. 影響の算出お願い

2 については、トラブルがどういった影響を与えたのかを調べてもらうということなので、これは分かりやすいかと思います。一方で、やや忘れがちなのが 1 です。

トラブルによって、予定している施策（キャンペーンなど）に影響が出ることがあります。施策に影響がでるトラブルの場合は、キャンペーンの一時停止であるとか、Push通知（を止めるであるとか、そういった対応をする必要があります。トラブルが起こった場合には、なるべく早めに情報を展開して、必要な対応を検討してもらうようにしましょう。

- to プロダクトの責任者

現場で対応するメンバーの代わりに、会社の事業長などの上位レイヤーへのレポートをしてくださっています。ですので、なるべく細かく状況を共有することを心がけましょう。

これはあくまでも一例ですが、レポートするときには下記フォーマットはこんな感じです。これらの情報が網羅されていれば、おそらく知らせるべき情報としては十分かと思いますし、逆に情報が埋められない部分があれば、そこは対応が必要な箇所だと思ってよいかと思います。

トラブルレポートのアップデートです。

■ トラブル状況
収束済み

■ トラブル事象
iOS端末（iPhone/iPad）において、XXX画面が開けなかった

■ トラブル時間帯
2021年12月28日(火) 10:00-11:27

■ トラブル原因
YYYにおいて、仕様上想定されていないZZZがセットされたこと。
それによりクライアント側で、エラー画面が表示されていた。

■ トラブル復旧方法
トラブル原因となっていたコードの修正

■ 影響
9,999,999,999円
（計算方法のリンクを貼ると良い）

■ お知らせ
復旧済みにて配信済み
（配信済みお知らせリンクを貼ると良い）

トラブル対応にあたっての心がけ

このトラブルは自分の担当プロジェクト関連じゃないし…みたいな考えはやめましょう。

• 「AWS障害？他チームにお任せしておこう」
• 「この案件はあっちの PM のやつのはず」

とかは絶対だめです。

インフラ系は代表的ですが、自分が持っているプロジェクトと直接関係ないものであってもユーザー影響範囲が大きいものもあります。そういったときこそ、積極的にトラブル対応に加わっていくようにしましょう。

他のPMが担当だし…のケースにおいては、基本的には担当者が対応すべきです。ですが、対応できない事情があるかもしれないので、すぐに反応がないようであれば、一旦サポートに入っておいて後で交代するとかでもいいので、一回入ってしまいましょう。

ミーティングがある？ ユーザーさんへの影響を止めることより優先されるべきミーティングなんてないので、遠慮なく飛ばしましょう。トラブル対応したことないからやり方が分からない？やらないと分かりません。やってれば慣れてきます。慣れれば、楽しくなります。

※ もしもそんな風に考えている人がいるならば…という仮定のもとに書いてます
※ 特に批判の意図はありませんので悪しからず

終わりに

個人的な地味 PM 仕事の代表ということで、トラブル対応について書いてみました。

書いておいてなんですが、あくまでも「自分はこんな考えで、こんな風にやっている」というだけです。正直なところ、トラブル対応のときのアクションが正しいのかどうかは分かってません。

もしも、もっとこうしてくれるとありがたいとか、こうした方がいいのでは？的なものがあれば、コメントくださいm(＿ ＿)m