freeeに点在する案件・プロジェクトを統合するための案件マスタ開発

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

Transcript

1. freeeに点在する案件‧プロジェクト を統合するための案件マスタ開発 仲⻄直也 2026年10⽉3⽇
2. 販売⼯数業種開発本部 ⼯数業種開発部 部⻑ 兼 プロダクトマネージャー 仲西直也 (mikan) 2022年4月に22年新卒エンジニアとして入社。 freee販売のengマネージャーとPdMを経て、 現在 は案件マスタ/工数管理/取引先マスタ/ 新規プロ ダクトを担当する部署のengマネージャー/部長と、 案件マスタ/新規プロダクトのPdMを担当。
3. この時間で伝えたいのは、 2つの取り組みでの気づきと工夫 エンジニア マネージャー ＋ プロジェクト マネージャー ＋ プロダクト マネージャー 設計 進⾏ 複数プロダクトを統合し、横断する機能 も⾒据えたマスタをどう設計したか 最⼤4チームが並⾛する、規模の⼤きい 開発をどうマネジメントしたか
4. ⽬次 • 背景編：なぜ案件マスタを作るのか • 設計編：モデルと依存関係をどう決めたか • マネジメント‧進⾏編：4チームでどう進めたか • まとめ
5. 01 背景編 なぜ案件マスタを作るのか
6. freeeには「案件」を持つプロダクトが 3つある freee販売 freee⼯数管理 freee業務委託管理 ⾒積‧受注‧売上を 案件ごとに管理 誰がどのプロジェクトに 何時間使ったかを記録 外注先への発注‧請求を プロジェクトごとに管理
7. ユーザーの頭の中では、案件は 1つ ユーザーの頭の中 freeeの中のデータ 販売の「案件」 案件A 売る‧作る‧外注する ⼯数管理の「プロジェクト」 業務委託管理の「プロジェクト」 販売‧⼯数‧外注は別々の業務。プロダクト固有の項⽬や機能があるのは当然
8. つなぐ機能はあった。でも片側からしかつなげなかった 営業 販売で案件を作る → ⼯数管理の担当者 プロジェクトを作って 連絡する ⼯数管理側からは紐づけられない → 営業 案件を開き直して 紐づける 案件名‧コード‧⽇付は⼆重⼊⼒
9. このままだと、プロダクトが増えるたびに連携開発が必要になる 3プロダクト 3通り → 4プロダクト 6通り → 5プロダクト 10通り 1対1でつなぐと、組み合わせの数だけ連携開発が必要になる
10. 各プロダクトを横断・依存して初めて実現できる機能を作りたい 案件の内容を 各プロダクトに反映する 案件を横断して 検索 各案件のデータを 集めて計算する どれも「案件が1つにまとまっていること」が前提
11. だから全プロダクトが参照する「案件マスタ」を真ん中に置く 案件マスタ 販売 ⼯数管理 業務委託管理 (今後) 今後の プロダクト
12. 02 設計編 モデルと依存関係をどう決めたか
13. 根っこのモデルは、後から変えるのはすごく大変 後から変える時に起きること ユーザーの業務を ⽌めずにデータ移⾏ （デュアルライト） UI/UXの ⾒直し 依存している 他サービスへの波及
14. 今求められているのは 1:1:1。でも将来は 1:Nが求められる 今求められて いるもの ⼯数管理 販売 案件マスタ 業務委託管理 束ねる層 A⼯程 将来 求められる もの 販売 ⼯数管理 業務委託管理 案件マスタ 束ねる層 B⼯程 ⼯数管理 業務委託管理 考えられるが選ばなかった案：1:Nをそのまま提供する ∕ 1:1でモデルも作る
15. 裏側の設計は 1:Nで持ち、ユーザーに提供する体験は 1:1:1にした ユーザーに 提供する体験 （1:1:1） ⼯数管理 販売 案件マスタ 業務委託管理（今後） 束ねる層 A⼯程 裏側の設計 （1:N） 販売 ⼯数管理 業務委託管理 案件マスタ 束ねる層 B⼯程 エンジニアとプロダクトマネージャーの両⽅をやっているので こういう業務の背景や開発⼯数観点を理解した上でモデルを考えやすい ⼯数管理 業務委託管理
16. 「マスタ」なのに、他プロダクトを横断・依存する機能も持ちたい マスタ群 取引先‧従業員‧商品 … 会計‧⼈事労務 販売‧⼯数管理‧業務委託管理など 依存の向き 案件マスタは 上段に置きたい。 でも下段の情報が必要
17. 1つのアプリの中を、 2つのモジュールに分けた 案件マスタ マスタのモジュール 他プロダクトに依存しない ↑ ⽮印は依存の向き ← プロダクトのモジュール 販売や⼯数管理に依存してよい ↓ 販売‧⼯数管理 など
18. 03 マネジメント‧進⾏編 4チームでどう進めたか
19. 開発は新規プロダクト 1つではなく、既存 2プロダクトの大改修も必要 案件マスタ freee販売 freee⼯数管理 新規開発 ⼤きな改修 ⼤きな改修 案件やプロジェクトには常に案件マスタが存在する設計 販売‧⼯数管理から登録した時に、マスタも⾃動で登録する仕組み
20. 最大4チームが、 1つのものを並走して作った 9月 10月 11月 12月 1月 2月 3月 4月 5月 6月 全チーム並⾛ 案件マスタチーム（Eng 3）仕様‧アーキテクチャ‧連携⽅針‧基盤 ⼯数管理チーム（Eng 4） 販売チーム（Eng 5） 追加チーム Eng 5 合計の関係者：Eng 約18 ∕ PdM 2 ∕ QA 7 ∕ デザイナー 3 7月
21. 合流の前に「なぜ作るのか」を普段より丁寧に説明しビジョンを示す 今の体験と 課題 なぜこれを 作ると 決めたか ユーザーの 体験が どう変わるか 概念モデルが どう変わるか 仕様の イメージ
22. 失敗：軌道に乗ったと思って離れたら、 2週間くらい混乱させた ビジョンを⽰す 各チーム間で 分かりにくく なったこと 軌道に乗った ように⾒える 離れる • 今、何が決まっていないのか • 何を優先したらいいのか • 他のチームが何を進めているのか 混乱
23. 4チームが並走する規模では、全体を見る独立した役割が必要になる この見極めが大事 1チーム チームリードが 全体も⾒る 2チーム ⽚⽅のチームリードが 全体も兼ねる。 それでも回る 4チーム 全体を⾒る仕事だけで1⼈分 PjMとして独⽴させる
24. 基礎的なことを疎かにせず徹底するのも大事 要件のレビュープロセスを明確にする 論点を⼀元管理し、 要件に反映したかまで追う 各チームの状況を⾒つつ、 依存してる内容もあるので⽇付を調整し、 他チームへ連携する 論点リスト：論点‧過程‧結論‧担当‧ 期限‧ステータスを1か所で管理
25. 報告は見る人のレイヤーに合わせて粒度を変える チームと⾒る粒度 27アイテムのタイムライン 上のレイヤーに報告する粒度 3〜4マイルストーン‧4段階‧5⾏サマリ → 画像は⼀部。実際はこの4〜5倍
26. 影響が大きいリリースだからこそ、一度に出さず、段階に分けて出した なぜ分けたか ⼀度に出すと原因を切り分けづらく、 リスクが⼤きい ユーザーに事前準備の時間が要る 分け⽅ 独⽴して 出せる変更を 先に 権限‧招待を 先⾏リリース 既存データ移⾏ （デュアル ライト） 7⽉ リリース 販売‧⼯数を 同時に切替
27. つらかったのは、普段のやり方のまま要件定義して読みづらい量になったこと 当時 スプレッドシートに1⾏ずつ。 読めない⾏数に 今 AIで動くモックを作り、 触りながら認識を合わせる
28. PdM・EMを兼ね、設計経験もあったから PjMとしてその場で意思決定しやすい PdMとして EMとして 設計経験から 仕様の判断を、 進捗と⼯数を⾒ながら 下せる 遅延や考慮漏れが ⽣まれそうな時点で 調整に回れる モデリングを ⾃分で先回りして 整理できる だから、PjMとして全体を進めやすかった
29. まとめ モデルは 将来を想定して 考える 裏側は1:N、体験は1:1:1 依存の向きは モジュールで守る 全体だけを⾒る⼈を 専任で置く⾒極め ⽅針を⽰した後も 離れすぎない 規模が変わったら 普段のやり⽅を ⾒直す 報告の粒度、 要件定義の⽅法