Upgrade to Pro — share decks privately, control downloads, hide ads and more …

特定領域から複数領域へ、そのとき何を求められるのか?縦と横、2つの影響力:統合型を目指す大規模...

Sponsored · Ship Features Fearlessly Turn features on and off without deploys. Used by thousands of Ruby developers.

 特定領域から複数領域へ、そのとき何を求められるのか?縦と横、2つの影響力:統合型を目指す大規模な開発組織での実践

Avatar for keitatomozawa

keitatomozawa

March 04, 2026
Tweet

More Decks by keitatomozawa

Other Decks in Business

Transcript

  1.   2 経歴 • 2016~2019: SIer ◦ SEとして様々な開発に遊軍的に携わる • 2019/11~:

    freee ◦ 前: ⼈事労務, ⼯数管理, 販売 ▪ 新規プロダクト多め ◦ 現: 統合flow基盤開発本部 本部⻑ ▪ 認証、認可、権限、課⾦、サポー ト基盤、申請承認、通知関連、 ファイル/OCR等 • 京都在住 tomoz(ともじー) Engineering Manager Keita Tomozawa X: @tomozkit プロフィール画像の トリミング⽅法
  2. 3 • 生成AIによって増えたケイパビリティをどうビジネスに活かせるか • 検証サイクルの限界(特定領域の開発スピードを10xにはできない) ◦ プロダクト開発では実際にユーザーに使ってもらったフィードバックをもとに次の一手を考 える必要があり、開発スピードの増加はある程度のところで頭打ちになる • 組織の組成単位の制約(チームの人数には下限がある)

    ◦ 個人でカバーできる範囲が増えたから今まで6人のチームを2人にできるか?属人性が高まり すぎること考えるとこの方向性には一定限界がある ◦ 複数人の目線が入ることは多様性の観点からもポジティブな影響がありそう 生成AIは我々の仕事をどう変えるか
  3. 4 • 皆が通るEMとしての出発点は、特定領域のチームのリーダーになること • 一方、その先のキャリア、特に管掌範囲を広げる方向の変化は一見非連続な変 化にみえ、決してイメージしやすいものではない ◦ え?今すでに1チームでも大変なのに、横に広げるなんて無理無理... ◦ プレイングできなくなりそう...

    • 生成AIの台頭によって、従来の1チームが抱えられるケイパビリティも増加 し、その増加は管掌範囲を広げる方向にも作用する ->管掌範囲が広がった際の「難所」とその「乗り越え方」に注目したい なぜ今、このテーマなのか
  4. 8 統合型経営プラットフォームを提供 バックオフィスの全体最適化を図る設計思想 経理 人事マスタ | 入退社手続 | 雇用契約 |

    マイナンバー | 勤怠申請 | 勤怠管理 | 給与計算・明細 | 社会保険 | 年末調整 人事 労務 販売 管理 法務 ‧ 情シス 税務申告 (法人税 | 償却資産税) 契約申請 | 文書作成 | 電子契約締結 | 文書管理 工数入力 | 工数申請 | 案件別人件費管理 勤怠申請 | 勤怠管理 財務会計 | 管理会計 | 固定資産 受取請求書 | 債務管理 | 振込 経費精算 | 請求書発行 | 債権管理 購買申請 | 受取請求書 | 債務管理 | 振込 | 経費精算 | 請求書発行 | 債権管理 | 法人カード SaaSアカウント管理 (発行 | 削除 | 棚卸 | 更新) 備品管理 購買申請 | 受取請求書 | 債務管理 | 振込 | 経費精算 | 法人カード 販売管理 | 受発注管理 | 案件収支管理 | 帳票発行 契約管理 | パートナー管理 | 発注管理 | 進捗管理 | 帳票発行 | 支払管理 請求書受取・スキャン代行 | 原本・データ保管 | 仕訳入力代行 | 支払管理 | 健康診断管理 | ストレスチェック | 労基署への報告書作成・電子申請 | ストレスチェックの集団分析 給与・賞与計算 | 入退社手続 | 身上変更 | 年末調整 | 年次イベント | 従業員対応
  5. 9 ヒトと事業を一気通貫。データで鍛え、数字で伸ばす。 統合データと適切な可視化 が経営と組織を成長させる 経営の可視化 業務とデータの 統合 統合
 flow
 Communi-


    cation flow
 Work flow
 Data flow
 I T 財務 会計 販売 購買 経理 給与 労務 評価 法務 総務 人事 事業別 P / L・部門別 P / L リアルタイムな 可視化 案件損益・P J 一覧 購買・発注情報 はたらく人の可視化 人事レポート 残業・労務レポート 評価・スキルレポート freee TOGO World 2025 より
  6. 10 現在、開発組織全体で600人超(Eng, PdM, ApD, QA) • 各サービスごとのプロダクト組織、ドメインや顧客セグメントによるチーム分けなど • インフラ・ミドルウェア・アプリなど幅広い基盤組織 •

    横断支援組織も存在 組織が拡大すると、基本的にチームはそれぞれ自律的に仕事を進める • 各チームはそれぞれのOKRに集中し、隣接領域との連携は減る • Conwayの法則: 組織の構造が、システムの設計に反映される • チームの自立性が高まるほど、何かあった時の調整コストが増大 大規模開発組織の実情
  7. 11 所謂 “疎結合” な組織では統合型は実現できない • 統合されているとは、仮にプロダクトをまたいだとしても、業務の中でシームレスに使えるこ と • そのためにはデータの統合、体験の一貫性などが必要 •

    "分断" された環境下で情報がサイロ化してしまうとこれらが達成できない 統合型のジレンマ: 疎結合な組織では解決できない課題 統合型プラットフォームを実現するには、 組織の結節点になるEMが分断を防ぐ必要がある
  8. 12 • 始まり: プレイヤーからリーダーに ◦ 1つの固定されたチームのリーダー(チーム規模: 3~4人) ◦ 設計も実装も全部把握している。自分で考えて、決められる •

    その後: 徐々に広がる管掌範囲 ◦ 今まで触ってこなかった領域のマネジメントを任される(チーム規模: 〜20人程度) ◦ そのチームのことは「誰よりも自分が知らない」状態からはじまる ◦ 実装の詳細を把握しないと、、、といっている場合ではない • 現在: さらに広がり続ける ◦ 組織レイヤが一段上がって、さらに広範囲に(チーム規模: 約150人) ◦ 認証、認可、権限、課金、サポート基盤、申請承認、通知関連、ファイル/OCR、インフラ 広がり続ける中で、何が求められてきた(ている)のか? 私のリーダーとしてのこれまで
  9. 14 個々の領域に対する影響力(縦/深さ) • 必ずしも自分が詳しくない領域も含め、自身の意見を持ってリードする • 詳細を全て把握できない中で、信頼を得て意思決定する • → これには「3つの壁」を乗り越える必要がある 組織横断でムーブメントを起こす(横/広さ)

    • 幅広い管掌範囲に対して、組織全体に変化を浸透させる • プロセスの標準化や品質管理など、横串の施策を推進 • → これには「適切な焦点」と「胆力」が必要 管掌範囲が広がると求められる2つの役割
  10. 17 1. 詳細把握の限界 ◦ 幅が広くなると、全ての領域で現場のエンジニアと同等の解像度を維持し続けることは物理的に不可能 ◦ それに対して、「ひとつひとつ積み上げていかないと全体は見えないのでは」という思い込みとの葛藤 2. 他組織との同期 ◦

    自組織の成果は、常に他部署の動向や戦略に依存 ◦ 組織の内側だけ見ていては、適切な判断は下せない ◦ ステークホルダーは増えれば増えるほど調整コストが指数関数的に増大 3. 信頼構築の難しさ ◦ 幅が広がると必然的に権限委譲せざるを得ないが、丸投げすぎる・引きすぎると「管理の人」という見え方に ◦ 介入しすぎも双方にとって不幸せな結果を招くだけ、難しい距離感 広範な管掌範囲をリードする際の3つの壁
  11. 18 失敗パターン: • 全領域を理解しようと、全ての定例、全てのレビューに参加 • 結果: 自分がボトルネックになり、組織全体のスピードが低下 ◦ だけならまだよく、自分が知らない領域の解像度を上げるためだけに非常に効率が悪い学習になる可能性も こうしたい:

    • 「完璧ではない」自分を受け入れる • 全領域を詳細に把握することを諦める • その代わり、適切なバランスで解像度を上げる場所を見極める • 専門性を持つメンバーを信頼し、自分は「組織としての意思決定」と「環境整備」に専念 詳細把握の限界との向き合い方
  12. 20 • 特定領域のEMの時: ◦ 自チームの技術スタック、ロードマップ、成果に集中 ◦ 他部署との連携は「たまに発生するイベント」 • 複数領域のEMになると: ◦

    基盤チームとプロダクトチームの連携 ◦ 組織をまたいだ差し込み的な調整 ◦ これらが「日常的な業務」に変わる • 求められるスキル: ◦ 相手の組織が何を目指しているのかを理解する力 ◦ それによって、自分たちのやりたいことの伝え方を変えられる力 ◦ 組織横断での最適化を考える視点も重要 他組織との同期/連携の壁
  13. 21 • メンバーが不安に感じること: ◦ 「このマネージャーは、私たちの領域のことを本当に理解しているのか?」 ◦ 「ただメンバーマネジメントしているだけではないか?」 • 失敗パターン: ◦

    無理に技術的な詳細に入り込み、専門家ぶる → 「わかってないのに口を出す人」と見られる ◦ 知らないことを隠して、意見も言わない → 「判断丸投げ、管理の人」と見られる • こうしたい: ◦ 自分の「明るくない領域」を素直に認め、わからないことは頼る ◦ 頼りながらも、「XXが大事だと思ってるんですがどうですか?」と問いを重ねてメンバーとのギャップを埋める ◦ メンバーの専門性を尊重しつつも、我関せずにならない。チームの “本業” に対して意地でも絡む 信頼構築の難しさの乗り越え方
  14. 25 新しいプロセスや文化を浸透させるには単にツールを配布するだけでは 不十分 1. 高い解像度で運用状況を把握 2. 各チームの文脈に合わせた伝え方 3. 時に泥臭く自分で足を運ぶ努力 4.

    その姿を通して周囲を巻き込み協力者を生み出していく 組織にムーブメントを起こす「胆力」 こうした胆力が組織のカルチャーを作る
  15. 27 • AI時代において管掌範囲の拡大は必然 • マネジメントに対して言われるネガティブイメージ ◦ レイヤが上がる = 現場から離れる ◦

    政治的な調整が増える ◦ 管理だけの人になる • 実際に体験してみると ◦ 組織を構造から改革でき、自分の仕事にレバレッジをかけられる ◦ 管掌範囲が広がったことによって手段が増え、持てる問題解決の手段が増える 管掌範囲が広がるキャリアの醍醐味 管掌範囲を広げることは、 エンジニアとしての影響力を最大化する最高の挑戦
  16. 28 • しかし、そんなキャリアに対して葛藤も多いのが私の率直な感情 ◦ 人を頼る心理的ハードル ◦ プレイヤーからマネージャーへの転換における価値の喪失感 ◦ “全てを把握できない”, “何者にもなれない”

    という不安 • 「完璧でないといけない」という思い込みからの解放 ◦ それぞれの領域のことを全て理解していなくても、周りを頼って価値を創出できる ◦ 思いやビジョンをきちんと伝えれば、それに応えて一緒に考えてくれる キャリアにおける葛藤と成長 この不完全さを受け入れたリーダーシップこそが、 ”広くみるマネジメント”の鍵
  17. 29 • 縦の影響力: 解像度の呪縛からの解放、選択と集中 ◦ 全てを知ることは不可能。専門家を信頼し、自分は「意思決定」と「環境整備」に全振りする 。 • 横の影響力:フォーマットだけではなく伝え方までこだわる「胆力」 ◦

    時に泥臭く一次情報をかき集め、自分の言葉で直接伝える・やってみせる手段も持つ。その上で理解してくれる仲 間を増やしていく。 特定領域*nの独立した組織ではなく、それをまとめるEMが いるからこそ、成果は大きくレバレッジする! 不完全さを受け入れる勇気が、組織の可能性を 最大化する