システム開発の要件定義とは？決めること・進め方・要件定義書の項目を解説

要件定義とは、システムで「何を作るか」を発注者と開発会社のあいだで決め、文書と画面にして合意する工程です。企画の次、設計の前に行い、ここで決めた内容が見積もり・設計・テストのすべての基準になります。

ところが実際には、「要件定義書に何を書けばいいのか」「どこまで決めれば終わりなのか」が曖昧なまま進んでしまうプロジェクトが少なくありません。本記事では、要件定義で決める7つの項目、進め方の6ステップ、失敗しやすい5つのケースを、発注担当者がそのまま使える粒度で解説します。

◆この記事の要点

• 要件定義とは：システムで実現することを具体的な条件に落とし、関係者で合意する工程。企画と設計のあいだにある上流工程です
• 目的：要件定義書を作ること自体ではなく、「何を作るのか」について関係者の認識を揃えること
• 決めること：目的・目標／業務要件／機能要件／非機能要件／データ・外部連携／UI/UX・利用環境／制約事項の7項目
• 進め方：目的とKPIの整理から始め、現状把握、あるべき姿の設計、要件の洗い出し、優先順位付け、画面でのレビューと合意の6ステップで進めます
• 当社の進め方：Figmaで作った画面を要件定義の納品物にし、期間1〜2ヶ月・費用100〜200万円を目安に、要件定義書と本開発の見積もりまでお出しします

» 【無料】システム開発の要件定義から株式会社ペンタゴンに相談する

筆者はアプリ・Webシステム開発会社「株式会社ペンタゴン」の代表として、スタートアップから大手企業まで10年以上、企画・要件定義から運用・保守までを担当してきました。要件定義書の項目だけ確認したい方は要件定義書の主な項目から読み進めてください。

アプリ開発専門のプロ「株式会社 Pentagon（ペンタゴン）」とは？

Pentagon（ペンタゴン）は、アプリ開発を専門に行う会社です。私たちは単なる開発会社ではなく、お客様の事業の成長を共に創り上げるアプリ開発パートナーです。お客様の事業の成長に本気で向き合うため、当社のアプリ開発では、

• 「もっとこうすれば良くなる」という提案を次々と出します
• 「使いやすさ」と「成果があがること」のどちらも妥協しないアプリを作ります
• リリース後もデータを見ながら、改善・グロースまで一緒に考えます

詳しくはペンタゴンの特徴をご覧ください。無料相談はこちらから

要件定義とは

要件定義とは、利用者や発注者の要望をもとに、開発するシステムが備えるべき機能・性能・制約を具体的に決め、関係者で合意する工程です。家づくりにたとえると、図面を引く前に「どんな暮らしをしたいか、そのために何部屋必要で、予算はいくらか」を確定させる段階にあたります。

要件定義の成果物は要件定義書と呼ばれます。ただし文章だけで合意すると、書いた側と読んだ側で解釈がずれたまま進みやすいため、業務フロー図や画面イメージをあわせて成果物にするケースが増えています。

要件定義はシステム開発のどの工程で行う？

要件定義は、企画の次、設計の前に行います。システム開発は一般的に「企画→要件定義→設計→実装→テスト→運用・保守」の順で進み、このうち企画から設計までを上流工程と呼びます。

各工程で何が成果物になり、どんなトラブルが起きやすいかは、システム開発の各工程の内容とトラブル対策で詳しく整理しています。

要件定義と要求定義の違い

要求定義は「何に困っていて、どうなりたいか」を利用者・発注者の言葉で整理する工程で、要件定義はそれをシステムで実現できる具体的な条件に変換する工程です。

要求定義を飛ばして要件定義から入ると、開発会社が推測で要求を埋めることになります。出来上がったシステムが現場で使われない原因の多くはここにあります。

要件定義の中でも、業務要件とシステム要件は分けて考えます。業務要件は「システムを入れて業務をどう変えるか」、システム要件は「そのためにシステムが満たすべき条件」です。システム要件は、さらに機能要件と非機能要件に分かれます。

要件定義と基本設計の違い

要件定義は「何を作るか」を決める工程、基本設計は「どう見せて、どう動かすか」を決める工程です。たとえば要件定義で「受注一覧を担当者と納期で絞り込める」と決めたら、基本設計ではその画面のレイアウト、項目の並び、データベースの項目、エラー時の表示までを具体化します。

実際には両者の境界は会社によって異なります。要件定義の段階で主要画面まで作る会社もあれば、画面は基本設計で初めて作る会社もあります。複数社の見積もりを比べるときは、要件定義にどこまで含まれているかを確認すると、金額差の理由が見えてきます。

なぜ要件定義が重要なのか

要件定義の目的は、要件定義書を作ることではなく、「何を作るのか」について関係者の認識を揃えることです。

発注担当者、現場の利用者、開発チーム、経営層は、それぞれ違う関心でシステムを見ています。認識が揃わないまま開発に進むと、完成間際になって「思っていたものと違う」という事態が起こります。

要件定義のアウトプットは誰のため？

要件定義書は、立場ごとに違う目的で読まれます。

同じ文書でも、現場の利用者は「自分の業務が回るか」を、経営層は「投資に見合うか」を見ています。どちらの立場から読んでも判断できる形にまとめておくと、合意までの時間が短くなります。

開発の目的と目標を明確にできる

要件定義を行うと、システム開発の目的と達成すべき目標がはっきりします。「業務を効率化したい」という漠然とした要望を「受注処理の時間を月40時間減らす」のような目標に置き換えておけば、開発中に迷ったときの判断基準になり、関係者全員が同じ方向を向いて進めます。

手戻りを防ぎ、コストと納期を抑えられる

曖昧な要件のまま開発を進めると、後の工程で手戻りが発生します。修正にかかる費用は、後の工程で見つかるほど大きくなります。画面まで合意せずに開発へ進み、テスト段階で「この項目では承認できない」と分かった場合、作り直しの費用は要件定義にかかる費用を簡単に超えてしまいます。

利用者の満足度を高められる

利用者の要望を要件に正しく落とし込めば、現場で実際に使われるシステムになります。反対に要件定義が不十分だと、機能はそろっていても業務の流れに合わず、利用者の期待とかけ離れたシステムが出来上がる恐れがあります。

要件定義では何を決める？要件定義書の主な項目

要件定義書とは、要件定義で決めた内容をまとめ、発注者と開発会社が合意した証拠として残す文書です。作成するのは通常は開発会社で、発注者はレビューして合意します。書く項目は、大きく次の7つに分けられます。機能要件に目が向きがちですが、後からトラブルになりやすいのは非機能要件と制約事項です。

③機能要件と④非機能要件は、まとめてシステム要件と呼ばれます。機能要件は「システムが何をするか」、非機能要件は「それをどれだけ快適に、安全に、止まらずに行うか」です。たとえば「受注データをCSVで取り込める」は機能要件、「1日500件を5分以内に取り込める」は非機能要件にあたります。

7項目すべてを最初から細かく決める必要はありません。目的と業務範囲、利用者数、連携先が分かれば概算の見積もりは出せます。金額が動かない確定見積もりを出すには、画面とデータ項目まで決める必要があります。

非機能要件で決めておきたい項目

非機能要件は、システムが「どれだけ快適に、安全に、止まらずに動くか」を決める要件です。機能の一覧には現れないため後回しにされやすく、決めないまま開発すると、リリース直前に性能不足やセキュリティの不備が見つかって大きな手戻りになります。

特に個人情報を扱うシステムでは、セキュリティ要件を要件定義の段階で決めておくことが欠かせません。後から追加すると、設計や実装をやり直すことになるためです。

工程ごとにどんな成果物が納品されるのかはシステム開発の工程別の納品物一覧にまとめています。

システム開発の要件定義を進める6ステップ

要件定義は、目的から逆算して要件を絞り込み、最後に画面で合意する順番で進めます。現状調査より先に目的とKPIを決めるのは、取捨選択の基準がないまま要望を集めると、出てきた要望がすべて要件に入ってしまうからです。

要件定義の前後も含めた、発注から運用・保守までのシステム開発の流れもあわせて確認しておくと、全体の中での位置づけがつかみやすくなります。

ステップ1　システム開発の目的・KPIを整理する

最初に「システムが導入されたあと、業務や事業がどういう状態になっていればよいか」を言葉にします。ヒアリングでは5W1H（いつ・どこで・誰が・何を・なぜ・どのように）を意識し、表面的な要望の裏にある課題を掘り下げます。

理想の状態が言葉になったら、削減時間・処理件数・継続率などのKPIに置き換えます。あわせて、対象とする業務の範囲もこの段階で関係者と合意しておきます。範囲が曖昧なまま始めると、後で「その業務も含まれていると思っていた」という食い違いが起こります。

ステップ2　現状の業務・システムを把握する

次に、いまの業務が実際にどう回っているかを調べます。担当者へのヒアリングに加え、実際の業務の様子を見せてもらうと、文書化されていない作業が見つかります。

• 誰が、いつ、何を、どのツールで行っているか（現行の業務フロー）
• 使っているExcel・帳票の項目と計算式（そのままデータ項目の要件になる）
• 「この取引先だけ手書き」「月末だけ順序が変わる」といった例外的な処理
• 連携している既存システムやSaaSと、その仕様書が残っているか
• 1日あたりの処理件数と、同時に使う人数（非機能要件の根拠になる）

現状の分析が浅いと本当の課題が見えず、適切な要件を決められません。

ステップ3　あるべき業務・ユーザー体験を設計する

現状の課題を踏まえて、システム導入後の業務の流れ（To-Be）を描きます。いまの業務をそのまま画面に置き換えるのではなく、不要な承認や二重入力をなくせないかを検討するのがこの段階です。

業務の流れと並行して、利用者が画面をどの順番で操作するかも設計します。ユースケース（誰が・どんな場面で・何をするか）やユーザーストーリーの形で書き出すと、必要な機能の漏れに気づきやすくなります。

ステップ4　必要な要件を洗い出す

To-Beの業務を実現するために必要な要件を、先に挙げた7項目に沿って書き出します。機能要件だけでなく、非機能要件や制約事項まで含めて洗い出すのがポイントです。

要件は「使いやすい画面」「高速に動く」のような曖昧な表現を避け、「主要画面は3秒以内に表示」のように確認できる形で書きます。業務の知識とシステムの知識の両方が必要になるため、業務に詳しい現場の担当者と、技術に詳しい開発会社の担当者がそろって検討することが大切です。

ステップ5　要件に優先順位を付ける

洗い出した要件をすべて第1弾で作ると、たいてい予算と納期に収まりません。コストと効果のバランスを見ながら、優先順位を付けて範囲を絞ります。優先順位付けには、要件を4段階に分けるMoSCoW（モスコウ）分析がよく使われます。

「Won't（今回は作らない）」を明記しておくと、開発中に同じ要望が蒸し返されるのを防げます。ステップ1で決めたKPIに効くかどうかを基準にすると、優先順位で揉めにくくなります。

ステップ6　画面・資料を使ってレビューし、合意する

最後に、要件定義書と画面イメージを使って関係者でレビューし、合意します。文章だけの要件定義書は読み手によって解釈が分かれるため、画面や帳票のサンプルを見ながら確認すると、抜け漏れや認識のずれがその場で見つかります。

レビューには、現場の利用者と決裁者にも参加してもらいます。担当者レベルで合意しても、後から決裁者が別の要望を出すと作り直しになるためです。合意した後も、開発中に要件が変わることはあります。変更の受付方法と、費用・期間への影響の伝え方をあらかじめ決めておくと、変更があっても混乱しません。

なお、アジャイル開発では最初に詳細な要件をすべて決めることはせず、大まかな要件を決めたうえで、短い開発サイクルごとに要件を見直していきます。

要件定義のおすすめ手法とポイント

要件定義を進める手法はいくつかあり、プロジェクトの特性に合わせて選びます。ここでは代表的な3つの手法を紹介します。

ユースケース駆動法

ユースケース駆動法は、利用者がシステムを使う場面（ユースケース）を中心に要件を定義する方法です。利用場面ごとに要件を整理するため、システムの全体像を把握しやすく、網羅的に要件を洗い出せます。ポイントは、利用者の業務の流れを正確に理解し、ユースケースを具体的に書くことです。記述用のテンプレートを用意しておくと効率よく進められます。

エッセンスによる要求開発手法

エッセンス（Essence）は、ソフトウェア開発のプロセスを改善するための知識体系です。要求開発手法では、エッセンスの枠組みを使って要件定義のプロセスを見える化し、標準化します。チームメンバー全員が考え方を理解し、プロセスに沿って進めることで、進捗や課題がはっきりします。

プロトタイピング法

プロトタイピング法は、早い段階でシステムの試作品（プロトタイプ）を作り、利用者に評価してもらう方法です。実際の画面に触れてもらうことで、文章のヒアリングでは出てこない潜在的なニーズを引き出せます。紙に描いた画面のような簡易的なものでも効果はありますが、本番に近い画面ほど具体的な指摘が集まります。

これらの手法は一つに決める必要はなく、組み合わせて使えます。大規模なプロジェクトではエッセンスによる要求開発手法が、アジャイル開発ではプロトタイピング法が向いています。開発モデルの選び方はシステム開発の手法と開発モデルの選び方で解説しています。

なお、生成AI開発を前提としたシステムでは、要件定義だけでなくPoCによる事前検証も重要になります。生成AI PoCの進め方や評価ポイントを知りたい方は「生成AI開発のPoCとは？進め方と本番導入につなげる5つの成功ポイント」もあわせて参考にしてください。

Pentagonが要件定義で重視していること

当社は要件定義を、要件定義書という文書を仕上げる作業ではなく、「作るべきものを小さく正確に絞り込む工程」と捉えています。そのために重視しているのが次の3点です。

欲しい機能ではなく、実現したい成果から逆算する

当社の要件定義は、機能の一覧を作ることからではなく、「システムが導入された後、業務や事業がどういう状態になっていればよいか」を言葉にすることから始めます。理想の状態をKPI（削減時間・処理件数・継続率など）に落としてから機能を選ぶと、「あったら便利」な機能が混ざりません。後から追加要望が出ても、「その機能はKPIに効くか」で判断できます。

企画段階では、利用者へのアンケート調査を行うこともよくあります。発注担当者自身も気づいていなかったニーズが見つかり、優先順位が入れ替わることも珍しくありません。

UI/UXの視点を要件定義段階から取り入れる

当社では企画段階からデザイナーが参加し、画面と業務の流れを同時に検討します。発注担当者と日々システムを使う現場の方は別の人であることが多いため、現場の方にも開発前の画面を触っていただき、いつもの作業をなぞってもらう確認を入れています。使い勝手の問題を実装後に見つけると、直すコストが跳ね上がるからです。

Figmaの画面で、認識のズレを早期に見つける

当社は、Figmaで作った画面を要件定義の納品物にしています。文章だけの要件定義書は、書いた側と読んだ側で解釈がずれたまま合意されがちです。実際の画面を見せて「この一覧にこの項目が並びます」「ここを押すとこの画面に移ります」と説明すると、現場から「この項目では判断できない」という指摘がその場で出ます。開発が始まってから出るはずだった手戻りを、要件定義のうちに前倒しできます。

あわせて、仕様や業務フローをAIに読ませ、未定義の部分や矛盾、抜けを指摘させています。人が見落としやすい決め漏れが、要件定義の段階で表に出ます。

こうして要件定義に十分な時間をかけられるのは、当社がFigmaをベースにしたAI駆動開発に取り組んでいるからです。下の図の左が従来の開発、右が当社のAI駆動開発で、コーディングの工数が圧縮される分を、決める時間（要件定義・設計）と確かめる時間（テスト・品質改善）に振り向けています。

AI駆動開発で要件定義後の期間と費用がどう変わるかは、AI駆動開発のWebシステム開発費用と期間で解説しています。

当社の要件定義は週1回の定例会議を軸に進め、期間は1〜2ヶ月、費用は100〜200万円が目安です。見積もりにどこまでが含まれ、何が変わると費用と期間が動くのかは文書で共有し、開発途中で仕様変更が出たときも影響をその都度お伝えします。

» 【無料】システム開発の要件定義から株式会社ペンタゴンに相談する

Figmaで画面を見ながら要件を固める当社の進め方は、要件定義から始めるシステム開発サービスで紹介しています。

要件定義で失敗しやすいケースと対策

要件定義の失敗には、よく見られるパターンがあります。代表的な5つのケースと対策を整理します。

失敗①　欲しい機能から考え始める

「こんな機能が欲しい」という話から要件定義を始めると、競合のシステムや便利そうな機能が次々に追加され、規模が膨らみます。出来上がったシステムに機能はそろっていても、肝心の業務課題が解決していないという結果になりがちです。まず目的とKPIを決め、その達成に必要な機能だけを選ぶ順番にします。

失敗②　現在の業務をそのままシステム化する

いまの業務手順をそのまま画面に置き換えると、紙の時代に必要だった確認作業や二重入力まで新しいシステムに残ります。システム化は業務を見直す機会でもあります。現状の業務フローを把握したうえで、なくせる手順がないかを検討してから要件に落としましょう。

失敗③　要望をすべて盛り込む

ヒアリングで集めた要望をすべて要件にするのは現実的ではありません。費用と期間が膨らみ、リリースが遅れるうえ、使われない機能も増えます。優先順位を付けて第1弾の範囲を絞り、リリース後の利用状況を見ながら段階的に機能を追加していくほうが、結果的に効果の出るシステムになります。

失敗④　現場ユーザーを要件定義に参加させない

管理職や発注担当者だけがヒアリングに答えると、「この取引先だけ手書き」「月末は順序が変わる」といった現場の実態が漏れます。開発後に「使えない」と言われる原因の多くがこれです。システムを毎日使う現場の担当者にヒアリングへ参加してもらい、画面のレビューにも加わってもらいましょう。

失敗⑤　非機能要件を後回しにする

性能やセキュリティ、運用保守の要件は、機能の一覧に現れないため後回しにされがちです。決めないまま開発を進めると、リリース直前に「利用者が増えると画面が重くなる」「権限の設定が足りない」といった問題が見つかります。非機能要件で決めておきたい項目を参考に、要件定義の段階で数値まで決めておきましょう。

要件定義と設計・テストの関連性

要件定義は、それだけで完結する工程ではありません。要件定義書の内容は設計工程に引き継がれ、テスト工程では合否の基準として使われます。

設計工程では、要件定義書に書かれた機能要件と非機能要件をもとに、画面・データ・処理の具体的な仕様を決めます。要件が曖昧なら設計も曖昧になるため、要件定義の質がそのまま設計の質になります。

テスト工程では、システムが要件定義書に書かれた機能と性能を満たしているかを検証します。特に、システム全体を通して確認する総合テストや、発注者が行う受け入れテストは、要件定義の内容をもとに観点を決めます。要件が「使いやすいこと」のように曖昧だと、テストで合否を判断できません。要件を書く段階から「どうやって確かめるか」を意識しておくと、設計とテストの手戻りが減ります。

関連記事：システムテスト（総合テスト）の種類と観点

要件定義は誰が行う？発注者と開発会社の役割

要件を出して決めるのは発注者、要件を引き出して文書と画面にまとめるのは開発会社です。要件定義書を発注者が自分で書く必要はありませんが、業務の実態を伝え、優先順位を決め、決裁する役割は開発会社が代わることができません。

発注者が担うこと

• 困りごとと、実現したい状態を言葉にする
• 現行業務を説明する（現場担当者のヒアリング時間を確保する）
• いま使っているExcel・帳票・マニュアルなどの資料を提供する
• 要件の優先順位と、第1弾で作る範囲を決める
• 画面と要件定義書をレビューし、合意する
• 関係部署を調整し、決裁する

開発会社が担うこと

• ヒアリングと現行業務の調査
• 業務フロー図（As-Is／To-Be）の作成
• 画面イメージの作成
• 要件定義書の作成
• 技術的な実現性と、費用・期間への影響の提示
• 他社の事例や過去のプロジェクトで得た知見の共有

発注者側の負担として見込んでおきたいのは、定例会議への出席と、現場担当者のヒアリング時間の確保です。当社の場合、定例は週1回が基本で、関係部署の合意が必要な局面では週2〜3回に増やします。決裁者が会議に出ないまま進めると、後から別の要望が出て作り直しになるため、最初の打ち合わせから同席をお願いしています。

反対に、開発会社がすべてを決めてしまうのも危険です。業務を最もよく知っているのは発注者であり、開発会社が推測で要件を埋めると、現場の実態に合わないシステムになります。開発会社は発注者の判断を支える立場として、選択肢と影響を示すのが役割です。

発注者が準備しておくものや、どこまで決まれば見積もりが出るのかは、発注側が準備するものと見積もりが出る条件で詳しく解説しています。

まとめ

要件定義は、システムで何を作るかを関係者で決めて合意する工程で、見積もり・設計・テストのすべての基準になります。要件定義書という文書を作ることがゴールではなく、発注者、現場の利用者、開発チーム、経営層の認識を揃えることに意味があります。

要件定義書には、目的・目標、業務要件、機能要件、非機能要件、データ・外部連携、UI/UX・利用環境、制約事項の7項目を書きます。進めるときは、目的とKPIを決めてから現状を調べ、あるべき姿を描いて要件を洗い出し、優先順位を付けたうえで画面を見ながら合意する順番が基本です。機能から考え始める、要望をすべて盛り込む、現場を巻き込まないといった失敗を避けるだけでも、手戻りは大きく減ります。

株式会社ペンタゴンは、Figmaで画面を先に固める要件定義と、FigmaをベースにしたAI駆動開発で、Webシステム・業務システム・アプリを開発しています。「何から決めればいいか分からない」という段階からでもご相談ください。

» 【無料】システム開発の要件定義から株式会社ペンタゴンに相談する