プランナーがAIと開発してみたら、開発生産性が4倍・Issue作成時間が95%削減された話

※この記事は、2025 Speee Advent Calendar11日目の記事です。昨日の記事はこちら

こんにちは、Speeeでプランナーとしてプロダクト開発に携わっている石川澄怜です。

Speeeには新卒で入社し、今年で3年目になります。大学時代は、中世日本文学における「地獄」についてひたすら研究していました。

現在は、リフォーム検討ユーザー様とリフォーム会社様をおつなぎするマッチングサービス「リフォスム」のプロダクト開発を担当しています。

はじめに：プランナーによるAI開発を検討しはじめたきっかけ

私が担当する領域の開発チームでは、プロダクトの成長が加速し、実現したい企画が無数にある一方で、開発リソースが明らかに不足しており、従来の進め方ではスケールの限界が見えている状態でした。

この構造的な詰まりによって、日常的にいくつかの事象が発生していました。

大きな企画に注力したくても、実装に着手できるまでのタイムラグが大きい
SEO開発特有の“小さいが重要度の高いイシュー”が常に発生し、積み上がるほど全体を圧迫する
新設チームゆえにプランナー側のデータベース理解が浅く、仕様の確認や影響範囲の把握などで毎回エンジニアに依存してしまう

特に、SEO開発では“大きな企画”と“細かなリスク回避”が常に同時並行で発生し、両方をエンジニアが実装する進め方ではどうしても限界が生まれる構造でした。

同時に、世の中的には急速に AI を前提とした開発スタイルが広がり始めており、Speee でも産業 AX を実現するうえで、「エンジニアがより複雑な課題や新しい技術探索に集中できる状態をつくる」ことがますます重要になってきていました。

この状況を前に、私たちがまず考えたのは「限られたリソースでどうスループットを最大化するか」という視点でした。

どこにエンジニアの時間を集中すべきか
どこならプランナーが AI と協働して巻けるのか
役割分担そのものを見直した方が早いのではないか

そういった整理の結果として、「企画の背景やユーザー理解を最も深く持っているのは企画者自身である」というシンプルな事実に立ち返りました。

企画の背景・意図・ユーザー課題をもっとも深く理解しているのは企画者自身であり、軽微な修正や調査であれば、むしろ企画者がそのまま実装した方が早いケースは少なくありません。

一方で、スキーマ設計や難所の実装、アーキテクチャ判断といった高度な領域はエンジニアの専門性が不可欠です。

そこで私たちは、AI (Claude)を前提とした新しい開発フローを取り入れ、“プランナーも開発に踏み込み、エンジニアはより難易度の高い領域に集中する”という両輪体制の構築に取り組みました。

まずは「小さな Issue を AI と一緒に実装してみる」から始めた

まずは、開発効率を上げるために軽微な Issue や調査タスクを AI と協働しながら自分で実装してみるというところからスタートしました。

しかし、実際にやってみると以下のような壁にぶつかりました。

Git の初歩的な操作ミスから手戻りが発生

プランナーとして Issue を起票する以外では Git を扱う機会がなく、ブランチを切る・PRを作成する・マージ・レビュー依頼といった開発フローに必要な基本操作には全く慣れていない状態からのスタートでした。

実際、当時は次のようなミスが頻発していました。

最新の master を取り込まず作業開始して、コンフリクト地獄になる
前のブランチで作業していたコミットがそのまま PR に混ざる

こういった基本操作でつまずくたびに、チームのエンジニアさんに助けてもらう場面が続きました。軽微な変更のつもりが、結果的に手戻りを生んでしまうこともしばしばありました。

特定箇所の軽微な修正のはずが予期せぬ場所に影響する

プランナーである自分がどのコンポーネントがどこで使われているのか把握できていないうえに、AI 側もコンポーネントの責務境界までは十分に理解できていませんでした。

これにより、「特定のページだけ直したつもりが、別のページの表示が崩れる」といった事象が発生しました。

特に、当時は View用のテンプレートが広く共通化されていたこともあり、どのファイルがどのページを担当しているのか判断がつかず、“軽微な修正” のはずが思わぬ副作用につながるケースが頻繁に起きていました。

Windows環境で開発していることによる弊害

当時のプランナー用 PC は Windows だったため、Rails × Docker のローカル環境を再現できない問題がありました。

その結果、

フロントのちょっとした表示変更ですら、ローカルで確認できない
よって、毎回ステージングにデプロイし、動作確認が必要になる
小さな修正の検証に 15〜30 分単位で待ち時間が発生する

という非効率な状態に陥っていました。

こうした課題が重なり、「プランナーが AI を使って軽微な開発を巻く」どころか、むしろチーム全体の負荷が一時的に増えてしまう状況が続いていました。

そこで、私たちはプランナーが安全かつ効率的に開発へ踏み込めるようにするため、「環境への投資」と「ルールづくり」に舵を切りました。

プランナーが安全に開発へ踏み込むために行った環境整備

軽微な Issue を AI と協働して進め始めたことで、「プランナーがどこでつまずき、どんな事故が起きやすいか」が徐々に可視化されていきました。

開発をする中で発生した事象を都度エンジニアに共有し、エンジニアはそれを“構造的に解消する仕組み”として環境やルールに落としていくラリーを重ねることで、プランナーでも安全に開発へ踏み込める土台をチームとして整えていきました。

ここでは、その中でも特に効果の大きかった取り組みを紹介します。

取り組み①：View用のコンポーネント規約の整備

当時のリフォスムは、View用のテンプレートが広く共通化されていたこともあり、「このファイルを直すと、どのページが影響を受けるのか」を私自身が把握しきれず、AI も責務範囲を十分に理解できていない状態でした。

そこでエンジニアに、ページ単位でコンポーネントを管理するための “View用のコンポーネント規約” を docs としてまとめてもらいました。

この規約では、

ページ固有のコンポーネントはページ内で完結すること
共通化する場合はデザイン・データ構造・振る舞いが完全に一致するものに限ること

といったルールを定義し、影響範囲を構造的に分離しました。

これにより、指示に対して修正して良い領域と、触るべきでない領域の境界が明確になり、軽微な修正を安心して進められる下地が整いました。

取り組み②：ブランチ切り替えのつまずきをなくすために、Git worktreeを導入

AI と協働して開発を進めるうえで、特に効果のあった取り組みは「Git 周りの環境整備」です。

どのブランチで作業しているのか、気づくと分からなくなってしまう
作業中のブランチが分からなくなり、意図しない差分が PR に混ざってしまう

こうしたミスを構造的に無くすために導入したのが Git worktree です。 Issue ごとに作業フォルダを完全に分離できるため、ブランチの切り替えによる混線が起きなくなり、プランナーの私でも安心して作業を進められるようになりました。

さらに、この仕組みはエンジニア側にも効果が大きく、複数の Issue を並列で進められるようになったことで、エンジニア自身の開発スループットも劇的に向上しました。

取り組み③：AIの解釈精度を上げるために、よく使う前提知識を「CLAUDE.md」へ体系化

AI と協働して開発を進める中で、「どんな Issue ならラリーなく実装まで走り切れるのか」が少しずつ掴めてきました。一方で、実装に入るまでに何往復もラリーが発生する Issue を振り返ると、そこにも明確な共通点がありました。

それは、リフォスム固有の“文脈や判断基準”が Issue の中に存在しないと、AI の解釈が必ずズレてしまう という点です。

同じ「クライアント」という言葉でも、掲載対象のクライアントと、施工情報を編集できるクライアントは全く別の概念であること
「エリア」や「部位」など、普段チーム内で当たり前に使っている言葉にも、リフォスム独自の定義や範囲があること
サイトの構造や検索体験に関する「暗黙の前提」が多く、Issue に書かないと AI は正しく読み取れないこと

こうしたプロダクト固有の文脈を知らないまま AI に投げると、AI は “あり得る一般的な実装” を返してしまい、意図と違うコードが出てくる。それを修正するために説明を追加し、またやり取りが増えるという構造になっていることに気づきました。

AI がなぜ意図と違う解釈をするのかを一つずつ追いかけた結果、「Issue では説明しきれない“リフォスムの前提”がボトルネックになっている」と分かりましたが、この問題は、実際に自分で実装してみたからこそ気づけたことでもあります。

こうした問題に対して、よく使う概念・判断基準・サイト構造・領域ごとの前提ルールを「CLAUDE.md」として体系化し、AI が最初からこの文脈を理解して動けるようにしました。

チームのCLAUDE.mdです。諸々のdocsと合わせると1,000行を超えそうです。

その他の取り組み

環境面でも、プランナーが開発を自走しやすい状態に整えていきました。

開発用PCとしてMacを導入したことで Docker が使えるようになり、フロントの表示確認をローカルで完結できる環境をようやく用意できました。

これにより、以前のように「小さな UI 修正でもステージングへ都度デプロイしないと確認できない」という待ち時間のロスが解消され、実装 → 確認 → 修正の回転速度が一気に上がりました。

また、プランナーが実装した小さな Issue については、複数の修正ブランチをまとめてステージングにデプロイし、まとめて動作確認するフローを取り入れることで、エンジニア・プランナー双方の確認コストを大きく削減できました。

取り組みの結果：開発生産性は約4倍まで向上した

こうした環境整備と役割設計の見直しにより、「プランナーが安全に開発へ踏み込み、エンジニアが難所に集中する」という両輪体制が少しずつ機能し始めました。

特に効果が顕著だったのは、“軽微〜中規模の開発タスクが、プランナー×AI のラインで高速に処理されるようになった” という点です。

その結果、定量的にも明確な変化が出始め、チーム全体の開発生産性はおよそ4倍に向上しました。

思わぬ複利：1つのイシューが3分で書けるようになった

また、この取り組みは思わぬ部分に大きな複利を生みました。ドメイン知識を蓄積させる目的で育てたCLAUDE.md が充実するほどAI の理解が深まり、結果として：

Issue に書く内容が簡略化される
要件が短くても意図通りのコードが返ってくる
プランナー側の起票・説明コストがさらに下がる

という “AI の理解が積み上がるほど、チーム全体の生産性が加速度的に上がる” 構造ができました。

結果的に、1issueあたり30分~1時間ほどかかっていた起票作業が、現在では1issueあたり3分で完成できるようになりました。

チームに起きた変化：役割の境界が自然と重なり始めた

AI と協働しながら開発する取り組みを続けたことで、チームの働き方そのものに変化が生まれ始めました。

プランナーは、コードの依存関係やデータ構造を理解しながら要件を書けるようになった
結果、実現可能性と難易度を踏まえた“精度の高い企画”が出せるようになった
エンジニアは、本来の専門性が活きる領域に集中できるようになり、余白と裁量が確保された
開発の詰まりが減り、チーム全体のスループットが向上したことで、「もっと価値ある企画をたくさん出す」フェーズへ移行できた

このフェーズの移行にともない、プランナーは Why / What といった価値探索により集中し、How の裁量はエンジニアへ大きく委ねられるようになりました。

一方で、How の判断には施策の背景や「なぜやるのか」の理解が不可欠なため、エンジニアは自然と Why に踏み込み、価値を見据えた技術的打ち手を提案してくれるようになりました。

さいごに

今回の取り組みがもたらした価値は、単にプランナーが実装できるようになっただけでなく、AI の力で役割間に適切な「のりしろ」が生まれ、プランナーとエンジニアが互いの専門性をぶつけ合いながら、チーム全体のスループットを一段階引き上げられた点にあると感じています。

Speee社内でも初めての取り組みではありましたが、産業AXに対する挑戦を受け入れ、積極的に開発環境への投資の後押しや、支援をしてくださったマネージャーのさとーるさん、プランナーAI開発プロジェクトを牽引してくださっている嶋さん、そして日々目標のために奮闘してくださっているチームのエンジニアさんなど、本当に多くの方々の支えがあって、大きな成果を出すことができました。

特に大きな推進力になったのは、私が開発へ踏み込むたびに発生したつまずきを一つひとつ受け止め、「どうすれば仕組みで解消できるか」を粘り強く一緒に考え、伴走してくれたエンジニアさんの存在だったのではないかと思います。

リフォスムはまだ立ち上げフェーズにあり、検索体験の改善からコンテンツ開発、データベース構造の拡張など伸ばしていける領域がたくさん残っています。今回の取り組みで得られた武器を土台に、リフォスムがもっとユーザーにとって価値あるサービスとしてスケールしていけるよう、プランナー・エンジニアのチーム一丸で挑戦を積み重ねていきたいと思います！

Speeeでは一緒にサービス開発を推進してくれる熱い仲間を募集しています！

新卒の方はこちらより本選考に申し込みが可能です！キャリア採用の方はこちらのFormよりカジュアル面談も気軽にお申し込みいただけます！

Speeeでは様々なポジションで募集中なので「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！