要件定義と基本設計の違いとは？目的・成果物・進め方をわかりやすく解説

システム開発のプロジェクトが始まると、「要件定義」と「基本設計」という工程が登場します。どちらも上流工程に位置づけられますが、「具体的に何が違うのか」「どこまでが要件定義でどこからが基本設計なのか」が曖昧なまま進めてしまい、後工程で手戻りが発生するケースは珍しくありません。

要件定義は「何を作るか」を決める工程であり、基本設計は「どう作るか」を決める工程です。この境界を正しく理解しておくことで、プロジェクトの品質・コスト・納期を守りやすくなります。

この記事では、要件定義と基本設計それぞれの目的や成果物の違い、進め方の手順、そして失敗しないためのポイントまで、発注者・開発者の双方に役立つ内容をまとめています。

確認したいポイント	結論	詳細
要件定義と基本設計の違いは？	「何を作るか」と「どう作るか」	要件定義はシステムに必要な機能や性能を決める工程で、基本設計はその実現方法を具体化する工程です
それぞれの成果物は？	要件定義書と基本設計書	要件定義書は機能一覧や非機能要件を、基本設計書は画面設計やデータベース設計などを文書化したものです
工程の順番と関係性は？	要件定義が先で基本設計が後	要件定義の成果物を入力として基本設計を進めるため、要件定義の品質がプロジェクト全体を左右します
発注者はどこまで関わるべきか？	基本設計の承認まで関与する	要件定義は発注者が主導し、基本設計は開発者が作成しますが、発注者の確認・承認が完了品質を高めます

この記事でわかること

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

・それぞれの工程で決める内容と主な成果物

・要件定義から基本設計へスムーズに移行する手順

・上流工程でよくある失敗パターンと対策

・発注者が各工程で確認すべきチェックポイント

＼ システム開発・DX推進のご相談はネクストスケールへ ／ ▶ 相談予約はこちら

要件定義とは？目的・決めること・成果物を解説

まずは要件定義の基本を押さえましょう。要件定義は基本設計の前に行う工程であり、プロジェクト全体の方向性を決定づける重要なフェーズです。

要件定義の目的と位置づけ

要件定義とは、開発するシステムに必要な機能や性能を明確にし、関係者間で合意を形成する工程です。英語では「Requirements Definition」と呼ばれ、システム開発における最上流の工程に位置します。

要件定義の目的は、発注者（ユーザー企業）と受注者（開発会社）の間で「何を作るのか」という認識を一致させることにあります。ここで決めた内容が、以降のすべての工程の基準となるため、要件定義の品質がプロジェクトの成否を左右するといっても過言ではありません。

IPAが公表している「共通フレーム2013」でも、要件定義は上流工程の中核として位置づけられており、利害関係者との合意形成を経て要件を確定させることが求められています（参考：IPA システム構築の上流工程強化）。

要件定義で決める内容

要件定義では、大きく分けて「機能要件」と「非機能要件」の2つを定義します。

機能要件とは、システムが備えるべき機能そのものを指します。たとえば「ユーザー登録機能」「検索機能」「帳票出力機能」など、業務上必要な機能を一覧化します。

非機能要件とは、システムの品質に関わる要件です。可用性（稼働率の目標）、性能（応答速度の基準）、セキュリティ（認証方式やアクセス制御）、拡張性（将来の利用者増加への対応）などが含まれます。

このほかにも、業務フローの整理、システム化の範囲の確定、プロジェクトのスケジュールや予算の概算、関係者の役割分担なども要件定義の段階で決めておく事項です。

要件定義の具体的な書き方については、要件定義の例の記事でシステム種類別のサンプルを紹介しています。

要件定義の主な成果物

要件定義の工程で作成される代表的な成果物は以下のとおりです。

要件定義書：システムに求められる機能要件と非機能要件を網羅的にまとめた文書です。プロジェクトの「契約上の合意内容」に近い重みを持ち、ここに書かれた範囲が開発の対象になります。

業務フロー図：現行業務の流れと、システム導入後の新しい業務の流れを可視化した図です。どの業務をシステムで代替し、どの業務を人が行うのかの境界を明確にします。

機能一覧（要求機能一覧）：システムに実装する機能をリスト化した文書です。各機能の優先度や実装予定時期を記載することもあります。

非機能要件一覧：可用性・性能・セキュリティ・運用保守性などの項目ごとに、求められる水準を数値や基準で明記した一覧です。

要件定義書の書式やレイアウトについて詳しく知りたい方は、要件定義書のフォーマットの記事もあわせてご確認ください。

基本設計とは？目的・決めること・成果物を解説

要件定義で「何を作るか」が決まったあとに行うのが基本設計です。ここでは基本設計の目的と、具体的に何を設計するのかを解説します。

基本設計の目的と位置づけ

基本設計とは、要件定義で決まったシステムの要件を、具体的な設計としてどのように実現するかを決める工程です。英語では「Basic Design」や「High-Level Design」と呼ばれます。

要件定義が「What（何を作るか）」を決める工程であるのに対し、基本設計は「How（どう作るか）」を決める工程です。要件定義書をインプットとして、画面のレイアウトやデータベースの構造、外部システムとの連携方式などを具体的に定めていきます。

基本設計は、要件定義と同様にクライアント（発注者）が確認・承認するフェーズです。基本設計の次の工程である詳細設計は開発者向けの技術文書になるため、発注者が設計内容を直接確認できるのは基本設計までという点が重要です。ここで認識のズレを見逃すと、完成後に大きな手戻りが発生します。

基本設計で決める内容

基本設計では、要件定義で定められた機能を具体的な画面やデータ構造として設計していきます。主に以下の項目を決定します。

画面設計：各画面のレイアウト、配置する入力項目やボタン、表示する情報の内容を定めます。ユーザーが実際に操作する画面のイメージを具体化する作業です。

画面遷移設計：画面と画面のつながり（遷移）を設計します。「ログイン画面→トップ画面→検索画面→詳細画面」のように、ユーザーの操作導線を定義します。

データベース設計（論理設計）：システムが保持するデータの構造を設計します。テーブルの構成、各テーブルが持つ項目、テーブル間の関連性を定めます。

外部インターフェース設計：他のシステムや外部サービスとの連携方式を定めます。データの受け渡しのタイミング、フォーマット、通信プロトコルなどを設計します。

帳票設計：システムから出力される帳票やレポートのレイアウトと出力項目を定めます。

バッチ処理設計：定期的に自動実行される処理（夜間の集計処理やデータ連携処理など）の内容とスケジュールを定めます。

基本設計の主な成果物

基本設計で作成する代表的な成果物は以下のとおりです。

基本設計書：画面設計・画面遷移設計・データベース設計・外部IF設計などをまとめた設計文書の総称です。プロジェクトによっては「外部設計書」と呼ばれることもあります。

画面設計書（ワイヤーフレーム）：各画面のレイアウトを図で示した文書です。入力項目、ボタン、表示エリアの配置と、項目ごとのデータ型や入力制約を記載します。

画面遷移図：システム全体の画面の流れを図で表現したものです。ユーザーの操作に応じて、どの画面からどの画面に遷移するかを一覧化します。

ER図（エンティティ・リレーションシップ図）：データベースのテーブル構成とテーブル間のリレーションを視覚的に表現した図です。

機能設計書：各機能の処理概要、入出力データ、処理の流れを記述した文書です。詳細設計の前段階として、処理の骨格を定めます。

要件定義と基本設計の違いを比較表で整理

ここまでの内容をもとに、要件定義と基本設計の違いを比較表で整理します。両者の境界線を明確に理解しておくことで、各工程でやるべきことが見えてきます。

目的・観点・成果物の違い

比較項目	要件定義	基本設計
目的	「何を作るか」を決める	「どう作るか」を決める
英語表記	Requirements Definition	Basic Design / High-Level Design
観点	業務視点・ユーザー視点（What）	技術視点・システム視点（How）
主導者	発注者が主導、開発者が支援	開発者が主導、発注者が確認
主な成果物	要件定義書、機能一覧、業務フロー図、非機能要件一覧	基本設計書、画面設計書、画面遷移図、ER図、機能設計書
クライアント関与	必須（要件を出し切る責任）	必須（設計内容を承認する責任）
判断基準	業務上の必要性	技術的な実現可能性

このように、要件定義は「業務として何が必要か」を定める工程であり、基本設計は「技術としてどう実現するか」を定める工程です。要件定義の成果物が基本設計のインプットになるという関係性を理解しておくことが重要です。

詳細設計との違い

基本設計と混同されやすいのが「詳細設計」です。詳細設計は、基本設計で定めた内容をさらに細かくブレイクダウンし、プログラミングができるレベルまで落とし込む工程です。

基本設計が「システムの外部仕様（ユーザーから見える振る舞い）」を定めるのに対し、詳細設計は「内部仕様（プログラムの構造やアルゴリズム）」を定めます。基本設計書は発注者が確認しますが、詳細設計書は開発者間の技術文書であり、発注者が直接確認することは通常ありません。

したがって、発注者にとっては「要件定義で要望を出し切り、基本設計で設計内容を承認する」ことが、プロジェクトの成功に直結する最も重要なアクションとなります。

＼ システム開発・DX推進のご相談はネクストスケールへ ／ ▶ 資料請求はこちら

要件定義から基本設計への進め方｜5つの手順

要件定義と基本設計は別工程ですが、連続したプロセスとして一貫性を保つことが大切です。ここでは、要件定義の開始から基本設計の完了までの流れを5つのステップで解説します。

ステップ1：ヒアリングで業務課題と要望を洗い出す

要件定義の最初のステップは、発注者側の業務課題と要望を徹底的にヒアリングすることです。現在の業務フロー、使っているシステム、困っていること、新システムに期待することを聞き取ります。

ヒアリングでは、情報システム部門だけでなく、実際にシステムを使う現場部門のメンバーも参加してもらうことが重要です。現場の声を拾えないと、要件定義に漏れが生じ、完成後に「使いにくい」「想定と違う」といったフィードバックが発生します。

ヒアリングの結果は、議事録として記録し、発注者側と共有しておきましょう。認識のズレを早期に発見する手段として、プレ要件定義（概略レベルの要件整理）を先に実施するのも有効です。

ステップ2：要件を整理し要件定義書を作成する

ヒアリングで収集した情報をもとに、要件を体系的に整理し、要件定義書として文書化します。このとき、機能要件と非機能要件を明確に分けて記載することがポイントです。

機能要件は、業務プロセスごとに必要な機能を洗い出し、機能一覧として整理します。「受注管理機能」「在庫照会機能」のように、業務の言葉で記述することで、発注者にとって理解しやすい文書になります。

非機能要件は、可用性・性能・セキュリティ・拡張性の各観点で、目標値を数値で定めます。「稼働率99.9%以上」「画面の応答時間3秒以内」のように、測定可能な指標で記載しましょう。

また、システム化の対象範囲と対象外の範囲を明記しておくことも重要です。範囲が曖昧なまま進むと、後工程で「これもシステム化するはずだった」という認識のズレが発生します。

ステップ3：要件定義書のレビューと合意形成

要件定義書が完成したら、発注者と開発者の双方でレビューを行い、合意形成を行います。このレビューがプロジェクト全体の品質を左右するため、形式的な確認で終わらせてはいけません。

レビューでは、以下の観点で内容を確認します。記載された要件に抜け漏れがないか。要件同士に矛盾がないか。技術的に実現可能な内容か。優先順位が適切に設定されているか。スケジュールと予算に整合性があるか。

合意した要件定義書は、以降の工程で変更が生じた場合の基準点（ベースライン）になります。変更が必要になった際は、変更管理のルールに基づいて影響範囲を評価し、関係者の承認を経て変更を反映します。

ステップ4：基本設計に着手し画面・データ構造を設計する

要件定義書の合意が完了したら、その内容をインプットとして基本設計に着手します。基本設計では、要件定義で定めた「What」を「How」に変換する作業を行います。

まず画面設計では、要件定義で定められた機能をどの画面でどのように実現するかを設計します。画面遷移図を作成し、ユーザーの操作導線を確認します。

次にデータベース設計では、要件定義で整理したデータ項目を、テーブル構成に落とし込みます。ER図を作成してテーブル間のリレーションを視覚化し、データの整合性を確認します。

外部システムとの連携がある場合は、インターフェース設計も並行して進めます。データ連携のタイミング（リアルタイムかバッチか）、データフォーマット、エラー時の処理方針などを定めます。

ステップ5：基本設計書のレビューと承認

基本設計書が完成したら、発注者のレビューと承認を得ます。基本設計は発注者が設計内容を確認できる最後の工程であるため、ここでの確認は特に慎重に行う必要があります。

発注者側のレビュー担当者は、画面設計書を見ながら「自分たちの業務がこの画面構成で問題なく行えるか」をシミュレーションすることが大切です。画面の項目名や配置、遷移の流れが業務の実態に合っているかを具体的にチェックしましょう。

基本設計書の承認後、開発チームは詳細設計に進みます。基本設計の段階で見つけられなかった問題は、詳細設計以降で発覚しても修正コストが大きくなるため、「ここが最後の砦」という意識で臨むことが重要です。

システム開発の外注を検討している場合は、システム開発の外注とはの記事で、費用相場や外注先の選び方を解説していますので参考にしてください。

＼ システム開発・DX推進のご相談はネクストスケールへ ／ ▶ 相談予約はこちら

要件定義と基本設計を成功させるための5つのポイント

上流工程の品質を高めるには、工程ごとの作業を丁寧に進めるだけでなく、プロジェクト全体を見通した取り組みが必要です。ここでは、要件定義と基本設計を成功に導くための実践的なポイントを紹介します。

ポイント1：発注者と開発者の役割分担を明確にする

要件定義では発注者が主体的にリードし、基本設計では開発者が技術的な設計をリードするというのが基本の役割分担です。しかし実際のプロジェクトでは、この分担が曖昧なまま進み、結果として双方が相手に任せきりになってしまうケースがあります。

プロジェクト開始時に、工程ごとの主担当・副担当を明文化したRACIチャート（責任分担表）を作成しておくと、役割の曖昧さを防ぐことができます。

ポイント2：要件定義の段階で要望を出し切る

要件定義書は、開発対象の範囲を定める「契約上の合意」に近い意味を持ちます。ここに書かれていない要件は基本的に開発の対象外として扱われるため、発注者は要件定義の段階で必要な機能を出し切ることが重要です。

基本設計以降で「これも欲しかった」と気づいた場合、追加要件として扱われ、費用の増加や納期の延長につながります。要件定義の段階で現場部門のメンバーも巻き込み、業務に必要な機能を網羅的に洗い出しましょう。

ポイント3：基本設計では画面を使って認識を合わせる

基本設計の段階で最も効果的なコミュニケーション手段は、画面のモックアップやワイヤーフレームを使った認識合わせです。文章だけの設計書では、発注者と開発者の間で「画面のイメージ」に認識のズレが生じやすくなります。

画面のモックアップを作成し、実際の業務シナリオに沿って操作をシミュレーションすることで、「この項目が足りない」「この配置では使いにくい」といったフィードバックを早期に得ることができます。

ポイント4：変更管理のルールを事前に決めておく

プロジェクトが進むなかで、要件の変更や追加が発生することは避けられません。重要なのは、変更が発生した際の対応ルールを事前に決めておくことです。

変更管理のルールとして、「変更依頼の提出方法」「影響範囲の評価方法」「承認フロー」「費用やスケジュールへの影響の取り扱い」を定めておきましょう。ルールがないまま変更を受け入れると、スコープの拡大（スコープクリープ）が起き、プロジェクトの遅延やコスト超過を招きます。

ポイント5：テスト計画を上流工程のうちに策定する

テスト計画は、開発やテストの工程で初めて考えるものではありません。要件定義や基本設計の段階で、「どのような観点でテストするか」を決めておくことで、設計の品質を高めることができます。

たとえば、要件定義で定めた各機能について「受入テストでどのような条件をクリアすれば合格とするか」を明確にしておくと、要件自体のあいまいさに気づくことができます。テストの観点が決められない要件は、定義が不十分な可能性があるため、要件定義の段階で見直すきっかけになります。

＼ システム開発・DX推進のご相談はネクストスケールへ ／ ▶ 資料請求はこちら

上流工程でよくある失敗パターンと対策

要件定義と基本設計は、後工程に与える影響が大きいため、この段階での失敗はプロジェクト全体のリスクに直結します。ここでは、よくある失敗パターンとその対策を紹介します。

失敗1：要件が曖昧なまま基本設計に進んでしまう

「なんとなく合意した」状態で基本設計に入ると、設計の途中で要件の解釈に食い違いが生じ、手戻りが頻発します。要件定義書の各項目が、具体的かつ測定可能な形で記述されているかを確認したうえで次工程に進みましょう。

対策としては、要件定義書のレビュー時に「この要件をもとにテストケースを作成できるか」という観点でチェックする方法が有効です。テストケースが書けない要件は、記述が曖昧であるサインです。

失敗2：基本設計で発注者の確認が形骸化する

基本設計書は技術的な内容が多いため、発注者が内容をよく確認しないまま承認してしまうケースがあります。しかし、基本設計は発注者が設計内容を直接確認できる最後のフェーズです。

対策としては、基本設計のレビュー会議で画面遷移図やワイヤーフレームを使って業務シナリオをウォークスルーし、発注者が「自分の業務で使えるか」を実感を持って確認する場を設けることです。

失敗3：非機能要件を後回しにしてしまう

機能要件の議論に時間を取られ、非機能要件（性能、セキュリティ、可用性など）の定義が不十分なまま基本設計に進むケースも多く見られます。非機能要件はシステムの品質を左右する重要な要素であり、後から追加すると設計の根本的な見直しが必要になる場合があります。

対策としては、要件定義の初期段階から非機能要件のチェックリストを用意し、機能要件と並行して議論を進めることです。IPAが公開している「非機能要求グレード」のテンプレートを活用するのも効果的です。

失敗4：要件定義と基本設計の境界が曖昧になる

プロジェクトによっては、要件定義と基本設計の作業が混在し、どこまでが要件定義でどこからが基本設計なのかわからなくなることがあります。

対策としては、各工程の完了条件（Exit Criteria）を事前に定めておくことです。「要件定義は要件定義書のレビュー完了をもって終了とする」「基本設計は基本設計書の承認をもって終了とする」のように、明確な区切りを設定します。

情報システム部門の体制が不足している場合は、外部の専門家を活用する方法もあります。情シス外注の進め方の記事で、外注する業務の切り分けや契約のポイントを解説していますのでご参照ください。

まとめ

要件定義と基本設計は、どちらもシステム開発の上流工程に位置する重要なフェーズです。要件定義は「何を作るか」を決める工程であり、基本設計は「どう作るか」を決める工程です。この違いを正しく理解し、各工程で適切な作業を行うことが、プロジェクトの成功につながります。

要件定義では、機能要件と非機能要件を網羅的に定義し、発注者と開発者の間で合意を形成します。基本設計では、要件定義の内容を画面・データ構造・外部連携などの具体的な設計に落とし込み、発注者の承認を得ます。

上流工程でよくある失敗を防ぐためには、発注者と開発者の役割分担を明確にすること、要件定義の段階で要望を出し切ること、基本設計の確認を形骸化させないこと、変更管理のルールを事前に定めておくことが重要です。

本記事の内容を参考に、要件定義と基本設計の違いを正しく理解し、品質の高い上流工程を実現してください。