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

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

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

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

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

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

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

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

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

外部設計とは

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

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

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

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

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

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

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

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

内部設計とは

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

企画者が携われる最後の上流工程

実際、外部設計フェーズは企画者 / 開発者が協力して認識のズレを修正できる最後のチャンスです。特に開発をアウトソーシングしている場合、内部設計以降で企画者がプロジェクトに携われる機会は、受入テスト以外ほとんどありません。

企画者が外部設計フェーズへ積極的に関与すべきなのはこのため。外部設計がシステム開発プロジェクトの重要なフェーズであるのもこのためです。

外部設計書を構成するドキュメントのサンプル

ただし、企画者（ユーザー）の確認を前提としてるとはいえ、外部設計の成果物 / アウトプットは「外部設計書」です。設計 / 開発の知識 / ノウハウに乏しければ、設計書を理解するのは簡単ではないでしょう。

そんな方の参考になるよう、以下から外部設計書に含まれる主なドキュメント（設計書）のサンプルを紹介しておきます。

システム設計のドキュメントサンプル

システム構成図の例

画像出典：富士通

画面設計のドキュメントサンプル

画面一覧の例

画像出典：IPA（独立行政法人 情報処理推進機構）

画面レイアウトの例

画像出典：IPA（独立行政法人 情報処理推進機構）

画面遷移図の例

画像出典：IPA（独立行政法人 情報処理推進機構）

帳票設計のドキュメントサンプル

帳票一覧の例

画像出典：IPA（独立行政法人 情報処理推進機構）

帳票レイアウトの例

画像出典：IPA（独立行政法人 情報処理推進機構）

バッチ設計のドキュメントサンプル

バッチ処理一覧の例

画像出典：IPA（独立行政法人 情報処理推進機構）

バッチ処理フロー図の例

画像出典：IPA（独立行政法人 情報処理推進機構）

テーブル・ファイル要件のドキュメントサンプル

テーブル関連図（ER図）の例

画像出典：IPA（独立行政法人 情報処理推進機構）

CRUD図の例

画像出典：IPA（独立行政法人 情報処理推進機構）

外部インターフェース設計のドキュメントサンプル

外部システム関連図の例

画像出典：IPA（独立行政法人 情報処理推進機構）

【まとめ】外部設計の重要性・全体像を紹介しました

外部設計は、システム開発プロジェクトの成否を分ける重要な開発工程。発注側としてどのように関与すればいいのか？知りたい企業担当者に向け、開発プロジェクトにおける重要性から内部設計との違い、成果物となる外部設計書のサンプルまで、外部設計の全体像を解説してきました。

特にシステム開発をアウトソーシングする場合、外部設計はどうしても開発側に任せてしまいがちなフェーズです。しかし、外部設計をおろそかにしていたのでは、理想のシステムにはなりません。外部設計でやるべきこと、企画者としてどうすべきかを念頭に、積極関与していく姿勢が重要です。

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

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