案件票に「要件定義〜基本設計」と書かれていると、「どこまで自分で決める仕事なのか？」と迷うことはありませんか。
結論から言うと、要件定義はシステムが満たすべき条件を合意する工程、基本設計はその要件を画面・API・データ・外部連携などの具体的な外部仕様へ落とす工程です。
ただし、工程名や成果物の分け方は案件ごとに変わります。文書名を暗記するより、「何を決めるのか」「誰と合意するのか」「変更したらどこへ戻るのか」で見分けるのが実務的です。
要件定義と基本設計の違いを先に比較する
| 比較軸 | 要件定義 | 基本設計 |
|---|---|---|
| 主な目的 | システムが満たすべき条件を決める | 要件を具体的な外部仕様へ落とす |
| 中心となる問い | 何を実現する必要があるか | 利用者や外部システムからどう見える形にするか |
| 主な確認相手 | 業務担当、利用者、発注側、PM、開発側 | 業務担当、PM、設計・開発チーム、外部連携先 |
| 成果物の例 | 機能要件、非機能要件、業務ルール、対象範囲、制約 | 画面、画面遷移、API、帳票、外部I/F、データの外部仕様 |
| 変更時の影響 | 「何を作るか」自体が変わる | 合意済み要件の実現方法・見せ方が変わる |
IPAのDX SQUAREでも、要件定義では利用者のニーズや課題から要求を抽出し、ステークホルダーと合意して要件へまとめ、その後の基本設計で要件を具体化すると整理されています。
よく「要件定義＝WHAT、基本設計＝HOW」と説明されます。入口としては便利ですが、基本設計は内部実装の細部まで決める工程とは限りません。まずは外から見える仕様を具体化すると捉えると、詳細設計との違いも整理しやすくなります。
要件定義は「システムが満たす条件」を合意する
要件定義では、利用者や業務部門から出た要望を、そのまま機能名へ置き換えるのではなく、システムが満たすべき条件へ整理します。
たとえば「検索を使いやすくしたい」という要望だけでは、まだ要件として曖昧です。何に困っているのかを分解します。
- 検索結果が出るまで遅いのか
- 条件を指定しにくいのか
- 欲しいデータを絞り込めないのか
- スマートフォンで操作しにくいのか
- 検索結果をCSVで持ち出したいのか
ここで「誰が」「何に困っていて」「何ができれば解決なのか」「今回どこまで対応するのか」を合意できると、後工程が判断しやすくなります。
要件定義で確認したい5項目
- 目的：何の業務課題を解決するのか
- 対象：誰が、どの業務で使うのか
- 機能：システムとして何ができる必要があるか
- 非機能：性能・可用性・セキュリティなど何を満たすか
- 範囲と制約：今回やること・やらないこと、期限や既存環境の制約は何か
要件定義で大切なのは、実装方法を早く決めることではありません。後から「そもそも必要なものが違った」とならないよう、作る対象と完了条件をそろえることです。
基本設計は「合意した要件を外部仕様へ変える」
要件が決まったら、基本設計で利用者や外部システムから確認できる振る舞いへ落とします。
IPAの機能要件の合意形成ガイドでも、外部設計では要件定義の結果をもとに、システムと利用者、システム間のインタフェースや振る舞いを具体化すると整理されています。
- どの画面に何を表示するか
- どの操作でどこへ遷移するか
- APIへ何を渡し、何を返すか
- 入力エラー時に何を表示するか
- どの権限で何を操作できるか
- 外部サービスとどの情報をやり取りするか
- どのデータを保持し、利用者からどう見えるか
つまり、基本設計は「要件を満たすために、システムとしてどんな約束を外へ見せるか」を決める工程です。
クラス分割、メソッド構成、内部処理フロー、物理DB、例外処理の実装方式などは、案件によって詳細設計側で扱われます。工程の境界は固定ではないため、成果物一覧と責任範囲を先に確認しましょう。
CSVダウンロード機能で違いを見る
具体例として、「検索結果をCSVでダウンロードしたい」という要望を考えてみます。
要件定義で決めること
- 誰がCSVを必要としているか
- どの業務で使うのか
- どの検索条件を反映する必要があるか
- 必要なデータ項目は何か
- 個人情報を含めてよいか
- 対象件数や処理時間にどんな条件があるか
- 今回の開発範囲に含めるか
ここでは「CSV出力という機能が必要か」「どんな条件を満たすべきか」を合意します。
基本設計で決めること
- どの画面にダウンロードボタンを置くか
- どの検索条件を出力へ引き継ぐか
- CSVの列名・並び順・文字コードをどうするか
- 0件時にどう表示するか
- 権限がない利用者にはどう見せるか
- 件数超過やエラー時にどんなメッセージを返すか
同じCSV機能でも、要件定義は「必要な条件」、基本設計は「利用者から見える具体的な振る舞い」が中心です。
境界で迷ったら3つの質問で判断する
実務では、「この項目は要件定義書？ 基本設計書？」と迷うことがあります。そんなときは文書名より、次の3つを確認します。
- 必要な機能・条件そのものが変わるか：変わるなら要件定義へ戻る可能性が高い。
- 利用者や外部システムから見える約束が変わるか：変わるなら基本設計側の見直しが必要になりやすい。
- 外部仕様を変えず、内部の実装だけが変わるか：詳細設計や実装側で閉じる可能性が高い。
IPAのソフトウェア開発に関する資料でも、画面設計のような項目はユーザーの要求と設計仕様が連続しやすく、要件定義と基本設計の境界が必ずしも明確ではないと説明されています。
だからこそ「この工程なら絶対ここ」と決め打ちするより、誰と何を合意した情報なのかを追うほうが安全です。
よくある4つのズレと直し方
1. 要望をそのまま要件にする
「もっと使いやすく」「検索を速く」といった言葉は、そのままでは完了判定ができません。誰の何が改善すればよいのか、対象・条件・制約へ分解します。
2. 要件定義で画面や技術を固定しすぎる
本来の課題を確認する前に「Reactでこの画面を作る」と固定すると、別の方法で解決できる余地を失います。先に必要な結果を合意し、実現方法は設計で詰めます。
3. 基本設計で要件を勝手に変える
設計してみて実現が難しいと分かっても、担当者だけで要件を縮めてはいけません。性能、コスト、期限などの制約を整理し、要件の決定者へ戻して合意します。
4. 工程名だけで担当範囲を判断する
「基本設計」と書かれていても、実際には顧客ヒアリングを含む案件もあれば、確定済み要件を設計書へ落とすところから始まる案件もあります。工程名より、入力資料・成果物・承認者を確認します。
フリーランス案件では5項目を確認する
案件票に「要件定義〜基本設計」とあったら、担当範囲を具体化してから判断するとミスマッチを減らせます。
- 要求元：誰から要望を受け取るのか
- 整理範囲：要求整理から担当するのか、要件は確定済みか
- 合意相手：顧客・業務部門と直接確認するのか
- 成果物：要件定義書、画面、API、データ、外部I/Fのどこを作るのか
- 決定権：自分が案を出すのか、最終判断まで担うのか
特に単価や役割を比較するときは、「要件定義経験あり」というラベルだけでは深さが分かりません。何を整理し、誰と合意し、どこまで次工程へつないだかまで説明できると担当範囲が伝わります。
スキルシートの書き方例
△「要件定義・基本設計を担当」
○「利用部門からの変更要求を整理し、対象範囲・入力条件・権限を確認。合意した要件をもとに画面・API仕様を基本設計へ落とし、開発チームへの説明まで担当」
これは書き方の例です。実際に担当していないヒアリングや意思決定を追加せず、自分が行った仕事だけで整理してください。
レビューでは「要件→設計」を追えるか確認する
- 基本設計の各仕様が、どの要件を満たすものか説明できるか
- 要件にある対象範囲・制約が設計から抜けていないか
- 設計中に発見した未決事項を勝手に補完していないか
- エラー・権限・0件・上限など例外時の振る舞いが整理されているか
- 要件変更が起きた場合、影響する画面・API・データを追えるか
設計書をきれいに埋めることより、前工程の合意を次工程へ追跡できることが重要です。要件と基本設計のつながりが見えれば、変更時の影響調査もしやすくなります。
違いは「条件」と「外部仕様」で覚える
要件定義と基本設計の違いは、単純に「上流か、その次か」だけではありません。
要件定義ではシステムが満たすべき条件を関係者と合意し、基本設計ではその要件を利用者や外部システムから確認できる仕様へ具体化します。
次に案件票や設計書を見るときは、「これは何を満たすための条件か」「誰から見える仕様か」「変更したら誰との合意へ戻るか」の3点を確認してみてください。工程名だけでは見えなかった担当範囲が整理しやすくなります。
