「外部設計って結局何をするの？」
「外部設計書って何を書けばいい？」
「内部設計との線引きがよくわからない」

システム開発に関わり始めたばかりの方ほど、こういった疑問にぶつかりがちです。

外部設計とは、システムを使う人の目線に立って仕様を具体化していく作業です。
どんな画面を用意するか、どう操作するか、何を入力・出力するか、帳票はどうするか。
そういった「見える部分」を整理するのが主な仕事です。現場によっては基本設計と同じ意味合いで使われることもあります。

IPAの資料でも、外部設計の段階までに発注者と開発者が機能要件について認識をそろえておくことの重要性が強調されています。
外部設計は書類を作るだけの工程ではなく、後工程での手戻りや認識のズレを防ぐための重要なステップです。

この記事では、外部設計の基本的な意味から、外部設計書に書くべき内容、内部設計との使い分け、作成時に意識したいポイントまでを、わかりやすく整理してお伝えします。

外部設計とは

外部設計の意味

外部設計とは、システムの「外側」——つまりユーザーが実際に触れる部分の仕様を固めていく工程です。
具体的には、以下のような内容を検討・整理します。

• どのような画面が必要か
• ユーザーはどう操作するか
• 何を入力し、何が表示されるか
• どのような帳票を出力するか
• 外部のシステムとどのように連携するか

要件定義で「何をつくるか」が決まったら、外部設計では「それを利用者はどう使うか」を形にしていきます。
画面・操作・データ出力など、ユーザーの目に触れるインターフェース全般を対象とするのが外部設計の範囲です。

外部設計はどの工程にあるのか

開発プロセス全体の中では、要件定義の次、内部設計や実装の手前に位置します。一般的には以下のような順序で進みます。

要件定義 → 外部設計 → 内部設計 → 実装 → テスト

IPAの資料でも、画面設計は要件定義や外部設計の段階で作成された業務フローを土台にして進めることが前提とされています。

外部設計が重要な理由

外部設計が果たす最大の役割は、発注者・利用者・開発者の三者が同じ認識を持てる状態をつくることです。
この工程が不十分なままだと、こんなトラブルが起きやすくなります。

• 完成した画面が想定とまったく違う
• 必要だった入力項目が抜けていた
• 操作が直感的でなく使いづらい
• 帳票や出力データの形式が想定外だった

IPAのガイドでも、外部設計の完了時点で機能要件の合意をとることが強く推奨されています。
後からの仕様変更を防ぐ意味でも、外部設計は手を抜けない工程です。

外部設計とほかの工程との違い

外部設計と要件定義の違い

要件定義は「何を実現するか」を決める工程です。ビジネス上の課題や必要な機能、開発のスコープや前提条件などを洗い出します。
外部設計は、その決定事項をベースに「どういう形でユーザーに届けるか」を具体化していく工程です。

外部設計と基本設計の違い

実務の現場では、外部設計と基本設計がほぼ同義で使われるケースも少なくありません。外部設計は基本設計の別名として扱われることもあります。

用語の定義は現場によって異なるため、プロジェクトに入る際は「この職場ではどう使い分けているか」を最初に確認しておくと安心です。

外部設計と内部設計の違い

この二つの違いは、誰のための設計かという視点で整理するとわかりやすいです。

ログイン機能を例にとると、外部設計では「IDとパスワードの入力欄をどう配置するか」「ログインボタンを押したら何が起きるか」「エラーメッセージはどう表示するか」を決めます。
内部設計では「認証処理のロジック」「どのDBテーブルと照合するか」「セッション管理をどうするか」を決める、という使い分けです。

外部設計で決めること

画面設計

外部設計の中心となる作業が画面設計です。各画面について、以下のような内容を整理していきます。

IPAの画面設計ガイドでも、外部設計工程で作成する業務フローを基点として画面を設計していくアプローチが示されています。

画面遷移

画面そのものだけでなく、「画面同士のつながり」も外部設計の重要な検討事項です。たとえば、

• 一覧画面から詳細画面へ移動する
• 入力画面から確認画面へ進み、完了画面へ遷移する
• エラーが発生したら入力画面に戻る

といった流れを明確にしておく必要があります。
画面単体がきれいに設計されていても、遷移設計が甘いと実際の操作でユーザーが迷いやすくなります。

入出力項目

各画面で扱うデータの定義も外部設計の範囲です。
入力項目については、以下のような内容を明確にします。

出力項目についても、何を表示するか、どの条件のときに表示するか、並び順はどうするか、まで詰めておくと後の工程がスムーズに進みます。

帳票・インターフェース設計

外部設計の対象は画面だけではありません。帳票出力や外部連携も含まれます。
代表的なものとしては、CSV・PDFの出力、メール通知、外部APIとの連携、他システムへのデータ受け渡しなどがあります。
これらは外部設計書や帳票仕様書、インターフェース仕様書としてまとめられることが多いです。

操作性やユーザビリティ

外部設計は仕様を列挙するだけの作業ではなく、「使いやすいか」という視点が欠かせません。

ボタンの配置は直感的か、入力の流れに無理がないか、エラーが出たときに次の行動がわかるか、必要な情報にすぐたどり着けるか。
こうした使い勝手への配慮が、ユーザー体験の品質を左右します。

外部設計書とは

外部設計書の役割

外部設計書は、外部設計で決定した内容を文書としてまとめたものです。その目的はシンプルで、関係者全員が同じ認識を持てるようにすることです。外部設計書があることで、発注者はシステムの仕上がりを事前に確認でき、開発者は実装の方向性を正しく理解でき、テスターは検証観点を整理しやすくなります。また、開発後に見返す際の参照資料としても役立ちます。

外部設計書に書く内容

プロジェクトの規模や性質によって多少異なりますが、外部設計書に盛り込まれることが多い内容は以下の通りです。

• 画面一覧・画面レイアウト
• 入出力項目の定義・入力チェックルール
• 画面遷移の流れ
• 帳票・外部連携の仕様
• エラーメッセージの内容と表示条件
• 操作手順の説明

よくある成果物の例

外部設計フェーズで作成される資料の代表例としては、外部設計書・画面仕様書・帳票仕様書・インターフェース仕様書・画面遷移図・項目定義書などが挙げられます。一つの資料にまとめることもあれば、用途や対象読者によって分冊することもあります。形式よりも「必要な情報が過不足なく揃っているか」が大切です。

外部設計書を作るときのポイント

読む相手を意識する

外部設計書を読むのは開発者だけではありません。
発注者、PM、デザイナー、テスターなど、技術的なバックグラウンドが異なるさまざまな人が目を通します。

こうした配慮が、資料の伝わりやすさを大きく左右します。

画面仕様と画面遷移をセットで考える

各画面について、「この画面はどこから来るのか」「操作後はどこへ進むのか」という流れを意識しながら設計することが重要です。

個々の画面仕様がどれだけ詳細でも、遷移の設計が不十分だと実際の使い勝手は見えてきません。
逆に、遷移図だけあって各画面の仕様が曖昧でも困ります。
両者を連動させて考えることが、品質の高い外部設計につながります。

入力チェックとエラー表示を丁寧に定義する

外部設計書で抜け落ちやすいのが、バリデーションとエラー時の挙動です。

• 必須項目が未入力のとき
• 入力形式が合っていないとき
• 対象データが存在しないとき
• 操作権限がないとき

それぞれのケースでどのようなメッセージをどこに表示するかを事前に定義しておくと、実装フェーズでの手戻りが大幅に減ります。

外部設計でよくある課題

要件定義の焼き直しで終わってしまう

外部設計書を作ったつもりが、要件定義の内容を言い換えただけになっているケースがあります。

外部設計に求められるのは、ユーザーが実際に操作する場面まで粒度を落とすことです。
「予約機能がある」で止まらず、「どの画面で、どの項目を入力し、どのボタンを押すと、どのような結果になるのか」まで書き切ることが求められます。

画面設計に力を入れすぎて遷移がおろそかになる

見た目の整ったレイアウトを作ることに集中するあまり、画面間のつながりが薄くなるケースがあります。

• 「戻る」ボタンの動線がない
• 処理完了後の遷移先が不明確
• エラー発生時にどこへ戻るかが曖昧

こうした問題は、リリース後のクレームや修正対応につながりやすいので注意が必要です。

設計書の書き方がメンバーによってバラバラ

複数人で外部設計書を作成すると、画面によって記載の粒度や書き方がバラバラになりがちです。

細かく書かれた画面がある一方、別の画面は概要しかないという状態ではレビューも通しにくくなります。
テンプレートや記述ルールを事前に統一しておくことが、品質を安定させる鍵になります。

まとめ

外部設計とは、ユーザーや発注者の目線に立って、システムの見える部分の仕様を具体化する工程です。
要点を整理すると、以下のようになります。

一言で表すなら、外部設計とは「ユーザーが触れる世界を設計する工程」です。