要件定義とは？システム開発で失敗しない進め方

01はじめに｜要件定義とは、最初につまずきやすい工程です

要点： 要件定義とは、システムで何をどこまで実現するかを具体的に決め、文書として残す工程です。開発工程のいちばん最初にあり、ここで決めきれなかった分だけ、あとの工程で費用と時間に跳ね返ってきます。決めるのは発注側の仕事です。

「システム開発は要件定義が大事」。この言葉自体は、どこでも目にします。ただ、実際にご相談をいただくと、多くの方が引っかかっているのは別のところです。「大事なのは分かるが、自分が何を決めればいいのか分からない」。これが本当の悩みではないでしょうか。

要件定義とは、作るものの中身を決めて文書にする工程です。落とし穴もあります。開発会社と数回打ち合わせをして方向性が見えると、決まった気になってしまうのです。ところが議事録を読み返すと、画面の項目も、権限の範囲も、月末処理の扱いも、何ひとつ確定していません。

この記事では、2000年創業のWeb制作・システム開発会社ZenWeb Japanが、発注側の立場で要件定義の進め方を整理します。「明日の打ち合わせで、自分が何を持っていけばいいか」が分かる形にしました。開発全体の流れはWebシステム開発サービスのページにまとめています。

まずは、要件定義の全体像をつかめる動画をご覧ください。決めるべき項目と進め方が、順を追って整理されています。

02要件定義・要求定義・要求仕様書は、それぞれ何が違うのか

要点： 要求定義は「発注側がやりたいこと」、要件定義は「それを実現するために作るもの」です。要求仕様書は発注側が要望をまとめた文書、要件定義書は開発会社と合意した仕様の文書。順番は、要求定義 → 要求仕様書 → 要件定義 → 要件定義書となります。

言葉が似ているので混乱しやすいところです。区別する実益ははっきりしています。どちらの文書に書いてあるかで、責任の所在が変わるからです。

• 要求定義。 「毎月の請求書作成に3日かかっているので、半日にしたい」。業務の困りごとと、達成したい状態を言葉にする段階です。発注側が主役になります。
• 要求仕様書（RFP に添える資料を含む）。 要求定義の内容を文書にしたもの。開発会社に渡して、見積りと提案の土台にしてもらいます。
• 要件定義。 「請求データを取り込み、承認を1段階にして、PDFで一括出力する」。要求を、作れる形の仕様に翻訳する段階です。開発会社が主導し、発注側が確認して合意します。
• 要件定義書。 合意した内容の文書。以後の見積り、開発、検収は、すべてこの文書を基準に進みます。

実務でいちばん多いつまずきは、要求定義を飛ばして、いきなり要件定義から始めてしまうことです。「こういう画面が欲しい」から入ると、その画面が本当に必要かを誰も検証しないまま作ることになります。困りごとから始めれば、画面を作らずに解決できる場合も見つかります。要求仕様書の書き方に迷うときは、見積りの読み方をまとめた記事もあわせてご覧ください。

03要件定義の進め方｜発注側が踏む5つのステップ

要件定義の進め方は、現状の棚おろし → 目的の言語化 → 範囲の線引き → 仕様の確定 → 合意の5段階です。順番を入れ替えないでください。範囲を決める前に仕様を詰めると、決めた内容が次々にひっくり返ります。

ここでの主役は発注側です。開発会社は書式を整え、抜けを指摘し、実現方法を提案しますが、「うちの業務ではこうする」を決められるのは業務を持っている側だけです。

要件定義の進め方（5ステップ）

打ち合わせの進行表としてそのまま使えます。1回で1ステップずつ進めれば、1〜2か月で終わります。

1. 現状の業務を棚おろしする。 誰が、いつ、どの資料を使って、何をしているか。実際に使っているExcelや帳票をそのまま持ち寄り、いま動いている手順を書き出します。
2. 目的を数字で言い切る。 「効率化したい」では判断ができません。「月末の3日を半日にする」「転記ミスを月10件からゼロにする」のように、達成したかどうかを後で確認できる形にします。
3. やらないことを先に決める。 今回作る範囲より先に、今回は作らない範囲を決めます。これが最も効きます。「在庫は今回対象外」と紙に書いておくだけで、あとの議論が短くなります。
4. 画面と項目まで下ろす。 どんな画面があり、どの項目を入力し、誰が承認し、何が出力されるか。ここまで下ろして初めて、見積りが実際の金額に近づきます。
5. 要件定義書に署名して合意する。 読み合わせをして、その場で承認します。ここを口頭で済ませると、あとで「言った・聞いていない」が必ず起きます。

3番目の「やらないことを先に決める」だけは、順番を守ってください。範囲が開いたまま画面の話を始めると、打ち合わせのたびに新しい要望が足され、いつまでも終わりません。

04要件定義で決める項目｜機能要件と非機能要件の切り分け

要点： 決める項目は、機能要件（何ができるか）と非機能要件（どんな状態で動くか）の2つに分かれます。抜けやすいのは後者です。速度・同時利用人数・稼働時間・保存期間は、書いていないと後から費用が動く代表格です。

機能要件は打ち合わせで自然に話題になります。問題は非機能要件です。「動けばいい」と考えていると、動いた後に困ります。10人で使う前提の設計に50人が同時にログインすれば、当然遅くなります。下の表を、そのまま抜けチェックに使ってください。

右端の列を縦に読んでみてください。「発注側」と書かれた行は、開発会社がどれだけ優秀でも代わりに決められません。逆に言えば、この5〜6項目さえ社内で先に固めておけば、要件定義の打ち合わせは驚くほど速く進みます。

05データで見る｜工期・予算・品質を狂わせる要因の上位

要点： 国内のユーザー企業981社への調査では、工期・予算・品質のいずれを悪化させた要因でも、上位に「要件定義の難易度向上」が入っています。工期では51.0%と最も高く、原因は技術でも人手でもなく、決めきる作業そのものにあると分かります。

感覚の話ではありません。一般社団法人 日本情報システム・ユーザー協会（JUAS）が経済産業省の監修のもとで実施した企業IT動向調査2025（2024年度調査）では、QCD（工期・予算・品質）の悪化に影響を与えたトレンドを企業自身が挙げています。

注目したいのは、「要件定義の難易度向上」と「要件定義の時間不足」が、別々の項目として上位に並んでいることです。難しくなっているうえに、時間も足りていない。この2つは対処法がまったく違います。難易度には人の配置で、時間不足にはスケジュールの引き方で応じるしかありません。

工期が遅れた企業の約半数が、その理由に「要件定義の難易度向上」を挙げています。遅れの原因は、開発の速さではなく決めきる作業にあります。

06「予定どおり完了」した割合は、10年で下がり続けている

要点： 同じ調査で、工期が予定どおり完了したプロジェクトの割合は、10年間どの規模でも下がり続けています。100人月未満の小規模開発でも、2015年度の35.2%から2024年度は31.0%へ。小さい案件だから安心、とは言えなくなっています。

中小企業が発注するシステムの多くは、いちばん上の行（100人月未満）にあたります。規模が小さくても、3社に2社は予定どおりに終わっていません。

横に読むと、2018年度あたりを山にして、その後はどの規模でも下がっています。同じ調査では、品質が予定どおりにならなかった要因として「計画時の考慮不足」が39.1%、「仕様変更の多発」が27.2%挙げられており、いずれも要件定義の段階に根がある項目です。

予定どおりに終わらせたいなら、開発期間を短く見積もるのではなく、要件定義に時間を取るほうが結果的に近道です。費用の考え方はシステム開発の費用相場をまとめた記事で詳しく整理しています。

07要件定義の失敗｜現場でよく見る5つのつまずき

要点： 要件定義の失敗は、知識不足ではなく進め方から生まれます。決裁者が打ち合わせに出ない、現場に聞かない、やらない範囲を決めない、口頭で合意する、途中で担当が変わる。この5つがそろうと、ほぼ確実に作り直しが発生します。

どれも、あとから振り返れば防げたものばかりです。順番に見ていきます。

• 決裁者が打ち合わせに出ない。 担当者だけで詰めた内容が、最後の報告でひっくり返ります。金額と範囲に関わる場面には、決められる人が同席してください。
• 現場に聞かないまま決める。 管理側の理想で設計すると、例外処理が抜けます。実際に入力する人が15分話すだけで、抜けの半分は見つかります。
• やらない範囲を決めない。 「あとで考える」と保留した項目は、必ず開発の途中で戻ってきます。しかも、いちばん高くつくタイミングで戻ってきます。
• 口頭で合意して先へ進む。 打ち合わせで納得した内容が、文書に落ちていない状態です。数か月後には双方の記憶が食い違います。
• 途中で担当者が変わる。 引き継ぎ資料が議事録だけだと、決めた理由が失われます。「なぜそう決めたか」を1行添えておくだけで防げます。

この5つに共通しているのは、技術の問題がひとつもないことです。要件定義でつまずく原因は、たいてい社内の合意形成の側にあります。だからこそ、開発会社を替えても同じことが起きます。

なお、社内に詳しい人がいないことを不安に感じる必要はありません。判断の役割分担についてはシステム開発の外注と内製を比べた記事で整理しています。

08仕様の固め方｜その場で決められないときの3つの手

要点： 仕様の固め方で行き詰まったら、無理に結論を出さず、扱い方を決めてください。使える手は3つです。期限つきで保留する、第1段階の範囲から外す、いまのやり方をそのまま仕様にする。曖昧なまま進めるより、はるかに安全です。

要件定義の打ち合わせでは、どうしても決めきれない論点が出ます。「請求書の締め日を変えるかもしれない」「来期から拠点が増えるかもしれない」。こうしたときに「とりあえず柔軟に作っておいてください」と言うのが、いちばん高くつきます。柔軟さは、そのまま費用です。

1. 期限つきで保留する。 「9月15日までに社内で決定し、それまでは現行どおりとする」と、決定期限と暫定の扱いをセットで書きます。保留それ自体は問題ではありません。期限のない保留が問題です。
2. 第1段階の範囲から外す。 決まらない機能は、次の段階に回します。予約の受付だけ先に作り、キャンセル料の計算は運用が固まってから足す、という進め方です。実例は予約システムの導入方法をまとめた記事で紹介しています。
3. いまのやり方をそのまま仕様にする。 迷ったら、現行業務を変えないことを仕様にします。改善は動かしてからでも間に合います。最初から理想形を目指すと、決まらない項目が積み上がります。

3つとも、結論を先送りする手ではありません。「決められない」という事実を、扱いの決まった状態に変える手です。文書に残っていれば、開発会社は見積りを出せますし、あとから揉めることもありません。

09要件定義にかけた期間と、着手後に出てくる追加費用

要点： 要件定義を短く切り上げた案件ほど、着手後の仕様追加が増えます。当社が扱った中小企業向け案件では、2週間未満で終えた案件の追加費用は当初見積りの2〜3割に達する一方、1〜2か月かけた案件では1割前後に収まっていました。

ここからは、ZenWeb Japanが手がけた案件の傾向です。開発期間3〜6か月ほどの業務システムを対象に、要件定義にかけた期間ごとに、着手後の動きを整理しました。

いちばん下の行に注意してください。要件定義は長くかければよい、というわけでもありません。3か月以上かけても追加費用は1〜2か月の場合とほとんど変わらず、その分だけ全体の期間が延びます。中小企業の業務システムであれば、1〜2か月が現実的な落としどころです。

費用の話は、ホームページ制作でも構造が似ています。決めきらないまま進めた分が、後から乗ってくる点は共通です。詳しくはホームページ制作の費用相場をまとめた記事もご覧ください。

10要件定義書に載っていないと危ない項目チェック

要点： 要件定義書を受け取ったら、機能の説明よりも先に、6つの項目を探してください。やらないことの一覧、保留項目と決定期限、データ移行の範囲、検収の基準、公開後の窓口、変更したいときの手続き。これらが無い文書は、まだ合意には使えません。

要件定義書は、分厚さでは判断できません。機能の説明が丁寧でも、下の6項目が無ければ、揉めたときに拠りどころがありません。受け取ったその日に、目次で探してみてください。

この6つのうち、とくに効果的なのは1つ目と6つ目です。やらないことが書いてあり、変更したいときの手続きが決まっていれば、途中で要望が出ても揉めません。「追加になりますね」ではなく「変更申請を出しましょう」と話が進みます。

11まとめ｜要件定義とは、決めきるまでを含む工程です

要点： 要件定義とは、話し合う工程ではなく決めきる工程です。決める人を出席させ、やらないことを先に書き、決まらない項目には期限か段階を割り当てる。この3つを守れば、着手後の追加費用は大きく下がります。

ここまでの内容を、短くまとめます。

• 決める主体は発注側。 業務の流れ、権限、出力、同時利用人数は、開発会社が代わりに決められません。
• やらないことを先に書く。 範囲の線引きが、そのあとの議論の長さを決めます。
• 決まらない項目は、扱いを決める。 期限つき保留、次の段階、現行踏襲の3択で処理します。
• 期間の目安は1〜2か月。 短すぎると追加費用が2〜3割、長すぎても効果は頭打ちになります。
• 文書で合意する。 範囲・期限・検収・変更手続きが書かれて、はじめて合意に使えます。

要件定義は、専門知識を試される場ではありません。自社の業務を、いちばんよく知っている人が説明する場です。分からない用語は、その場で聞いてください。聞かれて困る開発会社なら、そもそも一緒に進める相手ではありません。

ZenWeb Japanでは、要件定義から設計・開発・公開後のメンテナンスまでを一貫して担当しています。詳しくはWebシステム開発のサービス内容をご覧ください。Excel業務の置き換えから検討したい場合は、Excel業務をシステム化すべきサインの記事が出発点として分かりやすいと思います。

12よくある質問

要点： 要件定義について、ご相談の場でよくいただく質問をまとめました。期間、費用、担当者、要求仕様書との違い、要件定義だけを依頼できるかについてお答えします。

1. 要件定義とは、ひとことで言うと何ですか？

作るシステムの中身を具体的に決めて、発注側と開発会社で合意し、文書に残す工程です。開発工程のいちばん最初にあり、以後の見積り・開発・検収は、すべてこの文書を基準に進みます。「話し合う工程」ではなく「決めきる工程」と考えてください。

2. 要件定義書は、発注側と開発会社のどちらが書くのですか？

文書としてまとめるのは、通常は開発会社です。ただし中身を決めるのは発注側です。業務の流れ、権限の範囲、必要な出力は、業務を持っている側にしか決められません。書く人と決める人が違う、と整理しておくと混乱しません。

3. 要件定義には、どれくらいの期間がかかりますか？

開発期間3〜6か月ほどの業務システムであれば、1〜2か月が目安です。当社の案件では、2週間未満で切り上げた場合、着手後の追加費用が当初見積りの2〜3割に達しました。一方で3か月以上かけても効果は頭打ちになります。

4. 要求仕様書と要件定義書は、どう違いますか？

要求仕様書は、発注側が「やりたいこと」をまとめて開発会社に渡す文書です。要件定義書は、それを受けて「作るもの」を双方で合意した文書です。順番としては、要求仕様書が先、要件定義書が後になります。

5. 要件定義だけを先に依頼することはできますか？

できます。要件定義を1つの契約として区切り、その成果物をもとに開発の見積りを取り直す進め方です。作る内容が固まっていない段階では、この形のほうが総額を抑えやすくなります。お問い合わせから、現在の状況をお聞かせください。