当サイトの記事は編集部がIPAなど公的機関の公開資料と読者の声を調べて独自に執筆しています。
『要件定義、基本設計、詳細設計。順番は分かるけど、中身の違いを説明しようとすると言葉に詰まる』という方も多いはずです。
結論から言うと、3つは同じものを「何を作るか」「どう見せるか」「中でどう動かすか」と、だんだん細かくしていく工程です。この記事では、1つの画面を例に、工程ごとに書く中身がどう変わるかを並べてお見せします。
要件定義・基本設計・詳細設計の違いは？
要件定義は「何ができればいいか」、基本設計は「利用者からどう見えるか」、詳細設計は「プログラムの中でどう動くか」を決めます。後の工程ほど、書く内容が細かくなり、読む人が開発側に寄っていきます。
3つの工程は、どれも開発の前半にあたる上流工程です。ただ、決める相手と細かさがはっきり違うんです。
要件定義そのものの意味は要件定義とはで詳しく紹介しています。
| 観点 | 要件定義 | 基本設計（外部設計） | 詳細設計（内部設計） |
|---|---|---|---|
| 決めること | 何を作るか | 利用者から見える部分をどう作るか | プログラムの中の作り |
| 主な読み手 | 発注側の承認者、開発側 | 発注側の確認者、開発側 | 開発担当（プログラマー） |
| 書く中身 | 業務要件、機能要件、非機能要件 | 画面、帳票、操作、データ、外部連携 | 処理の手順、部品の分け方、データの扱い |
| 確かめるテスト | 受入テスト | システムテスト | 結合テスト、単体テスト |
発注側がどこまで関わるかも違う
要件定義は、発注側と開発側が一緒に決める工程です。基本設計では、発注側は画面の案などを確かめる役になります。
詳細設計は、ほとんど開発側の中で進みます。発注側が詳細設計書を細かく読むことは少ないですよね。
呼び方は会社によって揺れる
基本設計を「外部設計」、詳細設計を「内部設計」と呼ぶ現場も多いです。さらに、全体の構成を決める工程を「方式設計」や「概要設計」と分けて呼ぶこともあります。
IPAの「共通フレーム2013」でも、要件定義の後にシステム方式設計、ソフトウェア方式設計、ソフトウェア詳細設計と続く並びで説明されています。言葉が現場の呼び名と1対1で対応するわけではないので、プロジェクトの最初に意味をそろえておくと安心ですよ。
要件定義と基本設計の境目をもっと詳しく知りたい方は、要件定義と基本設計の違いで1つの機能を例に並べています。
1つの画面で比べると、書く細かさがこう変わる
ここがこの記事でいちばん伝えたいところです。同じ画面について、3つの工程でそれぞれ何を書くのかを並べてみましょう。
架空の題材として、会社に来るお客さまの来訪予約を登録する画面を例にします。社員が事前に来訪予約を入れておき、受付で確認できるようにする仕組みです。
要件定義で書くこと（例）
要件定義では、画面の形には触れず、業務として何ができればいいかを書きます。
| 番号 | 要件（例） |
|---|---|
| 1 | 社員は、来訪の日時・来訪者の会社名と氏名・面会する社員を事前に登録できる |
| 2 | 受付担当は、当日の来訪予定を一覧で確認できる |
| 3 | 来訪者が到着したら、面会する社員に知らせる |
| 4 | 来訪者の情報は、登録した社員・面会する社員・受付担当だけが見られる |
基本設計で書くこと（例）
基本設計では、上の要件を、利用者が触る画面の形に落とします。
| 項目 | 基本設計の内容（例） |
|---|---|
| 画面の項目 | 来訪日、来訪時刻、来訪者の会社名、来訪者の氏名、人数、面会する社員、備考 |
| 入力の決まり | 来訪日は今日以降のみ。来訪者の氏名と面会する社員は入力が要る |
| ボタン | 「登録する」「戻る」 |
| 画面の移り方 | 登録すると確認のメッセージを出し、来訪予定一覧の画面に戻る |
| エラーの見せ方 | 入力が足りない項目の横に、何が足りないかを表示する |
詳細設計で書くこと（例）
詳細設計では、「登録する」を押した後に、プログラムの中で何がどの順番で起きるかを書きます。
| 項目 | 詳細設計の内容（例） |
|---|---|
| 処理の手順 | 入力の決まりを確かめ、問題がなければ来訪予約のデータを保存し、一覧画面へ移る |
| 入力の確かめ方 | 来訪日が今日より前ならエラーにする。面会する社員は社員の一覧に存在するかを確かめる |
| データの保存 | 来訪予約のデータに、登録した社員と登録した日時を一緒に記録する |
| 失敗した時 | 保存に失敗したら内容を記録に残し、利用者には再度試すよう案内する |
| 部品の分け方 | 入力の確かめ、保存、通知を別々の部品に分け、ほかの画面からも使えるようにする |
3つを上から読むと、同じ「登録できる」という話が、だんだん細かくなっていくのが分かりますよね。
要件定義は「発注側が読んで判断できる」細かさ、基本設計は「利用者の目で確かめられる」細かさ、詳細設計は「プログラマーが迷わず作れる」細かさ、と考えると書き分けやすくなります。
同じ要件でも、決める人の顔ぶれが変わる
細かくなるにつれて、話し合う相手も変わっていきます。来訪予約の例で、工程ごとの会話を想像してみてください。
要件定義の場では、こんな会話になります。
利用部門「当日に急に来るお客さまもいるので、当日の予約も入れられるようにしたいです」
開発側「分かりました。当日の予約も受け付ける、を要件に入れておきますね」
基本設計の場では、話題が画面に移ります。
開発側「当日の予約は、日付の欄に今日の日付を最初から入れておく形でいかがでしょう」
利用部門「それなら入力の手間が減りますね。その案で進めてください」
詳細設計の段階になると、話し合いは開発側の中が中心です。今日の日付をどこから取るか、時刻の確かめ方をどうするかといった話を、設計の担当とプログラマーの間で詰めていきます。
誰が書いて、どのテストで確かめる？
『それぞれの工程で作った書類は、後で何に使うの？』と疑問に思う方もいるかもしれません。
実は、それぞれの書類は、後のテストで「正しくできたか」を確かめる基準になるんです。左側の上流工程と右側のテスト工程を対応させるV字モデルという見方で整理すると、次のようになります。
| 上流工程の書類 | 主に書く人 | 対応するテスト | テストで確かめること（来訪予約の例） |
|---|---|---|---|
| 要件定義書 | 開発側が中心、発注側と一緒にまとめる | 受入テスト | 社員が予約を入れ、受付が当日の一覧で確認できるか |
| 基本設計書 | 開発側 | システムテスト | 画面の項目・移り方・エラー表示が設計どおりか |
| 詳細設計書 | 開発側 | 結合テスト、単体テスト | 入力の確かめ方や保存の処理が設計どおりに動くか |
要件定義から設計、テスト、運用までの全体の流れは要件定義から運用までの流れで紹介しています。
工程ごとに書類を引き継ぐ手順
- 要件定義書の要件に番号を振り、発注側と開発側で承認する
- 基本設計書の画面や機能に、元になった要件の番号を書く
- 詳細設計書の処理に、元になった基本設計の項目を書く
- テストの項目にも、どの書類のどの項目を確かめるかを書く
番号でつないでおくと、要件が変わった時に、どの設計とどのテストに影響するかをすぐたどれます。
境目で迷った時はどう決める？
『この話は要件定義？それとも設計？』と、打ち合わせの途中で迷う場面はよくありますよね。
迷った時は、その話が「誰にとって大事か」を考えてみてください。
- 業務のルールや作る範囲が変わる話は、要件定義で決める
- 利用者が見る画面や帳票の形の話は、基本設計で決める
- 利用者からは見えない、プログラムの中の作りの話は、詳細設計で決める
- 決めないと費用や期間が変わる話は、できるだけ早い工程で決める
例えば、来訪予約で「当日の予約も受け付けるか」は業務のルールなので要件定義です。「来訪日を選ぶ欄をカレンダー形式にするか」は基本設計、「日付の確かめ方をどの部品で行うか」は詳細設計になります。
要件定義の段階で、詳細設計にあたる処理の手順まで決めようとすることです。発注側には判断しにくい話が増えて、打ち合わせが長引きます。逆に、業務のルールを詳細設計まで決めずにおくと、プログラマーが自分の判断で決めてしまい、受入テストで食い違いが見つかりやすくなります。
要件定義ガイド
まずは型をそろえよう｜要件定義書のテンプレートと記入例
章立て・各章に書くこと・1行の記入例をひとつの表にまとめました。白紙から書き始める前に、型を手元に置いておきましょう。
無料要件定義書のテンプレートを見る当サイトの記事ページに移動します。
3つの書類で、よく起きる抜け漏れ
工程を分けて書くと、工程と工程のすき間で抜け漏れが起きることがあります。よく見かけるものを表にまとめておきますね。
| 抜けやすいところ（例） | 起きること | 防ぎ方 |
|---|---|---|
| 要件にある通知が、基本設計の画面にない | 到着しても社員に知らせが届かない | 要件の番号と画面を対応表でつなぐ |
| 基本設計のエラー表示が、詳細設計の処理にない | 入力ミスの時に画面が止まる | 基本設計の項目ごとに処理を書く |
| 見られる人の決まりが、設計で具体化されていない | 関係のない社員も来訪者の情報を見られる | 権限の決まりを基本設計で表にする |
各工程が開発全体のどこに位置するかは、要件定義プロセスとはでも紹介しています。
よくある相談に答えます
要件定義・基本設計・詳細設計について、質問サイトでよく見かける相談を要約して、編集部から答えます。
相談1：職場で飛び交う工程の言葉が、それぞれ何をするのか分からない
要件定義、基本設計、詳細設計、開発、単体テストといった言葉が職場で使われていて、それぞれの中身を知りたい、という相談です。
要件定義は「何を作るか」、基本設計は「どう見せるか」、詳細設計は「中でどう動かすか」を決める工程です。開発でプログラムを作り、単体テストで部品ごとに正しく動くかを確かめます。この記事の来訪予約の例のように、1つの画面で順に追うと、つながりが見えてきますよ。
相談2：基本設計と詳細設計は何が違うのか
要件定義の進め方と一緒に、基本設計と詳細設計の違いを知りたい、という相談です。
いちばんの違いは「利用者から見えるかどうか」です。基本設計は画面や帳票など利用者が触る部分を、詳細設計は利用者からは見えないプログラムの中の作りを決めます。見える部分なら基本設計、見えない部分なら詳細設計、と覚えておくと迷いにくくなります。
来訪予約の例でいえば、日付を選ぶ欄の形は基本設計、その日付が正しいかを確かめる処理の順番は詳細設計です。同じ「日付」の話でも、見える部分と見えない部分で工程が分かれるんです。
相談3：業務経歴書に工程の名前を書く時、どこまで書いていいのか
業務経歴書に、要件定義・基本設計・詳細設計などの工程名を書く時、それぞれがどんな作業を指すのか知りたい、という相談です。
- 要件定義は、発注側との打ち合わせで要件を決め、要件定義書をまとめた経験を指します
- 基本設計は、画面や帳票などの設計書を作った経験を指します
- 詳細設計は、プログラムの中の処理を設計した経験を指します
- 工程名だけでなく、担当した書類や役割を一言添えると伝わりやすくなります
よくある質問
要件定義と詳細設計は、どちらが難しいですか。
難しさの種類が違います。要件定義は発注側と話し合って合意を取る難しさ、詳細設計はプログラムの作りを正確に決める難しさがあります。
小さな開発でも、3つの工程を全部やる必要がありますか。
工程を分けて書類を作らないこともあります。ただ、何を作るか、どう見せるか、中でどう動かすかを決めること自体は、規模が小さくても省けません。
要件定義が終わってから、詳細設計まで飛ばすことはありますか。
小さな改修では、基本設計と詳細設計をまとめて1つの書類にすることがあります。ただ、利用者から見える部分を確かめる機会がなくなると受入テストで食い違いが見つかりやすいので、画面の案だけでも発注側に見てもらうのがおすすめです。
詳細設計書は発注側も確認しますか。
確認しないことが多いです。発注側は要件定義書と基本設計書を中心に確かめ、詳細設計は開発側の中でレビューします。
まとめ
- 要件定義は「何を作るか」、基本設計は「どう見せるか」、詳細設計は「中でどう動かすか」を決めます
- 1つの画面で並べると、後の工程ほど書く中身が細かくなっていくのが分かります
- それぞれの書類は、受入テスト、システムテスト、結合テストと単体テストの基準になります
- 迷った時は「業務のルールか」「利用者から見えるか」で、どの工程で決めるかを判断できます
コメント