システムの開発工程について学ぼう！-第2回 基本設計-

0. この記事について

私自身が「要件定義からリリースまでの工程を学びたい！」と思いまとめているものです。

第2回として、要件定義(第1回)の次の作業となる
「基本設計」 について整理していきます！

今回まとめたことを、実践可能になることが目標で、未熟な点多々あるかと思います。
日々ブラッシュアップして参りますため、
改善点など、是非ご教示いただけますと幸いです。
よろしくお願いします！

表などはスマホだと絶望的に見にくいので折り畳んだりした方が良さそう…

0. 目次

1. 実施要否の確認表
   1.1. 工程選択の考え方
2. 各工程の詳細
   1. 要件の再確認と整理
   2. システム方式設計
   3. 機能分割・構成設計
   4. 画面設計
   5. 帳票設計
   6. データベース設計（論理）
   7. ファイル設計
   8. バッチ処理設計
   9. 外部インターフェース設計
   10. セキュリティ設計
   11. 非機能要件の実現方式検討
   12. 運用・保守設計
   13. 成果物の作成とレビュー

1. 実施要否の早見表

基本設計について調べましたが、
工程全容(一覧)がわからず、結局どこからどう進めたらいいの？と感じました。
そのため、工程一覧と、その選択（各工程をどのような条件で実施するのか）
を以下のように表にまとめてました。

実施可否の早見表

No	工程名	必須	システムの構成要素・特性
			画面	帳票	DB管理	ファイルI/O	バッチ処理	外部連携	運用保守
1	要件の再確認と整理	◎
2	システム方式設計	◎
3	機能分割・構成設計	◎
4	画面設計		○
5	帳票設計			○
6	データベース設計（論理）				○
7	ファイル設計					○
8	バッチ処理設計						○
9	外部インターフェース設計							○
10	セキュリティ設計	◎
11	非機能要件の実現方式検討	◎
12	運用・保守設計								○
13	成果物の作成とレビュー	◎

表の見方:

• No(実施順): 各工程の一般的な実施順の目安。プロジェクトにより前後あり
• ◎ (基本的に必須): プロジェクトの特性にかかわらず、通常は必ず実施
• ○ (条件付き): その列のヘッダー記載の項目（画面/バッチ処理など）を管理する場合、工程を実施
• 空欄: 通常その条件ではその工程は実施されない

1.1. 工程選択の考え方

• 必須工程（ほぼ全ての案件で実施）: 1, 2, 3, 6(データがある場合), 10, 11, 13
• 条件により必須となる工程:
  • 画面がある場合: 4
  • 帳票がある場合: 5
  • ファイルI/Oがある場合: 7
  • バッチ処理がある場合: 8
  • 外部連携がある場合: 9
  • 運用・保守が重要視される場合: 12
• 努力目標/推奨工程（実施することで品質向上）: 各工程の深掘り、代替案の比較検討、PoCの実施など。
• 不要な工程（該当機能がない場合）: 例えば、Web APIのみのシステムであれば画面設計(4)や帳票設計(5)は不要になる可能性があります。

2. 各工程の詳細

1. 要件の再確認と整理 (Requirement Reconfirmation and Organization)

• 目的: 要件定義の成果物（要件定義書、機能一覧、非機能要件一覧など）の内容を正確に理解し、基本設計を進める上での前提条件や不明点を明確にする
• 主な作業内容:
  • 要件定義書、議事録などの内容理解
  • 機能要件、非機能要件について、設計担当者間での認識合わせ
  • 要件の曖昧な点、矛盾点、不足点を洗い出し、要件定義担当者や顧客に確認
  • 基本設計を進める上での制約条件（技術的制約、予算、期間など）を再確認
• 考慮点: 本工程での認識齟齬は、後工程での大きな手戻りの原因となるため、疑問点は必ず解消しておくことが重要

2. システム方式設計 (System Architecture Design)

• 目的: システム全体の実現方式、基本的な構造（アーキテクチャ）を決定する。技術的な基盤を選定し、後続の設計の拠り所とする
• 主な作業内容:
  • システム構成（ハードウェア、ソフトウェア、ネットワーク）の概要を決定する（例：クライアントサーバ型/Web3層構造/マイクロサービスアーキテクチャなど）
  • 主要な技術要素（OS、プログラミング言語、フレームワーク、ミドルウェア、DBMSなど）の選定または方針を決める
  • 開発標準、コーディング規約などの適用方針の決定
  • 必要に応じて、技術的な実現可能性の検証（PoC: Proof of Concept）を実施
• 考慮点: 非機能要件（性能、可用性、セキュリティなど）を考慮した方式選定が重要。また、既存システムとの連携や将来的な拡張性も視野に入れる

3. 機能分割・構成設計 (Functional Decomposition / Component Design)

• 目的: システムが持つべき機能を、より管理しやすい単位（サブシステム、モジュール、コンポーネントなど）に分割し、それぞれの役割と責務を定義する
• 主な作業内容:
  • 機能一覧に基づき、関連性の高い機能をグルーピングする
  • システムの主要な構成要素とその関係性を図示する（機能構成図、モジュール構成図など）
  • 各構成要素（モジュール）が担当する機能や責務を明確にする
• 考慮点: モジュール間の依存度を適切に保ち、変更の影響範囲を局所化できるように分割することが望ましい（凝集度を高め、結合度を低くする）

4. 画面設計 (Screen Design)

• 目的: 利用者がシステムを操作するためのインターフェース（画面）の構成、遷移、レイアウトの概要を設計する
• 主な作業内容:
  • 画面一覧作成: システムに必要な画面をすべて洗い出す
  • 画面遷移設計: 利用者の操作の流れに沿って、画面間の遷移関係を図示する（画面遷移図）
  • 画面レイアウト設計: 主要な画面について、表示項目、入力項目、ボタンなどの配置や構成を大まかに定義する（ワイヤーフレーム、モックアップ）。詳細なデザインではなく、要素の配置や種類を定義する
• 考慮点: 利用者の操作性（ユーザビリティ）、業務フローとの整合性を考慮。要件定義で作成された業務フローやプロトタイプがあれば参考にする

5. 帳票設計 (Report Design)

• 目的: システムが出力する帳票（紙やファイル）のレイアウトや出力条件を設計する
• 主な作業内容:
  • 帳票一覧作成: システムが出力する帳票をすべて洗い出す
  • 帳票レイアウト設計: 各帳票の出力項目、配置、計算式、出力形式（PDF, Excel, CSVなど）を定義する
  • 出力条件（データ抽出条件、出力タイミングなど）を定義する
• 考慮点: 法的な要件や顧客の指定様式がある場合はそれに準拠します。データ量や出力頻度も考慮します

6. データベース設計（論理） (Logical Database Design)

• 目的: システムで扱うデータを、特定のDBMSに依存しない形で構造化し、管理方法を定義する
• 主な作業内容:
  • エンティティ抽出・関連定義: システムで管理すべき情報の単位（エンティティ）を洗い出し、それらの関連性を定義する（ER図の作成）
  • 属性定義: 各エンティティが持つべき情報項目（属性）を洗い出し、データ型（文字、数値、日付など）、桁数、制約（必須、一意など）の概要を定義する（テーブル定義書の作成）。正規化を行い、データの冗長性を排除する
  • 主キー、外部キーなどの関係性を定義する
• 考慮点: データの整合性、拡張性、検索効率などを考慮して設計します。物理設計（インデックスなど）は詳細設計で行いますが、論理設計の段階で性能面も意識しておくことが重要です。

7. ファイル設計 (File Design)

• 目的: システム間で受け渡すファイルや、バッチ処理などで使用するファイルのフォーマット（レコードレイアウト）を定義する
• 主な作業内容:
  • ファイル一覧作成: システムで使用するファイルを洗い出す。
  • ファイルレイアウト定義: 各ファイルのレコード形式、項目名、データ型、桁数、文字コードなどを定義する
  • ファイル命名規則、受け渡し方法などを定義する。
• 考慮点: 連携先システムとの仕様調整が必要です。データ量や処理頻度に応じて適切なフォーマットを選定します

8. バッチ処理設計 (Batch Processing Design)

• 目的: 定期的に実行される、あるいは大量データを一括処理するバッチ処理の方式、処理フロー、ジョブ構成などを設計する
• 主な作業内容:
  • 処理フロー設計: バッチ処理全体の流れ、ステップを図示する。
  • ジョブ設計: 処理をジョブ（実行単位）に分割し、ジョブ間の依存関係や実行順序を定義する（ジョブネットワーク図）
  • 入力データ、出力データ、処理ロジックの概要を定義する。
  • 異常時の処理（リトライ、エラー通知など）や再実行の方式を定義する。
  • 実行スケジュール、処理時間目標などを定義する。
• 考慮点: エラーハンドリング、リカバリ、性能（処理時間）、運用監視のしやすさを考慮します。

9. 外部インターフェース設計 (External Interface Design)

• 目的: 他のシステムやサービスと連携するための方式やデータ形式を定義する。
• 主な作業内容:
  • 連携方式（API、ファイル連携、DB連携、メッセージキューなど）を決定する。
  • 利用するAPIのエンドポイント、リクエスト/レスポンス形式、認証方式などを定義する。
  • 連携するデータの項目、形式、マッピングルールを定義する。
  • 連携時のエラーハンドリング方式を定義する。
  • 連携シーケンス（呼び出し順序）を図示する（シーケンス図など）。
• 考慮点: 連携先システムの仕様確認が不可欠です。同期/非同期、リアルタイム性、セキュリティなどを考慮します

10. セキュリティ設計 (Security Design)

• 目的: システムのセキュリティ要件（機密性、完全性、可用性）を満たすための基本的な対策や方式を設計する
• 主な作業内容:
  • 認証方式（ID/パスワード、多要素認証など）を決定する
  • 認可方式（アクセス制御、権限管理）の概要を設計する
  • データの暗号化（通信経路、保存データ）の方針を決定する
  • 不正アクセス対策（ファイアウォール、WAF、入力チェックなど）の概要を検討する
  • セキュリティログの取得方針を決定する
• 考慮点: プロジェクトのセキュリティポリシーやガイドラインに準拠します。脅威分析を行い、リスクに応じた対策を検討します

11. 非機能要件の実現方式検討 (Designing for Non-Functional Requirements)

• 目的: 性能、可用性、拡張性、運用性、保守性などの非機能要件を実現するための具体的な方式やアーキテクチャ上の考慮点を明確にする
• 主な作業内容:
  • 性能: 目標性能値（レスポンスタイム、スループット）を達成するための方式（キャッシュ、非同期処理、負荷分散など）を検討する
  • 可用性: 目標稼働率を達成するための方式（冗長化、フェイルオーバー、バックアップ/リストア）を検討する
  • 拡張性: 将来的なデータ量やアクセス数の増加に対応できる構成（スケールアウト/スケールアップの容易さ）を検討する
  • 運用・保守性: ログ設計、監視設計、設定変更の容易さ、障害解析のしやすさなどを考慮した設計を行う
• 考慮点: 非機能要件はシステム全体に関わるため、方式設計や各詳細設計項目と密接に関連します。トレードオフ（例：性能とコスト）を考慮して最適な方式を選択します

12. 運用・保守設計 (Operations & Maintenance Design)

• 目的: システム稼働後の運用（起動・停止、監視、バックアップなど）や保守（障害対応、メンテナンス）に必要な事項を設計する
• 主な作業内容:
  • システム起動・停止手順の概要を定義する
  • 監視項目（リソース使用率、エラー発生、プロセス稼働状況など）と監視方法の概要を定義する
  • バックアップ対象、方式、スケジュール、リストア手順の概要を定義する
  • ログの収集・管理方法を定義する
  • メンテナンス手順（リリース手順など）の概要を検討する
• 考慮点: 非機能要件の一部とも重なりますが、より運用者の視点に立った具体的な手順や方法論を検討します

13. 成果物の作成とレビュー (Deliverable Creation and Review)

• 目的: 上記工程で決定した事項をドキュメント（基本設計書）としてまとめ、関係者間でレビューを行い、内容の妥当性、整合性、網羅性を確認し、承認を得る
• 主な作業内容:
  • これまで検討・設計した内容を、規定されたフォーマットに従ってドキュメント化する（システム構成図、画面遷移図、ER図、テーブル定義書、インターフェース定義書など）
  • 設計者間での内部レビューを実施する
  • 開発リーダー、プロジェクトマネージャー、場合によっては顧客や運用担当者などを交えて公式レビューを実施する
  • レビューでの指摘事項を反映し、ドキュメントを修正・完成させる
• 考慮点: レビュー観点（要件との整合性、設計標準の遵守、実現可能性、後工程への情報伝達の十分性など）を明確にして実施することが重要です