💡「なんちゃってアジャイル」を卒業する！段階的成果物提供の完全マニュアル

![名称未設定のデザイン.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3637864/10818062-d2e9-4770-8fb9-523726caf033.png)

こんにちは😊
株式会社プロドウガの[@YushiYamamoto](https://qiita.com/YushiYamamoto)です！
React/Next.js専門のフリーランスエンジニアとして、日々アジャイルな開発現場で活動しています。

> **「アジャイルで進めたいのですが、契約上、最初に全設計書をください」**  
> **「仕様変更はOKですが、最初にサインした成果物リストは絶対です」**

こんな言葉に「あれ？」と思ったことはありませんか？
それは、**アジャイル開発の良さを殺してしまう「名ばかりアジャイル」のサイン**かもしれません。

この記事では、アジャイルのスピード感を最大限に引き出す **「成果物の段階的提供」** という考え方を、具体的な契約書の書き換え例を交えて解説します。

---

## 😱 1. なぜ「全部入り」の成果物リストは危険なのか？

従来のウォーターフォール開発では、最初に**「全部入り」**のドキュメントセットを作るのが当たり前でした。

- **【よくある全部入りリスト】**
    - 要件定義書
    - 基本設計書
    - 詳細設計書
    - 全テスト仕様書...etc

しかし、変化に素早く対応したいアジャイル開発でこれをやると、**４つの大きな問題**が発生します。

:::note warn
#### 💣 アジャイル開発で「全部入り」が引き起こす４つの問題
1.  **変化への抵抗** 😨  
    せっかく作ったドキュメントが「聖書」になり、**仕様変更が悪**になってしまう。

2.  **ムダな作業** 😩  
    どうせ変わる部分の**詳細設計に時間を浪費**してしまう。

3.  **スピードの低下** 🐢  
    **ドキュメントのレビューばかり**で、肝心の「動くもの」がなかなか出てこない。

4.  **認識のズレ** 💔  
    **分厚いドキュメントは結局誰も読まなくなり**、最終的に「こんなはずじゃ…」となる。
:::

アジャイルの思想は **「📜 包括的なドキュメントよりも、動くソフトウェアを 🚀」** です。成果物の考え方も、この思想に合わせる必要があります。

---

## ✨ 2. 解決策は「段階的提供」：必要なものを、必要なタイミングで

そこで有効なのが**「成果物の段階的提供（だんかいてき ていきょう）」**です。
プロジェクト全体をいくつかのフェーズ（段階）に区切り、**そのフェーズのゴールに必要なものだけを成果物として定義**する方法です。

### 🚀 「段階的提供」がもたらす4つのメリット
| メリット | 一言でいうと？ |
| :--- | :--- |
| **柔軟性の向上** | **「やっぱりこっち」がやりやすい！** 市場の変化に合わせて、計画を柔軟に変更できます。|
| **リスクの早期発見** | **「あ、なんか違う」に早く気づける！** MVPで動くものに触れ、根本的な問題を早期に発見できます。|
| **コスト効率の改善** | **ムダな書類仕事が減る！** 「今、作るべきもの」に集中できます。|
| **信頼関係の構築** | **目に見える進捗で安心！** 短いサイクルで成果を出し続けることで、クライアントとの信頼が深まります。|

### 🗺️ プロジェクトを３つの段階に分けてみよう

例えば、新規サービス開発ならこんな風に分けられます。

| 段階 | 🎯 目的（ゴール） | 🎁 主な成果物 |
| :--- | :--- | :--- |
| **Phase 1: MVP開発** | **価値を素早く検証する** | ・プロダクトバックログ<br>・動くMVP機能<br>・簡易テスト報告書 |
| **Phase 2: 基幹機能開発** | **主要機能を本格的に作る** | ・基幹機能<br>・API設計書<br>・（必要なら）基本設計書 |
| **Phase 3: 本格運用準備** | **いつでも公開できる状態にする** | ・全機能<br>・（簡易版）運用マニュアル<br>・テスト計画書 |

---

## ✍️ 3. 契約書はこう書く！実践的なビフォーアフター

「理屈はわかったけど、契約書にはどう書けばいい？」
ここが一番のキモですよね。実際の契約条項で見てみましょう。

### 📜 契約条項の書き換え例

#### 【❌ Before】従来の一括納品型
> **第X条（成果物）**  
> 乙は甲に対し、本業務の成果物として、以下の各号を202X年X月X日までに納品する。  
> 1. 要件定義書  
> 2. 基本設計書  
> 3. 詳細設計書  
> ...（以下、全リストが続く）

#### 【✅ After】段階的提供型
> **第X条（成果物）**  
> 乙は甲に対し、本業務の成果物を、**以下の各段階の完了に応じて納品**する。**各段階の完了をもって検収**を行い、当該段階の対価を支払うものとする。  
>
> **1. 第1段階（MVP開発）**  
> &emsp;(a) プロダクトバックログ（主要ユーザーストーリー）  
> &emsp;(b) MVPとして動作するソフトウェア（α版）  
>
> **2. 第2段階（基幹機能開発）**  
> &emsp;(a) 基幹機能を含むソフトウェア（β版）  
> &emsp;(b) API仕様書  
>
> **3. 第3段階（本格運用準備）**  
> &emsp;(a) 全機能が実装されたソフトウェア（正式版）  
> &emsp;(b) 運用マニュアル（主要機能に関するもの）

:::note info
#### 💡 契約のポイント
-   **各段階のゴールを明確にする**：「MVPとして●●機能が動作すること」など、完了条件を具体的に。
-   **検収と支払いを段階ごとに紐づける**：双方のキャッシュフローリスクを軽減できます。
:::

---

## 📊 4. 一目でわかる！段階的提供のプロジェクトフロー

このプロジェクトの流れと、各段階で作成される成果物の関係を視覚的に見てみましょう。


```mermaid
graph TD
    subgraph プロジェクトフロー
        A[プロジェクト開始] --> B(Phase 1: MVP開発)
        B --> C{MVP検収・支払い}
        C --> D(Phase 2: 基幹機能開発)
        D --> E{基幹機能検収・支払い}
        E --> F(Phase 3: 本格運用準備)
        F --> G{最終検収・支払い}
    end

    subgraph Phase 1 成果物
        B1[プロダクトバックログ]
        B2[動くMVP機能]
        B3[簡易テスト報告書]
    end
    
    subgraph Phase 2 成果物
        D1[基幹機能]
        D2[API設計書]
        D3[基本設計書]
    end
    
    subgraph Phase 3 成果物
        F1[全機能]
        F2[運用マニュアル]
        F3[テスト計画書]
    end

    B --- B1 & B2 & B3
    D --- D1 & D2 & D3
    F --- F1 & F2 & F3
```

https://www.mermaidchart.com/play?utm_source=mermaid_live_editor&utm_medium=toggle#pako:eNqFUk1r20AU_CvLHkp60CHWTYdCbFmmh4APpZduD4ot24VUCv6glBBItG1xKmhS4qQNNUlaWuKQhqSHQuykv-ahlfMv-nblWlawqA7LztvZebPztE4rXtWhBtU0jbkVz629qBvMJWTVfu112gap2vWmIwvthvPSMUjNazqtNnMVv7bqvao07GabPDGR0-qs1Jv2WoO0Fp8xCvwT8Avwr8E_Bf8SeBf4vqzwW0afS8n4yy8wWm7YLYcsGmT5afnuIIgOR4w-TChLc-WQGJ4GKa3COqMoIb73w50PwG9E71Js78PWG0Y3EpY57ZgzSHg8CodDcXY85n_mtC6i4izlP9LWVFo3iOj_FCe3d1tB1BuI0UHoH6akSygt-pvRbz9T1HGrqVw7KyW5kfFOIiOiuyuO-tH2WTrUmQnwzX_x7wLnao85XqX5OeSHAbbekfmpp6YJOhKiq6_i8x7wd-APUTA8-RV-fC--XE-YGW5zU7e5DLemdDubcvpUCiyVH48HF-NBN2k3OdXjuxj2fUKGH33qR8_wYyk_bwdzzFjSTDxS4EfAA-A_wP8G_DxN01X-k6DQVdS7uW9M_thE0x6RfAzyChRiUFDAjIGpQDEGRQWsGFgKlBIBDUdPHuA85aIn1zUMGUumrJt6clnDx2LJknUL63TjL7AKozg

このように、フェーズの進行と成果物の作成が連動していることがわかります。

---

## 🎉 まとめ：アジャイルの本質は「対話」と「変化への適応」

アジャイル開発における成果物管理で一番大切なのは、
**「完璧なドキュメント」を作ることではなく、**
**「クライアントとの対話を通じて、継続的に価値を届け続ける」こと**です。

### 🚀 明日からできる３つのアクション

1.  **契約書を見直す** 📄  
    成果物リストが「全部入り」なら、「段階的」にできないか交渉してみましょう。

2.  **クライアントと話す** 🗣️  
    「なぜアジャイルなのにドキュメントが重いのか？」を恐れず問いかけ、段階的提供のメリットを丁寧に説明しましょう。

3.  **チームで共有する** 🤝  
    「今回のゴールは？」「必要なアウトプットは？」を常に意識合わせしましょう。

従来の慣習にサヨナラして、プロジェクトの特性に合った成果物のあり方を模索することが、アジャイル開発を成功に導く最短ルートです。

### 最後に：業務委託のご相談、承ります！
アジャイルな開発手法を用いたシステム開発やWeb制作を得意としています。
「仕様が固まっていないけど相談したい」「柔軟な開発パートナーが欲しい」という方は、ぜひお気軽にお声がけください。一緒にビジネスの成功を目指しましょう！