プロダクト開発に障害はつきものであり、障害対応としてユーザーに対する「補填」や「お詫び」に頭を悩ませることも多いでしょう。

「補填」や「お詫び」は誰に・何を・どのくらい配布すればよいのでしょうか？そもそも「補填」と「お詫び」の違いって何でしょうか？

大丈夫です。この記事を読めば、障害対応時の「補填」と「お詫び」について慌てずロジカルに意思決定することができます。障害が起きたからと言ってすぐに「補填はどうするんですか？」「お詫びを配布した方がいいのでは？」などと騒ぐのは今日で終わりにしましょう。ちゃんと答えがあります。

• 「補填」と「お詫び」は全く性質が異なります

• 世の中には「良い補填」と「悪い補填」があります

本記事では、こうしたサービス障害における「補填」と「お詫び」の思考法を整理します。

[1] 「補填」の整理

まずは「補填」について整理します。

[1-1] 「補填」とは何か

「補填」とは、各ユーザーが被った不利益を、ユーザーごとに個別で、必要十分に回復する行為です。

システム障害を起こした際に、まず第一に考えるべきは「お詫び」ではなくこの「補填」です。ユーザーに不利益を生じさせてしまったのですから、当然その分を正確に復旧する責任があります。

例えば「ATMから現金が引き出せないのに残高だけ減ってしまった」という障害を考えます。この際に運営者が行うべきは、各ユーザーの消失した残高分の返金です。「Aさんは10万円、Bさんは3万円、Cさんは1万円消失している」という状況においては、「Aさんに10万円、Bさんに3万円、Cさんは1万円の残高を復旧する」べきです。何をアタリマエな、と思うかもしれませんが、「補填」と「お詫び」の区別がついていない人は、こういう状況で「口座を持っている全員に一律500円付与しましょう」など見当外れなことを言い出してしまうのです。

[1-2] 「補填」はとても大変

「補填」には「特定」と「回復」という2つのプロセスがありますが、どちらも多大なコストがかかります。

まず、ユーザーごとの不利益を具体的に「特定」する必要があります。このためには事前のログ設計はもちろんのこと、障害の影響範囲の正確な調査が必要です。この特定結果に十分な正確性と自信がないと、補填実行後に押し寄せる「自分も補填対象のはずだ！」「被害金額より少ないぞ！補填が足りない！」といった問い合わせに右往左往してしまいます。ユーザーの勘違いであればよいものの、実際に「特定」の考慮漏れがあったりしたら最悪です。

次に、ユーザーごとに特定した不利益をユーザー個別で「回復」する必要があります。この「回復」はミスの温床です。そもそもユーザーに何かを付与し直したりデータを巻き戻すような都合のよい開発機能は存在しないか普段使わないでしょう。また、定常的に発生するオペレーションではないので、どうしても正確性の担保は難しくなります。万が一、補填の対象と「回復」の実行結果がズレていたりすると、全てのユーザー状態がめちゃくちゃになってしまい復旧不可能になります。

「補填」でミスをすると、ユーザーの感情を逆撫でしてしまいます。ユーザーからしてみれば、そもそもサービス運営者の落ち度で不利益を被っているわけですから、さらに追い打ちでアフターケアまで間違っていたら「本当に反省してるのか？」という怒りが生まれるのは至極当然のことです。

[1-3] 「補填」は運営の責任

「補填」はとても大変ですが、あなたはサービス運営者として逃げずに「補填」をやり切らなければいけません。なぜなら、障害を起こしたのはあなただからです。サービス運営者の苦労はユーザーには1ミリも関係ありません。サービス運営者にはユーザーに対する責任があります。

考えてみてください。もし、あなた自身がユーザーとして、 "ATMから現金が引き出せずに残高だけ減る" ような事態に直面したら、当惑と怒りで問題が解決するまでは何も手につかなくなることでしょう。そんな時に「対象者が多くて被害金額の特定が大変なので補填はできません」などと開き直る運営者を許せるはずがありません。

「補填」が嫌ならはじめから障害を起こさなければいいのです。補填の苦難を心の底から体験した人は、サービス障害を憎むようになります。「再発防止策」の欄に書かれた「注意を徹底する」という文言に仄かな怒りを覚えるようになれば、あなたはプロダクト運営者としてひとつ成長したと言えます。

[1-4] 「補填」は十分"以上"に

TIPSとして、「補填」はややユーザーの利益側に倒すとよいです。「必要かつ十分に」ではなく、「必要かつ十分 "以上" に」です。

というのも、先述のように「補填」には少しでも漏れや不足があるとユーザーの感情を逆撫でしてしまいます。ここで不足が生じるくらいなら、安全側に倒して手厚くしよう、という発想です。

例えば、障害発生時刻を「20時00分05秒 〜 20時30分17秒」とログ特定できたケースでは、補填対象は少しだけ広げて「20時00分00秒 〜 20時31分00秒」とする、といったイメージです。ユーザーへのアナウンスにおいても障害の対象を「20時00分〜 20時31分」と端数を丸めてしまいます。厳密に秒単位で見ると本来は障害の対象外であるユーザーにも補填が発動してしまっているのかもしれませんが、それは利益側なので、わかりやすさを優先して良しとしよう、ということです。

「判断に迷ったらユーザーの利益側に倒す」というのは障害対応時の鉄則です。

[2] 「お詫び」 の整理

次に「お詫び」を整理します。「お詫び」は「補填」と似て非なるものです。

[2-1] 「お詫び」とは何か

「お詫び」とは、全ユーザーに対して均一に利益を提供する行為です。前述の「補填」がユーザーを個別で捉えていたのに対して、「お詫び」では全ユーザーを同じ状態として扱います。

[2-2] 「お詫び」は不誠実

「お詫び」は怠惰で不誠実な対応です。なぜなら、ユーザーの被った不利益に対する根本的な回復になり得ないからです。

先程のATM障害の例で言うと、「Aさんは10万円、Bさんは3万円、Cさんは1万円消失している」という状況において、「口座を持っている全員に500円分のクオカードを郵送する」といった行為が「お詫び」です。「お詫び」ではユーザーの不利益それ自体に対して直接的な解決になっていない、ということがわかるでしょう。

いわば「お詫び」は、ユーザーが被った不利益とは直接関係のない利益を一律で供与することで、有耶無耶にして場を収めようとする行為です。

したがって、障害発生時に「お詫び」はMUSTのものではありません。

[2-3] 「お詫び」が乱用されてしまう理由

この不誠実な「お詫び」がよく使われてしまう理由は、運 営者にとってラクだからです。「ユーザーごとの不利益の具体的な "特定"」と「ユーザーごとに生じた不利益の個別 "回復" 」という本来必要で手間のかかる2ステップを省略してしまうわけなので。

また、障害の性質としてユーザーごとの不利益を特定しようがなく、「お詫び」しか選択肢がない、というケースもあります。ユーザーに対して、文字通り「取り返しがつかないこと」をしてしまったわけです。下記に例を挙げます。

[2-4] 「お詫び」の代償

「お詫び」を実行すると、ロイヤルユーザーがサービスから離れてしまいます。構造的に、「お詫び」ではロイヤルユーザーであればあるほど、自分の被った不利益に対する回復の程度が小さいと感じるからです。

一般に、サービスに対するロイヤルティが高く熱心に利用してくれているロイヤルユーザーの方が、同じ障害における不利益のダメージは他のユーザーよりも大きくなります。例えばサービスが一時ダウンしてしまった時、休眠ユーザーはノーダメージで済むのに対して、ロイヤルユーザーは「普段通り熱量高く利用できていたら得られていたであろう体験」が損なわれるという不利益を被ることになります。

「お詫び」はそうした状況下で全ユーザーに一律で利益供与をするわけですから、被害の大きかったロイヤルユーザーにとっては不利益の回復度合が相対的に小さくなります。

さらに、不利益を被っていないはずのユーザー（例：障害発生時にアクセスすらしていなかったユーザー）にも一律の利益供与が行われてしまうので、それを横目に見ると不公平感がさらに高まります。

ロイヤルユーザーにとっての「お詫び」は、自分の被った不利益に対して正当に賠償がされず、一方で自分より日頃の貢献度が低い人たちがフリーライドで利益を享受している姿を目にする体験です。そんな不公平で不誠実な体験を押しつけられてしまっては、サービスから離れるのも当然です。

[3] まとめ：「補填」と「お詫び」の思考法

[3-1] 「補填」と「お詫び」の整理

ここまでに説明した「補填」と「お詫び」の違いを整理します。

この整理から、「良い補填」と「悪い補填」の違いが分かるはずです。

[3-2] 「良い補填」とは

良い補填とは、「補填」を実行した上で、さらに追加で「お詫び」を実行するものです。つまり「各ユーザーが被った不利益を個別で必要かつ十分以上に回復」した後で、「全ユーザーに対して均一に利益を提供」するもの。

これにより、障害発生前と比べて、全てのユーザーの利益がフェアな形でポジティブ側に傾くことになります。ユーザーがサービス運営者に対して感謝やロイヤルティを発生してくれる可能性すら出てきます。ピンチがチャンスになり得ます。

[3-3] 「悪い補填」とは

一方で、悪い補填とは、「補填」のプロセスを実行せず、「お詫び」のみを実行するものです。つまり、ユーザーが被った不利益を具体的に特定することも回復することもせず、「一律で利益供与」することによって有耶無耶にして場を収めようとするものです。

これでは、障害発生前と比べて、ユーザー間でユーザー体験が不公平になってしまい、特にロイヤルユーザーである程に不利益が大きくなってしまいます。ユーザーがサービス運営者に対して怒り・嫌気を持つ可能性が高まります。ピンチがそのまま致命的な問題になり得ます。

[3-4] プロダクト運営者としてあるべき姿

プロダクト運営者としては、障害発生時には第一に「補填」を実行しましょう。ユーザーに対して発生させてしまった不利益を回復する責任があります。

その上で、「お詫び」を上乗せするかどうかを、事業やユーザーへの影響を踏まえて判断してください。あくまで「お詫び」は付帯的・補助的なものであり、ユーザーに対して発生させてしまった不利益を根本解決できるものではないことに留意してください。

最後に、本記事で述べた「補填」は、あくまで障害という運営の不手際を償う行為であり、そもそも障害を起こさないことこそが最も「良い」運営です。「補填」と「お詫び」は知識として持ちつつも、発動しないで済むような開発をしましょう。

[重大発表] 後日、ProductZineにて記事化予定！

本記事の内容は後日、プロダクトマネージャー向けメディア「ProductZine」さんにて寄稿記事化することが決まっています。（まだnoteに投稿していない段階だったのに、メディアの方のコンテンツに対する嗅覚はすごいですね）

その際には内容を掘り下げて補強する予定なので、この記事に対してのご質問・ご意見・リクエストがありましたらお気軽に御守（X / twitter @OnMorik）までご連絡ください！ 今後も読者の方のお役に立つ記事を書いていきたいので、モチベーションのためにも感想をいただけるとうれしいです！

それではみなさん、良いプロダクト運営を！