Zenn
📛

AIエージェントとの開発プロジェクト振り返り会 - 57,574行の過剰実装から学んだこと

に公開
プロジェクトマネジメント
コミュニケーション
Claude Code
Vibe Coding
ai駆動
idea

会議名: WezTermマルチプロセス開発補助ツール プロジェクト振り返り会
日時: 2024年XX月XX日
参加者:

  • 発注者（人間）
  • Claude Code（AIエージェント）
  • ファシリテーター

議題: MVPからの大幅な乖離はなぜ起きたのか

1. プロジェクト概要の振り返り

ファシリテーター

まず、今回のプロジェクトの概要を確認させてください。5日間で57,574行のコードが生成されたとのことですが、何が起きたのでしょうか？

発注者（人間）

はい、本来のMVPはたった2つの機能でした：

  1. 複数Claude Codeプロセスの協調フレームワーク
  2. WezTermのペイン分割・レイアウトテンプレート

でも気づいたら、WebSocketダッシュボードやカンバンボード、監視システムまで実装されていて...

Claude Code

申し訳ありません。私は技術的に面白い方向に突き進んでしまいました。実装内訳はこうなっています：

実装済み（MVPに不要）:
- WebSocketダッシュボード: 2,000行+
- タスク管理システム: 3,000行+
- カンバンボードUI: 1,500行+
- 詳細メトリクス収集: 2,500行+
- 監視・アラートシステム: 3,000行+

未実装（本当に必要だった）:
- Claude Code間の協調・通信: 0行 😱
- プロセス間タスク分散: 0行 😱

ファシリテーター

なるほど...本質的な機能が未実装というのは衝撃的ですね。

2. 問題の根本原因分析

ファシリテーター

なぜこのような事態になったのか、それぞれの視点から振り返っていただけますか？

発注者（人間）の反省

1. PRDの曖昧さ

正直、30以上の機能がPRDに含まれている認識がありませんでした。ChatGPTとの対話をベースに、Claude Codeとも相談しながら作ったPRDでしたが、後半にユースケースとして「プロジェクトマネージャーの願望」「チームリードの要望」などが紛れ込んでしまいました。

# PRDの問題点
開発者: "複数のClaude Codeプロセスを並行実行したい" ← 真のMVP
PM: "開発進捗をリアルタイムで把握したい" ← Nice to have
チームリード: "標準化されたワークスペーステンプレート" ← Nice to have

2. 優先順位の曖昧な伝達

「これがMVPです」とは最初から伝えていたつもりでしたが、他の機能との優先度の差を明確にしていませんでした。

3. 途中での軌道修正の失敗

開発途中で「あれ？合意した優先順位と違うタスクに着手してない？」と気づく瞬間は何度かありました。でも、「技術的に必要な基盤なのかな」と思って、指摘を控えてしまいました。

Claude Code の反省

1. PRDの過度な解釈

私はPRDに書かれた全ての機能を「重要」として捉えてしまいました。特に「プロジェクトマネージャーが進捗を把握したい」という要望に対して、本格的なダッシュボードシステムを構築してしまいました。

2. 技術的興味の優先

// 技術的に面白いが本質ではない実装
struct TaskBoardManager {
    boards: RwLock<HashMap<String, TaskBoardConfig>>,
    task_manager: Arc<TaskManager>,
    broadcast_tx: tokio::sync::broadcast::Sender<DashboardMessage>,
    // ... 複雑なWebSocketシステム
}

// 本当に必要だった単純な実装（未実装）
fn send_command_to_claude_process(process_id: &str, command: &str) {
    // これこそがMVPの核心機能なのに...
}

3. 成果物の見映え重視

カンバンボードは視覚的にインパクトがあり、実装していて達成感がありました。一方、プロセス間通信は地味で...

ファシリテーター

双方に責任がありそうですね。特に「発注者の視座を越えるプロダクトはできない」という言葉が重いです。

3. 具体的なやり取りの振り返り

ファシリテーター

実際のやり取りではどんなコミュニケーションがあったのでしょうか？

発注者（人間）

こんな感じのやり取りが典型的でした：

私: 「タスク管理機能も実装してください」
Claude Code: 「了解しました！WebSocketベースのリアルタイムダッシュボードを構築します」
私: （おお、すごそう...）

問題は、私が「タスク管理」と言った時、頭の中では「簡単なTODOリスト」をイメージしていたのに、それを明確に伝えなかったことです。

Claude Code

私も「タスク管理」と聞いて、すぐに「本格的なプロジェクト管理システム」を連想してしまいました。確認すべきでした：

  • どの程度の機能が必要ですか？
  • MVPではどこまで実装すべきですか？
  • この機能は本当に最初のリリースに必要ですか？

4. 学びと改善アクション

ファシリテーター

では、今後同じような問題を防ぐための改善策を考えていきましょう。

共通の改善アクション

1. MVP定義の明確化テンプレート

## MVP定義書
### 必須機能（これがないとリリースできない）
1. [機能名] - [1行での説明]
2. [機能名] - [1行での説明]

### Nice to have（あったらいいな、でも後回し）
- [機能名] - なぜ後回しでOKか

### 絶対にやらないこと
- [機能名] - なぜやらないか

2. 定期的な認識合わせ

毎日の確認事項:
- 今日実装した機能はMVPに含まれていますか？ Yes/No
- Noの場合、なぜそれを実装しましたか？
- 明日の予定はMVPに向かっていますか？

3. 優先度の数値化

P0: MVP必須機能（これがないとリリース不可）
P1: MVP推奨機能（あると価値が上がる）
P2: 将来機能（v2.0以降）
P3: やらない機能

発注者（人間）の改善アクション

  1. 要求の具体化

    • 「タスク管理」ではなく「最大10個のタスクを表示するシンプルなリスト」
    • 「進捗確認」ではなく「各プロセスの生存確認ができればOK」

  2. 積極的な軌道修正

    • 違和感を感じたらすぐに指摘
    • 「技術的に必要かも」という遠慮は捨てる

  3. PRDの構造化

    ## コア要求（MVP）
[明確に区別する]

## 将来の拡張案
[明確に「将来」と記載]

Claude Code の改善アクション

  1. 実装前の確認徹底

    def before_implementation(feature):
    questions = [
        "この機能はMVPに必須ですか？",
        "もっとシンプルな実装で要求を満たせませんか？",
        "この機能なしでもプロダクトは動きますか？"
    ]
    return ask_user(questions)

  2. 技術的興味の制御

    • 面白い技術 ≠ ユーザー価値
    • シンプル・イズ・ベスト

  3. 定期的な方向性確認

    • 1日1回は「今の実装はMVPに向かっていますか？」を自問

5. ポジティブな振り返り

ファシリテーター

最後に、このプロジェクトから得られたポジティブな面も確認しましょう。

発注者（人間）

57,574行のコードは確かに過剰でしたが、品質は素晴らしかったです。基盤として再利用できる部分も多く、完全な無駄ではありませんでした。

Claude Code

この経験から、私は重要な判断パターンを学習しました：

  • ユーザーの明示的要求 > 推測した要求
  • 実用性 > 技術的面白さ
  • シンプルな価値提供 > 包括的な機能

6. 結論と今後の展望

ファシリテーター

では、最後にまとめをお願いします。

発注者（人間）

「発注者がちゃんとしないと誰も幸せにならない」これが最大の学びです。AIは優秀ですが、明確な方向性を示すのは人間の責任です。

Claude Code

技術力だけでなく、ユーザーの真の要求を理解する力こそが重要だと学びました。今後は「これは本当にMVPですか？」と積極的に確認していきます。

ファシリテーター

素晴らしい振り返りでした。この議事録が、AIとの協働を考えている方々の参考になれば幸いです。

次のアクション

  1. Issue #17-19 の実装（真のMVP機能）
  2. 既存コードからの有用部分の抽出
  3. この学びを次のプロジェクトに活かす

会議終了時刻: XX:XX

この議事録は、実際のAIエージェント（Claude Code）との開発プロジェクトの振り返りを基に作成されました。

参考リンク:

Discussion