障害対応をがんばるPMは尊い

メルペイでPMしてます、さとじゅんです。

言いたいことはタイトルの通りです。

「障害対応がんばるPMは尊い！！！！！！！！」」

現場からは以上です。

ありがとうございました。

、、、と言うくらい、タイトルでもう言いたいことの80%くらいを言い切ってしまいました。

ちなみに最初に言っておきますが、障害対応自体はPMだけでなく関わった方すべてが尊いです。

これは間違いありません。

今回はPMに焦点をあてた内容にしたかったのでこのタイトルにしました。

障害が起きた時、とてもプレッシャーのかかる局面だったかと思います。
なにが起きてるのかわからず焦ってしまったと思います。
それでも仲間と乗り越えてきたんだと思います。

みなさま本当にいつもお疲れさまでございます。

まえおき

ということで、プロダクトを運用していく過程で障害対応は避けては通れないですよね。

昨今の華々しいプロダクトマネジメント論はプロダクトマネージャーの仕事のひとつを的確に現していると思いますが、そういったこと以外にも、とても地味でなかなか評価にもつながりづらいようなさまざまなタスクをこなしていくのがPM職の現実だと思います。

今回はそういった地味だけどとても重要で大切なことである、障害対応に焦点を当てたnoteを書いてみることにします。

障害対応は大変だ

障害は突然起こります。

リリースした時に発覚するものもあれば、リリースした後のお問い合わせから気づくことができて、青ざめながら事実確認をすることもあると思います。

そんな時、エンジニアはすぐにログを追って、状況確認をしてと忙しく動き回ります。

ではPMはなにができるでしょうか？

特に意識して動きたいのは下記のポイントです

1. コミュニケーションのパイプラインを整備して情報を集約する

障害が起きると、各所でその障害に関する質疑が繰り返されてしまいます。

そうすると、例えばひとりのエンジニアが何人もの人からの同じ質問に答えるなど、別の苦労が発生してしまいます。

そうならないためにもコミュニケーションのパイプラインを整えます。

例えば今回の障害専門のslackチャンネルを立ち上げるなどして、とにかく情報の集約に努めます。

そうすることで、重要情報が散乱しないためだれでもそこをみれば状況がわかる状況を作り出せます

2. 正しくわかりやすく情報を伝える

エンジニアが出してくれた情報を元に、情報をまとめていきます。

いつなにがどうして起きたのか、影響範囲はどのくらいだったのか。

これらを出来る限りサマリーしてslackで投稿しておきます。

するとあとから障害に気がついた関係者にとってもわかりやすい状況を作ることができます。

影響範囲の洗い出しは予めクエリを作成しておいて、PMでもクエリを回せばすぐに結果が出せる状況を作っておくと、よりチームで効率的に障害を対応することができます

3.なるべく関係者全員がわかるように発信する

slackのスレッドを掘り下げすぎて、そのスレをみている人にしか状況がわからないみたいな状況はなるべく避けたいです。

なるべく関係する人がすぐに状況を理解できるように、slackであればオープンに投稿していきましょう。

4. 暫定対応・お客さまへのコミュニケーションを検討する

システムの暫定対応が完了して止血できたら、お客さまへのコミュニケーションをどのように行うか検討しましょう。

サービス内の告知ページや、お問い合わせの対応方針を決めるなど、コミュニケーションの方針について不明瞭な点があれば、積極的に巻き込まれにいって決めにいきましょう。

5. 恒久対応・再発防止策を検討する

暫定対応はあくまで暫定なので、恒久対応と再発防止策をエンジニアと協力して検討しましょう。

恒久対応のために他のチームの巻き込みが必要であれば積極的にしていきましょう。

ここはエンジニア主導で行われる場合も多いと思いますので必要に応じてアクションしていきましょう。

5. 障害対応の振り返りをする

今回の障害対応で「うまくできた」ところ「うまくできなかったところ」を関係者で話合いましょう。

もしかしたら開発以外の運用面でルールを決めていたらもっとスムーズに対応できた場面があるかもしれません。

チームのちからで同じことが起きた時に、もっと素早く対応できるようにするにはどうしたらいいかを考えていきましょう。

やっぱり障害対応は大変だ

ここまで書いてきて、やっぱり障害対応は大変だと思います。

特にPMはエンジニアではないので直接的に障害を直すことはできません。

ただ、障害は起きてしまったらステークホルダー全員に対してコミュニケーションが必要なので、その陣頭指揮を取り、すべて着地させられるように動き回ることがPMの役割のひとつとも言えると思います。

[番外編] 決済システムの障害対応

ここからはちょっと番外編です。

いまわたしが携わっている「決済」という領域の障害対応について少し紹介をしていきます。

ここでも地味ながら、大切ななにかがあるのです。

ちなみにわたしは、前職ではソーシャルゲームのPMやエンタメ系アプリのPMをしており、今はメルペイで決済システムの開発をしています。

正直なところ、その中でも今携わっている決済システムのPM時代がもっとも障害対応が大変で、もっとも学びが多かったと言えます。

例えばゲームを作っていた時は、軽微な不具合であれば影響範囲次第でもありますが、サッと直してお客さまに対して謝罪のお知らせを掲載し、一定期間が経過するとお知らせを取り下げるような運用があるかと思います。

しかし決済システムの障害の場合この限りではありません。

決済システムのようなオフラインで日常的に利用されるプロダクトにおいては、生活の一部ともなっているのでひとつの障害がもたらす影響が、甚大なものになります。

決済システムがなんらかの理由で正常に動かず、エラーが起きてしまうと、リアルな世界では、例えばレジ前で店員とお客さまが決済システムが使えないということで混乱してあたふたとしてしまいます。

お客さまからしたら、レジに並んでいる後ろの人にも迷惑がかかるし、とてもいやな体験をさせてしまいます。

そういった状況を見かねてお店の担当からクレームのお電話をいただくこともあります。

障害が起きる原因

これはいろいろなシチュエーションが考えられると思います。

自分の開発チームでなにか問題があるままリリースをしてしまった場合や、他の開発チームの障害にひきずられて起きてしまうこともあると思います。

他にも、自社が利用している他社システム(AWSなどのクラウドサービスなど) で障害が起きて、引きずられる形で決済障害が発生してしまった場合もあると思います。

理由はどうあれお客さまからするとそれはすべて「決済事業者で起きた障害」と思われてしまいます。

悔しいですが、これは仕方のない事実です。

決済処理に障害が起きたら

決済処理に障害が起きた時にPMがエンジニアと協力してやることは以下です。

• 障害自体の止血対応

• いつからなにが起きて影響範囲はどれくらいなのかを把握する

• お客さまに対して障害のお知らせを掲載するなどして連絡をする

ここまでは一般的な障害対応と同じですが、決済障害の場合、オフラインで事業を営んでいるお店(以下、加盟店)のみなさまにご迷惑をおかけしてしまうので他にもいくつかやるべきことがあります。

1. 障害が起きたら直ぐに、直ちに、1秒でも早く加盟店にメールを送る

2. 必要であれば障害が落ち着いた後、すみやかに障害報告書を提出する

1.ですが決済事業においては、障害が起こることよりも障害が起きた事実を加盟店に報告することが遅かったことの方が問題視される場合があります。

前述のようにレジ前ではお客さまも店員も障害によって困惑しているわけですから、なるべく早く障害が起きた事実を知りたいわけです。

だから、起きたら事象に対する解像度が上がっていなくても、まず連絡をくれと言われることがあります。

なのでとにかく1秒でも早く連絡をする必要があります。

2.ですが、障害が起きた際にどのくらいの影響があって、原因、経緯が何で、再発防止策がなにかを報告する必要があります。

これらはエンジニアだけで書ける内容ではないですし、セールスだけで書ける内容でもないので、PMが間を取り持ち、各所に調整を重ねて完成に漕ぎ着けていきます。

より強固な体制を作るためにプロダクトとしてできること

障害はないにこしたことはないですが、発生してしまうことはあると思うので、発生後にいかに誠意ある対応を迅速にできるかが重要だと思っています。

数々の決済障害を経て、いくつかプロダクトとしても開発してきた内容があるので、紹介させてください。

1. 障害発生時の加盟店への自動メール発報システム

2. 決済障害時に決済データの不整合の発生数を低減させるサーキットブレイカー

1.ですが、障害発生時に1秒でも早く障害の事実を加盟店の皆さまにお知らせするために、ある閾値を超えたら自動で障害報告のメールが送られるシステムを構築しました。

休日に障害が起きてもメール自体は自動で送られる基盤ができたのでPMとしては少し安心することができるようになりました。

2.ですが、決済障害が起きると一番ややこしいのが、実は決済データの不整合です。

お客さまは決済が成功しているとアプリ上表示されているのに、加盟店側のレジは決済失敗とみなすらような事象が発生することがあります。

これを回避するために内部的にサーキットブレイカーを用意して、データ不整合を発生させなくするシステムを開発しました。

エラーの数に応じてサーキットブレイカーが自動でcloseしてくれるので二次災害を防ぐのに一役買ってくれています。

数々の障害対応を経て

やはり障害対応は大変だと思います。

プレッシャーのかかる中で原因究明と止血対応、各所への報告、謝罪、恒久対応の検討とたくさんのTODOにおわれてしまいます。

でも障害のないシステムを作ることはできません。

そして障害が起きた時こそ、チームの真価が問われる時でもあります。

誰も責めず、みんなで解決する、次につなげる

このような姿勢が重要なのではないでしょうか。

改めまして、、いつも障害対応に、尽力している皆様、、本当にお疲れさまでございます。

私もそのひとりとしてこれからもがんばっていきます。

※こんな感じのnoteいくつか書いてます。
よかったらtwitterフォローお願いします
https://twitter.com/junsam22