自己紹介と前提
bravesoftの受託事業の事業部長をしているタッキーです
これまでbravesoftにて自社サービスのCS/企画/PdM/マーケをしたり、受託部門の事業部長になってからもクライアントワークでプロジェクトマネージャーとして動いていますが、唯一言えることはエンジニアではない(エンジニアから入った経歴ではあるが。)
なので現在は普段は複数の案件を並行して見ているのが主務なのだが
その日々のタスクの中で社内の案件管理システムが、とても課題まみれで案件推進や、経営との数値の意思決定をする上でも、どうにもいかないというストレスフルなものでした。
案件の受注金額・ステータス・粗利管理を一元化するビジネスアプリケーションであり、この数値が経営の基盤となっているから大変だ。
不具合は多く、アーキテクチャはLaravel / PHP / MySQL / jQuery といったレガシー構成。
Eloquentモデルは60個超、マイグレーションは100本以上とたまり、社内の営業からバックオフィスまで、日常的に使われている・・・。
上の通り、PHPやLaravelもEOLを迎えており、普段はクライアントに向き合うことが多いため会社的にも保守に投資できる予算もない。
典型的な「動いているから放置されているが、大きく触ると壊れる」システム。
このシステムの保守・改修を、他の案件をこなしながら1週間でキャッチアップし、開発からサーバーへのデプロイまで回せる体制を作った。AIと一緒に。
これは「エンジニアがAIを使って効率化しました」という話ではない。
非エンジニアのPMが、AIを「開発チーム」として組織し、ディスカバリーからデリバリーまでのプロダクト開発の全プロセスを1人で回している話だ。
何をやったのか：3行で
- Claude Code（AIコーディングツール）に10人の専門エージェントを定義し、計画・設計・実装・レビュー・テスト・検品・振り返りまで自動化した
- Confluence にプロダクトのドキュメントポータルを構築し、AIが自動で更新する仕組みを作った
- この体制で 1週間のうちに15フィーチャーを完了し、サーバーへのデプロイまで実施した
なぜPM/PdMがコードを触っているのか
正確に言えば、「コードを触っている」のはAIだ。
自分がやっているのは、プロダクトの意思決定とプロセスの設計だ。「何を作るか」「なぜ作るか」「どの順番で作るか」を判断し、AIに実行させている。
PMやPdMの仕事はクライアントワーク・プロダクト開発において職種も役割は違うが、広義な意味でビジネス的にいえば、ディスカバリー（何を作るべきか見つける）からデリバリー（届ける）までの全プロセスを統括することや、ビジネスをグロースさせ、エンドユーザーに体験価値を届ける人材である。
ただ、社内システムには構造的な問題がある。投資・保守できる予算が後回しになる。
売上を直接生まない社内システムに開発予算はつきにくい。結果、メンテナンスが後回しになり、アーキテクチャはEOLを迎える。
このサービスもPHPのサポートは終了し、Laravel もEOL、フロントエンドはjQueryのまま。
動いているから放置されるが、パフォーマンスは劣化し、改修のたびに技術的負債が積み上がる。ドキュメントもなく、もはや当時触った人はいないレベルだ。
かといって、リプレイスに投資する予算やSaaSで代替する予算もない。エンジニアをアサインする余裕もない。
だがAIを「開発チーム」として使えば、この制約を突破できる。
予算がなくても、エンジニアがいなくても、PMが直接ディスカバリーからデリバリーまでを一気通貫で回せるという話である。
「仕様駆動」だけではない：ディスカバリーからデリバリーまで
よくある誤解
AIを使った開発というと、「仕様を書いてコードを生成する」ことを想像するかもしれない。いわゆる仕様駆動開発だ。
そもそも自分がやっているのはそこだけに留めない。プロダクト開発に必要な全レイヤーをカバーしている。
何故ならば、幹部レイヤーとしては、経営としても色々な説明責任を求められるからこそ、ただ仕様通り開発するだけでは片手落ちなのである。
プロダクトの全レイヤー
Confluenceに構築したドキュメントポータルの構成がそのまま物語っている：
| レイヤー | 内容 | 担当 |
|---|---|---|
| ディスカバリー | 社内ユーザーインタビュー、ペインポイントの記録 | PM（自分） |
| プロダクト管理 | バックログ整備、RICE優先順位付け、ユーザーマップ、意思決定ログ | AI（PMの記録をもとに整備） |
| ロードマップ | 中長期計画、段階的モダナイゼーション | AI（PM方針をもとに策定） |
| 計画・要件・設計・仕様 | 計画書 → 要件定義書 → 設計書 → 仕様書（技術+業務） | AI（レビューはAIエージェント3人並列） |
| 実装・レビュー | コーディング、PR作成、コードレビュー | AI（レビューはAIエージェント3人並列） |
| テスト・検品 | テスト設計・実行、検品チェックリスト実行 | AI（test-executor, inspector） |
| リリース判定 | Go / Conditional Go / No-Go 判定 | AI → PM承認 |
| デプロイ | ステージング → 本番サーバーへの反映 | PM（自分） |
| 振り返り・改善 | 4アナリスト並列振り返り → プロセス自己修復 | AI |
| ナレッジ蓄積 | 成功パターン/アンチパターン/プレイブック | AI（自動生成） |
注目してほしいのは、仕様から下だけではないということだ。
PMとして自分がやったのは、社内のユーザーにインタビューして課題やペインポイントを記録したこと。それだけだ。
そこから先——バックログの整備、RICEスコアによる優先順位付け、ユーザーマップの構築、ロードマップの策定——これらは全部AIがやっている。
プロダクトマネジメントの上流から、サーバーへのデプロイ・その後のレポーティングまで、PMが手を動かすのは「ユーザーの声を聞く」と「最終判断を下す」だけだ。
PMとして一番重要なもの：意思決定ログ
Confluenceの「プロダクト管理」セクションには意思決定ログがある。「何をやる/やらないの判断理由」を時系列で記録している。
AIがバックログを整備し、優先順位をつけ、計画書を作っても、最終的に「これをやる」と決めるのはPMだ。その判断の根拠を残しておくことで、AIに振り回されずに済む。
1週間のタイムライン
他の案件を並行してこなしながら、このシステムの保守体制を1週間で構築した。Git履歴が全部残っている。約260コミットである
Day 1：キャッチアップ
- システムの全体像を把握（CLAUDE.mdにアーキテクチャを記述）
- 最初のバグ修正（案件詳細画面のnullエラー）
Day 2：最初のフィーチャー群
- メモリ最適化（238MB → 56MB）
- CSV出力のN+1解消
- コード品質リファクタリング
- 部門表示改善
- 開発ドキュメントの管理構造（backlog → active → done）を設計
Day 3-4：開発プロセスの標準化
-
.claude/配下にスキル（20個）、エージェント（10人）、ルール（5種）を定義 - Agent Teamsパターンへの全面移行
- N+1修正をフルプロセスで実行（計画 → 要件 → 設計 → 仕様 → 実装 → レビュー → テスト → 検品 → リリースサマリー → アーカイブ）
- 検索URL共有機能の追加
Day 5-6：プロセスの成熟
- テスト基盤構築 + 振り返り + 自己修復（ここで初めてプロセスが「進化」した）
- コントローラリファクタリング Phase 1 & 2（ProjectControllerの分割）
- Confluenceにドキュメントポータルを構築
Day 7+：通常運用
- CSV列カスタマイズ機能の開発（現在進行中）
- バックログの計画書作成（セキュリティ強化、承認フロー最適化など）
ポイントは、これが「他の案件や経営に関することもやりながら」ということだ。 このシステムだけに集中していたわけではない。AIが並列で動いてくれるから、自分はPMとしての判断と承認に集中できた。
Confluence：AIが更新するドキュメントポータル
なぜConfluenceか
別にNotionでも良い。ただ全社的にはConfluenceだっただけであり、全社的にNotionであればNotionMCPを使っていただけである。
ただ共通して言えるのは、社内システムの最大の負債は「ドキュメントがない」ことだ。コードを読めば個々の機能は分かるが、「このシステムは何のためにあるのか」「どういう設計思想で作られているのか」がどこにもない。
Confluenceにドキュメントポータルを構築し、以下を整備した：
- プロダクト概要・技術スタック・アーキテクチャ
- 開発プロセスの全体像（13ステップ × 20スキル × 10エージェント）
- コーディング規約（5種）
- ナレッジベースの構造
- フィーチャー管理のライフサイクル
AIが更新する
ここが重要だ。このドキュメントポータルはAIが更新している。
Claude CodeにはAtlassianプラグインが統合されている。フィーチャーの開発プロセスで生まれたナレッジ、プロセスの改善内容、新しいルールやエージェントの追加——これらの変更がConfluenceのドキュメントに自動反映される。
たとえば、振り返り（step11-retro）で「Eager Loadingの定数化パターン」が成功パターンとして記録されると、Confluenceのアーキテクチャページにもその知見が反映される。開発プロセスに新しいスキルが追加されれば、Confluenceのスキル一覧も更新される。
ドキュメントが腐らない。 これが最大のメリットだ。人間が手動でドキュメントを更新する運用は、必ず破綻する。AIが開発プロセスの一部としてドキュメントを更新するなら、コードとドキュメントの乖離が発生しない。
AIを「プログラマー」ではなく「チーム」として使う
10人の専門エージェント
AIに「コードを書いて」と頼むのではなく、チームの役割を与えた。
| 役割 | エージェント | 専門性 |
|---|---|---|
| セキュリティレビュアー | security-reviewer | XSS/SQLi/CSRF/認証認可（22観点） |
| アーキテクチャレビュアー | architecture-reviewer | レイヤー整合性/パフォーマンス/後方互換性（26チェックポイント） |
| UXレビュアー | ux-reviewer | WCAG準拠/操作性/レスポンシブ（12項目） |
| コード品質レビュアー | code-quality-reviewer | バグ/DRY違反/デッドコード/複雑度（50+パターン） |
| テスト実行者 | test-executor | テストケースの自動実行とPass/Fail記録 |
| 検品担当 | inspector | 仕様準拠/パフォーマンス/セキュリティ/UI（4カテゴリ並列） |
| ドキュメント分析 | doc-analyst | ドキュメント工程の品質分析 |
| コード分析 | code-analyst | 実装工程のパターン分析 |
| QA分析 | qa-analyst | テスト・検品工程の精度分析 |
| プロセス分析 | process-analyst | 全工程のボトルネック分析 |
これらが並列で動く。人間のチームで「全員のレビューが揃うまでマージしない」のと同じ規律をAIにも適用している。
なぜPMにこれが効くのか
エンジニアがAIを使う場合、「自分でもコードは書けるが、AIに書かせた方が速い」というレバレッジだ。
PMの場合は違う。自分ではコードレビューの専門性がない。セキュリティの脆弱性を見抜く目も、N+1クエリを検出する経験もないPMも存在する。だからこそ、専門エージェントの価値が大きい。
PMが持っているのは「何を作るべきか」「どの順番で作るか」「この品質で出してよいか」の判断力だ。AIが持っているのは「どう作るか」「どこにリスクがあるか」の実行力と検出力。この組み合わせが、PMとAIの理想的な役割分担になる。
13ステップの開発プロセス
全体像
コマンドを1つ打つだけで、その工程に必要なドキュメントが生成され、レビューが走り、判定が返ってくる。
PMとして自分が手を動かすのは、図の中で「PM」と書かれた2箇所——ユーザーインタビューとリリース判断・デプロイだけが必須であり。残りは任意で、重要な機能の際や、ドキュメントで調べてほしいことや気になった点を指示出す以外は、すべてAIが実行する。
Claude Code Skillsについて
計画からリリースまでの13ステップの開発プロセス全体をAIで自動化した。
/step01-plan 計画書作成
/step01-review 計画レビュー（3エージェント並列）
/step02-requirements 要件定義書作成
/step02-review 要件レビュー（3エージェント並列）
/step03-design 設計書作成
/step03-review 設計レビュー（3エージェント並列）
/step04-specs 仕様書作成（技術 + 業務）
/step04-review 仕様レビュー（3エージェント並列）
/step05-tasks タスク化 + ブランチ作成
/step05-run タスク実行
/step06-report 実装レポート
/step07-code-review PR作成 + コードレビュー（3エージェント並列）
/step08-test テスト設計
/step08-run テスト実行（test-executor）
/step09-inspection 検品チェックリスト作成
/step09-run 検品実行（inspector × 4並列）
/step10-summary リリースサマリー（Go / No-Go判定）
/step11-retro 振り返り（4アナリスト並列）
/step12-evolve 自己修復
/step13-archive PRマージ + アーカイブ
プロセスパスの自動選択
すべてに13ステップのフルプロセスは過剰だ。step01-planで変更規模を判定し、適切なパスを自動選択する。
| パス | 条件 | 省略される工程 |
|---|---|---|
| Full | 複数ファイル or 50行超 | なし（全工程） |
| Light | 1ファイル and 50行以下 | 要件定義, 設計とそのレビュー |
| Refactoring | コード移動・分割のみ | 要件定義・設計を簡略版に |
この判断もAIがやるが、最終決定はPMが承認する。
自己修復するプロセス
その中で特筆すべきはこの自己修復プロセスを必ず通すことである
フィーチャーを重ねるほど賢くなる
数回のフィーチャーをdevelopにマージしたとき、1個目とはレビューの精度が全く違っていることも実感する。
同じコマンドを打っているだけなのに。
振り返り → 自己修復のループを回す価値の言語化。
step11-retroで4人のアナリストが並列で振り返りを実行し、Good / Bad / Tryを報告する。step12-evolveで、そのTryを実際のプロセス改善に変換する——スキル定義の更新、エージェントのチェックポイント追加、ルールの追加、ナレッジの記録。
実例：
Feature A の振り返り
→ 「Eager Loadingの定数化」を成功パターンとして記録
→ architecture-reviewer のチェックポイントに追加
Feature B のコードレビュー
→ architecture-reviewer が「Eager Loadingが定数化されていない」を自動検出
→ 修正
フィーチャーを1つ完了するたびに、プロセスが改善される。使うほど良くなる。
蓄積されたナレッジ
この繰り返すフィーチャーを通じて、1週間ほどで43のナレッジドキュメントが自動蓄積された：
- 成功パターン 11件（並列レビュー、CI早期検証、Eager Loading定数化など）
- アンチパターン 15件（マイグレーションのDB名ハードコード、Composerバージョン不整合など）
- プレイブック 2件（Git Worktree並列開発手順など）
- 振り返りレポート 14件(最序盤は振り返りを入れなかった。システムがそれ以前の話すぎたため)
デプロイまでやる
PMがデプロイまでやることに違和感を持つ人もいるかもしれない。
でも考えてみてほしい。ディスカバリー（何を作るか）→ 定義（要件・設計・仕様）→ 開発（実装・レビュー）→ 品質保証（テスト・検品）→ デリバリー（デプロイ）。プロダクトの価値はユーザーに届いて初めて発生する。
「コードはできました、でもデプロイは来週です」では意味がない。
AIがコードを書き、レビューし、テストし、検品する。Go判定が出る。あとはサーバーに反映するだけだ。そこにエンジニアを待つ理由がない。リリースサマリーにGo判定が出ていて、テストが全件Passしていて、検品チェックリストがすべて合格なら、PMが自信を持ってデプロイできる。
AIが品質を保証してくれるからこそ、非エンジニアでもデプロイの判断ができる。これは逆説的だが、AIによる品質保証がなければ、PMがデプロイすべきではないとも言える。
実績
数字で見る1週間
| 指標 | 数値 |
|---|---|
| 完了フィーチャー | 15 |
| developへのPR（マージ済み） | 30 |
| コミット数 | 260 |
| 専門エージェント | 10人 |
| スキル（スラッシュコマンド） | 20個 |
| コーディングルール | 5種 |
| 自動蓄積ナレッジ | 43ドキュメント |
| バックログ（計画済み） | 4フィーチャー |
パフォーマンス改善の実績
EOLを迎えたアーキテクチャでも、やれることは山ほどあった。放置されていたパフォーマンス問題をAIチームで片っ端から潰した。
案件一覧ページ（9,642件）：
| 指標 | Before | After | 改善率 |
|---|---|---|---|
| SQLクエリ数 | 4,404 | 95 | 97.8%削減 |
| TTFB（初期表示速度） | 8.8秒 | 535ms | 94%改善 |
CSV一括ダウンロード（9,642件）：
| 指標 | Before | After | 改善率 |
|---|---|---|---|
| SQLクエリ数 | 約77,000 | 13 | 99.98%削減 |
| 処理時間 | 数十秒 | 489ms | 98%改善 |
| メモリ使用量 | 288.5MB | 102.5MB | 64%削減 |
案件登録画面：
| 指標 | Before | After | 改善率 |
|---|---|---|---|
| ピークメモリ | 238MB | 44.5MB | 81%削減 |
| データロード | 188MB | 6MB | 97%削減 |
メモリ128MBの制限でOOM（Out of Memory）クラッシュしていた画面が、正常に表示されるようになった。
検索機能：
| 指標 | Before | After | 改善率 |
|---|---|---|---|
| SQLクエリ数 | 206 | 19 | 90.8%削減 |
| セッションストレージ | 114.8MB | 103バイト | ほぼゼロに |
セッションに114.8MBのデータを格納してOOMクラッシュしていた問題も解消した。
完了フィーチャー一覧
| フィーチャー | カテゴリ |
|---|---|
| 案件一覧N+1解消 | パフォーマンス |
| CSVダウンロードN+1解消 | パフォーマンス |
| 案件登録メモリ最適化 | パフォーマンス |
| 案件一覧Eager Loading最適化 | パフォーマンス |
| 検索機能最適化 | パフォーマンス |
| 未承認カウント最適化 | パフォーマンス |
| 検索URL共有 | 機能追加 |
| 部門表示改善 | 機能追加 |
| コントローラリファクタリング Phase 1 & 2 | リファクタリング |
| 案件一覧リファクタリング | リファクタリング |
| コード品質改善 | リファクタリング |
| Docker環境構築 | インフラ |
| テスト基盤構築 | インフラ |
PMがこれをやる意味
エンジニアとの違い
エンジニアがAIを使う場合：「自分でもできるが、AIの方が速い」。効率化の話だ。
PMがAIを使う場合：「今まで自分にはできなかったことが、できるようになる」。能力拡張の話だ。
PMは「何を作るべきか」の判断力を持っている。でも「どう作るか」の実行力がない。AIはその逆だ。この組み合わせは、実は非常に自然だ。
ディスカバリーからデリバリーまでの一気通貫
従来のプロダクト開発では、PMとエンジニアの間にコミュニケーションコストが発生する。要件を伝え、仕様を確認し、実装を待ち、レビューをお願いし、修正を待ち、デプロイを依頼する。
AIチームなら、そのコミュニケーションコストがゼロになる。PMの頭の中にある「これが必要だ」を、直接プロダクトに変換できる。
しかもただ思いつきにチャットして開発してもらうわけじゃない。全てを計画的にドキュメントと変更管理を残しつつレビューもしてもらいながらである。
ただし、これは「エンジニアが不要」という話ではない。大きなアーキテクチャ変更、セキュリティの最終判断、パフォーマンスチューニングの深い部分——人間のエンジニアの専門性が必要な場面はある。AIチームは「PMが日常的な保守改修を自律的に回す」ための仕組みだ。
自分の理解の範疇を越える作業をするときには、その意思決定を下せるレベルには自ら学ぶ必要はある。
なのでここでは最前線には居ないにせよ、幸い自分自身がエンジニアを経験していたからこそ決定できる場面が0とはいえないことも事実ではあることは補足しておく。
やってみて分かったこと
うまくいったこと
判断と実行の分離が明確になった。 PMは「何を」「なぜ」「いつ」を決め、AIは「どうやって」を実行する。この役割分担が自然に機能した。
品質の安定。 AIのレビューは毎回同じ厳しさで、同じ観点を漏らさずチェックする。PMがコードの品質を直接判断できなくても、AIエージェントのレビュー結果を信頼できる。
ドキュメントが腐らない。 ConfluenceもGitのナレッジベースも、開発プロセスの中でAIが更新する。人間の「あとでドキュメント書こう」は永遠に来ないが、AIの自動更新は毎回確実に走る。
課題
AIの判断を鵜呑みにしない訓練が必要。 Go判定が出ても、PMとして「本当にこれでいいのか」を考える癖をつける必要がある。AIは便利だが、最終責任はPMにある。
大きな設計判断にはエンジニアが必要。 Laravel 9 → 12への段階的な移行、Blade → React + Inertia.jsへの移行——こういった判断は、AIの振り返りからヒントは得られるが、人間のエンジニアと議論すべきだ。
セットアップコストはゼロではない。 10エージェント × 20スキル × 5ルールの定義は自分の経験や観点に依存した部分はある。
ただし、一度作れば再利用できることや他の人へも渡せる。そしてプロセスが自己修復するので、時間とともに良くなる。
まとめ
AIを使ったプロダクト開発の話は、たいてい「エンジニアの生産性の向上」で会話が終わってしまうことがある。
今回のアプローチは違う。
**非エンジニアのPMが、AIに「開発チーム」の役割を与え、ディスカバリーからデリバリーまでのプロダクト開発の全プロセスを1人で回す仕組みを作った。**ということだ。
- 何を作るべきかを見極め（ディスカバリー）
- 計画・要件・設計・仕様を定義し（定義）
- AIチームが実装・レビュー・テスト・検品し（開発・品質保証）
- Go判定を確認してデプロイする（デリバリー）
- 振り返りでプロセス自体が改善される（学習）
- Confluenceのドキュメントも自動で更新される（知識管理）
260コミット、15フィーチャー、43のナレッジドキュメント。他の案件をこなしながら、1週間で。
コードが書けなくても、品質の高いプロダクトは作れる。
QCD——Quality（品質）、Cost（コスト）、Delivery（納期）。従来、この3つは「どれか2つを取れば1つを犠牲にする」トレードオフだった。
AIチームはこのトレードオフを崩す。10人の専門エージェントによるレビュー・テスト・検品で品質を担保し、人件費ゼロの開発チームでコストを抑え、他の案件と並行しながら1週間で15フィーチャーというスピードを実現する。
必要なのは「何を作るべきか」の判断力と、AIを組み込んだプロセスを設計する力であり
これを今まで標準化や言語化出来なった自身の能力を同じスキルやエージェントを活用することで他の人でも実行できるということである。