外部設計は、「システム開発をスムーズに進め、高品質な製品を作るために重要な工程」です。
本記事では、外部設計とは何かを分かりやすく、概要から詳しく解説します。
内容を理解できると、クライアントからの要望をしっかり汲み取り、ユーザー視点に立ったシステムを開発できるでしょう。
合わせて覚えておきたい、内部設計の内容やシステム設計全体の流れも紹介するので、ぜひ参考にしてください。
アプリ・システム開発のプロが開発のお悩みを解決します
アプリ・システム開発の6割が失敗すると言われています。クライアントのリピート率100%のリレイスにご相談ください。
＼ まずは無料相談！1営業日以内に返信 ／
目次
外部設計とは
外部設計（external design）とは、システム開発における工程の1つです。「基本設計」や「概要設計」ともいわれます。
外部という単語で表されるのは、ユーザーが触れる表面的な部分をシステムによって調整するためです。
また、外部設計によって目に見える枠組みを設定すると、双方で開発のイメージが定まります。
外部設計で設定する機会が多いのは、下記のエンドユーザーに向けた仕様です。
- 操作画面のレイアウト
- 操作方法
- データ出力
- セキュリティ
- 運用規定
- 開発スケジュール・費用
外部設計をより深く理解するには、知識がなければ混同しやすい内部設計の内容も理解しておきましょう。
外部設計と合わせて知りたい内部設計とは
内部設計（Internal design）では、外部設計で決められた内容を実現するシステムやプログラムを設計します。
ユーザーの目に見える外側の機能が、クライアントの要望通り処理できるようにシステムを設計する開発工数です。
システムの内部を細かく構築する段階のため、「詳細設計」と呼ばれることもあります。
内部設計で大切なのは、外部設計の内容を忠実に反映させることですが、後の作業が円滑に進められるような配慮も必要です。
理想のシステム構想と実際のプログラミング作業の間に入って、スムーズに開発が進められるような段取りを組むのが内部設計の役割であるといえるでしょう。
外部設計と内部設計の違い
違いを簡潔に表現すると、下記の通りです。
- 外部設計…ユーザーが実際に利用する外側部分の設計工程
- 内部設計…ユーザーから見えない内側の設計工程
外部設計は「ユーザーが直接見て触れられる部分を決める」工程です。
ユーザーが使いやすいサービスを目指し、システム全体の概要や大まかな機能を設計します。
エンドユーザーが直接触れる部分は、クライアントのビジネス結果に影響する場合も多いです。
そのため、クライアントの意見が最も反映される部分でもあります。
一方、内部設計は「ユーザーには見えない開発者よりの内容」です。
外部設計で決定された内容が反映されることが条件になるため、一般的にクライアントに確認する工数は発生しません。開発者の意見を優先して、作業を円滑に進められるように設定しましょう。
システムを設計する流れ｜外部設計と内部設計の仕事内容
システムを設計する際は、以下の流れでプロジェクトが進行します。
- 要件定義で方針を決める
- 外部設計でシステムの機能を決める
- 内部設計でデータ構造を決める
システム設計は、どのようなサービスを作りたいかクライアントからの要望をまとめる要件定義からスタートします。
実際の流れと合わせて、具体的な仕事内容まで解説するので、それぞれ確認してみましょう。
要件定義で方針を決める
要件定義とは、「クライアントの要望をどう実現させるかの方針をまとめるための工数」です。
すべての工程が要件定義を元に進められるため、重要な項目といえます。
要件定義の段階での作業は、下記の内容で進行される場合が多いです。
- n
すべての内容が定まった段階で、要件定義書を作成します。要件定義書を元にして外部設計や内部設計が進められるため、定義を明確にすると作業の後戻りや作り直しといったリスクを回避できます。
このように、要件定義は、開発側が何をすべきか理解し、クライアントとプロジェクトの認識をすり合わせるために必要不可欠な項目です。
外部設計でシステムの機能を決める
要件定義書が仕上がったら、外部設計でシステムの機能を決めます。
検討すべき内容について段階を追って設計するために、3つの工程で進行します。
- 方式設計
- 機能設計
- それ以外の設計
具体的な工程を、下記の表にまとめました。
| 工程 | 内容 |
|---|---|
| 方式設計 | システム実装・基盤の方針を設計するハードウェアやソフトウェアの機能や構造を検討するシステム基盤やや開発言語をどうするか検討するアプリケーションの場合、全体の設計も含まれるため「アーキテクチャ設計」ともいう |
| 機能設計 | システムを機能単位で分割してそれぞれのデータベースを設計するデータの入出力・データベース同士の情報の受け渡し・操作・帳票の出力などを検討するユーザーの満足度につながるUX/UIの仕様も検討する |
| その他の設計 | クライアントの要望に沿うセキュリティ・運用規定・納期・開発費用などの決定する作成したサービスの運用で必要な内容を決める |
業務フローやシステムの構成図、遷移図などの枠組みを作りながら作業を進めます。
すべての流れが設定できたら、成果物として外部設計書にまとめます。外部設計書は、開発の輪郭が分かりやすいように図を使用しましょう。
内容を確認してクライアントから了解を得られた段階で、次の内部設計に移行する流れです。
内部設計でデータ構造を決める
内部設計の主な作業は、下記3つの工程に分けられます。
- 機能分割
- データベース設計
- 入出力の詳細設計
機能分割では、開発するシステムを分割します。例えばECサイトの場合、以下の機能が必要とされることが多いです。
- 商品を一覧表示する機能
- ショッピングカート機能
- 注文情報管理機能
最終的に1つのページに表示される内容でも、必要な機能ごとに分割して設計すれば分担による作業効率が向上します。
機能分割から、各モジュールごとにデータを表示するために必要な以下の内容を構築するのが、データベース設計です。
- システム内部のデータ処理
- 初期値の定義
- デフォルト値
- ファイルやデータのやり取りに関する機能
- UI/UXの実装・表現手段
- 入力データのチェック方法
- データの検索ルール
- エラー処理
入出力の詳細では、サイトのエラーやプログラムの不具合といった項目を設計します。
外部設計書を書くときのポイント
外部設計の決定内容を、クライアントや設計者以外のメンバーにわかりやすく伝えるのが外部設計書です。外部設計に携わる際には、内容をしっかり理解しましょう。
外部設計書を書くときのポイントを詳しく解説します。外部設計書に盛り込むべき項目を、わかりやすく表にまとめました。
| 項目 | 内容 |
|---|---|
| 業務フロー | 業務内容や流れを図でまとめるクライアントに伝わるようにシンプルで明確なものにする |
| 機能一覧表 | 開発対象となる機能を一覧で提示する開発担当が作業内容を把握しやすくなる |
| ネットワーク構成図 | ネットワークに関する情報をまとめた構成図IPアドレスやVLAN・Pathなど必要な情報を共有するもの誰が見ても理解できるような「わかりやすさを重視」するトラブル時の経路調査に使う「全体概要図」や設計・設定時に使う「コンポーネント詳細図」などを用意する場合もある |
| テーブル定義 | データベースのテーブルを定義したもの項目・データ型・キーを表でまとめる定義内容の記載もあるとよりわかりやすいシステムをスムーズに引き継ぐ際に重要となる項目 |
| ER図 | データ構造を「実体（entity）」「関連（relationship）」「属性（attribute）」に分けて視覚的にまとめた設計図システム全体を俯瞰で確認できる仕様の理解がしやすくなり後戻りのリスクを抑えられる設計者以外でも内容を把握できるため運用・保守にも役立つ |
| 画面レイアウト・帳票レイアウト | クライアントにシステムのイメージを確認してもらう項目操作・管理画面の完成イメージを視覚的に提示する見た目だけでは伝わらない「入力項目や出力情報」についての補足資料があるとわかりやすい |
設計書が完成したら、下記を確認してください。
- 要件定義と整合性がとれているか
- 実現できるシステムであるか
- クライアントにわかりやすくまとめられているか
丁寧な外部設計書は、エンジニアにとって開発・運用しやすい環境が整えられるほか、作業内容をクライアントへわかりやすく伝える資料にもなります。
まとめ
外部設計は、「クライアントの要望を整理してシステム開発の基盤を整える工程」です。高品質なシステムを制作するために重要な工程なので、必要な作業内容をしっかり把握しましょう。
また、要件定義に沿った設計をするためには、「丁寧な外部設計書の作成も重要」です。記事を参考に、わかりやすい設計書を作成して、スムーズな内部設計につなげてください。
