あたらしい上流工程の形。 0日導入からはじめるAI駆動PM

2026.1.29 AI駆動開発勉強会 第7回 AI駆動PM/PdMスペシャル　登壇資料

Transcript

1. あたらしい上流工程の形。 0日導入からはじめるAI駆動PM ランスティア株式会社/クマイ総研 熊井悠 2026.1.29 AI駆動開発勉強会 第7回 AI駆動PM/PDMスペシャル
2. 本登壇で話したいこと 導入期間を0日にしてみた その理由と効果は？ 0日導入とは？ AI駆動開発における 要件定義・設計の最前線 上流工程の最前線 AI時代にPMは どのように過ごしいくべきか？ PMの目指す道 其の一 其の二 其の三
3. 自己紹介 熊井 悠（本名：竹下祐豪） ランスティア株式会社 CEO/CTO ・シンプレクス（2015-2018） ：Javaエンジニア・PM ・ベイカレントコンサルティング（2019-2020） ：ITコンサルタント ・2社起業（2019-2025 / 2020-現在） 　・受託開発を中心としたビジネスを展開 　・2023年からAIを活用したシステム開発検証（OpenAI APIの自社組み込み） 　・2024年から本格的にAI駆動開発をチーム展開 　・2025年 Rinstack リリース / GEAR.indigo 事業譲受 PMは2016年頃〜 多い時期は400-500人月/年のプロジェクト管理を実施 システムPM/インフラPM 両方を経験していることが特徴 CI/CD、DevOps（ITIL）によるプロセス変革が大好物
4. 僕の考える「AI駆動PM」とは？ ＝ 生産性向上だけではなくプロセス変革をする者 なぜなら局所最適ではボトルネックが移転するだけだから 本当に実現すべきは「全体最適」による抜本的変革（ 『ザ・ゴール』参照） じゃあ全体最適をするために何をすべきなの・・・？ これが本日のテーマです！ 例）要件定義は早くなったが、 　　お客さんの検討スピードは変わらなかった
5. 其の一 0日導入とは？
6. AI駆動開発組織を2024年4月〜運営してきた気づき スクラッチ開発の場合アーキテクト視点が重要 AIが生成したものを判定できる技術力や視力（気付ける力） 高速化しようとした場合、積み重ねたプロセスの破壊が必要 ただ抜け漏れが発生するリスクもある AIツールは体験の差でしかない。 結論はドーピングに近い。小学生が世界新記録を出せる訳はない ここから学んだ教訓 開発組織におけるアーキテクチャ・コード基盤が重要 AI駆動開発プロセスにおけるボトルネックを排除する変革力 フルスタック化は困難、ドメインマスター化は可能性あり
7. コード基盤 アーキテクチャ 何もない状態 自然言語指示 スケルトンコード + 自然言語 コード品質 低い コード品質 高い 開発組織におけるアーキテクチャ・コード基盤が重要 完全なVibe Conding状態よりもスケルトンコードありきが品質が安定する ※とはいえLLM性能向上により解消されつつはあるが、 　メンバーの教育的側面からしても後者の方が学習効率がいいのは事実
8. 要件定義 設計 開発 テスト リリース 超高速化 AI駆動開発プロセスにおけるボトルネックを排除する変革力 レビューが 積み上がる レビューを最適化する（＝部分最適）のではなく レビューを減らす仕組みを変革すべき 　・例）スケルトンコードをコード基盤にして実装する前提にすれば 　　　　変更箇所が少なくなるので、結果としてレビューコストが減る 部分最適から全体最適できる変革力がポイントとなる
9. フルスタック化は困難、ドメインマスター化は可能性あり フロントエンド バックエンド インフラ ・技術スタックを統一する ・アーキテクチャを統一する ・それに基づくドキュメント群を用意する（上流工程） ・それに基づくツール（Skillsなど含む）を用意する 上記の工数を減らすことで、事業の専門領域（ドメイン）に全振りできる 全ての専門領域を1人で対応することが理想だが現実的にどうすべきか？
10. 気づきましたか？ ここまで見てきて AI駆動開発も、開発プロセスも 「何」を意識して試行錯誤していますか？
11. そうです。コードです。 ・ 「要件」を「コード」に変換するための工程 ・コード品質を担保するための工程 王様であるコードを制することが 最大の関心事なのです
12. そこから導いたのは0日導入という方法論 よく知らない 王様（お殿様） よく知っている 王様（お殿様） つまり全体最適を制するには「コード」から考える必要があります コード（技術）をもとに最適なアーキテクチャ設計や それを支えるAI駆動開発のプロセスを再考する必要があります。 どっちが取り組みやすいか？
13. 導入 実装 要件 0日導入は「すでにできているシステム」から始める 1.プロジェクト開始時に「基盤コード」を環境（テスト環境）にデプロイ 2.お客様と「基盤コード」をもとに要件定義・設計をする 3.ドキュメントは「基盤コード」前提の雛形を差分修正するのみ 4.可能な限り定例会では「アップデート」したものを見せる 実装 要件 実装 要件 AI駆動PMは 要件をイシュー化しパイプラインへ伝達する これができない仕組みがあれば徹底的に変革する
14. 0日導入ではアジャイル（DevOps）式のプロセスが標準に これって結論アジャイルだよね？ →その通りです 　ただ事業・組織そのものを変革するまで行かねば 　大きな効果を発揮することができない なぜなら「技術スタック外」のことは やらないと宣言するようなものだから 餅は餅屋
15. 其の二 上流工程の最前線
16. 事前にリバース エンジニアリング ドキュメント クラウド環境へ デプロイ 基盤コードありきの上流工程 実際の最近の取り組みを紹介 技術スタックやアーキテクチャが決まれば こちらのパイプラインだけ回すことになる 0日導入 システムを見せて 要件定義をする 稼働開始 Issue登録 Update ドキュメント更新 こちらでカバーできない機能要件は カスタマイズではなく 可能な限り基盤コードを進化させる
17. 実際の例：リバースエンジニアリングのドキュメント
18. 実際の例：追加要件から追加仕様を更新
19. 其の三 PMの目指す道
20. AI時代のPMのあるべき姿とは？ 変革者たるべきPMが身につけるべきものは？ 技術を学ぶ（プログラミング言語・インフラ） 技術を実現するための工程を学ぶ（テスト・CI/CD） その変革の最前線に立ち実現する
21. AI駆動PMを加速するGEAR.indigo Bizのご案内　 無料トライアル はこちら
22. ご清聴ありがとうございました