大規模開発組織で「未完」の基盤を育てるために、 完璧ではないEMがいかにして価値を作るか

talk in https://tenshoku-draft.connpass.com/event/361976/

1. 　 大規模開発組織で「未完」の基盤を育てるために、 完璧ではないEMがいかにして価値を作るか 2025.08.07
2. 　 2 経歴 • 2016~2019: SIer ◦ SEとして様々な開発に遊軍的に携わる • 2019/11~: freee ◦ 前: ⼈事労務, ⼯数管理, 販売 ▪ 新規プロダクト多め ◦ 現: プロダクトを跨いで利⽤される共 通機能群を開発する部署を取りまとめ るEM(約20名規模) 趣味 • スポーツ(する/みる) ◦ 野球(阪神), バスケ(京都), F1, ランニン グ, 筋トレ, ボルダリング, ヨガ, etc • 飼い猫 • 散財 tomoz(ともじー) Engineering Manager Keita Tomozawa プロフィール画像の トリミング⽅法
3. 　 freeeのプロダクトビジョン
4. スモールビジネスを、 世界の主役に。
5. 5 統合型経営プラットフォームを提供 バックオフィスの全体最適化を図る設計思想 経理 人事マスタ | 入退社手続 | 雇用契約 | マイナンバー | 勤怠申請 | 勤怠管理 | 給与計算・明細 | 社会保険 | 年末調整 人事 労務 販売 管理 法務 ‧ 情シス 税務申告 （法人税 | 償却資産税） 契約申請 | 文書作成 | 電子契約締結 | 文書管理 工数入力 | 工数申請 | 案件別人件費管理 勤怠申請 | 勤怠管理 財務会計 | 管理会計 | 固定資産 受取請求書 | 債務管理 | 振込 経費精算 | 請求書発行 | 債権管理 購買申請 | 受取請求書 | 債務管理 | 振込 | 経費精算 | 請求書発行 | 債権管理 | 法人カード SaaSアカウント管理 （発行 | 削除 | 棚卸 | 更新） 備品管理 購買申請 | 受取請求書 | 債務管理 | 振込 | 経費精算 | 法人カード 販売管理 | 受発注管理 | 案件収支管理 | 帳票発行 契約管理 | パートナー管理 | 発注管理 | 進捗管理 | 帳票発行 | 支払管理 請求書受取・スキャン代行 | 原本・データ保管 | 仕訳入力代行 | 支払管理 | 健康診断管理 | ストレスチェック | 労基署への報告書作成・電子申請 | ストレスチェックの集団分析 給与・賞与計算 | 入退社手続 | 身上変更 | 年末調整 | 年次イベント | 従業員対応
6. 6 ヒトと事業を一気通貫。データで鍛え、数字で伸ばす。 統合データと適切な可視化 が経営と組織を成長させる 経営の可視化 業務とデータの 統合 統合
 flow
 Communi-
 cation flow
 Work flow
 Data flow
 I T 財務 会計 販売 購買 経理 給与 労務 評価 法務 総務 人事 事業別 P / L・部門別 P / L リアルタイムな 可視化 案件損益・P J 一覧 購買・発注情報 はたらく人の可視化 人事レポート 残業・労務レポート 評価・スキルレポート freee TOGO World 2025 より
7. 　 大規模組織における基盤組織 の成り立ちとその難しさ
8. 8 • ERPの領域に複数のプロダクトを作っていく中で、必然的に似通った機能を作 るシチュエーションが出てくる ◦ 認証認可・権限・課金・通知・マスタ・UI… • 車輪の再発明を防ぐべく、共通機能を基盤として切り出して作ってきた • 特にfreeeでは「統合」を掲げており、あらゆるプロダクトを跨いで一貫した ユーザー体験を作りたいので、余計に基盤の重要度が高い 基盤組織の成り立ち … プロダクト プロダクト プロダクト プロダクト 基盤 プロダクト プロダクト …
9. 9 基盤作って万事解決や！ Slackに通知を 送りたいです！ 基盤を作るから みんな使って〜
10. 10 基盤作って万事解決や！...とはならない 本人宛にDMで通知をしたくて... XXの内容によってYYとZZの チャンネルに送り分けたくて... 本人だけじゃなくて複数人にまと めて送りたくて... そこまで全部は把握しきれない...
11. 11 • 一口に「共通機能」といってもプロダクトが使いたい機能の有り様は千差万別 • プロダクトも増えていく中、あらかじめあらゆるニーズを満たすことは難しい ◦ “プロダクト” を “ユーザー” と置き換えれば、プロダクト開発でも一緒ですよね • 「作って終わり」にせず、常にプロダクトのニーズを拾い続けて（それでいて 個別最適にはせず）基盤の機能のみならず責務のあり方も含めてアップデート をし続けなければならない 基盤は常に「未完」、だから難しい
12. 12 「基盤」と一言で言うけれど 基盤全体 よっしゃ基盤 つくるで〜〜
13. 13 「基盤」と一言で言うけれど、実態は... 認証・認可 課金 通知 マスタ 権限 UI 申請承認 うわっ、 私の管掌範囲 広すぎ…？
14. 14 • プロダクトはそれぞれのプロダクトでチームとして大きくなっていくが、基盤 の個々のチームはそれに比するとスケールするスピードが緩やかで、組織的に も基盤として集約されることが多い（と思う） • 基盤に集約されるチームは「基盤」であることが一番の共通点で、隣をみると 専門性が全く異なるチームが連なっている 基盤は多様、だから難しい
15. 　 完璧ではないEMのジレンマ
16. 16 • こうした性質の組織をリードすると考えたとき、愚直に考えれば「広さ」も 「深さ」もどっちも必要に思える ◦ だからこそ面白い、やりがいがあるのも事実 • それゆえ、一つの基盤のリーダーから複数のリーダーとなるには大きなギャッ プが立ち塞がる • 人はそう簡単にはスーパーマンにはなれない。「広さ」と「深さ」の間の板挟 みをどう乗り越えていくか 完璧ではないEMのジレンマ
17. 17 • 広い領域にそのまま薄く広く関与してしまい、結局どこの領域でも大きな変化 を作れない • メンバーとの1on1も、業務のつながりが薄いためキャリア相談マン的な立ち回 りの域を超えない • 何か問題が起こった時にも、やることの手札もないためズルズルいってしまう 実際ハマった落とし穴
18. 　 広い領域をリードするための原則① 『組織を孤立させない』
19. 19 • 基本的にステークホルダーは少ない方がものごとが進めやすい。なので、成り 行きに任せるとチームはできるだけ小さくまとまろうとする力学が働きやす い。 • 広い範囲を担当するリーダーだからこそ、その力学に対して歯止めをかけられ る存在になり得る • そうした役割として意識していることを2つ紹介 原則①『組織を孤立させない』
20. 20 • 基盤チームは、その専門性ゆえに成り行きに任せるとサイロ化する力学が働く • 一方、基盤はステークホルダーが多さゆえ状況の変化が多い ◦ 例えば何か新しい基盤が必要になったり、プロダクトの状況に応じて優先度が変わるなど • チームを構成するメンバーのマインドが柔軟であればその分状況の変化にも対 応できるので、横のつながりを作るための機会を作っておく ◦ 実際にやってること: 障害の振り返りを一緒にやる、雑に成果を讃えあう場をつくるなど • また、組織の変化と個人のキャリア観が合うかも重要 ◦ メンバーとの接点を一定保ち続け、チャレンジアサインの選択肢を手札に持っておく 組織横断での横のつながりをつくる・たもつ
21. 21 • 良い基盤を作るには、必要なものをタイムリーにデリバリーしていけるかが肝 • 各基盤チームは、その基盤を育てていく上でもちろんプロダクトの意見も聞く 必要がある • リーダーとして、そうしたステークホルダーに当たるような人の意見をチーム に届けられる環境を用意する ◦ 基盤は全ての要望を受け入れられる訳ではないという点において、必ずしも楽なコミュニケーションばかりでもな い。時には関係値を築き維持するためにwetな方法もとる。 ステークホルダーとの距離を縮める
22. 　 広い領域をリードするための原則② 『目標第一』
23. 23 • 自分にとって明るくない領域を担当しようと思う場合、すでにそこに取り組ん できたメンバーへの遠慮もあって、ついついディティールからは一歩引いた振 る舞いをしてしまいがち • そのスタンスではどうしても（悪い意味で）「マネジメントの人」という距離 感を超えられない • 直接現場に関わらないとしても、各領域が成すべき目標に対して真摯になる • そのために意識することを3つ紹介 原則①『目標第一』
24. 24 • その人に「広さ」を求めなくても良いような役割分担をすり合わせる ◦ 例えば、メンバー育成面はフォローを入れるとか、リソースアロケーションの問題は巻き取るなど • 常に専門性の高いリーダーがいるとは限らないので抜擢と育成も重要 ◦ 特に育成局面では、リーダーとの間の関係性だけでは見方が一元的になるリスクがあるので、メンバー・PdMなど ファンクション・立場が異なる人とも直接の接点を持ち、育成しているメンバーの伸びしろをきちんと対話する • リーダーを擁立したからといって「後は任せた」とおまかせするのではなく、 上述のような役割分担を共有しつつ、リーダーと二人三脚で目標達成にコミッ トする 強い専門性を持った領域のリーダーを立てる
25. 25 • リーダー本人とだけやり取りするのではなく、同じ領域を担当する各ファンク ションにまたがって目標に対するズレが起きないように関係者間で対話をする ◦ freeeでの場合、例えばPdMは組織的には別であるが、同じチームだと思って対話する • 特に「いつまでに」「誰に対して」デリバリーするかがあやふやになりがちな ので明確な目標を持つ ◦ 基盤特有の問題として、作った機能を導入してもらう約束をしていてもなんらかの優先度変更によって後から見送 られることもある。こうした変化に対して常に目標をアップデートする必要がある。 • また、目標からこぼれ落ちた部分への認識も合わせておきたい。状況が変わっ た際（トラブったとか）に何を優先すべきかなどを迅速に意思決定するため 各チームの目標に対して解像度を上げる
26. 26 • 1on1、各チームのミーティングなども含めて全部やろうとするとパンクする • 今自身が解くべき課題は何かに向き合い、必要なものに時間を投じれるだけの 濃淡をつける • 各チームのミーティングなど、定例に出てしまうのがスケジュール管理上は楽 だが、めんどくさくても毎週・毎日出席判断をする ◦ 「今週のアレは大事なんだっけ？」という問いを常に持ち続けるということ 時間の使い方に濃淡をつける
27. 27 • 「目標に対して真摯」というのは自分がそう思っていてもメンバーからそう 思ってもらえないとあんまり意味がない • 広い管掌範囲のため、どうしても個々に割くことのできる時間は少なくなる が、そんななかで上記のような認識を持ってもらうには見せ方の工夫も必要 • 例えば、特に重視したいキーワードをピン留めして使い続けたりする ◦ whyも重要だが、どうしても当てはめる事象に応じて説明の中身が変わるので、本人視点では一貫した主張も受け 手がそう受け取れるかの間にはギャップがある。なので「言葉の固定」で一貫性を強調するという意図 tips: 見せ方は重要
28. 　 これから活躍を広げるあなたへ
29. 29 • 大規模・基盤組織に限らず、これから活躍のフィールドを広げる際にも通づる ことかもしれない • 人は「完璧ではない」からこそ、周りを頼り、組織全体で価値を創造する意識 が重要 これから活躍を広げるあなたへ
30. スモールビジネスを世界の主役に