フロー効率よりAIのポテンシャルを!開発プロセスを「個人アサイン」にシフトした理由

こんにちは!ファインディでプロダクト開発部のVPoEをしている浜田です。

AI駆動開発が浸透するなかで、エンジニア1人あたりの開発能力は大きく向上しています。しかし、従来のチーム単位のアサイン方式のままでは、そのポテンシャルを十分に引き出せていないと感じていました。 この記事では、私たちが開発プロセスを「チーム単位」から「個人単位」のアサインへ移行した背景と、その結果得られた変化について紹介します。AI駆動開発を取り入れたものの、チームの開発プロセスをどう変えるべきか悩んでいる方に向けた内容です。

これまでの開発プロセス

ファインディのプロダクト開発部には複数の開発チームがあり、それぞれ5名前後のエンジニアにPdMとデザイナーを加えた構成で、協働しながらプロダクト開発を進めています。

これまでの開発プロセスでは、施策開発をチームにアサインし、メンバーそれぞれが優先度の高いタスクをフレキシブルに取っていくスタイルで運用していました。1つの施策開発をチームにアサインすると、結果的に4名程度のエンジニアが集中して取り組み、一気に開発を完了させるという進め方です。いわばフロー効率を重視した開発スタイルで、最も優先度の高い施策を最速で完了させることに注力していました。

この方式はチームの連携が生まれやすく、うまく機能していました。複数人が同じ施策に取り組むことで、設計の議論がその場で生まれたり、実装中に詰まったときもすぐに相談できたりと、チームで動くからこその強みがありました。

AI駆動開発で見えてきた課題

AI駆動開発の導入により、エンジニア1人が同時に扱える開発量は増えました。タスク分解をおこなって依存関係さえ明確にできれば、かなりの数のタスクをAIエージェントに渡して並列で進めることが可能です。加えて、これまではキャッチアップに時間がかかっていたような、自身の習熟度が低い技術スタックの部分であっても、AIをパートナーにして自力で開発を進められるようになりました。

しかし、フロー効率を重視した従来のスタイルでは、このAIのポテンシャルを十分に引き出せませんでした。複数のエンジニアで1つの施策を分担している状態では、一人ひとりが持つタスクの粒度はすでに細かくなっています。そこからさらにタスクを分解して複数のAIエージェントに並列で任せるのは難しく、AIの役割はあくまで副操縦士としての補助にとどまっていました。

加えて、タスクのアサインを明確に決めず、手が空いた人から優先度の高いタスクを取っていくスタイルでは、自分がこの先どのタスクを担当するかが見通せません。先の計画が立たない以上、AIエージェントに先回りしてタスクを渡して並列で進めてもらうこともできず、結局は目の前の1つのタスクをAIと一緒にこなすだけになってしまいます。

個人アサイン方式への移行

そこで、施策開発を個々のエンジニアにまるごとアサインする方式へと切り替えました。

1人が施策全体を担当することで、タスクの分解と計画を自分の裁量で行えるようになります。どの部分をAIエージェントに並列で任せ、どの部分を自分で手を動かすかを事前に整理できるので、AIを副操縦士ではなく、複数の作業を同時に進めるパートナーとして活用できるようになりました。

具体的には、Claude Codeのような自律型エージェントを用いて複数のワーカーを立ち上げます。そして、あるコンポーネントの実装やテストコード生成をそれらに並列で進めさせながら、自身は全体の設計やオーケストレーションに集中する、といった働き方です。 この「1人のエンジニアが複数のAIエージェントを指揮する」具体的なワークフローについては、以下の記事で詳しく解説していますので、あわせてご覧ください。

tech.findy.co.jp

フロー効率を重視していた頃と比べると、最も優先度の高い施策が完了するまでの速度は低下します。4名で集中して取り組んでいたものを1名で担当するのですから、これは当然のトレードオフです。しかし、エンジニア間のコミュニケーションコストが減ることや、AIによるアウトプット量と速度の向上により、大きく低下させることなく開発を進められています。さらに、2番目、3番目に優先度の高い施策も別のエンジニアが並行して開発を進めるため、個々の施策にかかる期間が延びても、結果としてより多くの施策を素早くリリースできるようになりました。

実際に、この変化は定量的な指標にも明確に表れています。以下のグラフは紹介した変更を行なった開発チームのPR(プルリクエスト)作成数の推移ですが、個人アサインへの移行を本格的に進めた2026年2月中旬以降、PR数が明確に一段増えていることがわかります。個人のポテンシャルを引き出すアプローチが、開発チーム全体のアウトプット最大化に繋がった形です。

PR数の推移グラフ

一方で、チーム全体のまとまりという意味では変化がありました。これまでのように全員で1つの開発に集中する場面は減り、どちらかというと個々の集まりに近い形になっています。

ただし、チームとしての連携を完全に手放したわけではありません。たとえば設計の方針に関わる判断は、個人で抱えずチームで議論してから進めるようにしていますし、実装についても「属人化」を防ぐためにプルリクエストをこまめに分割してレビューし合うプロセスを維持しています。さらに、各自が何に取り組んでいるかを定期的に共有する場を設けることで、お互いの状況が見えなくなることも避けています。つまり、チームとしての協働がなくなったのではなく、その関わり方が変わったというのが正確な表現です。

個人のオーナーシップを高める

AI時代だからこそ、個人を目立たせることが重要だと考えています。

チームの一員として開発に参加するだけでは、個々のエンジニアの貢献が見えにくくなります。極端に言えば、AIに代替されやすいポジションになってしまう可能性もあります。個人がオーナーシップを持ち、「これは自分がやった」と自信を持って言える状態をつくることが、エンジニアとしての価値を高めることにつながると思っています。

個人アサインに移行したことで、各エンジニアが担当する施策に対して当事者意識を持って取り組むようになりました。設計の意思決定からリリースまでを一貫して担うことで、施策全体を自分ごととして捉える姿勢が自然と生まれています。また、チームで開発していた頃はどうしても窓口がチームリーダーに集中しがちでしたが、施策ごとに個人をアサインしているため、メンバーそれぞれがPdMや事業メンバーと直接やりとりをおこなうようになりました。その結果、施策の背景やリリース後の効果に対する意識が上がるなど、良い効果が出ています。

これはマネジメントの観点からも好ましい変化でした。誰がどの施策を推進しているかが明確になるので、成果の可視化にもつながります。チームの中で埋もれるのではなく、一人ひとりの仕事が見える状態をつくることが、エンジニアのモチベーションにもよい影響を与えていると感じています。

技術改善が進みやすくなった

個人アサインに切り替えたことで生まれたもう1つの変化として、技術的な改善が進みやすくなったことがあります。

チーム全体で施策開発に集中していた頃は、技術改善やリファクタリングはどうしても後回しになりがちでした。個人にアサインされる形になったことで、自分の裁量で改善タスクを差し込みやすくなりました。実際に、以前はなかなか手がつけられなかったライブラリのアップデートやテストの整備といった地道な改善が、各エンジニアの判断で着実に進むようになっています。

チームとしてもリソース配分を明確にしました。施策開発、改善、その他の割合を7:2:1と定めたことで、「2割のリソースは技術改善に使おう」という共通認識が生まれ、改善活動に取り組みやすい環境が整っています。

まとめ

フロー効率を重視したチーム開発から、AIのポテンシャルを引き出す個人アサインへと開発プロセスを移行しました。個々の施策が完了するまでの速度は下がるものの、AIエージェントを活用した並列開発によってチーム全体のアウトプットはむしろ増加し、実際にPR数にもその変化が表れています。加えて、個人のオーナーシップが高まり、技術改善にも手が回るようになりました。

チームのまとまりが薄れるリスクはありますが、設計判断の議論やレビューといった連携ポイントを意識的に残すことでバランスを取っています。AI駆動開発を推進するなかで開発プロセスの見直しを検討している方の参考になれば幸いです。

ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。

herp.careers