PR：この記事にはアフィリエイトリンクが含まれます。
生成AIを使ったシステム開発では、コードを書く前の要件定義が大切です。AIに「便利な機能を考えて」と頼むだけだと、誰の困りごとをどう解決するのかが曖昧なまま進みます。後で困るのは、たいていこの部分ですよね。
初心者がまず押さえたいのは、ユーザーストーリーで利用者の目的を表し、受け入れ条件で完成の判定方法を決めること。生成AIは整理を助けてくれますが、要件を決める責任まで引き受けてはくれません。
| 本 | 主に学べること | 参考価格（税込） |
|---|---|---|
 図解まるわかり 要件定義のきほん | 要件定義の全体像、文書、テスト計画 | 2,068円 |
 ユーザーストーリーマッピング | 利用者の行動と機能の整理、チームでの検証 | 3,960円 |
 要件定義の極意 | 業務フロー、現場の声、優先順位づけ | 3,278円 |
 レガシーコードからの脱却 | ユーザーストーリー、受け入れテスト | 3,190円 |
 戦略的AI活用による要求工学知識体系の実践ガイド | 生成AIを使った要求獲得や仕様作成 | 3,190円 |
 AI駆動開発の教科書 | 要件定義から運用までのAI活用 | 2,860円 |
価格は各書籍の希望小売価格を目安にしています。実売価格は時期や販売店によって変わるため、購入時に確認してください。
要件定義の役割
要件定義では作る機能の一覧を整えたうえで、利用者や関係者の話から解決したい課題をつかみ、システムが担う範囲を合意できる形にします。ここで合意した範囲が、その後の設計や開発の前提になります。
たとえば「問い合わせ対応をAIで効率化したい」という要望でも、対象が社内担当者か顧客かで仕組みは変わります。何を問い合わせと呼び、回答を誰が確認するのか。まず言葉の意味をそろえましょう。
前提が曖昧なまま進むと、開発中に機能が増えたり、完成後に「想定した使い方と違う」と気づいたりします。すべてを先回りして決め切るより、重要な前提や未決事項を見える形にすることが大切です。
生成AIを使うなら、入力する情報の扱いも要件に含めます。個人情報や社外秘を送ってよいか、出力を人が確認するか、誤回答時にどう案内するか。便利さと運用上の責任を、初めから一緒に考えたいですね。
AI開発の論点
従来の画面や処理に加え、生成AIを使うシステムでは、どんな入力にどのような出力を期待するかを決めます。同じ質問でも回答が変わることがあるため、毎回同じ文章が返る前提にはできません。
社内規程に答えるチャットなら、規程にない内容を断定せず、根拠の文書を示す条件が必要です。回答できない場合は担当窓口を案内する条件も加えます。「正確に答える」だけでは完成を判定できないので、避けるべき誤りも明記します。
回答の品質は、入力文だけでなく参照データや更新頻度にも左右されます。古い規程を使ったら何が起きるか、対象外の質問をどう扱うか。そこまで整理すると、設計やテストで確かめる点が見えてくるでしょう。
精度を数値で示すときにも注意が必要です。評価する質問の集め方や「正解」の基準が曖昧なら、数字だけが独り歩きします。現場で許容できる間違いと、人の確認が必要な場面を先に分けておくのが現実的です。
ストーリーで表す
ユーザーストーリーは、誰が何をしたいのか、なぜ必要なのかを短く共有する書き方です。「営業担当者として過去の提案書を検索し、顧客への回答を早く準備したい」と書けば、機能の背景まで伝わります。
ただし、この一文だけで仕様が完成するわけではありません。対象の提案書や検索結果の表示、閲覧権限は、関係者との質問や議論で明らかにします。ストーリーは会話を始める入口です。関係者とのやり取りを通じて、必要な内容を具体化していきます。
機能名から考えると、「生成AIチャットを作る」のように手段が先行しがちです。利用者の達成したいことを起点にすれば、検索や既存画面の改善でも解決できるかもしれません。作る範囲を見直す助けにもなります。
「ユーザーストーリーマッピング」は、顧客や利用者とのワークショップで機能を洗い出し、カードに記録して並べ替える方法を扱います。チームレビューや顧客・ユーザーとのテストまで学びたい人には、この本が役立ちます。
条件を具体化
受け入れ条件は、ストーリーが満たされたかを関係者が確かめるための基準です。「回答に参照元を表示する」「該当情報がなければ推測せず担当窓口を案内する」と書けば、実装後に確認できます。
通常の成功例に加えて、入力不足や対象外の質問、権限のない利用者も想定します。AIの回答を人が承認してから送る運用なら、その操作と記録も確認対象です。例外を一つずつ考えると、必要な処理がはっきりします。
「使いやすい」「十分に速い」は、人によって判断が分かれる表現です。応答時間や対象データ、確認者など、必要な観点を話し合い、測れる言葉に置き換えましょう。数字を置くなら、実際に守れるかまで確かめます。
「レガシーコードからの脱却」は、目的や利用者を伝えるストーリーと、明確な受け入れテストの基準を扱います。コードレビューやふりかえりにも触れており、条件づくりをチームの確認につなげたい人に役立つ本です。
関係者と文書
要件は利用者や業務担当者、開発者、運用担当者の視点を集めて整理します。すべての希望をそのまま実装する必要はありませんが、理由や優先順位を聞かずに削るのは危険です。背景を確かめると、必要な要件かどうかを判断できます。
業務フローを描くと、作業の順番や担当者間の受け渡し、例外処理が見えてきます。現場の言葉を記録し、いつ誰がどの情報を見て判断するかを整理すると、画面やAIの役割も具体的になります。
「図解まるわかり 要件定義のきほん」は、関係者との進め方から文書作成、テスト計画までを図解で学べます。AI・IoTの要件定義例も掲載されており、全体像や用語と成果物のつながりを知りたい初心者におすすめです。
実務上の失敗を防ぐ視点を深めたい人には、「要件定義の極意」がおすすめです。業務フローや現場の声を起点に、ユースケースと動くプロトタイプへ進む方法を20のルールで紹介します。成果物の共有や優先順位、意思決定者の明確化も扱います。
生成AIとの分担
生成AIは、会議メモの要約やストーリー案の作成、曖昧な表現への質問出しに活用できます。「要望から利用者と目的を整理し、未確認事項を挙げて」と頼めば、議論のたたき台ができます。
ただし、AIが補った前提や作った条件を事実として扱ってはいけません。元の発言や業務ルールと照らし、関係者に確認してから採用します。法令や権限、データの保存期間や障害時の対応は担当者が根拠を確認します。
「戦略的AI活用による要求工学知識体系の実践ガイド」は、要求獲得の効率化・高品質化や要求仕様の分類・生成を扱います。プロンプト連鎖を用いた要求定義支援の手法と実施例を知りたい技術者や開発者に合います。
開発工程全体でのAI活用を学ぶなら、「AI駆動開発の教科書」があります。企業システムを例に、要件定義から運用までを解説します。Python FastAPIとJava Spring Bootのハンズオンに加え、導入手順やKPI、情報漏えいなどのリスクも扱います。
結論
初心者が先に身につけたいのは、利用者の目的と完成条件を人と合意する力です。AIへの指示文は、その後に磨けば十分です。
要件定義の全体像を知るなら「図解まるわかり」、ストーリーを整理したいなら「ユーザーストーリーマッピング」がおすすめです。要件定義が初めてなら図解の基礎書から読むとよいでしょう。
受け入れ条件や実務上の確認を深めるには「レガシーコードからの脱却」や「要件定義の極意」がおすすめです。要求工程で生成AIを学ぶなら「戦略的AI活用による要求工学知識体系の実践ガイド」が合います。
開発全体のAI活用なら「AI駆動開発の教科書」がおすすめです。すでに現場の課題がある人は実務書から読み、生成AIの出力を案として扱いましょう。ストーリーと受け入れ条件を関係者と確かめる習慣が、学びを現場につなげます。
Amazon の PC をスコア化してみた
Amazonにある8〜14インチの小型WindowsタブレットやノートPCを、スペック別にスコア化して比較・ランキング。
