要件定義の進め方【発注側】5つの手順と記入例｜例外・完成条件・情シスとの担当表付き

AI開発の要件定義のうち、目的と決める人・今の業務・変えた後の業務の流れ・AIに渡す情報と止まったときの許容範囲・合格ラインの5つは発注側だけでまとめられ、社外に払う費用は0円、社内の時間は約46時間（人件費に換算して約15万円。後述の前提による試算）が目安です。一方で、AIで本当にできるか・どう作るか・いくらかかるかは開発会社と一緒に確かめないと決まらないため、そこから先は開発会社と進めます。当社の場合、試作を作って業務で使えるかを確かめる工程（PoC）は、検証内容の整理から評価結果のまとめまでで300万円〜です（税別。クラウドなどの実費は別）。本番システムの完成価格ではありません。

この記事は、「開発会社に頼む前に、社内で要件をまとめておくように」と言われた、あるいはまとめようとして手が止まっている経営者・事業責任者・業務部門長の方に向けて書いています。国が発注者向けに示している考え方をもとに、発注側が書くべきものと書かなくてよいものの線引き、約4週間で進める5つの手順、自分たちに質問して埋める「社内ヒアリングシート」（記入例付き）、通常と例外を分けた業務表と完成条件（受入条件）の書き方、情報システム部門・業務部門・決める人の担当表、AI開発で発注側が決めておくこと、費用と期間の目安までを順に説明します。

開発会社が使うヒアリングシートは、開発会社が発注側に聞くためのものです。この記事のシートは、発注側が自分たちに聞いて埋めるためのものです。まだ何も決まっていない段階で、先に開発会社へ相談したい場合は要件が固まっていない段階で開発会社に相談する方法をご覧ください。

発注側の要件定義が止まる3つの場面

出典: JUAS（日本情報システム・ユーザー協会） 公式サイト

社内で要件をまとめようとした担当者は、だいたい次のどこかで止まります。

1. 何から書けばいいか分からない

「要件定義書 テンプレート」で探すと、機能の一覧、画面の一覧、性能、セキュリティ対策といった項目が並んでいます。これらは主に開発会社と一緒に決める項目で、業務部門の人がゼロから埋めようとしても手が止まります。

2. 会議のたびに候補が増える

「ついでにこれも」「あの部署の作業も」と対象が広がり、どこまでを今回やるのかが決まりません。広がるほど費用の見込みも膨らみ、稟議にかけられなくなります。

3. 決めたはずのことが後から覆る

現場と部門長で決めた内容を、最後に役員が見て「そもそも目的が違う」と言う。決める人がはっきりしないまま進めると、ここで振り出しに戻ります。

これは一部の会社だけの話ではありません。一般社団法人 日本情報システム・ユーザー協会（JUAS）の「企業IT動向調査2025」は、企業が上流工程（何を作るかを決める工程）を中心に内製化（外に頼まず社内で担うこと）を進めたいと考えている一方で、「現行業務への理解不足から内製化に踏み切ることができず、ベンダーに依存し続ける」状況にあるとまとめています。同じ調査では、10年間の推移で「予定どおり完了」するプロジェクトの割合がすべての規模で低下傾向にあり、工期が悪くなる要因として、要件定義の難しさや時間不足が上位に挙がっています。

3つの場面に共通する原因は、発注側が書くべきものと、開発会社と一緒に決めるものが混ざっていることです。まず、この線を引きます。

発注側だけで決められること・開発会社と決めること・試さないと分からないこと

出典: デジタル庁 公式サイト

国の発注向けガイドは「業務要件は発注者が作るもの」としている

デジタル庁の「デジタル・ガバメント推進標準ガイドライン 実践ガイドブック」（2024年5月31日版）は、国の機関がシステムを発注するときの実務を解説した文書です。行政機関向けなので民間企業にそのまま当てはまるわけではありませんが、発注する側がどこまで自分で作るかについて、はっきり書かれている一次情報です。

同ガイドブックは、要件定義で決める要件を「業務要件、機能要件、非機能要件」の3種類に分けています。業務の言葉に直すと次のとおりです。

そのうえで、次のように書いています。

「機能要件については自動車ディーラーに相談することができますが、業務要件は車を利用したい当事者でしか定義できません」

「要件定義の実質部分を事業者に丸投げしてしまっては、その先のプロジェクトは絶対にうまくいきません」

要件定義を外部に委託する場合についても、「業務要件定義書は発注者が作るものです」とし、優先順位付けや企画内容の決定などの意思決定は発注者が責任を持って行う、としています。IPA（情報処理推進機構）の「ユーザのための要件定義ガイド 第2版」も、システムの要件を定義する責任は、そのシステムを使って事業に貢献する立場のユーザ（発注側）にあると言われている、という立場で書かれています。

3つに分けた線引き

これらの一次情報と、経済産業省がAI開発について示している「段階を分け、段階ごとに続けるか止めるかを判断する」進め方をもとに整理すると、次のようになります。

デジタル庁が2026年6月12日に改定した「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン」（DS-920）も、生成AIのシステムを企画するときは「業務知見者と生成AIシステム知見者の両者が連携する体制」を前提にしています。業務を知る発注側と、AIやシステムに詳しい人（社外でもよい）の組み合わせで進めるのが国の考え方で、発注側だけで最後まで完結させることは求められていません。

つまり、目指すのは「発注側だけで要件定義を終わらせること」ではありません。表の1段目（業務要件と合格ライン）を発注側だけで先に書き上げ、2段目と3段目を開発会社に聞ける状態にすることです。

1段目を書いてから相談すると、最初の打ち合わせが変わる

発注側で要件をまとめる5つの手順（約4週間）

出典: IPA（情報処理推進機構） 公式サイト

手順に入る前に、期間の考え方を1つ押さえておきます。JUASの「ソフトウェア・メトリクス調査2025」（2025年4月10日）では、開発全体に占める要件定義の割合が、期間では約20%なのに対し、作業量では15%前後にとどまります。調査はこの理由を、要件定義は他の工程と比べて「作業を分担して進めることが適さない」ためと説明しています。

業務の言葉に直すと、要件定義は人を増やしても早く終わらないということです。決める人と業務担当者の予定が、そのまま期間を決めます。

以下は、取りまとめ役（シートを埋めて社内を回る人。この記事を読んでいる方が担うことが多い立場です）を1人置き、決める人の確認を2回入れて、約4週間で終える組み方です。時間は後述の費用の試算と同じ前提です。

手順1：目的と決める人を決める（1週目）

やること：何を減らしたいのか・増やしたいのかを、数字で1〜2行にします。あわせて、優先順位と予算を最終的に決める人を1名決め、予算の桁（数十万円か、数百万円か）と、使い始めたい時期とその理由を聞きます。

よくある止まり方：目的が「業務効率化」「DXの推進」のまま進んでしまう。これでは、後で「うまくいったか」を誰も判定できません。「どの作業を、月何時間から何時間にするか」まで言い換えます。決める人を「関係部署の合議」にするのも避けます。合議にすると、後から「聞いていない」という声が出たときに、誰が決め直すのかが分からなくなります。

手順2：今の業務を数える（1〜2週目）

やること：対象業務を1つに絞り、誰が・どの頻度で・何件・1件何分・月何時間やっているか、使っているシステムやファイルの名前、手順、例外、ミスが起きている箇所を書き出します。月の時間は感覚で書かず、2週間（10営業日）だけ件数と時間を記録します。業務担当者の8時間の内訳は、手順の書き出し2時間、記録（1日15分×10日）2.5時間、例外とミスの洗い出し2時間、取りまとめ役からの聞き取り1.5時間です。

よくある止まり方：「人によってやり方が違うので書けない」。違いはそのまま書いてください。それが後で例外の欄になり、仕組みで扱えるかどうかを開発会社が判断する材料になります。

手順3：変えた後の流れを描く（3週目）

やること：変えた後、誰が何をするのかを手順の形で書きます。同時に、今回やらないことを書きます。「ついでにこれも」と出てきた候補は、捨てずに「次の段階の候補」として別の欄に移します。AIを使う場合は、どこで人が確認するかも、この流れの中に書き込みます（詳しくは後述）。

よくある止まり方：「全部AIに任せたい」と書いてしまう。人が確認する箇所がない流れは、国のガイドラインでリスクが高いとされる形に近づきます（後述）。

手順4：扱う情報と、止まったときの許容範囲を決める（3週目）

やること：AIや仕組みに入れる情報の種類と件数、個人情報や機密が含まれるか、社外のAIサービスに入れてよいか、結果を誰が見てよいかを、情報システムや個人情報の担当者と決めます。あわせて、止まったときにどこまで許せるか、何人が使うか、件数は増えるかを業務の言葉で書きます。

よくある止まり方：「個人情報が入っているか分からない」。社内の担当者が実物を10件ほど開いて確認します。止まったときの許容範囲を「絶対に止まらないこと」と書くのも避けます。止まらないことを求めるほど仕組みの費用は大きくなるので、「半日止まったら、手作業に戻して回せるか」で考えます。

シートのF欄にある止まったときの許容範囲などの項目は、IPAの「非機能要求グレード」の6つの大項目（可用性／性能・拡張性／運用・保守性／移行性／セキュリティ／システム環境・エコロジー）を、業務の言葉の質問に置き換えたものです。非機能要求グレードは、発注側と開発側の認識のずれを防ぐために、これらの大項目を整理しています。

手順5：合格ラインと、決まっていないことのリストを作る（4週目）

やること：過去の実際の事例を集め、「何件中何件、手直しなしで使えれば合格か」「1件でも間違えたら困るものは何か」「どうなったら本番に進まないか」を決めます。業務担当者の8時間の多くは、過去の事例に正解を付ける作業です。最後に、発注側だけでは決められないことを「開発会社に聞くことリスト」にまとめ、決める人にシート全体へ目を通してもらったうえで（1時間）、確認会議（1時間×2回）でシートを確定させます。

よくある止まり方：判定しやすい事例ばかり集めてしまう。実際の業務には例外や判断に迷うものが混ざるので、期間を区切って、届いた順にそのまま集めます。

社内ヒアリングシート（記入例付き）

「自分たちに聞く質問」の列は、そのまま自社用に使えます。記入例は、調剤薬局を20店舗運営する会社の本部が、店舗から届く報告メールの振り分けを効率化したいという架空の設定です（数字も架空です）。

A. 目的と決める人

B. 対象業務の今

C. 変えた後の姿

D. 扱う情報

E. AIの合格ライン

F. 止まったとき・使う規模

G. 決まっていないことリスト（開発会社に聞くこと）

シートを書き終えたら、G欄のリストを持って開発会社に相談します。複数の会社に同じ条件で見積もりを頼む場合は、このシートをもとにシステム開発の相見積もりとRFP（提案依頼書）テンプレートの書式に書き写すと、各社に渡す情報をそろえられます。

例外・優先順位・完成条件をシートに書き足す（記入例）

A〜G欄を書けば、開発会社に相談する材料はそろいます。ただ、見積もりと納品後の確認（検収）で食い違いが出やすいのは、業務の始まりと終わり、例外の扱い、完成の確かめ方の3つです。ここでは、前の節と同じ架空の設定（調剤薬局チェーン本部の報告メール。数字も架空）で、シートに足す表の記入例を示します。

業務の始まりと終わりを1行で決める

最初に、対象業務がどこで始まり、どこで終わるかを1行で書きます。記入例なら「店舗が報告メールを送った時点から、担当部署に通知が届き、管理表に記録が残った時点まで」です。担当部署がその報告にどう対応するかは、終わりの外に置きます（C欄の「今回やらないこと」と一致させます）。始まりと終わりが書かれていないと、開発会社ごとに見積もりに含める作業がずれ、比べられなくなります。

通常の流れと例外を分けて書く

B欄の「例外」を、ケースごとの表に広げます。頻度はB欄と同じく記録した値を書き、感覚で書きません。

例外をすべて仕組みで扱おうとすると、作る量も試す量も増えます。「人に回す」と決めた例外も、立派な要件です。そのかわり、人に回る件数と時間が、目的の数字（記入例では月10時間以下）に収まるかを確かめます。

仮定に基づく試算で確かめてみます。人に回るのが月100件（分けられない報告・判定できないもの・緊急など）で1件2分、抜き取り確認が1日10件×20営業日＝200件で1件1分とすると、100件×2分＋200件×1分＝400分で、約6.7時間です。月10時間以下に収まるので、表の扱いで進められます。収まらない場合は、後回しにした例外を必須に上げるか、抜き取りの件数を減らすかを、決める人が選びます。

必須と後回しを決める基準

今回の範囲に入れる例外（必須）と、次の段階に回す例外（後回し）は、次の順で決めます。

• 1件でも外すと困るものは必須：記入例の緊急の報告のように、割合で許せないもの
• 頻度が高く、人に回すと目的の数字に届かないものは必須：記入例の「1通に複数の報告」（約1割）など
• 頻度が低く、人に回しても目的の数字に収まるものは後回し：C欄の「次の段階の候補」に移す

後回しにした例外も、「今回は人に回す」という扱いだけは決めておきます。扱いが決まっていない例外は、誰も気づかないうちに仕組みが間違えるか、止まるかのどちらかになるためです。必須か後回しかの案は取りまとめ役が作り、最後はA欄の決める人が決めます。

完成をどう確かめるか（受入条件）

E欄の合格ラインは、AIが業務に使えるかを試す段階（PoC）の基準です。これとは別に、納品された仕組みを業務で使い始めてよいかを発注側が確かめる基準を、受入条件として書きます。例外表の各ケースと、D欄・F欄で決めたことが、そのまま確かめる項目になります。

受入条件は、開発会社との契約の前に合意しておきます。書かれていない条件は、検収のときに「完成している・していない」の食い違いになりやすいからです。テストに使うメールは、D欄で決めたとおり名前を伏せたものを使い、実物をいつ・どの形で渡すかは契約の後に決めます。

なお、例外表は手順2〜3、受入条件は手順5で一緒に作ります。前述の約46時間の試算には、受入条件を書く時間は含めていません。書く場合は手順5の時間が増えます。

生成AIで作れる部分と、自社で決める部分

例外の候補の洗い出しや、受入条件・テストケースの文章のたたき台は、ChatGPTやClaudeなどの生成AIでも作れます。B欄の手順とC欄の流れを渡して「起こりうる例外を挙げて」と頼めば、担当者が思い付かなかったケースも出てきます（D欄で決めた条件どおり、実物のメールや名前は入れません）。自社で決めるのは、ケースごとの実際の頻度、外したときの影響、必須か後回しか、合格の数字です。ここは自社の記録と判断なので、AIの出力をそのまま使わず、記録した値で置き換えます。

情シス・業務部門・決める人の担当表｜誰がどの欄を決めるか

社内で要件をまとめるとき、業務部門は「早く使い始めたい」、情報システム部門は「社内規程とセキュリティを満たしてから」と考えるのが自然で、どちらも正しい立場です。ただ、誰がどの欄を決めるかが決まっていないと、互いの確認を待って止まります。シートを書き始める前に、欄ごとの担当を1枚の表にしておきます。

次の表は、記入例の設定に合わせた説明用の分担例です（実際の案件の分担表ではありません）。会社の規模や情報システム部門の有無で変わるので、列を自社の部署名に置き換えて使ってください。

判断待ちを減らすために、あわせて次の3つを決めておきます。

• 情報システム部門の確認が要る欄を最初に伝える：D欄・F欄と、受入条件のうち権限・記録・止まったときの条件です。手順4の確認（3時間）を、あらかじめ予定に入れておきます
• 社内規程で決まっている条件を先に出してもらう：社外のAIサービスを使うときの申請、個人情報を扱うときの手続きなど。後から出てくると、C欄の流れから組み直しになります
• 意見が割れたときに、決める人が判断する期日を決める：割れた欄を空欄のまま進めないためです（よくある質問のQ1も参照）

情報システム部門が無い会社では、取りまとめ役が兼ね、D欄・F欄で判断できない点をG欄に回して開発会社に聞きます。発注企業と開発会社の間で、どこまで任せられるかは開発会社に丸投げできる範囲・できない範囲で整理しています。

AI開発で、発注側が決めておく3つのこと

出典: 総務省 公式サイト

AIを使う開発では、一般的なシステム開発の要件に加えて、次の3つを発注側で決めます。どれも開発会社には決められず、決めないまま作り始めると、終わった後に「使えるのか使えないのか」を誰も判断できなくなります。

1. 合格ラインは「割合」ではなく「何件中何件」で書く

「精度90%以上」と書くと、何に対する90%なのか、誰が数えるのかが決まりません。「過去の報告メール100件のうち、手直しなしで使える判定が90件以上」のように、元にする事例・件数・判定する人をセットで書きます。

決めるときのポイントは3つです。

• 事例は実際の業務からそのまま集める：判定しやすいものだけを選ぶと、試したときだけ合格して、本番ではうまくいきません
• 「1件でも間違えたら困るもの」を別に書く：緊急の連絡の見落としのように、割合で許してはいけないものは、全体の合格ラインとは別の条件にします
• やめる基準も一緒に書く：経済産業省の契約ガイドラインが示す段階的な進め方は、段階ごとに続けるか止めるかを判断する前提です。「確認と手直しにかかる時間が、今の作業時間の半分を超えたら本番に進まない」のように止める条件を先に決めておくと、試した結果を見て迷わずに済みます

合格ラインを試す工程（PoC）の費用と成果物は、AIのPoC費用の相場で詳しく解説しています。

2. 人が確認する箇所を「誰が・何を見て・何件に1件」まで書く

デジタル庁のDS-920は、生成AIの使い方ごとにリスクの高さを判定する例を載せています。その中で、相手のメールの内容に応じた返信を作り、職員の確認を経ずに自動で返信するものは「高リスク」、検索結果を要約して具体的な手続きのページに案内するものは「低リスク」とされています（行政機関向けの指針で、民間企業への法的な拘束力はありません）。

民間でも考え方は同じで、AIの結果が人の確認を経ずに社外や患者・顧客に届く流れは、リスクが高いと考え、確認を挟む箇所を要件の段階で決めます。

ただし、「人が確認する」と書くだけでは足りません。総務省と経済産業省が2026年3月31日に公表した「AI事業者ガイドライン（第1.2版）」は、AIエージェント（指示を受けて自分で複数の作業を進めるAI）を新たに対象に加えるとともに、人が最終判断する仕組みが形だけになるリスクと、AIの判断を信じすぎて確認がおろそかになる傾向（自動化バイアス）に注意を促しています。

形だけにしないために、シートのC欄には次の4点を書きます。

• 誰が確認するか
• 何を見て判断するか（元の文章の該当箇所など）
• 全件か、何件に1件か
• 確認に使う時間が、目的の数字（減らしたい時間）と両立するか

4点目は見落とされがちです。1日60件を毎日全件確認すると決めたら、減らせる時間はほとんど残りません。全件確認するものと抜き取りで確認するものを、目的の数字と一緒に決めます。

3. AIに渡してよい情報を、作り始める前に決める

DS-920は、権限を持つ人だけがアクセスの範囲を設定できるようにすることや、入力・出力・アクセスの記録（ログ）を取って管理することを、企画の段階で検討する項目に挙げています。あわせて、入力した内容がAIの学習に使われる設定のまま機密情報や個人情報を扱うと、入力した人以外にも情報が漏れるおそれがある、と注意しています。

IPAの「テキスト生成AIの導入・運用ガイドライン」（2024年7月）も、AIへの入力による機密情報の漏えいや、社内の資料をAIに読ませる仕組みで新たに生じるリスクへの対策を、導入・運用・セキュリティの担当者ごとに整理しています。

シートのD欄では、少なくとも次を決めておきます。

• 入れる情報に、個人情報・取引先の情報・社外秘の情報が含まれるか
• 社外のAIサービスに入れてよいか。入れる場合の条件（学習に使われない契約・設定にする、名前などを伏せてから入れる、など）
• 結果を見てよい人の範囲
• 入力・結果・閲覧の記録を残すか、どれくらいの期間残すか

シートを作る作業そのものに、社内でChatGPTなどの生成AIを使う場合も同じです。D欄を先に決めてから使ってください。

決めた後に変え続けないための3つのルール

発注側の変更が、裁判で失敗の原因とされた例

システム開発の失敗をめぐって、発注側の責任が認められた裁判があります。野村ホールディングスと野村證券が日本IBMを訴えた裁判で、一審の東京地裁（2019年3月20日判決）は日本IBMに約16億円の支払いを命じましたが、控訴審の東京高裁（2021年4月21日判決）はこれを覆し、野村側の請求を棄却したうえで、未払いの業務委託料など約1億円を野村側が支払うよう命じました。野村側が上告を取り下げ、判決は確定しています。報道によると、高裁はプロジェクトが失敗した原因を、仕様を固めた後も変更の要求を多く出し続けた発注側にあると判断しました（日経クロステック）。

個別の事情が大きい裁判なので、どの案件にも当てはまるわけではありません。ただ、「決めた後に発注側が変え続けると、その結果の責任は発注側に来うる」ことを示す実例です。デジタル庁の実践ガイドブックも、業務要件が定まっていないと、何度もシステムの要件に変更や追加が発生し、スケジュールやコストに大きなマイナスが出るとしています。

シートを作るときに、あわせて決めておく3つのルール

1. 決める人を1人にし、シートのA欄に名前を書く：関係部署の意見は取りまとめ役が集め、最後は1人が決めます
2. シートを確定する日を決め、それ以降の変更は1つの窓口で受けて記録する：変更の理由、言い出した人、決めた人を1行ずつ残します。現場の担当者が開発会社に口頭で直接伝えるのはやめます
3. 変更には費用と期間がかかることを、開発会社との契約の前に合意する：変更の見積もりの出し方と、決める人の承認を経てから作業に入る手順を決めておきます

小さな修正まで禁止する必要はありません。避けたいのは、確定した後に、目的や対象範囲を覆す変更が続くことです。追加費用が発生する典型的なパターンはシステム開発の追加費用、発注側の進め方が原因でつまずく例はAI開発が失敗する原因にまとめています。

発注側がどこまで書くか｜3つの分担のしかた

要件をまとめる方法は、発注側がどこまで書くかによって大きく3つに分かれます。どれが正解ということはなく、社内の状況によって合う方法が変わります。

デジタル庁の実践ガイドブックの考え方（業務要件は発注者が作り、機能要件を文書にする作業は事業者が行うことが多い）に最も近いのは②です。社内にシステム企画の経験者がいない会社でも、①まで背伸びせず②で止めれば、社内だけで進められる範囲を無理なく使い切れます。

③を選ぶ場合、要件定義は「作業した期間や時間に対して払う契約（準委任契約）」で依頼するのが一般的です。契約の形の違いはAI開発の契約形態、そもそも外部に頼むか社内で作るかから迷っている場合は生成AIの内製と外注が判断の材料になります。

なお、シートを書いてみて、対象が「毎月決まった手順で繰り返している作業」だと分かった場合は、システムを一から作るより、既存の業務自動化のサービスで足りることがあります。その場合の費用の比べ方はAIエージェントの導入費用をご覧ください。

費用と期間の目安

社内でシートを作る場合：社外費用0円、社内の時間は約46時間

※手順の節の時間を積み上げた試算で、調査データではありません。業務担当者が2名なら、合計67時間・約21万円です。対象業務が複数の部署にまたがる場合は、部署の数に応じて手順2〜5の時間が増えます。

この46時間は、開発会社に要件定義を頼んでも、なくなる時間ではありません。デジタル庁のガイドブックが言うとおり、業務要件は発注側にしか決められないので、開発会社に頼めば同じ内容を聞き取りや定例の中で聞かれます。違いは、社内の都合のよいタイミングで先に書くか、開発会社の予定に合わせて答えるかです。

要件定義を開発会社に頼む場合の相場（他社の公開情報）

公開されている金額は幅が大きく、根拠が示されていないものも多いので、「簡易なものでも数十万円から、中規模なら数百万円」という桁の目安として使ってください。

当社の価格

初回相談は無料・30分（オンライン、Google Meet）で、シートが途中までしか埋まっていない段階でもご相談いただけます。G欄の「開発会社に聞くこと」や、書きかけの例外表・受入条件をお持ちいただければ、自社でAIを使って進める部分と任せる部分を一緒に切り分けます。相談後に、依頼範囲の候補・進め方・費用の目安をまとめた相談メモをお送りします。要件定義書の作成を当社に頼む場合は有償で、始める前に範囲と金額をお示しして合意をいただきます。料金に含まれる範囲と進め方の詳細は、受託開発サービスの料金と進め方に載せています。

▶ 要件と完成条件の整理を相談する（無料・30分）

AI開発全体の費用感はAI受託開発の費用相場、AIを使わない業務システムの場合は業務システム開発の費用相場をあわせてご覧ください。

当社の公開実績｜シートのどの欄に当たる要件か

公開できる範囲で、当社が業務整理・要件定義から開発までを担当した2件を紹介します。社名・金額・効果の数字は公開していません。どちらも、この記事の記入例（調剤薬局チェーン本部の報告メール。架空の設定）とは別の案件です。

薬局：複数店舗・数千人分の記録を管理するシステム

課題：店舗ごとに分かれていた記録と確認の状況を、担当者間で把握できるようにしたい。

担当した範囲：業務整理、要件定義、システム開発。

成果物：記録管理システム、店舗・担当者ごとの権限設計、確認工程の整理。

シートとの関係：この記事のシートでいえば、D欄の「結果を見てよい人」（誰にどの店舗の記録を見せるか）と、C欄の「人が確認する箇所」（どの工程で誰が確認するか）を決める要件に当たります。担当表で情報システムの担当と決める人が関わる欄です。

通信事業：数万件の請求情報をまとめて計算する仕組み

課題：件数の多い請求情報の集計を、担当者の手作業に頼らずに行いたい。

担当した範囲：集計ルールの整理、要件定義、システム開発。

成果物：請求情報の取り込み・集計処理、確認対象を絞り込む管理画面。

シートとの関係：B欄の件数と例外、そして「全件を人が見るか、確認する対象を絞るか」を決める要件（C欄と例外表）に当たります。

シートを作った後の流れと期間

上の段階は当社の進め方ですが、発注側の列は他社に相談する場合にもそのまま使えます。当社の受託開発では、作る前に目的と完成条件をそろえる進め方をとっています。対応できる工程の範囲は受託開発サービスの進め方をご覧ください。

開発会社との要件定義にかかる期間の目安

シートで書いた業務要件に、機能や性能などの要件を加えて要件定義を終えるまでの期間は、開発全体の規模で変わります。JUASのソフトウェア・メトリクス調査2025は、標準的な開発期間（月）を「3.23 × 作業量（人月）の立方根」という式で示しています。これに、要件定義が期間の約20%を占めるという同じ調査の比率を当てはめると、次のようになります。

※調査の式と比率を当てはめた試算で、調査結果そのものではありません。人月は、1人が1ヶ月で行う作業量の単位です。JUASの調査は業務システムの開発が中心で、AI開発に特化した数字ではありません。

社内でシートを作る約4週間は、開発会社との要件定義の前に置く期間です。稟議や契約にかかる期間も含めたスケジュールの組み方はAI開発の期間で解説しています。相談先の見極め方はAI開発会社の選び方にまとめています。

よくある質問

Q1. 業務部門と情報システム部門で、書く内容の意見が割れたらどうすればいいですか。

割れやすいのは、D欄（AIに渡してよい情報）とF欄（止まったときの許容範囲）です。業務部門は「使えなければ意味がない」、情報システム部門は「漏れたら責任を取れない」という立場から意見を出すので、どちらも間違ってはいません。この場合は、A欄に書いた決める人に、両方の案を並べて判断してもらいます。「名前を伏せてから入れる」「社外のAIサービスは使わない」のように条件を変えた案ごとに、実現できるか・費用がどう変わるかをG欄に書き足し、開発会社に聞いてから決めても遅くありません。避けたいのは、意見が割れた欄を空欄のまま先に進むことです。空欄は、開発会社ごとに見積もりの前提がばらつく原因になります。どちらの案を誰が書き、誰が決めるかは、前述の担当表で先に決めておくと、割れたときに慌てずに済みます。

Q2. 要件をまとめている途中で、決める人が異動や退職で交代しました。

新しい決める人に、A欄、C欄の「今回やらないこと」、E欄の合格ラインの3か所だけは確定し直してもらってください。この3か所は決める人の判断そのもので、前任者の決定を黙って引き継ぐと、後から「自分は同意していない」という形で覆りやすい部分です。反対に、B欄（今の業務の数字）は事実の記録なので、決め直す必要はありません。交代のたびに全体をやり直すと期間が延びるので、「変わるのは判断の欄だけ」と切り分けて、短い確認で済ませるのが現実的です。交代に備えて、判断の欄には「なぜそう決めたか」を1行ずつ残しておくと、引き継ぎが速くなります。

Q3. 現場が忙しく、2週間も記録を取る余裕がありません。

記録の代わりに、すでにある数字から数える方法があります。メールなら受信フォルダの件数、システムへの入力なら登録の件数、紙の帳票なら綴りの枚数から、1ヶ月の件数が分かります。1件あたりの時間は、担当者に数件だけ実際にやってもらい、時間を測れば目安が出ます。件数×1件あたりの時間で月の時間を出し、「推定」と書いておけば、開発会社に相談する材料としては十分です。記録を取る場合でも、月末だけ件数が増えるような業務は、月末を含めないと月の時間を小さく見積もってしまう点に注意してください。

Q4. シートを持って相談したら「AIを使わないほうがいい」と言われました。シートは無駄になりますか。

無駄にはなりません。B欄（今の業務）、C欄（変えた後の流れ）、F欄（止まったとき・使う規模）は、AIを使うかどうかに関係なく、業務システムを作るとき、既製のサービスを選ぶとき、手順そのものを見直すときにもそのまま使えます。「AIでなくてよい」と早く分かったことで、試す費用をかけずに済んだとも言えます。確認したいのは、その理由です。「件数が少なく、仕組みを作る費用に見合わない」「決まった形式のデータなので、AIを使わない処理のほうが確実」のように、理由がB欄の数字や業務の中身と結びついて説明されていれば、判断として信頼できます。

Q5. シートの下書きを、ChatGPTなどの生成AIに作らせてもいいですか。

使える部分と、使わないほうがいい部分があります。使えるのは、担当者から聞き取ったメモを欄ごとに振り分ける、例外の洗い出しに抜けがないかを確認する、といった作業です。使わないほうがいいのは、B欄の件数と時間、C欄の今回やらないこと、E欄の合格ラインです。ここは自社の事実と判断なので、AIが書くともっともらしい一般論になり、開発会社の見積もりの前提として役に立ちません。また、下書きを作らせる前にD欄を決め、患者名・顧客名・取引先名などを入力しないこと、使うサービスの設定（入力内容が学習に使われるかどうか）を確認することを守ってください。

Q6. 秘密保持契約を結ぶ前に、シートをどこまで開発会社に見せていいですか。

シートは「契約前に渡す版」と「契約後に追加で渡す資料の一覧」に分けて作っておくのがおすすめです。契約前の版には、A欄（目的と数字の目標、予算の桁、時期）、B欄の件数・時間・使っているシステムの名前、C欄の流れ、G欄のリストを入れます。「患者の名前が書かれることがある」といった、情報の種類を伝えるだけなら実物は出ていません。契約の後にしたいのは、実物のメールや帳票、顧客や患者の情報が入ったデータ、社外秘の業務ルールそのものです。分けておくと、複数の会社に相談する場合も、各社に見せる範囲がそろいます。社内に情報の持ち出しに関する規程がある場合は、そちらを優先してください。

Q7. 要件定義書の決まった書式（WordやExcelのひな形）はありますか。

すべての会社が使う決まった書式はありません。IPAやデジタル庁は項目や考え方を示していますが、実際の書式は会社ごとに異なります。発注側が作るのは、この記事のシートのように業務の言葉で書いた業務要件までで十分です。機能や性能の要件を文書にする作業は、デジタル庁のガイドブックでも事業者（開発会社）が行うことが多いとされており、書式は開発会社側のものに合わせるのが一般的です。発注側が気をつけたいのは書式ではなく、開発会社がまとめた要件定義書を受け取ったとき、シートのA〜F欄の内容がどこに反映されているかを1つずつ確かめることです。反映されていない欄があれば、その場で理由を聞いてください。

Q8. 受入条件で決めた確認は、発注側が自分でやるのですか。

合否を判断するのは発注側です。テストの手順書や、テスト用の環境・データの準備は、開発会社と分けて担う形もあります。どちらが何を用意するかは、受入条件と一緒に契約の前に決めます。発注側が用意しておきたいのは、E欄で正解を付けた過去の事例と、例外表のケースごとのテスト用データ（名前を伏せたもの）です。確かめる人には、実際に使う人（記入例では本部スタッフ）を入れてください。条件どおりに動くかに加えて、確認の手間が目的の数字に収まるかも、その場で分かります。

要件と完成条件の整理から相談できます

• シートのB欄までは書けたが、C欄から先で手が止まっている
• E欄の合格ラインを、どの数字で置けばいいか分からない
• 例外のどこまでを今回の範囲に入れるか、受入条件をどう書くかが決めきれない
• 情報システム部門と業務部門で、どの欄を誰が決めるかがまとまらない
• G欄のリストが長くなり、AIでできるのか、そもそも作るべきなのかも分からない

このような段階からのご相談をお受けしています。初回相談は無料・30分（オンライン）で、要件が決まっていなくても大丈夫です。相談後に、依頼範囲の候補・進め方・費用の目安をまとめた相談メモをお送りします。当社の価格は、既存システムの改修 100万円〜、PoC 300万円〜、本開発は個別見積です（すべて税別。クラウドや外部サービスの利用料などの実費は別）。

ご相談の際は、書けたところまでのシートをお持ちください。空欄は空欄のままで構いません。実物のメールや、顧客・患者の情報が入ったデータは送らないでください。どの欄を社内で決め、どの欄を一緒に確かめるかの整理からご一緒します。

▶ 要件と完成条件の整理を相談する（無料・30分）

関連記事：要件が固まっていない段階で開発会社に相談する方法／システム開発の相見積もりとRFPテンプレート／AIのPoC費用の相場／AI開発の契約形態／AI開発が失敗する原因