更新日 2023.12.13
カテゴリーシステム開発

外部設計とは｜内部設計との違い・重要性・外部設計書のサンプルを紹介！

外部設計は、システム開発プロジェクトの成否を分ける重要な開発工程。開発を外注していても発注側の積極的な関与が必要です。そこで本記事では、開発プロジェクトにおける重要性から内部設計との違い、成果物となる外部設計書のサンプルまで、外部設計の全体像を解説していきます。

なお、システム開発会社の探し方・選び方がわからない！という方はシステム幹事にお気軽にご相談ください。貴社の目的・予算にあった最適な会社を厳選してご紹介します。相談料・会社紹介料などは無料です。

【無料】システム開発会社を紹介してもらう

1. ウォーターフォール型システム開発における外部設計の位置付け
2. 外部設計とは
1. 2-1. 外部設計のアウトプットは外部設計書
2. 2-2. 外部設計のインプットとなる要件定義との関係
3. 内部設計とは
1. 3-1. 内部設計のアウトプットは内部設計書
4. 外部設計と内部設計の違い・関係性
5. 外部設計が重要なのはなぜか
6. 外部設計書を構成するドキュメントのサンプル
7. 【まとめ】外部設計の重要性・全体像を紹介しました

ウォーターフォール型システム開発における外部設計の位置付け

外部設計は、ウォーターフォール型システム開発プロジェクトの「上流工程」に位置付けられる重要な開発工程です。まずは、おさらいの意味を含め、ウォーターフォール型システム開発、および上流工程について簡単に解説しておきましょう。

ウォーターフォール型システム開発とは、水が上流から下流に流れるように、順を追って開発ステップを進めていくシステム開発手法のこと。完成までに「要求定義」>「要件定義」>「外部設計」>「内部設計」>「開発（プログラミング）」>「テスト」という工程を経る場合が一般的です。

このうち、要求定義から内部設計まで、実際の開発に取り掛かる前に「どのようなシステムを作るのか」を明確にする開発工程を「上流工程」といいます。順を追って開発ステップを進めるウォーターフォール型の場合、1つの開発ステップを完了させてから次のステップに移ることが原則。前の開発ステップに逆戻りすることは想定されていません。

上流工程の開発ステップ	概要
要求定義	企画者が開発するシステムに求める要求を定義するステップ
要件定義	システムに求められる要求をどのように実現するかを定義するステップ
外部設計	要件定義で定めたシステムをどのように作るか設計するステップ
内部設計	外部設計されたシステムを開発者がどのように実現するべきか設計するステップ

【無料】システム開発会社を紹介してもらう

外部設計とは

上流工程のうち、要件定義の後、内部設計の前に位置付けられる開発工程が「外部設計」です。外部設計（External Design）とは、ユーザーの目にする「システムの外側」を設計する開発工程のこと。

具体的には、要件定義で定めた「システムへのニーズ」を実現するため、実装する機能を大枠で決定・設計する工程。システムのベーシックな大枠、全体像を決めるステップのため「基本設計（Basic Design）」とも呼ばれます。開発するシステムによって異なりますが、外部設計のステップでは、主に以下の項目を設計します。

外部設計の主な設計項目	概要
システム設計	機能要件 / 非機能要件をもとに、ニーズを実現するのに必要なシステム構成を設計
画面設計	画面一覧、遷移図など、ユーザーのアクションに応じた操作画面を設計
帳票設計	納品書や請求書などの帳票画面を設計
バッチ設計	データの自動処理（バッチ処理）の手順 / 方法を設計
テーブル・ファイル要件	取り扱うファイルの定義、データを処理 / 保管を担うデータベースの設計
外部インターフェース設計	開発するシステムと連携する、外部システムとの接続 / 連携方法を設計

外部設計のアウトプットは外部設計書

外部設計のステップで設計された各項目は、成果物としてのドキュメント「外部設計書」へとまとめられます。各設計項目で作成される主な設計書は以下の通り。

外部設計の主な設計項目	作成するドキュメントの例
システム設計	ハードウェア / ソフトウェアを含むシステム / ネットワーク構成図など
画面設計	画面一覧、レイアウト図、遷移図、入出力項目など
帳票設計	帳票一覧、レイアウト図、帳票編集定義など
バッチ設計	バッチ処理一覧、処理フロー図、処理定義など
データベース設計	テーブルファイル一覧、ER図、CRUD図など
ファイル設計	ファイル一覧、レイアウト図など
外部インターフェース設計	外部インターフェース一覧、レイアウト図など

外部設計のインプットとなる要件定義との関係

もちろん、各項目はゼロから設計されるわけではありません。外部設計は、要件定義の結果として作成される成果物「要件定義書」をベースに作成されます。要件定義書に記載される定義項目は、主に以下の通り。

要件定義書の主な定義項目	概要
システム要件	要求定義をもとに、予算・技術面を考慮しながらシステム化するもの / しないものを選別し、開発の方向性をを定義
機能要件	システム要件をもとに、実装しているべき必要な機能を定義
非機能要件	機能以外でシステムに求められる要件を定義。可用性、拡張性、セキュリティなど
技術要件	利用するプラットフォーム / ライブラリ / 言語など、開発に必要な技術を定義
その他要件	システムの特性に応じてクリアすべき法的規制など

つまり、要件定義のアウトプットとして作成される要件定義書は、外部設計するために必須のインプットだという関係性。要件定義書に不備があれば、当然、外部設計のステップにも大きな影響を与えます。

【無料】システム開発会社を紹介してもらう

内部設計とは

システム開発の設計ステップが、なぜ「外部設計」「内部設計」に別れているのか？疑問を感じる方のために、内部設計についても簡単に解説しておきましょう。

内部設計（Internal Design）とは、外部設計で具体化したシステムの機能を、どのように実現していくのか？開発者の指標となる設計書を作成する開発ステップのこと。外側（ユーザー）からみた機能の内部構造を設計するため「内部設計」と呼ばれます。

内部設計のアウトプットは内部設計書

内部設計のステップで設計された各項目は、成果物としてのドキュメント「内部設計書」へとまとめられます。しかし、システム開発を外注する場合、内部設計書は依頼側に公開されないこともあります。各設計項目で作成される主な設計書は以下の通り。

内部設計の主な設計項目	作成するドキュメントの例
クラス図	システムを構成するクラスの関係を示す静的資料
モジュール構成図	各機能の処理に必要なモジュールを示す静的資料
アクティビティ図	操作 / 処理の流れを示した動的資料
シーケンス図	クラス / オブジェクト間のやりとりを時間軸で示した動的資料
IPO（処理機能記述）	バッチ処理などの入力 / 処理 / 出力の流れを示す動的資料
開発方針 / ルール	フレームワーク / ライブラリ / 言語 / 記述ルールなどの指示書

外部設計と内部設計の違い・関係性

ここまでの解説でお分かりのように、外部設計が「ユーザーから見えるシステムの操作性 / 機能を設計する」のに対し、内部設計は「機能を実現する内部構造を設計」します。つまり、外部設計はシステムへの要求を具体化する企画者 / ユーザーのための設計、内部設計は機能の実装方法を具体化する開発者のための設計です。

また、外部設計のアウトプットとして作成される外部設計書は、内部設計するために必須のインプットだという関係性です。外部設計書に不備があれば、当然、内部設計のステップにも大きな影響を与えます。

外部設計が重要なのはなぜか

それでは、外部設計がウォーターフォール型システム開発プロジェクトの成否を分けるほど重要なのはなぜか？以下から、その理由をいくつか簡単に紹介していきます。

企画者 / 開発者の認識のズレを修正

外部設計は、システム要件 / 機能要件 / 非機能要件といった、要件定義フェーズで定めた各種要件を具体的な設計書に落とし込むフェーズです。この過程で企画者 / 開発者の間に認識のズレが発生していないか？確認してズレがあれば修正するフェーズとなるのが外部設計です。

なぜなら、企画者 / 開発者双方とも要件に合意したにもかかわらず、企画者の意図と異なる設計図ができあがった、というのはよくあることだからです。つまり、具体的な設計図という形で完成形をイメージできる外部設計は、認識のズレを修正するのに適したフェーズ。特に、開発を外部へアウトソーシングする場合は重要なポイントです。

システム開発工程の手戻りリスクを低減

企画者 / 開発者間で綿密にコミュニケーションしながら外部設計フェーズを進めることによって、システム開発工程の手戻りリスクを低減できます。

なぜなら、ウォーターフォール型システム開発の場合、より下流の工程になってからの修正 / 手戻りはスケジュール遅延 / 予算超過に直結するから。外部設計フェーズまでに認識のズレを修正しておけば、リスク / 被害を最小化できます。たとえば、要件定義で認識のズレを解消する、それでも生じてしまったズレを外部設計で修正するイメージです。