freeeにおけるSoftware Factory

freee 技術の日 2026のセッション資料です。

Transcript

1. 顧客価値を起点に開発プロセスと組織を変える全社規模の挑戦 freeeにおけるSoftware Factory kei / ken 2026年10⽉3⽇
2. 写真を⼊れる CTO室超速開発ラボ リードエンジニア 写真を⼊れる CTO室超速開発ラボ リードエンジニア kei ken freee人事労務の開発を経て、現在で は基盤開発チームでプロダクトリードエ ンジニアとマネージャーを務めつつ、 超速開発（Software Factory）の開 発を行っています。 フューチャーで基幹システムの設計・ 開発に従事後、2024年にfreee入社。 freee会計・基盤プロダクトのエンジニ ア、マネージャを経て、現在は統合モ ジュールのマネジメントと超速開発を 兼務。
3. 01 freeeの Software Factoryの全体像 個⼈の⼯夫を、全社で回る開発プロセスへ
4. freeeのSoftware Factoryの全体像 AI活⽤の課題 ! AI活⽤度のばらつき ! ⼈やチームによって活⽤度合いに ⼤きな差が⽣じている。 ! ノウハウ共有の不全 活⽤できている個⼈の知⾒やノウハウが、 組織全体に展開‧共有されていない。 ⽬的化するAI利⽤ AIを活⽤すること⾃体が⽬的化してしまい、 ⼈によってはついていけず負担になる。 ! 共通化しても浸透しない 良い仕組みを作っても使われない。 仕組みの存在⾃体が知られない。 メンテナンスが属⼈化してしまう。
5. freeeのSoftware Factoryの全体像 世界的なSoftware Factory本格化の流れ • ソフトウェア開発ライフサイクル(SDLC)全体の自動化がトレンドに。 • 先進事例: RampやFactoryなどにみられるSDLC全体を対象としたファクトリーの構築。
6. freeeのSoftware Factoryの全体像 Software Factoryとは ソフトウェア開発の⼿順やツール‧品質管理などを標準化し⼯業製品のように効率的かつ⼤量に⽣産する仕組みや考え⽅ Software Factory 改善 要求 ガイド 修正 開発 出荷可能な ソフトウェア センサー ⼈間は価値の発⾒‧探索にさらに⼒を⼊れられるようにするため ソフトウェアは⾃律的に⼯場製品のような⾼度な⽣産管理によって構築される ソフトウェア開発のD4U（Done for You）
7. freeeのSoftware Factoryの全体像 「部分⾃動化」の罠とプロセス全体の重要性 ✕ 部分自動化の限界とリスク ◯ プロセス全体での整合性確保 1. 実装フェーズのみの自動化の限界 「思った実装と違う」という問題が多発。 上流から一貫した正しさを追求することで、 真の自動化価値を発揮 2. 手戻りの発生 テストを自動化しても、仕様や設計のズレがあれば意味が ない。 正しい要求仕様 ↓ 正しい設計 ↓ 正しい実装・テスト 正しい実装は正しい設計から、正しい設計は正しい要求仕様から生まれる。
8. freeeのSoftware Factoryの全体像 統合ERP（単⼀プロダクト群）の強みと複雑性 統一された世界観 相互依存と複雑性 組織的課題の克服 【強み】統合 ERPの一体感 【構造的課題】影響範囲が広大 単一のプロダクト群として、全社で 一貫したデザインポリシーと技術方 針を持っている。 多角的なプロダクト群が密接に連 携するため、システム全体の複雑 性が増大。 【組織的アプローチ】 Software Factoryへ • UI/UXのシームレスな 体験提供 • プロダクト間の深い相互依存関 係 • 共通化されたデータモデルによ る高効率なデータ連携 • 一部の改修が全体へ及ぼすリ グレッションリスク • 開発基盤の共通化によるス ピーディーな機能拡張 • 仕様・ドメインの高度な複雑性 の管理 多数のチームと多様なプロダクトを 一元的に集約・接続する困難を乗 り越える。 • チーム横断的な開発プロセス の標準化 • Software Factoryへの統合・ 接続プロセスの構築 • スケーラブルな組織体制と運用 の確立
9. freeeのSoftware Factoryの全体像 開発プロセスを⽀える仕組み ✓ ナレッジ ハーネス ⼈のレビュー 既存の仕様や判断の コンテキストを渡す ⽣成‧検証‧修正を回す 意図と判断を確かめる フィードバックをSoftware Factoryに渡し、必要な上流から再実⾏
10. freeeのSoftware Factoryの全体像 シフトレフトとフィードバックサイクル⾼速化 必要に応じて⼈が成果物を確認 ⽬的や 必要な情報 要求 ⼈がまとめて確認 要件定義 設計 実装 プロトタイプ AIが仮決めした判断は プロトタイプ開発：完全⾃動 未確定事項として残す 参照 テスト設計‧実⾏（並⾏して進む） テスト結果 mainにマージ 要件‧設計 レビュー プロトタイプの 動作確認 未確定事項の ⾒直し リリース マージ時に更新 ナレッジベース 既存仕様‧⽤語‧業務ルール ∕ 設計⽅針‧過去の意思決定 ── 複数の情報源を横断して参照する共通の基盤
11. freeeのSoftware Factoryの全体像 シフトレフトとフィードバックサイクル⾼速化 フィードバック内容に応じて、要件定義または設計から⼀式を差分修正 ⽬的や 必要な情報 要求 ⼈がまとめて確認 要件定義 設計 実装 プロトタイプ AIが仮決めした判断は プロトタイプ開発：完全⾃動 未確定事項として残す 参照 テスト設計‧実⾏（並⾏して進む） テスト結果 mainにマージ 要件‧設計 レビュー プロトタイプの 動作確認 未確定事項の ⾒直し リリース マージ時に更新 ナレッジベース 既存仕様‧⽤語‧業務ルール ∕ 設計⽅針‧過去の意思決定 ── 複数の情報源を横断して参照する共通の基盤
12. freeeのSoftware Factoryの全体像 AI前提の開発環境へ 組織・プロセス全体への浸透 AI前提の再設計 全体最適の実現 個人任せの活用にとどまらず、AI が自然と開発プロセスに組み込 まれる環境 を構築。 単に既存業務へAIを導入・追加す るのではなく、「AI前提で作る」 た めのナレッジ整備・アーキテクチャ ・組織・プロセスを整備し再現性を 高める。 優れた仕組みが無意識に適用さ れ、シニアエンジニアが全体最適 化に注力できる環境 を目指す。 組織全体で標準化された仕組み を通じて、開発者全員が日常的に AIの真価を発揮できるように支 援。 AIの能力を最大限に活かせる開 発を定義。 個人の成果を超えて、全社的かつ 持続的なインパクトを生み出す開発 体験を実現。
13. freeeのSoftware Factoryの全体像 AI活⽤の課題 全社標準化 チーム内活⽤ 個⼈の⼯夫 使いこなす⼈ 使いこなす ⾃然と誰もが だけが速い チームだけが AIの恩恵を 早い 受ける 良い方法を開発の標準的な流れに組み込む
14. 02 ハーネスと モジュール化されたパイプライン AIが要求から動く成果物まで作り切るための仕組み
15. ハーネスとモジュール化されたパイプライン freee Software Factoryのハーネス全体像 Orchestrator 拡張 依存順に実⾏ ∕ 完了を機械検査 ∕ 中断から再開 任意の連携‧未設定時は挙動不変 ⼯程の中で効くハーネス タスクモジュールの切替え ガイド: コンテキストと作法 センサー: 機械の検証 レビュー: AI と⼈の⼆重化 フォローアップ コンテキストを渡す テストを作る AI がレビューし直す 未確定事項⼀覧 ⽤語集‧ADR‧steering‧ 既存コードの調査結果を 作業前に必ず共有 テスト観点を粒度別に定義 要件⇔テストの対応を突合 し、抜けを列挙 観点別‧根拠必須の指摘、 ⾃動修正は上限を設け、収 束しなければ⼈へ AI の仮決定と⼈間の承認を 区別して記録‧追跡する 成果物の作り⽅を 揃える 機械で⽌める ⼈が確認する フォローアップ 必須成果物‧契約を検査し 全充⾜で初めて次⼯程へ 全⽂を読ませず、⼈が判断 すべき要点だけを確認 誤りが混⼊した⼯程を 出⼒形式‧粒度‧⼯程間の 受け渡しを契約として固定 ナレッジ検索 ナレッジグラフを利⽤し 再設計を防ぐ 特定し、上流から⼀括修正 する 修正は上流から反映し、該当⼯程のゲートへ再⼊ すべての⼯程を横断して⽀えるハーネス 実⾏を制御する ナレッジを保つ 実⾏を計測する 排他ロック‧並列書き込みの衝突検査 ⼆重起動は⽌まる側に倒して防ぐ SSoT を役割ごとに分ける 時間‧コスト‧⼈の介⼊を記録 誤りを検知し、⾃⼰評価‧改善できる環境へ プロジェクト履歴を残しフェーズを縦串で追跡 github / jira / local を選択 orchestratorがIssueを⾃律駆動 Factoryの⾃⼰改善 レビュー指摘を根本課題に集約 レビュー観点‧skill 改善へ還元 外部 UI‧実装 skill ⽤途に合うツール‧エージェン トと接続
16. ハーネスとモジュール化されたパイプライン 動く成果物まで⼀気通貫で作り、品質保証を早く回す 要件‧設計‧実際の動作を突き合わせ、整合性を確かめる 要求から⼀気通貫で作る   要件 設計 品質保証のサイクル    要件‧設計‧動作‧テスト結果 整合性と課題を検証 動く プロトタイプ テスト設計‧実⾏も並⾏して進む  ⾃動検証 ＋ ⼈のレビュー‧判断 実装‧検証ま で再実⾏  要件‧設計を更新 修正内容に応じて戻る 作る ➔ 整合性を確かめる ➔ 直す  フォローアップ 仕様を修正‧設計を改善‧品質を上げる
17. ハーネスとモジュール化されたパイプライン AI を速くしたのではなくハーネスの回し⽅を変えた 要件からプロトタイプ完成まで ⸺ ⼈待ちを除く AI 稼働の実測 AI 稼働 約 15.6 時間 → 約 5 時間 フォローアップ 改善前は、設計の⾃動レビュー‧修正の収束だけで 399 分かかっていた 01 終わりを決める 02 約 4.5 時間 → 約 53 分 変わった 2 タスクだけ実装し、12 タスクは再利⽤ フォローアップ の前に決める 03 まとめる‧並列にする 改善前 改善前 改善前 指摘のたびに、また⼀周 実⾏中に論点が増え、全体をやり直す 個別に修正し、順番に待つ 改善後 改善後 改善後 まとめ直して実物を確認 影響範囲と派⽣論点を先に確認 修正を⼀括で反映し 残る論点は 未確定事項 にして⼈が判断 変わった部分だけを直す 独⽴した⼯程を同時に進める 終わりを決め、先に決め、まとめて並列に回す 仮決定での完⾛は、リリース品質の承認ではない ⸺ 最後の判断は⼈が⾏う
18. ハーネスとモジュール化されたパイプライン 仕様を探る段階と、本番品質に仕上げる段階を分ける 試作で仕様を探り、固まったら確定した判断を引き継いで本番品質へ引き上げる 仕様を固める 01 要件 設計 本番品質へ引き上げる 02 動く プロトタイプ フォローアップ 仕様のズレ、未確定事項の フォローアップ をここで終える  設計を追記  テストを設計  コードを仕上げる 作り直さず 品質観点での 設計項⽬を⾜す テスト分析‧設計を実⾏ 計画を作り直し、本番品 質へ その後の フォローアップ は対象とその影響範囲だけ直す 機械的な検査は毎回全体にかけ、漏れを防ぐ ⾮機能のセンサー‧ガードレール 03  脆弱性診断 コード‧依存ライブラリ  性能チェック 負荷‧遅いクエリ  lint‧テスト‧CI 毎回、全体にかける 04  全体の最終審査 main へ出す前 試作で仕様を固め、本番品質と⾮機能のゲートを通して出す main へ 段階的にマージ
19. ハーネスとモジュール化されたパイプライン 機能適合性を軸に、⼈が担保していた確認を⼯場へ組み込む ISO/IEC 25010 の機能完全性と機能正確性に⼈の介⼊が多く潜む 機能完全性 Functional Completeness 機能正確性 Functional Correctness ⼈が担保していたこと： 必要な機能が、漏れなく⼊っているか 決定論 LLM 決定論 LLM LLM 静的レビュー（機械） 必須成果物‧契約‧ID のつながりを検査 静的レビュー（LLM） 要件‧設計‧計画を観点別に敵対的レビュー トレーサビリティマトリクス 要求→要件→設計→コード→テストを⾃動⽣成‧照合 AC ⇔ 実装 ⇔ テストの照合 受⼊条件ごとに、実装とテストの有無を確かめる ⼈が担保していたこと： 仕様どおりに、正しく動くか 実装済み 決定論 動的テスト CI‧カバレッジ‧ミューテーションテスト LLM テストケース⽣成 仕様から起こし、境界値‧異常系の観点を出す 実装済み LLM 仕様 ⇔ 実装の照合 テストオラクルの代わりに、仕様と実装を照らす 実装済み LLM 探索的テストのエージェント化 ブラウザを操作して、触って確かめる 構想 監視‧アラート＋ログ⼀次トリアージ リリース後のエラーを LLM が⼀次切り分け 構想 実装済み 実装済み 実装済み 決定論 LLM 決定論と LLM の⼆重で確かめ、⼈は最終判断に集中する ⽌められるものは機械で ∕ ⼀部 判断が要るものは LLM で ∕ それでも残る判断だけを⼈へ
20. ハーネスとモジュール化されたパイプライン トレーサビリティで後から直しても⽭盾させない 後⼯程で直すと、前⼯程と⽭盾しがち ── それを防ぐのがトレーサビリティ つながりがないと 要求 要件 設計 コード つながりがあると テスト 設計を直しても、要件‧コード‧テストは古いまま 要求 要件 設計 コード テスト つながりをたどって、前後のフェーズも揃える 整合性を保ったまま直せる ⾷い違いが⽣まれる フェーズ間チェック ＋ 敵対的レビューで確かめる ナレッジグラフ 要求からソースコードまでを、ID と関係で 1 つのグラフにつなぐ 要求 R-012 要件 UC-021 設計 ドメインモデル‧API コード テーブル‧関数 「この要求の実装はどこか」「この変更はどの要件に響くか」を辿れるから、 どこを直しても⽭盾なく直せる
21. ハーネスとモジュール化されたパイプライン SSoT はソース。設計書にはソースから読み取れない判断だけを書く ソースと⼆重管理はしない ── それでも設計書を書くのは、３つの役割があるから 何を書き、何をソースに任せるか 設計書の 3 つの役割 要件 ⼈が書く 何を‧なぜ作るか 概要設計（全体設計） ⼈が決める モジュールをまたぐ契約‧責務 freee‧プロダクト‧ドメインとしての判断 AI にとっての俯瞰図 ソースだけでは全体像をつかめず、エージェントも間違える 2 ⼈が判断する場 全体の⽅針は LLM ではなく⼈が決める 早い段階で決める 3 エージェントの記憶 フォローアップ してもセッションの記憶に頼らず、⻑期にわ たって開発を進められる プロトタイプで 先に作り 本実装で 設計を⾒直す 詳細設計 書かない ソースと⼆重管理しない ソースコード AI が実装する 1 設計の SSoT 設計書は、AI の俯瞰図であり、⼈の判断の場であり、エージェントの記憶 ⼆重管理しない ∕ 整合はトレーサビリティで確かめる ∕ ⻑期の開発を記憶に頼らず続けられる
22. ハーネスとモジュール化されたパイプライン ⼯場そのものを測り、間違いの原因までたどって直す 「何となく良くなった」ではなく、ログで測って直す 1 集める 2  評価データセット 決まった題材を定期的に 回して⽐べる  ⽇々の開発ログ 実際の開発を⼯場の モニタリングとして記録 測る 3 時間 リードタイム ⼈の介在率‧時間 コスト LLM のトークンコスト コンテキスト⽬安 いちばん⼤切 ⼯場のアウトプット品質 直す ナレッジ システム仕様‧法制度‧観点 ADR‧アーキテクチャ‧連携 ハーネス スキルとフロー（⼿順） ガイドとセンサー 結果だけでなく、中間成果物のどこでなぜ間違えたかをたどる 原因はここ 要求 要件 ここで間違えた 設計 コード テスト 例：コードの誤りでも、原因は要件を決めきれていなかった 直したら同じ評価で回し、ほかが壊れていないかも確かめる プロダクトのルール レイヤと責務‧ドメインモデル API の作り⽅
23. 03 全社ナレッジベースと 「暗黙知」の明⽂化 AIが知らないコンテキストを、参照できる形にする
24. 全社ナレッジベースと「暗黙知」の明⽂化 AIはプロダクトのコンテキストを知らない 現状のコード‧普遍的な情報 ⼀般的な実装⽅法なら、AIも知っている 暗黙知となっている 既存のプロダクト仕様 過去の判断と、その理由 利⽤者やサポートが知っている例外 コンテキストを伝えずに作ってもらうと ⼀般的には⾃然でも、 今のサービスには合わないものができる
25. 全社ナレッジベースと「暗黙知」の明⽂化 仕様とルールを参照できる形に 仕様 ルール 今、何がどう動いているか 何を基準に判断‧実装するか 現在の挙動‧例外 判断‧実装の⽅針 例：どういう条件で操作できるか 例：アクセス権をどう設計するか 変更の理由と出典も残す 人も確認でき、何を根拠に変えたかを辿れるように
26. 全社ナレッジベースと「暗黙知」の明⽂化 共通化できるナレッジと製品固有のナレッジ 共通のナレッジ 製品固有のナレッジ デザイン‧技術⽅針など 製品ごとの仕様‧例外、連携する製品への影響 複数チームで使う 製品ごとに保つ 参照 参照 今回の開発 今回確認した仕様や判断理由を、次の開発のコンテキストに
27. 全社ナレッジベースと「暗黙知」の明⽂化 ナレッジは⾃動で更新される
28. 全社ナレッジベースと「暗黙知」の明⽂化 全社ナレッジベースと暗黙知の明⽂化 コンテキストの共有 暗黙知のリスク回避 同じ過ちを繰り返さない freee固有コンテキストの参照 属人化によるデタラメ生成防止 明文化と自動生成のサイクル 実装や設計において、背景にある 思想やルールをAIに理解させるこ とが不可欠。 全社共通のナレッジベースを常に 参照させる仕組みにより、前提条 件のブレを防止。 ユーザーや一部のエンジニアのみ が知る「暗黙知」が放置されている 状態は危険。 獲得した知見や暗黙知を即座に 明文化し、ナレッジベースへ蓄積。 文脈を持たないAIは誤った推論を 行い、デタラメな成果物を生成す るリスクが。 次回以降、より素早く・正確な成果 物が自動生成される継続的改善 の仕組みを構築。 循環サイクル : 暗黙知の明文化 ➔ 全社ナレッジ蓄積 ➔ AI生成精度の進化 ➔ 開発スピード加速 ナレッジが更新されるたびにAIの出力精度が向上し、組織全体のアウトプット効率工場
29. 04 レビューと認知負荷 AIが書いた量を、⼈はどう判断するか
30. レビューと認知負荷 AIは書き終わった。⼈間は読み終わらない。 社内ツールのチェックリスト機能だけで 要求仕様書 1ファイル‧約2.6万⽂字 12ファイル‧約31万⽂字 ＝ 400字詰め原稿⽤紙で 約770枚 設計書 10ファイル‧約18.2万⽂字 テスト分析 1ファイル‧約10万⽂字 読む量が多い 要件‧設計‧テストで約31万⽂字 設計書の1ページ（F-1） どこを判断すればいい？ 網羅的な記述から ⾒るべきポイントを探す つながりが追えない UC 1-1 → F-1 → TA-1 を IDで⼿繰って⾏き来する AIが使う詳細は必要。 そのままでは、⼈が判断しづらい。
31. レビューと認知負荷 AI向けと⼈向けのドキュメントを分ける 設計書は省略しない。読む相⼿に合わせて⾒せ⽅を分ける AI AI ⽤：元の設計書をそのまま読む 細かく、網羅的に 項⽬の型‧必須‧桁まで 設計書 (SSoT)   実装   テスト すべてのAPIの⼊⼒と出⼒ AIレビュー 例外‧エラーのすべてのパターン 網羅的に書く 省略しない‧要約しない ⼈ ⼈⽤：理解しやすく、絞ったViewを別に作る 全体像：情報のつながり 判断する場所だけを⾒る freee のルールを加味 ⼀般論ではなく、プロダクト‧ ドメインの決まりごとに沿って  理解 しやすく  絞る  判断点：事実‧理由‧問い レビューView 細かい属性‧標準のAPI → AIに任せる 設計書は削らない。 AIは全部を読み、人は理解しやすく絞った Viewを見る
32. レビューと認知負荷 まず認知科学に沿って読みやすくしたが、それでも読む量は多いまま 表⽰：読みやすくなった 先に全体像を⾒せ、図と説明を近くに置く ID で辿れる つながり：辿れるようになった 各ページに元の箇所と コンテキストになるページへのリンク 読む量：まだ多いまま 31 解説ページ 33 確認の問い 省略せずに整理しているので、量はそのまま
33. レビューと認知負荷 ⾒る場所を絞るためにレビューの観点を取り⼊れる 溜める観点のナレッジ 今回の成果物 共通の観点 設計⽅針‧データモデル‧API I/F‧ 状態遷移‧業務ルール‧要求との対応‧ ⾮機能⾯‧システム間連携 プロダクト特有の観点 ‧ドメインのコア（給与計算など） ‧freee‧プロダクト独⾃の部分 例：給与の反映⽉、確定済み給与の遡及‧ 差額 要件‧設計‧未確定事項⼀覧‧ AIレビューの指摘 掛け合わせて ⼈が判断する箇所を絞り込む 採⽤する ∕ 軽く確認する ∕ 機械に任せる を理由付きで整理 ⼈向けのレビューHTML 全体像 情報の関係と判断する場所 事実 何を作るのか 理由 なぜそう決めたのか 問い ⼈に判断してほしいこと
34. レビューと認知負荷 判断が要るところだけ⾒せる シニアエンジニアにヒアリングして、設計で⾒たい観点を整理した 隠す（判断不要） ⾒たい観点：共通の8つ ＋ プロダクト特有 設計⽅針 データモデル API I/F ⽅針が要件の⼤枠に合っているか ⾮⾃明な判断に、根拠があるか 粒度‧関係性‧Value Object、なぜそうしたか 集約の責務と境界、不変条件をどこで守るか 画⾯起点で、CRUDから外れたところ エラー応答‧認可まで決まっているか 状態遷移 システム間連携 業務ルール 異常ルート‧業務例外ルート 同じデータを触る操作の競合‧順序 外部連携のシーケンスと、どう影響するか 送信‧確定など、戻せなくなる点はどこか 業務ルール‧法令から導いた不変条件 境界値（ゼロ‧上限‧端数）の扱い 要求との対応 ⾮機能⾯ プロダクト特有 すべてのUC‧不変条件が設計に対応しているか 要件にない先回りの設計がないか 権限‧性能‧監査‧信頼性 機能を⽌めたときの流出経路と、切り戻し⼿段 ⼈事労務なら、給与計算まわりを重厚に 例：給与の反映⽉、確定済み給与の遡及‧差額 ‧標準のCRUD ‧既存ルールどおりのAPI ‧コードや既存仕様を 調べれば分かること 人に聞くのは 4つだけ 事業判断 ／ 利用者の挙動 ／ 他チームとの契約・制約 ／ 不可逆なリスク
35. レビューと認知負荷 観点ごとに今回どこまで確認するかを⽰す レビュー観点。採⽤‧軽く確認‧最重要‧機械検証‧低優先を、理由付きで⽰す 共通観点 × ドメイン観点の採否
36. レビューと認知負荷 ⼈が判断する問いまで具体的に⽰す 成果物区分を後から変えても完了した記録はそのままにし、次に記録を直すときだけ新しい区分で確かめる 業務ルール‧様式 HIGH 未確認 出どころ OQ-030 設計した事実 なぜそうしたか ⼈が判断する問い 「完了なら成果物が必要」という確認 は、記録したときにだけ⾏います。区分 を変える前に完了にした記録を遡って確 かめ直すことはしません。 記録済みの実績をマスタの編集で崩さな いため。次に記録を更新するときに直せ ば⾜りる。 区分を「成果物を必ず残す」へ変えた後 も、それ以前の完了が成果物なしのまま 残ることを許容できますか。 全⽂を読み解くところから、この設計でよいかを判断するところへ
37. レビューと認知負荷 観点を溜めるほど「⾒なくていい」が増える ⼈が⾒る量（イメージ） ① 観点をナレッジに溜める 共通の観点 ∕ ドメイン固有の観点 ② AIのレビュー‧テストが 判定できる範囲が広がる 今 ⼈が⾒る ⼈が⾒て気づいた 観点を戻す AIに任せる 観点が溜まると ③ ⼈は残った 判断点だけを⾒る 実例：「成果物どうしの⾷い違い」は機械レビューが12観点で照合済み ↓ ⼈は残った指摘だけを⾒る ⼈が⾒る AIのレビュー‧テストで確認 ＝ ⾒なくていい ⾒る量を減らすのは、読み⾶ばしではなく 「確認済み」を増やすこと
38. 中締め：対談 最初に戻れるなら何から始める？ 理想の開発体験を最初にひとつ通す 評価環境を整えて改善サイクルを回せる状態を作る 理想ドリブンの体験と実現性も両軸から あとは、開発プロセスの再設計を 先にやり切りたかった
39. 05 Software Factory後の エンジニアの役割 AIが実装する時代に、エンジニアは何をするか
40. Software Factory後のエンジニアの役割 AIが実装するならエンジニアは何をする？ Software Factory：複数の案件を並列で進める 案件A 案件B 判断待ち 実装 → テスト 判断待ち 要件 → 設計 → 実装 → テスト 案件C ⼈ 要件 → 設計 → 実装 → テスト 判断 判断 判断待ち 要件 → 設計 → 実装 → テスト 判断待ち 判断 要件 → 設計 → 実装 → テスト 判断待ち 要件 → 設計 → 実装 → テスト 判断 判断 実装 → テスト 判断待ち 判断 ⼈のところには、複数の案件から判断の依頼が次々に届く レビューに追われる… 動作確認だけで、 ⼀⽇が終わる… ⾃分の技術⼒は、 落ちていかないか？
41. Software Factory後のエンジニアの役割 エンジニアは「何を作るか‧どう作るか」に時間を使う Software Factory：複数の案件を並列で進める 案件A 案件B 判断待ち 実装 → テスト 判断待ち 判断 ユーザーと話す 判断 判断待ち 要件 → 設計 → 実装 → テスト 要件 → 設計 → 実装 → テスト 要件 → 設計 → 実装 → テスト 案件C ⼈ 要件 → 設計 → 実装 → テスト 新しい技術を試す 判断待ち 判断 判断待ち 実装 → テスト 要件 → 設計 → 実装 → テスト 観点を溜める 判断 仕組みを改善 判断 判断待ち ユーザーと話す 判断 新しい技術を試す ⼯場が動いている間の時間を、ユーザー‧技術‧品質‧仕組みづくりに使う 何を作るか ユーザーと話し、プロダクト を企画する どう作るか 新しい技術を試し、全体の アーキテクチャを考える 品質をつくる 判断の観点をナレッジに溜 め、AIが確かめる範囲を広げ る 開発者も人にしかできない判断に時間を使う 開発の仕組みを育てる ⼯場の待ち時間や⼈の負担を ⾒つけて、改善する
42. 06 freeeが⽬指す Software Factoryの未来 ⼈の判断を中⼼に、開発環境を育てる
43. freeeが⽬指すSoftware Factoryの未来 Human-in-the-loop / Human-on-the-loop の境界設計 完全自動化の限界 Dark Factoryを目指さない Dark Factory (完全無人化 )の 回避 システムを過度にブラックボックス 化させないための明確な方針を策 定。 • 障害発生時の対応コスト高騰 を防ぐ • 予期せぬ例外処理への柔軟 性を維持 • 業務のブラックボックス化によ るリスクを排除 明かりを灯すポイント 人間の介在箇所の設計 Scrap & Build プロトタイピングの検証 自動化と人の判断の役割分担 手戻りを防ぐ早期検証サイクル 定型業務の効率化と、人間の本 質的な意思決定を明確に分離。 早期に動くプロトタイプを作成し、 前提条件の検証を実施。 • 定型作業 : 完全自動化を推進 しスピード向上 • 早期段階での動くプロトタイプ 構築 • 意思決定 : 人間のレビュー・判 断を必須プロセスとして介在設 計 • コンテキストの不整合があれ ば躊躇なくScrap & Buildを実 施 • 責任の所在とガバナンスの確 保 • 大規模な手戻りリスクの 低減と最適化
44. freeeが⽬指すSoftware Factoryの未来 スプリントの超短周期化と24時間クラウドFactory 超短周期スプリント クラウド開発環境への完全移行 24時間 Software Factory 週単位から「 1日複数回」へ ローカル脱却と共通基盤化 AIによる止まらない自動開発 従来の1〜2週間単位のデプロイ・ 開発サイクルを根本から見直し、1 日に複数回のサイクルを回す超 高速開発へ進化。 個人のローカル端末依存から、ク ラウド上の統一された共通開発環 境へと移行。リアルタイムな状況 可視化を実現。 人間の開発現場がオフラインとな る夜間や休日も、クラウド上のAI エージェントが自律的に稼働・テス ト・構築を進行。 期待される効果 フィードバックループの圧倒的短 縮と、機能提供スピードの爆発的 な向上。 期待される効果 成果物・プロセスの即時共有によ り、サイロ化を防ぎチーム全体の 透明性が向上。 期待される効果 開発リソースの限界を超えた連続 的な価値創出と生産性の極大化。
45. freeeが⽬指すSoftware Factoryの未来 超短周期スプリント 確かめる プロトタイプと 要件‧設計を確認 また確かめる 反映を実物で確認 この周期を もっと短く テスト結果もこの循環の中で テスト結果も確認‧修正に使う。 ⼈の確認だけが品質保証ではない ⼈による フィードバック 両⽅を設計する 実⾏時間 ＋ 集まって判断するタイミング 処理だけ速くなっても、確認の機会が 少なければ学びは増えない 要件または 設計から再実⾏
46. freeeが⽬指すSoftware Factoryの未来 クラウド開発環境への完全移⾏ 1 個⼈の端末に依存しない実⾏環境 ⼈が不在の間も処理を続ける 2 進⾏状況と成果物をチームで共有 必要な⼈が途中から判断に参加しやすい 3 仕組みの改善を各チームへ届ける 改善した仕組みを皆に届けやすくする
47. freeeが⽬指すSoftware Factoryの未来 AIと共創する未来 freeeはお客様のバックオフィスを自動化し、クリエイティブな活動を支えることを目指してきたように、 私たち開発者自身にもクリエイティブな課題や意思決定に集中できる環境を作っていきます。 これまで技術的な壁で後回しにしていたことが、AIの力でようやく実現できるフェーズに入りました。 この新しい開発者体験を、ぜひ皆さんと共にアップデートしていければと思います。