未経験者歓迎！知識ゼロからシステムエンジニアを目指す

内部設計

内部設計では、外部設計で定義されたシステムの仕様をもとに、開発するシステムを機能やモジュール単位で分割し、それらの組み合わせ方やインタフェースの仕様などを設計します。内部設計は「システム構造設計」「詳細設計」とも呼ばれます。

なお、要件定義や外部設計とは異なり、顧客や外部システム開発チームとの仕様調整を行うことはほとんどありません。内部設計は開発チーム内での技術的な意思決定と実装方針の確立に重点を置き、設計品質とメンテナンス性を確保することが目的です。

機能分割とアーキテクチャ設計

内部設計工程では、まず機能を論理的な単位に分割します。2026年現在、クラウドネイティブ環境での開発が主流となっており、マイクロサービスアーキテクチャの考え方が極めて重要です。Kubernetesなどのオーケストレーションプラットフォーム上での運用を想定し、独立して展開・スケーリング可能な単位での分割設計が標準的になっています。

たとえば、ECサイトで商品注文機能を実装する場合、以下のようなマイクロサービス単位での分割が考えられます。

分割したそれぞれのマイクロサービスについて、インタフェースや処理ロジックを詳細に設計していきます。開発言語がJava、Python、TypeScript、Go、Rustなどのオブジェクト指向言語やシステムプログラミング言語の場合、「クラス図」「シーケンス図」「状態遷移図」といったUML図を作成し、システムの動作を明確化します。API設計ではOpenAPI（Swagger）形式での仕様定義がデファクトスタンダードとなっており、フロントエンドとバックエンドチームが並行開発を進める際に不可欠な役割を果たします。また、gRPCやProtocol Buffersといった高性能なRPC通信の活用も一般的になってきました。

「モジュール」と「コンポーネント」の違い

「モジュール」も「コンポーネント」も、ソフトウェアの部品を表す用語です。

「モジュール」は、特定の機能を持つ関数やメソッド、データ構造をまとめた単位です。通常は単独でコンパイル可能ですが、単体では動作しません。オブジェクト指向プログラミングの文脈では、クラスやメソッドの集合がモジュールに相当します。

「コンポーネント」は、モジュールを複数組み合わせたもの、またはそれ以上の大きさの機能単位を表します。マイクロサービス環境では、Dockerコンテナで実行される個別のサービスや、複数サービスを組み合わせたシステムの一部がコンポーネントとなります。コンポーネント単体では通常、単独では動作できません。

階層としては「コンポーネント ＞ モジュール ＞ クラス/関数」となりますが、組織やプロジェクトによって定義は異なることが多いため、チーム内で用語の定義を明確にしておくことが重要です。

データ設計

システムで扱うデータベースやストレージのスキーマ・レイアウトを設計します。外部システムとのインタフェースは外部設計で定義済みですが、内部設計ではシステム内部で利用するデータの構造や永続化方式を詳細に定義します。

現在の開発では、リレーショナルデータベース（RDB）だけに依存するのではなく、要件に応じた複数のデータストアを組み合わせる「ポリグロット・パーシステンス」が標準的です。例えば、キャッシュ用のRedis、ドキュメント指向のMongoDB、全文検索用のElasticsearch、時系列データ向けのTimescaleDB、リアルタイムデータベース（Firebase Realtimeなど）など、用途や性能要件に応じて最適なテクノロジーを選択します。また、データレイク構想の場合はApache Iceberg等の分析用フォーマットの活用も一般的です。

スケーラビリティ、応答性能、可用性、デバッグ可能性といった非機能要件に加え、セキュリティ（データ暗号化、アクセス制御）、可観測性（ログ、メトリクス、トレース）、災害復旧（バックアップ・リカバリー戦略）を含めた総合的なデータ設計が重要です。マイクロサービス環境では、各サービスがデータベースを独立して持つ「データベースパー・マイクロサービス」パターンも検討する価値があります。

■次の記事
プログラミング

内部設計 関連ページ

開発工程とは

開発工程モデル

各工程の成果物を正確に仕上げることの重要性

要件定義

外部設計

プログラミング

単体テスト

結合テスト

システムテスト

運用テスト

システム移行