外部設計と内部設計の違いとは？システム開発を成功に導く設計工程を徹底解説
システム開発のプロジェクトに関わる際、「外部設計」と「内部設計」という言葉を頻繁に耳にするものの、その違いを正確に理解している方は意外と少ないかもしれません。
この2つの設計工程は、システム開発において車の両輪のような関係にあり、どちらが欠けてもプロジェクトの成功は望めません。
本記事では、外部設計と内部設計の本質的な違いと、それぞれが果たす役割について詳しく解説します。単なる定義の説明にとどまらず、なぜこの2つの工程が分かれているのか、どのような視点で設計を進めるべきなのかといった、実務で活きる知識をお届けします。
システム設計における2つの設計工程の位置づけ
システム開発では、要件定義の後に設計フェーズが始まります。ここで理解しておくべきなのは、設計工程が「外部設計」と「内部設計」の2段階に分かれている理由です。
多くの解説記事では「外部設計はユーザー視点、内部設計はエンジニア視点」という説明で終わってしまいますが、この分離にはもっと深い意図があります。それは、異なる関心事を分離することで、それぞれの工程で適切な意思決定ができるようにするためです。
外部設計では「何を作るか」に焦点を当て、内部設計では「どう作るか」に集中します。このように関心事を分離することで、クライアントとのコミュニケーションと技術的な実装の両方を、それぞれ最適な形で進められるのです。
要件定義から設計への橋渡し
要件定義で決まった「システムで実現すべきこと」を、実際に開発できる形に落とし込むのが設計工程です。ただし、要件定義の内容をいきなりプログラムコードに変換することは現実的ではありません。
そこで、まず外部設計で「システムの振る舞い」を明確にし、続く内部設計で「システムの内部構造」を詰めていきます。段階的に詳細度を上げていくことで、プロジェクトの各段階で適切なレビューが可能になり、手戻りのリスクを最小化できます。
外部設計とは？クライアントとの合意形成を実現する工程
外部設計は、ユーザーから見えるシステムの姿を定義する工程です。画面のレイアウト、操作の流れ、システム間の連携といった、ユーザーが直接体験する部分を設計します。
外部設計で定義する主な内容
外部設計では、以下のような要素を具体化していきます。
画面設計では、各画面のレイアウトや項目、ボタンの配置などを決定します。単に見た目を決めるだけでなく、ユーザーの業務フローに沿った操作性を実現することが重要です。たとえば、データ入力画面であれば、入力順序が実際の業務手順と一致しているか、頻繁に使う機能がすぐにアクセスできる位置にあるかなどを検討します。
機能設計は、システムが提供する各機能の仕様を定義します。ある機能のボタンを押したときに何が起こるのか、どのような条件でエラーメッセージが表示されるのかといった、システムの振る舞いを明確にします。
ここで注意したいのは、外部設計の段階では「どのプログラミング言語を使うか」「どのデータベースに保存するか」といった技術的な詳細には触れないということです。あくまでユーザー視点での機能要件に集中するのが外部設計の役割なのです。
システム方式設計では、サーバーとクライアントの役割分担や、他システムとの連携方式を決めます。たとえば、既存の販売管理システムとどのようなタイミングでデータをやり取りするのか、リアルタイム連携なのかバッチ処理なのかといった方式を定義します。
外部設計書に含まれる成果物
外部設計の成果物として、一般的に以下のドキュメントが作成されます。
画面仕様書には、各画面のワイヤーフレームや項目定義、画面遷移図が含まれます。クライアントがこれを見れば、完成するシステムの姿を具体的にイメージできる内容となります。
機能仕様書では、各機能の処理フローや入力値の妥当性チェックのルール、エラー処理の仕様などを記載します。この段階で、クライアントと「どのような場合にエラーとするか」「どのようなメッセージを表示するか」といった細かい仕様を合意しておくことが、後の手戻りを防ぐ鍵となります。
外部インターフェース仕様書は、他システムとのデータ連携の仕様を定義します。データフォーマット、通信プロトコル、エラー時の再送ルールなど、システム間連携に必要な約束事を文書化します。
なぜ外部設計が重要なのか
外部設計が果たす最も重要な役割は、クライアントとの認識の齟齬を防ぐことです。要件定義書だけでは、システムの具体的な動作まではイメージしにくいものです。
外部設計書という形で画面イメージや操作フローを可視化することで、クライアントは「自分たちが本当に欲しかったもの」を確認できます。この段階で認識のズレを修正しておけば、開発後半での大きな手戻りを避けられるのです。
実際のプロジェクトでは、外部設計のレビュー時にクライアントから「この画面遷移だと操作が煩雑になる」「この項目が足りない」といったフィードバックをもらうことがよくあります。これは外部設計が機能している証拠であり、このタイミングでの修正は開発工数への影響も比較的小さく済みます。
内部設計とは？技術的な実装を可能にする詳細設計
内部設計は、外部設計で定義した機能を実際にどう実現するかを決める工程です。プログラムの構造、データベースのテーブル設計、処理アルゴリズムなど、システムの内部構造を詳細に設計します。
内部設計で定義する主な内容
機能分割では、外部設計で定義された機能を、実際に開発する単位（モジュールやクラス）に分解します。たとえば、「商品検索」という機能を、検索条件の妥当性チェック、データベース検索、検索結果の整形といった複数のコンポーネントに分割し、それぞれの責務を明確にします。
適切な機能分割により、複数のエンジニアが並行して開発を進められるようになり、また各モジュールの単体テストも容易になります。ここでの判断が、後の開発効率やメンテナンス性に大きく影響するのです。
物理データ設計は、データベースの具体的な構造を決める工程です。どのテーブルにどのカラムを持たせるか、主キーや外部キーをどう設定するか、インデックスをどこに作成するかなどを決定します。
ここでは、データの整合性を保ちながら、パフォーマンスも考慮した設計が求められます。たとえば、正規化を徹底すればデータの重複は減りますが、検索時に多くのテーブルを結合する必要が生じ、性能が低下する可能性があります。理論と実践のバランスを取ることが、ベテランエンジニアの腕の見せどころです。
入出力の詳細設計では、各処理の入力パラメータと出力結果の詳細仕様を定義します。関数やメソッドのシグネチャ、データ型、値の範囲、エラーハンドリングの方法などを決めます。
この段階で詳細を詰めておくことで、実装フェーズではエンジニアが迷わずコーディングできるようになります。逆に、内部設計が曖昧だと、実装中に何度も設計判断が必要になり、進捗が遅れる原因となります。
内部設計書に含まれる成果物
内部設計の成果物には、以下のようなドキュメントが含まれます。
クラス図やモジュール構成図は、システムの構造を視覚的に表現します。オブジェクト指向開発ではクラス図が、手続き型開発ではモジュール構成図が用いられることが多いでしょう。これらの図により、各コンポーネント間の依存関係が明確になります。
詳細処理フロー図では、各処理のアルゴリズムを詳細に記述します。複雑な計算ロジックや条件分岐が多い処理については、フローチャートや疑似コードで処理手順を明確にします。
データベース設計書には、テーブル定義やER図が含まれます。各テーブルのカラム名、データ型、NULL許可の可否、デフォルト値、制約条件などを詳細に定義します。
プログラマーへの設計図としての役割
内部設計書は、プログラマーにとっての設計図となります。優れた内部設計書があれば、経験の浅いエンジニアでも、意図通りの実装ができるようになります。
逆に内部設計が不十分だと、実装者が勝手に判断してコーディングすることになり、結果として統一性のないコードベースが生まれてしまいます。保守性や拡張性が低いシステムになってしまう原因の多くは、実は内部設計の甘さにあるのです。
外部設計と内部設計の本質的な違い
ここまで見てきたように、外部設計と内部設計は単に工程が違うだけでなく、視点と目的が根本的に異なります。その違いを改めて整理しましょう。
視点の違い：ユーザー視点 vs エンジニア視点
外部設計はユーザー視点で「何を実現するか」を定義します。システムを使う人が、どのような操作でどのような結果を得られるのかという、ユーザー体験に焦点を当てます。
一方、内部設計はエンジニア視点で「どう実現するか」を定義します。どのような技術やアーキテクチャを使って、外部設計で定めた機能を実装するのかという、技術的な実現方法に焦点を当てます。
この視点の違いが、設計書を読む人の違いにもつながります。外部設計書はクライアントにも理解できる内容である必要がありますが、内部設計書は技術者向けのドキュメントとなります。
変更の影響範囲の違い
外部設計の変更は、ユーザー体験に直結する変更です。画面の項目が増えたり、操作フローが変わったりすれば、ユーザーはその変化を直接感じます。そのため、外部設計の変更にはクライアントの承認が必要となります。
内部設計の変更は、システムの内部構造の変更です。使用するライブラリを変えたり、データベースのテーブル構造を調整したりしても、ユーザーから見た動作が変わらなければ、クライアントへの説明は不要なケースが多いでしょう。
ただし、内部設計の変更が性能や保守性に影響を与える場合は注意が必要です。たとえば、データベース設計の変更により処理速度が大幅に低下する場合などは、たとえ内部の変更でもクライアントへの説明が求められます。
作成タイミングと並行性
外部設計と内部設計は、基本的には順番に行われます。外部設計で「何を作るか」が確定してから、内部設計で「どう作るか」を考えるという流れです。
ただし、大規模プロジェクトでは、一部の機能について外部設計が終わった段階で、その部分の内部設計を始めることもあります。また、内部設計を進める中で技術的な制約が見つかり、外部設計に戻って仕様を調整するというフィードバックループも発生します。
重要なのは、外部設計で決めるべきことと内部設計で決めるべきことを明確に区別し、適切な順序で意思決定を進めることです。
レビュー参加者の違い
外部設計のレビューには、クライアント側の担当者、プロジェクトマネージャー、システムエンジニアなど、幅広いステークホルダーが参加します。技術的な詳細よりも、ビジネス要件が正しく反映されているか、ユーザビリティは十分かといった観点でレビューが行われます。
内部設計のレビューは、主に技術メンバーで行われます。アーキテクト、リードエンジニア、実装を担当するプログラマーなどが参加し、技術的な妥当性、実装の容易さ、保守性といった観点で評価します。
この参加者の違いを理解していないと、外部設計書に技術用語を多用してクライアントを混乱させたり、内部設計のレビューをクライアントに求めて時間を浪費したりといった問題が起きます。
外部設計の作業を成功させるポイント
外部設計を効果的に進めるためには、いくつかの重要なポイントがあります。
クライアントの業務理解を深める
優れた外部設計を作るには、単に要件定義書を読むだけでは不十分です。クライアントの業務を現場レベルで理解する必要があります。
たとえば、受注管理システムを開発する場合、実際の受注処理の流れを観察し、どのタイミングでどのような情報が必要になるのかを肌で感じることが重要です。現場の担当者が何に時間を使っているのか、どこでミスが起きやすいのかといった情報は、使いやすいシステムを設計する上で貴重な材料となります。
プロトタイプやモックアップの活用
画面設計を紙の仕様書だけで伝えるのは限界があります。実際に操作できるプロトタイプや、視覚的なモックアップを作成すると、クライアントの理解が格段に深まります。
最近では、FigmaやAdobe XDといったツールを使えば、比較的短時間でインタラクティブなプロトタイプを作成できます。クライアントに実際に操作してもらうことで、仕様書だけでは気づかなかった問題点が浮かび上がることも少なくありません。
非機能要件も明確にする
外部設計というと機能面ばかりに目が行きがちですが、非機能要件も重要です。性能要件（レスポンスタイムの目標値）、可用性要件（システムの稼働時間）、セキュリティ要件（アクセス権限の考え方）なども、外部設計の段階で明確にしておく必要があります。
たとえば、「検索結果は3秒以内に表示される」という性能要件を外部設計で定義しておけば、内部設計や実装の段階で、その目標を達成するための技術選択ができます。
内部設計の作業を成功させるポイント
内部設計を効果的に進めるためのポイントも押さえておきましょう。
保守性と拡張性を重視する
内部設計では、当面の実装だけでなく、将来の変更や機能追加を見据えた設計が求められます。システムは一度作って終わりではなく、運用開始後も機能追加や仕様変更が繰り返されます。
そのため、変更に強い設計を心がける必要があります。たとえば、ビジネスロジックとデータアクセス層を明確に分離しておけば、データベースの種類を変更する際にも影響範囲を最小限に抑えられます。
デザインパターンの知識も、ここで活きてきます。状況に応じて適切なパターンを適用することで、柔軟性の高い設計を実現できます。
パフォーマンスを考慮した設計
特にデータベース設計では、パフォーマンスを意識することが重要です。大量のデータを扱うシステムでは、テーブル設計やインデックスの設定が、システムの性能を大きく左右します。
ただし、過度な最適化は禁物です。将来ボトルネックになりそうな箇所を見極め、そこに焦点を当てた最適化を行うのが賢明です。すべての処理を最初から最適化しようとすると、設計が複雑になりすぎて保守性が低下します。
技術的負債を生まない判断
プロジェクトには必ず納期があり、時には妥協も必要です。しかし、内部設計での安易な妥協は、後々の技術的負債となって返ってきます。
「今回は時間がないから、とりあえずこの方法で実装しよう」という判断が、後のメンテナンスコストを大幅に増加させることは珍しくありません。短期的な納期と長期的な保守性のバランスを取ることが、内部設計における重要な判断力です。
実装者とのコミュニケーション
内部設計書は最終的にプログラマーが読むものです。設計者が想定した通りに実装してもらうには、明確で曖昧さのない記述が必要です。
また、内部設計の段階で実装者の意見を聞くことも重要です。実装の現場で作業する人の視点から見ると、設計書だけでは分からない問題点が見えてくることがあります。設計者と実装者の間で密なコミュニケーションを取ることが、スムーズなプロジェクト進行につながります。
システム開発全体における設計工程の位置づけ
ここまで外部設計と内部設計について詳しく見てきましたが、最後に、これらの工程がシステム開発全体の中でどのような役割を果たしているのかを確認しておきましょう。
要件定義から実装への橋渡し
設計工程は、抽象的な要件を具体的な実装へと橋渡しする翻訳の工程と言えます。要件定義ではビジネスの言葉で記述されていた内容を、外部設計でシステムの仕様に、内部設計で技術的な設計に、段階的に具体化していきます。
この段階的な詳細化により、各工程で適切なレベルでのレビューが可能になり、問題の早期発見につながります。
品質を左右する重要工程
システムの品質は、実装だけでなく設計の質に大きく依存します。優れた設計があれば、実装者のスキルレベルに関わらず、一定の品質を保つことができます。
逆に、設計が不十分だと、たとえ優秀なプログラマーが実装しても、統一性のないシステムになってしまいます。設計工程にしっかり時間をかけることが、結果的にプロジェクト全体の効率化につながるのです。
基本設計・詳細設計という呼び方について
ここまで「外部設計」「内部設計」という言葉を使ってきましたが、プロジェクトによっては「基本設計」「詳細設計」という呼び方をすることもあります。
一般的に、基本設計は外部設計とほぼ同義で、詳細設計は内部設計とほぼ同義です。ただし、プロジェクトや組織によって定義が微妙に異なることもあるため、プロジェクト開始時に用語の定義を確認しておくことが重要です。
まとめ
外部設計と内部設計は、それぞれ異なる視点と目的を持つ重要な工程です。外部設計ではユーザー視点で「何を実現するか」を定義し、内部設計ではエンジニア視点で「どう実現するか」を詳細化します。
この2つの設計工程を適切に進めることで、クライアントの要求を満たしつつ、技術的にも優れたシステムを構築できます。それぞれの工程の特性を理解し、適切な成果物を作成することが、システム開発プロジェクトを成功に導く鍵となります。
設計工程は地味に感じられるかもしれませんが、ここでの判断と作業が、システムの運命を大きく左右します。丁寧な設計作業への投資は、必ず後の工程で回収できるはずです。システム開発に関わるすべての方が、外部設計と内部設計の重要性を認識し、適切な時間とリソースを割り当てることを願っています。
