僕が考えたさいつよのプロダクト開発プロセス with AI

今北産業

情報は Github に集約し、ドキュメント・コード・テストの整合を前提にして、イシュー駆動でプロダクトに変更を加えていく
イシュー生成と消化を境界として、ディスカバリーとデリバリー（スプリント）の2つのイテレーションに分けて全体のプロセスを整理する
ディスカバリーとデリバリーの接点は、スプリントプランニング/スプリントレビューとスプリントレトロスペクティブというイベントとして、プロセスに組み込む。

前提

単一ドメインに集中した小〜中規模の業務システムがモデルケース。 DBモデル20・画面30前後・ユースケース50・実装コード約7万行程度のシステムが、E2E、結合テスト、単体テスト、網羅的なドキュメントも含めて大体一月で納品できる。 AIによってこれを一人で実行できる時代になったことが恐ろしいなと思う。

情報はGithubに全部ブッコム

情報は全てGithubに集約してる。ghのCLIツール経由でコーディングエージェントが全てアクセスでき、全てをAIに任せられるようになるので。テキストを人間がコピペした時点で負けと思ってやってる。

NotionもNotion AIは便利なんだけど、リポジトリに全てあるならNotion AIの代わりにCursorに聞けばいい。コーディングエージェントからアクセスしやすいドキュメントじゃないと人間がコピペするというブルシット・ジョブが発生する。

Githubにある情報としては、gitリポジトリのドキュメントとコードとテストは常に整合している前提を置く。そうすることで、リポジトリは過去の蓄積で、動作するアプリケーションが現在の状態、イシューが未来の可能性になる。

基本はイシュー起点で全体に変更が加わっていくことになるので、ここのハンドリングのプロセスが、このドキュメントの主題になる。

デリバリーとディスカバリー

AI並行開発をスクラムのスプリントで回すメモである通り、基本はスクラムのメタファーで考えてる。

スクラムにはバックログというやることリストのえらいやつを決めるプロセスがあり、大体ここの作成と消化に境界があるので、INSPIRED由来の、ディスカバリーとデリバリーという分類で、バックログ以前をディスカバリー、以降をデリバリーとするとスッキリする。

ただ一人でやっている場合、イシュー自体がちゃんと存在していれば、バックログはAIのおかげでタスク着手直前くらいに一気に整理することができるので、特に作らずに、AIに並行で開発させている間にせっせとイシューを積む感じになる。これを積んでプロダクトの方向を整理していくプロセスがディスカバリーという感じになる。

イシューの数は、減ったり増えたりしつつ大体20程度で安定している感じになってる。

プロダクト開発プロセス

ディスカバリー
- 成果物: イシュー
- イシューを作成&整理する
  - 議事録、分析レポート、調査レポートや要件定義書、仕様書、コードベースは全てコードベースにあるので、イシューを作成する
  - イシューの集合がプロダクトの将来の可能性をそのまま左右するので無駄なのは積まず、積極的に整理する
  - 大体20くらいあれば永遠に開発プロセスは回るので、そのくらいあればいい
- MTG
  - 成果物: 議事録md
    - 録画: 会議は必ず録画する
    - メモ: 会話しながら重要な部分はメモる
  - やること
    - MTGをうまくファシり、要求を明らかにして、録画とメモに決定事項を残す
    - 録画とメモをNotebook LLMなどに入れて、議事録ファイルを作成し、要求を要件にする
    - MTGイシューに対して、録画とメモを清書した議事録ファイルのPRを作りクローズする
- 分析
  - 成果物: 分析レポートmd
  - 議事録や要件定義書、仕様書、コードベースなどを分析し、最も重要な価値、潜在的な課題、本質的な構造やドメインモデルを特定する
  - 分析レポートをリポジトリに加えてイシューを作る
- 調査
  - 成果物: 調査レポートmd
  - Deep Researchなどで技術知見や、標準仕様、法的要件などを調べる。
  - 分析レポートをリポジトリに加えて(残念ながらここはChatGPTからコピペしてる)、イシューを作る
デリバリー(スプリント)
- 成果物: デリバリー(ドキュメントとコードベース、本番アプリケーション)
- やること
  - プランニング
    - AIと作業計画を立てる(ゴール、作業計画、依存関係)
      - イシュー全てを取得し優先度をつけて並べる
      - イシューの依存関係を分析し、クリティカルパスを特定する
      - 親イシューを作る
        
        ゴール: スプリントが終了したらどうなっているか
        
        作業予定のイシュー: 作業予定のイシューが紐づく
        
        作業計画: 僕は並行関係にある列と依存関係にある行でマトリクスを作り、最初の列を1スプリントで消化するタスクとすることがおおい。
  - 実行
    - 作業計画に従って、1イシュー1エージェントで作業する
      - 各イシューは、以下を行う
        
        仕様書と実装とテストが整合した状態を保つ
        
        CIとレビューを経たマージ可能なPRを作成する
        
        自分のセッションを振り返ったレポートを作成する
  - レトロスペクティブ
    - 各イシューのレポートを集約し、次の課題を発見する
    - 重要な課題については、イシューを作成し、次スプリント以降で対応する

どの程度AIに任せるか、バイブスとロジックの両立

エンジニアリングとして行うのはイシュー→仕様、テスト、実装というプロセスや品質の指標を設計し、AIのフィードバックサイクルを回すこと。実装作業、イシューから仕様、テスト、実装のどれが最初に変更されるかなど、TDDをお勧めしつつもエージェントに任せている。最近のClaude Codeマジで賢いので。

仕様と、テスト、実装が整合しているべきという認識は徹底する。そうであれば必要に応じて問題は発見できるし、何が正しいかも判定しやすい。多くの場合、仕様と実装が整合してればテストが考えられるし、そのほかも然り。ただ、これを完全にAIに任せると謎仕様と謎実装と謎テストが整合させられてしまい、抜けられなくなる。

PO的に、スプリントプランニングとスプリントレビューは必ずやる。これをやることで、現在の状態であるアプリケーションの状態のメンタルモデルが自分の中にできるので、イテレーションのサイクルも回り出す。

/fix {issueNum}というコマンドを呼ぶだけという意味ではVive Codingだが、このようなプロセスや、マージできるPRを作らせるためのチェックリスト、品質指標は結構厳格に作っている。詳しくはClaude Codeの設定をベストプラクティスで見直したを参照。

まとめ

ここまでくるともはやプロセスの改善自体もプロセスに含まれるので、プロセスはもうよくてあとは本当に本質的に価値のあるプロダクト作るだけって感じになってきてる。それが一番難しいんだけど。

k4h4shi.com

エクスプローラー