要望どおりに動いた。それだけで、業務のルールまで作れたことにするな

「申請を一覧にして、承認ボタンを付けてほしい」。その要望どおりの画面ができた。登録も検索も速く、承認を押せば表示が変わる。依頼者は満足し、来週から使いたいと言う。

けれども、ボタンの動作だけでは、誰が承認してよいか、どの証拠を見て決めるか、承認後に取り消せるか、例外をどこへ戻すかは決まらない。要望は欲しい結果を伝える。業務ルールは、その結果を正しいものとして成立させる条件を決める。

承認・取消し・例外のルールが未定義なら、要望どおりに作れた機能を、そのまま実業務の確定へつないではいけない。

要望の文を、「正しいと認める条件」へ開く

「一覧で見たい」は、現場の困りごとをよく表している。ただし、一覧に誰の案件まで表示するのか、古い情報をどう示すのか、何を正本とするのかは別に決める必要がある。「早く承認したい」も、誰が何を確認し、どの状態なら承認できるかまでは含んでいない。

要望を受けたら、五つの問いへ開く。

• 対象：どの案件、利用者、情報に適用するか
• 権限：誰が見て、入力し、確定し、取り消せるか
• 条件：何がそろったとき、その操作を正しいと認めるか
• 証跡：誰が、いつ、何を根拠に変えたと残すか
• 例外：条件を満たさないとき、どこで止め、誰が判断するか

これらは要望を難しく言い換えるためではない。画面が黙って決めてしまうルールを、業務側が先に選ぶためである。作成者が答えを知らない場合は、AIにそれらしい条件を補わせず、依頼者へ質問として返す。現在の手作業で守っている条件も記録し、今回も適用するか確認する。

業務の状態は、画面のラベルより多い

画面に「申請中」「承認済み」と表示されていても、実際の仕事には「不足資料の確認中」「差戻し」「取消し待ち」「例外判断待ち」があるかもしれない。

業務状態とは、表示名ではなく、その案件について何が成立し、次に誰が何をできるかを示す条件である。状態遷移は、ある状態から次の状態へ移す操作と、その前提である。

状態を横に並べ、状態の間の矢印へ四つを書く。操作できる役割、必要な情報、残す記録、失敗時の戻り先である。たとえば承認済みへ進むには、承認権限だけでなく必要書類がそろい、二重承認ではなく、承認者と時刻が記録されることを条件にする。取消しなら、単に表示を戻すのか、すでに行った通知や計上も訂正するのかを決める。

画面上でボタンを隠すだけで、業務ルールを守れるとは限らない。OWASPのBusiness Logic Security Cheat Sheet は、業務上守る条件を明文化し、操作の順序や状態遷移をサーバー側で検証する考え方を示す。AI固有の事故率や個別業務の正しさを示す資料ではないが、見た目とは別に業務条件を仕組みで守る根拠になる。

状態の名前を決めただけでは足りない。誰が、何を根拠に、どの記録を残して次へ進めるかまでが業務ルールである。

承認、取消し、例外を別の仕事として決める

承認は「はい」を押す機能ではなく、確認した内容に責任を持って業務を確定する判断である。代理承認を認めるか、担当変更時に誰が引き継ぐか、承認後の情報変更を許すかを決める。

取消しは、表示を前へ戻すだけでは終わらないことがある。顧客へ通知済み、会計へ連携済み、別部署が作業を開始済みなら、それぞれに訂正や連絡が必要になる。元の状態へ戻せない場合は、「取消済み」という新しい状態と、訂正履歴を残す方が業務に合うかもしれない。

必要書類が後から届く、締切後に訂正する、担当者が不在、外部連携が止まる。こうした例外をすべて「入力ミス」として差し戻すと、利用者は仕事を終えるために別の台帳を作り始めるかもしれない。自動で決められないものには「保留」の置き場所を作り、判断者、期限、手作業への戻し方、再開条件を決める。

すべてを機能化しなくてもよい。手作業で処理するなら、それを正式な業務ルールとして記録し、画面側が誤って先へ進めないようにする。

要望と業務ルールを、同じ表の別の列に置く

要望を否定せずにルールへ渡すには、一枚の表が使える。左から「要望」「守る業務ルール」「仕組みで守る箇所」「人が判断する箇所」「未定義」を置く。作成者は通常の一件と例外の一件を依頼者とたどり、答えが決まらない欄を未定義として残す。承認の範囲や業務ルールの変更は、決める権限を持つ人へ確認する。

たとえば「承認を早くする」という要望に対し、「申請者と承認者は別」「必要書類がそろうまで確定しない」というルールを書く。仕組みでは権限と必須条件を確認し、例外書類の妥当性は人が判断する。代理承認の範囲が決まっていなければ、未定義として責任者と期限を付ける。

IPAの非機能要求グレード関連資料 は、利用者から見えにくい運用、保守、復旧、移行などを要件として整理する補助になる。AI利用の効果や事故率を測る資料ではない。画面の要望を聞いた後に残る仕事を、要件から落とさないために参照できる。

この表から、確認できる文を作る。「承認者以外は確定できない」「取消しは元の承認記録を消さない」「例外は保留になり、指定担当へ届く」。試験の網羅性は別の検討だが、少なくとも何が正しい業務なのかを先に合意できる。

実業務への再開条件は、「未定義がゼロ」ではない

すべての例外を最初から決め切ることは難しい。必要なのは、重要な未定義が黙って確定処理へ流れないことだ。

実業務への利用を再開するには、対象範囲の状態と遷移、確定・取消しの権限、主要な例外の行き先、操作と判断の記録、未定義を保留にする手順をそろえる。業務責任者がその内容を確認し、利用者が元の手順へ戻れることも確かめる。

そろわない間は、申請案の作成、一覧の閲覧、担当者による確認前の下書きに限る。承認、送信、計上など後工程を動かす確定操作は行わせない。未定義が見つかったら、ルールを決めるまで保留にするか、対象外として明記する。

実業務を再開するのは、画面が要望どおりになったときではない。重要な状態・権限・例外を誰が決め、どこで止めるかを説明できたときである。

完成と報告する前に、取消しや不足が起きた一件を依頼者とたどる

要望は、作るべき価値を教えてくれる。ただし、その価値を業務で正しく使うためのルールまで自動的に含んではいない。

完成と報告する前に、普通に終わる一件と、取消しや不足が起きる一件を依頼者とたどる。「この状態なら、誰が何をしてよいか」と聞き、決まっていない条件を記録する。答えが人によって違うなら、AIに決着をつけさせず、業務の決定を担う人へ返す。先にそろえるのは画面ではなく、そのルールである。

参考資料

• OWASP Business Logic Security Cheat Sheet 
• IPA 非機能要求グレード関連資料