当サイトの記事は編集部がIPAなど公的機関の公開資料と読者の声を調べて独自に執筆しています。
『要件定義と基本設計、どこまでが要件でどこからが設計なの？』と、打ち合わせのたびに境目で迷っている方も多いはずです。
結論から言うと、要件定義は「何を作るか」を決める工程で、基本設計は「利用者からどう見えるように作るか」を決める工程です。この記事では、1つの機能を例に2つの書き方を左右に並べて、線引きが目で見て分かるようにお伝えします。
要件定義と基本設計の違いは？
要件定義は「何ができればいいか」を発注側と開発側で合意する工程です。基本設計は、その合意を受けて、画面・帳票・操作・外部との連携など「利用者から見える部分をどう作るか」を決める工程です。
要件定義と基本設計は、どちらも開発の上流工程にあたります。ただ、決めることの中身と、話し合う相手との距離感が違うんです。
要件定義そのものの全体像は要件定義とはで紹介しています。ここでは2つの違いに絞って見ていきますね。
| 観点 | 要件定義 | 基本設計 |
|---|---|---|
| 決めること | 何を作るか（機能・品質・範囲） | 利用者から見える部分をどう作るか |
| 主な問い | 何ができればいいか | どんな画面・帳票・操作にするか |
| 中心になる人 | 発注側と開発側の両方 | 開発側（発注側は確認とレビュー） |
| 主な成果物 | 要件定義書、業務フロー図、機能一覧 | 基本設計書（画面設計、帳票設計、データ設計など） |
| 確かめるテスト | 受入テスト | システムテスト |
V字モデルで見るとつながりが分かる
開発の工程は、V字モデルという見方で整理されることがよくあります。左側の上流工程と、右側のテスト工程を対応させて考える見方です。
この見方では、要件定義の内容は受入テストで、基本設計の内容はシステムテストで確かめます。つまり要件定義書は「発注側が合格かどうかを判断する基準」、基本設計書は「開発側がシステム全体を確かめる基準」になるんです。
基本設計は外部設計とも呼ばれる
基本設計は、外部設計と呼ばれることもあります。利用者から見える「外側」を設計するからです。
これに対して、プログラムの内部の作りを決める工程を詳細設計（内部設計）と呼びます。要件定義・基本設計・詳細設計の3つをまとめて比べたい方は、要件定義・基本設計・詳細設計の違いもあわせて読んでみてください。
1つの機能で並べると、線引きがはっきり見える
ここがこの記事でいちばん伝えたいところです。定義を読むより、同じ機能を2つの工程で書き分けた例を見たほうが、境目はずっとつかみやすいんです。
架空の題材として、社内研修の受講申し込みを管理する仕組みを新しく作る場合の、「研修に申し込む」機能を例にします。
要件定義での書き方（例）
要件定義では、業務として何ができればいいかと、守るべき条件を書きます。画面の形にはまだ触れません。
| 番号 | 要件（例） |
|---|---|
| 1 | 社員は、公開中の研修の一覧から受けたい研修を選んで申し込める |
| 2 | 定員に達した研修は申し込めず、キャンセル待ちとして登録できる |
| 3 | 申し込みには上長の承認が必要で、承認されたら本人に知らせる |
| 4 | 研修の担当部署は、研修ごとの申込者と承認状況を一覧で確認できる |
| 5 | 申し込みの情報は、本人・上長・研修の担当部署だけが見られる |
基本設計での書き方（例）
基本設計では、上の要件を、利用者が実際に触る形に落とします。画面の項目や遷移、通知の文面、エラーの出し方などを決めます。
| 要件の番号 | 基本設計の内容（例） |
|---|---|
| 1 | 研修一覧画面に、研修名・日程・会場・残り枠を表示する。行を選ぶと研修詳細画面に移り、「申し込む」ボタンを置く |
| 2 | 残り枠がない研修は「満席」と表示し、ボタンを「キャンセル待ちに登録」に切り替える |
| 3 | 申し込むと上長に承認依頼の通知を送る。上長の承認画面には申込者・研修名・日程と、承認・差し戻しのボタンを置く |
| 4 | 担当部署向けに申込者一覧画面を作り、研修名で絞り込み、表計算ソフト形式で出力できるようにする |
| 5 | ログインした人の役割によって、表示するメニューと見られる申し込みを切り替える |
左右を見比べると、要件定義は「できること」を、基本設計は「どう見えるか・どう操作するか」を書いているのが分かりますよね。
文の中に「画面」「ボタン」「項目の並び」「メールの文面」が出てきたら、基本設計の話であることが多いです。「誰が」「何ができる」「どんな条件で」で書けるなら、要件定義の話と考えてみてください。
境目で起きやすい会話の例
実際の打ち合わせでは、要件定義の場で設計の話が出ることもよくあります。
利用部門「申し込みボタンは、画面の右上にあると押しやすいと思うんです」
開発側「ありがとうございます。ボタンの位置は基本設計で画面の案をお見せする時に決めさせてください。今日は、申し込みに上長の承認が要るかどうかを先に決めたいです」
利用部門「たしかに、そっちが決まらないと画面も決まらないですね」
設計の話が出た時は、否定せずに「どの工程で決めるか」を伝えて、メモに残しておくのがおすすめです。せっかくの意見を、基本設計の時に拾えるようにしておきましょう。
品質の要件も、基本設計で形が変わる
線引きは、機能だけでなく品質の要件にもあります。同じ研修の申し込みの例で見てみましょう。
| 要件定義での書き方（例） | 基本設計での書き方（例） |
|---|---|
| 申し込み開始日に社員が一斉に使っても、待たされずに申し込める | 申し込みが集中する日を想定して、画面の表示と登録の処理を分けて受け付ける構成にする |
| 申し込みの情報は、本人・上長・研修の担当部署だけが見られる | 役割ごとに見られる画面とデータの範囲を表にまとめ、ログイン時に役割を判定する |
| 研修の履歴は、後から本人が見返せる | 受講履歴の画面を作り、年度で絞り込めるようにする |
要件定義では「どのくらいの品質を約束するか」、基本設計では「その約束をどう実現するか」を書く、という関係は機能のときと同じなんです。
発注側は基本設計で何を確かめる？
基本設計は開発側が中心になって進めますが、発注側の出番がなくなるわけではありません。むしろ、画面の案が出てくるこの段階は、使う人の目で確かめる大事な機会です。
- 要件定義書の要件が、どの画面や帳票で実現されるかが分かる
- 実際の業務の順番どおりに、画面を操作できる流れになっている
- 例外の場面（差し戻し、取り消し、満席など）の画面がある
- 画面の言葉が、現場でふだん使っている言葉になっている
『画面の案を見たら、要件定義で決めたことと違う気がする』と感じたら、遠慮せずに聞いてみてください。ずれに気づくのが早いほど、直す手間は小さくて済みます。
要件定義書と基本設計書には、それぞれ何を書く？
『要件定義書と設計書、どの章に何を書けばいいの？』と迷う方も多いですよね。
会社ごとに様式は違いますが、よく見かける章立てを並べると、次のようになります。
| 要件定義書の主な章（例） | 基本設計書の主な章（例） |
|---|---|
| 背景・目的、現状の課題、目指す姿 | システムの全体構成 |
| 対象範囲（スコープ） | 機能の一覧と機能ごとの説明 |
| 業務要件（業務フロー・業務一覧） | 画面の一覧、画面のレイアウト、画面遷移 |
| 機能要件（機能一覧・画面一覧・帳票一覧・データ・外部連携） | 帳票のレイアウト |
| 非機能要件 | データの項目と持ち方 |
| 移行要件、運用・保守要件 | 外部システムとの連携の方式 |
| 制約条件・前提、用語集、未決事項、承認欄 | 権限の設計、エラーの扱い、メッセージの一覧 |
要件定義書にも「画面一覧」が入ることがありますが、ここでは「どんな画面が必要か」の名前と目的までです。レイアウトや項目の並びは、基本設計書に書きます。
要件定義書の章ごとの役割は要件定義書とはでも紹介しています。
要件定義書の1行と設計書の1行をつなげておく
要件定義書と設計書は、別々に作るとつながりが見えなくなりがちです。設計書の各項目に「元になった要件の番号」を書いておくと、後から確かめやすくなります。
- 要件定義書の要件に、通し番号を振っておく
- 基本設計書の画面や機能ごとに、対応する要件の番号を書く
- どの設計とも結びつかない要件が残っていないかを確かめる
- どの要件とも結びつかない設計がないかも確かめる
- 要件が変わった時は、番号をたどって影響する設計を洗い出す
4番目の確認は見落とされがちです。要件にない設計は、頼まれていない機能が紛れ込んでいるサインかもしれません。
外部設計・概要設計・アーキテクチャ設計…設計の呼び名を整理
『システム設計、概要設計、アーキテクチャ設計、概念設計…。名前が多すぎて、どれが基本設計なの？』という声もよく聞きます。
実は、設計の呼び名は会社や現場によってかなり揺れます。ここでは、よく使われる意味をまとめておきますね。
| 呼び名 | よく使われる意味 | 要件定義との関係 |
|---|---|---|
| 基本設計 | 利用者から見える部分（画面・帳票・操作・外部連携）を決める | 要件定義の直後に行う |
| 外部設計 | 基本設計とほぼ同じ意味で使われる | 要件定義の直後に行う |
| 概要設計 | 全体の構成を決める工程、または基本設計の別名として使われる | 要件定義の後、基本設計と同じ頃か前に行う |
| 方式設計・アーキテクチャ設計 | サーバー・ネットワーク・ソフトの組み合わせなど全体の構成を決める | 非機能要件を受けて決める |
| 概念設計 | 全体像をおおまかに描く段階を指して使う現場がある | 要件定義の前後で、構想をまとめる時に使われる |
| システム設計 | 設計工程全体をまとめて指すことが多い | 要件定義の後に続く工程の総称 |
| 詳細設計・内部設計 | プログラムの内部の作りを決める | 基本設計の後に行う |
IPAの「共通フレーム2013」では、システム要件定義の後にシステム方式設計、ソフトウェア要件定義の後にソフトウェア方式設計と詳細設計が続く、という並びで工程が説明されています。現場の「基本設計」「詳細設計」という呼び名と、言葉が1対1で対応するわけではない点だけ覚えておきましょう。
アーキテクチャ設計は非機能要件と深くつながる
アーキテクチャ設計（方式設計）は、要件定義で決めた非機能要件の影響を強く受けます。
例えば「研修の申し込み開始日に社員が一斉にアクセスしても止まらない」と決めていれば、それに耐えられる構成を考えることになります。非機能要件があいまいだと、構成を決める根拠がなくなってしまうんです。
非機能要件の合意には、IPAの「非機能要求グレード」が使えます。可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つの大項目について、レベルを0〜5の段階で選んでいく方式です。
呼び名に迷ったら最初にそろえる
呼び名が揺れること自体は、珍しいことではありません。大事なのは、プロジェクトの中で意味をそろえておくことです。
- 「基本設計」と「外部設計」を同じ意味で使うかどうか
- 「概要設計」「方式設計」を基本設計の中でやるか、別の工程にするか
- 要件定義書と基本設計書の承認者がそれぞれ誰か
- 画面のレイアウトを要件定義と基本設計のどちらで決めるか
「それは設計の話」と言えるようになる判断表
『要件定義の場で、どこまで答えればいいか分からない』という方のために、迷った時の判断表を用意しました。
| 出てきた話題（例） | どちらで決める？ | 理由 |
|---|---|---|
| 申し込みに上長の承認が要るか | 要件定義 | 業務のルールそのものだから |
| 定員を超えた時にどうするか | 要件定義 | 業務として何ができればいいかの話だから |
| キャンセル待ちの順番の決め方 | 要件定義 | 利用者にとっての公平さに関わる決めごとだから |
| 申し込みボタンの位置や色 | 基本設計 | 見せ方の話だから |
| 一覧の並び順の初期値 | 基本設計 | 画面の作り方の話だから |
| 通知メールの件名と本文 | 基本設計 | 見せ方の話だから（送ること自体は要件定義） |
| 何人が同時に使っても止まらないか | 要件定義（非機能要件） | 品質の約束だから |
| どのサーバー構成にするか | 基本設計（方式設計） | 品質の約束をどう実現するかの話だから |
迷った時は「これを決めないと、作るものの範囲や費用が変わるか」を考えてみてください。変わるなら要件定義で、変わらないなら基本設計で決める、という目安が使えます。
要件定義の場で画面のレイアウトまで決めようとして、業務のルールが決まらないまま時間切れになることです。逆に、承認の要否のような業務ルールを基本設計まで先送りすると、画面を作ってから作り直しになりやすくなります。
要件定義ガイド
まずは型をそろえよう｜要件定義書のテンプレートと記入例
章立て・各章に書くこと・1行の記入例をひとつの表にまとめました。白紙から書き始める前に、型を手元に置いておきましょう。
無料要件定義書のテンプレートを見る当サイトの記事ページに移動します。
要件定義の後、基本設計に入る前に確かめたいこと
要件定義が終わったら、すぐに基本設計に飛び込みたくなりますよね。ただ、その前に一度立ち止まって見ておきたいことがあります。
- 要件定義書が発注側と開発側の両方に承認されている
- 未決事項が一覧になっていて、決める期限と担当が書かれている
- 非機能要件が「速く」「安全に」ではなく、確かめられる形で書かれている
- 要件定義の場で出た設計の意見が、メモとして残っている
要件定義から運用までの全体の流れは要件定義から運用までの流れで紹介しています。
よくある相談に答えます
要件定義と基本設計について、質問サイトでよく見かける相談を要約して、編集部から答えます。
相談1：要件定義と基本設計の線引きを、打ち合わせで言えるようにしたい
要件定義の場で質問された時に、「それは設計の話です」と自信を持って言えるようになりたい、という相談です。
「作るものの範囲や業務のルールが変わる話」は要件定義、「見せ方や作り方の話」は基本設計、と分けて考えると判断しやすくなります。この記事の判断表のように、自分のプロジェクトでもよく出る話題を表にしておくと、打ち合わせで迷わずに済みますよ。
言い方にも少し気を配りたいところです。「それは設計の話です」と切るより、「それは基本設計で決めたいので、メモしておきますね」と伝えると、相手も安心して次の話に進めます。
相談2：要件定義の工程で、設計や実装に近い資料まで求められる
要件定義の段階なのに、設計書や実装に近いレベルの資料を作るよう言われて戸惑っている、という相談です。
発注側が完成の姿を早く確かめたい時に、こうした依頼が出ることがあります。まずは「何のためにその資料が必要か」を聞いてみてください。画面のイメージを確かめたいだけなら、ラフな画面案で十分なこともあります。ただ、契約で決めた範囲を超える作業になる場合は、上司や担当の営業と相談して、工程や費用の扱いを決めておきましょう。
相談3：要件定義や基本設計は、どこで覚えるもの？
プログラミングは独学できても、要件定義や基本設計は実際のプロジェクト以外で経験を積めるのか、という相談です。
- 身近な業務を題材に、要件一覧と画面の案を自分で書いてみるのが練習になります
- 先輩が書いた要件定義書と基本設計書を並べて読み、どの要件がどの設計になったかをたどるのもおすすめです
- 打ち合わせの議事録を書く役を引き受けると、要件が決まっていく流れを間近で見られます
未経験から身につける順番は要件定義のスキルを未経験から身につける方法で詳しく紹介しています。
よくある質問
要件定義と基本設計は、同じ人が担当してもいいですか。
問題ありません。小さなプロジェクトや社内開発では、同じ人が両方を担当することもよくあります。その場合も、要件定義書の承認を取ってから基本設計に入ると、手戻りを減らせます。
要件定義書と基本設計書は、1冊にまとめてもいいですか。
まとめることもできます。ただ、承認する人や確かめるテストが違うので、章を分けて「どこまでが合意済みの要件か」が分かるようにしておくのがおすすめです。
基本設計の段階で要件を変えたくなったらどうしますか。
基本設計の中で勝手に変えず、変更の依頼として発注側と話し合います。決まった内容は要件定義書にも反映して、承認を取り直しておきましょう。
要件定義の段階で画面のイメージを見せてもいいですか。
見せてもかまいません。言葉だけでは伝わりにくい要件を確かめるのに役立ちます。ただ、その画面がそのまま完成形になるわけではなく、レイアウトなどは基本設計で改めて決めることを、見せる時に伝えておきましょう。
外部設計と基本設計は同じものですか。
多くの現場で、ほぼ同じ意味で使われています。ただ呼び方は会社によって揺れるので、プロジェクトの最初に確かめておくと安心です。
まとめ
- 要件定義は「何を作るか」、基本設計は「利用者からどう見えるように作るか」を決める工程です
- 1つの機能で並べると、要件定義は「できること」、基本設計は「画面や操作」を書いているのが分かります
- 要件定義書の画面一覧は名前と目的まで、レイアウトは基本設計書に書きます
- 外部設計・概要設計・アーキテクチャ設計などの呼び名は揺れるので、最初にそろえておきましょう
- 迷ったら「作る範囲や費用が変わるか」で、どちらの工程で決めるかを判断できます
コメント