業務システムが途中で止まったら？戻せない通知と未完了を分ける例外処理

エラー表示と、途中で残った仕事を分ける

例外処理とは、通常の流れから外れたときに、システムと担当者が何をするかを決めることです。エラーメッセージを出すだけでは、社内の票、部品の手配、外部への連絡がどう残ったかまでは説明できません。画面で処理が止まったように見えても、別の工程が先に進んでいる場合があります。

この仕事の「受付完了」「手配完了」「顧客対応完了」は、同じ意味ではありません。受付連絡が単に依頼を受け付けた案内なのか、訪問や部品の確保まで約束する文面なのかも、実際の原文で確認します。送信済みという値から、顧客へ約束した範囲や契約上の効果を補いません。

処理を戻すことにも違いがあります。データの更新を取り消すこと、別の手配で仕事を続けること、誤った案内を訂正することは、それぞれ別の作業です。MicrosoftのCompensating Transaction patternでも、補正は業務ごとの判断を必要とし、単純に最初の状態へ戻るとは限らないと説明されています。これは分散システムの設計指針で、この会社の方式や採用製品を決めるものではありません。

一回の送信結果を調べて再送する話は、システム連携のエラーで再送前に確認することへ分けています。ここでは、すでに残った社内作業と外向きの連絡を含めて、業務としてどの状態へ進めるかを考えます。

送信済みと結果不明を、同じ項目で比べる

送信記録がある依頼では、受付連絡は送信済み、部品手配は未完了です。もう一つの依頼は、送信も部品手配も結果が未確認です。この違いから、次に調べる対象を読み分けます。二つを、失敗した依頼と修正後の依頼としてつなぎません。

送信記録がある依頼では、通知を送った事実を消して全体を未処理に戻すと、残った記録や顧客への説明が合わなくなります。まず未完了の部品手配を調べ、顧客に追加連絡が必要かを業務責任者へ相談します。部品がない、提供側に障害がある、といった原因はまだ決められません。

結果不明の別依頼では、通知を送っていないとは言えません。社内作業票との対応、送信側の履歴、利用している連絡手段で確認できる結果を調べます。確認できないまま同じ案内を送り直すかどうかを、担当者の感覚だけで決めないようにします。

同じ修理依頼の記録を、工程ごとに照合する

調査では、まずどの修理依頼の話かをそろえます。依頼を区別する情報と、作業票・部品手配・連絡記録の対応を確かめ、別の依頼や別の試行の結果を混ぜないことが大切です。実際にどの番号や版を使うかは、開発先と現場で確認します。

社内作業票：保存された内容と、次に進める条件

票が保存されているかに加え、どの修理内容が残り、後から変更されたか、担当者が保留を見分けられるかを調べます。票の存在だけで、部品が手配済みになったり、訪問できる状態になったりするわけではありません。

部品手配：未完了と、結果を調べられていない状態

手配先、対象の部品、今回の依頼との対応、完了の根拠を確かめます。未完了と確認できる場合でも、どこまで進んだかは別に調べます。結果そのものが不明なら、同じ手配を重ねる前に、手配側で確認できる記録と照会先を開発先へ尋ねます。

受付連絡：送信要求・送信記録・顧客の受領を分ける

送信を頼んだ記録、送信処理の結果、相手が受け取ったと確認できる情報は別です。どこまで確認できるかは、採用する製品や仕組みで異なります。今回の送信記録だけから到達や既読を確定せず、分からない段階を残したまま相談します。

毎朝のファイルをどの段階から再実行するかは、毎朝のファイル連携の設計で扱います。また、複数の受信先へ出来事を伝える方式そのものは、注文のイベント連携で扱います。本稿では、その方式の採用を前提にせず、一件の修理依頼が途中まで進んだ後の判断へ絞ります。

戻す・別の方法で進める・保留する条件を決める

記録がそろったら、開発先へ実現できる操作を尋ね、業務側が顧客への影響を含めて選びます。「自動で元へ戻す」という一言で、次の三つをまとめないことが必要です。

取り消せる作業だけを、影響を確かめて戻す

保存済みの票を削除・取消できるか、取り消してよい段階か、後続の担当がすでに使っていないかを確認します。技術的に削除できることと、業務上消してよいことは別です。元の記録と取消の関係が追えるようにするかも、実際の仕組みに合わせて決めます。

この架空例では、送信した通知を「送らなかった」状態には戻せない前提です。 ただし、顧客が受け取った、読んだという実結果は未確認です。取消機能の有無を全製品へ一般化せず、必要な訂正や追加の説明を別の対外行為として判断します。

元に戻す代わりに、別の方法で仕事を続ける

部品手配が未完了なら、手配側へ状況を確認し、別の手配を検討することも候補です。ただし、この例で別手配が可能と確認されたわけではありません。既存の手配と重ならないか、日程や顧客への案内が変わるか、誰の了承が必要かを確かめてから選びます。

対応を続けた後も、何が変更され、何がまだ未確認かを残します。代替案を用意したことを、部品確保や修理完了の証拠にはしません。

根拠や権限が足りないときは、状態を保って人へ渡す

送信や手配の結果が分からない、取消の影響を判断できない、決定する人が未定、といった場合は保留が候補になります。保留は、記録を消して放置することではありません。対象、分かっている状態、照会先、次に判断する条件を残し、担当者が受け取れるようにします。

補正や再実行そのものが途中で止まる場合もあります。Microsoftの同指針は、補正の進み具合を追える情報や、人への通知が必要になる場合も扱っています。実際にどこから再開できるかは、この会社の実装と権限を確かめて決めます。

図で、連絡と部品手配の違いを読む

図では、社内作業票・受付連絡・部品手配を同じ修理依頼へ結び付けます。送信記録がある依頼と、通知結果が未確認の別依頼で、連絡と手配のどこが違うかを見てください。図の二例を改善前後として読まず、顧客受領や解決を示す印としても扱いません。

解説図を原寸で見る

図から判断すること：送信記録がある依頼は、部品手配の状況と、その後の顧客対応を調べます。結果不明の別依頼は、送信の結果と部品手配の状況を照会してから、次の操作を決めます。どちらも、作業票が保存されているだけで全体を完了にしません。

図を読んだ後の最初の行動：受付担当から、調べたい修理依頼と記録の所在を、部品を扱う担当・連絡手段を管理する担当へ渡します。業務責任者とは、保留、別手配、追加連絡を選ぶために必要な事実と決定する人をそろえます。図だけで本番を再送・取消する手順にはしません。

開発先へ、状態・権限・引継ぎを尋ねる

見積依頼や仕様の読み合わせでは、機能名だけでなく、この修理依頼が途中で止まったときに担当者が何を説明できるかを尋ねます。次の問いは、今回の仕事に合わせて具体化するための候補です。

結果不明を、何で確かめるか

「同じ依頼の票・手配・連絡を、どの情報で照合できますか。結果を確認できない場合は、どの担当へ何を渡しますか」と尋ねます。画面の表示だけでなく、相手側で確認できる範囲や、記録が取れない場合の保留も説明してもらいます。

この例では、部品の状況を証明できる既存記録と、結果確認なしで通知を繰り返せるかは未確認です。先に再送方法だけを決めず、何を根拠に選べるかを開発先へ確認します。

誰が、どこまで操作・判断できるか

「受付担当は保留を登録できるか、部品手配をやり直す権限は誰が持つか、顧客向けの訂正内容を誰が決めるか」を読み合わせます。開発先の操作説明だけで、会社内の了承や対外連絡の判断者が決まるわけではありません。

保留を決められる人と、顧客向け訂正を了承する人は、この例では未確認です。業務責任者が社内の役割を確認し、開発先には、その役割に必要な閲覧・操作・記録をどう用意するかを尋ねます。

自動対応が止まった後を、誰が受け取るか

「どの条件なら再試行し、どこで打ち切り、担当者へ何を知らせますか。手動対応中に自動処理が再び走るときは、重複や競合をどう扱いますか」と尋ねます。単にエラー通知が届くことだけでなく、対象を見つけて次を決められる内容かを確かめます。

自動再試行を許可する条件は未確認です。MicrosoftのRetry patternでは、要求の処理が済んでも返事が失われる場合や、再試行で副作用が重なる場合を扱っています。回数や間隔を一律に決めず、今回の業務と提供側の仕様に合わせて回答を求めます。

回答で今回の範囲と判断する人を更新する

回答を得たら、対象の修理依頼、各工程の完了の意味、結果を照会する方法、保留・取消・別手配・追加連絡の条件、判断する役割をそろえます。既存の記録で足りる部分と、新しく実装や運用手順が必要な部分を分け、今回どこまでを頼むかを読み合わせます。

「自動で回復できる」という回答なら、どの状態から何を行い、何をもって終えるかまで尋ねます。取り消せない連絡や、顧客判断が必要な範囲まで含まれるとは限りません。「人が対応する」という回答なら、誰が対象を受け取り、どの記録を見て、何を決めるかを具体化します。

回答がない条件は、そのまま未確定として残します。見積もりや画面案に名前が載っただけで合意済みにせず、誰が確認するかと、決まるまで保留する作業を示します。実現できない条件があれば、業務の順番や通知する時点、今回の範囲を見直す材料にします。

送信した案内を後から訂正する案と、通知の前に手配の状態を確かめる案は、影響する仕事も異なります。仕組みだけでなく、顧客に何を伝える業務なのかを業務責任者と確認して、採用する条件を更新してください。

途中停止後に何が残るかを試験で確かめる

仕様の説明がそろったことと、実際の動作が期待どおりだったことは別です。ここでは試験の組み立て方を示します。実施場所、利用できるデータ、外部連絡を止める方法や許可、戻し方を担当者と決め、実顧客へ通知を送る前提で試さないようにします。

1. 一件の初期状態と期待を決める。票・部品手配・連絡のどこまで済んだ条件を使うか、途中停止後に何を保存・保留・通知するかを合わせます。業務上、保留が正しい場合は、それを期待結果にします。
2. 止まった位置だけでなく、前後に残る状態を見る。票、手配側、連絡側の記録を同じ依頼へ結び、期待と実際を比べます。画面のエラー表示だけを、全工程が戻った証拠にしません。
3. 結果が分からない条件を選んで確かめる。今回の仕様に必要なら、処理の結果と返事を区別できる条件や、手動対応と自動処理が重なる条件を用意します。二重の手配・連絡をどう防ぎ、照会や保留へ渡すかを確認します。ここで一律の試行回数を指定しません。
4. 人が引き継げる所まで確認する。通知を受けた担当者が対象と未完了・未確認を見つけ、決めた権限で次の判断へ進めるかを確かめます。通知先へ送れたことだけで対応完了にしません。
5. 違いを対象・条件・結果で返す。どの工程の何が期待と違うかを伝え、原因や修正内容は調べてから残します。修正後は影響する状態と操作を同じ前提で確かめ、説明だけで合格へ変えません。

実際の試験結果は未確認です。 この架空例の送信済みや手配未完了は、納品試験を行った記録ではありません。試していない製品動作、再開成功、性能や顧客対応の結果を加えません。

保留した仕事を、次の担当へ渡す

運用へ渡すときは、「障害が起きたら開発先へ連絡」だけで終えず、受付担当がどの状態を見つけ、何を照会し、誰の判断を待つかまで読み合わせます。対象の依頼、確認した記録、未確認の結果、連絡先、次に判断する条件が対応していることが大切です。

顧客向けに追加連絡をするなら、元の案内との関係と、どの内容を誰が確認するかを決めます。送信後も受領の確認が必要かは業務によります。確認していない受領・了承や、部品手配の完了まで一つの「対応済み」にまとめません。

保留が増えたり、同じ例外が繰り返されたりしたら、調べられる記録、通知の時点、判断者、手動で扱う範囲を見直します。運用の変更は仕様と確認条件にも戻し、前の試験結果を新しい条件の合格として流用しないようにします。

まとめ：一件の途中状態と、次を決める人から始める

例外処理を頼むときは、エラー表示だけでなく、途中まで進んだ仕事がどう残り、誰が何を根拠に次を選べるかを決めます。社内作業票、部品手配、顧客への受付連絡を分け、送信済み・未完了・結果不明を同じ意味にしないことが出発点です。

戻せる作業、別の方法で続ける作業、責任者へ保留して渡す作業を、実際の仕組みと業務上の判断に合わせます。開発先の回答で範囲と役割を更新し、試験では一件の期待状態と実結果を照合してください。

最初の一歩：受付の仕事を一件選び、票・手配・連絡のどこまで確認できるかを担当者と並べます。分からない所を埋めず、次に調べる記録と、保留や顧客対応を決める人をIT発注担当から開発先へ確認します。