コンテンツにスキップ

ソフトウェア開発プロセス総合調査レポート

調査日: 2026-02-18


目次

  1. ウォーターフォール型 開発プロセスと成果物一覧
  2. アジャイル・スクラム型 開発プロセスと成果物一覧
  3. シーケンス図
  4. 各工程の問題点まとめ
  5. 各工程の生産性向上ポイント
  6. 生成AI中心の開発への変化予測
  7. 参考URL一覧

1. ウォーターフォール型 開発プロセスと成果物一覧

全体フロー

要件定義 → 基本設計 → 詳細設計 → 実装 → 単体テスト → 結合テスト → 総合テスト → 受入テスト → 運用保守

※ V字モデルでは左側(上流)と右側(テスト)が対応関係を持つ: - 要件定義 ↔ 総合テスト/受入テスト - 基本設計 ↔ 結合テスト - 詳細設計 ↔ 単体テスト


1.1 要件定義

工程名 要件定義
概要 システムに必要な機能・性能・制約条件を明確にし、開発の方向性を確定する最上流工程

成果物・ドキュメント一覧

# 成果物名 具体的な内容
1 要件定義書 システムの目的・背景、スコープ、機能要件・非機能要件を網羅的に記述
2 業務フロー図 現行業務(As-Is)および将来業務(To-Be)の流れを図示
3 機能一覧表 システムが実現すべき機能の一覧。優先度・実現方式を含む
4 非機能要件定義書 性能(応答速度等)、可用性、セキュリティ、拡張性などの要件を数値で定義
5 システム化業務範囲定義書 システム化する業務とシステム外で対応する業務の境界を定義
6 用語集・概念モデル プロジェクト内の業務用語定義、概念レベルのデータモデル
7 プロジェクト計画書 スケジュール、体制、予算、リスク管理方針等

1.2 基本設計(外部設計)

工程名 基本設計(外部設計)
概要 ユーザーから見えるシステムの外部仕様を設計する工程。画面、帳票、DB論理構造、システム構成を決定

成果物・ドキュメント一覧

# 成果物名 具体的な内容
1 基本設計書 システムアーキテクチャ、機能分割、処理方式の概要
2 画面設計書(画面レイアウト) 各画面の配置、入出力項目、バリデーション規則
3 画面遷移図 画面間の遷移パターンとトリガー条件
4 帳票設計書 出力帳票のレイアウト、出力条件、出力項目
5 データベース設計書(ER図) テーブル定義、エンティティ間リレーション、論理データモデル
6 システム構成図 ハードウェア・ミドルウェア・ネットワーク構成
7 インターフェース設計書 外部システム連携仕様(API仕様、ファイル連携仕様等)
8 バッチ処理設計書 バッチ処理一覧、実行スケジュール、処理フロー
9 セキュリティ設計書 認証・認可方式、暗号化方式、監査ログ方針等

1.3 詳細設計(内部設計)

工程名 詳細設計(内部設計)
概要 基本設計を実装可能なレベルまで詳細化。モジュール構造、処理ロジック、データ構造を具体的に記述

成果物・ドキュメント一覧

# 成果物名 具体的な内容
1 詳細設計書 モジュールごとの処理ロジック、入出力仕様、エラー処理
2 プログラム設計書 各プログラムの処理フロー(フローチャート、擬似コード等)
3 モジュール構造図 モジュール間の呼び出し関係と依存関係
4 クラス図・シーケンス図 オブジェクト指向設計の場合のUML図
5 テーブル定義書(物理設計) 物理テーブル名、カラム名、データ型、インデックス定義
6 共通処理設計書 共通ライブラリ、ユーティリティ関数の仕様
7 コーディング規約 命名規則、インデント、コメント記述ルール等

1.4 実装(プログラミング・製造)

工程名 実装(プログラミング)
概要 詳細設計書に基づき、ソースコードを記述する工程

成果物・ドキュメント一覧

# 成果物名 具体的な内容
1 ソースコード 機能・モジュールごとのプログラムファイル
2 実装メモ・技術ノート 実装上の判断根拠、ワークアラウンドの記録
3 ビルド手順書 コンパイル・ビルド・デプロイの手順
4 環境構築手順書 開発環境・テスト環境の構築手順
5 コードレビュー記録 レビュー指摘事項と対応結果の記録

1.5 単体テスト(UT)

工程名 単体テスト
概要 プログラムの最小単位(関数・メソッド・モジュール)が正しく動作するかを検証。V字モデルでは詳細設計に対応

成果物・ドキュメント一覧

# 成果物名 具体的な内容
1 単体テスト仕様書 テスト対象、テスト条件、入力値、期待結果
2 単体テスト結果報告書 テスト実施日、実施者、結果(OK/NG)、エビデンス
3 バグ報告書・障害票 不具合の内容、再現手順、重要度、対応状況
4 テストコード 自動テスト用のユニットテストコード
5 カバレッジレポート コードカバレッジ(C0/C1/C2)の測定結果

1.6 結合テスト(IT)

工程名 結合テスト
概要 単体テスト済みモジュールを結合し、インターフェースやデータ受け渡しの正当性を検証。V字モデルでは基本設計に対応

成果物・ドキュメント一覧

# 成果物名 具体的な内容
1 結合テスト仕様書 テストシナリオ、テスト条件、結合対象モジュール、期待結果
2 結合テスト結果報告書 テスト実施結果、不具合一覧、エビデンス
3 インターフェーステスト結果 外部システム連携の検証結果
4 障害管理表 不具合の管理(起票・対応・確認のステータス管理)
5 テスト進捗管理表 テスト消化率、バグ検出率の推移グラフ

1.7 総合テスト(ST)

工程名 総合テスト
概要 システム全体が要件定義の機能要件・非機能要件を満たしているかを検証。性能・負荷・セキュリティテスト含む。V字モデルでは要件定義に対応

成果物・ドキュメント一覧

# 成果物名 具体的な内容
1 総合テスト計画書 テスト方針、テスト範囲、テスト環境、スケジュール、体制
2 総合テスト仕様書 業務シナリオベースのテストケース、テスト条件
3 総合テスト結果報告書 テスト実施結果、品質評価、残存リスクの報告
4 性能テスト結果報告書 レスポンスタイム、スループット、リソース使用率
5 負荷テスト結果報告書 ピーク時の同時接続数、処理能力限界値
6 セキュリティテスト結果 脆弱性診断結果、対策状況
7 品質評価報告書 バグ密度、テストカバレッジ、品質メトリクス評価

1.8 受入テスト(UAT)

工程名 受入テスト
概要 発注者(ユーザー)がシステムの業務要件充足と実用性を最終確認する工程

成果物・ドキュメント一覧

# 成果物名 具体的な内容
1 受入テスト計画書 テスト方針、テスト範囲、ユーザー側テスト体制、合否判定基準
2 受入テスト仕様書 業務シナリオベースのテストケース(ユーザー視点)
3 受入テスト結果報告書 テスト実施結果、合否判定、残課題一覧
4 検収書(検収報告書) ユーザーが正式にシステムを受け入れた証明文書
5 課題管理表 受入テストで発見された課題と対応方針
6 移行判定資料 本番移行の可否を判断するための資料

1.9 運用保守

工程名 運用保守
概要 本番稼働後の安定運用維持、障害対応、機能改善、パフォーマンス監視を継続的に行う最長期工程

成果物・ドキュメント一覧

# 成果物名 具体的な内容
1 運用設計書 運用方針、監視項目、アラート基準、エスカレーションフロー
2 運用マニュアル 日常運用手順、定期バッチ実行手順、バックアップ・リストア手順
3 操作マニュアル(ユーザー向け) エンドユーザー向けシステム操作手順書
4 障害対応手順書 障害発生時の切り分け手順、復旧手順、連絡フロー
5 移行計画書・移行手順書 本番環境へのシステム移行・データ移行手順
6 保守契約書・SLA サービスレベル合意書(稼働率、対応時間等)
7 変更管理台帳 システム変更の履歴、影響範囲、承認記録
8 インシデント管理表 障害・インシデントの記録と対応履歴
9 リリースノート 各リリースの変更内容、修正バグ、既知の問題

2. アジャイル・スクラム型 開発プロセスと成果物一覧

全体フロー

プロダクトバックログ作成
┌─────────────────── スプリント(1〜4週間の反復) ───────────────────┐
│  スプリントプランニング → スプリント実行 → スプリントレビュー → レトロスペクティブ  │
│                          ↑ デイリースクラム(毎日)                               │
└──────────────────────────────────────────────────────────────────┘
    ↓ (反復)
リリース

2.1 プロダクトバックログ作成・リファインメント

工程名 プロダクトバックログ作成・リファインメント
概要 POが中心となり、製品に必要な全機能・要件を優先順位付きで管理。継続的に更新・精緻化される

成果物・ドキュメント一覧

# 成果物名 具体的な内容
1 プロダクトバックログ 全機能・要件を優先順位付きで一覧化。ユーザーストーリー、バグ修正、技術的負債を含む
2 プロダクトビジョン 製品が目指す方向性・ゴールを記述した文書
3 プロダクトロードマップ 中長期的な機能リリース計画の視覚化
4 ユーザーストーリー 「〜として、〜したい、なぜなら〜」形式の要件。受け入れ基準を含む
5 エピック 複数のユーザーストーリーをまとめた大きな機能単位
6 受け入れ基準(AC) 各バックログアイテムが「完了」と判断される個別条件
7 完了の定義(DoD) 全バックログアイテム共通の品質基準チェックリスト

2.2 スプリントプランニング

工程名 スプリントプランニング
概要 スプリント開始時の計画会議。スプリントゴールと取り組むバックログアイテムを選定(最大8時間/月スプリント)

成果物・ドキュメント一覧

# 成果物名 具体的な内容
1 スプリントゴール 今スプリントで達成すべき目標を1文で表現
2 スプリントバックログ 選定されたバックログアイテムとタスク分解の一覧
3 タスクボード(初期状態) To Do / In Progress / Done に分類されたタスク可視化ボード
4 キャパシティプラン チームメンバーの稼働可能時間・リソース配分計画
5 スプリント見積もり 各アイテムのストーリーポイントまたは時間見積もり

2.3 スプリント実行(設計・実装・テスト)

工程名 スプリント実行
概要 プランニングで決めた内容を実際に開発する期間(1〜4週間)。設計・実装・テスト・コードレビューを含む

成果物・ドキュメント一覧

# 成果物名 具体的な内容
1 インクリメント DoDを満たした、潜在的にリリース可能なプロダクトの増分
2 ソースコード バージョン管理されたプログラムコード
3 単体テスト・結合テスト 自動化されたテストコードおよびテスト結果
4 API仕様書 APIエンドポイントの仕様(Swagger/OpenAPI等)
5 ER図・データモデル データベース設計の図表
6 システム構成図 アーキテクチャ全体像を示す図
7 コードレビュー記録 プルリクエスト上のレビューコメントと承認記録
8 バーンダウンチャート スプリント期間中の残作業量推移グラフ
9 CI/CDパイプラインログ 自動ビルド・テスト・デプロイの実行結果

2.4 デイリースクラム

工程名 デイリースクラム
概要 毎日同じ時刻・場所で行う15分のタイムボックスミーティング。進捗検査と計画適応

成果物・ドキュメント一覧

# 成果物名 具体的な内容
1 更新されたタスクボード タスクの進捗(To Do → In Progress → Done)を反映した最新状態
2 障害・ブロッカーリスト 進行を妨げている課題の一覧
3 更新されたバーンダウンチャート 日次更新の残作業量推移

※ 口頭共有が主で、公式ドキュメントは少ない


2.5 スプリントレビュー

工程名 スプリントレビュー
概要 スプリント終了時にステークホルダーを含めてインクリメントをデモし、フィードバックを得る(最大4時間/月スプリント)

成果物・ドキュメント一覧

# 成果物名 具体的な内容
1 インクリメントのデモ DoDを満たした成果物の実演
2 ステークホルダーフィードバック 意見・要望・改善提案の記録
3 更新されたプロダクトバックログ フィードバック反映後に優先順位再調整されたバックログ
4 更新されたリリースプラン デモ結果に基づき修正されたリリース計画
5 スプリントレビュー議事録 議論内容・決定事項の記録

2.6 スプリントレトロスペクティブ

工程名 スプリントレトロスペクティブ(ふりかえり)
概要 チーム内の改善会議。プロセス・人間関係・ツールの観点で振り返り、改善アクションを決める(最大3時間/月スプリント)

成果物・ドキュメント一覧

# 成果物名 具体的な内容
1 KPT(Keep/Problem/Try)シート 「継続」「問題」「次に試すこと」を整理した記録
2 改善アクションアイテム 次スプリントで実施する具体的な改善施策リスト
3 チーム合意事項 ワーキングアグリーメント(チームの約束事)の更新
4 レトロスペクティブ議事録 議論内容と決定事項の記録

2.7 リリース

工程名 リリース
概要 インクリメントを本番環境にデプロイしエンドユーザーに提供。毎スプリントでリリース可能が原則だが実際のタイミングはビジネス判断

成果物・ドキュメント一覧

# 成果物名 具体的な内容
1 リリースプラン どの機能をいつリリースするかのスケジュール
2 リリースノート ユーザー向けの変更内容・新機能説明
3 デプロイメント手順書 本番環境へのデプロイ手順とロールバック手順
4 リリース判定記録 リリース可否の判断根拠・承認記録
5 運用マニュアル 運用チーム向け操作手順・トラブルシューティングガイド
6 パフォーマンステスト結果 負荷テスト・性能テストの実行結果

3. シーケンス図

3.1 ウォーターフォール型 シーケンス図

sequenceDiagram
    participant CL as 顧客/発注者
    participant PM as PM/BA
    participant DE as 設計チーム
    participant DV as 開発チーム
    participant QA as テストチーム
    participant OP as 運用チーム

    rect rgb(70, 130, 180)
    Note over CL, PM: 要件定義
    CL->>PM: 業務課題・要望のヒアリング
    PM->>PM: 業務フロー図作成
    PM->>PM: 要件定義書作成
    PM->>PM: 機能一覧表・非機能要件定義書作成
    PM->>CL: 要件定義書レビュー・承認
    CL-->>PM: 承認
    end

    rect rgb(60, 179, 113)
    Note over PM, DE: 基本設計(外部設計)
    PM->>DE: 要件定義書引き渡し
    DE->>DE: 基本設計書作成
    DE->>DE: 画面設計書・画面遷移図作成
    DE->>DE: DB設計書(ER図)・IF設計書作成
    DE->>DE: システム構成図・セキュリティ設計書作成
    DE->>CL: 基本設計書レビュー・承認
    CL-->>DE: 承認
    end

    rect rgb(186, 85, 211)
    Note over DE, DV: 詳細設計(内部設計)
    DE->>DV: 基本設計書引き渡し
    DV->>DV: 詳細設計書・プログラム設計書作成
    DV->>DV: モジュール構造図・クラス図作成
    DV->>DV: テーブル定義書(物理)・コーディング規約作成
    DV->>DE: 詳細設計書レビュー
    DE-->>DV: 承認
    end

    rect rgb(255, 165, 0)
    Note over DV: 実装(プログラミング)
    DV->>DV: ソースコード実装
    DV->>DV: コードレビュー実施
    DV->>DV: ビルド手順書・環境構築手順書作成
    end

    rect rgb(220, 20, 60)
    Note over DV, QA: 単体テスト(UT)
    DV->>DV: 単体テスト仕様書作成
    DV->>DV: テストコード作成・テスト実施
    DV->>DV: 単体テスト結果報告書・カバレッジレポート作成
    DV->>QA: バグ報告・修正
    end

    rect rgb(255, 105, 180)
    Note over QA: 結合テスト(IT)
    QA->>QA: 結合テスト仕様書作成
    QA->>QA: テスト実施・エビデンス取得
    QA->>QA: 結合テスト結果報告書・障害管理表作成
    QA->>DV: 不具合報告
    DV-->>QA: 修正・再テスト
    end

    rect rgb(100, 149, 237)
    Note over QA, CL: 総合テスト(ST)
    QA->>QA: 総合テスト計画書・仕様書作成
    QA->>QA: 業務シナリオテスト実施
    QA->>QA: 性能・負荷・セキュリティテスト実施
    QA->>QA: 品質評価報告書作成
    QA->>DV: 不具合報告
    DV-->>QA: 修正・再テスト
    end

    rect rgb(255, 215, 0)
    Note over CL, QA: 受入テスト(UAT)
    QA->>CL: テスト環境引き渡し
    CL->>CL: 受入テスト計画書・仕様書作成
    CL->>CL: 業務シナリオテスト実施
    CL->>CL: 受入テスト結果報告書作成
    CL->>PM: 検収書発行
    end

    rect rgb(128, 128, 128)
    Note over OP, CL: 運用保守
    QA->>OP: 運用設計書・運用マニュアル引き渡し
    OP->>OP: 本番移行実施
    OP->>OP: 監視・障害対応・インシデント管理
    OP->>DV: 保守依頼(改善・障害修正)
    DV-->>OP: 修正リリース
    end

3.2 アジャイル・スクラム型 シーケンス図

sequenceDiagram
    participant SH as ステークホルダー
    participant PO as プロダクトオーナー
    participant SM as スクラムマスター
    participant DT as 開発チーム
    participant ENV as 本番環境

    rect rgb(70, 130, 180)
    Note over SH, PO: プロダクトバックログ作成
    SH->>PO: ビジネス要求・フィードバック
    PO->>PO: プロダクトビジョン・ロードマップ作成
    PO->>PO: ユーザーストーリー・受入基準作成
    PO->>PO: プロダクトバックログ優先順位付け
    PO->>DT: 完了の定義(DoD)合意
    end

    loop スプリント(1〜4週間の反復)

        rect rgb(60, 179, 113)
        Note over PO, DT: スプリントプランニング
        PO->>DT: 優先バックログアイテム提示
        DT->>DT: スプリントゴール設定
        DT->>DT: バックログアイテム選定・タスク分解
        DT->>DT: スプリントバックログ・キャパシティプラン作成
        end

        rect rgb(255, 165, 0)
        Note over SM, DT: スプリント実行

        loop 毎日
            rect rgb(255, 228, 181)
            Note over SM, DT: デイリースクラム(15分)
            DT->>DT: 進捗共有(昨日/今日/障害)
            DT->>DT: タスクボード更新
            SM->>SM: 障害・ブロッカー解消支援
            DT->>DT: バーンダウンチャート更新
            end
        end

        DT->>DT: 設計・実装・テスト
        DT->>DT: コードレビュー・CI/CD実行
        DT->>DT: インクリメント作成
        end

        rect rgb(186, 85, 211)
        Note over SH, DT: スプリントレビュー
        DT->>SH: インクリメントのデモ
        SH->>PO: フィードバック提供
        PO->>PO: プロダクトバックログ更新
        PO->>PO: リリースプラン更新
        end

        rect rgb(220, 20, 60)
        Note over SM, DT: スプリントレトロスペクティブ
        DT->>DT: KPT/振り返り実施
        DT->>DT: 改善アクションアイテム決定
        SM->>SM: チーム合意事項更新
        end

    end

    rect rgb(128, 128, 128)
    Note over PO, ENV: リリース
    PO->>PO: リリース判定
    DT->>DT: リリースノート作成
    DT->>ENV: デプロイ実施
    DT->>DT: パフォーマンステスト・監視
    end

4. 各工程の問題点まとめ

4.1 ウォーターフォール型の問題点

工程 主な問題点
要件定義 要件の抜け漏れが後工程で発覚し手戻りコスト膨大 / 顧客が要求を正確に言語化できない / 非機能要件の軽視 / スコープクリープ
基本設計 要件の曖昧さを引き継ぎ解釈違いが発生 / 画面設計と業務実態の乖離 / IF仕様確定の遅延 / レビュー品質のばらつき
詳細設計 基本設計との整合性不良 / 粒度の不統一 / ドキュメント量が膨大でメンテコスト高 / 設計書とコードの二重管理
実装 設計書の不備による独自解釈 / 技術的負債の蓄積 / 開発者スキル差 / IT人材不足
単体テスト テストケースの網羅性不足 / テスト仕様書作成に工数大 / エビデンス取得が手作業 / 開発者自身のテストによる思い込み
結合テスト IF不整合の発覚 / 外部システム環境準備の遅延 / テスト環境構築に工数大 / 原因切り分けの困難
総合テスト 本番同等環境の構築困難 / テスト期間不足 / 非機能要件テスト基準の曖昧さ / セキュリティ人材不足
受入テスト ユーザー側テスト要員の確保困難 / この段階での要件漏れ発覚 / 合否判定基準の曖昧さ
運用保守 ドキュメント未更新 / 属人化 / 設計思想の引継ぎ不足 / レガシーシステムの技術的負債増大

4.2 アジャイル・スクラム型の問題点

工程 主な問題点
バックログ管理 バックログの肥大化(「バックログ墓場」) / ストーリー粒度の不統一 / POが板挟み / 受入基準の曖昧さ
スプリントプランニング 過剰コミットの常態化 / スプリントゴールの形骸化 / Readyでないアイテムの混入 / 見積もり精度の低さ
スプリント実行 ミニウォーターフォール化 / QAボトルネック / 技術的負債の蓄積 / ドキュメント省略しすぎ / コードレビュー形骸化
デイリースクラム 「報告会」への形骸化 / 15分超過 / リモートワークでの参加意識低下 / 障害の未解決ループ
スプリントレビュー 「発表会」化 / ステークホルダー参加率低 / フィードバック反映の仕組み不足
レトロスペクティブ 改善アクションの不実行 / 同じ問題の繰り返し / 心理的安全性不足 / マンネリ化
リリース 毎スプリントリリースの未達成 / CI/CD未整備 / 監視体制不十分 / ドキュメント更新後回し

5. 各工程の生産性向上ポイント

5.1 ウォーターフォール型

工程 生産性向上のポイント
要件定義 読み合わせ会で認識齟齬の早期解消 / プロトタイプ・モックアップ活用 / 非機能要件の数値化 / テンプレート標準化
基本設計 画面モックアップの早期作成 / 設計パターン・テンプレート標準化 / レビューチェックリスト / コンポーネント設計
詳細設計 テンプレート標準化と粒度ガイドライン / UMLツール活用 / リバースエンジニアリング活用 / 必要十分な粒度
実装 CI/CDパイプライン整備 / コードレビュー文化 / 静的解析ツール / フレームワーク標準化
単体テスト テスト自動化フレームワーク導入 / テストケース標準化 / カバレッジ目標設定 / TDD手法導入
結合テスト モック・スタブ活用 / テスト環境自動構築(IaC) / テストデータ自動生成 / CI/CD統合
総合テスト クラウド環境活用 / 性能テストツール自動化 / リスクベーステスト / 回帰テスト効率化
受入テスト 要件定義段階からの受入テスト観点織り込み / ユーザートレーニング実施 / 合否判定基準の事前合意
運用保守 初期段階からの運用担当者参画 / 運用自動化ツール導入 / ドキュメントのバージョン管理 / IaC活用

5.2 アジャイル・スクラム型

工程 生産性向上のポイント
バックログ管理 リファインメントに10%の時間確保 / ユーザーストーリーマッピング / INVEST原則 / ステークホルダーとの定期的コミュニケーション
スプリントプランニング 事前リファインメント徹底 / プランニングポーカー / ベロシティデータ活用 / スプリントゴールの明確化
スプリント実行 スウォーミング / TDD・BDD / ペアプログラミング・モブプログラミング / CI/CD自動化徹底
デイリースクラム スプリントゴール中心の議論 / 15分タイムボックス厳守 / タスクボード活用 / 非同期コミュニケーション検討
スプリントレビュー 実際に触ってもらうデモ / ステークホルダーへの事前案内 / フィードバック即時記録 / スプリントゴール達成度評価
レトロスペクティブ 改善アクションを次スプリントバックログに組込 / 手法のローテーション / 心理的安全性確保 / データに基づく振り返り
リリース CI/CD完全自動化 / フィーチャーフラグ活用 / カナリアリリース / リリースノート自動生成

6. 生成AI中心の開発への変化予測

6.1 工程横断の大きな変化

# 変化の方向性 詳細
1 工程の境界が曖昧化 要件定義→設計→実装をAIが一気通貫で処理可能に。従来の明確な工程区分が薄れ「Water-Scrum-Fast」のようなハイブリッド手法が台頭
2 人間の役割シフト 「コードを書く」→「意図を説明し、AIの出力をレビュー・統合する」。PM/POの判断力がより重要に
3 ドキュメントの位置づけ変化 「人間が読む文書」→「AIのインフラとしての構造化仕様」。人間とAI両方が理解できるドキュメント設計が必要
4 品質保証の変革 テスト自動生成・自動実行が標準化。テストエンジニアは「テスト戦略」と「AIが見落とすリスクの発見」に注力
5 開発スループットの飛躍的増大 一部報告ではベロシティ500%向上。NTTデータは2027年度に全体40%効率化、電通総研は上流工程30%向上を確認
6 内部品質投資の損益分岐点短縮 AIによる開発速度向上で技術的負債の影響がより早く顕在化。損益分岐点が1ヶ月→1週間に短縮
7 スプリント短縮 開発速度向上に合わせ、より短いスプリントで高速に学習・適応するサイクルへ移行
8 「AI + 人間」の協働 AIを「チームメンバーの一人」として位置づけ、人間とAIの協働ワークフローを構築する方向性

6.2 工程別のAI変化予測

ウォーターフォール型

工程 AI時代の変化
要件定義 自然言語の顧客要望をAIが構造化し要件定義書草案を自動生成 / 類似プロジェクトから抜け漏れリスク自動検出 / 曖昧表現のAI指摘
基本設計 要件定義書から画面モックアップ・ER図・API仕様書をAIが自動生成 / 設計書の整合性チェックをAI実行
詳細設計 基本設計書からの詳細設計ドラフト自動生成 / AIが直接コード生成可能なため詳細設計の役割が縮小 / 「Why」の記述が重要に
実装 AIコーディング支援が標準装備(2024年時点で51.3%が導入済み) / 仕様からのコード自動生成 / 人間はレビュー・品質保証にシフト
単体テスト コード・設計書からテストケース・テストコードをAI自動生成 / テスト失敗原因の即時分析 / テスト網羅性の自動評価
結合テスト IF仕様から結合テストシナリオAI自動生成 / テスト結果分析・原因切り分けAI支援 / テストデータ自動生成
総合テスト 業務シナリオからテストケースAI自動生成 / 性能ボトルネック自動特定 / セキュリティ脆弱性AI自動診断
受入テスト 業務フローから受入テストシナリオ自動生成 / AIチャットボットによる操作ガイダンス / RPA+AIで自動実行
運用保守 障害予兆検知・自動復旧 / ログ分析・監視のAI自動化 / レガシーシステムのドキュメント自動復元

アジャイル・スクラム型

工程 AI時代の変化
バックログ管理 ユーザーストーリー・受入基準のAI自動生成 / AI入力単位で粒度設計 / 過去データから優先順位・リスク予測
スプリントプランニング 過去ベロシティ分析から最適スプリントバックログ構成提案 / タスク分解のAI自動化 / スプリントスコープ大幅増加
スプリント実行 AI中心のコード生成、人間はレビュー・設計・統合 / テスト自動生成標準化 / 設計書とコードの整合性AI自動検証 / コードレビューへのAI参加
デイリースクラム タスク進捗のAI自動集約・レポート化 / Git・ツールデータから障害自動検知 / スプリントゴール未達の早期警告
スプリントレビュー 成果のAI自動サマリ化 / プロトタイプ・UIモックのAI自動生成 / 非同期フィードバック収集
レトロスペクティブ 定量データの自動分析 / 繰り返し問題パターンの検出 / 改善施策の効果予測
リリース リリースノート自動生成 / コード変更の影響範囲予測・リスクスコア算出 / 異常検知・自動ロールバック

6.3 AI導入の実績データ

項目 データ
生成AI導入率 2024年時点で51.3%の開発現場が導入済み
NTTデータグループ目標 2027年度に開発工程全体で40%の効率化
電通総研の実績 上流工程の半自動化AIエージェントで30%の生産性向上(2025年確認)
ベロシティ向上報告 一部チームで500%向上の報告あり
AI生成コードの課題 「ほぼ正しいが完全ではないAI出力」への対処が最大課題(開発者の66%が指摘)

7. 参考URL一覧

ウォーターフォール型 関連

開発プロセス全般・成果物 - システム幹事 - ウォーターフォール開発とは - システム幹事 - システム開発の成果物・ドキュメント一覧 - Qiita - ウォーターフォール開発の成果物まとめ - SINT - ウォーターフォールとは - SHIFT - ウォーターフォールモデルとは - briarpatch - システム開発の工程と手法 - CSS Innovation Lab - ウォーターフォール開発の工程と案件遂行のコツ - Engineer Labo - ウォーターフォールモデル徹底解説 - はろぐ - ウォーターフォールモデルと成果物

問題点・課題 - HiPro Tech - ウォーターフォール開発の問題点・将来性 - Worldhacks - ウォーターフォール型開発の問題点 - Rabiloo - ウォーターフォールモデルは時代遅れか - ノーコード総合研究所 - ウォーターフォールのメリット・デメリット

テスト工程 - VALTES - テスト工程とは - dip Engineer Blog - ウォーターフォール開発におけるテスト - offshore-kaihatsu.com - 受け入れテスト(UAT)とは

生産性向上 - 日立ソリューションズ東日本 - 要件定義の効率の良い進め方 - 日立ソリューションズ東日本 - 開発工程の効率化と手戻り工数削減 - LaKeel DX - システム開発の生産性向上 - NTT技術ジャーナル - AIを活用した開発標準

要件定義の品質 - ITmedia - 失敗しない要件定義3つのポイント - ヒンシツ大学 - 要件定義入門

運用保守 - ReSM - 運用設計書の構成例 - DX KING - 運用保守に必要なドキュメント - DTS - システム運用8つの課題と解決策


アジャイル・スクラム型 関連

スクラムアーティファクト・成果物 - Atlassian - アジャイル スクラム アーティファクト - SHIFT ASIA - スクラムの3つの作成物 - Ryuzee.com - アジャイル開発ドキュメント指針 - Qiita - アジャイル開発におけるドキュメント - ones.com - スクラムアーティファクト図 - Scrum Guide(公式) - ProjectManager - The 7 Scrum Artifacts

DoD・受け入れ基準 - Scrum.org - Definition of Done vs Acceptance Criteria - Atlassian - What Is the Definition of Done

スプリントレビュー・レトロスペクティブ - スパイスファクトリー - スプリントレビューとは - Ryuzee.com - スプリントレビューの進め方 - Promapedia - スプリントレトロスペクティブとは

問題点・課題 - SPIDERPLUS Tech Blog - 形骸化しないスクラム - Qiita - Agile Japan 2025 参加レポート - Findy Tech Blog - 開発生産性を阻む組織の3大課題 - Advised Skills - Common Challenges in Scrum

生産性向上 - Microsoft Learn - スプリントとスクラムのベストプラクティス - Scrum Inc. Japan - スウォーミング - CodeZine - Four Keysで見えたメリットと課題


生成AI・AI駆動開発 関連

テスト自動化・AI活用 - 富士通研究所 - テスト仕様書生成技術 - Fintan - 生成AIを活用したテスト仕様書作成の自動化 - Publickey - Autify Nexus(AIでテストケース自動生成) - gihyo.jp - 生成AIのソフトウェアテストへの活用 - Tricentis - AI in Software Testing 2025