要件定義の進め方【発注側向け】AI開発で社内だけで決められる範囲と記入例付きヒアリングシート【2026年9月最新】

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件ほど開いて確認します。止まったときの許容範囲を「絶対に止まらないこと」と書くのも避けます。止まらないことを求めるほど仕組みの費用は大きくなるので、「半日止まったら、手作業に戻して回せるか」で考えます。

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

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

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

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

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

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

A. 目的と決める人

B. 対象業務の今

C. 変えた後の姿

D. 扱う情報

E. AIの合格ライン

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

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

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

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

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

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

当社の価格

初回相談は無料で、シートが途中までしか埋まっていない段階でもご相談いただけます。G欄の「開発会社に聞くこと」をそのままお持ちいただければ、「既存の方法で足りそうか」「試さないと分からないか」「作るならどの価格帯か」を整理します。料金に含まれる範囲と進め方の詳細は、受託開発サービスの料金と進め方に載せています。

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

実際にやった事例｜シートのどの欄が結果を分けたか

守秘の関係で社名は出せません。当社が担当した3件を、この記事のシートのどの欄に当たる決定が効いたか、という観点で紹介します。

調剤薬局のケース：C欄「今回やらないこと」で、案件の規模が変わった

課題：使っている業務システムからデータを書き出し、Excelで加工して、別のシステムや管理表へ手で転記する作業が毎日発生していた。担当者が休むと業務が止まり、繁忙期には転記漏れも起きていた。どこまで直すべきかが決まっておらず、他社からは基幹システムの入れ替えを含む提案も出ていた。

決めたこと：「既存システムは残す」「対象は毎日発生している転記1箇所だけ」と、やること・やらないことを決めた。

作ったもの：既存システムはそのままに、データの取り込みと加工、次のシステムへの受け渡しを自動で行う仕組み。新しいシステムは導入していない。

何が変わったか：転記作業そのものと、転記ミスを探して直す時間がなくなり、担当者が休んでも業務が流れるようになった。相談から稼働までは約5週間。全社的なシステム刷新にしていれば、同じ困りごとでも半年単位の案件になっていた。

医療機関のケース：E欄「合格ライン」を先に決め、拡大の判断が2週間で済んだ

課題：蓄積された文書や記録は多いのに、必要な情報を探すのに時間がかかっていた。AIで効率化したい業務の候補は複数あり、全部を対象にすると費用も期間も膨らんで、稟議にかけられない状態だった。

決めたこと：候補の中から1業務に絞り、着手の前に「どの質問に、どの水準で答えられたら合格か」を文書で決めた。AIでどこまでできるかは試さないと分からないため、PoCとして進めた。

作ったもの：手元の資料をAIに読ませ、質問すると根拠となる箇所を示しながら答える仕組み。

何が変わったか：合格ラインが先に決まっていたため、拡大するかどうかを2週間で判断できた。本開発に進む範囲を、現場の言葉と数字で社内に説明できるようになった。期間は約3ヶ月。

インフラ企業のケース：G欄に当たる「データを取り出せるか」を要件定義で確かめ、変更の費用も先に決めた

課題：複数の社内システムにまたがるデータを人が突き合わせて確認しており、件数が多く、月末に負荷が集中していた。どのシステムから、どういう形でデータを取り出せるかは、一つずつ確認する必要があった。

決めたこと：要件定義の中で各システムのデータの取り出し方を確認し、つなぐシステムの本数を確定させた。つなぐ先が1本増えた場合の追加費用も、最初の見積もりの段階で決めた。

作ったもの：システム間のデータを自動で照合し、食い違いがある分だけを人に回す仕組み（本開発）。

何が変わったか：全件を人が見る運用から、例外だけを人が見る運用に切り替わり、月末に集中していた負荷が平準化された。途中で業務側の要望が増えても、追加費用をその場で計算できる状態を保てた。期間は約7ヶ月で、そのうち要件定義が2ヶ月。

3件とも、範囲・合格ライン・変更の扱いといった発注側が決める事柄を先に固め、AIでどこまでできるか・データを取り出せるかといった発注側だけでは分からない事柄を、その後の工程で確かめる順番になっていました。期間を左右したのは技術の難しさより、確認が必要な範囲の広さでした。

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

上の段階は当社の進め方ですが、発注側の列は他社に相談する場合にもそのまま使えます。当社では、事業・開発・セキュリティの担当が1つのチームで対応します。対応できる工程の範囲は受託開発サービスの進め方をご覧ください。

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

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

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

当社の事例では、小規模な改修で相談から稼働まで約5週間、PoCで約3ヶ月、本開発で約7ヶ月（うち要件定義2ヶ月）でした。社内でシートを作る約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つずつ確かめることです。反映されていない欄があれば、その場で理由を聞いてください。

要件定義のどこまでを社内で書くか、から相談できます

• シートのB欄までは書けたが、C欄から先で手が止まっている
• E欄の合格ラインを、どの数字で置けばいいか分からない
• G欄のリストが長くなり、AIでできるのか、そもそも作るべきなのかも分からない

このような段階からのご相談をお受けしています。当社の価格は、PoC 300万円〜、既存システムの小規模改修 30万円〜、本開発は個別見積（すべて税別）で、初回相談は無料です。医療機関・調剤薬局・インフラ企業での開発実績があります。

ご相談の際は、書けたところまでのシートをお持ちください。空欄は空欄のままで構いません。どの欄を社内で決め、どの欄を一緒に確かめるかの整理からご一緒します。

▶ 受託開発の詳細・無料相談はこちら

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