こんにちは、PM（プロダクトマネージャー）の嶋です。
今年は開発未経験のプランナー（PM・PO含む）がAIの力を借りてエンジニアなしで開発をする、というプロジェクトを行いました。AIなしの時代に戻れないほど業務体験が変わってしまったのでこれまでの取り組みを記事にしました。
まず、こんな経験はないでしょうか…？
「ちょっとした修正なのに、実装までに時間がかかる」
「バグの問い合わせがあった時に、エンジニアに確認しないと仕様がわからない」
「施策の効果を見るためのSQLのクエリ作成をエンジニアに依頼している」
「もっとたくさんリリースしたいけどエンジニアのリソースがない」
プロダクト開発チームが抱える課題に対し、私たちSpeeeは、AIを「使う」だけでなく「前提とする」ことで、ゲームチェンジを仕掛けようとしています。
「AIプランナー」ってなに？
一般的な概念ではないので説明すると、まず弊社では「開発物の要求（Issue）を決める役割」を持つ人をプランナーと呼んでいます。 プロジェクトの内容を説明するために新しい概念が必要でしたので、「エンジニア経験はないがAIの力を借りて要求決め〜開発実装まで一貫して進める役割」を「AIプランナー」と呼ぶことにしました。
Speeeが描くAI活用の未来図
Speeeでは、AI活用の成熟度を3段階で定義し、全社でその実現を目指しています。
個々人がAIを使いこなす「AX Level 1」から、AIをビジネスプロセスに組み込む「AX Level 2」、そして最終的にはAIを前提に産業全体を再創造する「AX Level 3」へ。 今回紹介する「AIプランナー」の取り組みは、まさにその最前線。開発未経験のプランナーがAIを相棒に、自ら開発・リリースまでを完結させる挑戦です。各チームのプランナーチームが、一人あたり週2〜5件というペースでリリースを継続しています。
なぜプランナーがコードを書くのか？「Issueを立てた人が開発する」という理想
この取り組みの根底にあるのは、「Issueを書いた人がそのまま開発できる状態が理想的だ」というシンプルな思想です。企画者自身がアイデアを最も深く理解している当事者として、AIと共に実装まで責任を持つ。これにより、開発の並行性を高め、組織全体のスループットを最大化することを目指しています。 AIプランナーたちは、対話型AIのClaude Codeと、ブラウザ上で開発環境を完結できるGitHub Codespacesを主な武器としています。これにより、環境構築のハードルを下げ、誰もが開発のスタートラインに立てるようにしました。
AIプランナーによる開発生産性向上と4つの具体的な成果
プランナーが開発を始めてから組織全体のリリース量が134％改善、プランナーによるリリースを開発組織全体の15％まで拡大させることができました。
- 高価なAI-OCRサービスをDifyで内製化しコストを1/10に削減
- Figmaのデザイン情報からUIの叩き台を自動生成し、実装を高速化
- バグの修正が必要な時に、仕様の調査〜実装までプランナーだけで進める
- Miroの複雑な仕様をAIが読めるMermaid図に変換し、エンジニアへの要件伝達を円滑化
これらはほんの一例ですが、これまでエンジニアの専門領域だった課題解決が、プランナーの手によってスピーディに進んでいます。
ぶつかったリアルな壁と、それを乗り越えたTips
もちろん、道は平坦ではありませんでした。想定通りに進まなかったことがたくさんありました。AIプランナーのリアルな課題とそれを乗り越えるためのTipsを共有します。
壁1：「簡単なはず」の環境構築が動かない
当初、Codespacesを使えば環境構築は不要になると考えていましたが、それは幻想でした。ローカルでの動作確認にはデータベースやテストデータの準備が必須で、結局は個別の環境構築が必要になるケースが発生したのです。
【Tip】 簡単な修正はCodespaces、複雑な修正や頻繁な確認が必要な場合はローカル環境、と割り切って使い分ける。全員が同じ環境を使う理想を追うのではなく、タスクの性質に応じて最適な環境（AIのプランや端末のスペックなど）を選択することが重要です。
壁2：AIによるUI修正が、意外と難しい
「フロントエンドの修正は簡単だと思っていたが、意外と難しい」という声がプロジェクト参加者から多く上がりました。自然言語で「ここのUIをこうして」と指示しても、AIにコンポーネント構造を正しく理解させ、意図通りに修正させるのは骨が折れる作業でした。
【Tip】 AIに丸投げするのではなく、プランナー側にもコードを理解する力が求められる。AIはあくまで補助輪であり、最終的な品質を担保するには、失敗を繰り返しながら開発の基礎知識を身につける学習プロセスが不可欠です。
壁3：コード品質の担保と、一時的なエンジニアの負荷増大
AIが生成したコードは、時に意図しない変更を含んでいたり、冗長になったりすることがあります。そして、プランナーが自力で解決できない問題は、エンジニアへの質問やレビュー依頼となり、結果的にエンジニアの負荷が一時的に増大しました。
【Tip】 短期的な負荷増は織り込み済みと捉える。プランナーが問い合わせ対応などの細かな修正を吸収することで、エンジニアはより集中すべき業務に取り組めるようになり、長期的には「プラマイゼロ」かそれ以上の効果が見込めると考えています。
AIプランナープロジェクトの目標設定
参加者のチームがバラバラなので「社内運用ツールだとバックエンド改修がメイン」「エンドユーザー向けのサービスではフロントエンド改修がメイン」のように必要な開発がそれぞれ異なるため、以下のようなざっくりとした目標を決めて個別にサポートをするようにしました。
- フェーズ1：プロジェクト参加者が全員1リリースする（どれだけ小さいリリースでもOK）
- フェーズ2：プロジェクト参加者の20％が週5以上リリースする
目標を置いたことで、チームの性質や必要なリリースの量にも差があることがわかり、チームにあわせてClaudeのプランや開発環境の構成を変えながら運用を進めていきました。毎月ウィンセッションを開催して、開発物やノウハウをみんなで共有することで参加者同士でアドバイスを送れるような繋がりを作るようにしました。
個人的な体験の補足 〜開発が近くなった〜
Claude＋VS codeで開発するようになってからコードの構造を調べるハードルは下がり、システムへの理解度が上がりました。これまでGithubではほとんどIssueしか作成していませんでしたが、PRを出すようになってからCIの思想など感覚的にしかわからなかった概念に直に触れることができてうれしかったです。
また、Claudeがないときはどのファイルを見れば必要な機能の処理が書いてあるかわからず、コードを特定しても読み解くスキルがないため、ドキュメントがない場合に仕様を完璧に理解するのに時間がかかる状態でした。
AIがコードを理解した上でAIと壁打ちしながらIssueを作成できるので、Issue作成の精度やスピードが爆発的に上がりました。
参考：嶋個人のcontributions
おわりに：AI時代のPMが真に向き合うべきこと
この取り組みは、プランナーの役割を広げるだけではありません。プランナーとエンジニア、それぞれの専門性を高めつつ、その間の境界領域が重なり合っていくようなイメージです。
言葉にされているものは全部AIがなんとかしてくれる。重要なのは、まだ言葉にされていないものを言葉にしていくこと。それがPMの仕事なのだと改めて感じました。 AIが言語化されたタスクを正確にこなす時代において、私たち人間に求められるのは、顧客自身も気づいていない価値や、戦略と施策の間にあるギャップを埋める「問い」を立て、言語化していくことです。 AIを最強の相棒として、人間にしかできない価値創造に挑戦していく。私たちの取り組みが、皆さんのチームのヒントになれば幸いです。
（ツールの補足）
AIプランナーが開発に使用しているツール構成
プランナーの標準PCがWindowsのためGitHub Codespacesを使っていますが、ローカル動作確認の頻度が多いメンバーにはMacを配布して環境構築をしています。
Claude Code
ターミナル上で動作するコマンドラインツール。 VS Codeの統合ターミナルで起動し、Claude（大規模言語モデル）と対話しながら開発できる。 ファイルの読み書き、コード検索、git操作などを自然言語の指示で自動実行。 プロジェクトのコードベース全体をコンテキストとして理解できる。VS Code（エディタ）
コードの表示・編集に使用。Claude Codeが編集したファイルをリアルタイムで確認できる。Docker Compose（ローカル実行環境）
Rails、MySQL、Redis、Webpackerなどをコンテナで起動できる。動作確認はdocker composeのコマンドで実施。Claude Codeが提案したコードを、実際にコンテナ内で動かして検証する。GitHub Codespaces（クラウド開発環境）
簡単な修正やレビュー時に使用します。ブラウザ上で完結するため環境構築が不要。
