【新人エンジニア必見！】要件定義と設計の役割分担と正しい進め方をわかりやすく解説

システム開発の現場で当たり前のように使われる「要件定義」と「設計」。新人エンジニアの中には、「この2つの違いを明確に説明できない」「どこからどこまでが誰の役割なのかわからない」と悩んでいる方も多いのではないでしょうか。本記事では、システム開発の土台となる要件定義と設計の決定的な違いを、目的・担当者・成果物など5つの観点から徹底的に比較し、スムーズな開発を実現するための正しい進め方をステップごとにわかりやすく解説します。結論から言うと、要件定義は「何を作るか（What）」を顧客と合意する工程、設計は「どうやって作るか（How）」を開発チームで具体化する工程であり、この役割分担の理解こそがプロジェクト成功の鍵を握ります。この記事を最後まで読めば、両者の関係性を完全に理解し、自信を持って開発業務に取り組めるようになるでしょう。

システム開発の土台となる要件定義と設計

システム開発プロジェクトを成功に導くためには、その初期段階である「要件定義」と「設計」が極めて重要です。この2つの工程は、しばしば家づくりに例えられます。顧客が「どんな家に住みたいか」という要望をヒアリングし、間取りや部屋数を決めるのが「要件定義」。そして、その要望をもとに、実際に家を建てるための詳細な設計図を作成するのが「設計」です。もし最初の要望の聞き取りが曖昧だったり、設計図に不備があったりすれば、どんなに優れた大工がいても、満足のいく家は建ちません。システム開発も同様で、要件定義と設計という土台がしっかりしていなければ、後工程での手戻りや仕様変更が多発し、最悪の場合プロジェクトは失敗に終わってしまいます。本章では、このシステム開発の根幹をなす2つの工程の概要と全体像を解説します。

そもそも要件定義とは何か

要件定義とは、システム開発の最初の工程であり、「誰が、何を、何のために作るのか」を明確にするプロセスです。顧客や利用者が抱える課題やニーズをヒアリングし、それを解決するためにシステムが備えるべき機能や性能を「要件」として定義し、文書化します。ここでの主な目的は、開発するシステムのゴールとスコープ（範囲）について、顧客と開発者の間で明確な合意形成を行うことです。例えば、「売上管理システムを刷新したい」という顧客の要望があった場合、「なぜ刷新したいのか（課題）」「刷新することで何を実現したいのか（ゴール）」「具体的にどのような機能が必要か」といった点を深掘りし、具体的な要件に落とし込んでいきます。この要件定義の質がプロジェクト全体の成否を左右するため、システム開発における最上流の重要な工程と位置づけられています。

設計工程の全体像

設計工程は、要件定義で決定した「何を作るか」を、「どうやって作るか」という具体的な実現方法に落とし込むプロセスです。要件定義書という「要求リスト」をもとに、システムの具体的な仕様や構造を記した「設計図」を作成する工程と言えます。この設計工程は、一般的に「基本設計（外部設計）」と「詳細設計（内部設計）」という2つのフェーズに分かれています。それぞれの役割と目的は明確に異なります。

工程名	別名	主な目的	主な成果物
基本設計	外部設計	ユーザーから見える部分の仕様を決定する。要件定義の内容をシステム仕様に変換する。	機能一覧、画面設計書、帳票設計書、ER図など
詳細設計	内部設計	開発者が見る部分の仕様を決定する。プログラミングができるレベルまで具体化する。	クラス図、シーケンス図、モジュール設計書など

まず「基本設計（外部設計）」では、ユーザーの目に触れる部分、つまりシステムのインターフェースや操作性を中心に設計します。画面のレイアウトやボタンの配置、画面間の遷移ルールなどを決め、顧客にシステムの完成イメージを具体的に提示し、要件定義で合意した内容が正しく反映されているかを確認します。

次に「詳細設計（内部設計）」では、基本設計で定められた機能をどのようにプログラムとして実現するか、その内部構造を設計します。開発者やプログラマーがこの設計書を見れば、迷うことなくコーディング作業に取り掛かれるレベルまで、処理のロジックやデータベースの物理設計などを詳細に定義します。このように、設計工程は段階的に具体化を進めることで、要件を正確かつ効率的にシステムとして実装するための重要な役割を担っています。

要件定義と設計の決定的な違いを5つの観点で比較

システム開発の工程において、要件定義と設計は密接に関連していますが、その役割と目的は明確に異なります。新人エンジニアが最初に戸惑うポイントでもあるこの2つの違いを、「目的」「担当者」「成果物」「必要なスキル」「思考プロセス」という5つの観点から比較し、それぞれの役割を深く理解していきましょう。この違いを把握することが、手戻りのないスムーズな開発プロジェクトの第一歩となります。

目的の違い 顧客の要望か実現方法か

要件定義と設計の最も根本的な違いは、その「目的」にあります。要件定義が「何を（What）」作るかを決めるのに対し、設計は「どのように（How）」作るかを具体化する工程です。

要件定義の主な目的は、顧客やユーザーが抱える業務上の課題を明らかにし、それを解決するためのシステムに必要な機能や性能を定義することです。つまり、ビジネス上のゴールを達成するために「何が必要か」を、関係者全員で合意形成することがゴールとなります。

一方、設計の目的は、要件定義で決定した事柄を、エンジニアが開発できるレベルまで技術的に具体化することです。システムの構造、データの流れ、画面の見た目、プログラムの内部ロジックなど、技術的な実現方法を詳細に落とし込んでいきます。

観点	要件定義	設計
目的	何を（What）作るかを定義する （顧客の課題解決、ビジネスゴールの達成）	どのように（How）作るかを具体化する （技術的な実現方法の確立）

担当者の違い ビジネスサイドか開発サイドか

目的が異なるため、それぞれの工程で中心となる担当者も変わってきます。要件定義はビジネスサイドの要求を深く理解する必要があるため、顧客とのコミュニケーションが中心となり、設計は開発サイドの専門知識が求められるため、エンジニアが中心となります。

要件定義では、プロジェクトマネージャー（PM）やITコンサルタント、上級システムエンジニア（SE）が、顧客企業の担当者や実際にシステムを利用するユーザーと対話を重ねながら進めます。開発チームだけでなく、営業担当者や経営層など、幅広いステークホルダー（利害関係者）が関わることが特徴です。

設計工程の主役は、システムエンジニア（SE）やITアーキテクト、プログラマーといった開発サイドのメンバーです。要件定義で決められた内容をもとに、技術的な知見を活かしてシステムの内部構造を組み立てていきます。もちろん、設計の途中でも顧客に確認を求めることはありますが、議論の中心は開発チーム内部になります。

観点	要件定義	設計
主な担当者	PM、ITコンサルタント、上級SE、顧客（ビジネスサイド）	SE、ITアーキテクト、プログラマー（開発サイド）

成果物の違い 要件定義書と設計書

各工程のゴールとして作成されるドキュメント（成果物）も明確に異なります。要件定義の成果物は「要件定義書」、設計の成果物は「設計書」と呼ばれます。

要件定義書は、システム開発の目的や範囲、必要な機能・非機能要件などをまとめたもので、顧客と開発者間の「契約書」のような役割を果たします。そのため、ITの専門家でないビジネスサイドの担当者でも理解できるよう、図や平易な言葉で記述されることが重要です。主な内容には、システム化の背景、業務フロー図、機能一覧、非機能要件（性能、セキュリティなど）が含まれます。

設計書は、要件定義書の内容を元に、開発者が実装作業を進めるための「設計図」です。設計書は大きく「基本設計書（外部設計書）」と「詳細設計書（内部設計書）」に分かれます。基本設計書は、画面レイアウトや帳票レイアウト、システム構成図など、ユーザーの目に見える部分やシステムの骨格を定義します。詳細設計書は、プログラムの処理ロジックやデータベースのテーブル定義など、開発者が直接コーディングする際の仕様を詳細に記述します。

観点	要件定義	設計
主な成果物	要件定義書 （業務フロー図、機能要件一覧、非機能要件一覧など）	設計書 （基本設計書、詳細設計書、ER図、シーケンス図など）
主な読み手	経営層、顧客、ユーザー、開発者	開発者（SE、プログラマー）、テスト担当者

必要なスキルの違い

それぞれの工程で求められるスキルセットも大きく異なります。新人エンジニアは、将来どのような役割を担いたいかを考えながら、必要なスキルを意識して業務に取り組むことが大切です。

要件定義では、顧客の言葉の裏にある本当のニーズを引き出すための「ヒアリング能力」や、様々な立場の関係者の意見を調整する「コミュニケーション能力」が極めて重要です。また、対象となる業界の「業務知識」や、現状の課題を分析し解決策を導き出す「コンサルティング能力」も求められます。

設計工程では、プログラミング言語やデータベース、インフラなどに関する深い「技術的専門知識」が不可欠です。複雑な要件を矛盾なく整理し、最適なシステム構造を組み立てる「論理的思考能力」や、再利用性や保守性を高めるための設計パターン（UMLなど）の知識も重要になります。

観点	要件定義	設計
必要なスキル	・コミュニケーション能力 ・ヒアリング能力 ・業務知識 ・課題解決能力	・技術的専門知識 ・論理的思考能力 ・設計手法の知識 ・正確なドキュメンテーション能力

思考プロセスの違い

最後に、問題解決に取り組む際の思考プロセスにも違いがあります。要件定義は発散的、設計は収束的な思考が中心となります。

要件定義では、「そもそも何が問題なのか」「理想の業務はどのような姿か」といった本質的な問いから始め、自由な発想でアイデアを広げていく「発散的思考」が求められます。顧客の要望を鵜呑みにするのではなく、「なぜ（Why）」それを実現したいのかを深掘りし、より良い解決策を探求するプロセスです。

一方、設計では、要件定義で定まったゴールに向かって、実現可能な選択肢の中から最も効率的で堅牢な方法を選び取っていく「収束的思考」が中心となります。性能、コスト、納期、将来の拡張性といった様々な制約条件の中で、最適な「解」を一つに絞り込んでいく論理的なプロセスです。

観点	要件定義	設計
思考プロセス	発散的思考 （Why/What：なぜ必要か、何をすべきか）	収束的思考 （How：どうやって実現するか）

要件定義から設計へ 正しいシステム開発の進め方

システム開発は、家づくりに例えられることがよくあります。どのような家を建てたいかを決めるのが「要件定義」、家の間取りや外観を決めるのが「基本設計」、そして柱の太さや配線の通し方を決めるのが「詳細設計」です。この流れを正しく理解し、一つひとつの工程を丁寧に進めることが、プロジェクト成功の鍵を握ります。特にウォーターフォール型の開発モデルでは、前の工程の成果物が次の工程のインプットとなるため、手戻りを防ぐためにも各ステップの役割を正確に把握することが不可欠です。ここでは、要件定義から設計へと進むための具体的なステップを解説します。

ステップ1 要件定義でゴールを明確にする

システム開発の最初のステップである要件定義は、プロジェクト全体の方向性を決定づける最も重要な工程です。ここでは、顧客やユーザーが抱える課題や要望をヒアリングし、「誰のために、何を解決するためのシステムを、いつまでに作るのか」というプロジェクトのゴールを明確に定義します。この段階での合意形成が曖昧だと、後の工程で仕様変更や手戻りが多発し、プロジェクトが失敗する大きな原因となります。要件定義では、大きく分けて「業務要件とシステム要件」および「機能要件と非機能要件」を整理・定義していきます。

業務要件とシステム要件の整理

まず、顧客がシステムを使って実現したい「業務」の流れや目的を整理します。これが「業務要件」です。次に、その業務要件を達成するために、システムが備えるべき事柄を定義したものが「システム要件」です。ビジネス上の目的から、それを実現するためのシステムの役割へと具体化していくプロセスです。

分類	説明	具体例（在庫管理システムの場合）
業務要件	システム化によって達成したい業務上の目的や改善点	・リアルタイムで在庫数を把握し、欠品による販売機会の損失を防ぎたい。 ・手作業による棚卸しの工数を80%削減したい。
システム要件	業務要件を実現するためにシステムが満たすべき要件	・商品が入荷・出荷された際に、在庫データが自動で更新されること。 ・ハンディターミナルでバーコードを読み取ることで棚卸しができること。

機能要件と非機能要件の定義

システム要件は、さらに「機能要件」と「非機能要件」に分類されます。この二つを明確に区別して定義することで、ユーザーが期待する機能と品質を両立したシステムを開発できます。

機能要件は、ユーザーがシステムを利用して特定のタスクを達成するために必要な「機能」に関する要件です。例えば、「商品を登録できる」「顧客情報を検索できる」といった、システムが提供する具体的な動作や処理内容を定義します。

一方、非機能要件は、システムの性能、信頼性、セキュリティといった「品質」に関する要件です。機能要件のように目には見えにくい部分ですが、ユーザーの満足度やシステムの安定稼働に直結する非常に重要な要素です。例えば、Webサイトの表示速度や、同時にアクセスできるユーザー数、データのバックアップ方針などがこれにあたります。

分類	説明	具体例（ECサイトの場合）
機能要件	システムが提供すべき具体的な機能	・ユーザー登録機能 ・商品検索機能 ・ショッピングカート機能 ・決済機能
非機能要件	機能以外の品質や性能に関する要件	・（性能）通常時、ページ表示は3秒以内であること。 ・（可用性）システムの稼働率は99.9%以上であること。 ・（セキュリティ）クレジットカード情報は暗号化して保持すること。

ステップ2 基本設計（外部設計）でシステムの骨格を作る

要件定義で固まった「何を作るか（What）」をもとに、「どのように作るか（How）」の概要を決めるのが基本設計の工程です。この工程は、主にユーザーの目に触れる部分の仕様を設計するため、「外部設計」とも呼ばれます。要件定義で洗い出した各要件を、どのような画面や機能で実現するのかを具体的に落とし込んでいきます。この段階で作成される基本設計書は、顧客と開発者の間で「完成するシステムはこのようなものです」という認識を合わせるための重要なドキュメントとなります。

画面設計や機能一覧の作成

基本設計では、主に以下のような成果物を作成します。

• 機能一覧: システムが搭載するすべての機能をリストアップし、それぞれの機能ID、機能名、概要などを記述します。
• 画面設計: ユーザーが直接操作する画面のレイアウトやデザインを定義します。ワイヤーフレームやモックアップを用いて、どこにどのボタンや入力項目を配置するかを視覚的に示します。ユーザーインターフェース（UI）やユーザー体験（UX）を考慮した設計が求められます。
• 帳票設計: システムから出力される請求書や納品書などの帳票レイアウトを定義します。
• データベース概要設計: システムで扱う主要なデータ項目を洗い出し、論理的なデータ構造を設計します。この段階では、まだ物理的なテーブル定義までは行いません。
• バッチ処理設計: 夜間に行うデータ集計など、ユーザーの操作とは非同期で実行される処理の概要を設計します。

ステップ3 詳細設計（内部設計）で実装レベルに落とし込む

詳細設計は、基本設計で定めたシステムの骨格に肉付けをし、プログラマーが迷わずコーディングに着手できるレベルまで仕様を具体化する工程です。ユーザーからは見えないシステム内部の動きや構造を設計するため、「内部設計」とも呼ばれます。基本設計書が「家の間取り図」だとすれば、詳細設計書は「柱の材質や太さ、配管や配線の具体的な経路を示した施工図」にあたります。この設計書の品質が、プログラムの品質や開発効率、将来の保守性に大きく影響します。

プログラムやデータベースの内部構造設計

詳細設計では、基本設計で定義された各機能を、より小さな単位であるプログラムのモジュールやクラスに分割し、それぞれの内部ロジックやデータ構造を設計していきます。主な成果物は以下の通りです。

• クラス設計: オブジェクト指向プログラミングにおいて、各クラスが持つ属性（データ）や操作（メソッド）を定義します。クラス図（UML）などを用いてクラス間の関係性も示します。
• モジュール設計: 各機能を実現するための処理の流れ（アルゴリズム）や、モジュール間のデータの受け渡し方法などを定義します。シーケンス図（UML）などが用いられることもあります。
• データベース物理設計: 基本設計で作成した論理データモデルをもとに、実際に使用するデータベース管理システム（DBMS）に合わせて物理的なテーブルを設計します。テーブル定義書を作成し、各カラムのデータ型、長さ、制約（主キー、外部キーなど）を厳密に定義します。パフォーマンスを考慮したインデックス設計もこの段階で行います。
• API設計: 外部システムと連携する場合、そのインターフェースとなるAPIの仕様（リクエストの形式、レスポンスのデータ構造など）を詳細に定義します。

新人エンジニアが要件定義と設計で失敗しないための3つのコツ

要件定義と設計は、システム開発プロジェクトの成否を分ける非常に重要な工程です。しかし、経験の浅い新人エンジニアにとっては、どこに注意すれば良いのか分からず、思わぬ落とし穴にはまってしまうことも少なくありません。後工程での大規模な手戻りやプロジェクトの失敗を防ぐためにも、ここで紹介する3つのコツをしっかりと押さえておきましょう。

常に目的とゴールを意識する

要件定義や設計を進めていると、目の前の機能や技術的な課題にばかり目が行きがちです。しかし、最も重要なのは「なぜこのシステムを作るのか」「この機能で誰のどんな課題を解決するのか」という目的意識です。目的を見失うと、顧客が本当に求めていたものとは違う、自己満足のシステムが出来上がってしまいます。常にプロジェクトの原点に立ち返り、目的とゴールを意識することが、手戻りを防ぎ、価値あるシステムを生み出すための第一歩です。

具体的なアクションとして、以下の点を常に自問自答する癖をつけましょう。

意識すべきポイント	具体的なアクション
Why：なぜ作るのか？	顧客のビジネス上の課題や、システムを利用するエンドユーザーの本当のニーズは何かを常に考える。「この機能は、〇〇という課題を解決するために必要だ」と明確に説明できるようにする。
What：何を作るのか？	目的を達成するために、具体的にどのような機能が必要なのかを洗い出す。機能の範囲（スコープ）を明確にし、作るべきものと作らないものを関係者と合意する。
How：どうやって実現するのか？	技術的な制約や予算、納期などを考慮し、最も効率的で現実的な実現方法を検討する。複数の選択肢を比較検討し、その選定理由を論理的に説明できるように準備する。
5W1Hでの整理	「Who（誰が）」「When（いつ）」「Where（どこで）」「What（何を）」「Why（なぜ）」「How（どのように）」の観点で要件や仕様を整理することで、曖昧さをなくし、抜け漏れを防ぐ。

関係者とのコミュニケーションを密にする

システム開発は、決して一人で行うものではありません。顧客、プロジェクトマネージャー（PM）、先輩エンジニア、デザイナー、インフラ担当者など、様々な立場の「ステークホルダー（利害関係者）」が関わります。これらの人々との認識のズレが、後に大きな問題へと発展します。特に新人エンジニアは、「こんなことを聞いたら迷惑かもしれない」「たぶんこうだろう」といった思い込みでコミュニケーションを怠りがちですが、むしろ積極的に対話し、認識を合わせることが成功への近道です。

疑問や不安を感じたら、すぐに相談・確認する勇気を持ちましょう。丁寧なコミュニケーションは、信頼関係を築き、プロジェクトを円滑に進めるための潤滑油となります。

ステークホルダー別のコミュニケーションのポイント

関わる相手の立場や役割によって、コミュニケーションで注意すべきポイントは異なります。以下の表を参考に、円滑な対話を心がけましょう。

ステークホルダー	役割	コミュニケーションのポイント
顧客・ユーザー部門	システムの要望を出し、最終的な利用者となる。	専門用語や技術的な話を避け、相手の業務内容を理解した上で平易な言葉で対話する。図やモックアップ（画面の試作品）を用いて、システムのイメージを具体的に共有する。
プロジェクトマネージャー(PM)	プロジェクト全体の進捗、品質、コスト、人員を管理する責任者。	進捗状況や課題、リスクを正直かつ早めに報告・連絡・相談（報連相）する。自分の判断で仕様変更などを進めず、必ず承認を得る。
先輩エンジニア・上司	技術的な指導や成果物のレビューを行う。	分からないことは放置せず、自分で調べた上で質問する。「何が分からないのか」を具体的にして相談することで、的確なアドバイスをもらいやすくなる。
他チームの担当者 (デザイナー、インフラ等)	特定の専門領域を担当する。	相手の専門領域を尊重し、必要な情報を正確に伝える。依存関係がある作業については、スケジュールや仕様を密に連携する。

成果物（ドキュメント）の書き方を学ぶ

要件定義や設計の工程では、「要件定義書」や「基本設計書」「詳細設計書」といった様々なドキュメントを作成します。これらのドキュメントは、関係者間の認識を統一するための「共通言語」であり、開発作業の「設計図」となる極めて重要な成果物です。曖昧な記述や分かりにくいドキュメントは、誤解や実装ミスを生み、品質の低下や手戻りの原因となります。

「誰が読んでも」「いつでも」「同じように解釈できる」ドキュメントを作成するスキルは、エンジニアにとって必須の能力です。最初は時間がかかるかもしれませんが、質の高いドキュメントを作成する習慣を身につけましょう。

良いドキュメントを作成するためのチェックリスト

• 網羅性：必要な情報に抜け漏れがないか。考慮すべきケース（正常系、異常系）がすべて記述されているか。
• 正確性：記述されている内容に誤りがないか。事実と解釈が区別されているか。
• 一貫性：ドキュメント全体で用語や表現が統一されているか。他のドキュメントとの間に矛盾がないか。
• 明確性：曖昧な表現（例：「いい感じに」「なるべく」）を避け、具体的・定量的に記述されているか。
• 可読性：文章の構成は論理的か。図や表を効果的に活用し、視覚的に理解しやすくなっているか。

また、文章だけでは伝わりにくいシステムの振る舞いや構造は、UML（統一モデリング言語）などの図解表現を積極的に活用しましょう。例えば、システムの機能間のやり取りを示す「シーケンス図」や、ユーザーの操作フローを示す「アクティビティ図」、データベースの構造を示す「ER図」などを用いることで、より直感的で分かりやすいドキュメントを作成できます。プロジェクトで利用しているConfluenceやBacklogといった情報共有ツールの使い方をマスターし、情報を整理・蓄積していくことも重要です。

まとめ

本記事では、システム開発の土台となる要件定義と設計について、その役割の違いから正しい進め方、そして新人エンジニアが失敗しないためのコツまでを網羅的に解説しました。

要件定義は「何を作るか（What）」を顧客視点で定義する工程、設計は「どう作るか（How）」を開発者視点で具体化する工程です。この目的、担当者、成果物などの明確な違いを理解することが、プロジェクトを円滑に進めるための鍵となります。

システム開発を成功に導くためには、要件定義でゴールを明確にし、基本設計で骨格を作り、詳細設計で実装レベルに落とし込むというステップを着実に踏むことが不可欠です。なぜなら、この一連のプロセスによって、要求の抜け漏れや仕様の認識齟齬を防ぎ、手戻りの少ない高品質なシステム開発が実現できるからです。

新人エンジニアの皆さんは、常に目的意識を持ち、関係者とのコミュニケーションを大切にしながら、ドキュメント作成のスキルを磨いていきましょう。本記事で解説したポイントを実践し、価値あるシステム開発に貢献できるエンジニアを目指してください。