エンジニア全般
外部設計と内部設計の違いが一目で分かる比較表や、それぞれのメリット・デメリット、実際の作業内容について詳しく解説しています。
外部設計書の作成時も、業務フローやシステム構成図の作成、機能一覧表の作成等のポイントを押さえることで、分かりやすく作成することができます。
システム開発で外部設計と内部設計の違いが分からないという方は、ぜひ参考にしてみてください。
国立の情報系大学院で情報工学、主にUI/UXを学んだあと、NTT子会社に勤務。 退社後はフリーランスとして、中小規模事業者様のIT化、業務自動化を支援しています。 DX推進の提案やPythonなどを用いた専用RPAツール開発のほか、市営動物園の周年企画などにもITエンジニアとして参画させていただきました。
外部設計・内部設計とは？
システム設計には、外部設計と内部設計の2つの段階があります。それぞれの設計における具体的な違いは以下のようになります。
外部設計では、システムの概要設計を行います。一方、内部設計はその詳細設計に相当します。
外部設計とは
外部設計は、システムの外側の設計を行うことです。システムが提供する機能や、ユーザーが利用する操作画面、他システムとのデータの受け渡しといった外部インターフェースの設計を中心に行います。
具体的に外部設計で定義する内容は以下のようなものがあります。
- システムが提供する機能とその概要
- ユーザーインターフェースの画面の内容と遷移
- 画面上の操作方法や入力/出力情報
- 他システムとの接続点やデータの受け渡し方法
- 画面イメージやワイヤーフレームによる画面定義
- 機能一覧表による機能定義
外部設計では、システムの内部処理は定義せず、外部から見える動作に着目します。ユーザーが利用できる機能や画面を設計するフェーズです。ユーザーから見て、システムがどのような機能を提供し、どのように利用できるかを表現します。
内部的なデータ構造や処理手順の詳細は、後続の内部設計で定義します。外部設計はシステムの方向性を決定し、内部設計でそれを詳細化していきます。
内部設計とは
内部設計は、システムの内部の仕様を定義する工程です。
外部設計で決定したシステムの機能やインターフェースを、どのように実装するかを具体的に設計します。
具体的に内部設計で定義する内容は以下のようなものがあります。
- 内部で利用するデータ項目と構造の定義
- データベースのテーブル定義やスキーマ設計
- プログラム内部の処理手順の詳細設計
- プログラム間の内部インターフェースの定義
- データの流れや内部データ形式の定義
- ハードウェア、OS、ミドルウェアとのインターフェース
- 非機能要件への対応（性能、信頼性等）
内部設計はコードに近い記述で、システム内部の詳細な動作を定義します。外部設計で示した機能を、どのモジュールがどのような手順で実現するかを具体化します。
外部設計がシステムの概要を定義するのに対し、内部設計はその詳細な実装方法を定義します。外部からは見えない部分の設計が主な内容となります。
外部設計と内部設計の違い
外部設計がシステムの外側から見た概要を表現するのに対し、内部設計はその中身の詳細設計を担当します。
設計工程は外部設計→内部設計の順に進めます。まず外部設計でシステムの目的や機能、インターフェースを明確化します。次に内部設計で、それを実現するためのデータ構造や処理手順を詳細に定義します。
| 項目 | 外部設計 | 内部設計 |
| 対象 | システムの外部仕様 | システムの内部仕様 |
| 着眼点 | システムの機能と動作 | システムの内部処理 |
| 記述内容 | 処理の流れ、インタフェース | データ構造、処理手順 |
| 表現方法 | 概念的表現 | 詳細な表現 |
| 目的 | システムが利用者にどのように見えどのように動くべきかを定義 | 効率的に動作し、安定したシステムを構築 |
| 内容 | ユーザーが使いやすいシステムを設計し、機能や操作性を具体化 | 外部設計で定義された全体像を実現するための具体的な構造、処理、動作を具体化 |
また、外部設計と内部設計を分けて行うメリットとしては以下の通りです。
- 要件定義と実装設計を分離できる
- システムの詳細な実装方法に依存しない設計ができる
- システムの機能面と構造面を区別して設計できる
- 機能変更の影響範囲を限定できる
外部設計によって作成される外部設計書は、内部設計を行う際の土台となります。
外部設計と内部設計は互いに補完し合いながら、システム全体の品質と性能を高めてくれます。両者の役割を明確に理解し、適切に補い合うことで、顧客の要望に応える信頼性の高いシステムを構築することができます。
外部設計と内部設計で行うそれぞれの作業
外部設計では、システムの外側から見える部分に関する設計を行い、内部設計では、システムの内側のデータ処理部分に関する設計を行います。
それぞれどのような作業があるのか、いくつかの例を紹介します。
外部設計で行う作業
まずは外部設計から紹介します。
画面設計
画面設計では、ユーザーが利用するすべての画面について、レイアウトと表示内容を詳細に定義します。
画面で表示する項目やレイアウトを具体的な画面イメージとして図示するほか、画面間の遷移についてもすべて洗い出し、画面遷移図を作成します。
※例えば、ECサイトの構築ならば、トップページ、商品検索ページ、商品詳細ページ、カートページ、購入完了ページなどがどのようなページ画面になるか、各ページはどのようにリンクで繋がっているかを図示します。
画面設計はユーザーインターフェース設計の根幹であり、ユーザーが目的の情報にたどり着けるよう、利用者目線で使いやすい画面設計を行います。
機能設計
機能設計では、システムの提供すべき機能を一覧化し、それぞれの概要をまとめた定義書を作成します。
例えばECサイトならば、会員登録、商品検索、カート機能、決済機能などを洗い出し、機能名、処理概要、入力と出力を記述した機能定義書を作成します。
また、関連事項や依存関係を機能一覧図や要求一覧図としてまとめ、システム機能の全体像を確認できるようにします。
方式設計
外部設計では、外部システムやデバイスとの接続方法などの、データのやり取りを定義する方式設計も重要になります。
例えば、ECサイトの決済機能では、クレジットカード決済会社のAPIやコンビニ支払い方法を図示する必要があります。また、配送状況の確認機能が必要ならば、どの配送業者のどのAPIを利用するかをビジネスプロセス関連図などを使って図にまとめます。
外部のプロセスやシステムとの接続方式は、使いやすさやコストを考慮して慎重に選ぶ必要があります。
各システムとの関連図を作成することで、ニーズと予算に合わせた方式を選べているか確認し、開発段階でのトラブルを回避することができます。
内部設計で行う作業
続いて、内部設計で行う具体的な作業を解説します。
機能分割
外部設計で必要と決まった要件や機能を更に分割し、内部設計を行う各機能ごとの区分けを行います。
この際に、各機能の説明を記載してより具体的な機能の定義や要件を明確にしておきます。
区分けする指標は開発側の事情によって様々ですが、機能が持つ責任を明確にし、システムの運用や拡張性、障害時の原因の切り分けなどを見据えて機能分割を行いましょう。
データベース設計
外部設計を実現するためのデータベースの構造を設計します。
ER図（エンティティリレーション図）を使ってデータモデルを明確にし、商品情報テーブルなどデータを参照するための最適なテーブル構造を設計し、物理設計、論理設計、インデックス設計にまとめます。
データフローの設計
各機能の処理を、様々なデータフロー図に起こします。
例えば、以下のようなフロー図を作成します。
- クラス図
- システムを構成するクラスの定義とその関係を視覚化した図
- モジュール構成図
- 各機能に必要なモジュール同士のインターフェースや依存関係を視覚化した図
- アクティビティ図
- システムやビジネスプロセスのワークフローを示すダイアグラム図
- シーケンス図
- オブジェクト間のメッセージのやり取りを示すダイアグラム図
外部設計と内部設計を分けて作成するメリット
外部設計と内部設計を明確に分けて設計工程を進めることで、いくつかのメリットがあります。
外部設計では、ユーザーの使いやすいインターフェースや機能を考えます。内部設計では、それを実現するためのデータ構造や処理手順を考えます。要求定義と実装設計を分離することで、ユーザー視点での設計と、システム視点での設計が明確になります。以下、詳しく解説していきます。
ユーザーの要望に近い設計ができる
外部設計では、ユーザーが直面する画面・操作性・機能に集中できるため、ユーザー要望に沿ったシステム設計が可能です。
例えばECサイトの商品検索では、キーワード検索や絞り込み、人気商品表示など使いやすい機能を盛り込めます。
一方の内部設計は、データ構造やアルゴリズムの観点に偏りがちで、ユーザー要望から外れがちです。外部設計に注力することで、ユーザーに求められるシステムを構築できるのです。
開発の効率が向上する
外部・内部の両面から開発全体を設計できるため、各フェーズの目的や規模感が明確になり、効率的な開発が可能です。
これは、開発時間の短縮とコスト削減に繋がります。また設計段階でリスクを具体化できるため、問題の早期発見・修正にも役立ち、後戻りや大規模修正を防げます。
品質の高いシステムを実現できる
設計を通じてシステム全体像を理解できるため、信頼性と顧客満足度の高いシステムの構築が可能です。
各部分の連携が明確化され、バグを起こしにくい安定したシステムが実装できます。
また顧客要求への適合度も設計段階で明確になり、満足度向上に繋がります。さらに保守・改修の容易さも高まり、長期運用に耐えられるようになります。
機能拡張が簡単にできる
外部・内部設計の分離で、機能変更時の影響範囲を内部に限定できます。
例えばECサイトに会員機能を追加する場合、外部設計は会員ページ・データ定義、内部設計は会員テーブル実装や認証ロジックとなります。外部インターフェースに変更がなければ、内部変更のみで機能拡張可能です。
内部実装技術の変更も外部に影響しにくくなり、保守性が向上します。変化するユーザーニーズに対応しやすく、機能拡張コストが低減できるのです。
外部設計書と内部設計書の作成のコツ
外部設計書と内部設計書には書き方のコツがあります。ここでは、作成のポイントを紹介します。
外部設計書の書き方のコツ
まずは外部設計の書き方のコツから紹介します。
機能一覧表は網羅的にリストアップすること
顧客の要望を取り入れた機能一覧を表にする際は、システムが提供する機能を網羅的にリストアップし、機能間の関係性についてもまとめましょう。
機能一覧表は、システムの機能要件を明確化するための重要な資料となります。
後の内部設計や実装の際に何度も確認することになるため、機能一覧表の作成時には要件定義に基づきシステムが提供すべき機能を漏れなく含んでいることが重要です。
非機能要件も忘れずにまとめる
非機能要件とは、システムが満たすべき性能、信頼性、セキュリティなど、機能以外の指標を指します。
外部設計書を作成する際には、どうしても顧客からの要望をまとめた機能要件定義を優先してしまいます。
ですが、非機能要件を開発工程の初期段階で明確にしておかないと、品質やコストの面でいずれ大きなトラブルを引き起こします。
性能、安定性、セキュリティといった観点を網羅的に洗い出し、数値目標を含めた具体的な定義を記載することが重要です。
内部設計書の書き方のコツ
続いて、内部設計書の書き方を紹介します。
フロー図はシンプルかつ明確に
各処理のフロー図を作成する際は、処理手順と条件分岐を簡潔に表現することが重要です。
各フェーズの入力と出力を明確化することで、処理の流れがわかりやすくなります。
また全体像がわかりにくくなるため、過度に分岐条件を増やすのは避けましょう。
業務フロー図の目的は、プロセスの手順と流れを理解しやすく可視化することです。
複雑な表現は避け、必要最小限のステップと条件分岐で構成することがポイントになります。
開発者に誤解されないような記述を心がける
内部設計書は実際にプログラミングを行う開発者向けに作成します。
開発者は外部設計書についてあまり良く知らないことも多く、内部設計書の内容を基にシステムを実装します。
そのため、開発者と設計書執筆者の間に認識のすれ違いが発生すると、思わぬトラブルを招きます。
可能な限り説明は簡潔かつ明瞭に、そして読みやすい文章を心がけましょう。
また開発者向け資料であるため、なるべく曖昧な表現や迂遠な表現は避け、専門用語を織り交ぜて端的に記載することも重要です。
共通のコツ
どちらの設計書にも共通の書き方ポイントもあります。
ドキュメントは量よりも質
設計書の作成において重要なのは、ドキュメントの量ではなく、記載内容の質です。
特にページ数を増やすために内容を不必要に詳細化すると、読みづらい資料になってしまいます。
必要な情報が正確に、簡潔に記述されているかが大切です。余分な説明や詳細は省き、要点のみを過不足なく記載することを心がけましょう。
例えば、「この情報は本当に必要か」を判断基準に、要点のみを絞り込んで記載するとよいでしょう。
図表や数式で見やすく仕上げる
顧客に見られる外部設計書はもちろん、開発チーム内で使う内部設計資料においても、図表を活用することで内容が理解しやすくなります。
例えば、システム構成図を図式化することで各要素との関係が一目で分かるようになりますし、積極的にフローチャート図で処理の流れを表現することで実装内容がより明確になります。
視覚的表現を最大限活用することで、設計書の分かりやすさと説得力が高まります。
段落だけの説明文書よりも、図と文の説明を組み合わせた資料の方が、理解度も高まります。
工程やスケジュール管理はしっかり行う
設計書作成において、作業の工程とスケジュールを明確にし、効率的に作業を管理することは非常に重要です。
設計書作成の各工程において、記載内容と担当者をあらかじめ明確に決定しておきましょう。
※例えば、機能設計担当者が最初に機能一覧を作成し、次に画面設計担当者が画面定義を行う、といった具合です。
設計書の品質と工数は、作業計画の妥当性に強く依存します。
工程とスケジュール管理を徹底することが、設計書作成の成功や失敗を左右する最も重要なポイントと言えるでしょう。
外部設計書と内部設計書のサンプル
外部設計書は発注者が確認することを前提としており、お互いにとってわかりやすい形式の設計書を作成します。
また、内部設計書はエンジニア同士が理解しやすいように、内部用の社内規則に沿って設計書を作成します。
とはいえ、相応の専門知識や設計経験、開発ノウハウがなければ、設計書やその形式を理解、作成するのは簡単ではありません。
どのような設計書を用いればいいのかとお悩みの方向けに、いくつかの設計書のサンプルを紹介したいと思います。
※設計書のサンプルはIPAが公表しているデータを引用しています。より深く設計書の書き方を知りたい方は引用元の資料も合わせて御覧ください。
外部設計書のサンプル
要求一覧図
要求一覧図では、顧客からの要求について、要求内容、経営目的、現状、目標値と達成度、関連部門などを一覧して表に起こします。
顧客が求めているものを設計段階で取りこぼさないように、実装手段だけでなく、その要求の業務目的や達成指標なども整理するとよいでしょう。
資料出典：IPA「システム構築の上流工程強化（非機能要求グレード）」
非機能要件定義表
非機能要件では、可用性、性能・拡張性、運用・保守、セキュリティ対策など機能以外の要望について、必要な要件を詳らかにします。
下記はIPAが公表した2018年の非機能要件グレードの表例です。
資料出典：IPA「システム構築の上流工程強化（非機能要求グレード）」
ビジネスプロセス関連図
ビジネスプロセス関連図は、対象とする業務の全体概要を把握できる図です。
販売や生産管理などシステムに関わる様々な外部プロセスが、開発するシステムへどのように影響するのかを理解するのに役立ちます。
ステークホルダー関連図
ステークホルダー関連図は、プロジェクトに関わるステークホルダーのつながりを図示します。
関連性を明確にしておくことで、課題や要求の抽出先、レビューや合意先などが明確になり、開発に移る前にプロジェクトにおけるキーパーソンを整理することができます。
状態遷移図
状態遷移図は、システムの各処理における画面の流れを図示します。
ユーザーがどのようにシステムを利用するかが把握できるため、顧客の要望に対するシステムの妥当性や実現性を確認するのに役立ちます。
内部設計書のサンプル
クラス図
クラス図はシステムの構成要素と、要素間の関係を視覚化した図です。
システムの機能を分割することで開発の単位を明確にし、再利用性や保守性を高めるのに役立ちます。
以下はIPAの「組込みソフトウェア開発における品質向上の勧め」から抜粋したクラス図の一例です。
資料出典：IPA「組込みソフトウェア開発における品質向上の勧め」
アクティビティ図
アクティビティ図は処理の活動（アクティビティ）の流れを視覚化した図です。
システムの処理手順を視覚的に確認するのに役立ちます。
以下はIPAの「組込みソフトウェア開発における品質向上の勧め」から抜粋したアクティビティ図の一例です。
資料出典：IPA「組込みソフトウェア開発における品質向上の勧め」
シーケンス図
シーケンス図はシステムの振る舞いを視覚的に整理して表現できる図です。
システムの処理フローを視覚的に理解し、特定のシナリオやユースケースの動作を確認するのに役立ちます。
以下はIPAの「組込みソフトウェア開発における品質向上の勧め」から抜粋したシーケンス図の一例です。
資料出典：IPA「組込みソフトウェア開発における品質向上の勧め」
まとめ：外部設計と内部設計はシステム開発に大切
外部設計では画面や機能を、内部設計ではデータ構造や処理手順を定義します。
外部設計書を作成する際は、要点を絞り込んで簡潔に記載し、図表を活用して視覚的に表現することが重要です。
内部設計書を作成する際は、データ構造や処理フローを簡潔にまとめ、開発者に伝わりやすい資料になるように心がけましょう。
設計段階で外部と内部を明確に分けて設計することで、ユーザー目線での設計と、システム目線での設計が明確に区別され品質の高いシステムを実現できます。
株式会社Jiteraでは、要件定義から設計、開発、保守までトータルに支援しています。
Jiteraの誇るAIが要件定義をサポートし、より柔軟で素早いシステム開発を実現します。
システム開発に悩む企業様、ぜひ一度Jiteraへご相談ください。
