要件定義の進め方——決める7項目と5ステップ、発注者が担う範囲【2026年版】

来週から要件定義が始まる。ベンダーからは「業務を教えてください」と言われているが、何をどこまで話せばよいのか分からない。社内からは要望が次々と上がってきて、気づけば機能一覧が100項目を超えている——要件定義の入口で止まってしまう方は少なくありません。

先に結論を書きます。要件定義でつまずく理由は、業務知識の不足ではありません。「要求」と「要件」を分けていないからです。現場から出てくる要望は要求であり、そのすべてが要件になるわけではありません。要件とは、予算と期限の中で今回採用すると決めたものです。要求には制限がありませんが、要件は必ず有限になります。

この違いがはっきりすると、要件定義の本体が見えてきます。集めることではなく、選ぶことです。そして選ぶ基準を持てるのは、事業の目的と予算を知っている発注者だけです。ヒアリングの設計も、文書にする作業も、ベンダーに任せてかまいません。任せられないのは、どれを今回やるかという判断です。

私はTALENTBASE VIETNAMでCOOを務めています。当社は受注する側として要件定義に入る立場です。2018年以降、約100社のご相談を受けてきましたが、進みが速い案件には共通点があります。現状の業務フローが1枚にまとまっていること、出てきた要望が「必須・あると良い・今回やらない」に仕分けられていること、そして決める人が1名決まっていることです。この3つがあると、初回の打ち合わせから中身の議論に入れます。当社は日本人PMがフロントに立ち、ヒアリングの設計と要件の整理、仕様の文書化を担います。最小構成は日本人PM+2〜3人月で月額約80万円から、1名から最短2週間で開始できます。

この記事では、要件定義で決める7項目、進め方の5ステップと発注者・ベンダーの役割分担、優先順位のつけ方、よくある失敗とその回避策、そして契約形態と費用の考え方を整理します。読み終えたら、業務フローを1枚にまとめて、手元の要望を3つに仕分けてみてください。この2つができていれば、初回の打ち合わせは確実に前に進みます。

要件定義で決めるもの——「要求」と「要件」は違う

要件定義という言葉は広く使われていますが、何を決める工程なのかは意外と共有されていません。ここを最初に押さえると、自分が何をすればよいかが見えてきます。

要件定義とは何を決める工程か

RFP(提案依頼書)は「こういう状況なので提案してください」と依頼する文書です。要件定義は、受注が決まったあとに「では、こう作ります」を確定させる工程です。順番でいうとRFPが先、要件定義が後になります。

要件定義の成果物は、その後2つの用途で使われます。ひとつは開発の見積もりの根拠。もうひとつは検収の基準です。「これができていれば完成」と言える状態を、この工程で作ります。だから曖昧なまま通すと、後の工程すべてに影響します。

決める7項目

要件定義で決める内容は、おおむね次の7つに整理できます。

非機能要件は技術者が決めるものと思われがちですが、そうではありません。「月末の締め処理の日は1時間止まっても業務は回るのか」といった判断は、業務を知っている側にしかできません。技術的な実現方法を決めるのはベンダーです。

要求は無限、要件は有限

ここが核心です。現場から上がってくる要望は「要求」です。要求には制限がありません。日々の不便を知っている人に聞けば、いくらでも出てきます。それをすべて積み上げると、見積もりは予算を超えます。

「要件」とは、その要求のうち、予算と期限の中で今回採用すると決めたものです。必ず有限になります。つまり要件定義の本体は、集めることではなく選ぶことです。

当社は受注する側として要件定義に入る立場です。機能一覧が100項目を超えた状態でご相談をいただくことがありますが、このとき必要なのは追加のヒアリングではなく、優先順位の決定です。決めるものが分かったところで、次は進め方を見ていきます。

進め方の5ステップと、発注者・ベンダーの役割分担

要件定義は、おおむね5つの段階を踏みます。段階ごとに発注者が何をするかを先に決めておくと、打ち合わせが待ち時間だらけになりません。

5つのステップと、各段階で発注者がやること

発注者の負担が集中するのはステップ3です。ここで決めきれないと、以降の工程がすべてぐらつきます。逆に言えば、ステップ2と4の作業量はベンダーに任せてかまいません。当社の場合、日本人PMがヒアリングの設計と要件の整理、仕様の文書化を担います。

優先順位のつけ方——必須・あると良い・今回やらない

分類は3つで足ります。「必須」は、これがなければ業務が回らないもの。「あると良い」は、あれば効率が上がるが、なくても運用できるもの。「今回やらない」は、将来やる可能性はあるが今回の予算と期限では対象外にするものです。

判断に迷ったときの基準を2つ挙げます。ひとつ、その機能がなかった場合に業務が止まるか。止まるなら必須です。ふたつ、代替手段があるか。手作業やExcelで当面しのげるなら、今回やらないに回せます。

大事なのは伝え方です。「削る」と言うと現場は反発しますが、「順番を決める」と言えば話が通ります。今回やらないものを一覧にして残し、次のフェーズの候補として明示してください。要望を否定したわけではないと分かる形にすると、協力が得られます。

初回までに用意すると進みが速い2つ

当社が要件定義に入る案件で、進みが速いものには共通点があります。3つあります。

ひとつ、現状の業務フローが1枚にまとまっていること。図でなくてもかまいません。「誰が、何を受け取り、どう処理して、次の誰に渡すか」が順に書いてあれば十分です。ふたつ、出てきた要望が3分類に仕分けられていること。仕分けが暫定でも、議論の出発点になります。みっつ、決める人が1名決まっていること。複数人の合議だと、その場で決まらず持ち帰りが増えます。

この3つがあると、初回の打ち合わせから中身の議論に入れます。逆にこれがないと、最初の2〜3回は現状の把握だけで終わります。削るのではなく、順番を決める。この言い換えを手元に置いておいてください。

失敗を防ぐ——よくある3つと、契約・費用・2026年の論点

最後に、つまずきやすい型と、契約や費用の考え方を整理します。失敗の形は限られているので、先に知っておけば避けられます。

よくある失敗3つと回避策

ひとつ目は「決めたつもりで決まっていない」です。打ち合わせで「では、その方向で」と終わり、文書に残っていない。回避策は簡単で、決定事項を議事録の冒頭に箇条書きで書き、次回の冒頭で読み合わせることです。

ふたつ目は「後出しの要求でスコープが膨らむ」です。要件定義の後半や開発中に新しい要望が出てくる。これはゼロにはできないので、扱いを決めておきます。出てきた要望は一度「次フェーズ候補」に入れ、今回入れるかどうかは工数と費用の見積もりを見てから判断する。この手続きがあれば、断ることも受け入れることも冷静にできます。

みっつ目は「部門間の要求衝突が終盤に噴出する」です。営業部と経理部で欲しいものが違う、といった状態が最後まで放置される。回避策は、ステップ3の段階で関係部署を同席させ、その場で優先順位を決めることです。個別ヒアリングだけで進めると、衝突は必ず終盤に来ます。

要件定義は有償の作業——契約形態と費用の考え方

要件定義は作業です。ヒアリング、整理、文書化に人の時間がかかります。無償で対応する会社もありますが、その場合は提案の一部として簡易に行われるのが一般的です。しっかり作るなら有償になります。

契約形態は準委任で進めることが多くなります。民法632条の請負は「仕事の完成」を内容とするため、何を作るかが確定していない要件定義の段階では、完成を定義できないからです(当社の整理)。なお、契約形態についての本記事の記述は一般的な整理であり、法的助言ではありません。個別の契約の判断は弁護士にご確認ください。当社が提供しているラボ型も準委任で、要件定義から継続して同じチームで進められます。最小構成は日本人PM+2〜3人月の月額約80万円から。1名から最短2週間で開始でき、増員は約1週間です。単価は実務3年で1,500USD、5年で2,000USD、ブリッジSEで3,000USD(1USD=150円換算が目安)と公開しています。

伺った内容から、要件定義を先に別の専門会社に依頼したほうがよいと判断することもあります。その場合は率直にお伝えします。

2026年、AIは要件定義をどう変えたか

生成AIの普及で、議事録の整理、要望の分類の下書き、要件定義書の草案作成は支援できるようになりました。当社もAIを活用した開発体制を組んでいます。作業時間は確実に減っています。

ただし、変わらないことがあります。どれを今回やるかという判断です。AIは選択肢と影響を整理できますが、事業の目的と予算に照らして決めることはできません。作業が速くなったぶん、決める人の不足がボトルネックとして目立つようになりました。あなたの手元で、業務フローは1枚にまとまっていますか。

よくある質問

要件定義について、実務でよく届く質問に答えます。いずれも初めて要件定義に関わる担当者から繰り返し聞かれる内容です。

Q1. 要件定義の期間はどのくらいですか

一律の目安は設けていません。期間は規模ではなく、決まっていないことの数で決まるからです。当社は、この記事で挙げた決める7項目のうち埋まっていない項目の数、要求を出す関係部署の数、既存システムとの連携の数の3つで見積もります。関係部署が多い、既存システムとの連携が多い場合は長くなります。逆に、決める人が1名に定まっていて業務フローが1枚にまとまっていれば、同じ規模でも短く済みます。

Q2. RFPと要件定義はどう違いますか

RFPは発注前に「提案してください」と依頼する文書、要件定義は受注後に「こう作ります」を確定させる工程です。順番はRFPが先です。

Q3. 要件定義をベンダーに任せきりにできますか

ヒアリングの設計と文書化は任せられます。ただし、どれを今回やるかの判断と、業務上の許容範囲(止まってよい時間など)は発注側で決めてください。

Q4. 要件定義の途中で要求が変わったらどうしますか

変更は起きる前提で、扱いを決めておきます。新しい要望は一度「次フェーズ候補」に入れ、工数と費用の見積もりを見てから今回入れるかを判断してください。

Q5. 要件定義の成果物は自社で保管できますか

契約に成果物として明記すれば受け取れます。当社は設計書や運用手順を納品物に含める運用です。次の会社に渡せる資産として。

まとめ: 要件定義の本体は、集めることではなく選ぶこと

要件定義でつまずく理由は、業務知識の不足ではありません。要求と要件を分けていないからです。現場から上がってくる要望は要求であり、制限がありません。要件は、予算と期限の中で今回採用すると決めたもので、必ず有限になります。だから要件定義の本体は、集めることではなく選ぶことです。そして選ぶ基準を持てるのは、事業の目的と予算を知っている発注者だけです。

決める項目は7つです。業務要件、機能要件、非機能要件、画面・UI要件、データ要件、外部連携要件、運用・保守要件。非機能要件は技術者が決めるものと思われがちですが、「月末の締め処理の日に1時間止まっても業務は回るか」といった許容範囲の判断は発注側にしかできません。進め方は5ステップで、体制づくり、ヒアリングと現状分析、要求の整理と優先順位づけ、要件の確定と文書化、合意形成と引き継ぎ。発注者の負担が集中するのは3番目です。ヒアリングの設計と文書化は、ベンダーに任せてかまいません。

優先順位は「必須・あると良い・今回やらない」の3分類で足ります。判断の基準は2つで、その機能がないと業務が止まるか、手作業やExcelで当面しのげるか。伝え方も大事で、「削る」ではなく「順番を決める」と言えば現場の協力が得られます。今回やらないものは一覧に残し、次フェーズの候補として明示してください。失敗の型は、決めたつもり、後出しの要求、部門間の衝突の3つです。いずれも議事録での決定事項の読み合わせと、関係部署の同席で防げます。発注前の依頼書についてはシステム開発のRFPの書き方、任せ方の設計はシステム開発の外注を丸投げにしない線引きもあわせてご覧ください。当社は日本人PMがヒアリングの設計と要件の整理、仕様の文書化を担うラボ型(準委任)で、最小構成は日本人PM+2〜3人月の月額約80万円から、1名・最短2週間で開始できます。まずは業務フローを1枚にまとめ、要望を3つに仕分けてみてください。現在の体制と要件をお聞かせいただければ、進め方を含めてお答えします。合わない案件にはその旨も率直にお伝えします。