AIの仕組みを納品したあと、止まった仕事を誰が戻すのか

A&Aの考え方

この記事は、毎日や毎週の処理を外部へ依頼する経営者に向けています。納品時に動いたかの検証手順ではなく、翌月も仕事を続けるために誰が何を引き受けるかが焦点です。A&Aの提案は、実行する場所、異常を受け取る人、復旧する人、未処理分を判断する人を、発注時点で分けて書くことです。一人が兼ねる場合でも、役割は省略しません。

A&Aの考え方

例えば開発会社が仕組みを直す契約でも、遅れた社内資料を今日は使うか、担当者が手作業で代替するかは、社内の判断になることがあります。技術的に復旧すれば業務も片付く、とは置かず、残った仕事をどこへ渡すかまで確認します。新しい運用担当を必ず雇う話ではなく、現在の担当者へ何が残るかを見えるようにするための整理です。

A&Aの考え方

本稿の設計では、エラー通知に加えて、予定時刻までに必要な成果物がない状態を確認する案です。処理が始まらなければ、処理の中からエラーが出るとも限りません。朝の資料なら、どの時刻を過ぎると誰が困るかを先に聞き、その前に気付ける確認を置きます。通知が来た人に、対象業務、遅れた期間、次に取る行動が分かる内容を渡します。

A&Aの考え方

通知を増やすだけでは対応の負担が増えるため、今すぐ止める状態、当日中に確認する状態、後で傾向を見る状態を分ける案です。担当者が休む日の代わりの受け取り手も必要です。夜間まで対応するか、翌営業日でよいかは、その業務の期限と契約範囲で決めます。常時稼働する仕組みだからといって、人の常時対応まで無条件に含めません。

A&Aの考え方

委託範囲には、状況確認、再実行、設定の修正、外部サービスへの確認、データの補正を分けて書くことを勧めます。再実行してよい処理と、重複した案内や取引を生むため確認が必要な処理も分けます。原因が外部側なら、担当者が直せない時間が残ります。その場合に誰が状況を追い、社内へ知らせ、代替方法を決めるかまでを運用の範囲として確認します。

A&Aの考え方

復旧時間を話すときは、通知が届くまで、担当が着手するまで、処理が戻るまでを分けます。「すぐ対応します」という説明だけでは、どの時間の約束かが分かりません。実際に保証する時間を設定する場合は、対象時間帯と例外を含めて契約で確認します。本稿の例に、特定時間での復旧保証や、既存サービスへの追加の対応義務は含めません。

A&Aの考え方

保守の負担は、障害対応だけではありません。外部サービスの変更確認、入力項目の追加、利用量の確認、担当交代に伴う権限の整理なども、対象に含むかを決める案です。月額費用という一行だけでなく、含む作業と別途判断する作業を並べます。相談中心の契約と実作業を含む契約も分け、助言を頼んだだけで日々の監視まで依頼したことにならないようにします。

A&Aの考え方

負担を測る際は、通知を読む時間、原因を調べる時間、修正する時間、社内へ説明する時間を残す案です。何も起きない月も、定期確認をしたならその時間を記録します。利用料とこれらの作業を含めて、もともとの手作業から何が減り、何が新しく増えたかを比べます。対応件数だけで良し悪しを判断せず、一件が長引いた理由を次の改善へ使います。

A&Aの考え方

引き継ぎ資料には、動く場所、管理者、必要な権限の管理先、通常時の確認方法、止め方、再開の条件を残すことを勧めます。鍵そのものを資料へ並べるのではなく、許可された担当者が必要なアクセスを取得する手順を示す案です。開発者だけが知る個人アカウントに依存していないかも確認します。担当変更のたびに仕組みを作り直す状態を避けるためです。

A&Aの考え方

ハグルミの運用記録を、ここでは発注範囲を考える材料として整理しました。過去の障害回数や復旧時間は、確認済みの成果数値として転用していません。経営者が次に聞く問いは、「止まったら連絡は来ますか」に加えて、「そのあと残った仕事を、誰がどう片付けますか」です。その答えまで見積もりに入れば、導入後に自社へ残る負担を比較できます。