Tweet
Tweet

Slide 1

Slide 1 text

　 1 大規模アジャイルフレームワークから学ぶ エンジニアマネジメントの本質 Engineering Management Conference Japan 2025 2025年02月27日 株式会社TOKIUM プロダクト本部開発部 橘高 俊 (@xi_kax)

Slide 2

Slide 2 text

テーマは「増幅」と「触媒」 2

Slide 3

Slide 3 text

どんなことを話すの？ 3 テーマは「増幅」と「触媒」 🤔 組織急拡大による課題が出る中で、EMに求められる期待も多岐にわたってきた ● 「同じ方向を向けていない」という問題 やりたいことや目標がバラバラな中でどうコンセンサスを取るか ● 「チーム間のコミュニケーションコストが増えやすい」という問題 多発した複数チーム（または複数グループ）をまたいだマネジメントコストをどう抑えるか ● 「EM が Everything Manager になっちゃうよ」問題 ピープルマネジメントしながら採用活動しつつ、全社横断PJを回すだと...? 　　などなど... 事業のスケール（増幅）を可能とする組織づくり（触媒）が求められるなかで 大規模アジャイルフレームワークによる課題解決を行い、 エンジニアリングマネージャ としてすべきことを再定義していったという話

Slide 4

Slide 4 text

Contents 1. 自己紹介 & 会社概要 2. 「大規模アジャイルフレームワーク（SAFe®）」とは何か？ 3. なぜ「大規模アジャイルフレームワーク（SAFe®）」なのか 4. 見えてきたエンジニアマネジメントの本質 5. まとめ 4

Slide 5

Slide 5 text

自己紹介 & 会社概要 5

Slide 6

Slide 6 text

自己紹介 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

Slide 7

Slide 7 text

7 会社概要 会社名 設立日 所在地 従業員数 代表取締役 株式会社TOKIUM 2012年 6月 26日 東京都中央区銀座6-18-2 野村不動産銀座ビル 12F 220名 (2025年2月、正社員のみ) 黒﨑 賢一

Slide 8

Slide 8 text

法人支出管理クラウド「TOKIUM」 8 会社概要 領収書は撮って入れるだけ ペーパーレス経費精算クラウド 🚀2016年01月リリース 企業の支出にまつわる非生産的業務を削減し、コア業務に専念する時間を生み出す複数のB2B/SaaSを提供 これらのB2B/SaaSの開発・運用を通し、「社会全体の生産性の飛躍的な向上」「各企業が価値ある商品・サービスの 提供に注力できる世界」の実現を目指す 請求書のための出社をなくす ペーパーレス請求書受領クラウド 🚀2020年10月リリース あらゆる取引関係書類を一元管理 電帳法対応の文書管理クラウド 🚀2023年04月リリース スキャン不要で契約書を一元管理 契約管理クラウド 🚀2024年06月リリース

Slide 9

Slide 9 text

サービス概略 9 会社概要 支出に関する オペレーションを支援 稟議・契約管理 会計連携・支払い 経費・請求書の管理 法人支出管理 プラットフォーム 支出分析を基に 支出の最適化を支援 支出分析・比較 支出先の提案 紙、メール、サイトからのダウンロードなど、あらゆる形式の経理に関わる書類をTOKIUMに一元化 支出に関する業務効率化をサポートし、企業の経済活動を支える社会インフラとなるプラットフォームを目指す。

Slide 10

Slide 10 text

現在の開発体制 10 会社概要 ソリューショントレイン (ST) プロダクト アジャイルリリーストレイン (ART) BSMコア アジャイルリリーストレイン (ART) オペレーション アジャイルリリーストレイン (ART) プラットフォーム アジャイルリリーストレイン (ART) 各プロダクトの 開発チーム群 オペレーションに 関連するプロダクトの 開発チーム群 プロダクト共通機能の 機能開発チーム群 問合せやインフラなど ロールベースで共通する チーム群 ※SAFe®に関連する用語については後述のスライドで説明していきます！

Slide 11

Slide 11 text

「大規模アジャイルフレームワーク（SAFe®）」とは何か？ 11

Slide 12

Slide 12 text

大規模アジャイルフレームワーク（SAFe®） 12 「大規模アジャイルフレームワーク（SAFe®）」とは何か？ SAFe® ：ビジネスアジリティを実現するための統合フレームワーク リーンアジャイルにおける リーダーシップ エンプラレベルの ソリューションデリバリ チームとテクノロジの アジリティ 継続的な学習文化 組織的なアジリティ 継続的なデリバリ リーンポートフォリオ管理

Slide 13

Slide 13 text

大規模アジャイルフレームワーク（SAFe®） 13 「大規模アジャイルフレームワーク（SAFe®）」とは何か？ SAFe® ：ビジネスアジリティを実現するための統合フレームワーク リーンアジャイルにおける リーダーシップ エンプラレベルの ソリューションデリバリ チームとテクノロジの アジリティ 継続的な学習文化 継続的なデリバリ リーンポートフォリオ管理 組織的なアジリティ ＼今回フォーカスする部分／

Slide 14

Slide 14 text

組織構造とそれぞれの役割 14 「大規模アジャイルフレームワーク（SAFe®）」とは何か？ 🚂アジャイルリリーストレイン (ART) 󰻀アジャイルチーム ARTが同じミッションに向かって協調し、 顧客に継続的な価値を作り出す組織的な仕組み 継続的なデリバリーのためのパイプラインを構築し、 複数チーム間での調整と共通作業を作り出す組織的な仕組み 仕様を定義、実装、テストし、お客様への価値提供のための すべてのスキルを持った職能横断的なチーム ソリューショントレインで 方向性 を決定 🚄ソリューショントレイン (Solution Train)

Slide 15

Slide 15 text

組織構造とそれぞれの役割 15 「大規模アジャイルフレームワーク（SAFe®）」とは何か？ 󰻀アジャイルチーム ARTが同じミッションに向かって協調し、 顧客に継続的な価値を作り出す組織的な仕組み 継続的なデリバリーのためのパイプラインを構築し、 複数チーム間での調整と共通作業を作り出す組織的な仕組み 仕様を定義、実装、テストし、お客様への価値提供のための すべてのスキルを持った職能横断的なチーム 🚄ソリューショントレイン (Solution Train) 🚂アジャイルリリーストレイン (ART) ARTで チーム間の調整と協調 を実施

Slide 16

Slide 16 text

組織構造とそれぞれの役割 16 「大規模アジャイルフレームワーク（SAFe®）」とは何か？ 🚂アジャイルリリーストレイン (ART) ARTが同じミッションに向かって協調し、 顧客に継続的な価値を作り出す組織的な仕組み 継続的なデリバリーのためのパイプラインを構築し、 複数チーム間での調整と共通作業を作り出す組織的な仕組み 仕様を定義、実装、テストし、お客様への価値提供のための すべてのスキルを持った職能横断的なチーム 🚄ソリューショントレイン (Solution Train) 󰻀アジャイルチーム アジャイルチームで 要望を実現 する

Slide 17

Slide 17 text

組織構造とそれぞれの役割 17 「大規模アジャイルフレームワーク（SAFe®）」とは何か？ 🚂アジャイルリリーストレイン (ART) 󰻀アジャイルチーム ARTが同じミッションに向かって協調し、 顧客に継続的な価値を作り出す組織的な仕組み 継続的なデリバリーのためのパイプラインを構築し、 複数チーム間での調整と共通作業を作り出す組織的な仕組み 仕様を定義、実装、テストし、お客様への価値提供のための すべてのスキルを持った職能横断的なチーム 🚄ソリューショントレイン (Solution Train)

Slide 18

Slide 18 text

なぜ「大規模アジャイルフレームワーク（SAFe®）」なのか 18

Slide 19

Slide 19 text

（再掲）どんなことを話すの？ 19 テーマは「増幅」と「触媒」 🤔 組織急拡大による課題が出る中で、EMに求められる期待も多岐にわたってきた ● 「同じ方向を向けていない」という問題 やりたいことや目標がバラバラな中でどうコンセンサスを取るか ● 「チーム間のコミュニケーションコストが増えやすい」という問題 多発した複数チーム（または複数グループ）をまたいだマネジメントコストをどう抑えるか ● 「EM が Everything Manager になっちゃうよ」問題 ピープルマネジメントしながら採用活動しつつ、全社横断PJを回すだと...? 　　などなど... 事業のスケール（増幅）を可能とする組織づくり（触媒）が求められるなかで 大規模アジャイルフレームワークによる課題解決を行い、 エンジニアリングマネージャ としてすべきことを再定義していったという話

Slide 20

Slide 20 text

20 その１． 「同じ方向を向けていない」という問題

Slide 21

Slide 21 text

「同じ方向を向けていない」という問題 21 なぜ「大規模アジャイルフレームワーク（SAFe®）」なのか 私たちの目標は〇〇だから、 このタスクの優先度を上げませんか？ 早く解決できる課題から着手したほうが、 最終的な提供価値は大きいでしょ？ このお客様のチャーンは避けたいから ビジネス的にも優先すべき！ そんなことよりライブラリのバージョン、 そろそろ最新版にしない？ 言い分としては全部正しくみえるが故に、何に軸足に置くべきか難しい PdM にかかる負担は大きく、それが筋の良い選択か否かは属人的になりやすい

Slide 22

Slide 22 text

同じ方向に向くために「頑張ったら効果的」なタイミングは？ 22 なぜ「大規模アジャイルフレームワーク（SAFe®）」なのか 目標 生み出されたベクトルに対して、一つずつ後から変えていくのは骨が折れる... であるならば、ベクトルが生まれる前から意図した向きになる力学を仕込んでおきたい！ やりたいことがバラバラからスタート やりたいことがほぼ揃った所からスタート 揃えるのは 比較的容易！ 揃えるのは ハードモード.. 共通の目標に向かっている状況

Slide 23

Slide 23 text

意思決定が一元化されたことで「同じ方向を向きやすい」環境へ 23 なぜ「大規模アジャイルフレームワーク（SAFe®）」なのか SAFe®の仕組みの中で、自然と同じ方向を向くことができる状態になった 結果として、判断に迷った際に考えるべきポイントが明瞭になった 🚄ソリューショントレイン (Solution Train) 🚂アジャイルリリーストレイン (ART) 󰻀アジャイルチーム 今スプリントにおいて注力すべきは UX の向上施策であり、インジケータは NPS とする！ フロントエンドに関する課題や パフォーマンスの改善に関連する課題の優先度を上げよう！ 事前に関連箇所のリファクタしておくか！ ライブラリ入れ替えるだけで早くなりそうなところ見つけた！

Slide 24

Slide 24 text

24 その２． 「チーム間のコミュニケーションコストが増えやすい」 という問題

Slide 25

Slide 25 text

代理取得 オペレーション 「チーム間のコミュニケーションコストが増えやすい」という問題 25 なぜ「大規模アジャイルフレームワーク（SAFe®）」なのか 会社としてのビジネス戦略は One Platform 異なるプロダクト開発チームが、多くのタイミングで協力して機能開発する必要があった A の開発 A の開発 B の開発 C の開発

Slide 26

Slide 26 text

会社のビジネス戦略を踏まえたうえで会議体を最適化 26 なぜ「大規模アジャイルフレームワーク（SAFe®）」なのか アジャイルリリーストレイン（ART）で情報を同期 開発における各チームの組織課題の解消や、進捗管理を一元化することで会議体を最適化 プロダクト ART オペレーション ART 代理取得 オペレーション ソリューショントレイン A の開発 C の開発 B の開発

Slide 27

Slide 27 text

27 その３． 「EM が Everything Manager になっちゃうよ」問題

Slide 28

Slide 28 text

「EM が Everything Manager になっちゃうよ」問題 28 なぜ「大規模アジャイルフレームワーク（SAFe®）」なのか ロードマップと目標に対する進捗って どうなってる？ EM (Engineering Manager)

Slide 29

Slide 29 text

「EM が Everything Manager になっちゃうよ」問題 29 なぜ「大規模アジャイルフレームワーク（SAFe®）」なのか ロードマップと目標に対する進捗って どうなってる？ チーム横断のPJが必要！ プロジェクトマネージャよろしくね！ EM (Engineering Manager)

Slide 30

Slide 30 text

「EM が Everything Manager になっちゃうよ」問題 30 なぜ「大規模アジャイルフレームワーク（SAFe®）」なのか ロードマップと目標に対する進捗って どうなってる？ チーム横断のPJが必要！ プロジェクトマネージャよろしくね！ EM (Engineering Manager) メンバーのキャリアについてヒアリング＆ 育成計画立てておいてね！

Slide 31

Slide 31 text

「EM が Everything Manager になっちゃうよ」問題 31 なぜ「大規模アジャイルフレームワーク（SAFe®）」なのか ロードマップと目標に対する進捗って どうなってる？ チーム横断のPJが必要！ プロジェクトマネージャよろしくね！ EM (Engineering Manager) メンバーのキャリアについてヒアリング＆ 育成計画立てておいてね！ プロダクトにかかってる原価について 費用対効果のレポート欲しいなぁ。。

Slide 32

Slide 32 text

「EM が Everything Manager になっちゃうよ」問題 32 なぜ「大規模アジャイルフレームワーク（SAFe®）」なのか ロードマップと目標に対する進捗って どうなってる？ チーム横断のPJが必要！ プロジェクトマネージャよろしくね！ EM (Engineering Manager) メンバーのキャリアについてヒアリング＆ 育成計画立てておいてね！ プロダクトにかかってる原価について 費用対効果のレポート欲しいなぁ。。 セキュリティと監査が始まるから 後のハンドリングしといて

Slide 33

Slide 33 text

「EM が Everything Manager になっちゃうよ」問題 33 なぜ「大規模アジャイルフレームワーク（SAFe®）」なのか ロードマップと目標に対する進捗って どうなってる？ うわぁぁぁ（大丈夫です、確認します！） プロダクトにかかってる原価について 費用対効果のレポート欲しいなぁ。。 セキュリティと監査が始まるから 後のハンドリングしといて EM (Everything Manager) メンバーのキャリアについてヒアリング＆ 育成計画立てておいてね！ チーム横断のPJが必要！ プロジェクトマネージャよろしくね！ （心の声） いい感じに役割分担したいなぁ。。。

Slide 34

Slide 34 text

SAFe®における階層ごとのロール定義 34 なぜ「大規模アジャイルフレームワーク（SAFe®）」なのか ソリューショントレイン エンジニア ソリューション アーキテクト ソリューション マネージャ システム アーキテクト リリーストレイン エンジニア プロダクト マネージャ ソリューションに対して 責任を持つ 🚄ソリューション トレイン アーキテクトに対して 責任を持つ 組織的プロセスに対して 責任を持つ 🚂アジャイル リリーストレイン スクラムにおける各階層ごとに責任範囲が定義しているため 一人で全部を抱え込まない組織体系となるように役割を分担しやすい

Slide 35

Slide 35 text

EM の役割をSAFe®の役割として分担 35 なぜ「大規模アジャイルフレームワーク（SAFe®）」なのか ロードマップと目標に対する進捗って どうなってる？ プロダクトにかかってる原価について 費用対効果のレポート欲しいなぁ。。 セキュリティと監査が始まるから 後のハンドリングしといて メンバーのキャリアについてヒアリング＆ 育成計画立てておいてね！ チーム横断のPJが必要！ プロジェクトマネージャよろしくね！ 「システムアーキテクト」が 共通のセキュリティレベルを定義 「プロダクトマネージャ」が ニーズを満たすためにかかったコストを確認 「リリーストレインエンジニア」が チームにおけるケイパビリティを整理 「目的に応じた任意のロール」が プロジェクト達成に向けてリードする 「プロダクトマネージャ」が プロジェクトの進捗を確認 ART における分類

Slide 36

Slide 36 text

見えてきたエンジニアマネジメントの本質 36

Slide 37

Slide 37 text

Engineering Manager として実際に求められてきたこと 37 見えてきたエンジニアマネジメントの本質 参照: https://github.com/engineering-manager-meetup/engineering-management-triangle (※Engineering Manager Meetup のコミュニティのみなさまありがとうございます！) これまでのEMに対する期待値は全部入り 当然ながら希少＆育成の再現性もない... Engineering Management Triangle ⚙ Technology 　組織の全体の技術を広く扱います。 📦 Product 　不確実なものをプロダクトにします。 🤝 Team 　組織というものにフォーカスをします。

Slide 38

Slide 38 text

参照: https://github.com/engineering-manager-meetup/engineering-management-triangle Engineering Management Triangle 「SAFe®」の取組みを経て見えてきた「Engineering Manager」 38 見えてきたエンジニアマネジメントの本質 ⚙ システムアーキテクト 　ARTによって開発された 　共通の技術や設計を定義する 📦 プロダクトマネージャ 　ニーズを満たすソリューションを定義し、 　ライフサイクルにおいて開発をサポートする 🤝 リリーストレインエンジニア 　ARTを介して 　チームが価値提供できるようリードする

Slide 39

Slide 39 text

エンジニアリングマネージャとしてすべきこと 39 見えてきたエンジニアマネジメントの本質 EM システムアーキテクト * 比重 SAFe®における リリーストレインエンジニア * 比重 プロダクトマネージャ * 比重 ＋ ＋ EM はSAFe®における「システムアーキテクト」、「リリーストレインエンジニア」および 「プロダクトマネージャ」の組み合わせで表現される性質を持ち、 これらの役割の比重は会社の規模やフェーズによって異なる ※この建付けにしたことで「探す」「育てる」も現実味も出てきてきた！

Slide 40

Slide 40 text

まとめ 40

Slide 41

Slide 41 text

今回話したこと 41 まとめ 事業のスケール（増幅）を可能とする 組織づくり（触媒）が求められるなかで 解決策としてSAFe®を導入し、組織的な課題解決を行った EM を「システムアーキテクト」「リリーストレインエンジニア」および 「プロダクトマネージャ」の ３つの役割として定義 することにつながった EM として求められていることが明確に定義できた！

Slide 42

Slide 42 text

今回話したこと 42 まとめ EM が 行動に自信を持って取り組むことができる組織 へ成長できた！ うわぁぁぁ... 何すればいいんだ...全部やらなきゃ... EM (Everything Manager) EM (Engineering Manager) 今は「システムアーキテクト」として 行動しよう！

Slide 43

Slide 43 text

今回話したこと 43 まとめ あなたの組織はどうですか？ ブースで Ask the Speaker やります！ Engineering Management Triangle もあります！ スケールするにあたっての課題感や解決方法、 色々とディスカッションできると嬉しいです！

Slide 44

Slide 44 text

株式会社TOKIUM 東 京 本 社 ｜ 〒104-0061　東京都中央区銀座 6 丁目18-2 野村不動産銀座ビル12階 西日本営業所 ｜ 〒550-0015　大阪府大阪市西区南堀江 1 丁目 1 番14号 四ツ橋中埜ビル 7 階 44 URL : https://www.keihi.com/company