不具合を直したことを誰に伝えるか：通知先を「報告者」ではなく「踏んだ人」で決める

A&Aの考え方

修正が出たときの通知先は、報告してきた人ではなく、そのエラーを実際に踏んだ利用者で定義します。報告は踏んだ人の一部からしか来ないため、報告者だけに返信すると、同じ不具合で手が止まったまま黙って離れた利用者には何も届きません。そして解決したかどうかは、通知した利用者が同じ操作をもう一度実行して成功したかという一つの記録で確かめます。判定に使う材料も入れ替わります。問い合わせの一覧ではなく、エラーの発生記録と、その後にその利用者が何をしたかの記録です。

A&Aの考え方

この定義で運用するには、三つを事前に決めておく必要があります。一つ、通知の起動点を問い合わせ側ではなく修正が出た側、つまりコードのマージ側に置くこと。二つ、通知する条件と通知しない条件を同じ一枚に書くこと。三つ、「直った」と「解決した」を分け、解決の確認を通知とは別の工程として持つこと。この三つを決めずに通知だけを増やすと、必要な人には届かないまま、困っていない人への接触が増えます。

A&Aの考え方

先にこの記事の成果物の形を言っておきます。通知文の雛形ではありません。「踏んだ利用者がエラーの後に何をしたか」で行を分け、各行に通知するかしないかと、その判定に使う記録を書いた一枚の表です。通知文は条件が決まってから書けば足ります。順番を逆にすると、文面の調整に時間を使ったのに送る相手が決まらない、という状態になります。

A&Aの考え方

一人で開発と運用を兼ねていると、サポートの改善はまず受付に向かいます。問い合わせが届いた時点で契約プランと直前の操作とエラーを自動で添える、といった工程です。これは効きます。受付側の設計そのものは「一人AI SaaSのサポート自動化：返信文より先に、失敗を再現できる文脈を添える」で扱っており、本記事はその後工程にあたります。ただし受付をどれだけ整えても、届く問い合わせの数は増えません。受付の改善は、来た分の処理を速くする改善です。黙っている側には触れていません。

A&Aの考え方

人が扱うのは、そこから人まで到達した分だけだと読めます。ただしこれは Decagon の顧客の利用者についての記述で、人が扱う側について同ページが述べているわけではなく、あなたの製品で何割が黙っているかを示すものでもありません。それでも読み取れることが一つあります。人が目にする問い合わせは、起きたことの全部ではなく、人まで到達した分だけだということです。報告は、困ったことに加えて「報告する手間を払う気がある」という条件を通過した出来事だけが届きます。手間を払わない側の選択は、黙って使うのをやめることです。

A&Aの考え方

だから解決後の工程を設計するとき、最初に置く問いは「返信文をどう速くするか」ではありません。「この修正が関係する利用者は誰か」です。この問いに答えられる記録を持っていない場合、通知の仕組みを作っても送る相手がチケットの一覧しか出てこないため、結局は報告者だけに返信する運用へ戻ります。

A&Aの考え方

この三分割は、小さな会社にとっては人員の話ではなく起動点の話として読む価値があります。三つを一つの「対応が終わったあとの作業」として扱うと、起動点が「自分が思い出したとき」に統一されます。忙しい日はどれも動きません。分けておけば、動かなかった工程がどれなのかが後から分かります。二人で回している側が三つに分けている理由も、人数ではなく起動点の違いの方にあると読めます。

A&Aの考え方

なお Gumloop の記事は、通知先を報告者ではなく踏んだ人で決めるべきだとは述べていません。マージを契機に「その人の問題に関係する修正が出た」と知らせる、と書いてあるだけです。報告者から踏んだ人へ対象を広げる読み替えはA&Aの提案であり、出典の主張ではありません。

A&Aの考え方

起動点を問い合わせ側に置くと、通知できる相手はチケットを持っている人に限られます。チケットは報告者にしかありません。この制約は運用の努力では外れません。通知できる対象の集合が、起動点によって先に決まってしまうからです。

A&Aの考え方

起動点を修正が出た側へ移すと、対象の集合は「その修正が直したエラーを踏んだ人」に変わります。チケットの有無は条件から外れます。実装の話をする前に、この入れ替えが設計の本体です。

A&Aの考え方

実務では、修正と対象を結ぶ一語が必要になります。手で運用するなら、修正をマージするときの説明文に、直したエラーの識別子を必ず書く、という規則で足ります。識別子はエラーコード、例外の種類、失敗した処理の名前のいずれか一つでかまいません。これがないと、通知の仕組みを作っても「この修正はどのエラーを直したのか」を毎回人が思い出す工程が残ります。

A&Aの考え方

一人で運用している規模なら、ここは自動化より先に規則化です。マージの説明文に識別子を書く、という一行の決めごとが、後から通知を自動化するときの接続点になります。逆に、識別子を書かないまま通知の自動化へ進むと、紐づけの推測を機械にやらせることになり、誤った相手へ送る経路を自分で作ることになります。

A&Aの考え方

ここが本記事の前提条件にあたります。エラーの記録に利用者を特定できる情報が入っていなければ、通知対象を「踏んだ人」で定義できません。だから通知の設計に入る前に確かめることは一点だけです。直近のエラー記録を一つ開いて、そこから利用者を特定できるか。できなければ、最初の作業は通知ではなく、この紐づけを作ることです。

A&Aの考え方

紐づけを作るときの範囲は、顧客との取り決めの範囲内に限ります。通知のために記録を増やす判断は、預かるデータの範囲を広げる判断と同じものです。本記事はその範囲を広げる提案はしません。すでに持っている記録から特定できるかどうかを先に確かめる、という順序だけを提案します。

A&Aの考え方

通知条件だけを書いた表は、運用すると接触が増え続けます。踏んだが困っていない利用者、すでに自力で回避した利用者、直近に別の通知を受けた利用者に、同じ基準で送ってしまうからです。通知の頻度は、それ自体が解約の理由になりえます。だから停止条件を別の文書に置かず、同じ表の同じ行に書きます。

A&Aの考え方

行を分ける軸は、エラーの重大さではありません。エラーを踏んだあとに、その利用者が何をしたかです。踏んだ直後に同じ操作を続けた人と、その操作だけをやめた人と、ログインが途切れた人では、修正の知らせの意味がまったく違います。そしてこの軸は、意見ではなく記録から判定できます。重大さで分けると判定が毎回主観に戻るのに対して、行動で分ければ同じ記録から同じ行が出ます。

A&Aの考え方

下の表はA&Aの設計案です。行の切り方も、頻度の上限も、確認までの期間も、どちらの出典にも書かれていません。表の最終行は、紐づけがない場合にここで止まるという意味で置いています。

A&Aの考え方

使い方は、修正をマージした直後に、まず下の三行（停止条件）を確かめ、どれにも当たらないときだけ上から順に該当する行を決めることです。先頭から読んで最初に当たった行で止めると、直近に二回通知した相手にもう一度送ることになり、この節が防ごうとしている過剰接触を自分で作ります。該当する行が決まれば、通知するかどうかと、その判定に使う記録が同時に決まります。判断を毎回ゼロから組み立てないことが目的なので、行を増やすよりも、各行の判定に使う記録が実際に手元にあるかを確かめる方が先です。手元にない行は、通知の条件ではなく、作る必要のある記録の一覧として読みます。

A&Aの考え方

この見方を修正の通知に当てはめると、「不具合を修正しました」という一文は説明の側に属します。利用者の側で止まっているのは作業であって、理解ではありません。完了の側に寄せるなら、通知には止まっていた作業を再開する一手が入ります。どの画面で、どの操作をやり直せばよいか。再試行が自動で済んでいるなら、済んでいるという事実が入ります。

A&Aの考え方

これは文面を丁寧にする話ではなく、短くする話です。原因の説明、再発防止の方針、謝罪の分量は、通知の目的に対しては余分です。載せるのは、踏んだ操作の名前と、そこから再開する一手の二つだけ。この二つが入っていない通知は、受け取った側に「で、何をすればいいのか」という判断を残すため、もう一度手間を要求していることになります。

A&Aの考え方

解決の確認は、この通知とは別の工程です。通知を送ったことは、解決したことの証拠になりません。Gumloop が効果確認を日次の独立した工程として持っているのも、送った事実と直った事実が別だからだと読めます。一人で運用する規模なら、確認の合図は調査票ではなく記録で足ります。通知した利用者が、その後に同じ操作をもう一度実行して成功したかどうか。これを一つ決めておけば、確認が毎回の手作業の問い合わせにならずに済みます。

A&Aの考え方

架空例に数値目標を置かなかったのは意図的です。この設計が直接変えるのは、修正が届く利用者の範囲と、解決を確認できた件数だけです。解約率や継続率がどう動くかは、この表からは出てきません。

A&Aの考え方

限界を四つ書きます。一つ、両方の出典は発行元自身による自社の説明であり、独立した監査ではありません。Gumloop の記事は同社の運用の記述であり、Decagon のページは同社製品の設計思想です。どちらも小規模事業での再現性を示していません。両ページに表示されている数値も、母数や定義が示されていないため本記事では採用していません。

A&Aの考え方

二つ、どちらのページも「通知先を報告者ではなく踏んだ人で決めよ」とは述べていません。その判定軸と、停止条件を同じ表に書くという設計はA&Aの提案です。三つ、Gumloop の仕組みは、エラー・利用者・マージ履歴が既に紐づいている前提で動きます。紐づけがない製品では、本記事の前提確認の節が最初の作業になります。

A&Aの考え方

四つ、この記事は効果を測っていません。A&Aはこの設計と解約率・継続率・売上の関係を測定しておらず、通知を広げれば離脱が減るという予測も示しません。通知の頻度が過剰になれば逆に働くことは設計上あらかじめ想定しており、だから停止条件を同じ表に置いています。

A&Aの考え方

今日できる一歩は一つです。直近のエラー記録を一つ開いて、そこから利用者を特定できるかを確かめること。特定できるなら、次のマージの説明文に直したエラーの識別子を書くところから始まります。特定できないなら、通知の設計より先に、その紐づけを作る作業が待っています。どちらであっても、記憶に頼る運用から記録に頼る運用へ移る入口は同じ場所にあります。