ホーム
テクノロジ系
D. 開発技術
ⅩⅡ. システム開発技術
2. 設計

2.1. システム設計のタスク

1. 概要

　システム設計は、ソフトウェア開発プロセスにおいて極めて重要な段階です。この段階では、要件定義で明確にされた機能要件と非機能要件を基に、システムの全体構造や詳細な仕様を決定します。システム設計のタスクを適切に実施することで、効率的で信頼性の高いシステムを構築する基盤が整います。特に、パフォーマンス、セキュリティ、拡張性などの非機能要件は、長期的なシステムの安定運用に直接影響を与えるため、慎重な設計が求められます。

2. 詳細説明

2.1. システム設計

　システム設計では、以下の主要な作業が行われます：

  • アーキテクチャ設計：システム全体の構造を決定します。モノリシックな構造とするか、マイクロサービスアーキテクチャを採用するかなど、設計方針を定めます。
  • サブシステム設計：システム内の各コンポーネントやモジュールの詳細設計を行います。各サブシステムの役割や機能を明確にし、どのように連携するかを定義します。ここで、UML図やフローチャートを使用することが一般的です（例：図1にフローチャートを示す）。
  • インターフェース設計：各コンポーネント間の連携方法（インターフェース）を定義します。APIの設計や、異なるサブシステム間のデータのやり取り方法を決定します。ここでは、データフォーマットや通信プロトコルの選定も重要です。
  • データベース設計：データ構造とデータ操作方法を定義します。正規化によるデータの整理や、適切なインデックス設計により、効率的なデータアクセスを確保します（例：図2にデータベース設計の例を示す）。
graph TD
    A[開始] --> B[要件分析]
    B --> C{スケーラビリティ要件?}
    C -->|高い| D[マイクロサービスアーキテクチャ検討]
    C -->|低い| E[モノリシックアーキテクチャ検討]
    D --> F{セキュリティ要件?}
    E --> F
    F -->|高い| G[多層アーキテクチャ採用]
    F -->|標準| H[シンプルな3層アーキテクチャ採用]
    G --> I[コンポーネント定義]
    H --> I
    I --> J[インターフェース設計]
    J --> K[データフロー設計]
    K --> L[テクノロジースタック選定]
    L --> M[アーキテクチャ文書作成]
    M --> N[レビュー実施]
    N --> O{承認?}
    O -->|Yes| P[終了]
    O -->|No| Q[フィードバック反映]
    Q --> I

図1：システムのアーキテクチャ設計におけるフローチャート

erDiagram
    USERS ||--o{ ORDERS : places
    ORDERS ||--|{ ORDER_ITEMS : contains
    PRODUCTS ||--o{ ORDER_ITEMS : "included in"

    USERS {
        int user_id PK
        string username
        string email
        string password_hash
    }

    PRODUCTS {
        int product_id PK
        string name
        string description
        decimal price
    }

    ORDERS {
        int order_id PK
        int user_id FK
        date order_date
        decimal total_amount
        string status
    }

    ORDER_ITEMS {
        int order_item_id PK
        int order_id FK
        int product_id FK
        int quantity
        decimal price
    }

図2：データベース設計の例（テーブル構造や正規化の図）

2.2. 利用者文書（暫定版）の作成

　システムの利用者向けに、以下のような文書を作成します：

  • ユーザーマニュアル：システムの操作方法や機能の使い方を、利用者向けにわかりやすく説明します。
  • 運用マニュアル：システムの運用や保守に関する手順や注意事項をまとめた文書です。特に、システム障害発生時の対応方法や、バックアップ・リカバリ手順を詳細に記載します。
  • トレーニング資料：システムを使用するユーザー向けに、教育目的で作成される資料です。これには、動画やスライド、ハンズオン形式の指導資料が含まれます。

2.3. システム設計の評価

　システム設計が正確かつ効率的に行われているかを確認するため、以下の観点から評価を行います：

  • 機能要件の充足度：すべての機能要件が設計に組み込まれているかを確認します。
  • 非機能要件の充足度：システムの処理速度やセキュリティ対策、拡張性といった非機能要件が適切に満たされているかを評価します。例えば、パフォーマンステストやセキュリティ診断がこれに該当します。
  • 設計の一貫性と整合性：設計全体が一貫性を保ち、サブシステム間で矛盾がないかを確認します。
  • コスト効率性：設計が開発や運用コストに見合ったものであるか、無駄がないかを検討します。特に、スケーラビリティを考慮しつつコストを抑える工夫が重要です。

2.4. システム設計の共同レビュー

　設計の妥当性を確認するため、関係者を交えたレビューを行います。このプロセスは設計のクオリティを確保する上で非常に重要です。以下の関係者が参加します：

  • プロジェクトマネージャー
  • システムアーキテクト
  • 開発チームリーダー
  • 品質保証担当者
  • ユーザー代表 　共同レビューでは、各メンバーが異なる視点から設計の妥当性や改善点を指摘します。特に、ユーザー代表やUX専門家が参加することで、ユーザー目線でのフィードバックが得られ、システムの使いやすさが向上します（例：図3に共同レビューのフローチャートを示す）。
flowchart TD
    A[開始] --> B[プロジェクトマネージャー: レビュー計画作成]
    B --> C[システムアーキテクト: 設計文書配布]
    C --> D[全員: 事前レビュー実施]
    D --> E{プロジェクトマネージャー: レビュー会議開催}
    E --> F[システムアーキテクト: 設計概要説明]
    F --> G[開発チームリーダー: 技術的観点からのレビュー]
    G --> H[品質保証担当者: 品質基準との整合性確認]
    H --> I[ユーザー代表: ユーザビリティ評価]
    I --> J{プロジェクトマネージャー: 議論とフィードバック集約}
    J -->|修正必要| K[システムアーキテクト: 設計修正]
    K --> L[品質保証担当者: 修正内容の確認]
    L --> M{プロジェクトマネージャー: 再レビュー必要?}
    M -->|はい| E
    M -->|いいえ| N[プロジェクトマネージャー: レビュー結果のまとめ]
    J -->|承認| N
    N --> O[開発チームリーダー: 次フェーズの計画立案]
    O --> P[終了]

    classDef pm fill:#f9d5e5,stroke:#333,stroke-width:2px;
    classDef architect fill:#eeac99,stroke:#333,stroke-width:2px;
    classDef leader fill:#e06377,stroke:#333,stroke-width:2px;
    classDef qa fill:#c83349,stroke:#333,stroke-width:2px;
    classDef user fill:#5b9aa0,stroke:#333,stroke-width:2px;
    classDef all fill:#d6e5fa,stroke:#333,stroke-width:2px;

    class B,E,J,M,N pm;
    class C,F,K architect;
    class G,O leader;
    class H,L qa;
    class I user;
    class D all;

図3：共同レビューのフローチャート（各メンバーの役割を示す）

3. 応用例

3.1. 大規模ECサイトの設計

　大手小売企業のECサイトリニューアルプロジェクトでは、システム設計が以下のように適用されました：

  • システム設計：マイクロサービスアーキテクチャを採用し、各機能が独立してスケーラブルに動作するように設計しました。
  • 利用者文書：カスタマーサポート向けの新機能操作マニュアルを作成し、クレーム対応や返品処理の迅速化を図りました。
  • 設計評価：負荷テストを実施し、1日あたりのピークアクセスにも耐えられるパフォーマンスを確認しました。
  • 共同レビュー：UX専門家を交えた設計レビューを行い、ユーザーインターフェースの改善点が反映されました。

3.2. 金融機関の基幹システム更新

　大手銀行の基幹システム更新プロジェクトでは、以下のようにシステム設計のタスクが適用されました：

  • システム設計：レガシーシステムから新システムへの段階的な移行計画を立案し、運用停止リスクを最小限に抑えました。
  • 利用者文書：新旧システムの並行運用手順書を作成し、運用スタッフへの教育を効率的に行いました。
  • 設計評価：セキュリティ専門家によるリスク評価を実施し、金融システム特有の高いセキュリティ要件を満たしました。
  • 共同レビュー：監査部門を交えたコンプライアンスチェックを実施し、法規制への適合性を確認しました。

4. 例題

例題1：

　あるシステム開発プロジェクトで、システム設計のタスクの一つである「利用者文書（暫定版）の作成」を行う際に含めるべき文書として、最も適切なものはどれか。

a) プロジェクト計画書
b) ユーザーマニュアル
c) ソースコード
d) テスト仕様書

回答例：
　正解は b) ユーザーマニュアル です。
　利用者文書（暫定版）の作成では、システムの利用者向けの文書を作成します。ユーザーマニュアルは、システムの使用方法を説明する文書であり、利用者文書の代表的な例です。

例題2：

　システム設計の評価において、以下の項目のうち、非機能要件の充足度を評価する観点として最も適切なものはどれか。

a) ユーザーインターフェースの使いやすさ
b) システムの処理速度
c) 実装するべき機能の網羅性
d) プログラミング言語の選択

回答例：
　正解は b) システムの処理速度 です。
　システムの処理速度は、典型的な非機能要件の一つであり、システムのパフォーマンスに直結する重要な評価観点です。

5. まとめ

　システム設計のタスクは、効果的なシステム開発を行う上で不可欠なプロセスです。主要なタスクとして、アーキテクチャ設計、サブシステム設計、インターフェース設計、データベース設計、利用者文書の作成、システム設計の評価、共同レビューがあります。これらのタスクを適切に実施することで、要件を満たし、品質の高いシステムを効率的に開発することが可能となります。応用情報処理技術者を目指す方々は、これらのタスクの重要性を理解し、実践的なスキルを身につけることが求められます。