■ 1. 背景と概要
- 2018年に書いた記事（ビッグバンマージを避けて少しずつコードをマージするアプローチ）を2026年時点で更新
- コーディングAIを活用した現代の開発フローの考え方と望ましい進め方を整理
■ 2. 2018年版フローの課題
- 設計・全容の共有が難しい:
- Pull Requestを小分けにすることで全体像が見えにくくなる
- リモートワーク普及によりホワイトボードでの認識合わせが困難になった
- レビュワーの分断:
- GitHubでランダムにレビュワーをアサインすると、シリーズ物のPRを別人がレビューすることになり全体の整合性が失われる
- チームの対策: レビュワーをプロジェクト単位で固定し、実装者と別の担当者がQAを行う
- 実装速度とレビュー速度のミスマッチ:
- コーディングAIにより数分でコードを生成できるが、レビューに1日待つ状況が生じる
- 前半のPRにレビューで方針転換が生じると後続PR全体に変更が波及し、誰も嬉しくない結果になる
■ 3. 動くプロトタイプの活用
- 2026年時点ではコーディングAIに依頼することで数分〜1時間以内に動くプロトタイプを入手できる
- プロトタイプを作ることで以下が明確になる:
- 企画情報だけで仕様として足りているか
- 曖昧で検討が必要な仕様が残っていないか
- 当初の設計に矛盾や破綻がないか
- 動くものが手に入ること自体に大きな価値がある
- ステークホルダーとの共有に活用する:
- ディレクターに動きを確認してもらい、希望や未決事項を議論する
- 両方の案を実装して比較検討することも可能
- エンジニアとはコードを見ながら完成時点の設計を事前に議論できる
■ 4. レビュワーに合わせたPull Request分割
- プロトタイプは速度重視で作成する:
- エッジケース、エラーハンドリング、テストは省略
- デバッグもAIに任せ、動くまで試行錯誤させる
- プロトタイプをそのままリリースはできないため、本番相当のコードへ作り直す
- 本番コードはエラーなく動作し、セキュリティや動作速度の要件も満たす必要がある
- Pull Requestの切り方:
- レビュワーが読める量の単位に分割してPRを作成する
- PR数とタイトルをレビュワーと事前に合意しておくことが望ましい
- コードの前でディスカッションしながらペアプログラミングで完成させる形でも良い
- ボトルネックの変化: 実装者の速度に律速していた従来から、レビュワーの速度に律速する形へ転換
■ 5. 工程の標準化
- 2018年の環境ではイテレーティブかつスパイラルな開発が一般的だった
- 現代の工程: ビッグバンなプロトタイピングを行ってから、人間が解釈できる単位に再構築する
- 一度に見るべき情報が増加する:
- 既存の本番コードベース
- 作成したプロトタイプ
- プロトタイプに対する人間のフィードバック
- 人間の認知がボトルネックにならないよう、各工程の入力と出力をスキル・手順として標準化することが有効
- 標準化の目的:
- 誰がやっても同じ結果を期待するのではなく、誰がやっても同じ前提情報を手にできることを期待
- 煩雑な情報収集を定型化し、取捨選択の判断を人間の仕事として残す
- タスクチケットの活用例:
- チケット本文を着手可能な形に整形し、チームのスキルへの案内を埋め込む
- AIにチケットを渡すことで、標準的な手順を自動的に実行させることができる
■ 6. 人間の役割: ろくろと陶芸家の関係
- 工程を書き下しても人間の仕事はなくならない
- ろくろの比喩: 回転させるのはろくろのモーターだが、土を触り器を形作るのは人間の手
- これからの開発者に求められるスキル:
- AIが出す前情報やプロトタイプをどう整理・解釈するか
- 複数の選択肢の中からどれを選ぶか取捨選択できるか