AI駆動でプロセスを一から組み替えたら何が変わったか — PM視点の体験記

こんにちは、Confit PM（PdM兼PjM）のあらきです。
AIとともに仕事をするのがすっかり当たり前の世の中になってきました。弊社でも、以前ブログでお伝えした通りClaudeを業務に取り入れています。
私も世の中の人がどんな取り組みをしているのか参考にしようと、「AIエージェント 開発 PM」といったワードで検索してみましたが、出てくるのはデータ分析や意思決定の話が多く、「開発プロセスをどう変えたか」「PM自身は何を感じたか」という記事はなかなか見つかりませんでした。
そこで今回は、私が新規開発案件でAI駆動を前提に開発プロセス全体を組み替え、実際に何を変えたか、変えてみてどうだったか、PM視点でお伝えしていきます。
なお、実装者視点の話も含めるとかなり長い記事になってしまうので、今回は「開発の進め方がどう変わったか」に重点を置いています。実装者視点の話は、別途エンジニアがブログを書く予定ですので、そちらをお待ちください。

プロジェクト概要

まず今回のプロジェクトの概要を簡単に説明します。今回は演題登録機能（研究者が学会に演題を提出する機能）のリニューアル案件です。

• 開発期間：約5ヶ月
• 画面数：約50画面
• 体制：PM1名、デザイナー1名、基盤担当1名、エンジニア2名
• 技術：TypeScript / Next.js（一部Kotlin）
• 主なAIツール：Claude Code（実装・テスト・レビュー）、Claude（仕様整理）

リニューアル案件では、既存DBをそのまま引き継いで上物のプロダクトだけ作り直したり、一部の機能を既存プロダクトから流用したりするケースもありますが、今回はデータ設計も含めて完全に一から作り直す前提でした。そのため、AIエージェント開発に合わせてプロセスや仕組みを一から練り直すのにちょうど良いプロジェクトでした。
このプロジェクト以前もAIエージェントは使っていましたが、バッチ処理や小規模な拡張が中心でした。ユーザー体験が問われるプロダクトで本格的に使うのは初めてだったので、AIエージェントにどこまで任せられるのか、楽しみな開発でした。

数字で見る「従来の開発 vs AI駆動開発」

従来の開発と、AI駆動開発で、どれくらい差があったか？結果を先にお見せします。AIエージェント登場前の、Confitオンラインプログラムサイトのリニューアル案件と比較して見てみます。

開発スピードはどれくらい上がったか？

項目	前回(従来の開発)	今回(AI駆動開発)
実装者の人数 × 期間	10人 × 24ヶ月 = 240人月	2人 × 5ヶ月 = 10人月
画面数	170	50
画面あたりの工数	約1.4人月	約0.2人月

「最初にコードを書き始めたタイミングから、リリースまで」の試験工程も含めた開発期間で比較しています。単純計算で約7倍の開発スピードです。前回とは利用技術が違うことや、画面あたりの複雑さが一様でないことは差し引いて考える必要がありますが、それでもかなりのスピードアップにつながっています。

品質保証をどうしたか？

AIエージェントで開発する際の悩みとして、AIが大量に作った機能をどうやって品質保証するかという点があげられます。短期間で大量の成果物が発生するので、コードレビューもテストも大変なことは想像に難くありません。
今回のプロジェクトでは「AIが作った実装物は、外部委託で実装したものと同じように品質保証をする」つまり「コードレビューではなくテストで品質を保証する」方針にしました。
この方針にした理由は単純で、AIが書くコード量が多すぎるからです。今回で言えば実装コードだけで約25万行なので、コードレビューで読み切って品質を判断するのは現実的ではありません。実際はレビューを全くしないわけではなく、Claudeによるコードレビューと実装者の簡単なレビューも組み合わせていますが、品質保証の主役はテストです。
また、テスト自体もできるだけ自動テストを整備する方針としました。人がやるテストは、社内ワーキンググループによる機能評価と、自動化しにくいUX面に絞っています。大量に実装された機能の全パターンを人が確認するのは時間がかかりすぎますし、何より、人は同じ確認を何度も繰り返すほど見落とします。正確に繰り返すことに関しては、機械に任せた方が確実です。
実際のテストコード量は以下の通りです。

項目	前回(従来の開発)	今回(AI駆動開発)
コード量	総数：約45万行 うち実装コード：約30万行 うちテストコード：約15万行	総数：約61万行 うち実装コード：約25万行 うちテストコード：約36万行
コード全体に占めるテストの割合	約3割	約6割

今回はテストコードをかなり厚く整備していることがわかります。従来の開発では、テストコードは時間の都合でどうしても後回しになりがちでした。AIエージェントを使うと、実装と同じスピードでテストも書けるため、開発初期からテストを揃えた状態で進められます。結果として、リリース時点で今後の保守開発を支える品質保証の基盤を作れたのは重要な成果でした。

その他開発プロセスの変化

ここからは、数字には出にくいプロセスの変化を3つ紹介します。

一番のインパクトは「チームが小さくなった」こと

私個人の中で一番インパクトが大きかったのは、小さいチームで大きなプロダクトを作れるようになったことです。
これまで大規模開発を始めるときは、「まず人を集める、終わったら解散」という流れでした。初対面のメンバーも集まるので、その前提でチームビルディングをするのもPMの仕事の一つでした。今回の開発も、従来であれば実装者を10人くらい集める必要があったと思います。
しかし今回は、エンジニア2人、全体でも5人のチームで進められました。勝手知ったるメンバーでそのまま作り始められますし、人数が少ない分、コミュニケーション経路も少なく、意思疎通のコストが目に見えて下がりました。
チームが小さくなった分、一人ひとりの役割は逆にはっきりしました。PMは要件レベルの取りまとめと、「何をどの順番で作るか」を決めることに注力します。エンジニアは、コードを書く人から、要件を詳細仕様に落とし込み、AIの実装を見極めて品質を担保する役割に変わってきています。

仕様書を固めてから作る → 作りながら固める

従来は「仕様書を固める → 実装する → できたものを評価する」でしたが、今回は「要件を満たすレベルでざっくり実装 → プロトタイプを動かしながら詳細仕様を固める」という手順で進めました。
こうすることで、「こうなるとは思っていなかった」という認識齟齬を早めに潰せます。また、「仕様検討段階では良いと思っていたが、いざプロダクトに載せてみると使いずらい」といった体験齟齬にも早い段階で気づけます。この2つを前半で潰せたので、プロジェクト後半は品質保証に集中できました。
ただ、エンジニアは「作り切ってから機能評価が入る」動きに慣れているので、「仕様検証できる程度に作り込む」という塩梅をエンジニアが掴むのも、PMが言語化するのも、難しい面はありました。これはPMとエンジニアの共通感覚として少しずつ育っていくものなので、仕様の揺れに付き合ってきたベテランエンジニアほど、その塩梅を掴むのが上手でした。

静止画でデザインレビュー → 動くプロダクトでデザインレビュー

これまでのデザインレビューは静止画で行っていましたが、今回はプロダクトに載せた状態で行いました。実際に触りながら確認できるので、静止画では気づきにくい操作感や画面遷移の違和感を早い段階で見つけることができます。ここは前述の仕様検証と同じ効果が出ています。
一方で期待と違ったのが、UI実装そのものです。デザインシステムとコンポーネントを渡せば、Claudeが良い感じにUIも作ってくれるのでは、と楽観的に始めたのですが、デザインシステムがあるのに独自実装をしたり、HTMLの構造が雑だったりと、UIを丸ごと任せるにはまだ厳しいという結論になりました。「人が目で見て感じる違和感」をAIが検知しにくい、というのも全体を通じて感じたところです。「デザインは人が作り、実装はAIと一緒に」が今の落としどころと考えています。

おわりに

ポジティブなことを色々書いてきたのですが、開発をやり切った率直な感想は、「AIに追い立てられて息つく暇がない」でした。これまで、仕様書を書き終えてからエンジニアが実装している期間は、PMにとって少し息をつける時間だったのですが、実装があまりに速いので一息つくタイミングがあまりありません。これはエンジニアも同じなので、意識的に「この期間は少し休もう」と設定していくことも大切だろうと思いました。
それでも、新しい前提に合わせて開発プロセスを一から組み直し、試しながら変えていったこの5ヶ月は、私にとって非常に楽しいものでした。今後も世の中の変化に合わせて、最善のプロセスを組み立てることを、楽しみながら続けていきたいと思います。