マジ価値を早く届ける意思決定のススメ 〜情報をそろえ、決めすぎを避ける〜/ A Decision-Making Approach for Delivering Better Products Faster

freee技術の日2025(https://freee-tech-day.freee.co.jp/2025/) での発表資料です。

資料内部リンク
* p19 "Disagree & Commit"について、[リーダーシップ・プリンシプル](https://www.aboutamazon.jp/about-us/leadership-principles)

* p22 [深いドメインと統合型経営プラットフォームを支えるモジュラモノリスの事例](https://speakerdeck.com/ogugu9/modular-monolith-that-support-deep-domains-and-integrated-management-platform?slide=12)

* p28 [freee支出管理開発本部の説明資料](https://speakerdeck.com/freee/company-presentation-materials-for-fleet-engineers-in-expenditure-management?slide=16)

* p31
* [freeeの中途エンジニアのポジション一覧](https://hire.wantedly.com/careers/freee/career_page_all_jobs?lang=ja&includeCasualVisits=false&jobFunctionId=116&locationId=80&experienceLevel=MID_CAREER&contractType=REGULAR_EMPLOYEE)
* [「支出管理」のポジション ](https://hire.wantedly.com/careers/freee/career_page_all_jobs/1500?lang=ja)

Transcript

1. マジ価値を早く届ける意思決定のススメ 〜情報をそろえ、決めすぎを避ける〜 mattsun / 松⽊久幸 2025年11⽉30⽇
2. 　 こんなことありませんか？ プロダクト開発を、カレー作りに例えてみます エンジニア）カレーにいれるスパイスを決めたいです！どちらにしますか？ • A：コリアンダー‧チリペッパー • B：クローブ‧シナモン PdM）え？（それを聞かれても何も決められないよ‧‧） 完成したカレーの味にどういう違いがでるの？ そのレシピは完成までにかかる時間の違いがあるの？
3. 　 この発表で得られること マジ価値を早く届けるための、 要件や作り⽅の意思決定⼒を⾼める具体的アプローチ • マジ価値 = ユーザーにとって本当に意味のあるもの • 早く届ける = 早く作る x 「シンプルに作る」 • 具体的アプローチ ◦ 1) 必要な観点‧情報をテーブルに並べる⽅法 ◦ 2) 意思決定を遅らせる⽅法 - 意図的に決めすぎず、少ないコストで検証する
4. 　 この発表に関⼼をもって欲しい⽅ • プロダクトの価値とデリバリー速度を両⽴させたい⼈ • 情報不⾜や前提ズレで判断が難しかった経験がある⼈ • 複数ロール間で共通の判断材料が揃わず、意思決定が難しかったことがある⼈ • 不確実な領域で意図的に意思決定を遅らせ、柔軟に対応できるようになりたい⼈
5. mattsun / 松木久幸
 freeeには、2022年入社。
 新卒でNTTコミュニケーションズ入社。ECサイト開 発、新規事業開発などに従事。
 2017年にシリコンバレーでEngineerとしてイン ターン。「良いチームの大切さ」を実感し、EMを志 す。
 プレイングマネージャーを経て現在は複数チーム のマネジメントを担う。
 ⽀出管理開発本部 部⻑ エンジニアリングマネージャー
6. 01 必要な観点‧情報をテーブル に並べる⽅法 マジ価値を早く届ける 意思決定のススメ 〜情報をそろえ、決めすぎ を避ける〜
7. 　 前提：チーム（複数）もプロダクトも⽴ち上げ期 「どんな機能をつくるか」に焦点があたっており、背景を理解していないがゆえに、異 なるロール間の認識合わせに時間がかかるし考慮漏れが起きやすい状況に⾒えた PdM）プロダクト⽴ち上げにあたり、これを作りたい！ • 作りたい機能⼀覧のドキュメント：開発A, 開発B, ‧‧‧   エンジニア） • AとBってどう関連する？ • Aと似た機能が、すでに別プロダクトにあるけど差分がありそう、 どう作れば良い？ 起きていたこと
8. 　 前提：意思決定のための情報とは？ 市場‧戦略 どんなユーザー‧領域か 業務要求 ニーズ‧要望 機能要件 提供する機能 設計 どう作るか
9. 　 PMMが詳しい領域 =Product Marketing Manager 前提：ロールによって詳しい領域が異なる エンジニアが 詳しい領域 PdMが詳しい領域 =ProductManager 市場‧戦略 どんなユーザー‧領域か 業務要求 ニーズ‧要望 機能要件 提供する機能 設計 どう作るか
10. 　 起きていたこと • 機能要件はPdMが決めるもの、正しい業務要求を PdMが知っているものという思い込み • 設計〜機能要件のみに焦点があり、その前提とな る情報が不⾜していた 再掲：起きていたこと 市場‧戦略 どんなユーザー‧領域か 業務要求 ニーズ‧要望 機能要件 提供する機能 設計 どう作るか
11. 　 やったこと1）前提情報をあわせる a)インセプションデッキで、なぜやるかを合わせた b)ロール横断で、モデリングをすることで、業務要 求の理解度をあげ考慮漏れを早期に減らす 市場‧戦略 どんなユーザー‧領域か 業務要求 ニーズ‧要望 機能要件 提供する機能 設計 どう作るか
12. 　 1-a）インセプションデッキ なぜやるか（市場や戦略）を改めて⾔語化して、前提知識をあわせた → 「似たような既存プロダクトと同じ物をつくる」のではなく、  この市場や戦略に基づきどんなプロダクトをつくるのかという背景 を踏まえたうえでの議論ができるようになった
13. 　 1-b）モデリング 業務要求を整理して、ロール横断でブラッシュアップ → 前提となる理解度をあげる  考慮漏れを早期に減らす 参考： カレーの例の モデリング
14. 　 例）カレーにいれるスパイス  A：コリアンダー‧チリペッパー  B：クローブ‧シナモン  ユーザーの要求   A：⾷欲をそそる   B：満腹感を満たす やったこと2）「良いプロダクト」から考える 「要求」を表す⾔葉から議論する 市場‧戦略 どんなユーザー‧領域か 業務要求 ニーズ‧要望 機能要件 提供する機能 設計 どう作るか
15. 　 補⾜）満たす「ニーズ」によってスパイスが変わる ニーズ スパイス名 役割 特徴と効果 A食欲を そそる =さっぱりと辛 さ強め コリアンダー さっぱり感・爽 やかな香り 柑橘系のような爽やかな香りと、まろやかな甘み を持つ。さっぱり感を出すのに重要。 チリペッパー 強い辛さ 赤唐辛子の粉末。量によって辛さを強力に調整 できます。 B満腹感 =甘めな濃厚 ビーフ クローブ 濃厚な甘い香り ・コク 非常に強く甘く刺激的な香り。肉の臭みを消し、濃 厚なコクと風味を深める。 シナモン 甘く深い香り 独特の甘い香りで、欧風カレーの深い風味や甘さ を強調する。
16. 　 やったこと3）重要な情報もテーブルに載せる 例） • 制約：今後の拡張性etc • ⼯数‧難易度 エンジニア以外のロールは知ることが困難 だが、意思決定に重要な情報を提供する 市場‧戦略 どんなユーザー‧領域か 業務要求 ニーズ‧要望 機能要件 提供する機能 設計 どう作るか
17. 　 実践した結果（1/2） • Before ◦ 何を作るかが話題の中⼼ ◦ 要求‧要件を考えるのはPdMだけ • After ◦ 要求‧要件から確認する会話が増えている ◦ 複数の⽬線で、良いプロダクトを早く届ける⼿段を考えられている 例） ‧この機能はこういう課題のために使われるのですよね？そうなら〜 ‧このユーザー課題に対してこの要件だと複雑でわかりにくいから、  別の要件にしたらどうだろうか？
18. 　 話題の中⼼の変化 Before  エンジニア PdM Product Manager 市場‧戦略 どんなユーザー‧領域か 業務要求 ニーズ‧要望 機能要件 提供する機能 設計 どう作るか After  エンジニア PdM Product Manager PMM Product Marketing Manager 話題の 中心 話題の 中心
19. 　 実践した結果（2/2） やっていて難しいと思うこと‧分かってきたこと • 100%認識齟齬をなくせるわけではない ◦ →⼤きな認識齟齬をなくす、早期に気づけるようにしている • モデリングに議論が紛糾する ◦ →時間を区切る、情報を集めたうえで再度考える • 誤解：何でもかんでも会話すればよいわけではない ◦ →前提を合わせて意思決定をスムーズにしていくこと ◦ →みんなで考えるが最後はオーナーが決定、Disagree & Commit※ ※ リーダーシップ‧プリンシプル - About Amazon Japan
20. 02 意思決定を遅らせる⽅法 意図的に決めすぎず、少ないコストで 検証する マジ価値を早く届ける 意思決定のススメ 〜情報をそろえ、決めすぎ を避ける〜
21. 　 起きていたこと • １）プロダクト⽴ち上げ期で不確実性が⾼く、プロダクトの⽅向が変わる可能性も ⼤きいといった状況下での、システムアーキテクチャ設計 • ２）初期にすべての「どう作るか」を定めるのが難しく、複数チームの開発の依存 度合いを減らしたかった
22. 　 やったこと１）変更可能性が⾼い場合には「変更しやすく保つ」 • １）プロダクト⽴ち上げ期で不確実性が⾼く、プロダクトの⽅向が変わる可能性も ⼤きいといった状況下 ◦ ドメインを過剰に分断し、多数のマイクロサービスでシステムを構築する⽅針 • 検索要件 & データ整合性を保つなど、分割していると逆に複雑性があがり拡張が難 しそうなことも⾒えていた • マイクロサービスを2つに減らして可逆性を⾼めた 参考：深いドメインと統合型経営プラットフォー ムを支えるモジュラモノリスの事例
23. 　 • ２）初期にすべての「設計=どう作るか」を定めるのが難しく、複数チームの開発の 依存度合いを減らしたかった ◦ 開発A: ⼀つのドメインを切り出すかどうかを決定し開発する ◦ 開発B: ⼀部の機能要件のために、Aで完成したドメインを参照する ◦ 開発C: 同上 やったこと２）コアな要件以外の意思決定を遅らせる 開発A 開発B 開発C
24. 　 • ２）初期にすべての「設計=どう作るか」を定めるのが難しく、複数チームの開発の 依存度合いを減らしたかった • BやCの開発において、Aを参照する要件はコアなものではなく副次的なものだった • そのためスコープアウトした開発(B,C-core)を先⾏して、Aが終わった後に追加開発し た(B,C-sub) • => リードタイムの削減、チーム横断での認知負荷の削減 やったこと２）コアな要件以外の意思決定を遅らせる 開発A B-core C-core B-sub C-sub
25. 　 実践した結果 • 意思決定のタイミングを考える時には、その情報のレベルを考えていた • １）変更しやすく保つ ◦ => 業務要求レベルで⾒通せていない状況 ◦ あとから捨てやすいくらいシンプルにつくる / 可逆性を⾼めることが重要 • ２）コアな要件以外の意思決定を遅らせる ◦ =>副次的な要件‧設計レベルでの意思決定 ◦ つくりながら、リリースする前までに決定を伸ばしてもそれによるリスクは 少ない
26. 03 まとめ  +告知 マジ価値を早く届ける 意思決定のススメ 〜情報をそろえ、決めすぎ を避ける〜
27. 　 まとめ • プロダクト開発する上で扱うべき情報には、レイヤーがある ◦ 市場‧戦略 / 業務要求 / 機能要件 / 設計 • 良いプロダクトや早く届ける⽅法を突き詰めるために、情報をテーブルに並べよう ◦ 「市場‧戦略 / 業務要求」といった前提をエンジニアも理解する ◦ 「設計」から⽣じる⼯数‧将来の制約といった意思決定に必要な情報をPdMも理解す る、など • これらの情報がわかることにより、 ◦ エンジニアも「業務要求 / 機能要件」に基づき、どんなプロダクトを作るか考えられる ◦ 決め過ぎない⽅が良いこと、いつまでに決めれば良いかもクリアになっていく
28. 　 freee⽀出管理 ⽀出管理本部 説明資料より抜粋
29. 　 freee⽀出管理 ⽀出管理本部 説明資料より抜粋
30. 　 freee⽀出管理 ⽀出管理本部 説明資料より抜粋
31. 　 We are hiring!! 中途エンジニアのポジション一覧 「支出管理」のポジション