詳細設計

一言でいうと

基本設計で決めた仕様を、処理の手順、モジュールの分け方、データ構造など、実装に取りかかれる粒度まで具体化する工程です。内部設計とも呼ばれます。

提唱者と登場年

詳細設計に対応する英語のDetailed Designは、米国国防総省が1988年に発行したソフトウェア開発の規格DOD-STD-2167Aに工程として規定されています。この規格では、詳細設計の段階でソフトウェアの構成要素をさらに小さな単位（ユニット）に分け、ユニットごとに設計上の要件を定めます。段階の終わりには、詳細設計審査（Critical Design Review）を行うと定めています。

国内では、独立行政法人情報処理推進機構が2020年12月に公開した「情報システム・モデル取引・契約書」第二版が、内部設計を「共通フレーム2013のシステム方式の確立、システム方式の評価及びレビューに相当するもの」と定義しています。何を詳細設計に含めるかは組織や契約によって異なるため、この定義も工程の対応関係を示したものにとどまります。

何を解決するか

実装する人によって作り方がばらつく状態を防ぎます。基本設計の段階では、画面や外部とのやり取りといった外から見える振る舞いは決まっていても、それを内部でどう分担して処理するかは決まっていません。詳細設計で処理の流れ、例外時の扱い、テーブルの項目と関係を文書にすると、複数の担当者が並行して実装しても部品どうしの前提がそろいます。

この工程は、設計する人と実装する人が分かれている体制を前提にしています。外部の開発会社や複数のチームに実装を分担させる場合ほど、文書の役割が大きくなります。

実際の進み方

基本設計書を入力に、モジュールやクラスの構成、処理ごとの手順、データベースのテーブル定義、エラー処理の方針を作成します。単体テストで確かめる観点も、この段階で洗い出すことができます。

レビューは主に開発側の内部で行い、基本設計との整合と、実装できる粒度になっているかを確認します。レビューを通った詳細設計書をもとに実装と単体テストへ進みます。

導入でよくある失敗

• コードとほぼ同じ内容を文書に書き写し、実装後の修正に文書の更新が追いつかなくなる
• 設計者と実装者の間で質問の窓口を決めず、解釈の違いが単体テストの段階で表れる
• 基本設計の変更を詳細設計へ反映する手順が無く、文書どうしが食い違う

求人票にこの語がある場合に読み取れること

「詳細設計から実装まで」と書かれた求人は、仕様が決まった状態から開発に入る役割であることが多く、発注側との仕様調整は別の担当者が行う体制だと推定できます。受託開発やシステムインテグレーションの組織で使われる語です。レジュメで「詳細設計」を担当範囲に挙げている候補者には、設計書を自分で書いたのか、他者の設計書をもとに実装したのかを確認してください。

隣接手法との違い