freeeにおけるファンクションを超えた一気通貫でのAI活用

freee 技術の日 2025 での講演内容です
https://freee-tech-day.freee.co.jp/2025/

Transcript

1. freeeにおけるファンクションを超えた ⼀気通貫でのAI活⽤ Futoshi Iwashita (jaxx) 2025年11⽉30⽇
2. Futoshi Iwashita
 (jaxx)
 2020年ジョイン。freee会計や freee請求書の債権ドメイン開発
 #Front-End Developer #自作 キーボード
 債権請求書開発部 部⻑ 兼 プロダクトマネージャー
3. 今年の課題
4. 登壇内容どう考えても AIになっちゃう問題
5. 　 話したいこと • AI活⽤における freee の強み • なぜ「⼀気通貫のAI活⽤」を⽬指すのか • 技術⾯、運⽤⾯でどのようなアプローチをとっているか
6. 　 AI活⽤における freee の強み • AI活⽤以前からのファンクションの⼀体感 ◦ 個⼈的にユーザーインタビューにPdM, ApD, Eng, QAが同 席できるのが印象的だった話
7. 　 AI活⽤における freee の強み • 開発プロセスの多様性 × ムーブメント型組織 ◦ 分散するアクション ◦ 集結するアクション
8. 　 Kent Beck の講演内容が良かった • 測定せよ、ただしレバーとして使うな • 終端で測定せよ • プレッシャーではなく、気づきを促せ • ⼤局に⽴て
9. 　 なぜfreeeは「⼀気通貫のAI活⽤」を⽬指すのか 開発生産性について議論する前に知っておきたいこと #開発生産性 - Qiita
10. レベル1生産性を改善した話 レベル2生産性を改善している話
11. 生産性レベル 1の取り組み
12. どういう方針で進めたか
13. 　 どういう⽅針で進めたか • 各ファンクションがインパクトにこだわって取り組めるように、⽀ 配率 × 圧縮率の⾼い業務の洗い出し 犬の道 | イシューからはじめよう
14. 　 どういう⽅針で進めたか オーナー 支配率, 圧縮率の高 い業務の洗い出し 支配率, 圧縮率の高 い業務の改善 生産性（レベル 1）の 成果 生産性（レベル 2）の 成果 生産性（レベル 3）の 成果 PdM/ApD DONE DOING TODO PdM/ApD/Eng/QA に よって達成される 事業部全体で達成さ れる Eng DONE DONE DOING PdM/ApD/Eng/QA に よって達成される 事業部全体で達成さ れる QA DONE DOING DOING PdM/ApD/Eng/QA に よって達成される 事業部全体で達成さ れる AIエージェントによる効果が明確に出 ていたEngを起点に着手
15. 支配率、圧縮率の高い業務の洗い出し
16. 　 業務タスクを細分化 • ⼈によって⾒積りのブレが⽣じないように限りなくタスクを細分化 • 難易度ベースかつプランニングポーカーでウェイトを算出 開発タスク feature flag 追加 APIスキーマ定義 DBマイグレーション ビジネスロジックの実装 API疎通 UIの実装 APIリクエスト インタラクション 開発タスク ウェイトの合計 feature flag 追加 1 APIスキーマ定義 エンドポイント定義（ route, Controller, sekisyo 定義） DBマイグレーション定義 DBマイグレーション実行時間測定 DBマイグレーション実行（メンテ or pt-osc） ビジネスロジックの実装（モデル実装） 5 ビジネスロジックの実装（ユースケース実装） 8 ビジネスロジックの実装（ Serializer実装 + Request Spec） 5 Jobの実装 Task の実装（or batch） cron の設定 インフラの見直し（job queue の見直し） パフォーマンス検証（速度、メモリ使用量） UIの実装（route の追加） UIの実装（デザインシステムを用いた実装） 8 UIの実装（表示要件（権限制御）） 5 APIリクエスト（API GETリクエスト） APIリクエスト（API POSTリクエスト）
17. 　 業務タスクで⽀配率の⾼いものを洗い出し • 妥当性を評価するためプロンプト化 • 実際のDesignDocを複数渡してみて⽀配率を出してみた
18. 　 この時点でわかったこと 元々の仮説： • プロダクトやプロジェクトによって⽀配的なタスクは違うの では？
19. 　 この時点でわかったこと 結果： • プロダクトやプロジェクトごとの⽀配率はあまり違いがない • 実装タスクにおいてはビジネスロジック、次いでUIが⽀配的
20. 　 ビジネスロジックが⽀配的なので • ビジネスロジックを効率化する • ビジネスロジック以外を限りなく0にする
21. 支配率、圧縮率の高い業務の改善
22. 　 業務タスクを Custom Slash Command で定型化 開発タスク feature flag 追加 APIスキーマ定義 エンドポイント定義（ route, Controller, sekisyo 定義） DBマイグレーション定義 DBマイグレーション実行時間測定 DBマイグレーション実行（メンテ or pt-osc） ビジネスロジックの実装（モデル実装） ビジネスロジックの実装（ユースケース実装） ビジネスロジックの実装（ Serializer実装 + Request Spec） Jobの実装 Task の実装（or batch） cron の設定 インフラの見直し（job queue の見直し） パフォーマンス検証（速度、メモリ使用量） UIの実装（route の追加） UIの実装（デザインシステムを用いた実装） UIの実装（表示要件（権限制御）） APIリクエスト（API GETリクエスト） APIリクエスト（API POSTリクエスト） APIリクエスト（API PUTリクエスト） APIリクエスト（API DELETEリクエスト） 細かいインタラクションの実装 エラーハンドリング フロントバリデーションの実装 E2Eテスト追加
23. 　 開発合宿を開催してみんなで作る
24. 　 実際の使い⽅ APIの仕様 Slash Command
25. 　 内容はこんな感じ
26. AIエージェントの課題
27. 遅い!
28. コンテキストが逼迫 !
29. 工夫ポイント
30. 　 • コード⽣成の⼤部分はスキーマ駆動開発の Generator に書くことで Custom Slash Command ⾃体はかなり短い記述になるように設計 ⼯夫ポイント OpenAPI Orval Open API Generator プログラミング⾔語に置き換えて⾃然⾔語の利⽤範囲を絞る
31. 　 • TypeSpec, Open API, Orval を⽤いたスキーマ駆動開発の話はエント リーになっているのでこちらをご覧ください ⼯夫ポイント OpenAPI ではなく TypeSpec を読み書きするスキーマ駆動開発 - freee Developers Hub
32. 　 詳しくは Introducing Claude Opus 4.5 \ Anthropic ただし⾃然⾔語の利⽤範囲を絞ることによるアドバンテージは⼤きい (追記) Opus4.5で⼀定改善している部分もある
33. 　 実装が定型化ことで DesignDoc の記述量も削減 主要論点にレビュイー/レビュアーが集中できるように 実装が定型化することで前⼯程に恩恵も
34. 　 まとめるとこんな感じ
35. 　 全員が取り組む時にサンクコストを気にしなくて 良いように再現性のあるものを3段階で評価 プラクティス集を作って事例紹介
36. 生産性レベル 2の取り組み
37. このアプローチの強み
38. 　 業務タスクの細分化/定型化は他ファンクション に対しても適⽤可能 開発タスク リスク洗い出し（調査、リスク洗い出し） リスク洗い出し（リスク洗い出し会実施） テスト計画（調査、計画） テスト計画（テスト計画共有会） テスト分析（調査、テスト分析） テスト分析（テスト分析共有会） テスト設計（テスト設計） テスト設計（テスト管理ツールへの登録） テスト準備（テスト環境準備・ツール準備） テスト準備（ダッシュボード作成） テスト準備（テストデータ作成） テスト実施（画面入力） テスト実施（画面表示） テスト実施（出力） テスト実施（計算） テスト実施（データ検索、集計） テスト実施（データ登録、更新） （省略） 開発タスク Brief作成(プロダクトFB) Brief作成(ビジネス課題設定) Brief作成(ターゲット設定) Brief作成(ユーザー課題仮説設定) Brief作成(定量クエリ集計) Brief作成(競合機能・仕様調査) Brief作成(既存機能・仕様調査) Brief作成(競合機能・評判調査) Brief作成(競合資料集め) Brief作成(調査設計) Brief作成(プロトタイプ作成：スクリプト設計) Brief作成(プロトタイプ作成：タスク設計) Brief作成(プロトタイプ作成：プロトタイプ) Brief作成(プロダクトFB) Brief作成(ビジネス課題設定) Brief作成(ターゲット設定) Brief作成(ユーザー課題仮説設定) （省略） QA PdM 開発タスク 情報設計(競合UI調査・分析) 情報設計(現行UI調査・分析) 情報設計（業務フロー・ユーザーシナリオ） 情報設計（システムの概念整理・抽象化） 情報設計（インタラクションシナリオ） 情報設計（要求・要件に対する論点だし） 情報設計(画面遷移図) 情報設計(ゾーニング) 情報設計(レイアウト検討) 画面設計(コンポーネント利用方針、調査・検討) 画面設計(Figma 作成：正常系) 画面設計(Figma 作成：Blank state) 画面設計(Figma 作成：Loading state) 画面設計(Figma 作成：Error state) 画面設計(Figma 作成：理想状態) 画面設計(Figma 作成：最大値) 画面設計(Figma 作成：レスポンシブ、モバイル、タブレット) （省略） ApD
39. 　 ChatGPT, Claude, Gemini は⽐較検討中 業務タスクの細分化/定型化は他ファンクション に対しても適⽤可能
40. ファンクションを超えて 取り組む上で大事なこと
41. ソフトウェア開発がこのまま簡単になっていけば、いずれはプログラミングの作業は まったく不要になる、という見方はずっと以前からあり、現在もなくなっていません。こ の見方は、プログラミングをよく知っている人間から見ると、「あまりに無邪気」としか 言いようがないものです。しかし、ついこういう見方をしてしまうのが人間である、とい うことも同時に言えます。そしてプログラマもやはり人間なので、同じようなことをする 時はあるのです。 Alan Griffiths 「魔法」に頼りすぎてはいけない | プログラマが知るべき 97のこと
42. 相手の業務内容を理解して 課題を紐解いていくの大事
43. 　 途中経過とのしての⽣産性 • レベル1⽣産性（仕事量の⽣産性）としてPR数は1.4〜1.5倍で推移 • 業務を細分化/定型化することにより全員の活⽤を後押しできてい る、ジョイン後の⽴ち上がり速度も顕著に改善
44. 　 途中経過とのしての⽣産性 といろいろ書きましたたが⼀番良かったことは 「何を作るかだけじゃなく、どうやって作るか」 を認識を揃えて複数⼈開発ができるのは楽しい!
45. 　 途中経過とのしての⽣産性 • AI活⽤×開発⽣産性を語る上でPR数が世の中的にも語られる⼀⽅で グッドハートの法則のような問題点もあった • PRよりも Slash Command や Prompt の分類による⼿元の業務として の活⽤度や成果を定量的に計測できるようになった
46. 　 Kent Beck の講演内容を振り返る 測定せよ、ただしレバーとして使うな: AI活⽤がどういった業務（機能開発、バグ修正、改善）に寄与 するを分析
47. 　 Kent Beck の講演内容を振り返る プレッシャーではなく、気づきを促せ: プロジェクト振り返りのテンプレートにAI活⽤の観点を記載す ることで、あくまでチームが⾃ら改善点に気づけるように
48. 　 いまチャレンジしていること • 実装部分を細分化/定型化できたので ◦ レビューやテストについても定型化できる可能性が⾼い ◦ Design Doc を書いたあと⼀部タスクは半⾃動化みたいなこと も可能となるかも
49. 以上です ありがとうございました！