企画を Software Factory-ready にする——開発が高速になったとき、PdMの仕事はどう変わったか

「 freee技術の日2026 」での発表資料です。

Transcript

1. 企画を Software Factory-ready にする 開発が⾼速になったとき、PdMの仕事はどう変わったか ⾕内 祐太 2026年10⽉3⽇
2. プロダクトマネージャー 谷内 祐太 yachi SIer、HR系スタートアップを経て、 2023年8月にfreee中途入社。freee 請求書や債権管理、金融領域のプロ ダクトマネージャーを担当。
3. 今⽇持ち帰ってほしいこと 開発が⾼速になると、PdMが注⼒すべき仕事は「渡す‧決める‧検証する」になる 1 渡す 既知の知は、AIが ⾃分で参照できる ナレッジベースに置く 2 決める 3 検証する 書くのは、PdMが説明責任を 持てる要求だけ 動くプロトタイプを 速く出して検証する それ以外は、AIが網羅的に記載し、 顧客にインタビューやプロトタイプ チームでレビューする を当てて、未知の知を既知の知に 変えていく この3つが揃って回っている状態を Software Factory-ready と呼ぶ 検証して既知になったことは、①渡すに戻り、次の企画の材料になる
4. (1) スモールビジネス向けに統合型クラウド ERPを提供 その他サービス 統合型クラウド会計ソフト 2013年3⽉〜 ⽇本のクラウド 会計ソフト市場 シェアNo.1(2) 請求書 経費精算 決算書 予実管理 ワークフロー 内部統制 注: 統合型クラウド⼈事労務ソフト 統合型クラウド販売管理ソフト 2014年10⽉〜 2022年11⽉〜 スモールビジネスの ⼈事管理市場において 売上⾦額シェアNo.1(3) 【国内初】 クラウド会計ソフトと ⼀体型で使える 販売管理サービス 勤怠管理 ⼊退社管理 給与計算 年末調整 マイナンバー 管理 ⽀出管理 社宅制度の導⼊ ⼈事労務 申告書作成 ⼯数管理‧労務費管理 ⾒積‧発注‧請求 法⼈⼿続き クレジットカード 開業⼿続き 電⼦契約 1. クラウドサービス：ソフトウェアやハードウェアを所有することなく、ユーザーがインターネットを経由して ITシステムにアクセスを行えるサービス 2. リードプラス「キーワードからひも解く業界分析シリーズ：クラウド会計ソフト編」（ 2022年8月） 3. 「freee人事労務」は ITRが今年調査発行した「 ITR MARKET VIEW：人事・給与・就業管理市場 2022」の人事管理市場において、従業員 100人未満および従業員 100~300人未満の企業で売上金額シェア No.1（2020年度）を獲得しています。 4
5. 前提：freeeは40を超えるプロダクトを持つ会社です 1 2 3 多数のプロダクト 統合体験を⽬指す 制度‧法令が仕様に直結 会計‧⼈事労務の印象が つながった体験こそが 制度‧法令の知識が 強いが、実際は販売‧⽀出‧ freeeの価値。1つの企画でも 仕様に直結する領域が多い IT管理‧固定資産‧ 他プロダクトへの影響と 申告など多数 ⼀体になった体験を考える ＝ 企画に必要な前提知識が、極端に重い構造
6. 企画意図を渡すと、数時間後に動くプロトタイプが出てくるようになった Software Factory＝ AIが設計‧実装を担う開発ライン。詳細は15:10からの「freeeにおけるSoftware Factory」セッションで ⼈ ② 未決事項に答える ① 企画意図を置く （後⼯程を⽌めるものだけ） ③ プロトタイプを 触って検証する OKになったら本実装へ Software Factory （AI） MRD 要求 仕様書 設計 ready システム 仕様 設計 設計 レビュー プロト タイプ 実装 本実装 QA ↻ 各⼯程で「⽣成 → 検査 → 修正」をまわす 未決事項 全⼯程の未決事項を1か所に集める ナレッジベース 企画と開発で共有するナレッジベース（既存仕様‧⽤語‧法令‧過去案件…） リリース
7. 「作る」が速くなった分、ボトルネックは企画に移った これまで 企画 設計 Software Factory以後 企画 テスト‧検証 実装 リリース テスト リリース 「企画」がボトルネックに 設計‧実装が数時間に ※ ⼯程の⻑さはイメージ ⼈の速さで進む⼯程は、⻑さが変わらない。Software Factoryが速くなるほど、その前後にある企画と検証が全体の速さを決める ＝ Software Factoryの⼊⼝にある企画が詰まり始めた。 そこで「AIで企画プロセスを⾼速化するプロジェクト」を⽴ち上げた
8. 01 そもそも、ボトルネックは本当に 企画書なのか？ プロジェクト開始前に、チームメンバーから出た問い
9. 測ってみると、企画の時間の⼤半は「書く」ではなく「調べる」だった 企画プロセスをタスクに分解して年間⼯数を⾒た（推計） 約274h 調査‧考慮事項 決めたこと 書くことの⾃動化ではなく、調べる対象を 約156h レビュー‧修正 記載 ナレッジベースにまとめ、AIが⾃分で引ける 状態にすることを本丸にした 約96h 仮説 共有‧調整 約60h ナレッジベースさえ揃えば、企画書は⽣成 できる 「記載」＝書く時間は、全体の約16% → これを複数のプロダクトで確かめにいった
10. 02 書くのは、確かに速くなった 複数プロダクトでの実証（2026年7⽉）
11. 企画⽂書の作成時間は、複数のプロダクトで短縮した 共通のナレッジベースを参照し、MRD‧要求仕様書を⽣成した ⽀出 固定資産 申告 IT管理 ⼈事労務 Before Before Before Before Before 4時間 1週間 2⽇ 2⽇ 2⽇ ▼ ▼ ▼ ▼ ▼ After After After After After 1時間 2〜3⽇ 2時間 2時間 2時間
12. 速さ以外に、現場が価値を感じたもの 考慮漏れの防⽌ 品質の均⼀化 並列処理 ⼀⼈だと⾒逃す論点を、 誰が‧いつやっても 隙間時間に指⽰だけ出し、 先に網羅的に ⼀定以上の⽔準になる 裏で複数の企画が 指摘してくれる 同時に進む
13. 精度を決めていたのは、書き⽅ではなくナレッジベースだった ⼈事労務の実案件で、⽣成された要求仕様書をPdMがレビューで直した箇所を調べた 直した原因は ナレッジベースを充実させるほど… ✓ 書き⽅ではなかった 同じスキル‧同じ⼊⼒でも 精度が上がった 本当の原因 既存仕様がナレッジベースに⼊っておらず、 AIに渡せていなかった ＝ 仮説どおり、ボトルネックは「書く⼒」ではなく「ナレッジベースの網羅性」だった
14. ナレッジベースの抜けは、そのまま企画速度の負債になる ナレッジベースが 薄い領域 会計と統合している プロダクト 最後の壁 AIを使っても 共通のナレッジベースを ヘルプに載らない社内情報‧ 速くならない 整えた効果が⼤きい 進⾏中の仕様変更‧ （結局、⼈が調べ直すから） 将来計画 ＝ AI活⽤の勝負どころは、プロンプトではなくナレッジベースの網羅性と鮮度
15. 既知の知を、AIが⾃分で参照できるナレッジベースに置く 企画と開発で共有するナレッジベース（イメージ） ⼯程の流れ 探索 PdM 企画 PdM AI：企画案を広げて選ぶ AI：要求仕様を書く 1 真ん中にナレッジベース 参照する ⾜りない知識を更新 現⾏仕様‧⽤語集‧法令‧制度‧意思決定の 記録‧不具合‧サポート履歴など。複数の データストアを抽象化した総称 Knowledge Base 複数のデータストアを抽象化した総称 運⽤ CS‧PdM AI：問い合わせ‧ 不具合から学ぶ 現⾏仕様 ⽤語集 法令‧制度 意思決定の記録 不具合‧障害 サポート履歴 顧客の要望 QAナレッジ バックログ ロードマップ 事業戦略 依存関係 設計 Eng AI：設計‧テスト設計 2 探索‧企画‧設計‧実装‧リリース‧運⽤の AIが、同じ場所から知識を引く 3 リリース QA‧PdM‧Eng 実装 Eng AI：仕様と実装のずれを検出 AI：コード‧テストを書く 全⼯程のAIが参照する ⾜りなければ更新して戻す 「既存仕様や法令‧制度の資料が⾜りない」 は、ナレッジの更新として返す
16. 誤算：AIは書きすぎる AIは、決まっていないことも⾃分で 仮に決めて、漏れなく書き切る 漏れなく書かれるほど、 PdMが譲れない要求が埋もれる 認証エラーの扱いや、 状態と結果の組み合わせ表まで書いてくる 30,000字 13,000字 最⼤の案件 ユースケース1つだけで • PdMが譲れない要求と、AIが仮に決めたことが、同じ重みで並ぶ • 読む⼿間もレビューの⼿間もトークンも増える → ナレッジベースを整えるだけでは⾜りない。何をPdMが決めるのかを定義し直す必要があった
17. 03 そこで、PdMが決めることを定義 し直した 渡す‧決める‧検証するの線をどこに引いたか
18. 書かないことを決めた：要求を「決める⼈」で3つに分けた 要求は、決める⼈で3つに分けられる PdM Eng Eng‧ApD どれに⼊るかは、1つの問いで判定する 業務要求‧業務ルール 要求仕様書 システムの振る舞い システム 仕様 （技術的専⾨知識をもとに網羅的に記載） 設計 「なぜそうするのかを、PdMが開発チームに 説明する責任を持てるか」 持てる 顧客の業務や課題を根拠に、理由を説明できる → PdMが決めて、要求仕様書に書く 持てない コードベースの調査や既存実装への考慮、整合性‧ 排他‧トランザクション‧性能などの専⾨知識が要る → AIが網羅的に記載し、チームでレビュー 設計書 「要求仕様書に書かなくてよいこと」を⽂章にして、スキルに組み込んだ ✂ 基本フローは書かない ✂ 判定表の軸にシステムの状態が ⼊ったら、その表はEngが持つ ✂ 理由が「整合性のため」「エラーを 防ぐため」としか書けない⾏は削る
19. 17⾏の表は、3⽂で⾜りた Before 状態の組み合わせ表 17⾏（2,211字） After 業務ルール3⽂ ＋ Engへの引き継ぎ1⾏ 業務ルール 1 業務ルール 2 業務ルール 3 → Engへの引き継ぎ（状態モデルへの展開はEngが持つ） PdMが読む量 元の⽂書 33.8k字 ⽂字を削るだけ 書く責務を変えた −22%で⽌まった 12.5k字 量を減らすのではなく、書く責務を変えた
20. Software Factoryに流してよい基準を「⽋陥ゼロ」から「ブロッカーゼロ」に変えた 設計readyゲートの5条件 1 全体設計に影響する事項が、確定または仮説として明⽰されている 2 要求同⼠、および既存仕様との⽭盾がない 3 棄却済み‧検証中の仮説が、確定した要求として混⼊していない 4 未確定事項に「仮説」などの識別表⽰がある 5 要求にHowや技術判断を書きすぎず、後⼯程の責務と分離されている Blockerがゼロなら、MajorやMinorが残っていてもSoftware Factoryに流してよい
21. 検証する：PdMが⾒るのは、V字の上の2段だけ Software Factory前提のV字モデル。左の⼯程で決めた⼈が、右の⼯程で確かめる PdM AI‧Eng QA レビュー：Biz‧Eng‧ApD‧QA リリース前から回す MRD PdM 顧客での検証 PdM 顧客の課題と価値の仮説 インタビューやプロトタイプを顧客に当てる レビュー：Eng‧ApD‧QA 決めた⼈が確かめる 要求仕様書 PdM PdMが意図して決めたこと この段は、⼈とAIの両⽅が⾒る 受⼊確認 PdM リスク検証 QA その意図がプロトタイプの 体験に表れているか リスクが⾼い ケースを検証 ◆ 設計ready（ブロッカー0件） レビュー：Eng‧ApD‧QA‧PdM システム仕様 AI システムテスト AI 技術的な専⾨知識をもとに網羅的に記載 境界値‧状態×権限の組み合わせを網羅 ◆ 設計レビュー レビュー：Eng 設計 Eng‧AI 結合‧単体テスト AI システム設計 AIが⽣成して⾃動で実⾏ プロトタイプ実装 本実装 Software Factoryが⽣成‧検証する範囲 PdM QA AIの仮決定 顧客に当てて検証する未知のことと、意図して決めたことが体験 に表れているか リスクが⾼いケースの検証 （網羅はAIのテスト） プロダクト判断はPdMが承認 技術判断はEngに回す
22. 04 Software Factoryに、 実際に流してみた freee請求書の2案件での⼀気通貫検証
23. 企画から実装まで⼀気通貫で通し、「Software Factoryの指標」で測った 難易度の違う2案件を選んだのは、Software Factoryがどこまで通⽤するかの幅を⾒るため freee請求書 企画意図 申請‧承認系の機能 要求仕様書 難易度：中〜⾼ freee請求書 設計ready システム 仕様 UIの⾒た⽬と使いやすさの改善 設計 レビュー 難易度：低 プロトタイプ ⽬的は速さの証明ではなく、「繋ぎ⽬で何が詰まるか」を洗い出すこと 計測した指標 ⏱ マシンの実⾏時間 $ トークンコスト ? 成果物の修正回数
24. プロトタイプでPdMが確かめたのは、70〜78項⽬のうち17項⽬ freee請求書の2案件で、AIが出した検証チェックリストを「PdMにしか判断できないもの」に絞った 申請‧承認系の機能 70 → 17 項⽬ UIの⾒た⽬と使いやすさの改善 78 → 17 項⽬ PdMが確かめる 意図して決めたことが体験に表れているか QA‧⾃動テストへ 合否が機械的に決まる網羅 • ⼀連の操作が、既存の操作の流れの中で完結するか • 上限と境界値 • 意図して決めたルールが守られているか（例：承認中は対象の 資料を差し替えられない） • 7つのステータスと各操作の全組み合わせ • 範囲の線引き（作り込みすぎていないか） • モバイル、アクセシビリティ、プラン別の表⽰ • AIの仮決定のうち、プロダクトとしての判断が必要なものを 承認する • 適⽤の前後で出⼒が変わらないこと • ロール別の権限、URLを直接⼊⼒したときの挙動 PdMが⾒るのは全体の4分の1以下 残りはQAと⾃動テストが網羅する
25. 企画意図を渡しただけで、ほぼ意図どおりのものが出てきた PdMが意図して決めたことは、ほぼそのままプロトタイプの体験に表れていた 案件 申請‧承認系の機能 難易度：中〜⾼ UIの⾒た⽬と使いやすさの改善 難易度：低 NGは作り直し（rework）に回した 意図が体験に表れていたか ✓ ✓ ✓ ✓ ✓ ✓ ✓ 13項⽬中 OK 10 ∕ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ NG 1 ✓ 11項⽬中 OK 9 ∕ ✓ ✗ − − ∕ 未検証 2 ✓ ✓ ✗ ✗ NG 2 ⽂書では決めきれなかった論点も、動くものを触る と決められた
26. 意図どおりに出たかを点数にし、⾜りなかった知識をナレッジベースに戻す 1 2 点数にする 外れた原因を3つに分ける UATの項⽬数を満点にして、意図したもの が出⼒されたかを評価 3 書き戻す 決めた内容は、要求仕様書の付記と、 要求起因 PdMが決めていなかった 解決済みの論点の⼀覧に書き戻す 要求起因のうち知識が⾜りなかったも ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✗ − − ✓ 設計起因 仮決定の副作⽤ 申請‧承認系の機能 Eng側の⽣成の問題 のは、ナレッジベースに戻す AIが仮に決めたことが、意図 とずれた 13項⽬中10項⽬（約77%） ＝ 検証して分かったことが、次の企画の「既知」になる
27. 05 正直なところ、まだ道半ばです 効いていないこと、残っていること
28. 動作検証では⼿応えを得た。でも「出荷できる」と⾔い切れるかには、不安が残った Engとの振り返り ⼿応え 不安 プロトタイプの動作検証では、PdMの視 点でもEngの視点でも、意図したものが 出てきている⼿応えを得た 本番に出荷できるレベルまで、網羅的に品質を保証しきれているか • AIが⽣成したドキュメントやコードを、⼈がすべてレビューするのは現実的ではない。 量が多すぎて、⼈がボトルネックに戻ってしまう • これまでは、要求仕様書や設計書を読み込むなかで「仕様として正しいか」を担保していた。 その⼯程がなくなった いま考えている打ち⼿ ⼈は重要な観点に絞ってレビューし、網羅はテスト で担保する ⽣成された仕様をレビューするステップを、 （例：テストケースを洗い出せていて、すべて通れ ⼯程として置くかどうか ば出荷してよい） プロトタイプで「よさそう」となったあとの ⼯程を、Software Factoryがどこまでカバー するか 次の⼀⼿：Software Factory前提で、品質保証を設計し直す
29. うまくいっていないことも、そのまま話します シニアPdMの時間は、 劇的には減っていない 全社展開は、 まだ道半ば • 競合調査や他システム連携の懸念 • まずは対象プロダクトを絞り、 整理は速くなったが、そこは元々 圧倒的な⽣産性向上を実証する 時間の⼤半ではなかった ことを優先している • AIに渡すインプットを書く労⼒ が、従来のPRDを書くのと同じく らいかかった Software Factoryは 稼働し始めたばかり • 意図したものとは違うものが出て くることも、まだある
30. 開発が速くなって、PdMが⼒を注ぐ場所はこう変わった これまで これから 既存仕様を、企画のたびに調べる → ナレッジベースを整え、AIが⾃分で引ける状態に保つ 分かったことが、個⼈の頭に残る → 検証で分かったことを、ナレッジベースに戻す 考えうるケースを、⽂書で網羅する → チームに理由を説明できる業務要求‧業務ルールだけを決める 仕様をまとめて、開発に渡す → コードベースの調査や技術的な専⾨知識が要る仕様は、 AIが網羅的に書き、⼈がレビューする 仮説を⽂書で詰めてから作る → 動くプロトタイプを速く出し、顧客に当てて未知を既知に変える ⽂書も画⾯も、すべてレビューする → 意図して決めたことだけを⾒て、網羅は仕組みに任せる 渡す 決める 検証する
31. 次は、顧客に当てて検証する回数を増やす 動くものが数⽇で出るなら これまで これから プロトタイプを顧客に当てる 回数を増やせる 要件定義‧設計‧実装に それなりに時間がかかっていた 次のフェーズ：探索の段階のAI Native化（企画の⼊⼝を、さらに上流へ） 渡す ナレッジベースにある既知の知 から、精度の⾼い初期仮説を 引き出す 検証する その仮説の上でプロトタイプを つくり、顧客に早く当てて 検証する 渡す → 決める → 検証するの輪を探索まで広げる 渡すへ戻る 検証で分かったことは、 またナレッジベースに戻る
32. まとめ 開発が⾼速になると、PdMが注⼒すべき仕事は「渡す‧決める‧検証する」になる 1 2 3 渡す 決める 検証する AIで要求から開発を⼀気通貫で⾼速化するための精度を決めたのは、 ナレッジベースだった 書くのは、PdMが説明責任を持てる要求にフォーカス。 コードや専⾨知識が要る判断は、AIが網羅的に記載しチームでレビュー 動くプロトタイプを速く出し、顧客に当てて、「未知の知」を「既知の知」に変えていく。 既知になったことは、次の企画に渡す