システム部門・ベンダーへの伝え方

18-1なぜ伝わらないのか

業務担当者がどれだけ丁寧に設計しても、それが作る側に正しく伝わらなければ、思っていたのと違う仕組みが出来上がります。業務部門とシステム部門・ベンダーの間で、話が食い違う原因はおおむね3つです。

原因	起きること	例
言葉のずれ	同じ言葉を違う意味で使っている、違う言葉で同じものを指している	業務側の「承認」は上長の判断、システム側の「承認」は画面のボタン操作を指している
前提が書かれていない	業務側には当たり前すぎて伝えなかったことが、作る側には分からない	「月末は件数が3倍になる」「量販店で買った人の記録はない」
「できます」の食い違い	「AIでこれはできますか」「できます」のやり取りで、条件や水準が抜け落ちる	「読み取りはできます」が、実は「きれいな画像なら9割程度」の意味だった

この章では、第1〜17章で作ってきた設計書を使って、これらの食い違いを防ぎながら、システム部門やベンダーと一緒に仕組みを実現していく方法を学びます。

18-2相談の段階に応じて、渡すものを選ぶ

設計書をすべて一度に渡す必要はありません。相談の段階と相手に応じて、必要なものを選びます。

段階	目的	渡すもの
1. 最初の相談	やりたいことと困りごとを共有し、進め方の見通しを得る	要件メモ（第5章）、業務分解表（第2章）
2. 実現方法の検討	作り方の案と、おおよその費用・期間を出してもらう	上記に加え、任せ分け表（第3章）、データの一覧と項目定義表（第6章）、連携一覧（第9章）、非機能の要件（第12章）
3. 見積もり・提案	具体的な作り方・費用・期間・体制を比べる	上記に加え、知識の棚卸し（第7章）、型の選択（第8章）、権限と記録（第10章）、評価計画と例題集の一部（第11章）
4. 作る・確かめる	作る側と一緒に細部を詰め、出来上がりを確かめる	すべて。特に例題集と、AIへの指示の案

どの段階でも、要件メモの「やらないこと」と「成功の物差し」は必ず含めます。作る側は、範囲と目標が分からないと、費用も期間も見積もれないからです。

18-3最初の相談の進め方

最初の相談では、次の順番で話すと、短い時間で相手に全体像が伝わります。

1. 目的：何のための取り組みか（1〜2文）
2. 困りごとと数字：いま何が起きていて、どのくらい困っているか（第14章のような現状の数字）
3. 成功の物差し：何がどうなれば成功か
4. 範囲とやらないこと：今回扱うこと、扱わないこと
5. 考えている任せ分け：どの工程にAIを使い、どこを人が持つか（業務側の案として）
6. 聞きたいこと：作る側の意見がほしい点

5の任せ分けは、「案」として示すのがコツです。業務側の考えを示すことで話が具体的になりますが、技術的にもっと良い方法があるかもしれません。作る側の意見を聞く余地を残しておきます。

18-4言葉の対応表を持っておく

この教材では、業務担当者に分かりやすい言葉を使ってきました。作る側は、同じものを別の言葉で呼ぶことがあります。対応を知っておくと、話がかみ合いやすくなります。

この教材の言葉	作る側がよく使う言葉	章
業務分解表、業務フロー図	業務フロー、スイムレーン図、As-Is（現状）／To-Be（あるべき姿）	第2章
任せ方のレベル	自動化レベル、ヒューマン・イン・ザ・ループ	第3・4章
人に回す	エスカレーション、例外処理	第4章
要件メモ	要件定義書、RFP（提案依頼書）の一部	第5章
項目定義表、データの関係	データ項目定義、データモデル、ER図	第6章
状態	ステータス、状態遷移	第6章
正本	マスタ、正のデータ、SoR（記録の正となるシステム）	第6章
型A：手順の一部をAIが担う	ワークフロー型、AIの部品化	第8章
型B：社内資料を参照して答える	RAG（検索拡張生成）	第8章
型C：AIが手順を考えて動く	AIエージェント	第8章
AIへの指示	プロンプト、システムプロンプト	第8章
例題集、合格ライン	評価データセット、テストデータ、評価基準	第11章
止まったとき	可用性、障害対応、BCP（事業継続計画）	第12章

相手の言葉が分からないときは、遠慮せずに「それは、業務でいうと何に当たりますか」と聞いてください。分からないまま話を進めることが、最も大きな食い違いの原因になります。

18-5提案と見積もりを確かめる

システム部門やベンダーから提案や見積もりが出てきたら、要件メモと照らし合わせて確かめます。技術的な中身をすべて理解する必要はありません。業務側が確かめるべきことは、業務側の言葉で確かめられます。

最後の「自社に残るもの」は見落とされがちですが重要です。AIへの指示、整えた知識、例題集は、業務のノウハウそのものです。ベンダーの仕組みの中にしか存在しない形にすると、ベンダーを変えたときにすべてを作り直すことになります。

18-6「できます」を確かめる

AIを使った仕組みの提案では、実演（デモ）を見せてもらう機会があります。実演はうまくいく案件で行われることが多いので、次のように確かめます。

確かめ方	理由
自社の例題で試してもらう	実演用の案件ではなく、自社の実際の案件でどう動くかが知りたい
境目の案件を入れる	典型的な案件ではなく、迷う案件での動きに実力が出る
判断できないはずの案件を入れる	資料にない質問に、推測で答えずに「分からない」と返すかを見る
根拠の示し方を見る	担当者が確かめやすい形で根拠が示されるか
同じ案件を何度か試す	結果がどのくらいぶれるかを見る

例題集（第11章）を早めに作っておくと、この確かめ方がそのまま使えます。複数の提案を比べるときも、同じ例題集で比べれば公平です。なお、例題集を社外に渡すときは、個人情報や取引先名を伏せ、渡してよい情報の範囲（第7章）を守ります。

18-7役割分担を決める

作る段階に入ったら、業務部門・システム部門・ベンダーの役割分担を決めます。曖昧なままだと、「それはそちらでやると思っていた」という作業の抜けが起きます。

作業	業務部門	システム部門	ベンダー
要件・成功の物差しの決定	責任を持つ	助言	助言
知識（規程・回答集）の整備	責任を持つ	—	形式の助言
例題集の作成と正解付け	責任を持つ	—	助言
AIへの指示の内容	内容に責任	助言	技術的な書き方
仕組みの設計と構築	確認	社内ルールとの整合	責任を持つ
権限・ログ・情報管理	要件を示す	責任を持つ	実装
受け入れの確認	責任を持つ	技術面の確認	支援
運用中の改善（知識・指示）	責任を持つ	支援	契約による

表を見ると分かるように、知識、例題集、指示の内容は、業務部門が責任を持つものです。AIを使う仕組みでは、作る作業の多くが、業務の知識を整えて言葉にする作業になります。「システムはシステム部門に任せる」という分担では、AIの仕組みは完成しません。

18-8受け入れの確認

仕組みが出来上がったら、業務部門が受け入れの確認を行います。「動くこと」ではなく、「業務で使えること」を確かめる作業です。

確認	内容
例題集での評価	合格ラインを満たすか（第11章）。作る側が測った結果だけでなく、業務側も一部を確かめる
業務の通しの確認	典型的な案件、例外、人に回す案件などを、受付から記録まで実際の流れで通してみる
権限の確認	AIが送信・確定できないこと、人だけが進められる状態が守られていることを、実際に操作して確かめる
止まったときの訓練	AIを止めた状態で、代わりの手順で業務を回せるか（第12章）
記録の確認	ログと確認の記録が、決めた項目どおりに残っているか

受け入れの確認を終えたら、いよいよ小さく試す段階に入ります。それが最終章、第19章のテーマです。