大規模アジャイルフレームワークから学ぶエンジニアマネジメントの本質

Transcript

1. 　 1 大規模アジャイルフレームワークから学ぶ エンジニアマネジメントの本質 Engineering Management Conference Japan 2025 2025年02月27日 株式会社TOKIUM プロダクト本部開発部 橘高 俊 (@xi_kax)
2. テーマは「増幅」と「触媒」 2
3. どんなことを話すの？ 3 テーマは「増幅」と「触媒」 🤔 組織急拡大による課題が出る中で、EMに求められる期待も多岐にわたってきた • 「同じ方向を向けていない」という問題 やりたいことや目標がバラバラな中でどうコンセンサスを取るか • 「チーム間のコミュニケーションコストが増えやすい」という問題 多発した複数チーム（または複数グループ）をまたいだマネジメントコストをどう抑えるか • 「EM が Everything Manager になっちゃうよ」問題 ピープルマネジメントしながら採用活動しつつ、全社横断PJを回すだと...? 　　などなど... 事業のスケール（増幅）を可能とする組織づくり（触媒）が求められるなかで 大規模アジャイルフレームワークによる課題解決を行い、 エンジニアリングマネージャ としてすべきことを再定義していったという話
4. Contents 1. 自己紹介 & 会社概要 2. 「大規模アジャイルフレームワーク（SAFe®）」とは何か？ 3. なぜ「大規模アジャイルフレームワーク（SAFe®）」なのか 4. 見えてきたエンジニアマネジメントの本質 5. まとめ 4
5. 自己紹介 & 会社概要 5
6. 自己紹介 6 自己紹介 & 会社概要 経歴 in TOKIUM 2017年　WebエンジニアとしてTOKIUM に入社（社員14人） 2019年　データ連携基盤チームをリーダーとして 0→1 立ち上げ 2020年　改善チーム（SRE + CRE）へ異動 2021年　CREチームをリーダーとして 0→1 立ち上げ 2023年　TOKIUM 初のEMとして複数チームのマネジメントを経験 2024年　開発部長としてエンジニアリング組織の成長を牽引 @xi_kax | いかねこ 橘高　俊 Kittaka　Shun
7. 7 会社概要 会社名 設立日 所在地 従業員数 代表取締役 株式会社TOKIUM 2012年 6月 26日 東京都中央区銀座6-18-2 野村不動産銀座ビル 12F 220名 (2025年2月、正社員のみ) 黒﨑 賢一
8. 法人支出管理クラウド「TOKIUM」 8 会社概要 領収書は撮って入れるだけ ペーパーレス経費精算クラウド 🚀2016年01月リリース 企業の支出にまつわる非生産的業務を削減し、コア業務に専念する時間を生み出す複数のB2B/SaaSを提供 これらのB2B/SaaSの開発・運用を通し、「社会全体の生産性の飛躍的な向上」「各企業が価値ある商品・サービスの 提供に注力できる世界」の実現を目指す 請求書のための出社をなくす ペーパーレス請求書受領クラウド 🚀2020年10月リリース あらゆる取引関係書類を一元管理 電帳法対応の文書管理クラウド 🚀2023年04月リリース スキャン不要で契約書を一元管理 契約管理クラウド 🚀2024年06月リリース
9. サービス概略 9 会社概要 支出に関する オペレーションを支援 稟議・契約管理 会計連携・支払い 経費・請求書の管理 法人支出管理 プラットフォーム 支出分析を基に 支出の最適化を支援 支出分析・比較 支出先の提案 紙、メール、サイトからのダウンロードなど、あらゆる形式の経理に関わる書類をTOKIUMに一元化 支出に関する業務効率化をサポートし、企業の経済活動を支える社会インフラとなるプラットフォームを目指す。
10. 現在の開発体制 10 会社概要 ソリューショントレイン (ST) プロダクト アジャイルリリーストレイン (ART) BSMコア アジャイルリリーストレイン (ART) オペレーション アジャイルリリーストレイン (ART) プラットフォーム アジャイルリリーストレイン (ART) 各プロダクトの 開発チーム群 オペレーションに 関連するプロダクトの 開発チーム群 プロダクト共通機能の 機能開発チーム群 問合せやインフラなど ロールベースで共通する チーム群 ※SAFe®に関連する用語については後述のスライドで説明していきます！
11. 「大規模アジャイルフレームワーク（SAFe®）」とは何か？ 11
12. 大規模アジャイルフレームワーク（SAFe®） 12 「大規模アジャイルフレームワーク（SAFe®）」とは何か？ SAFe® ：ビジネスアジリティを実現するための統合フレームワーク リーンアジャイルにおける リーダーシップ エンプラレベルの ソリューションデリバリ チームとテクノロジの アジリティ 継続的な学習文化 組織的なアジリティ 継続的なデリバリ リーンポートフォリオ管理
13. 大規模アジャイルフレームワーク（SAFe®） 13 「大規模アジャイルフレームワーク（SAFe®）」とは何か？ SAFe® ：ビジネスアジリティを実現するための統合フレームワーク リーンアジャイルにおける リーダーシップ エンプラレベルの ソリューションデリバリ チームとテクノロジの アジリティ 継続的な学習文化 継続的なデリバリ リーンポートフォリオ管理 組織的なアジリティ ＼今回フォーカスする部分／
14. 組織構造とそれぞれの役割 14 「大規模アジャイルフレームワーク（SAFe®）」とは何か？ 🚂アジャイルリリーストレイン (ART) 󰻀アジャイルチーム ARTが同じミッションに向かって協調し、 顧客に継続的な価値を作り出す組織的な仕組み 継続的なデリバリーのためのパイプラインを構築し、 複数チーム間での調整と共通作業を作り出す組織的な仕組み 仕様を定義、実装、テストし、お客様への価値提供のための すべてのスキルを持った職能横断的なチーム ソリューショントレインで 方向性 を決定 🚄ソリューショントレイン (Solution Train)
15. 組織構造とそれぞれの役割 15 「大規模アジャイルフレームワーク（SAFe®）」とは何か？ 󰻀アジャイルチーム ARTが同じミッションに向かって協調し、 顧客に継続的な価値を作り出す組織的な仕組み 継続的なデリバリーのためのパイプラインを構築し、 複数チーム間での調整と共通作業を作り出す組織的な仕組み 仕様を定義、実装、テストし、お客様への価値提供のための すべてのスキルを持った職能横断的なチーム 🚄ソリューショントレイン (Solution Train) 🚂アジャイルリリーストレイン (ART) ARTで チーム間の調整と協調 を実施
16. 組織構造とそれぞれの役割 16 「大規模アジャイルフレームワーク（SAFe®）」とは何か？ 🚂アジャイルリリーストレイン (ART) ARTが同じミッションに向かって協調し、 顧客に継続的な価値を作り出す組織的な仕組み 継続的なデリバリーのためのパイプラインを構築し、 複数チーム間での調整と共通作業を作り出す組織的な仕組み 仕様を定義、実装、テストし、お客様への価値提供のための すべてのスキルを持った職能横断的なチーム 🚄ソリューショントレイン (Solution Train) 󰻀アジャイルチーム アジャイルチームで 要望を実現 する
17. 組織構造とそれぞれの役割 17 「大規模アジャイルフレームワーク（SAFe®）」とは何か？ 🚂アジャイルリリーストレイン (ART) 󰻀アジャイルチーム ARTが同じミッションに向かって協調し、 顧客に継続的な価値を作り出す組織的な仕組み 継続的なデリバリーのためのパイプラインを構築し、 複数チーム間での調整と共通作業を作り出す組織的な仕組み 仕様を定義、実装、テストし、お客様への価値提供のための すべてのスキルを持った職能横断的なチーム 🚄ソリューショントレイン (Solution Train)
18. なぜ「大規模アジャイルフレームワーク（SAFe®）」なのか 18
19. （再掲）どんなことを話すの？ 19 テーマは「増幅」と「触媒」 🤔 組織急拡大による課題が出る中で、EMに求められる期待も多岐にわたってきた • 「同じ方向を向けていない」という問題 やりたいことや目標がバラバラな中でどうコンセンサスを取るか • 「チーム間のコミュニケーションコストが増えやすい」という問題 多発した複数チーム（または複数グループ）をまたいだマネジメントコストをどう抑えるか • 「EM が Everything Manager になっちゃうよ」問題 ピープルマネジメントしながら採用活動しつつ、全社横断PJを回すだと...? 　　などなど... 事業のスケール（増幅）を可能とする組織づくり（触媒）が求められるなかで 大規模アジャイルフレームワークによる課題解決を行い、 エンジニアリングマネージャ としてすべきことを再定義していったという話
20. 20 その１． 「同じ方向を向けていない」という問題
21. 「同じ方向を向けていない」という問題 21 なぜ「大規模アジャイルフレームワーク（SAFe®）」なのか 私たちの目標は〇〇だから、 このタスクの優先度を上げませんか？ 早く解決できる課題から着手したほうが、 最終的な提供価値は大きいでしょ？ このお客様のチャーンは避けたいから ビジネス的にも優先すべき！ そんなことよりライブラリのバージョン、 そろそろ最新版にしない？ 言い分としては全部正しくみえるが故に、何に軸足に置くべきか難しい PdM にかかる負担は大きく、それが筋の良い選択か否かは属人的になりやすい
22. 同じ方向に向くために「頑張ったら効果的」なタイミングは？ 22 なぜ「大規模アジャイルフレームワーク（SAFe®）」なのか 目標 生み出されたベクトルに対して、一つずつ後から変えていくのは骨が折れる... であるならば、ベクトルが生まれる前から意図した向きになる力学を仕込んでおきたい！ やりたいことがバラバラからスタート やりたいことがほぼ揃った所からスタート 揃えるのは 比較的容易！ 揃えるのは ハードモード.. 共通の目標に向かっている状況
23. 意思決定が一元化されたことで「同じ方向を向きやすい」環境へ 23 なぜ「大規模アジャイルフレームワーク（SAFe®）」なのか SAFe®の仕組みの中で、自然と同じ方向を向くことができる状態になった 結果として、判断に迷った際に考えるべきポイントが明瞭になった 🚄ソリューショントレイン (Solution Train) 🚂アジャイルリリーストレイン (ART) 󰻀アジャイルチーム 今スプリントにおいて注力すべきは UX の向上施策であり、インジケータは NPS とする！ フロントエンドに関する課題や パフォーマンスの改善に関連する課題の優先度を上げよう！ 事前に関連箇所のリファクタしておくか！ ライブラリ入れ替えるだけで早くなりそうなところ見つけた！
24. 24 その２． 「チーム間のコミュニケーションコストが増えやすい」 という問題
25. 代理取得 オペレーション 「チーム間のコミュニケーションコストが増えやすい」という問題 25 なぜ「大規模アジャイルフレームワーク（SAFe®）」なのか 会社としてのビジネス戦略は One Platform 異なるプロダクト開発チームが、多くのタイミングで協力して機能開発する必要があった A の開発 A の開発 B の開発 C の開発
26. 会社のビジネス戦略を踏まえたうえで会議体を最適化 26 なぜ「大規模アジャイルフレームワーク（SAFe®）」なのか アジャイルリリーストレイン（ART）で情報を同期 開発における各チームの組織課題の解消や、進捗管理を一元化することで会議体を最適化 プロダクト ART オペレーション ART 代理取得 オペレーション ソリューショントレイン A の開発 C の開発 B の開発
27. 27 その３． 「EM が Everything Manager になっちゃうよ」問題
28. 「EM が Everything Manager になっちゃうよ」問題 28 なぜ「大規模アジャイルフレームワーク（SAFe®）」なのか ロードマップと目標に対する進捗って どうなってる？ EM (Engineering Manager)
29. 「EM が Everything Manager になっちゃうよ」問題 29 なぜ「大規模アジャイルフレームワーク（SAFe®）」なのか ロードマップと目標に対する進捗って どうなってる？ チーム横断のPJが必要！ プロジェクトマネージャよろしくね！ EM (Engineering Manager)
30. 「EM が Everything Manager になっちゃうよ」問題 30 なぜ「大規模アジャイルフレームワーク（SAFe®）」なのか ロードマップと目標に対する進捗って どうなってる？ チーム横断のPJが必要！ プロジェクトマネージャよろしくね！ EM (Engineering Manager) メンバーのキャリアについてヒアリング＆ 育成計画立てておいてね！
31. 「EM が Everything Manager になっちゃうよ」問題 31 なぜ「大規模アジャイルフレームワーク（SAFe®）」なのか ロードマップと目標に対する進捗って どうなってる？ チーム横断のPJが必要！ プロジェクトマネージャよろしくね！ EM (Engineering Manager) メンバーのキャリアについてヒアリング＆ 育成計画立てておいてね！ プロダクトにかかってる原価について 費用対効果のレポート欲しいなぁ。。
32. 「EM が Everything Manager になっちゃうよ」問題 32 なぜ「大規模アジャイルフレームワーク（SAFe®）」なのか ロードマップと目標に対する進捗って どうなってる？ チーム横断のPJが必要！ プロジェクトマネージャよろしくね！ EM (Engineering Manager) メンバーのキャリアについてヒアリング＆ 育成計画立てておいてね！ プロダクトにかかってる原価について 費用対効果のレポート欲しいなぁ。。 セキュリティと監査が始まるから 後のハンドリングしといて
33. 「EM が Everything Manager になっちゃうよ」問題 33 なぜ「大規模アジャイルフレームワーク（SAFe®）」なのか ロードマップと目標に対する進捗って どうなってる？ うわぁぁぁ（大丈夫です、確認します！） プロダクトにかかってる原価について 費用対効果のレポート欲しいなぁ。。 セキュリティと監査が始まるから 後のハンドリングしといて EM (Everything Manager) メンバーのキャリアについてヒアリング＆ 育成計画立てておいてね！ チーム横断のPJが必要！ プロジェクトマネージャよろしくね！ （心の声） いい感じに役割分担したいなぁ。。。
34. SAFe®における階層ごとのロール定義 34 なぜ「大規模アジャイルフレームワーク（SAFe®）」なのか ソリューショントレイン エンジニア ソリューション アーキテクト ソリューション マネージャ システム アーキテクト リリーストレイン エンジニア プロダクト マネージャ ソリューションに対して 責任を持つ 🚄ソリューション トレイン アーキテクトに対して 責任を持つ 組織的プロセスに対して 責任を持つ 🚂アジャイル リリーストレイン スクラムにおける各階層ごとに責任範囲が定義しているため 一人で全部を抱え込まない組織体系となるように役割を分担しやすい
35. EM の役割をSAFe®の役割として分担 35 なぜ「大規模アジャイルフレームワーク（SAFe®）」なのか ロードマップと目標に対する進捗って どうなってる？ プロダクトにかかってる原価について 費用対効果のレポート欲しいなぁ。。 セキュリティと監査が始まるから 後のハンドリングしといて メンバーのキャリアについてヒアリング＆ 育成計画立てておいてね！ チーム横断のPJが必要！ プロジェクトマネージャよろしくね！ 「システムアーキテクト」が 共通のセキュリティレベルを定義 「プロダクトマネージャ」が ニーズを満たすためにかかったコストを確認 「リリーストレインエンジニア」が チームにおけるケイパビリティを整理 「目的に応じた任意のロール」が プロジェクト達成に向けてリードする 「プロダクトマネージャ」が プロジェクトの進捗を確認 ART における分類
36. 見えてきたエンジニアマネジメントの本質 36
37. Engineering Manager として実際に求められてきたこと 37 見えてきたエンジニアマネジメントの本質 参照: https://github.com/engineering-manager-meetup/engineering-management-triangle (※Engineering Manager Meetup のコミュニティのみなさまありがとうございます！) これまでのEMに対する期待値は全部入り 当然ながら希少＆育成の再現性もない... Engineering Management Triangle ⚙ Technology 　組織の全体の技術を広く扱います。 📦 Product 　不確実なものをプロダクトにします。 🤝 Team 　組織というものにフォーカスをします。
38. 参照: https://github.com/engineering-manager-meetup/engineering-management-triangle Engineering Management Triangle 「SAFe®」の取組みを経て見えてきた「Engineering Manager」 38 見えてきたエンジニアマネジメントの本質 ⚙ システムアーキテクト 　ARTによって開発された 　共通の技術や設計を定義する 📦 プロダクトマネージャ 　ニーズを満たすソリューションを定義し、 　ライフサイクルにおいて開発をサポートする 🤝 リリーストレインエンジニア 　ARTを介して 　チームが価値提供できるようリードする
39. エンジニアリングマネージャとしてすべきこと 39 見えてきたエンジニアマネジメントの本質 EM システムアーキテクト * 比重 SAFe®における リリーストレインエンジニア * 比重 プロダクトマネージャ * 比重 ＋ ＋ EM はSAFe®における「システムアーキテクト」、「リリーストレインエンジニア」および 「プロダクトマネージャ」の組み合わせで表現される性質を持ち、 これらの役割の比重は会社の規模やフェーズによって異なる ※この建付けにしたことで「探す」「育てる」も現実味も出てきてきた！
40. まとめ 40
41. 今回話したこと 41 まとめ 事業のスケール（増幅）を可能とする 組織づくり（触媒）が求められるなかで 解決策としてSAFe®を導入し、組織的な課題解決を行った EM を「システムアーキテクト」「リリーストレインエンジニア」および 「プロダクトマネージャ」の ３つの役割として定義 することにつながった EM として求められていることが明確に定義できた！
42. 今回話したこと 42 まとめ EM が 行動に自信を持って取り組むことができる組織 へ成長できた！ うわぁぁぁ... 何すればいいんだ...全部やらなきゃ... EM (Everything Manager) EM (Engineering Manager) 今は「システムアーキテクト」として 行動しよう！
43. 今回話したこと 43 まとめ あなたの組織はどうですか？ ブースで Ask the Speaker やります！ Engineering Management Triangle もあります！ スケールするにあたっての課題感や解決方法、 色々とディスカッションできると嬉しいです！
44. 株式会社TOKIUM 東 京 本 社 ｜ 〒104-0061　東京都中央区銀座 6 丁目18-2 野村不動産銀座ビル12階 西日本営業所 ｜ 〒550-0015　大阪府大阪市西区南堀江 1 丁目 1 番14号 四ツ橋中埜ビル 7 階 44 URL : https://www.keihi.com/company