tl;dr
- 動く試作を開発初期に作ったことで、bizとの認識合わせと体験検証が前倒しされた
- その結果、外部仕様のズレだけでなく、内部設計の改善にも早く到達できた
- AIコーディングエージェントの価値は実装速度そのものよりも、検証と学習の順序を入れ替えられることにある
何をやったか
今回の開発テーマは、アプリケーション内のLP的なコンテンツページをハードコードからCMSに置き換えるというタスクだった。
対象は5ページ前後。もともと社内デザイナーがデザインを作り、bizがそれをエンジニアに渡して実装する流れだったが、既存ページはガッツリとハードコードされており、ページごとに細かい仕様やデザインの違いがあった。CMS化にあたっては、それらのルールを把握しながら置き換える必要があった。
そしてこのタスクでは、実質的なユーザーが社内のbizだった。biz自身がCMSに入稿して使う側なので、仕様書をレビューするよりも実際に触ってもらった方がズレが見えやすい。つまり、フィードバックまでの距離が近く、検証コストが低い状況だった。
従来ならどう進めていたか
うちのチームはスクラムで1スプリント1週間で回していて、1スプリントに1プロセスを進めるのがスタンダードだった。
つまり、仕様検討に1スプリント、設計に1スプリント、実装に1スプリント。最終的にbizが使えるようになるのは3週間後。しかも初週の仕様検討の段階では、誰もページ全体のルールを完全には把握していないので、まともなフィードバックは得られていなかったと思う。
この設計先行フローには合理性もあった。各スプリントで合意のタイミングが明確なので、チーム内の進め方が揃いやすく、不安が減る。何から着手すべきか迷いづらい。チームとしてそのやり方でうまく回っていた。
なので、今回の記事で従来のフローを否定したいわけではない。
今回変えたこと
今回は、着手1日目でコーディングエージェントを使って手元で動く状態まで作り、2〜3日目にはチーム内レビューに回して実際に触ってもらった。
このやり方に切り替えられた背景はいくつかある。
- 他チームでAI駆動で似た進め方をしている人に触発された
- 「ユーザー目線のフィードバックを入れたイテレーションを3回くらい回すと、ユーザー要望にも応えやすく内部品質も良くなる」という話を見た
- チーム内にも「そろそろAIネイティブな開発フローにしないと厳しい」という空気があった
- ちょうどその時期から、従来のような設計チケット消化型ではなく、オーナーが比較的自由に進められるスタイルに変わった
- そのため、既存の進め方を壊す心理的コストが低かった
bizにフィードバックをもらう場は、スクラムの朝会を使った。biz・devが全員いる場なので、動くものを見せれば自然とコメントがもらえる。「意見もらえたらラッキー」くらいの温度感だったが、実際にはかなり具体的なフィードバックが出てきた。
何が起きたか
想定していた仕様では漏れていたポイントに、早い段階で気づくことができた。
出てきたフィードバックは大きく2種類あった。
表示の柔軟性に関するもの：
- 注釈などでフォントサイズを変えたいケースがある
- ページ下部に補記（「〇〇のページに遷移する」など）を入れたい
- 重要事項説明書のようなファイルを複数で表示するパターンがある
- 特定ページのデザイン再現が難しい → ある程度類型化した上で、自由にレイアウトができるフィールドを追加できると汎用性が高そう
データ構造に関するもの：
- 朝会にエンジニアも同席していたので、CMSの画面を見ながら入稿スキーマについてもフィードバックがもらえた
- エンジニアから「よく使うパーツはコンポーネント化していけると楽そう」という発言があった
これらは、仕様書ベースのレビューでは出てきづらい類のフィードバックだった。実際に入稿してみて初めて「ここが足りない」「ここはこうしたい」が具体化するタイプのもので、体験ベースの検証が前倒しされたからこそ得られたと言える。
内部設計への波及
ここで面白かったのは、外部仕様のフィードバックが内部設計の改善にもつながったこと。
きっかけはdevの「よく使うパーツをコンポーネント化できると楽」という発言だった。これを受けて、CMS側のオブジェクトタイプをセクション単位で分けて、フロントのコンポーネントと1:1に対応させる構造を思いついた。結果として、入稿時の操作とコードの構造が対応するのでメンテナンスしやすくなった。
また、1回目に作ったのはあくまでプロトタイプだったので、2週目にはフィードバックを踏まえて作り直すことができた。AIに書かせたコードは雑なポイントも多かったが、外部仕様の変更に合わせて改めて整理することで、より凝集性の高い構造にできた。
プロトタイプのコードは一回捨てて作り直している。試作をそのまま本番に出した話ではなく、試作で得た学びをもとに、2周目でより良い設計で書き直したという話だ。
（正直に言うと、内部品質がどの程度向上したかは定量的には言えない。ただ、フィードバックなしにいきなり設計していたら到達しなかったであろう構造には到達できたと思う。）
AIの役割
「AIで爆速開発できました」という話にはしたくない。今回のポイントはそこではない。
AIの役割は、試作の初速を出した触媒だった。
具体的に言うと、AIなしの場合はまず既存のページをひとつひとつ調べて、CMSのスキーマをどうするかじっくり考えるところから始めていたはず。各工程に1〜2日かかってもおかしくなかった。
AIを使ったことで、「一旦既存のページ全部さらってCMSのスキーマに整理して」で一気に土台が出てきて、それをCMSに入れるのもAI任せで早かった。画面の実装もAIにやらせた。結果として、手書きなら数日かかっていた工程が1時間程度に圧縮された。
ただし、ここで重要なのは単に速くなったことではなく、速くなったことで「雑に作って壊して作り直せばいい」という発想自体が生まれたことだ。AIなしだったらスクラップビルドという選択肢はそもそも思いつかなかった気がする。
つまり、AIの寄与は2つある。
- 試作を作る時間を圧縮した（各工程1-2日 → 約1時間）
- 「作り直し前提で進める」というプロセス変更の心理的ハードルを下げた
今回ワークした条件
ここまで書いてきた話は、いくつかの条件が噛み合ったからワークしたと思っている。正直に整理しておきたい。
フィードバックの距離が近かった
今回はbizが社内にいて、しかも実質ユーザーだった。朝会で動くものを見せればその場でフィードバックが返ってくる。toC向けのアプリケーションで外部ユーザーが相手なら、そもそも検証したい仮説の組み立てからもっとシビアにやるべきだし、誰からどうフィードバックをもらうかの座組も違ってくる。
題材がCMS化だったから効いた可能性がある
今回は「触ってみるとズレが出やすい」テーマだった。入稿してみて初めて「ここが足りない」が分かるタイプの仕事。ドメインルールが重い領域やバックエンド中心の変更では、そもそも「動くもの」の定義が違うし、触って検証できる範囲も限られる。同じやり方がどこでも効くとは限らない。
テスト基盤があった
これはめちゃくちゃ大きい。今回はStorybook + Chromaticでほぼ完全なVRTが実現できていたので、「最終確認はVRTで」と割り切れた。だから雑に壊しに行けた。テスト基盤がない現場で同じことをやると、作り直しのたびにデグレのリスクを抱えることになる。「雑に壊せる」ための安全網は、このやり方の前提条件だと思う。
言えることと、まだ言えないこと
今回の経験から言えるのは、少なくとも以下の条件が揃ったとき、試作先行のプロセスは有効だったということ。
- ユーザーが近くにいて、すぐにフィードバックが得られる
- 触ってみることでズレが出やすいテーマである
- テスト基盤があり、壊して作り直すことの安全性が担保されている
そして、AIの価値は「速く書けること」そのものよりも、速く書けることによって検証と学習の順序を入れ替えられることにあった。従来なら設計→実装→検証だった流れが、試作→検証→設計→実装に変わった。認識合わせのタイミングが3週間後から数日後に前倒しされた。
これがより広い条件で成立するかは、まだわからない。ドメインルールが複雑な領域、バックエンド中心の変更、外部ユーザーが対象のプロダクトなどで同じように効くかは、今後試してみないと言えない。
今回は「たまたま条件が揃っていた」部分も大きいと思う。ただ、試作を先に作ることで設計の材料が先に増える、という構造自体は条件を選ばない気がしている。
