コンテンツにスキップ
Process Compass（プロセスコンパス）

ウォーターフォール開発プロセス(日本の SIer 標準形)

既存プロセスの体系 ／ 種別: ライフサイクルプロセス(開発の全工程)

要件定義から受入まで工程を一方向に直列に並べ、各工程末の完了判定(レビュー・審査)を通過してから次工程へ進む開発プロセスモデル

ひとことで言うと: 工程を一列に並べ、各工程の終わりに「できたか」の審査を通ってから次へ進む進め方。日本では審査が契約の区切り(検収)を兼ねる

全体マップ(第1階層)

各フェーズをクリックすると、フェーズ内のワークフロー(第2階層)へ移動します。

graph LR
  ph0["要件定義"]
  ph1["基本設計(外部設計)"]
  ph0 -->|"G1 要件定義完了判定"| ph1
  ph2["詳細設計(内部設計)"]
  ph1 -->|"G2 基本設計完了判定"| ph2
  ph3["製造(コーディング)"]
  ph2 -->|"G3 詳細設計完了判定"| ph3
  ph4["単体テスト(UT)"]
  ph3 --> ph4
  ph5["結合テスト(IT)"]
  ph4 -->|"G4 製造・単体テスト完了判定"| ph5
  ph6["総合テスト(ST)"]
  ph5 -->|"G5 結合テスト完了判定"| ph6
  ph7["受入・リリース"]
  ph6 -->|"G6 総合テスト完了判定 / G7 出荷判定"| ph7
  gEnd{"G8 検収(受入判定)"}
  ph7 --> gEnd
  click ph0 "/process-compass/processes/waterfall/requirements/" "要件定義の詳細へ"
  click ph1 "/process-compass/processes/waterfall/basic-design/" "基本設計(外部設計)の詳細へ"
  click ph2 "/process-compass/processes/waterfall/detailed-design/" "詳細設計(内部設計)の詳細へ"
  click ph3 "/process-compass/processes/waterfall/coding/" "製造(コーディング)の詳細へ"
  click ph4 "/process-compass/processes/waterfall/unit-test/" "単体テスト(UT)の詳細へ"
  click ph5 "/process-compass/processes/waterfall/integration-test/" "結合テスト(IT)の詳細へ"
  click ph6 "/process-compass/processes/waterfall/system-test/" "総合テスト(ST)の詳細へ"
  click ph7 "/process-compass/processes/waterfall/acceptance/" "受入・リリースの詳細へ"

目的と成果

目的(purpose): 大規模・多人数・受発注構造の開発において、工程と成果物を直列に固定し、各工程末の完了判定で品質と契約責任を確定させながら計画どおりにシステムを完成させる

成果(outcomes):

  • 各工程の承認済み成果物一式(要件定義書〜テスト成績書)が揃っている
  • 工程ごとの完了判定・検収の記録が残っている
  • 検収合格により契約上の債務履行が確定している
  • 保守へ引き継ぎ可能な文書群が残っている

原典: 通説上の原典は Royce 1970。ただし原典は逐次一発勝負を「リスキーで失敗を招く」と警告し、反復(Do it twice)と継続的顧客関与を推奨していた。「waterfall」の語は Bell & Thayer 1976 が初出、制度化は DOD-STD-2167(1985)

ISO/IEC/IEEE 12207 対応: 主に「テクニカル(要件定義〜検証・妥当性確認を中心にカバー。日本では共通フレーム(SLCP-JCF)が語彙基盤)」プロセス群をカバー

ロール

ロール責任日本の現場での実態
PM(プロジェクトマネージャ)プロジェクト執行責任者。顧客折衝・納期取り決め・トラブル対応指揮・工程管理中小規模では PL を兼務。元請け側に置かれる
PL(プロジェクトリーダー)現場責任者。設計・製造の進捗管理小規模プロジェクトでは置かれない
SE(システムエンジニア)要件定義・設計など上流工程を担当し、機能・性能を決定上流専任は元請けに集中。設計と製造管理の兼務が多い
PG(プログラマー)SE の設計に沿った実装(下流工程)多重下請け構造では二次請け以下へ発注されがち
品質保証部門(QA)プロセス品質とプロダクト品質の両面を評価し、品質ゲート(計画審査・工程終了審査・出荷判定)を運営プロジェクトから組織上独立した部門として大手に存在。判定権限の強さは会社により差がある
顧客側レビュアー(ユーザ企業)要件定義・基本設計の承認、受入テスト・検収の実施。連絡協議会での意思決定業務部門が多忙でレビューが形式化しやすい

ゲート(決裁・レビュー)

ゲート種別Deliverables判定基準判定者判定結果
G0 計画審査 ※プロジェクト開始前に実施(フェーズ図には表示されない)決裁(Go/Kill)プロジェクト計画書 / 品質計画計画の実現性 / 体制・リスクの妥当性QA部門+事業部門長承認 / 条件付き承認 / 差し戻し
G1 要件定義完了判定決裁(Go/Kill)要件定義書要件の合意(利害関係者の識別・評価・合意タスクの完了) / スコープ確定顧客+PM(連絡協議会)承認(次工程契約へ) / 差し戻し
G2 基本設計完了判定決裁(Go/Kill)基本設計書要件定義書との整合 / 外部仕様の顧客合意顧客+PM承認 / 差し戻し
G3 詳細設計完了判定決裁(Go/Kill)詳細設計書基本設計書との無矛盾 / コーディング可能な粒度 / レビュー完了PL/PM(+QA)。ベンダ内承認 / 差し戻し
G4 製造・単体テスト完了判定決裁(Go/Kill)ソースコード / 単体テスト成績コードレビュー・静的解析の実施 / 予定テストの完了 / バグ密度が基準内PL(+QA)承認 / 差し戻し
G5 結合テスト完了判定決裁(Go/Kill)結合テスト成績書テスト消化率・残バグ件数が基準内PM(+QA)承認 / 差し戻し
G6 総合テスト完了判定決裁(Go/Kill)システムテスト成績書 / 品質報告非機能要件の充足 / 残存リスクの評価PM+QA承認 / 差し戻し
G7 出荷判定決裁(Go/Kill)全成果物+品質エビデンスプロセス品質・プロダクト品質の総合評価QA部門長(組織上独立した判定)出荷可 / 出荷不可
G8 検収(受入判定) ※期間内に通知がない場合は「みなし検収」で合格扱いになる決裁(Go/Kill)検査仕様書に基づく検査結果 / 検収書契約・仕様との適合(民法改正後は契約不適合責任の起点)顧客合格(債務履行確定) / 不合格(修補請求等)

成果物(information items)

成果物作成者説明
要件定義書SE(システムエンジニア)基本設計のインプット。受入テストの検証基準。準委任契約の成果物
基本設計書(外部設計書)SE(システムエンジニア)画面・帳票・インタフェース・DB論理設計。総合テストの検証基準。顧客承認対象
詳細設計書(内部設計書)SE(システムエンジニア)モジュール仕様・物理DB。結合テストの検証基準
ソースコード・実行モジュールPG(プログラマー)単体テスト以降のテスト対象
テスト仕様書(単体/結合/システム各層)SE(システムエンジニア)V字で対応する設計書から導出される実施基準
テスト成績書・品質報告PL(プロジェクトリーダー)テスト密度・バグ密度等。工程終了審査・出荷判定のエビデンス
検査仕様書・検収書顧客側レビュアー(ユーザ企業)検収の判定基準と記録。みなし検収条項あり
操作マニュアル・移行手順書SE(システムエンジニア)受入・教育・本番移行、保守への引き継ぎ

建前と実運用(日本の現場)

  • 工程末ゲートは品質判定と契約の区切り(準委任→請負の切り替え、検収)を兼ねる。日本の標準形の本質は開発モデルというより契約モデル
  • 工程完了判定が日程優先で「条件付き通過」の連発になり、品質ゲートが通過儀式化するリスクが知られる
  • 人月ビジネス(単価×人数)は文書量・工程数の削減と収益が相反し、重厚な工程・文書が温存されやすいという指摘がある
  • 多重下請け構造により、元請け(PM/SE=上流)と二次請け以下(PG=製造・単体テスト)の工程別分業が定着している
  • 原典(Royce)の警告(反復・Do it twice・継続的顧客関与)が落ち、図の逐次モデルだけが制度化された経緯そのものが最大の「建前と実態の乖離」

フェーズ一覧(第2階層へ)

参考文献