要件定義の進め方｜AIを使って精度を上げる手順

システムを外注しようとして、最初に止まるのが要件定義です。「要件をまとめてください」と言われても、何をどこまで書けばいいのかが分からない。社内に情報システム部門がなければ、なおさらです。

結論から言うと、要件定義は完璧を目指した瞬間に失敗します。中小企業がやるべきなのは、分厚い仕様書を書くことではありません。「何に困っているか」「何をやらないか」「今は決められないことは何か」を、自分の言葉で整理することです。

本記事では、情報システム部門がいない会社が外注する前に自分で要件を固めるための手順を6ステップで解説します。あわせて、AIを使って抜けを減らす具体的な方法と、AIに任せてはいけない判断の線引きを整理します。

結論｜要件定義は6ステップで足りる

最初に全体像をお伝えします。

情シスがいなくても進められる

要件定義は、技術の知識がないとできない作業だと思われがちです。しかし実際に決めるべき中身の大半は、技術ではなく業務の話です。誰が、いつ、どの紙を見て、何を転記しているか。それを知っているのは現場の人だけです。

IPA（情報処理推進機構）も「ユーザのための要件定義ガイド 第2版」のなかで、システムの要件を定義する責任は、そのシステムを使ってビジネスに貢献する役目を負うユーザにあるという考え方を示しています（出典：IPA「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」）。技術はベンダーが担いますが、業務をどうしたいかは発注側にしか決められません。

AIは整理役、決めるのは人

AIは要件定義の道具として非常に相性が良いのですが、役割を間違えると逆効果になります。AIに任せてよいのは「整理」と「指摘」まで。何を優先するか、何を捨てるかという判断は人がやります。

ここを混同して「AIに要件定義書を作らせる」と、もっともらしい体裁の文書ができあがります。ところが中身は一般論で、自社の例外処理が一行も入っていない。これが最も危ない使い方です。

完璧な要件定義は目指さない

中小企業の要件定義で目指すべきゴールは、「今分かっていること」と「まだ決められないこと」が両方書かれている状態です。決められないことを空欄のまま放置するのではなく、「これは3か月後に決める」と書いておく。これだけで後の揉め事が大きく減ります。

要件定義とは何を決める作業か

言葉の整理から始めます。

「何のために」を決める

最初に決めるのは目的です。「受注処理を早くしたい」なのか「入力ミスを減らしたい」なのか。この2つは似ているようで、作るものがまったく変わります。速さを求めるなら入力項目を減らす設計になり、正確さを求めるならチェックを増やす設計になります。

目的が2つ以上あると、ベンダーは両方を満たそうとして中途半端なものを作ります。目的は1つに絞り、残りは「できれば」に落とすのが実務的です。

「誰が何をするか」を決める

次に、業務の流れです。受注が入ってから請求までに、誰が何を触るか。ここを書き出さずにシステムだけ決めると、「入力する人が現場にいない」「承認する人がパソコンを使わない」といった問題が稼働後に発覚します。

「作らないこと」を決める

これが最も抜けやすい項目です。対象外の業務を明記していない依頼書は、必ず揉めます。「在庫管理は今回の対象外」「本社のみで支店は次回」と書いておけば、見積りの前提が揃い、金額の比較ができるようになります。

要求と要件はどう違うか

混同されやすい3つの言葉を整理します。

言葉	誰が出すか	中身の例
要求	現場・経営	「二重入力をやめたい」
要件	発注側が整理	「受注データを1回入力すれば納品書に反映される」
仕様	ベンダーが設計	「受注テーブルから納品書を自動生成する画面を用意する」

発注側が担当するのは要求を集めて要件に整理するところまでです。仕様まで自分で書こうとすると、技術的に無理な指定をしてしまい、かえって高くつきます。

要件定義が失敗する5つの原因

IPAは同ガイドの説明のなかで、システム開発の遅延の過半は要件定義の失敗にあると言われると述べています（出典：IPA「ユーザのための要件定義ガイド 第2版」）。では、なぜ失敗するのか。中小企業で実際に起きやすいパターンを5つに整理します。

現場を知らない人が書く

最も多い原因です。社長や総務担当が想像で書いた要件は、現場の実態とずれます。「受注は基本メールで来る」と書いたものの、実際は電話とFAXが半分を占めていた、という食い違いは珍しくありません。

対策は単純で、実際に手を動かしている人に1時間話を聞くことです。書く人と知っている人が別なら、必ずこの時間を取ってください。

完璧を目指して終わらない

「抜けがあると困るから、全部書いてから出そう」と考えると、要件定義が半年止まります。その間に業務は変わり、書いた内容が古くなります。

IPAが中小企業向けに公開している「ストーリーで学ぶ要件定義実践入門」でも、段階的に試行しながら、作り込まずに、パッケージやクラウドサービスに業務を合わせるという進め方がポイントとして挙げられています（出典：IPA「ストーリーで学ぶ要件定義実践入門」）。全部を先に決める前提を捨てることが、中小企業では特に重要です。

将来の要望を全部入れる

「将来こうしたい」を全部入れると、見積りが跳ね上がります。しかも使われない機能が半分以上になります。将来の要望は「今回やらないリスト」に移し、日付をつけて別枠で管理してください。捨てるのではなく、先送りを明文化するという意味です。

言葉の意味が揃っていない

社内で「案件」「受注」「引き合い」がそれぞれ別の意味で使われている会社は非常に多いです。この状態で要件を書くと、ベンダーは自分の解釈で作ります。稼働後に「これは受注ではない」と言われても、もう直せません。

対策は用語集を1枚作ることです。10語もあれば十分です。「案件＝見積り提出前のもの」「受注＝注文書を受領したもの」と定義するだけで、認識のずれが目に見えて減ります。

決められないことを放置する

「単価の丸め方はまだ決まっていない」「支店の運用は検討中」。こうした未決事項を空欄のまま渡すと、ベンダーは勝手に決めるか、あるいは見積りに余裕を積みます。どちらも発注側が損をします。

「未定である」と書くことも要件定義です。いつ、誰が決めるかまで書いておけば、それは立派な情報になります。

進め方｜6ステップの全体像

ここからが実務の手順です。全体像を先に示します。

ステップ	やること	目安
1	困っていることを書き出す	半日
2	現状の業務を可視化する	2〜3日
3	目的と優先順位を決める	半日
4	やらないことを決める	半日
5	動く試作を作ってみる	1〜3日
6	依頼書にまとめる	1日

合計で1〜3週間です。半年かける必要はありません。

ステップ1｜困っていることを書き出す

いきなり「要件」を書こうとしないでください。最初は不満だけを集めます。

業務ではなく不満から書く

「受注管理業務」といった単位で書くと、抽象的になって進みません。「毎週金曜の夕方、同じ数字を3か所に転記していて腹が立つ」という粒度で書いてください。感情がついている不満ほど、実在の課題です。

集め方は、現場に紙を1枚配って「今の仕事で無駄だと思うことを5個書いてください」と依頼するだけで十分です。会議で聞くと出てきません。

1日の流れをそのまま書く

もう1つの集め方は、担当者に朝から夕方までの動きを時系列で書いてもらう方法です。「9時：FAXを確認」「9時30分：Excelに転記」というレベルで書いてもらいます。ここに、本人も無駄だと気づいていない作業が出てきます。

AIに整理させる指示文

集まった不満は、そのままだと重複だらけです。ここでAIを使います。

ポイントは4行目です。これを入れないと、AIは一般的な業務課題を勝手に足してきます。自社の実態から離れた要件が混ざる原因は、ほぼここです。

ステップ2｜現状の業務を可視化する

次に、いま実際にどう動いているかを書き出します。

紙とExcelの流れを追う

1つの業務について、情報がどこから来てどこへ行くかを追いかけます。「注文書がFAXで届く→受注台帳のExcelに手入力→出荷指示書を印刷→倉庫に渡す→出荷後に別のExcelに実績入力」。この形で書ければ十分です。

図にする必要はありません。矢印でつないだ箇条書きで足ります。きれいな業務フロー図を作ろうとして止まるくらいなら、文章のままベンダーに渡すほうが早いです。

例外処理を必ず書き出す

ここが最重要です。要件定義が破綻する原因のほとんどは、例外処理の見落としにあります。

• 急ぎの注文が電話で来たときはどうしているか
• 数量が変更になったときは誰に連絡するか
• 特定の取引先だけ単価の計算方法が違わないか
• 月末だけ違う手順を踏んでいないか
• 担当者が休んだ日は誰が代わるか

これらは現場の人にとって当たり前すぎて、聞かれないと出てきません。しかしシステムにとっては、この例外こそが工数を左右します。

AIに抜けを指摘させる

書き出した業務の流れをAIに読ませて、抜けを指摘させます。これがAIの最も有効な使い方です。

AIは「返品が発生した場合の処理は記載されていません」「取引先ごとの締め日の違いが不明です」といった指摘を返します。自分では気づかない抜けを、他人の目で見てもらう役割としてAIを使うわけです。

出てきた質問は、そのまま現場へのヒアリングシートになります。ここで20問のうち5問でも「確かに決めていなかった」が出れば、AIを使った価値は十分にあります。

ステップ3｜目的と優先順位を決める

集めた困りごとを、優先順位のついた形に変えます。

目的は1つに絞る

前述のとおり、目的が複数あると設計がぶれます。「今回は転記作業をなくすこと」と決めたら、それ以外は副次的な扱いにします。

必須・あると良い・不要

集まった要望を3つに仕分けします。この仕分けはAIにやらせてはいけません。何が必須かは、業務と経営の事情を知っている人にしか判断できないからです。

区分	意味	判断の基準
必須	これがないと導入する意味がない	目的に直結するか
あると良い	予算が余ればやる	なくても業務は回るか
今回やらない	次回以降に検討	いつ検討するか日付を書く

実務上のコツは、「必須」を7個以内に抑えることです。10個を超えると、ほぼ全部が必須という意味になり、優先順位として機能しなくなります。

数字で測れる形にする

「業務を効率化したい」では、成功したかどうかを誰も判定できません。「月60時間かかっている転記作業を20時間以下にする」と書けば、稼働後に評価できます。

この数字は、ステップ2で業務を書き出したときに測っておきます。ストップウォッチは不要で、担当者に「だいたい何時間くらい？」と聞いた概算で構いません。

ステップ4｜やらないことを決める

ここを飛ばす会社が非常に多いのですが、費用に最も効くステップです。

対象外を先に書く

依頼書の冒頭に「今回の対象外」を明記します。会計連携、支店の運用、スマートフォン対応、既存データの移行。これらを書いていないと、ベンダーによって見積りの前提がバラバラになり、金額の比較が成立しません。

将来やることは別枠にする

「将来的には在庫管理も」と口頭で伝えると、ベンダーは将来を見込んだ設計を提案し、初期費用が膨らみます。将来の構想は「第2段階として検討中」と別項目に切り出し、今回の見積りには含めないと明記してください。

決められないことを決める

未決事項の書き方です。以下の3点をセットで書きます。

• 何が決まっていないか（例：支店での運用ルール）
• いつまでに決めるか（例：設計完了までに）
• 誰が決めるか（例：営業部長）

この形で書いておけば、ベンダー側も「ここは仮置きで進める」と判断でき、無駄な保険が見積りに乗りません。不明点を隠すより、明示するほうが安くなります。

ステップ5｜動く試作を作ってみる

ここが、従来の要件定義との最大の違いです。

言葉より画面のほうが速い

「こういう画面が欲しい」を文章で説明しても、正確には伝わりません。人によって思い浮かべる画面が違うからです。一方、実際に動く画面を見せれば、認識のずれはほぼ消えます。

近年はAIに自然言語で指示してコードを書かせる手法が普及し、非エンジニアでも簡単な試作なら数時間で作れるようになりました。この手法についてはバイブコーディングとは｜中小企業の業務での使い方で、作ってよいものと作ってはいけないものを含めて詳しく解説しています。

試作は捨てる前提で作る

試作の目的は、本番システムを作ることではなく、要件を確定させることです。「せっかく作ったから本番でも使おう」と流用するのが最も多い失敗です。試作には、業務が止まったときの復旧手段も、権限管理も、データの保全もありません。

本番データを読み込ませるのも避けてください。項目名と数件のダミーデータで、画面の形は十分に確認できます。

試作で分かることの範囲

試作で分かること、分からないことを整理します。

項目	試作で分かるか
入力項目の過不足	分かる
画面の流れが業務に合うか	分かる
現場が使えるかどうか	分かる
帳票の見た目	分かる
大量データでの速度	分からない
同時に使ったときの動作	分からない
セキュリティの妥当性	分からない

分からない領域は、そのままベンダーに委ねる部分です。試作は「発注側が決められることを決めきる」ための道具だと考えてください。

試作を現場に触らせる

作った試作は、必ず実際に入力する人に触ってもらいます。会議室で見せるのではなく、5分でいいので自分で操作してもらってください。ここで「この項目、うちでは使いません」「この順番だと入力できません」が出れば、外注前に修正できます。

この段階で反対意見が出るのは良い兆候です。導入への抵抗が強い場合の進め方はAI導入に反対されたときの進め方で整理しています。

ステップ6｜依頼書にまとめる

最後に、ここまでの内容を1つの文書にします。

依頼書に必ず書く8項目

項目	書く内容
1. 目的	何を良くしたいか。1つに絞る
2. 現状	今の業務の流れと所要時間
3. 必須要件	7個以内。番号を振る
4. あると良い要件	予算次第で外せるもの
5. 対象外	今回やらないことを明記
6. 未決事項	いつ誰が決めるかまで書く
7. 非機能の要求	利用人数・稼働時間・データ量など
8. 前提条件	予算感・希望時期・既存システム

文量は数ページで構いません。厚さではなく、判断に必要な情報が揃っているかが重要です。

非機能の要求も伝える

忘れられやすいのが、機能以外の要求です。IPAは「非機能要求グレード」というツール群を公開しており、これは非機能要求についてのユーザと開発者との認識の行き違いを防止することを目的に、要求項目を網羅的に分類したものです（出典：IPA「システム構築の上流工程強化（非機能要求グレード）紹介ページ」）。中小企業がそのまま使うには詳細すぎますが、考え方は参考になります。

最低限、次の項目を数字で書いてください。

• 同時に使う人数（例：最大8人）
• 使う時間帯（例：平日8時〜19時）
• 扱うデータ量（例：受注が月400件）
• 止まったときに許容できる時間（例：半日）
• バックアップの要否と復旧の想定
• 社外からアクセスする必要があるか

これらは見積り金額に直結します。書いていないと、ベンダーは安全側に見積もるか、逆に最低限の構成で提案してきます。どちらも後で揉めます。

見積りが比較できる形にする

複数社に依頼する場合は、全社に同じ依頼書を渡してください。口頭での補足を会社ごとに変えると、前提が揃わず比較になりません。

また、見積書には「初期費用」「月額費用」「保守の範囲」「追加開発の単価」を分けて記載するよう依頼してください。総額だけの見積りは比較できません。

AIを要件定義に使う3つの型

ここでAIの使い方を整理します。要件定義でのAI活用は、次の3つに集約されます。

型1｜書き出しを整理させる

現場から集めた断片的なメモを、重複を削って分類させる使い方です。人がやると半日かかる整理が、数分で終わります。元の情報を人が持っているので、精度の面でも安全です。

型2｜想定質問を出させる

業務の説明を読ませて、「ベンダーから聞かれそうな質問」を出させます。事前に質問を潰しておくと、打ち合わせの回数が減ります。

逆の使い方も有効です。ベンダーからもらった提案書を読ませて、「この提案で確認すべき点を10個挙げてください」と依頼する。技術用語の多い提案書に対して、何を聞き返せばよいかが分かります。

型3｜抜けと矛盾を指摘させる

書き上げた依頼書を読ませて、矛盾や不足を指摘させます。

4行目で「改善案は不要」と伝えるのが要点です。改善案まで出させると、AIが書いた要件が混ざってしまい、どこまでが自社の意思か分からなくなります。

なお、社内文書やファイルをAIに扱わせる仕組みについてはMCPとは｜AIと社内システムをつなぐ仕組みで解説しています。企画書や稟議書の作成にAIを使う方法は企画書をAIで作る手順にまとめています。

AIに任せてはいけない判断

使い方の線引きを明確にします。

優先順位は人が決める

「どの機能が必須か」をAIに決めさせてはいけません。AIは一般的に重要とされる機能を選びます。しかし自社にとっての必須は、経営方針や人員配置、取引先との関係で決まります。この情報はAIに与えていないので、正しく判断できるはずがありません。

現場の例外は人しか知らない

「A社だけは請求書を紙で郵送している」「繁忙期だけパートが入力する」。こうした事情はどこにも書かれていません。AIに聞いても出てきません。ヒアリングを省略する道具としてAIを使うと、必ず抜けます。

数字と固有名詞は必ず確認

AIが生成した文書に、実在しない製品名や、確認していない数値が入ることがあります。依頼書に載せる前に、数字と固有名詞は人が1つずつ確認してください。ベンダーに渡す文書に誤りがあると、そのまま設計に反映されます。

社外に出せない情報の扱い

取引先名、単価、個人情報を含むファイルをそのままAIに読み込ませるのは避けてください。取引先名は「A社」「B社」に置き換えるだけで、整理作業の精度はほとんど落ちません。

参考として、総務省「令和7年版 情報通信白書」によれば、生成AI導入に際しての懸念事項として日本では「効果的な活用方法がわからない」が最も多く、次いで「社内情報の漏えい等のセキュリティリスク」が挙げられています（出典：総務省「令和7年版 情報通信白書」企業におけるAI利用の現状）。使い方を決めてから始めることが、この2つの懸念への同時の答えになります。

モデルケース｜要件定義の3週間（試算）

進め方のイメージを示します。以下は実在の企業ではなく、当社が想定する典型的な状況にもとづく試算です。効果は状況によって変わります。前提は時給2,500円・月20営業日で計算しています。

置かれた状況

従業員25名の製造業。受注はFAXとメールで届き、Excelの受注台帳に手入力。そこから出荷指示書と請求データを別々に作り直しています。担当は2名で、転記と確認に月60時間ほどかかっている状態です。

項目	状態
受注件数	月400件程度
入力担当	2名（うち1名はパート）
転記・確認の時間	月60時間
社内の情報システム担当	いない
過去のシステム導入	1度検討したが要件がまとまらず中断

週ごとの動き

時期	やったこと	かけた時間
1週目前半	現場5名に困りごとを紙で提出してもらい、AIで分類	4時間
1週目後半	受注から請求までの流れを箇条書きで記述	6時間
2週目前半	AIに抜けを指摘させ、出た20問を現場に確認	5時間
2週目後半	必須7項目を確定、対象外と未決事項を整理	4時間
3週目前半	受注入力画面の試作を作り、担当2名に操作してもらう	8時間
3週目後半	依頼書にまとめ、3社に同じ文書を送付	5時間

合計32時間、実働で約4日分です。

この工程で起きた変化

• AIの指摘から、返品時の処理と取引先ごとの締め日の違いが未整理だと判明
• 試作を触った担当者から「入力の順番が実務と逆」との指摘が出て、外注前に修正
• 対象外を明記したことで、3社の見積りが同じ前提で比較できる状態に
• 要望のうち5項目を「今回やらない」に移し、初期の範囲を縮小

費用と時間の見立て

項目	内容
要件定義の支援費用	初期0円＋月5万円
社内でかけた時間	32時間
転記・確認の時間	月60時間 → 月20時間（想定）
削減時間	月40時間
金額換算（時給2,500円）	月10万円相当

数字そのものより重要なのは、要件が固まらず中断していた検討が3週間で前に進んだという点です。以前の中断も、技術の問題ではなく「何を頼めばいいか分からない」が原因でした。

業種別｜要件定義でつまずく点

業種によって、抜けやすい箇所が異なります。

製造業

つまずきやすいのは品番と図番の管理です。同じ製品に複数の呼び方があり、社内と取引先で番号体系が違うケースが多くあります。ここを整理せずに進めると、データ移行の段階で止まります。

建設・設備工事

案件単位で条件がすべて違うため、「標準的な流れ」が存在しないのが特徴です。無理に標準化しようとせず、「案件ごとに変わる項目」を明示するほうが実務に合います。原価の集計単位（工事別か、工種別か）も先に決めてください。

卸売・小売

取引先ごとの単価と締め日の違いが最大の落とし穴です。「基本は月末締め、ただしA社は20日締め」といった例外が必ずあります。数が多くても、依頼書には例外の件数だけでも書いてください。

士業・サービス業

案件の進捗管理が中心になりますが、顧客情報の取り扱いが要件に直結します。誰がどの情報を見られるかという権限設計を、要件定義の段階で決めておく必要があります。

医療・介護

個人情報と法令要件の比重が大きい領域です。試作にも実データを使わない、権限と記録の要件を先に固める、という2点を最初に決めてください。要件定義の自由度は他業種より低くなります。

よくある失敗の直し方

要望が現場から出てこない

「特に困っていません」と言われる場合、聞き方が悪いことがほとんどです。「困っていることは？」ではなく「この作業がなくなったら嬉しいものを3つ」と聞いてください。答えやすさが変わります。

経営者と現場で話が違う

経営者は「売上分析をしたい」、現場は「入力を減らしたい」。よくある対立です。この場合、入力を減らす仕組みを作れば、分析用のデータも自然に貯まるという順序で整理できることが多くあります。順番の問題として扱ってください。

ベンダーの説明が分からない

専門用語で説明された内容が分からないまま進めると、後で必ず困ります。その場で「それは業務でいうと何が変わりますか」と聞き返してください。答えられないベンダーは、業務を理解していない可能性があります。

見積りが会社ごとに違いすぎる

金額が3倍以上開く場合、要件の解釈が揃っていないのが原因です。安い見積りが対象範囲を狭く読んでいるだけ、というケースが大半です。各社に「どこまでを含んでいるか」を書面で確認してください。

途中で要件が増え続ける

打ち合わせのたびに要望が増えるなら、要件を確定させる日を決めていないことが原因です。「この日以降の追加は第2段階として扱う」と最初に宣言してください。追加を禁じるのではなく、行き先を作るのが要点です。

進め方チェックリスト

すべてを完璧に埋める必要はありません。埋まっていない項目が分かっている状態が、良い要件定義です。

よくある質問（FAQ）

Q. 要件定義は誰がやるべきですか？

A. 発注側の担当者です。IPAも、システムの要件を定義する責任は、そのシステムを使ってビジネスに貢献する役目を負うユーザにあるという考え方を示しています。ベンダーは技術の実現方法を担いますが、業務をどうしたいかは社内でしか決められません。実務的には、現場をよく知る人と決裁権のある人の2名体制が動きやすい形です。

Q. 情シスがいなくても進められますか？

A. 進められます。決めるべき中身の大半は技術ではなく業務の話だからです。技術的な選択（サーバーの構成、開発言語など）は、依頼書に書かず、ベンダーの提案に委ねてください。発注側が技術まで指定すると、かえって高くつきます。

Q. 要件定義にどれくらい期間が必要ですか？

A. 中小企業の1業務であれば、1〜3週間が目安です。半年かかっている場合は、完璧を目指しすぎているか、決められないことを放置している可能性があります。期間を先に決めて、その中で決まったことを書くほうがうまくいきます。

Q. 要件定義が失敗する最大の原因は何ですか？

A. 現場の業務を知らない人が書くことです。次に多いのが例外処理の見落としです。「基本的にはこう流れる」までは誰でも書けますが、急ぎの注文、数量変更、特定取引先だけの例外といった部分が抜けると、稼働後に手作業が残ります。

Q. AIに要件定義書を作らせてよいですか？

A. お勧めしません。体裁の整った文書はできますが、中身が一般論になり、自社の例外が一行も入りません。AIに任せてよいのは「集めた情報の整理」「想定質問の生成」「抜けと矛盾の指摘」までです。何を優先し何を捨てるかの判断は人がやってください。

Q. AIへの指示で気をつけることは？

A. 「書かれていないことを推測で補わないでください」を必ず入れてください。これがないと、AIは一般的な業務課題を勝手に足してきます。また、改善案まで出させると自社の意思とAIの提案が混ざるため、指摘だけを求める使い方が安全です。

Q. 取引先の情報をAIに読ませても大丈夫ですか？

A. 実名や単価はそのまま入れないでください。「A社」「B社」に置き換えるだけで、整理作業の精度はほとんど落ちません。個人情報を含むファイルも同様です。読み込ませない範囲を先に決めてから使ってください。

Q. 試作を作ってから発注する意味はありますか？

A. あります。「こういう画面が欲しい」を文章で説明しても、人によって思い浮かべるものが違います。動く画面を見せれば、認識のずれはほぼ消えます。入力項目の過不足や画面の流れは試作で確認でき、外注前に修正できます。

Q. 試作をそのまま本番で使えませんか？

A. 避けてください。試作には権限管理、データの保全、障害時の復旧手段がありません。試作の目的は本番を作ることではなく、要件を確定させることです。捨てる前提で作り、本番は要件を固めたうえで別途進めてください。

Q. 非機能要件とは何を書けばよいですか？

A. 同時に使う人数、使う時間帯、扱うデータ量、止まったときに許容できる時間、バックアップの要否、社外からのアクセスの有無です。これらは見積り金額に直結します。書いていないと、ベンダーは安全側に見積もるか最低限の構成で提案してきます。

Q. 決まっていないことは書かないほうがよいですか？

A. 逆です。「未定である」と書くことも要件定義です。何が決まっていないか、いつまでに、誰が決めるかをセットで書いてください。不明点を隠すと、ベンダーは見積りに保険を積みます。明示するほうが安くなります。

Q. 見積りが会社ごとに大きく違います

A. 要件の解釈が揃っていないのが原因です。安い見積りが対象範囲を狭く読んでいるだけ、というケースが大半です。全社に同じ依頼書を渡し、「どこまでを含んでいるか」を書面で確認してください。初期費用・月額費用・保守範囲・追加開発の単価を分けて出してもらうと比較できます。

Q. 途中で要望が増えて収拾がつきません

A. 要件を確定させる日を決めていないことが原因です。「この日以降の追加は第2段階として扱う」と最初に宣言してください。追加を禁じるのではなく、追加の行き先を作るのが要点です。

まとめ

• 要件定義は技術ではなく業務の話。情シスがいなくても進められる
• 失敗の原因は現場を知らない人が書く／完璧を目指す／将来を全部入れる／用語が揃っていない／未決を放置する
• 手順は6ステップ。1〜3週間で足りる
• AIに任せるのは整理・想定質問・抜けの指摘まで
• 優先順位と例外の判断は人が行う
• 指示文には「推測で補わないで」を必ず入れる
• 動く試作を作ってから発注すると認識のずれが減る
• 依頼書には対象外と未決事項を必ず書く
• 完璧な要件定義は不要。決められないことを決めておく

要件定義でつまずく会社の多くは、能力ではなく順番の問題です。困りごとを集め、現状を書き、優先順位をつけ、やらないことを決める。この順番さえ守れば、専門知識がなくても外注に耐える依頼書は作れます。

無料相談はこちら（初回のご相談・お見積りは無料です）

試作の作り方はバイブコーディングとは｜中小企業の業務での使い方、社内システムとAIをつなぐ仕組みはMCPとは、稟議や企画書の作成は企画書をAIで作る手順、他業務も含めた全体像は業務効率化のアイデア20選にまとめています。

基幹システムの入れ替えを前提にした要件定義では、先に判断すべきことがあります。基幹システム刷新の進め方をあわせてお読みください。