システム開発における設計工程

設計工程は、要件定義で決めた「何を実現するか」を、実装できる「どのように作るか」へ具体化する段階です。

基本設計と詳細設計に分ける方法が代表的ですが、名称や境界は組織、契約、開発手法によって変わるため、成果物と責任範囲で確認します。

設計工程の目的

設計工程の目的は、利用者の要求を満たすシステムの構造と振る舞いを定め、実装・テスト・運用で判断できる共通の仕様を作ることです。

画面、データ、外部連携、権限、性能、障害時の動作などを関連づけ、要件を実現する方法を選びます。

設計書の作成だけが目的ではありません。

複数の実現方法から、制約、費用、保守性、リスクを踏まえて方針を決め、その理由を関係者が追える状態にすることが設計です。

前後工程との関係は、開発エンジニアが関わる工程も参考にしてください。

出典：厚生労働省 職業情報提供サイト「システムエンジニア（受託開発）」

基本設計と詳細設計の違い

基本設計では、利用者や外部システムから見える仕様と、システム全体の構成を主に決めます。

画面・帳票、データベース、外部連携、権限、インフラ構成などが代表例です。

詳細設計では、基本設計をもとに、処理手順、モジュール、データ形式、入力チェック、例外処理などを実装可能な粒度へ分解します。

ただし、画面項目をどちらで決めるかなどは案件ごとに異なります。

工程名ではなく、誰が読んで何を判断できる成果物かを確認すると違いを整理しやすくなります。

開発手法による設計の違い

ウォーターフォール型では、基本設計と詳細設計の期間、成果物、承認条件を区切り、合意後に実装へ進む形が一般的です。

仕様変更が起きたときは、要件や関連する設計書への影響を確認します。

アジャイル開発では、優先度の高い機能を小さな単位で設計・実装・確認し、学びを次の反復へ反映します。

設計活動がなくなるわけではなく、設計を確定する範囲と時期、記録方法が変わります。

いずれの手法でも、重要な判断理由、インターフェース、品質条件など、後から参照する情報は共有できる形で残してください。

設計前に確認すること

設計を始める前に、承認済みの要件、未決事項、技術・運用上の制約、レビュー体制を整理します。

入力となる情報が曖昧なまま作図や文書化を進めると、設計者ごとに異なる前提が入り、後工程で矛盾が見つかりやすくなります。

要件と未決事項を確認する

まず、業務要件、機能要件、非機能要件、移行・運用要件を読み、設計で満たす条件を抽出します。

各要件に識別番号があれば、画面、機能、データ、テストとの対応を追えるようにします。

要件に「使いやすい」「十分に速い」など解釈が分かれる表現が残っている場合は、利用場面、処理量、確認方法を要件担当者へ戻して確認してください。

未決事項は推測で埋めず、決定者、期限、影響範囲を記録します。

要件定義から見直したい場合は、システム開発の要件定義も参考になります。

制約と現行環境を把握する

設計案を選ぶ前に、既存システム、利用できるクラウド・製品、ネットワーク、データ形式、外部API、社内標準を確認します。

予算、納期、ライセンス、運用時間、保守体制、法令・規程も設計を制限する条件です。

現行環境と接続する場合は、仕様書だけでなく、実データの揺れ、通信可能時間、障害時の責任分界も確かめます。

制約は設計の自由度を狭める情報であると同時に、実現できない案を早期に除く判断材料です。

前提が変わったときに設計への影響を追えるよう、根拠と確認日も残してください。

設計・レビュー体制を決める

設計対象を画面、業務機能、データ、外部連携、基盤などに分け、担当者と責任者を決めます。

分担する場合は、共通用語、命名規則、設計書の粒度、更新方法を先にそろえてください。

レビューでは、利用部門、開発、インフラ、セキュリティ、運用など、確認すべき観点に応じて参加者を選びます。

誰が承認するか、指摘をどこに記録するか、未解決事項をどの条件で次工程へ持ち越すかも決めます。

基本設計で決める項目

基本設計では、要件を利用者や外部システムから確認できる仕様と、システム全体の構成へ変換します。

画面や機能を個別に決めるだけでなく、データ、権限、連携、性能、運用まで相互の関係を確認することが欠かせません。

画面・帳票・操作を設計する

画面設計では、利用者、操作目的、表示項目、入力項目、遷移、権限、エラー表示を決めます。

見た目だけでなく、業務の開始から完了まで操作できるか、例外時に戻れるかを確認してください。

帳票では、出力条件、項目、並び順、形式、保存・配布方法を定めます。

画面一覧、画面遷移図、ワイヤーフレームを使うと、利用者と開発者の認識を合わせやすくなります。

ただし、色や配置の議論だけに偏らず、業務要件と各操作が対応しているかをレビューの基準にします。

データ・権限・連携を設計する

データ設計では、業務で扱う情報をエンティティや項目へ整理し、識別方法、関連、保存期間、更新責任を決めます。

同じ意味のデータが複数箇所で管理される場合は、正とする情報源を明確にしてください。

権限設計では、利用者の役割ごとに閲覧・登録・更新・削除できる範囲を定めます。

外部連携では、送受信するデータ、方式、タイミング、認証、失敗時の再実行、責任分界を確認します。

個別仕様を別々に決めず、データの生成から利用・削除までの流れとして整合性を見てください。

システム構成と非機能を設計する

システム構成では、アプリケーション、データベース、ネットワーク、外部サービスなどの配置と接続を決めます。

要件で定めた性能、可用性、拡張性、バックアップ、監視、セキュリティを、構成や運用手順へ反映します。

「高性能」「安全」といった言葉だけでは設計を評価できません。

対象となる処理、想定負荷、障害時の動作、測定・確認方法を対応づけます。

セキュリティは実装後に追加するのではなく、設計段階から認証、権限、暗号化、ログ、脅威への対応を検討してください。

出典：IPA「セキュリティ・バイ・デザイン導入指南書」

詳細設計で決める項目

詳細設計では、基本設計で合意した仕様を、開発者が迷わず実装できる処理単位へ分解します。

正常時の流れだけでなく、入力不備、外部連携の失敗、重複実行なども扱い、単体テストで確認できる条件まで具体化します。

処理とモジュールを設計する

機能を処理やモジュールへ分け、各単位の責任、入力、出力、呼び出し関係、処理順序を定めます。

一つのモジュールに複数の役割を詰め込むと、変更の影響を追いにくくなるため、責任の境界を明確にしてください。

処理フロー、シーケンス図、クラス図、API仕様などは、関係を表す手段として使います。

図を作ること自体を目的にせず、並行処理、トランザクション、再実行、状態遷移など、文章だけでは誤解しやすい点を可視化します。

実装方法を過度に固定せず、守るべき仕様と開発者へ委ねる判断を分けることも必要です。

データ形式と例外処理を決める

詳細設計では、変数やファイル、APIのデータ型、桁数、必須条件、形式、初期値、コード体系を決めます。

データベースを扱う場合は、テーブル、カラム、キー、制約、インデックス、更新方法まで具体化します。

例外処理では、入力誤り、データ不整合、通信失敗、タイムアウト、権限不足が起きたときの動作を定めてください。

利用者への表示、ログへ残す情報、再試行、処理の取り消し、通知先を区別します。

機密情報をエラー画面やログへ不用意に出さないなど、正常系と同じ段階で安全な失敗の仕方を設計することが欠かせません。

テストできる仕様に落とし込む

設計内容は、実装できるだけでなく、期待どおりか確認できる必要があります。

入力条件、処理、出力、状態変化、境界値、例外時の結果を明確にし、単体テストの観点へつなげてください。

曖昧な表現が残る場合は、サンプルデータや具体的な入出力例を設計書へ添えます。

要件、基本設計、詳細設計、テスト項目に識別子を持たせると、抜けや変更影響を追いやすくなります。

設計の進め方と成果物

設計は、要件を設計項目へ展開し、方針を決め、図や文書に表し、レビューで確かめる流れで進めます。

成果物の種類を増やすより、参照関係、最新版、決定理由を明確にし、実装・テスト・運用で使える情報を残してください。

要件から設計項目へ展開する

最初に、要件ごとに影響する画面、機能、データ、連携、構成、運用を洗い出します。

全体方針や共通仕様を先に決めてから個別機能へ進むと、担当者ごとの設計のばらつきを抑えやすくなります。

設計案が複数ある場合は、要件への適合、技術的実現性、費用、性能、保守性、リスクを比較し、採用理由を記録してください。

小さな検証が必要な技術課題は、期限と確認項目を決めて試します。

依存関係の強い項目から合意し、後続の設計を何度もやり直さない順番を組み立てます。

図と設計書で仕様を表す

成果物には、基本設計書・詳細設計書のほか、画面一覧、データモデル、インターフェース仕様、構成図、処理フローなどがあります。

プロジェクトによっては、Wiki、チケット、リポジトリ内の文書へ分けて管理します。

一つの文書へすべてを詰め込まず、情報の性質に合う表現を選んでください。

図には対象範囲と凡例を付け、一覧には識別番号を持たせます。

同じ内容を複数箇所へ重複して書く場合は正本を決め、更新漏れを防ぎます。

成果物の形式より、必要な人が最新の仕様を見つけて判断できることを優先します。

レビューと変更を管理する

レビューでは、要件との対応、仕様間の整合性、実現性、操作性、性能、セキュリティ、運用性、テスト可能性を確認します。

読み合わせだけでなく、業務の流れやデータの変化をたどると、境界部分の抜けを見つけやすくなります。

指摘には対象、内容、対応者、期限、判断結果を記録し、未解決のまま埋もれないようにしてください。

設計変更が起きたら、要件、関連設計、コード、テスト、運用手順への影響を確認します。

承認済みの版と検討中の変更を分け、関係者が異なる仕様を参照しない状態を保ちます。

設計品質を高めるポイント

設計品質は文書量ではなく、要件を満たし、仕様同士が矛盾せず、実装・テスト・運用で判断できるかで評価します。

案件へ参画するときも「設計あり」という説明だけで決めず、対象範囲、成果物、意思決定、顧客との接点まで確認してください。

要件との対応と整合性を保つ

各要件がどの画面、機能、データ、テストで実現・確認されるかを対応づけます。

対応先がない要件や、根拠となる要件がない機能を見つけたら、追加・削除の判断を関係者へ確認してください。

設計書同士の整合性も確認します。

画面では入力できるのにデータ項目がない、API仕様と処理フローでエラーコードが異なる、といった矛盾は実装時の手戻りにつながります。

用語集、共通仕様、レビュー観点をそろえ、変更時には関連箇所を検索できる管理方法を採用します。

保守性とセキュリティを考慮する

短期的に実装できるかだけでなく、機能追加、障害調査、部品の更新、担当者交代を想定して設計します。

責任範囲を分け、依存関係を明確にし、設定値やログを運用しやすい形に整えてください。

セキュリティでは、扱う情報と想定する脅威を確認し、必要な認証、権限、暗号化、入力検証、監査ログを設計へ組み込みます。

すべてのシステムに同じ対策を置くのではなく、用途とリスクに応じて選びます。
設計段階で考慮すれば、後工程で構造から見直すリスクを抑えやすくなります。

出典：IPA「セキュリティバイデザインを標準とする、クラウドベースの開発プロセスの励行」

案件ごとの担当範囲を確認する

設計案件を選ぶときは、基本設計・詳細設計という工程名に加え、担当する機能、作成する成果物、レビュー相手、意思決定の範囲を確認します。

同じ「基本設計」でも、画面設計だけを担当する案件と、顧客調整から構成・非機能まで扱う案件では得られる経験が異なります。

応募時には、設計した対象、要件との対応、比較した選択肢、レビューで調整した内容を説明できるよう整理してください。

次に担当したい工程が決まっているなら、設計・上流工程を含む案件一覧で業務内容を比較すると、必要な経験を把握しやすくなります。

システム開発の設計工程では、要件を基本設計でシステム全体と外部仕様へ変換し、詳細設計で実装可能な内部仕様へ分解します。

名称や境界は案件で変わるため、設計項目、成果物、確認者、完了条件を基準に担当範囲を整理してください。

要件との対応、仕様間の整合性、変更履歴を保ち、実装・テスト・運用で利用できる設計を目指しましょう。