プロジェクトの流れ

プロジェクトの流れとは

SIer のプロジェクトは、顧客への営業・提案に始まり、要件定義、設計、実装、テスト、リリースを経て、運用・保守に至る一連のフェーズで構成される。特にウォーターフォール型の開発プロセスでは、各フェーズを順番に完了させていくことが基本となる。ここではプロジェクト全体の流れを俯瞰的に解説する。

基本概念

フロー図

SIer のプロジェクトの典型的な流れを以下に示す。

営業・提案 → 要件定義 → 基本設計 → 詳細設計 → 実装 → テスト → リリース → 運用・保守
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[営業・提案]  顧客の課題をヒアリングし、提案書・見積もりを作成
     │
     ▼
[要件定義]    「何を作るか」を決める ── 業務要件、機能要件、非機能要件
     │
     ▼
[基本設計]    「どう作るか」の大枠を決める ── 画面、DB、インターフェース
     │
     ▼
[詳細設計]    プログラムレベルの設計 ── クラス図、シーケンス図、処理仕様
     │
     ▼
[実装]        詳細設計に基づいてコーディング + 単体テスト
     │
     ▼
[テスト]      結合テスト → 総合テスト → ユーザー受入テスト
     │
     ▼
[リリース]    本番環境へのデプロイ、データ移行、切り替え
     │
     ▼
[運用・保守]  監視、障害対応、改修、問い合わせ対応

各フェーズの概要

営業・提案

顧客企業の課題やニーズをヒアリングし、システム化による解決策を提案する。提案書、概算見積もり、プロジェクト計画の概要を作成し、受注を目指す。コンペ（競合他社との提案競争）になることも多い。

• 主に関わる職種: 営業、PM、SE（上級）
• 成果物: 提案書、概算見積書

要件定義

「何を作るか」を明確にするフェーズ。顧客の業務フローを分析し、システムに求められる機能（機能要件）と、性能・セキュリティ・可用性などの条件（非機能要件）を文書化する。プロジェクトの成否を左右する最も重要なフェーズとされる。

• 主に関わる職種: PM、SE
• 成果物: 要件定義書、業務フロー図、機能一覧

基本設計（外部設計）

要件定義の内容をもとに、「どう作るか」の大枠を設計する。画面レイアウト、データベースのテーブル構成、外部システムとのインターフェース、システム全体のアーキテクチャなどを決定する。顧客がレビューに参加するため「外部設計」とも呼ばれる。

• 主に関わる職種: SE、インフラエンジニア
• 成果物: 画面設計書、DB 設計書（ER 図）、インターフェース設計書、アーキテクチャ設計書

詳細設計（内部設計）

基本設計をプログラマーが実装できるレベルまで具体化する。処理ロジックの詳細、クラス構成、メソッドの入出力仕様、エラー処理の方針などを設計する。顧客には通常公開しないため「内部設計」とも呼ばれる。

• 主に関わる職種: SE、PG（上級）
• 成果物: 詳細設計書、クラス図、シーケンス図、処理フロー図

実装（製造）

詳細設計書に基づいてプログラムをコーディングし、単体テスト（ユニットテスト）を実施する。SIer では「製造」「製造工程」と呼ばれることが多い。コーディング規約に従った実装と、テストエビデンス（証跡）の作成が求められる。

• 主に関わる職種: PG
• 成果物: ソースコード、単体テスト仕様書、単体テストエビデンス

テスト

実装したプログラムを組み合わせて、システム全体が正しく動作するかを段階的に確認する。SIer のテストは通常、以下の段階で行われる。

• 主に関わる職種: テストエンジニア（QA）、SE、PG
• 成果物: テスト計画書、テストケース、テスト結果報告書

リリース（本番移行）

テストを完了したシステムを本番環境にデプロイする。既存システムからの移行がある場合は、データ移行や並行運用期間の設定など、慎重な計画が必要となる。リリース当日は関係者が待機し、問題発生時の切り戻し手順も事前に準備する。

• 主に関わる職種: PM、SE、インフラエンジニア
• 成果物: 移行計画書、リリース手順書、切り戻し手順書

運用・保守

リリース後のシステムを安定的に稼働させるフェーズ。システム監視、障害対応、ユーザーからの問い合わせ対応、法改正や業務変更に伴う改修などを継続的に行う。プロジェクトの中で最も期間が長いフェーズであり、SIer にとっては安定した収益源となる。

• 主に関わる職種: 運用・保守担当、SE、インフラエンジニア
• 成果物: 運用手順書、監視設計書、障害報告書

SIer での実態

典型的なプロジェクト期間

プロジェクトの規模によって大きく異なるが、目安は以下の通り。

これに加えて運用・保守フェーズが数年〜十数年続くことも珍しくない。基幹系システムの中には 20 年以上運用されているものもある。

フェーズごとの工数配分

一般的なウォーターフォール型プロジェクトにおける工数配分の目安を以下に示す（プロジェクトの特性により変動する）。

テストの工数比率が最も大きいことに注目してほしい。SIer のプロジェクトでは品質に対する要求が高く、テスト工程に全体の 4 分の 1 以上の工数を割くことが一般的である。

ドキュメント文化

SIer のプロジェクトでは、各フェーズで大量のドキュメント（設計書、テスト仕様書、議事録、課題管理表など）が作成される。これはウォーターフォール型開発において、前のフェーズの成果物が次のフェーズのインプットとなるためである。また、顧客への説明責任や、メンバー交代時の引き継ぎ、監査対応（特に金融系）のためにも、ドキュメントの整備が重視される。

新入社員がまず驚くのがこのドキュメントの量であることも多い。設計書のフォーマットや記載ルールはプロジェクトごとに定められており、これに従って正確に記述するスキルが求められる。

まとめ

• SIer のプロジェクトは営業・提案から運用・保守まで、8 つのフェーズで構成される
• 要件定義はプロジェクトの成否を左右する最重要フェーズであり、「何を作るか」を明確にする
• テスト工程は全体工数の 4 分の 1 以上を占め、品質への要求が高い
• プロジェクト期間は小規模で 3〜6 ヶ月、大規模では数年に及ぶ
• 各フェーズで大量のドキュメントが作成され、ドキュメントの作成・管理スキルが重要となる