現行業務をAIに説明して、改善案とRFP項目まで作る
手順書の無い月次業務を、聞き取り→工程分解→To-Be→システム要件→RFP項目の順に整理する方法です。現行業務の事実、残す工程の判断、ベンダー選定は人が行います。
1. Before ― 手元はどうなっているか
架空のITコンサル企業、オリオンテクノロジーズ株式会社。月次の売上計上は、こういう流れになっています。
Excel（営業各部から） → 手作業で加工 → CSV → 会計システムに取込 → エラーが出た行を修正
担当は3名。状況はこうです。
- 手順書が無い。3人がそれぞれのやり方で回している。誰が担当した月かで、出来上がりが微妙に違う。
- エラーが毎月出るが、記録が残っていない。誰がどう直したかは、直した本人の記憶の中にしかない。
- 何のためにやっているか説明できない工程がある。前任者から引き継いだチェック作業が2つあり、なぜ必要なのかを誰も知らない。ただ、やめる判断もできない。
- システム更改の話が出ている。部長から「要件をまとめておいて」と言われたが、要件の書き方が分からない。
2. 問題の分解 ― 何を整えれば進むのか
順番を守ることが大事な作業です。飛ばすと、あとで全部やり直しになります。
- いまの業務を書き出す（事実）
- 工程を種類で分ける … 手作業／重複／判断が必要／システム化できる／統制上残すべき／エラーが出る場所
- 課題を整理する
- To-Be を描く
- システム要件に翻訳する
- RFPの項目にする
1が粗いと、4も6も粗くなります。いきなりTo-Beから始めません。
現行業務の事実そのもの。AIは貴社の業務を知らないので、書き出すのは人がやります。ただし「書き出すための質問項目」はAIに作らせられます。また、業務をどう変えるかの決定と、どのベンダーを選ぶかの判断も人です。AIは選定基準の案を作るところまでで、ベンダーの製品仕様はAIに聞かず、ベンダーの資料で確認します。
3. AIに任せること／人が判断すること
- 現行業務を書き出すための聞き取り項目の設計
- 書き出した業務の工程分解
- 重複している作業、手戻りが起きている箇所の指摘
- 統制上の論点の指摘
- To-Be案を複数出させる
- 業務の言葉を、システム要件の言葉に翻訳させる
- RFP項目のたたき台と、ベンダーへの質問案
- 現行業務の事実（何をしているか）
- どの工程を残し、どれをやめるか
- 統制上、人が残るべき工程の判断
- 投資判断とベンダー選定
- 部内・関係部署との合意
4. 実行 ― AIとのやりとり
順番 ― いきなり説明しない
先に、AIに聞き取りの質問を作らせます。自分で説明を始めると、書きやすいところだけ書いて、抜けたところが最後まで抜けたままになります。
往復1回目 ― AIが理想論のTo-Beを出した
（書き出した業務を渡したあと）「RPAとAI-OCRを導入し、取込から計上までを全自動化することで、月次決算を3日短縮できます。承認も含めてワークフロー化することで、さらに効率が上がります。」
3つあります。①「3日短縮」の根拠が無い。こちらは所要時間を渡していません。②承認まで自動化に含めている。統制上、人が承認すべき工程があります。③どの工程が自動化できるかを判断する材料を渡していないのに、全自動化と言い切っています。
「効果の数値は書かないでください。工程ごとに『自動化できる／人が残る／判断が必要』の3つに分け、人が残る工程にはその理由も書いてください。承認と最終確認は人が行う前提です。」
工程表になりました。承認と例外判断が「人が残る」に分類され、理由として「金額の妥当性を人が確認しないと、誤った計上がそのまま通るため」と書かれました。
「自動化できる」に分類された工程を、1つずつ本当にそうか確認します。特に、判断していないように見えて実は毎月判断している工程（「この得意先は例外扱い」といった暗黙の処理）を、「判断が必要」に戻します。ここを見落とすと、システム化してから問題になります。
往復2回目 ― RFP項目が一般的すぎた
「機能要件：仕訳入力機能を有すること／帳票出力機能を有すること／マスタ管理機能を有すること」
どのベンダーもYESと答えられる項目ばかりで、比較になりません。RFPは「できますか」を聞く場ではなく、「どうやってできるのか」を説明させる場です。
「どのベンダーもYESと答えられる項目は削ってください。代わりに、当社の困りごと（毎月フォーマットが変わるExcelの取込、エラー行の特定、取込のやり直し）に対して、どう実現するかを具体的に説明させる質問にしてください。」
「毎月フォーマットが変わる外部データの取込について、①取込の項目対応（マッピング）を利用部門が自分で変更できるか、できる場合はどの画面で行うか ②取込エラーが出た行と、その理由をどのように表示するか ③取込をやり直した場合に、二重計上を防ぐ仕組みを説明してください」という形になりました。
質問に、自社の実際の件数と頻度を入れます（「月あたり約1,200件、3部門から」など）。規模が書かれていない質問には、ベンダーも一般論でしか答えられません。
5. エラーと例外 ― うまくいかないとき
- AIが、知らないはずの業務を知っているように書く … 「当社の業務について、私が説明していないことは書かないでください」を毎回入れます。それでも書いてきたら、その部分は削って渡し直します。
- 書き出しが粗いと、To-Beも粗くなる … 1工程1行で済ませず、「誰が・何を見て・何を判断して・どこに出すか」の4点で書きます。判断が入っている工程は、これを書こうとすると手が止まります。手が止まった工程が、いちばん重要な工程です。
- 3人のやり方が違う … 統一してから書こうとしません。3通りとも書き出します。違いがそのまま課題の一覧になります。
- 「何のためか分からない工程」が出てきた … すぐには廃止しません。誰が何のために始めたかを確認するまで残します。理由が分からないものを消すのは、理由が分かって消すより危険です。
- 関係部署の作業が見えない … 営業部の作業まで含めて書くと範囲が広がりすぎます。まず経理部の中だけで書き、外に出る／入ってくる境目だけ明記します。
6. 検証 ― 正しいとどう言えるか
- 書き出した業務を、実際にその作業をしている3人に見せて「これで合っているか」を確認する。ここを飛ばすと、後工程が全部崩れます。いちばん重要な検証です。
- To-Beの各工程に、担当と承認者が書かれているか。空欄があれば、まだ設計できていません。
- 「人が残る」工程に、残す理由が書かれているか。理由が書けない工程は、本当に残す必要があるか再検討します。
- RFP項目のうち、どのベンダーもYESと答えるものが残っていないか。残っていれば、比較の役に立ちません。
- 現行のエラー発生箇所が、To-Beでどうなるかが書かれているか。ここが書かれていないRFPは、いまと同じ問題を新システムでも抱えます。
7. 注意点
8. After ― 翌月以降、何が変わるか
- 手順書が無かった業務に、書き出した資料ができます。これ自体が引継ぎ資料になります。
- 「何のためにやっているか分からない工程」が一覧になり、確認の対象になります。
- システム更改の話が、ベンダー主導ではなく自部門主導になります。「何ができますか」ではなく「これをどう実現しますか」を聞けます。
- 更改しない判断になった場合でも、手作業の削減余地が見えます。書き出した資料は無駄になりません。
- 自分が今月やった作業を、30分だけ使って「誰が・何を見て・何を判断して・どこに出すか」の4列で書き出す
- AIに渡して、重複している工程と、判断が必要な工程に印をつけさせる
- 印がついた工程のうち、手順書が無いものが何個あるかを数える
応用 ― 難易度を上げる場合
同じ型を、決算早期化、内部統制の見直し、属人化の解消にも使えます。複数の業務で書き出しが揃ってくると、部門全体のどこに時間が使われているかが見えるようになります。