AIエージェントを業務に入れる前に読む要件定義・業務分析の本｜言語化から始める4冊

「この業務、AIに任せられませんか」という相談を受けて話を聞いていくと、途中でほぼ必ず止まる場所があります。その業務の入力は何で、出力は何で、どうなったら正解なのか。ここが誰の口からも出てこないのです。担当者は毎日きちんとこなしているのに、手順が頭と経験の中にあって、外に出す形になっていません。この状態のままツールを配っても、うまくいったのかどうかすら判定できません。

原因はモデルの性能ではなく、業務が言語化されていないことです。そして業務を言語化する技術には、生成AIより前から積み上がってきた名前があります。要件定義であり、業務分析です。この記事では、生成AI・AIエージェントを業務に入れる前段として役立つ、要件定義・業務分析の実在の日本語書籍を4冊、段階順に紹介します。なお本記事は書籍紹介であり広告を含みます。価格・版・在庫・目次は変わるため、最新は各出版社の公式ページでご確認ください。

AI導入の失敗が「要件定義の失敗」に見える理由#

生成AIの導入がうまくいかなかったという話を分解すると、次の4つのどれかに当てはまることが多いです。いずれもモデルの問題ではありません。

• 入力が定まっていない。同じ依頼でも、人によって渡す資料の粒度も形式もばらばらで、出力が安定しない。
• 出力の合格ラインがない。出てきた文章が「良い」のか「使えない」のか、判断が担当者の感覚に依存している。
• 業務の境界が曖昧。どこまでAIにやらせ、どこから人が判断するのかが決まっておらず、責任の所在が宙に浮く。
• 例外が見えていない。普段の8割の流れだけが語られ、残り2割の例外処理が本番で噴き出す。

この4つは、そのまま要件定義でつまずくポイントと同じです。つまり、AIを入れる前にやるべきことは新しい何かではなく、昔からある「業務を言語化して合意する」作業だということになります。

やっかいなのは、この状態でもデモは動いてしまうことです。担当者が自分の頭の中にある前提を補いながらプロンプトを書けば、それらしい出力は出ます。困るのはその先で、別の人が同じ作業をした瞬間に結果が変わり、「AIは使えない」という結論だけが残ります。再現しない成功は、成功として扱えません。

もうひとつ見落とされやすいのが、言語化されていない業務は評価もできないという点です。合格ラインが無ければ、出力の良し悪しはレビューする人の気分で変わります。この状態で「精度が低い」と言われても、モデルを替えるべきなのか、指示を直すべきなのか、そもそも任せる範囲が広すぎるのかを切り分けられません。改善のループが回らないまま、なんとなく使われなくなるのがよくある終わり方です。

4冊をどう選び分けるか#

先に押さえる「言語化の最小セット」#

本を読む前でも、次の5項目を埋めるだけで議論の解像度は上がります。逆にここが埋まらない業務は、まだAIに渡す段階ではないと判断できます。

とくに効くのは例外の欄です。業務を説明してもらうと、たいていは普段の流れだけが語られます。「その手順が使えないのはどんなときですか」と聞くと、ようやく差し戻しや特例の話が出てきます。AIに任せて事故が起きるのは、ほぼこの領域です。

1. 要件定義の全体像を最短でつかむ#

要件定義を体系立てて学んだことがない人が最初に手に取る一冊としては、技術評論社の「はじめよう！ 要件定義 ～ビギナーからベテランまで」が入りやすい構成です。要件定義を「作ってほしい人と作る人の間の合意事項」と位置づけ、UI・機能・データという3つの軸で何をどう決めていくかを扱います。四六判で分量も抑えめなので、まず全体の地図を持ちたい段階に向いています。

生成AIの文脈で効いてくるのは、この「UI・機能・データ」という分け方です。AIに任せたい業務についても、どんな形で依頼を受け取るのか(UI)、何をする処理なのか(機能)、どのデータを読み書きするのか(データ)を分けて書き出すだけで、議論が具体的になります。逆に言えば、この3つを書けない業務は、まだAIに渡せる状態になっていません。

はじめよう！ 要件定義 ～ビギナーからベテランまで(技術評論社)

広告

著者: 羽生章洋 / 出版社: 技術評論社。要件定義をUI・機能・データの3軸で決めていく流れを、分量を抑えてまとめた入門書です。決めるべき項目の地図を最初に持ちたい人に向きます。最新の版・価格は公式ページでご確認ください。

Amazonで見る楽天で見るYahoo!ショッピングで見る

※価格・在庫は変動します。最新の情報は各販売サイトでご確認ください。

2. 「作らせる側」の立ち回りを学ぶ#

生成AI導入の主役は、多くの場合エンジニアではなく業務部門です。自分では作らないが、作ってもらう責任は負う。この立場の教科書として書かれたのが、日本経済新聞出版の「システムを作らせる技術 エンジニアではないあなたへ」です。構想から依頼、プロジェクト中の課題解決までを対象に、業務担当者がすべきことと陥りやすい落とし穴を扱います。388ページと厚めですが、その分カバー範囲が広い一冊です。

AI導入の相談でよく起きる「ベンダーに丸投げしたら、動くけれど誰も使わないものが出てきた」という失敗は、システム開発でずっと繰り返されてきた失敗と同じ形をしています。生成AIかどうかに関係なく、要求を出す側が何を決め、どこまで関与するかという話です。社内展開の進め方そのものについては、当メディアの別記事も合わせてどうぞ。

システムを作らせる技術 エンジニアではないあなたへ(日本経済新聞出版)

広告

著者: 白川克・濵本佳史 / 出版社: 日本経済新聞出版。システムに詳しくない業務担当者が「作ってもらう」ために何をすべきか、構想から課題解決までを事例つきで解説した厚めの一冊です。発注側として動く立場に向きます。最新の版・価格は公式ページでご確認ください。

Amazonで見る楽天で見るYahoo!ショッピングで見る

※価格・在庫は変動します。最新の情報は各販売サイトでご確認ください。

3. 利用者の流れから機能を切り出す#

要件を機能一覧から作ると、項目は埋まるのに使われないものができあがることがあります。オライリー・ジャパンの「ユーザーストーリーマッピング」は、利用者の行動を時間の流れに沿って並べ、そこからストーリーを切り出して優先順位や分割を決める手法をまとめた本です。手法の考案者自身による解説で、ストーリーの理解の仕方からライフサイクルごとの使い方までを扱います。

AIエージェントの設計に効くのは、この「流れで並べる」発想です。一連の業務を1つの大きな依頼としてAIに渡すと、どこで失敗したのか分からなくなります。利用者の行動単位に分けておくと、任せる範囲を小さく切れて、どのステップの品質が悪いのかも切り分けられます。人がどこで確認に入るかを決めるうえでも、流れの可視化は前提になります。

ユーザーストーリーマッピング(オライリー・ジャパン)

広告

著者: Jeff Patton / 監訳: 川口恭伸 / 訳: 長尾高弘 / 出版社: オライリー・ジャパン。利用者の行動の流れからストーリーを切り出し、優先順位と分割を決める手法を体系的に解説しています。任せる単位を小さく刻みたい場面で効きます。最新の版・価格は公式ページでご確認ください。

Amazonで見る楽天で見るYahoo!ショッピングで見る

※価格・在庫は変動します。最新の情報は各販売サイトでご確認ください。

4. モデルで構造化し、抜けと矛盾を潰す#

文章だけで書いた要件は、読めば分かった気になれる一方で、抜けや矛盾に気づきにくいという弱点があります。秀和システムの「モデルベース要件定義テクニック」は、RDRA(リレーションシップ駆動要件分析)という手法をもとに、コンテキストモデル・ユースケースモデル・データモデルといった図で要件同士の関係をつなぎ、整合性を点検しながら要件定義書に落としていく流れを扱います。ECサイトなどのケーススタディと、モデルごとのリファレンスが収録されています。

4冊のなかでは最も型がはっきりしており、その分だけ独学のハードルは上がります。ただ、業務の登場人物・外部システム・データの関係を図で押さえる習慣は、AIエージェントに社内システムを触らせる設計を考えるときにそのまま活きます。どのシステムのどのデータに、誰の権限で触るのかという整理は、結局のところ要件のモデル化と同じ作業だからです。

モデルベース要件定義テクニック(秀和システム)

広告

著者: 神崎善司 / 出版社: 秀和システム。RDRAをベースに、複数のモデルを関連づけて要件の整合性を点検する型を解説した実務書です。図で構造を押さえたい人、抜け漏れの点検方法が欲しい人に向きます。最新の版・価格は公式ページでご確認ください。

Amazonで見る楽天で見るYahoo!ショッピングで見る

※価格・在庫は変動します。最新の情報は各販売サイトでご確認ください。

4冊の守備範囲を整理する#

同じ「要件定義」という言葉でも、4冊が扱う範囲は重なりつつずれています。読む順番を決める材料として整理しておきます。

読む順番に唯一の正解はありませんが、非エンジニアの推進担当であれば入門書から作らせる技術へ、開発側と一緒に設計まで進めるならユーザーストーリーマッピングからモデルベースへ、という流れが素直です。4冊とも初版からは時間が経っているため、開発の前提が現在と異なる記述はあります。考え方を取り出して使う読み方をおすすめします。

本では埋まらない、AI固有の要件#

要件定義の本を読んでも、そのままでは決まらない項目があります。ここは公開されている一次情報を見ながら、自分たちで設計する部分です。

このうち任せる範囲とツール設計については、モデル提供元の公開資料が参考になります。Anthropicの技術記事では、複雑な仕組みを組む前にまず単純な構成で足りるかを検討すること、エージェントに渡すツールは説明文を含めて丁寧に設計することが述べられています。仕組みを凝る前に、任せる作業と渡す道具をはっきりさせるという点で、要件定義の発想と地続きです。

任せる範囲については、いきなり全工程を渡さないという判断がよく効きます。5工程ある業務のうち、判断を伴わない2工程だけをAIに任せ、残りは人が担当する。これは手抜きではなく、失敗したときにどこが原因かを特定できる形にするための設計です。範囲を狭く始めて、うまくいった工程から広げるほうが、結果的に早く定着します。

人の承認点については、コストとリスクの兼ね合いで決めます。すべての出力を人が確認するなら事故は減りますが、確認の手間が効率化分を食い潰します。逆に確認を外すなら、外した操作は取り返しがつくものに限る、といった線引きが要ります。ここは業務ごとに違うので、一般論ではなく自分たちの業務で決めるしかない部分です。

合格基準の決め方は、そのまま評価の設計につながります。「良い出力」を言葉で書けるようになった段階で、評価データを作る話に進めます。

言語化の作業そのものをAIに手伝わせるとき#

要件を書き出す作業自体にも、生成AIは使えます。ヒアリングの録音から論点を拾う、書いた要件を読ませて「この記述だと解釈が分かれる箇所はどこか」を挙げさせる、例外パターンの候補を列挙させる、といった使い方です。とくに例外の洗い出しは、人だけでやると経験の範囲に縛られるため、たたき台を出させる価値があります。

ただし、AIが出した論点は「候補」であって事実ではありません。実在しない業務手順や、その会社には存在しない部署名がもっともらしく混ざることがあります。出てきた項目は必ず業務担当者に当てて、実在するかどうかを確認してから採用してください。要件の記述に誤りが混ざると、後工程すべてがその誤りの上に積み上がります。

よくある誤解: 要件定義は分厚い文書を作ることではない#

要件定義と聞くと、分厚い仕様書を作る作業を思い浮かべる人がいます。ただ、生成AIを業務に入れる場面で必要なのは、承認を通すための書類ではなく、関係者の理解を揃えるための記述です。A4で1枚に収まっても、入力・出力・完了条件・例外・判断者が書けていれば十分に機能します。

もうひとつの誤解は、「最初に全部決めきる必要がある」というものです。実際には、動かしてみて初めて分かる要件がかなりあります。とくにAIを使う業務では、どんな出力が出てくるかを見るまで合格ラインを言語化できないことも珍しくありません。最初に決めるのは、試す範囲と、試した結果をどう判定するかまで。そこから書き足していく前提のほうが現実的です。

読む前にやっておくと効く準備#

本を読む効果を上げるために、先に手を動かしておきたいことが2つあります。

1つは、対象業務を1つに絞ることです。「営業部門の業務全般」では大きすぎて、どの本を読んでも自分の話に落ちません。「見積書のドラフト作成」「問い合わせメールの一次仕分け」くらいまで下ろすと、本の記述をそのまま当てはめて考えられます。

もう1つは、その業務を実際に一度書き出してみることです。うまく書けなくて構いません。書けなかった箇所が、そのまま「言語化できていない部分」であり、本を読むときに注意して読む箇所になります。読む前と読んだ後で同じ業務を書き直してみると、何が身についたかも分かります。

本記事で紹介した書籍の情報(書名・著者・出版社・刊行時期・構成)は、各出版社の公式ページおよび公式書誌情報(執筆時点)を参照しています。AIエージェントの設計に関する記述はAnthropicの公開技術記事、社内ルールに関する記述は総務省・経済産業省およびデジタル庁の公開資料を参照しました。価格・版・在庫・目次は変わるため、最新は各公式ページでご確認ください。

よくある質問#

まとめ#

生成AIやAIエージェントを業務に入れる作業は、新しい技術の導入である前に、業務を言語化して合意する作業です。ここが曖昧なままだと、どんなモデルを選んでも成果の判定ができません。今回紹介した4冊は、その言語化のやり方を段階ごとに教えてくれます。まずは対象業務を1つに絞って書き出し、書けなかった部分を持って、いまの自分に近い1冊から読み始めてみてください。