freeeにおける⼤規模ソフトウェアファクトリーの実践_AI×開発組織Summit 2026

Transcript

1. freeeにおける ⼤規模ソフトウェアファクトリーの実践 AI×開発組織Summit 2026 freee株式会社 取締役 CAIO 特別講演 横路 隆 ｜ 2026年10⽉16⽇
2. 慶應義塾大学大学院修了後、ソニー株式会社に 入社。2012年、現代表取締役CEO佐々木ととも にfreeeを共同創業。以来、freee会計の基礎と なる機能開発を多数手がけ、freee社の技術面 を牽引。 横路 隆 取締役 CAIO Yokoji RYu 2015年、CTO就任。2026年1月に退任し、新設 されたCAIO（Chief AI Officer）に就任。AIを経 営の根幹と位置付け、プロダクトと技術を最も理 解する立場として、AIによる社内の業務変革と、 顧客への新たな価値提供を推進している。 日本CTO協会顧問。 2
3. freee Movement Deck スモールビジネスを、 世界の主役に。 freeeは「スモールビジネスを、世界の主役に。」をミッションに 掲げ、統合型経営プラットフォームを開発・提供し、 だれもが自由に自然体で経営できる環境をつくっていきます。 起業やビジネスを育てていくことを、もっと魅力的で気軽な 行為に。個人事業や中小企業などのスモールビジネスに携わる すべての人が、じぶんらしく自信をもって経営できるように。 大胆にスピード感をもってアイデアを具現化できる スモールビジネスは、今までにない多様な価値観や生き方、 新しいイノベーションを生み出す起爆剤だと私たちは考えています。 スモールビジネスが大企業を刺激し、社会をさらにオモシロク、 世の中全体をより豊かにする流れを後押ししていきます。 3
4. freeeは40を超えるプロダクトを統合型ERPとして提供し、 有料課⾦ユーザーは約70万社に。 40+ 約70万社 プロダクト数 有料課⾦企業数 マルチプロダクト 統合体験を提供 制度‧法令が仕様に直結 会計‧⼈事労務の他に、販売‧⽀出 ‧IT管理‧固定資産‧申告など マルチにプロダクトを提供 1つの企画でも他プロダクトへの影 響と、⼀体になった体験を考える必 要がある 企画に必要な前提知識が極端に重い 構造。業種ごとに会計基準そのもの が分かれる 4
5. AIによって、ものづくりは確実に速くなった 1.90倍 3.95倍 89.6% プルリクエスト数 変更⾏数 AI⽣成コードの割合 前年同⽉⽐ 前年同⽉⽐ 2026年9⽉時点 出典：freee社内計測（2026年9⽉時点） 5
6. チームでのAI活⽤の枠を超えて全社標準化へ freeeの現在地 全社標準化 チーム内活⽤ 個⼈の⼯夫 ⾃然と誰もが 使いこなす AIの恩恵を 使いこなす⼈ チームだけが 受ける だけが速い 早い 良い方法を開発の標準的な流れに組み込む
7. freeeがSoftware Factoryに取り組む理由 既に資産として顧客価値を見極め・作り・届ける基盤を持ち、AI時代に我々の市場がさらに拡大すると信じているから。 ① ② ③ Horizontal SaaS コンパウンド戦略 ミッションクリティカルな領域 • 顧客価値を証明済みのB2B業 務領域と顧客基盤が⼀定規模 で既に存在 • 複数業務領域へのプロダクトを 展開し、これまでも統合価値を 訴求 • AI以前は費⽤対効果の合わな かった中⼩企業向けのカスタ マイズ開発が安価に提供可能 になり、市場が拡⼤ • 認証‧権限‧課⾦‧ワークフ ロー‧監査‧API‧CI/CDな ど、共通基盤の共通資産が既に ある • 会計‧⼈事労務などの、正確性 と⼈が責任をとることが求めら れるドメインで、ナレッジと専 ⾨⼈材が集積 • 毎年の法改正の対応を含む、持 続的なSaaSの安定提供 • プロダクトと共有データが増え るほど、顧客価値が複利で向上 需要確実性 × 市場拡⼤期 × 再利⽤可能資産 × 要求品質
8. freeeにおける⼤規模ソフトウェアファクトリーの実践 1. Software Factoryはどのように動いているのか 2. 実践した結果と学び 3. freeeの次への挑戦
9. 01 Software Factory はどう動いているか
10. Software Factory とは？ 開発の⼿順‧ツール‧品質管理を標準化し、⼯業製品のように⼤量⽣産する仕組み Software Factory 改善 要求 ガイド 修正 開発 出荷可能な ソフトウェア センサー 10
11. Software Factory の全体像 開発プロセスを⽀える仕組み ✓ ナレッジ ハーネス ⼈のレビュー 既存の仕様や判断の コンテキストを渡す ⽣成‧検証‧修正を回す 意図と判断を確かめる フィードバックをSoftware Factoryに渡し、必要な上流から再実⾏
12. Software Factory の全体像 シフトレフトとフィードバックサイクル⾼速化 必要に応じて⼈が成果物を確認 ⽬的や 必要な情報 要求 ⼈がまとめて確認 要件定義 設計 実装 プロトタイプ AIが仮決めした判断は プロトタイプ開発：完全⾃動 未確定事項として残す 参照 テスト設計‧実⾏（並⾏して進む） テスト結果 mainにマージ 要件‧設計 レビュー プロトタイプの 動作確認 未確定事項の ⾒直し リリース マージ時に更新 ナレッジベース 既存仕様‧⽤語‧業務ルール ∕ 設計⽅針‧過去の意思決定 ── 複数の情報源を横断して参照する共通の基盤
13. Software Factory の全体像 シフトレフトとフィードバックサイクル⾼速化 フィードバック内容に応じて、要件定義または設計から⼀式を差分修正 ⽬的や 必要な情報 要求 ⼈がまとめて確認 要件定義 設計 実装 プロトタイプ AIが仮決めした判断は プロトタイプ開発：完全⾃動 未確定事項として残す 参照 テスト設計‧実⾏（並⾏して進む） テスト結果 mainにマージ 要件‧設計 レビュー プロトタイプの 動作確認 未確定事項の ⾒直し リリース マージ時に更新 ナレッジベース 既存仕様‧⽤語‧業務ルール ∕ 設計⽅針‧過去の意思決定 ── 複数の情報源を横断して参照する共通の基盤
14. ハーネス ガイドで渡し、センサーで⽌め、AIと⼈の⼆重レビューで確かめ、誤りは上流から直す Orchestrator ｜ 依存順に実⾏ ∕ 完了を機械検査 ∕ 中断から再開 ∕ 時間‧コスト‧⼈の介⼊を記録 ガイド：コンテキストと作法 センサー：機械の検証 • ⽤語集‧ADR‧既存コードの調査結果を、作業前に 必ず共有する • 出⼒形式‧粒度‧⼯程間の受け渡しを「契約」とし て固定する • 要件⇔テストの対応を突合し、抜けを列挙する • 必須成果物‧契約を検査し、全充⾜で初めて次⼯程 へ進める レビュー：AIと⼈の⼆重化 フォローアップ：誤りを特定し上流から⼀ 括で修正 • 観点別‧根拠必須の指摘。⾃動修正は上限を設け、 収束しなければ⼈へ • ⼈は全⽂を読まず、判断すべき要点だけを確認する • AIの仮決定と⼈の承認を区別して記録‧追跡する • 誤りが混⼊した⼯程を特定し、上流から⼀括修正し て該当ゲートへ再⼊ 14
15. ⼈のレビュー ⼈間が責任を持って判断するべきポイントを⽰す 夜 AI稼働 朝 差分再実⾏ 指⽰を置く 要件→設計→実装→ テスト（並列） 判断点だけを確認 要件または設計から ⼀式を修正 ① クラウド開発環境 ② 未確定事項⼀覧 ③ ⼈向けレビューView • 個⼈の端末に依存せず、⼈が不 在の間も処理を続ける • AIが仮決めした判断は「未確定 事項」として残し、⼈の承認と 区別して記録‧追跡 • 設計書はAI⽤に省略せず網羅的 に残す • 進⾏状況と成果物をチームで共 有し、途中から判断に参加でき る • 朝は仮決定の承認と残った論点 だけに向き合う • ⼈は「全体像‧事実‧理由‧問 い」に絞った別のViewで、判断 する場所だけを⾒る 15
16. 「作る」が速くなった分、企画と検証の速度も必要になる 企画 これまで 設計 実装 テスト・検証 リリース 設計・実装が高速に Software Factory以後 人の速さで進む工程（長さは変わらない） 企画 テスト‧検証 リリース AIで速くなった工程（Software Factory） 企画と検証は人の速さのまま → 全体の大半を占め、ボトルネックに ※ ⼯程の⻑さはイメージ Software Factoryが速くなるほど、その前後にある企画と検証が全体の速さを決める ＝ Software Factoryの⼊⼝にある企画が詰まり始めた。 そこで「AIで企画プロセスを⾼速化するプロジェクト」を⽴ち上げた
17. Software Factoryの体制 Software Factoryを⼟台に、超速企画と超速開発ラボが体制を整え、プロダクトチームが実案件で使う プロダクトチーム ⼯場の「仕組み」を使う Eng‧PdM‧QA‧ApD • 実案件をファクトリーに流す • ⼈が判断した観点をナレッジに戻す • Factory Owner∕Outcome Ownerを担う 超速企画プロジェクト CTO室 超速開発ラボ ⼯場の「⼊⼝」を整える ⼯場の「中⾝」を作る • 企画と開発で共有するナレッジベースを整備 • PdMが決める要求の範囲と「設計readyゲート」を定義 • 複数プロダクトで実証（2026年7⽉〜） • ハーネスとモジュール化されたパイプラインを開発 • 評価データセットと、⼯場を計測する基盤を整備 • 改善した仕組みを各チームへ届ける ⼟台 Software Factory ナレッジ 既存の仕様や判断の コンテキストを渡す ハーネス ⼈のレビュー ⽣成‧検証‧修正を回す 意図と判断を確かめる
18. Software Factoryのロール ⼈はファクトリーの品質と顧客価値に責任を持ち、AIは実⾏を担う Factory Owner（⼯場⻑） Outcome Owner 出⼒の品質を保つ ＝ ラインと検証を設計 本質的な顧客価値を届ける ＝ 要求の投⼊と出荷判断 • 検証設計の厚みを保つ • 解く課題と優先度を決める • 何を合意し、何を委ねるかを決める • 受け⼊れ基準を定義する • 環境と権限を整える • 出す∕出さないを決める • 基準を外れたらラインを⽌める • なぜこの⽅針かを残す 18
19. 02 実践した結果と学び
20. Software Factoryを実践した結果、 開発リードタイムが⼤幅に削減 開発 企画⽂書 ハーネスの回し⽅を変えた実測（要件→プロトタイプ、⼈待ちを除く） MRD‧要求仕様書の作成時間（2026年7⽉、複数プロダクトで実証） AI稼働 プロダクト 従来 導⼊後 削減率 ⽀出 4時間 1時間 75% 固定資産 1週間 2〜3⽇ 約60% 申告 2⽇ 2時間 約88% IT管理 2⽇ 2時間 約88% ⼈事労務 2⽇ 2時間 約88% 約15.6時間 約5時間 −68% フォローアップ 約4.5時間 約53分 −80% 開発‧企画のどちらも、リードタイムを 60〜90% 短縮 20
21. ⼀⽅、ファクトリー化を進める中で課題も⾒えてきた ✓ ナレッジ ファクトリーが効くのは、 ナレッジが揃った領域 適する状況 既存仕様・用語・業務ルールが 明文化されている領域 適さない状況 業務が属人化している・言語化されて いない等ナレッジが薄い領域 ハーネス ⼈のレビュー リリースできるというには、まだ 品質に不安が残る AIが高速で書きあげるが、 • 意図と違うものが出てくる • ハーネスの設計が不十分 • 読む手間も、レビューする手間 も、トークンも増える • どこを判断すれば良いか分から ない 人間が読み終わらない 人間がボトルネックになる
22. 既知の知を、AIが⾃分で参照できるナレッジベースに置く 企画と開発で共有するナレッジベース（イメージ） ⼯程の流れ 探索 PdM 企画 PdM AI：企画案を広げて選ぶ AI：要求仕様を書く 1 真ん中にナレッジベース 参照する ⾜りない知識を更新 現⾏仕様‧⽤語集‧法令‧制度‧意思決定の 記録‧不具合‧サポート履歴など。複数の データストアを抽象化した総称 Knowledge Base 複数のデータストアを抽象化した総称 運⽤ CS‧PdM AI：問い合わせ‧ 不具合から学ぶ 現⾏仕様 ⽤語集 法令‧制度 意思決定の記録 不具合‧障害 サポート履歴 顧客の要望 QAナレッジ バックログ ロードマップ 事業戦略 依存関係 設計 Eng AI：設計‧テスト設計 2 探索‧企画‧設計‧実装‧リリース‧運⽤の AIが、同じ場所から知識を引く 3 リリース QA‧PdM‧Eng 実装 Eng AI：仕様と実装のずれを検出 AI：コード‧テストを書く 全⼯程のAIが参照する ⾜りなければ更新して戻す 「既存仕様や法令‧制度の資料が⾜りない」 は、ナレッジの更新として返す
23. ハーネスと⼈のレビュー AI向けと⼈向けのドキュメントを分ける 設計書は省略しない。読む相⼿に合わせて⾒せ⽅を分ける AI AI ⽤：元の設計書をそのまま読む 細かく、網羅的に 項⽬の型‧必須‧桁まで 設計書 (SSoT)   実装   テスト すべてのAPIの⼊⼒と出⼒ AIレビュー 例外‧エラーのすべてのパターン 網羅的に書く 省略しない‧要約しない ⼈ ⼈⽤：理解しやすく、絞ったViewを別に作る 全体像：情報のつながり 判断する場所だけを⾒る freee のルールを加味 ⼀般論ではなく、プロダクト‧ ドメインの決まりごとに沿って  理解 しやすく  絞る  判断点：事実‧理由‧問い レビューView 細かい属性‧標準のAPI → AIに任せる 設計書は削らない。 AIは全部を読み、人は理解しやすく絞った Viewを見る
24. ⼯場からの通知を起点に、⼈はレビューViewだけを⾒る 社内ツールの機能開発 1 案件を、要求からテスト分析まで⾃動レーンで流した実例（2026年9⽉） 1 Factory の 起動 🔥 自動レーン / <案件名> level=high implement=prototype depth=minimal entry=requirement • 要求を⼊れてレーンを起 動。難易度‧試作か本番か ‧深さ‧起点⼯程を指定 • 成果物と判断の履歴はリポ ジトリに⾃動蓄積 2 ⼯程ごとにViewを公開 3 ⼈が問いに答える 📄 requirement のレビュー View 判断 3 件 📄 design のレビューView 判断 11 件 📄 test-analysis のレビュー View 確認 85 件 判断 76 件（未確認 58 / 要変 更 0） 設計の方針 6 本 → 個々の判断 → 承認 • ⼈向けビューは判断点だけ を抜き出した別 View • 設計書‧分析書は削らず、AI が全⽂を読む • 設計書は開かない。事実‧ 理由‧問いを読んで決める • ⼈の判断は承認∕変更とし て記録に残る 4 上流から直す 🔁 rework を開始しました （起点: requirement / 変更: system-spec, domain-model, api, sequence, frontend） • 誤りが⼊った⼯程から差分 再実⾏。下流は⾃動で作り 直す • 承認されるまで 2 → 3 → 4 を繰り返す 承認されるまで繰り返す（通知はすべて Slack に⾃動投稿） ※ 通知⽂‧件数は実際の投稿を簡略化して転記。案件名‧リンクは省略
25. ハーネスと⼈のレビュー ⾒る場所を絞るためにレビューの観点を取り⼊れる 溜める観点のナレッジ 共通の観点 今回の成果物 要件‧設計‧未確定事項⼀覧‧ AIレビューの指摘 設計⽅針‧データモデル‧API I/F‧ 状態遷移‧業務ルール‧要求との対応‧ ⾮機能⾯‧システム間連携 ⼈向けのレビューHTML 全体像 情報の関係と判断する場所 事実 何を作るのか 理由 なぜそう決めたのか 問い ⼈に判断してほしいこと 掛け合わせて ⼈が判断する箇所を絞り込む プロダクト特有の観点 ‧ドメインのコア（給与計算など） ‧freee‧プロダクト独⾃の部分 例：給与の反映⽉、確定済み給与の遡及‧ 差額 採⽤する ∕ 軽く確認する ∕ 機械に任 せる を理由付きで整理
26. ハーネスと⼈のレビュー 判断が要るところだけ⾒せる シニアエンジニアにヒアリングして、設計で⾒たい観点を整理した 隠す（判断不要） ⾒たい観点：共通の8つ ＋ プロダクト特有 設計⽅針 データモデル API I/F ⽅針が要件の⼤枠に合っているか ⾮⾃明な判断に、根拠があるか 粒度‧関係性‧Value Object、なぜそうしたか 集約の責務と境界、不変条件をどこで守るか 画⾯起点で、CRUDから外れたところ エラー応答‧認可まで決まっているか 状態遷移 システム間連携 業務ルール 異常ルート‧業務例外ルート 同じデータを触る操作の競合‧順序 外部連携のシーケンスと、どう影響するか 送信‧確定など、戻せなくなる点はどこか 業務ルール‧法令から導いた不変条件 境界値（ゼロ‧上限‧端数）の扱い 要求との対応 ⾮機能⾯ プロダクト特有 すべてのUC‧不変条件が設計に対応しているか 要件にない先回りの設計がないか 権限‧性能‧監査‧信頼性 機能を⽌めたときの流出経路と、切り戻し⼿段 ⼈事労務なら、給与計算まわりを重厚に 例：給与の反映⽉、確定済み給与の遡及‧差額 ‧標準のCRUD ‧既存ルールどおりのAPI ‧コードや既存仕様を 調べれば分かること 人に聞くのは 4つだけ 事業判断 ／ 利用者の挙動 ／ 他チームとの契約・制約 ／ 不可逆なリスク
27. ハーネスと⼈のレビュー 観点ごとに今回どこまで確認するかを⽰す レビュー観点：採⽤‧軽く確認‧最重要‧機械検証‧低優先を、理由付きで⽰す 共通観点 × ドメイン観点の採否
28. ハーネスと⼈のレビュー ⼈が判断する問いまで具体的に⽰す 成果物区分を後から変えても完了した記録はそのままにし、次に記録を直すときだけ新しい区分で確かめる 業務ルール‧様式 HIGH 未確認 出どころ OQ-030 設計した事実 なぜそうしたか ⼈が判断する問い 「完了なら成果物が必要」という 確認は、記録したときにだけ⾏い ます。区分を変える前に完了にし た記録を遡って確かめ直すことは しません。 記録済みの実績をマスタの編集で 崩さないため。次に記録を更新す るときに直せば⾜りる。 区分を「成果物を必ず残す」へ変 えた後も、それ以前の完了が成果 物なしのまま残ることを許容でき ますか。 全⽂を読み解くところから、この設計でよいかを判断するところへ
29. ハーネスと⼈のレビュー 観点を溜めるほど「⾒なくていい」が増える ⼈が⾒る量の変化（イメージ） 今 ① 観点をナレッジに溜める 共通の観点 ∕ ドメイン固有の観点 ② AIのレビュー‧テストが 判定できる範囲が広がる ⼈が⾒る AIに任せる 観点が溜まると ⼈が⾒て気づいた 観点をナレッジに戻す ③ ⼈は残った 判断点だけを⾒る 実例：「成果物どうしの⾷い違い」は機械レビューが12観点で照合済み ↓ ⼈は残った指摘だけを⾒る ⼈が⾒る AIのレビュー‧テストで確認 ＝ ⾒なくていい ⾒る量を減らすのは、読み⾶ばしではなく 「確認済み」を増やすこと
30. freeeが⽬指しているのは選択的Dark Factory freeeのステップ STEP 1 STEP 2 STEP 3 STEP 4 選択的Dark Factory 今後 現在地 個⼈のAI活⽤ ローカルAgent チーム利⽤への昇華 計測可能な Software Factory 2023年〜2024年 2025年1⽉〜夏頃 2025年8⽉〜2026年3⽉ 2026年4⽉〜現在 STEP 5
31. ⾃動化と同時に、価値を創出するために⼈が⾒るべきポイントに 集中できる状態を作りだす ✕ ダークファクトリー 🌚 ⼈を排除した完全無⼈の⼯場 • 誰にも理解されない成果物が蓄積し、障害時の対応コス トが跳ね上がる • AIはドメイン知識‧⻑期的な設計意図‧最終責任を完全 には持てない 🌝 ✕ ライトファクトリー ⼈が全⼯程を理解‧監視し続ける⼯場 • ⽣成速度が上がるほど、⼈の意思決定とレビューが律速 になる • シフトレフトしても、⼈の仕事を上流へ移しただけでは 解決しない ⽬指す姿 選択的Dark Factory 判断が要るところだけ⼈が⾒て、それ以外はAIと 機械に任せる⼯場 • ⽌められるものは機械で、判断が要るものはLLM で、残る判断だけを⼈へ • ⼈に聞くのは4つだけ：事業判断‧利⽤者の挙動‧他 チームとの契約‧不可逆なリスク • ⼈の介在率をKPIにし、「⾒なくていい」範囲を広げ ていく ⼈の認知負荷を、判断が要る点だけに集中させ、 デリバリーのインパクトを最⼤化する。 コードには着⽬しない。成果物の仕様とテスト結果を⾒て不安があれば必要なところでスポットライト当てる。
32. 開発者は⼈にしかできないことに時間を使う Software Factory：複数の案件を並列で進める 案件A 案件B 判断待ち 実装 → テスト 判断待ち 判断 ユーザーと話す 判断 判断待ち 要件 → 設計 → 実装 → テスト 要件 → 設計 → 実装 → テスト 要件 → 設計 → 実装 → テスト 案件C ⼈ 要件 → 設計 → 実装 → テスト 判断待ち 新しい技術を試す 判断 判断待ち 実装 → テスト 要件 → 設計 → 実装 → テスト 観点を溜める 判断 仕組みを改善 判断 判断待ち ユーザーと話す 判断 新しい技術を試す ⼯場が動いている間の時間を、ユーザー‧技術‧品質‧仕組みづくりに使う 何を作るか ユーザーと話し、プロダク トを企画する どう作るか 新しい技術を試し、全体の アーキテクチャを考える 品質をつくる 判断の観点をナレッジに溜 め、AIが確かめる範囲を広 げる 開発の仕組みを育てる ⼯場の待ち時間や⼈の負担 を⾒つけて、改善する
33. 03 freeeの次への挑戦
34. ファクトリーを全チームへ標準化し、24時間稼働を⽬指す 超短周期スプリント クラウド開発環境への 完全移行 24時間稼働する Software Factory 週単位から「 1日複数回」へ ローカル脱却と共通基盤化 AIによる止まらない自動開発 従来の1〜2週間単位のデプロイ・開発 サイクルを根本から見直し、1日に複数 回のサイクルを回す超高速開発へ進 化。 個人のローカル端末依存から、クラウド 上の統一された共通開発環境へと移 行。リアルタイムな状況可視化を実現。 人間の開発現場がオフラインとなる夜間 や休日も、クラウド上のAIエージェントが 自律的に稼働・テスト・構築を進行。 期待される効果 期待される効果 成果物・プロセスの即時共有により、サ イロ化を防ぎチーム全体の透明性が向 上。 開発リソースの限界を超えた連続的な 価値創出と生産性の極大化。 期待される効果 フィードバックループの圧倒的短縮と、 機能提供スピードの爆発的な向上。 34
35. Software Factory時代にマッチした 組織体制や開発者の役割をアップデート • ファクトリーの安定運⽤‧改善ができるファクト リーオーナー、顧客価値の最⼤化に責任を持つ エンジニアの育成 • SoftwareFactoryにマッチした既存の開発者の役 割定義を再定義し、ジュニア〜シニアまでを対象 とした育成施策やキャリアパス設計
36. AI時代に価値を届ける仕組みを ⼀緒に作りませんか？ • プロダクトリードエンジニア • データエンジニア • プロダクトマネージャー • 社内AI推進エンジニア 等 積極採⽤中！！