外部設計
外部設計とは要件定義で決まった内容をもとに、ユーザーインターフェースや他システムとの連携仕様を設計する工程です。「基本設計」や「概要設計」と呼ばれることもあります。クラウドネイティブアーキテクチャ、マイクロサービス、コンテナ化（Docker、Kubernetes）が標準的となった現代では、REST API、GraphQL、gRPCなどのインターフェース仕様設計が外部設計の重要な役割となっています。また、AI/機械学習モデルの推論APIやイベント駆動アーキテクチャへの対応も、現代的な外部設計では必須となっています。
この工程では利用者から見てシステムがどのように振る舞うべきか、操作する画面のレイアウトや操作方法、データフロー、データベースの構造などを決めていきます。特にモバイルやWebアプリケーション、PWA（Progressive Web Apps）では、レスポンシブデザイン、アクセシビリティ、パフォーマンス最適化が設計段階で重要です。さらに、セキュリティ設計（OWASP対応、データ暗号化、認証・認可スキーム）もこの段階で組み込むことが必須です。
外部設計工程でまず行うことは「設計基準」を決めることです。画面や帳票のデザインや操作性に関わる共通事項をルール化して、設計するメンバーで共有することで、全体として統一感のある設計書を作るのです。具体的な設計基準としては、「画面設計基準」、「帳票設計基準」、「API設計基準」、「データベース設計基準」に加えて、「セキュリティ設計基準」や「パフォーマンス基準」などが含まれます。
画面設計
画面上の入力項目や出力項目、ボタンをどこに配置するか、それぞれの色やサイズなどの「画面レイアウト」を設計します。現代はフロントエンドフレームワーク（React、Vue.js、Angular、Svelte等）を使用した開発が主流であり、TypeScript、JavaScriptを用いたコンポーネント駆動開発が一般的です。次に「画面遷移」を設計します。画面遷移とは「画面の操作によって、どの画面に表示が切り替わるか」を矢印で示したものです。スマートフォンやタブレット、デスクトップなど複数デバイスに対応するレスポンシブデザイン、ページの高速化（Lazy Loading、Image Optimization）、ダークモード対応、アクセシビリティ（WCAG 2.1準拠）も現代の画面設計では必須です。さらに、ユーザーエクスペリエンス（UX）を最大化するため、A/Bテスト、ヒートマップ分析、ユーザビリティテストも設計検証に組み込まれます。
帳票設計
「帳票」とは金銭や物品の取引などを記録した、帳簿や伝票などの定型的な印刷物のことをあらわします。出金や入金、出荷、納品などを記録として蓄積したり、相手方へ通知するために作成される書類で、出納帳や入出金伝票、請求書、領収書などといったさまざまな種類のものが含まれます。「帳票設計」ではこれら帳票のレイアウトを決めていきます。現在はペーパーレス化、デジタル化、電子署名対応が進み、PDF生成、クラウドストレージ連携、タイムスタンプ埋め込みを前提とした設計が一般的です。さらに、電子帳簿保存法や各種コンプライアンス要件への対応も設計に含まれます。
オーバーレイ印刷とは
多くの帳票は「書式」部分と「データ」部分に分かれます。
「書式」部分は帳票のタイトルや罫線といった固定の印刷内容のことを指します。
たとえば、請求書であればタイトルの「請求書」や明細の「罫線」などです。
いっぽう、「データ」部分は日付や金額など可変となる印刷内容のことを指します。
たとえば請求書であれば請求日や合計金額などです。
これら固定の「書式」と可変の「データ」を重ねて印刷する方式を「オーバーレイ印刷」と呼びます。現在ではHTML/CSSを用いたPDF生成（Puppeteer、Playwright等を使用）やクラウドプリント機能が一般的であり、より柔軟で保守性の高い帳票管理が可能になっています。
外部インターフェイス設計
外部システムとやり取りするインターフェイスの内容を設計します。クラウド化とマイクロサービスアーキテクチャの浸透により、REST API、GraphQL、gRPC、WebSocket、メッセージキュー（RabbitMQ、Apache Kafka、AWS SQS等）を用いたシステム間の連携が標準的になっています。また、イベント駆動アーキテクチャやサーバーレス（AWS Lambda、Google Cloud Functions等）への対応も現代的な設計では重要です。API仕様設計時には、OpenAPI（Swagger）で標準化し、セキュリティ（OAuth 2.0、API Key、mTLS）も併せて設計します。
データ項目の決定
データとして何をやり取りするのかを決めます。たとえば、顧客の属性をあらわすデータであれば「氏名」「住所」「生年月日」などです。APIの時代には、エンドポイントごとに提供するデータ項目、レスポンスの粒度（Over-fetching、Under-fetching への対応）、ページネーション、フィルタリング、ソートといった仕様も設計時に明確に定めることが重要です。
データ形式の決定
やり取りするデータは固定長なのか可変長なのか、を決めます。固定長とは１行のレコード長（バイト数）が固定のデータ形式を指します。レガシーシステムでは固定長データを扱うことがありますが、新規開発ではほぼ採用されません。
可変長とは１行のレコード長（バイト数）が可変のデータ形式を指します。現在の標準フォーマットはJSON（JavaScript Object Notation）であり、REST APIを通じた連携ではJSON形式が大多数です。XML形式もAPI連携では使用されていますが、JSONの方が軽量で処理が効率的なため広く採用されています。GraphQLでは独自の型定義とクエリ言語を用いることで、クライアント側での柔軟なデータ取得が可能です。
区切り文字が「,」カンマであれば、「Comma Separated Values」の頭文字をとって「csv」形式と呼ばれ、データの一括投入やレポート出力で今も使用されています。
連携タイミングの決定
データをいつやり取りするか、毎日なのか、週に1回なのか、リアルタイムなのかを決めます。リアルタイム処理が求められるシステムではWebSocket、Server-Sent Events（SSE）、メッセージキュー（RabbitMQ、Apache Kafka、AWS SNS/SQS等）を使用した非同期連携が標準的です。また、CI/CDパイプラインの自動化により、デプロイ時のデータ同期やバッチ処理もスケジュール管理されます。
連携方式の決定
データをどのように連携するかを決めます。従来のCD や テープなどの外部記憒媒体での連携は廃止され、現在はHTTPS通信、クラウドストレージ（AWS S3、Google Cloud Storage等）、VPN、専用のAPI連携が主流です。ファイアウォール内での連携ではVPN、インターネット経由ではHTTPSやTLS 1.3を用いたセキュアな通信が必須です。Zero Trust セキュリティ、エンドツーエンド暗号化、デジタル署名もデータ連携の信頼性を確保するため必須です。クラウドプロバイダー（AWS、Google Cloud、Microsoft Azure等）が提供するマネージド統合サービスやEvent Mesh、API Gateway、Data Integration サービスを利用する選択肢も増えています。
データベース設計
データベース設計とはデータベースによってデータを管理できるように現実の世界を抽象化してデータモデルを作成していく作業です。データモデルはデータベースをどのように構成するかということを定義したものです。現代では用途に応じた多様なデータベース選択肢があります。リレーショナルデータベース（MySQL、PostgreSQL、オンプレミス/クラウドマネージド型）、NoSQL（MongoDB、DynamoDB、Firestore等）、データウェアハウス（BigQuery、Redshift、Snowflake等）、タイムシリーズデータベース（InfluxDB、TimescaleDB、Prometheus等）、グラフデータベース（Neo4j、DynamoDB Global Secondary Indexes等）など、データの特性に応じた選択が重要です。さらに、キャッシング層（Redis、Memcached）を併用したアーキテクチャも一般的です。
このデータモデルを作成していく作業（データモデリング）は一般的に「概念設計」、「論理設計」、「物理設計」という3つの段階を通して行われます。そして、それぞれの段階ではアウトプットとして「概念モデル」、「論理モデル」、「物理モデル」が作成されます。
なお、「概念設計」までを外部設計、「論理設計」と「物理設計」を内部設計と扱う会社もありますが、本サイトでは全て外部設計として扱います。
概念設計
概念設計では、データベースによって管理の対象とするものを現実の世界から抽出して概念モデルを作成します。ビジネスドメイン駆動設計（DDD：Domain Driven Design）の考え方を適用し、ユビキタス言語、境界づけられたコンテキスト、エンティティ、バリューオブジェクトなどの概念を活用します。エンティティ間の関係や制約条件を明確に定義することが重要です。
概念モデルの作成にあたっては、ERモデル（実体参照モデル）がよく使用されます。ERモデルでは、その名のとおり、実体（エンティティ）と関連（リレーションシップ）によってモデルを作成していきます。実体は現実の世界を構成する実体そのもの、関連は実体間のつながりを表現します。また、実体や関連は属性（アトリビュート）を持つことができます。現代ではER図の作成ツール（Lucidchart、draw.io等）やデータベース設計ツール（dbdiagram.io等）が活用されます。
論理設計
論理設計では、概念設計によって作成された概念モデルを特定のデータモデルに対応した論理モデルに変換します。リレーショナルデータベースではERモデルからリレーショナルモデルを作成します。NoSQLデータベース（ドキュメント型、キー・バリュー型、グラフ型等）を使用する場合は、各データベースの特性に合わせた設計が必要です。例えば、MongoDBではドキュメント構造の最適化、DynamoDBではパーティションキーの選定が重要です。
リレーショナルモデルではERモデルからテーブル（リレーション）への変換は機械的に行うことができます。しかし、そのままテーブルに変換しただけでは、リレーショナルモデルとして適切な形式にならない場合があります。
そこで、論理設計ではテーブルをリレーショナルモデルとして適切な形式に変換する作業（正規化）を行います。テーブルを正規化することによってデータの冗長性や不整合を減少させることができます。正規化は第1正規形から第3正規形、さらにBCNF（Boyce-Codd正規形）まで段階的に進められます。
物理設計
物理設計の段階になって初めてデータベースとしての性能について考慮します。具体的には、論理設計において正規化したテーブルの定義を戦略的に非正規化（デノーマライズ）したり、インデックス戦略を定義したり、パーティショニングやシャーディングを導入したりして性能が向上するようにモデルを修正していきます。クラウド環境ではスケーラビリティ、自動バックアップ、レプリケーション、フェイルオーバー、コスト効率性も重要な検討項目です。また、物理設計では使用するデータベースに依存する機能（トランザクション分離レベル、ロック機構、レプリケーション設定、暗号化、監査ログ等）を活用することもあります。
物理設計によって修正されたモデルを物理モデルと呼び、このモデルをもって実際にデータベースによって管理することができる形式となります。さらに現代では、Infrastructure as Code（Terraform、CloudFormation等）によるデータベース構成の自動プロビジョニングや、ロードバランシング、読み取り専用レプリカの自動スケーリングなども物理設計に含まれます。
■次の記事
内部設計
■おすすめ記事
プログラミングスクール２８選 - 受講内容と料金まとめ(無料あり) ※ 就職・転職支援付き
フリーランスエンジニア 案件サイト ２４選 - 【最高単価／募集地域／公開案件数】まとめ
ITエンジニアのキャリアアップを検討しているなら
PR
