外部設計とは？内部設計との違いや作業内容・設計書作成を解説

システム開発における外部設計は、要件定義で明確にした要求を具体的なシステム仕様に落とし込む重要な工程です。外部設計では、ユーザーから見えるシステムの機能や操作方法を設計し、クライアントとの認識合わせを行います。本記事では、外部設計の基本概念から内部設計との違い、具体的な作業内容、設計書の作成方法まで詳しく解説します。

外部設計とは？システム開発における基本概念を解説

外部設計の定義と基本的な役割

外部設計とは、システム開発において、ユーザーから見えるシステムの機能や仕様を定義する工程です。要件定義で明確にされた業務要件をもとに、システムがどのような機能を提供するか、ユーザーインターフェースをどのように設計するかを決定します。

外部設計は、システム開発の上流工程に位置し、システムの外観や操作性を決定する重要な役割を担います。この工程では、システムの画面設計、帳票設計、外部システムとの連携方法などを具体的に設計していきます。

外部設計の成果物である外部設計書は、発注者とシステム開発者の間で合意を形成するための重要な文書となります。この設計書によって、システムの完成イメージを関係者全員で共有することができます。

システム開発全体における外部設計の位置づけ

システム開発の流れにおいて、外部設計は要件定義の次に実施される工程です。要件定義で整理された業務要件を、システムとして実現するための設計を行います。

外部設計の後には内部設計が続き、外部設計で決定された機能を技術的にどのように実現するかを詳細に設計していきます。このように、外部設計と内部設計は密接に連携しながら、システム全体の設計を完成させていきます。

また、外部設計では、後工程のプログラミングやテストで必要となる設計情報を整理し、システム開発全体の品質向上に貢献します。

外部設計が重要な理由

外部設計は、システム開発の成功を左右する重要な工程です。この工程で設計の品質が低いと、後工程でのシステム開発に大きな影響を与えてしまいます。

外部設計書の品質によって、クライアントとの認識合わせが円滑に進むかどうかが決まります。分かりやすい外部設計書を作成することで、システムの仕様について発注者と開発者の間で共通理解を形成できます。

さらに、外部設計で明確にされた機能や仕様は、内部設計や実装工程での作業効率に直接影響します。適切な外部設計を行うことで、システム開発全体のスケジュール管理や品質管理が効率的に行えるようになります。

システム設計の流れと外部設計の位置づけ

要件定義から外部設計への移行プロセス

要件定義では、システムで実現すべき業務要件や機能要件を整理します。要件定義書をもとに、外部設計では具体的なシステムの機能や画面を設計していきます。

要件定義と外部設計の移行プロセスでは、要件定義で整理された内容を詳細化し、システムとして実現可能な形に変換していきます。この際、要件定義の内容と外部設計の内容に矛盾が生じないよう注意が必要です。

移行プロセスでは、要件定義書の内容を精査し、不明確な点があれば発注者と協議を行います。外部設計を開始する前に、要件定義の内容について関係者間で合意を形成しておくことが重要です。

外部設計から内部設計への移行プロセス

外部設計の成果物である外部設計書は、内部設計の入力情報として活用されます。内部設計では、外部設計で決定された機能を技術的にどのように実現するかを詳細に設計していきます。

外部設計と内部設計の移行プロセスでは、外部設計書の内容を内部設計チームに正確に伝達することが重要です。外部設計での設計意図や制約事項を内部設計に反映させる必要があります。

また、内部設計の過程で技術的な制約により外部設計の変更が必要となった場合は、外部設計チームとの調整を行い、システム全体の整合性を保つことが求められます。

システム開発におけるV字モデルと外部設計

システム開発のV字モデルにおいて、外部設計は左側の設計工程に位置します。V字モデルでは、外部設計の対になる工程として結合テストがあり、外部設計書をもとにテスト設計を行います。

V字モデルの考え方では、外部設計で決定された機能や仕様が、結合テストで適切に検証されることが重要です。外部設計書の品質が高ければ、効果的なテスト設計が可能になります。

また、V字モデルでは各工程での成果物の品質管理が重要視されており、外部設計書についても適切なレビューや承認プロセスを経る必要があります。

外部設計と内部設計の違いを詳しく解説

外部設計の特徴と作業内容

外部設計の特徴は、システムのユーザーに見える部分を設計することです。画面設計、帳票設計、外部システムとの連携方法など、システムの外観や操作性に関する設計を行います。

外部設計では、以下のような作業を実施します。

• 画面設計とユーザーインターフェースの設計
• 帳票設計と出力仕様の決定
• 外部システムとの連携方法の設計
• データの入出力仕様の設計
• 業務フローの整理と機能配置の決定

外部設計は、クライアントにとって理解しやすい形で設計内容を表現する必要があります。そのため、技術的な詳細よりも、業務の流れや機能の使い方を重視した設計を行います。

内部設計の特徴と作業内容

内部設計の特徴は、システムの内部構造を技術的に設計することです。外部設計で決定された機能を、どのようなプログラム構造で実現するかを詳細に設計していきます。

内部設計では、以下のような作業を実施します。

• プログラム設計とモジュール分割
• データベース設計とテーブル構造の決定
• 処理フローの詳細設計
• 例外処理とエラーハンドリングの設計
• パフォーマンスとセキュリティの考慮

内部設計では、外部設計で決定された機能を技術的に実現するため、プログラミングの知識や技術的な専門性が求められます。

外部設計と内部設計の違いを表で比較

外部設計と内部設計の違いを理解することで、システム開発における各工程の役割を明確にできます。

外部設計と内部設計は、それぞれ異なる視点でシステムを設計する重要な工程です。外部設計はユーザーの視点から、内部設計は技術者の視点から、システムの品質向上に貢献します。

システム開発を成功させるためには、外部設計と内部設計の両方の品質を高め、それぞれの設計内容に整合性を保つことが重要です。

外部設計で行う具体的な作業内容

方式設計の詳細

外部設計における方式設計では、システム全体のアーキテクチャを決定します。外部設計では、システムの基本的な構成方針や技術的な実現方法を明確にし、要件定義書をもとに具体的なシステム構成を検討していきます。

方式設計の作業内容には以下が含まれます。

• システムアーキテクチャの設計
• 技術基盤の選定と方針決定
• セキュリティ方針の策定
• パフォーマンス要件の検討
• システム運用方針の設計

外部設計の方式設計では、クライアントの要件を満たすために、どのような技術やアーキテクチャを採用するかを決定します。この段階で技術的な実現性や将来的な拡張性を考慮した設計を行います。

機能設計の詳細

外部設計書において機能設計は、システムが提供する機能を詳細に定義する重要な作業です。要件定義で整理された機能要件をもとに、具体的な機能仕様を設計していきます。

機能設計では以下の作業を行います。

• 業務フローの詳細化
• 画面設計と画面遷移の定義
• 帳票設計の詳細化
• バッチ処理の設計
• エラーハンドリングの設計

外部設計における機能設計では、システムの機能をどのように実現するかを明確にし、内部設計での実装につなげられるよう詳細な仕様を策定します。この段階で機能の実装方法や処理の流れを具体的に設計します。

インターフェース設計の詳細

外部設計でのインターフェース設計は、システムが他のシステムやユーザーとどのように連携するかを設計する作業です。外部設計書には、システムの入出力の詳細設計を含める必要があります。

インターフェース設計の主な作業内容は以下の通りです。

• 外部システムとの連携方式の設計
• API設計とデータ交換形式の定義
• ファイル入出力の設計
• ユーザーインターフェースの設計
• 通信プロトコルの選定

外部設計と内部設計の違いを考慮し、外部設計では他システムとの連携部分を重点的に設計します。この設計書をもとに、システム開発において一貫性のある連携処理を実現できるよう詳細な仕様を策定します。

データ設計の詳細

外部設計におけるデータ設計では、システムで扱うデータの構造や管理方法を設計します。外部設計のデータ設計では、要件定義で整理されたデータ要件をもとに、データベース設計の基本方針やデータの流れを明確にしていきます。

データ設計の作業内容には以下が含まれます。

• 論理データモデルの設計
• データ辞書の作成
• データフローの設計
• データの一意性制約の定義
• データ保持期間の設計

外部設計でのデータ設計は、内部設計での物理データベース設計の基盤となります。外部設計と内部設計の違いを意識し、外部設計では概念的なデータ構造を中心に設計を行います。

外部設計書の作成方法と必要な成果物

外部設計書に含むべき内容

外部設計書には、システム開発の次のフェーズである内部設計で必要となる情報を全て含める必要があります。外部設計書の品質は、その後のシステム開発全体の品質に大きく影響します。

外部設計書に含むべき主な内容は以下の通りです。

• システム概要と設計方針
• 業務フロー図
• システム構成図
• 機能一覧表
• 非機能要件の詳細
• インターフェース仕様
• データ設計書
• セキュリティ設計

外部設計書は、発注者やクライアントが理解しやすい形で作成することが重要です。技術的な詳細は内部設計で扱うため、外部設計書では概念的で分かりやすい表現を心がけます。

業務フロー図の作成方法

外部設計における業務フロー図は、システムがどのように業務を支援するかを視覚的に表現する重要な成果物です。要件定義書をもとに、より詳細な業務フローを設計していきます。

業務フロー図の作成においては、以下の点を重視します。

• 業務の流れを時系列で整理
• システムと人の役割分担を明確化
• 判断分岐点の詳細化
• 例外処理の流れを含める
• 関係者間の情報共有プロセス

外部設計の業務フロー図は、クライアントとの認識合わせでも重要な資料となります。発注者が理解しやすい形で作成し、システムの動作を具体的にイメージできるよう工夫します。

システム構成図の作成方法

システム構成図は、外部設計書の中でも特に重要な成果物の一つです。外部設計では、システム全体の構成を明確にし、各コンポーネントの役割や連携方法を具体的に設計書に記載します。

システム構成図の作成では以下の要素を含めます。

• システムの主要コンポーネント
• データベースとアプリケーションの関係
• 外部システムとの接続点
• ネットワーク構成の概要
• セキュリティ境界の明示

外部設計のシステム構成図は、内部設計での詳細設計の基盤となるため、一貫性と実現可能性を十分に検討して作成します。

機能一覧表の作成方法

機能一覧表は、システムが提供する全ての機能を整理した重要な外部設計書の成果物です。要件定義の機能要件を詳細化し、機能ごとの仕様を明確にします。

機能一覧表には以下の項目を含めます。

• 機能ID と機能名
• 機能の概要と目的
• 入力情報と出力情報
• 処理条件と制約事項
• 関連する他機能との関係
• 優先度と重要度

外部設計における機能一覧表は、内部設計での実装設計の基礎となるため、漏れや矛盾がないよう十分に検討して作成します。

非機能要件の整理方法

外部設計では、システムの性能やセキュリティなどの非機能要件を詳細に整理し、設計書に明記します。要件定義で整理された非機能要件をもとに、より具体的な設計指針を策定します。

非機能要件の整理では以下の観点を考慮します。

• パフォーマンス要件の具体化
• 可用性とシステム稼働率
• セキュリティ要件の詳細化
• 拡張性と保守性の考慮
• 運用・監視要件の整理

外部設計書における非機能要件は、システム開発の品質を左右する重要な要素です。内部設計での実装に必要な詳細レベルまで整理し、設計書に明記します。

外部設計書作成時のポイントと注意点

要件定義との整合性を保つ方法

外部設計書の作成では、要件定義との整合性を保つことが最も重要です。外部設計は要件定義書をもとに作成するため、要件定義の内容と矛盾しない設計を行う必要があります。

要件定義との整合性を保つために以下の点を注意します。

• 要件定義書の内容を詳細にレビュー
• 機能要件の漏れや重複をチェック
• 非機能要件の実現可能性を検証
• 要件変更時の影響分析を実施
• 要件定義書との対応表を作成

外部設計と内部設計の違いを意識し、外部設計では要件定義で定められた要件を満たす設計を行います。設計書の品質を高めるため、要件定義との整合性を定期的に確認します。

クライアントにとって分かりやすい資料作成

外部設計書は、クライアントや発注者が理解しやすい形で作成することが重要です。技術的な詳細は内部設計で扱うため、外部設計書では概念的で分かりやすい表現を心がけます。

分かりやすい資料作成のポイントは以下の通りです。

• 専門用語の使用を最小限に抑制
• 図表を効果的に活用
• 業務の流れを明確に表現
• システムの動作を具体的に説明
• 想定される利用シーンを記載

外部設計書は、クライアントとの認識合わせでも重要な資料となります。発注者が理解しやすい形で作成し、システムの価値を明確に伝えられるよう工夫します。

実現可能なシステム設計の考慮点

外部設計では、技術的な実現可能性を十分に検討した設計を行う必要があります。理想的な設計だけでなく、実際の開発において実現可能な設計を策定することが重要です。

実現可能なシステム設計のための考慮点は以下の通りです。

• 技術的制約の事前確認
• 開発期間とコストの制約
• 既存システムとの互換性
• 運用・保守の容易さ
• 将来的な拡張性の確保

外部設計書の作成では、内部設計での実装が困難な設計を避け、現実的で実現可能な設計を心がけます。設計書の品質を高めるため、技術的な検証を十分に行います。

設計書の品質向上のためのレビュー方法

外部設計書の品質向上のためには、体系的なレビュープロセスが不可欠です。設計書の品質は、その後のシステム開発全体の品質に大きく影響するため、入念なレビューを実施します。

効果的なレビューのための方法は以下の通りです。

• 複数の視点からのレビュー実施
• チェックリストを活用した確認
• 要件定義との整合性確認
• 実現可能性の技術的検証
• 設計書の完成度評価

外部設計書のレビューでは、内部設計での実装に必要な情報が全て含まれているかを確認します。設計書の品質を継続的に改善し、システム開発の成功につなげます。

外部設計におけるクライアントとの認識合わせ

設計書を使った効果的な説明方法

外部設計書を使ったクライアントへの説明では、分かりやすさと正確性の両立が重要です。外部設計書は技術的な内容を含むため、クライアントの理解度に応じた説明方法を選択します。

効果的な説明方法のポイントは以下の通りです。

• 業務フローを中心とした説明
• 画面モックアップの活用
• システム構成図の分かりやすい解説
• 具体的な利用シーンの説明
• 質問に対する丁寧な回答

外部設計の説明では、クライアントがシステムの動作を具体的にイメージできるよう工夫します。発注者との認識合わせを確実に行い、後工程での認識齟齬を防ぎます。

クライアントからのフィードバックの活用

外部設計書に対するクライアントからのフィードバックは、設計書の品質向上と認識合わせに重要な役割を果たします。クライアントの意見を適切に反映し、より良い設計書を作成します。

フィードバックの活用においては以下の点を重視します。

• フィードバックの内容を詳細に記録
• 要件定義への影響度を分析
• 設計変更の妥当性を検討
• 変更による影響範囲の確認
• 変更内容の文書化と共有

外部設計におけるフィードバックの活用では、システム開発全体への影響を考慮し、適切な対応を行います。クライアントとの認識合わせを確実に行い、設計書の品質を向上させます。

設計変更時の対応プロセス

外部設計の段階で設計変更が発生した場合、体系的な対応プロセスが必要です。設計変更はシステム開発全体に影響を与えるため、適切な手順で対応します。

設計変更時の対応プロセスは以下の通りです。

• 変更要求の内容確認と記録
• 変更による影響範囲の分析
• 変更コストとスケジュールの算出
• クライアントとの変更内容協議
• 変更承認後の設計書更新

外部設計書の変更では、内部設計への影響も考慮し、システム開発の一貫性を保ちます。設計書の品質を維持しながら、適切な変更対応を行います。

発注者との合意形成のポイント

外部設計における発注者との合意形成は、システム開発の成功に不可欠です。外部設計書の内容について、発注者の理解と合意を得ることが重要です。

発注者との合意形成では以下のポイントを重視します。

• 設計書の内容を段階的に説明
• 発注者の懸念点を詳細に聞き取り
• 技術的な実現可能性を明確に説明
• コストとスケジュールの妥当性を提示
• 合意内容の文書化と確認

外部設計での合意形成では、発注者が安心してシステム開発を進められるよう、十分な情報提供と丁寧な説明を行います。クライアントとの信頼関係を構築し、プロジェクトの成功につなげます。

外部設計から内部設計への移行プロセス

外部設計の成果物を内部設計にどう活用するか

外部設計から内部設計への移行において、外部設計書の成果物を効果的に活用することが重要です。外部設計では、システムの外部仕様やユーザーインターフェース、データの流れなどを定義していますが、内部設計では外部設計で定義された機能を実際にどのように実装するかを詳細に設計していきます。

外部設計書に記載された機能仕様書や画面設計書、データ設計書などの成果物は、内部設計における設計書作成の基礎資料となります。内部設計チームは、これらの外部設計書をもとに、プログラムの内部構造やデータベースの詳細設計、処理アルゴリズムの設計を行います。

外部設計と内部設計の違いを理解し、外部設計の成果物を適切に内部設計に引き継ぐことで、システム開発全体の品質向上とスケジュール遵守が可能になります。

内部設計チームへの情報共有方法

外部設計から内部設計への移行では、設計書の内容を正確に伝える情報共有が不可欠です。外部設計チームと内部設計チームの間で、設計書の意図や要件定義との関連性、クライアントの要望などを詳細に共有する必要があります。

情報共有の方法としては、設計書の引き継ぎ会議の開催、設計書に関する質疑応答セッションの実施、外部設計の担当者による内部設計チームへの説明などがあります。また、外部設計書に記載されていない暗黙の知識や、設計時の判断根拠なども併せて共有することが重要です。

設計の一貫性を保つための工夫

外部設計と内部設計の間で設計の一貫性を保つためには、設計書の品質管理と継続的なレビューが必要です。外部設計で定義された仕様が内部設計で適切に実装されるよう、定期的な設計レビューを実施し、設計書の整合性を確認します。

また、外部設計書と内部設計書の間でトレーサビリティを確保し、どの外部設計の要素がどの内部設計に対応しているかを明確にすることも重要です。これにより、設計変更が発生した場合でも、影響範囲を正確に把握し、適切な対応を行うことができます。

外部設計と内部設計の責任範囲の明確化

外部設計と内部設計では、それぞれの責任範囲を明確に定義する必要があります。外部設計は主にシステムの外部仕様や機能要件の定義を担当し、内部設計はその実装方法や技術的詳細の設計を担当します。

責任範囲の明確化により、設計書の作成責任者や承認者、変更管理の担当者などが明確になり、プロジェクト管理の効率化が図れます。また、外部設計と内部設計の間で発生する可能性のある課題や問題についても、事前に対応策を検討しておくことが重要です。

外部設計でよくある課題と解決策

要件定義の不備による影響と対策

外部設計において最も頻繁に発生する課題の一つが、要件定義の不備による影響です。要件定義が不十分な場合、外部設計の作業が進まず、設計書の品質が低下する可能性があります。また、外部設計の段階で要件定義の不備が発覚した場合、プロジェクト全体のスケジュールに大きな影響を与える可能性があります。

対策としては、外部設計を開始する前に要件定義書の内容を詳細にレビューし、不明な点や曖昧な点を明確にすることが重要です。また、要件定義の担当者と外部設計の担当者が定期的にコミュニケーションを取り、要件定義と外部設計の整合性を確保する必要があります。

クライアントとの認識齟齬を防ぐ方法

外部設計では、クライアントとの認識齟齬が発生しやすく、これが後のシステム開発に大きな影響を与える可能性があります。クライアントの要望と外部設計の内容が一致しない場合、設計変更や追加作業が必要になり、コストやスケジュールの増加につながります。

認識齟齬を防ぐためには、外部設計書の内容をクライアントにわかりやすく説明し、定期的な確認作業を行うことが重要です。また、外部設計の各段階でクライアントからのフィードバックを積極的に収集し、設計内容に反映させることで、認識齟齬を最小限に抑えることができます。

設計書の品質が低い場合の改善策

外部設計書の品質が低い場合、内部設計の作業効率が低下し、システム開発全体の品質に影響を与えます。設計書の品質を向上させるためには、設計書の作成プロセスの見直しと継続的な改善が必要です。

改善策として、設計書のテンプレートの標準化、レビュープロセスの強化、設計書作成者のスキル向上などが挙げられます。また、過去のプロジェクトの事例を参考にし、品質の高い設計書の作成方法を学ぶことも重要です。

スケジュール遅延を防ぐための工夫

外部設計の作業でスケジュール遅延が発生すると、システム開発全体のスケジュールに影響を与えます。スケジュール遅延を防ぐためには、外部設計の作業計画を詳細に策定し、進捗管理を徹底することが重要です。

また、外部設計の各作業項目について、適切な工数見積もりを行い、リスクを考慮したスケジュール設定を行うことも重要です。さらに、外部設計の担当者のスキルレベルや作業負荷を考慮し、適切なリソース配分を行うことで、スケジュール遅延のリスクを最小限に抑えることができます。

外部設計に関するFAQ

外部設計にはどのくらいの期間がかかりますか

外部設計の期間は、システムの規模や複雑さ、要件定義の詳細度によって大きく異なります。一般的に、中小規模のシステムでは2〜4ヶ月程度、大規模なシステムでは6ヶ月から1年以上かかる場合もあります。外部設計の期間を適切に見積もるためには、要件定義書の内容を詳細に分析し、設計書の作成工数やレビュー工数を考慮する必要があります。

外部設計書は誰が作成するのですか

外部設計書は、通常、システムエンジニアやシステムアーキテクトが中心となって作成します。ただし、大規模なプロジェクトでは、機能別や領域別に複数の担当者が分担して作成することもあります。外部設計書の作成には、システム開発の経験と技術的知識が必要であり、要件定義からシステム設計への変換能力が求められます。

外部設計と基本設計は同じですか

外部設計と基本設計は基本的に同じ意味で使用されることが多く、システムの外部仕様や機能要件を定義する設計フェーズを指します。ただし、企業や組織によって用語の使い方が異なる場合があるため、プロジェクトの開始時に用語の定義を明確にすることが重要です。

外部設計でプログラミングの知識は必要ですか

外部設計では、直接的なプログラミング作業は行いませんが、システムの実装可能性を考慮した設計を行うため、プログラミングの基礎知識は必要です。特に、使用予定の技術や開発環境の制約を理解し、実現可能な設計を行うためには、一定レベルの技術的知識が求められます。

外部設計書の承認プロセスはどうなっていますか

外部設計書の承認プロセスは、通常、設計書の作成完了後に実施されます。承認者は、プロジェクトマネージャー、クライアント、技術責任者などが含まれ、設計書の内容が要件定義と整合性があること、技術的に実現可能であることなどを確認します。承認プロセスでは、設計書の修正要求や追加要件の検討も行われ、最終的な承認を得て内部設計に移行します。