1.3.1. 全体開発スケジュール

1. 概要

　システム開発において、「全体開発スケジュール」はプロジェクト全体の計画を時間軸に沿って整理したものです。これは単なる工程表ではなく、プロジェクトの成功を左右する重要な戦略的ツールとなります。全体開発スケジュールは、システム化計画の立案段階で作成され、開発の方向性や範囲、期間、コストなどを明確にするものです。

　全体開発スケジュールの重要性は、以下の点にあります：

1. プロジェクト全体の見通しを提供する
2. リソース（要員、予算、設備など）の適切な配分を計画する
3. 各工程や作業間の依存関係を明確にする
4. プロジェクトの進捗管理の基準となる
5. リスク管理の基盤となる

2. 詳細説明

2.1. 全体開発スケジュールの目的

　全体開発スケジュールの主な目的は以下のとおりです：

1. プロジェクト全体の見える化
   • 開発の始点から終点までの全工程を視覚化することで、プロジェクト関係者の共通理解を促進します。
2. リソースの最適配分
   • 限られた要員や予算をいつ、どこに、どれだけ投入するかを計画します。
3. 進捗管理の基準設定
   • 実際の進捗と計画を比較することで、遅延やリスクを早期に発見できます。
4. 品質確保のための時間配分
   • テストや品質保証活動に十分な時間を確保することで、システムの品質を担保します。
5. 納期管理
   • 顧客との契約上の納期を守るための工程管理を可能にします。

2.2. 全体開発スケジュールの考え方

表1: 全体開発スケジュールの検討項目チェックリスト

2.2.1. サブシステム分割の考慮

　大規模なシステム開発では、システム全体を機能や目的に応じて複数のサブシステムに分割することが一般的です。全体開発スケジュールでは、これらのサブシステム間の関係性や開発順序を考慮する必要があります。

　サブシステム分割の際の考慮点：

• 機能的な独立性
• 技術的な依存関係
• 利用部門や業務フローとの関連性
• 開発リソースの効率的な配分

2.2.2. 優先順位付けの重要性

　限られたリソースの中で開発を進めるためには、機能や要件に優先順位を付けることが不可欠です。優先順位付けの基準としては以下が挙げられます：

• ビジネス上の重要度
• システム構成上の依存関係
• ユーザーニーズの緊急性
• 技術的な実現難易度
• リスクの大きさ

　優先順位の高い機能から順に開発を進めることで、プロジェクトの早い段階から価値を生み出すことができます。

2.2.3. 要員計画との連携

　全体開発スケジュールは、プロジェクトに必要な要員の数と質、そのタイミングを明確にします。以下の点を考慮して要員計画を立てます：

• 各工程で必要となる技術スキル
• ピーク時の要員数と平準化の可能性
• 外部リソースの活用タイミングと範囲
• 要員の教育・トレーニング期間

2.2.4. 納期管理のアプローチ

　納期を守ることはプロジェクト成功の重要な要素です。納期管理においては以下を考慮します：

• 契約上の納期制約
• 中間成果物の納品タイミング
• バッファ（余裕）の設定
• 納期リスクの特定と対策

2.2.5. 費用計画との整合性

　全体開発スケジュールは費用計画と密接に関連しています。スケジュールの各段階で必要となる費用を以下の観点から計画します：

• 人件費（内部要員・外部要員）
• ハードウェア・ソフトウェアの調達費用
• 設備・環境構築費用
• その他経費（トレーニング、旅費など）

2.2.6. 品質確保のための時間配分

　高品質なシステムを開発するためには、適切な品質保証活動を計画する必要があります：

• レビュー・インスペクションの実施タイミングと期間
• 各種テスト（単体・結合・システム・受入）の十分な期間確保
• 品質メトリクスの測定と評価のタイミング
• バグ修正のための余裕時間

2.2.7. クリティカルパスの特定と管理

　クリティカルパスとは、プロジェクトの最短完了時間を決定する一連の作業経路のことです。クリティカルパス上の作業が遅延すると、プロジェクト全体の納期に影響します。

　クリティカルパスの管理ポイント：

• クリティカルパス上の作業の特定
• クリティカルパス上の作業への重点的なリソース配分
• クリティカルパス上の作業の進捗管理の強化
• クリティカルパスの変化の監視と再評価

flowchart LR
    subgraph "ネットワーク図"
    A(開始) --> |3日| B(タスクA)
    A --> |2日| C(タスクB)
    B --> |4日| D(タスクC)
    C --> |6日| D
    B --> |5日| E(タスクD)
    D --> |2日| F(タスクE)
    E --> |1日| F
    F --> |2日| G(終了)
    end
    
    classDef critical fill:#ff6666,stroke:#333,stroke-width:2px;
    class A,B,D,F,G critical;
    
    subgraph "ガントチャート"
    direction TB
    H[開始] --- I[タスクA]
    J[タスクB] --- K
    I --- L[タスクC]
    K[.] --- L
    I --- M[タスクD]
    L --- N[タスクE]
    M --- N
    N --- O[終了]
    end
    
    style I fill:#ff6666,stroke:#333,stroke-width:2px;
    style L fill:#ff6666,stroke:#333,stroke-width:2px;
    style N fill:#ff6666,stroke:#333,stroke-width:2px;
    style H fill:#ff6666,stroke:#333,stroke-width:2px;
    style O fill:#ff6666,stroke:#333,stroke-width:2px;
    
    P[クリティカルパス] --- Q[最長経路: 開始→タスクA→タスクC→タスクE→終了]
    style P fill:#ff6666,stroke:#333,stroke-width:2px;
    style Q fill:#ff6666,stroke:#333,stroke-width:2px;

図1: クリティカルパスの概念図

2.3. スケジュール管理ツール

　全体開発スケジュールの作成・管理には、様々なツールが活用されています：

• Microsoft Project：ガントチャート作成やクリティカルパス分析に優れた業界標準ツール
  Microsoft Project for the web | プロジェクトをオンラインで管理
  PMIでも標準的なツールとして位置づけられています。
• Redmine：オープンソースのプロジェクト管理ツールで、チケット管理とガントチャート機能を提供
  Redmine.JP — オープンソースのプロジェクト管理ソフトウェア Redmine 日本語情報サイト
• Jira：アジャイル開発に適したタスク管理ツールで、かんばんボードやバーンダウンチャートに対応
  Jira | 課題 & プロジェクト管理ソフトウェア | Atlassian
• Trello：シンプルで直感的なタスク管理ができるカードベースのツール
  どこからでも To Do をキャプチャし、整理し、取り組むことができます | Trello
  導入しやすい直感的なツールです。
• Asana：チーム協業に適したプロジェクト管理ツール
  チームの仕事、プロジェクト、タスクをオンラインで管理 • Asana • Asana

　これらのツールを活用することで、スケジュールの視覚化、リソース配分の最適化、進捗の自動追跡などが可能になります。

3. 応用例

3.1. ウォーターフォールモデルでの全体開発スケジュール

　従来型のウォーターフォール開発では、要件定義から設計、実装、テスト、リリースまでの各フェーズを順次進めます。全体開発スケジュールの例：

1. 要件定義（2ヶ月）：業務分析、システム要件の明確化
2. 基本設計（3ヶ月）：システム全体の設計、サブシステム分割
3. 詳細設計（3ヶ月）：各機能の詳細設計
4. 実装（4ヶ月）：プログラミング、単体テスト
5. 結合テスト（2ヶ月）：モジュール間の連携確認
6. システムテスト（2ヶ月）：システム全体の動作確認
7. 受入テスト（1ヶ月）：ユーザーによる検証
8. 移行・リリース（1ヶ月）：本番環境への展開

　この例では、クリティカルパスは通常、メインとなるサブシステムの開発ラインになることが多く、そこに重点的にリソースを配分します。

3.2. アジャイル開発における全体開発スケジュール

　アジャイル開発では、短いイテレーション（スプリント）を繰り返しながらシステムを段階的に構築していきます。全体開発スケジュールの例：

1. プロダクトバックログ作成（2週間）：優先順位付けされた要件リストの作成
2. リリース計画（1週間）：主要マイルストーンの設定
3. スプリント（2週間×12回）：機能の実装とテスト
4. リリース準備（1週間）：ドキュメント整備、トレーニング
5. 本番リリース（1週間）：デプロイと初期サポート

　アジャイル開発では、各スプリントの中で優先順位の高い機能から実装していくため、早い段階からビジネス価値を生み出すことができます。

gantt
    title ウォーターフォールとアジャイルのスケジュール比較
    dateFormat MM
    axisFormat %m月
    
    section ウォーターフォール
    要件定義       :w1, 01, 2M
    基本設計       :w2, after w1, 2M
    詳細設計       :w3, after w2, 2M
    実装           :w4, after w3, 3M
    結合テスト     :w5, after w4, 1M
    システムテスト :w6, after w5, 1M
    受入テスト     :w7, after w6, 0.5M
    移行・リリース :w8, after w7, 0.5M
    
    section アジャイル
    プロダクトバックログ作成 :a1, 01, 0.5M
    リリース計画      :a2, after a1, 0.5M
    スプリント1（要件・設計） :a3, after a2, 1M
    スプリント2（設計・開発） :a4, after a3, 1M
    スプリント3（開発・テスト） :a5, after a4, 1M
    スプリント4（開発・テスト） :a6, after a5, 1M
    スプリント5（開発・テスト） :a7, after a6, 1M
    スプリント6（開発・テスト） :a8, after a7, 1M
    スプリント7（テスト・改善） :a9, after a8, 1M
    スプリント8（テスト・改善） :a10, after a9, 1M
    スプリント9（最終調整）   :a11, after a10, 1M
    リリース準備      :a12, after a11, 0.5M
    本番リリース      :a13, after a12, 0.5M

図2: ウォーターフォールとアジャイルのスケジュール比較

3.3. 大規模プロジェクトでのサブシステム分割と段階的リリース

　大規模なシステム開発では、システム全体をサブシステムに分割し、段階的にリリースすることがあります：

1. 共通基盤システム開発（6ヶ月）：認証、権限管理、ログ管理など
2. コアサブシステム開発（8ヶ月）：業務の中核となる機能
3. 周辺サブシステム開発（並行して6ヶ月）：補助的な機能
4. 外部システム連携（4ヶ月）：他システムとのインターフェース開発
5. 段階的リリース：
   • 第1フェーズ：共通基盤とコアサブシステムの一部
   • 第2フェーズ：コアサブシステムの残りと周辺サブシステムの一部
   • 第3フェーズ：全機能と外部システム連携

　この例では、サブシステム間の依存関係に基づいて優先順位付けし、クリティカルパスとなる共通基盤とコアサブシステムの開発に重点的に要員を配置します。

4. 例題

例題1

　あるECサイトのリニューアルプロジェクトについて考えます。以下の条件でプロジェクトの全体開発スケジュールを立案する際、クリティカルパスとなるのはどの工程の組み合わせですか？

条件：

• サブシステム：(A)会員管理、(B)商品管理、(C)注文管理、(D)決済管理
• 各サブシステムの開発期間：
  • (A)会員管理：3ヶ月
  • (B)商品管理：2ヶ月
  • (C)注文管理：4ヶ月
  • (D)決済管理：2ヶ月
• 依存関係：
  • (C)注文管理は(A)会員管理と(B)商品管理の完了後に開始可能
  • (D)決済管理は(C)注文管理の完了後に開始可能

flowchart LR
    start((開始)) --> A["(A)会員管理
3ヶ月"]
    start --> B["(B)商品管理
2ヶ月"]
    A --> C["(C)注文管理
4ヶ月"]
    B --> C
    C --> D["(D)決済管理
2ヶ月"]
    D --> finish((完了))
    
    classDef critical fill:#ff6666,stroke:#333,stroke-width:2px;
    classDef normal fill:#99ccff,stroke:#333,stroke-width:1px;
    
    class A,C,D,start,finish critical;
    class B normal;
    
    subgraph パス1["パス1:
9ヶ月 (クリティカルパス)"]
    E["(A)会員管理"] --> F["(C)注文管理"] --> G["(D)決済管理"]
    end
    
    subgraph パス2["パス2:
8ヶ月"]
    H["(B)商品管理"] --> I["(C)注文管理"] --> J["(D)決済管理"]
    end
    
    style パス1 fill:#ffeeee,stroke:#ff6666,stroke-width:2px;
    style パス2 fill:#eeeeff,stroke:#9999ff,stroke-width:1px;

図3: 例題1の依存関係図

例題2

　ある企業情報システムの開発において、限られた要員（システムエンジニア10名）を効率的に配置するための全体開発スケジュールを作成しています。以下の条件で、最適な要員配置と開発期間を検討してください。

条件：

• サブシステム：(X)人事給与、(Y)販売管理、(Z)在庫管理
• 各サブシステムの必要工数：
  • (X)人事給与：120人月
  • (Y)販売管理：150人月
  • (Z)在庫管理：90人月
• 優先順位：(Y)販売管理 > (Z)在庫管理 > (X)人事給与
• 納期制約：18ヶ月以内に全システムを稼働させる
• 品質目標：重大バグ0件でのリリース

5. まとめ

　全体開発スケジュールは、システム開発プロジェクトの成功に不可欠な計画ツールです。その主な目的は、プロジェクト全体の可視化、リソースの最適配分、進捗管理の基準設定、品質確保のための時間配分、納期管理にあります。

　全体開発スケジュールを立案する際の重要な検討項目として：

1. サブシステム分割による効率的な開発アプローチ
2. 機能や要件への適切な優先順位付け
3. 要員の適正配置と技術スキルの考慮
4. 納期制約の中での現実的な計画
5. 費用計画との整合性確保
6. 品質目標達成のための活動計画
7. クリティカルパスの特定と重点管理

　これらの要素を適切に検討し、バランスの取れた全体開発スケジュールを立案することで、プロジェクトのリスクを低減し、成功確率を高めることができます。実際のプロジェクトでは、不確実性やリスクに対応するためのバッファを設けることも重要です。

　最後に、全体開発スケジュールは固定的なものではなく、プロジェクトの進行に応じて定期的に見直し、必要に応じて調整していくことが、成功への鍵となります。