基本設計

一言でいうと

要件定義で決めた内容をもとに、画面や帳票、他システムとの接続など、利用者から見える仕様を決める工程です。外部設計とも呼ばれます。

提唱者と登場年

基本設計は、日本の受託開発で工程の名前として定着した呼び名です。設計を段階に分け、段階ごとに公式のレビューを設けた規格の例に、米国国防総省が1988年に発行したソフトウェア開発の規格DOD-STD-2167Aがあります。この規格は設計を予備設計（Preliminary Design）と詳細設計（Detailed Design）の2段に分け、それぞれの終わりに公式のレビューを設けました。ただし予備設計の対象はソフトウェアの構成要素への要件の割り当てで、日本の基本設計が扱う画面や帳票の仕様とは中身が一致しません。

国内では、独立行政法人情報処理推進機構が2020年12月に公開した「情報システム・モデル取引・契約書」第二版が、外部設計書を「画面、帳票などのユーザインターフェース、他システムとの通信やデータ入出力等のインターフェースなど、本件ソフトウェアの入出力全般に関する仕様を定めた設計書」と定義しています。同契約書の初版は、経済産業省が2007年に公開しました。

何を解決するか

基本設計は、発注側と開発側が、作るものの外形に合意するための工程です。要件定義の段階では機能の目的が書かれていても、画面の項目、並び順、入力を誤ったときの表示までは決まっていません。基本設計でこれらを文書にし、発注側が確認して確定させることで、後の工程で「思っていた画面と違う」という手戻りを減らします。

前提として、発注側に確認と確定の権限がある担当者が必要です。モデル契約書も、外部設計書の確定を発注側の権限と責任として定めています。

実際の進み方

画面の一覧と遷移、画面ごとの入出力項目、帳票のレイアウト、外部システムとのインターフェース、主要なデータの定義を作成します。性能やセキュリティなど非機能の方式も、この段階で大枠を決めます。

文書がそろったら、発注側と開発側がレビューを行い、要件定義書と矛盾がないかを確認します。受託開発では、確定した基本設計書が以後の工程の契約上の基準になり、確定後の変更は変更管理の手続きで扱います。

導入でよくある失敗

• 発注側がレビューを形式的に通し、画面を操作する段階になって要望が大量に出る
• 基本設計と詳細設計の境界を決めずに進め、同じ内容を両方の文書に書くか、両方から漏らす
• 非機能の条件を後回しにし、詳細設計の段階で方式の見直しが必要になる

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

「基本設計から担当」と書かれている場合、実装に加えて、発注側や利用部門との仕様調整まで任される範囲だと読み取れます。受託開発やSIerの出身者の経歴書に多い語で、工程を分けた開発の経験を示します。自社サービスを開発する組織では、同じ内容の仕事が仕様策定やデザインレビューと呼ばれる場合があります。候補者には、確定させた設計書の範囲と、誰の承認で確定したかを確認してください。担当した範囲が具体的にわかります。

隣接手法との違い