はじめに
圧倒的な爆速のアウトプットをしてくれるAIの話題に事欠かない昨今ですが、
特にClaudeCodeでのサブエージェントの活用などによる並列化の話題が全面に感じることが多いと個人的には考えています。ただ、実際にそれを適用するときにいろいろと気になった点がありました。
私の思考
- まだすべてを人が介在せずにアウトプットを確定させる段階にはなっていないのではないか
- システム開発担当としてより良い状態のシステムを開発する必要がある
- 自身(や同僚)がちゃんと理解した状態でないと、その状態にはならないはず
- AIのアウトプットから学びや気づきを得て、次に生かせるようになることは重要
- 並列化しても、どこかで人の部分でボトルネックになるのではないか
- では、どのように人が介在すべきか
以降の本投稿の内容については、「なぜ作るか」「何をつくるか」といったフェーズは完了し、
実際に1つのコンポーネント(何らかのAPIやUI)をスクラッチ開発する際に適用していることとなります。
チームは少人数で構成され、スケジュールもタイトである状況ではありつつ、品質面は確保することを重視しています。
開発フェーズの定義
私は以下のような進め方を採用しました。
| フェーズ | 概要 |
|---|---|
| ① | リポジトリ土台の定義 |
| ② | アーキテクチャ定義＋単一機能の動作確認 |
| ③ | 機能追加（レールに乗る） |
2. 各フェーズの詳細定義
フェーズ①：リポジトリ土台の定義
| 項目 | 内容 |
|---|---|
| 目的 | 開発環境・構成ルールの確立 |
| 成果物 | ディレクトリ構成、READMEやCLAUDE.mdなどの定義 |
| 完了基準 | 管理方針、実装方針が一定妥当であること |
| レビュー方針 | 必須（構成の誤りは全体に波及） |
| AIの役割 | ボイラープレート生成、設定ファイル生成、依存関係の調査補助 |
| 人間の役割 | 構成の最終判断、セキュリティ設定の確認 |
フェーズ②：アーキテクチャ定義＋単一機能の動作確認
| 項目 | 内容 |
|---|---|
| 目的 | 拡張可能な「レール」の確立 |
| 成果物 | レイヤー構成、DB設計、API設計、動作する単一機能、テスト |
| 完了基準 | 1機能が正常に動作し、コードが設計方針と一致している状態 |
| レビュー方針 | 必須（ここでの設計ミスはフェーズ③全体の手戻りになる） |
| AIの役割 | 複数設計案の生成・比較、実装コードの生成 |
| 人間の役割 | 設計案の選択・判断、コードレビュー、セキュリティ観点のレビュー |
フェーズ③：機能追加（レールに乗る）
| 項目 | 内容 |
|---|---|
| 目的 | ②で確立したアーキテクチャに沿った機能の量産 |
| 成果物 | 各機能の実装コード、テスト |
| 完了基準 | CI（自動テスト）がパスすること |
| レビュー方針 | 原則スキップ。セキュリティ・情報漏洩のみ確認 |
| AIの役割 | 実装コードの生成（メイン担当） |
| 人間の役割 | セキュリティ観点のレビュー、CI結果の確認 |
細かい作りの部分は最初の①②で決めきるのを基本としており、「もくもくと作った」部分には、
(私個人は)特段興味が無く、またこれまでAIのアウトプットを信頼する進め方となります。
スクラッチ開発での並列化のリスク
version1開発時にいきなり複数機能をエージェントで並列開発するのは妥当なのか？という疑問が生じました。
具体的には以下の例のような状態が発生しうると想定しています。
- 機能A実装 → 設計の誤りなど発見
- 機能B実装 → ↑の誤りのまま進む
- 機能C実装 → ↑の誤りのまま進む
スクラッチ開発の初期は「アーキテクチャが本当に正しいか」がまだ検証されていない段階です。
この例の場合は、3機能分の手戻りが発生することとなります。
気づいた点で再度AIに修正を依頼するのはその通りなのですが、もう少し最初の段階で詰めておくべき部分はあると考えています。(それでも何かしらは発生する可能性は十分にあると考えます)
並列化を行うのは3〜5機能(テストコード含む)を実装し、アーキテクチャが安定したと判断できた時点がより良いと考えています。
無事にversion1が市場投入され、動作実績がある程度できた段階でのversion2開発では、
(version1のレールに乗るような機能追加であれば)並列化での開発は安心感が高まると考えています。
並列化の効果マップ
以下は、並列化の恩恵がどこで得られるかを事前に検討したものです。
AIの圧倒的なアウトプットを武器に、「実装を2パタン作らせて見比べる」のようなこともできるとは思いました。(1つを突き詰めて良くしていくのがいいのか、このような見比べがいいのか、どちらがworkするか・・・は検証する価値があるかもしれません)
| フェーズ | タスク種別 | 並列化効果 | 理由 |
|---|---|---|---|
| ① | ボイラープレート生成 | ◎ | 独立したファイル群の生成 |
| ① | 設定ファイル生成 | ◎ | 相互依存が少ない |
| ① | 土台のレビュー・意思決定 | ✕ | 人間のボトルネックは変わらない |
| ② | アーキテクチャの判断・決定 | ✕ | 直列の意思決定が必要 |
| ③ | 独立した機能単位の実装（初期・レビューあり） | ✕ | アーキテクチャ未安定＋PRが積み上がる |
| ③ | 独立した機能単位の実装（安定後・CI整備済み） | ◎ | 設計安定かつ品質ゲートあれば並列効果あり |
| ③ | 共有モジュールの改修 | △ | 競合リスクあり。設計で分離すべき |
| 全般 | ジュニアの理解向上 | ✕ | 理解は並列化できない |
終わりに
現在この進め方を、個人的には納得して進めることはできています。
もし「レール」を作れないシステムの場合であれば、このようにはいかないのではと思います。
(レールを作れない開発に出会ったことがないです)
その他ですが、実装部分がある程度お任せにできている反面、レビューの部分がやたらと大変かつ億劫に感じています。自身でコーディングすることがある程度の「癒し」になっていたのかなと考えたりします。
皆様からみたら、「遅い開発」になるのかもしれません。
どこが削れるか、今後も意識していこうと考えています。