- 読み
- きほんせっけい・しょうさいせっけい
- 英語
- Basic Design / Detailed Design
- 別名・関連
- 外部設計、内部設計
なぜ重要か
要件定義が「何を作るか」を決めるのに対し、設計は「どう作るか」を決めます。基本設計の段階で画面の構成や入力項目、帳票の形を確認しておけば、完成後に「使いにくい」「項目が足りない」と気づく事態を減らせます。詳細設計は開発者が実装の見通しを立てるためのもので、複数人で開発する場合や、後から別の人が保守する場合に特に価値があります。
発注・開発の実務での意味
発注者が主に確認するのは基本設計です。画面のイメージ（ワイヤーフレーム）、入力項目の一覧、データの持ち方、他システムとの連携方法などが提示されるので、実際の業務に照らして違和感がないかを見ます。この段階での修正は、実装後の修正より格段に少ない手間で済みます。
詳細設計は、開発者がどこまで文書化するかが案件によって異なります。小規模な開発では、詳細設計書を厚く作るより、動く画面を早く見せて調整するほうが効率的なこともあります。ただし、保守を別の会社や担当者に引き継ぐ可能性があるなら、データ構造と主要な処理の説明は残しておくべきです。設計書の範囲と粒度は、見積の段階で確認しておきましょう。
関連する用語
この用語が出てくるガイド
- 要件定義とは何をすることか — 発注前に整理したい5つのこと要件定義はシステムで何を実現するかを合意する工程です。発注前に整理したい目的と成功条件、現状業務の流れ、利用者と権限、扱うデータ、やらないことの5つを、想定例を交えて解説します。
- システム開発の見積書の読み方 — 工数・単価・前提条件のチェックポイントシステム開発の見積書は総額よりも内訳と前提条件が重要です。明細の見方、人月と単価の関係、前提条件と除外事項、仕様変更時の扱い、複数の見積を比較する手順を整理します。
- 他社が作ったシステムの引き継ぎ・保守を依頼するときのチェックリスト前の開発会社が作ったシステムの保守を別の会社に引き継ぐときの手順を、資料・アカウント・ソースコード・環境の棚卸しから調査、リスク整理、保守範囲の合意、移行まで、確認項目の表とともに解説します。
- 小さな会社のためのRFP（提案依頼書）の書き方小さな会社が Web システム開発を依頼するときの RFP（提案依頼書）の書き方を手順で解説します。入れる項目の一覧、要件定義との関係、避けたい書き方を整理します。
- Webシステム開発の費用はどう決まるか — 相場の「考え方」と見積の内訳Webシステム開発の費用がどのように決まるのかを、工数と単価、要件の粒度、品質・非機能要件、保守費、変動要因の観点から解説します。金額の相場ではなく、見積を読み解くための考え方を整理します。
- 請負契約と準委任契約の違い — Web開発を依頼するときの契約形態請負契約は「完成」に、準委任契約は「作業」に対価を払う契約です。両者の比較、契約不適合責任と検収の考え方、工程ごとの使い分け、契約前に書面で確認したい項目を整理します。
関連するサービス
監修: Unlogical Systems合同会社（杉並区・西荻窪）公開