「共創型エンジニアリングマネジメント」 の挑戦と実践

1. 「共創型エンジニアリングマネジメント」 の挑戦と実践 by うっしー / @sudo5in5k (牛窪 翔) 2025/2/27 Engineering Manager Conference Japan 2025
2. 自己紹介 2 • うっしー (Sho Ushikubo) • 株式会社kubellでEMをやっています ◦ 元々はAndroidエンジニアで、EMは3年ほど • マネジメント領域で最近勉強しているのは ◦ 開発生産性・会計学・人的資本経営 ◦ エンジニアの活動が事業にどう結びつくかに興 味があります • アカウント (プレーリーカードで交換もぜひ🍻) ◦ X (旧: Twitter) - @sudo5in5k ◦ note - @sudo5in5k
3. 今回の発表で関心がありそうな方・発表の流れ 3 • エンジニアリングマネージャーの育成・成長に課題を感じる方 • EM中心の組織設計に興味がある方 • サイロ化や局所最適化に直面しており、チーム間連携強化を目指したい方 一般論＋自身の経験を言語化して、規模に応じた組織変化とEMの難しさ EMグループの設立と「共創型エンジニアリングマネジメント」について 弊社のこれまでの組織体制とEMの役割 総括 関心がありそうな方
4. 01 | 規模に応じた組織変化とEMの難しさ
5. 事業が軌道に乗ると組織が変わるのはなぜ？ 5 ChatGPTに聞いてみました 業務を効率的に進めるため・責任を明確にするためとのこと
6. 事業が軌道に乗るとどうなる -これまでの経験を言語化して- 6 • 事業が軌道に乗ると以下のことが起こる ◦ 顧客数増加 ◦ 顧客層拡大 ◦ プロダクト・サービス多様化 • 課題の分割が必要になる ◦ 利益最大 (抽象度⏫) ▪ 売上アップ (抽象度⬆) ▪ コストダウン (抽象度⬆) ◦ 課題はさらに分割される ▪ 〇〇施策をリリースする (抽象度⬇) ▪ サーバー運用費削減 (抽象度⬇) など
7. 事業が軌道に乗るとどうなる -これまでの経験を言語化して- 7 • 課題はさらに分割されると「タスク」になる ◦ 例: 〇〇施策をリリース ▪ デザイン作成 (抽象度⏬) ▪ 要件定義作成 (抽象度⏬) ▪ API作成 (抽象度⏬) ◦ 例: サーバー運用費削減 ▪ 契約プラン変更 (抽象度⏬) ▪ 構成見直し (抽象度⏬) 抽象と具体を駆使して複雑な問題を分割すると、タスクになり解きやすくなる
8. タスクが増えるとどうなる -これまでの経験を言語化して- 8 • タスクを消化、より効率的するための仕組みづくりがされる • 当然人も増えてきて、組織規模も大きくなる • 分業制の形へ移行していく ◦ Pros ▪ 個々が強みであるタスクに集中できる ◦ Cons ▪ 自分が理解できる範囲が狭くなる ▪ 協力することが難しくなってくる • 落ちているボールをどうする？ • これはどこのチームが担当する？ 効率的にタスクを消化できるようになるが全体を理解するのは難しくなってくる
9. タスクが増えるとどうなる -これまでの経験を言語化して- 9 • また、「タスク」は独立とは限らない • 例: ◯◯施策をリリースする ◦ いくつの工程・担当者がいる ◦ 全工程が終わってはじめて価値提供 • もし設計開発が遅れてリリースが間に合わなかったら誰のせい？ ◦ 遅れた設計開発者？ ◦ プロセスが悪かったため全員？ ◦ デザインがわかりにくく開発が遅れたかもしれない？ • 分業の形をとっていたとしても、個人の成果は他人の成果に左右される面もある タスクを遂行するため進捗の管理・指導が必要で、責任の所在を明確にしなければならない
10. そこで、 みなさん「マネージャー」の出番です
11. 「管理」による組織の生産性向上の期待 -これまでの経験を言語化して- 11 • マネージャーとしてある程度のまとまり(=部門、事業) を管理することで以下の効果が期待できる ◦ トップマネジメントからの権限委譲による成長 ◦ まとまり同士の役割分担化 ◦ コミュニケーションの複雑性の解消 ◦ まとまり内の迅速な意思決定や動機付け ◦ 責任の明確化 最初はいわゆる「マイクロマネジメント」の段階 • 管理による効率化・生産性向上が見込めるが、マネージャーが手放しでは回らない状況 短期的or状況に応じて有効だが、中長期では弊害も出てくる
12. 「マイクロマネジメント」の弊害？ -これまでの経験を言語化して- 12 • 組織の変化により「マイクロマネジメント」が保てなくなる時が来る • 人員増加による認知限界 • 人事異動・キャリア変化 ◦ 役割設計の劣化 ◦ 「ピーターの法則」 効率的のため「管理」をしているのに、マネージャーの負担が大きくなりボトルネックに 異動やキャリア変化で構成がカオスになり、役割・情報が劣化していく
13. 「権限委譲」による解決？ -これまでの経験を言語化して- 13 • 組織変化に対応するため、「タスク」だけでない様々な業務をマネージャーが権限委譲 • 権限委譲により以下が解決できる ◦ マネージャー実務負担軽減 ◦ メンバーの自主性向上 ◦ メンバーの成長促進 書籍『エンジニアリングマネージャーのしごと』より引用抜粋 それだけ「権限委譲」は難しい、委譲がされた後に起こり得る結果は？ • 一方、委譲の「難しさ」もある ◦ 原則、組織図通り委譲されてしまう ◦ 人により委譲内容と受け取り方に濃淡がある ◦ メンバーが判断することが増え、人員構成が変わればやり方が異なる人が集まる
14. 委譲がされたあとの最悪なシナリオ -これまでの経験を言語化して- 14 • 委譲内容（濃淡あり）をもとに自分たちの見える範囲の中で最善のことを実行 • 独自の管理方針や行動がされてくる ◦ ≠ 自己組織化 ◦ =「局所最適」へ ▪ 本当は分割前の課題を解決したい ▪ しかし分割の課題を最適にしている • 私たちの成果が他部署成果に左右される面もある • 協力したいが、他部署がすることが見えにくい ◦ 自己完結できる目標の実行 ◦ より上位の部署や経営層とのズレ ▪ 「サイロ化」へ
15. 「マネージャー」として 局所最適・サイロ化することは 成果になるでしょうか
16. 「マネージャー」の成果は？ 16 マネージャーのアウトプット = あなたのチームのアウトプット + あなたが影響を与えた他チームのアウトプット 書籍『エンジニアリングマネージャーのしごと』より引用抜粋 局所最適・サイロ化はまずい状況といってよい • 自チームだけの成果を極限に高くすると総量は高いが、それではダメ • 「マネージャー」として全体最適しながらチームを生産的にするバランスを保つ ◦ 全体最適＝分割前の課題を解決するということ ▪ 経営やCxOレイヤーの人たちが何を狙いにしているか理解し意思決定 ▪ 意思決定と実行を他チームにも波及させるようにする ◦ 個別最適 = 全体最適を意識し自チームのエンジニア組織に権限委譲・生産的にする
17. エンジニアリングマネジメントの難しさ -これまでの経験を言語化して- 17 • これまでの話は悲観的すぎるでしょうか？一部頷ける点もあったのではないでしょうか • EMのみなさん「マネージャーのアウトプット」を最大化できていますか？ ◦ VP, CxO, 経営層のねらいを理解し、各部署・マネージャーが横断して、全体の生 産性を意識して行動できるようマネジメント業務にあたれているか ◦ 逆にエンジニアが活動した成果が、経営のどこに結びつくか理解できるか ◦ それらを支える、テクノロジー・プロジェクト・プロダクト・ピープルマネジメ ント (EMの4領域) の能力を駆使できるか • 競合が成長していくなか、これらスキルやマインドセットをいち早く獲得できますか？ 組織が成熟するにつれて上記のような成果や能力を求められてくる段階があるはず それだけミドルマネジメントは自律性・視野の広さが必要で、難易度が高い
18. 02 | 弊社のこれまでの組織体制・EMの役割
19. 弊社プロダクト「Chatwork」 ※※Nielsen NetView 及びNielsen Mobile NetView Customized Report 2024年4月度調べ月次利用者（MAU:Monthly Active User）調査。 調査対象はChatwork、Microsoft Teams、Slack、LINE WORKS、Skypeを含む41サービスを株式会社kubellにて選定。 効率的に情報共有できる グループチャット 仕事の見える化ができる タスク管理 見落としがなくなる ファイル管理 いつでも会議ができる ビデオ/音声通話 19
20. 従業員数は500人超+ 20 25人 25人 56人 77人 89人 91人 107人 162人 251人 312人 589人 2011/3 法人化 （設立） 13人 Chatwork リリース 2015/4 シリーズA 3億 2016/1 シリーズB 15億 マザーズ 上場 2004/11 2005 2008 2011 2015 2016 2017 2018 2019 2020 2021 2022 2023* *2023年度からグループ従業員数 2024/12 461人 上場時の5倍を突破、順調に組織は拡大している
21. チャットサービスに留まらず、多角的な事業として展開予定 BPaaSで業務提供 ドキュメント 管理 Web会議 タスク管理 プロジェクト管理 ストレージ エンゲージメント SaaSで業務効率化 CRM/SFA BPaaSで業務提供 人事評価 採用 電話代行 勤怠管理 労務管理 様々な経営支援 コアビジネスに注力できる環境 資金調達 助成金 請求管理 契約管理 決済 会計 福利厚生 ビジネス上発生するあらゆる業務をチャットを起点として解決・支援する形へ プロダクトとしてさらなるグロースが必要 21
22. 多角的な事業を展開するための組織体制 ※2025年1月時点 組織は役割・機能別に大きく7つのディビジョンとCxO直下の横断組織で構成されています 22 BPaaSディビジョン コミュニケーションプラットフォーム 戦略を推進。「Chatwork」アカウン ト事業の開発部門、セールス部門のほ か、BPaaS事業も含めた横断のマーケ ティング部門などが所属 コミュニケーションプラットフォーム ディビジョン インキュベーション戦略を推進。 R&D、事業開発部門のほか、データ推 進を担う開発組織などが所属 インキュベーションディビジョン BPaaS戦略を推進。BPaaS事業の開発組 織、セールス部門のほか、グループ会社 のコーポレート部門などが所属 カルチャー＆ブランド ディビジョン ピープル ディビジョン 経営企画 ディビジョン コーポレート ディビジョン 採用、育成、HRBP、労務 などの人事部門が所属 人材開発、カルチャー推 進、広報・ブランディング などの部門が所属 法務、総務、経理財務、 コーポレートIT、セキュリ ティなどの部門が所属 経営企画、IR、投資・アラ イアンスなどの部門が所属
23. 「Chatwork」プロダクト成長を担うこれまでのエンジニア組織の体制 23 • Feature Team: 事業価値を創出 • Platform Team: Feature Teamの認知負荷を 下げる職能別チーム • People Management Team: 横串でピープル マネジメントを担当 参考: https://findy-code.io/engineer-lab/dev-productivity-con-chatwork EM=マネジメント対象者が多い代わりに ピープルマネジメントに閉じた役割に近い DevOps を実現するための「Feature Team」 体制 (≠ team topology)
24. 本体制でEMがピープルマネジメントに特化したことのPros/Cons 24 • Pros ◦ EMのリソース効率が良く、1チームに対して複数人でマネジメントができる ◦ チームの自律性を促進できている ▪ 結果、複数施策もリリースし成長できてきた • Cons ◦ プレイングやEMの他領域のマネジメントスキルを獲得したいニーズに応えること が難しく、同時に採用の難しさもある ◦ ピープルマネジメントに傾倒しすぎると、事業戦略とEM (≒ 各部署) の戦略紐づけ が不明確になりやすい状況が一部発生した ◦ 組織全体の責任と権限の不明瞭化 ▪ プロジェクトのマネジメントを誰がやる・PdMの責任がどこまで , etc.
25. 私達も「エンジニアリングマネジメントの難しさ」に直面している 25 「持続的に生産性が上げられる開発組織づくり」をテーマに、VPoEとEM全員で解決すること を意思決定し、「エンジニアリングマネジメントグループ」創設へ 「Chatwork」 プロダクトは既にリリースから14年も経っている 多角的な事業成長をしていくうえで「持続性」のある成長が必要 一過性の組織づくり・一過性の成果や生産性では持続的なグロースは果たせない マネージャーとして、組織のガバナンス統一・全体最適を意識し、持続的に生産性が あげられる開発組織づくりをしたうえで、経営に対して成果を示す必要ありと判断
26. 03 | エンジニアリングマネジメントグループ について
27. 「エンジニアリングマネジメントグループ」テーマとコンセプト 27 1. 上位戦略と接続した戦略設定・組織運営 2. 経営からエンジニアまでの生産性を接続し 開発活動を有用化する 3. 開発者体験を向上させる テーマ 「持続的に生産性があげられる組織づくり」 コンセプト
28. EMグループとしてのエンジニアリングマネージャーの役割定義を再考 28 ビジョン実現の推進 人材管理 生産性向上 プロセス改善 技術戦略策定 環境整備 カルチャー醸成 組織のビジョンを理解し、他部門も巻き込みながら組織全体が それらの達成に向けて行動するよう促す エンジニアの採用・育成・目標設計・評価・キャリアパス形成の サポート及びチームのコンディション・エンゲージメントの向上 生産性指標の定義とマネジメントを行い、事業目標との整合性確保 デリバリー速度・品質・価値の向上を目指し、開発プロセスを最適化 生産性向上のための職能ごとの技術戦略の策定とコミットメント エンジニアの創造性が発揮されやすい開発者体験の良い環境整備 組織のMVV (ミッション・ビジョン・バリュー) に基づく文化醸成
29. エンジニアリングマネジメントグループの体制 29 Before After • 各職能ごと1名EMをつける ◦ ポテンシャル登用あり • EMの複数チーム管轄を撤廃 ピザサイズ程度に • EM全員+VPoEのグループ
30. 「共創型エンジニアリングマネジメント」とは 30 共創 = EM + VPoE全員で個々の強みを活かしつつエンジニア組織の課題に取り組む 3⃣ 進捗を適宜共有しながら、合意形成 をしていく 1⃣ テーマ・コンセプト・役割から、解 決したい抽象的な課題を提起し優先順 位と担当を決める 2⃣ 担当EMのペアが課題を具体化しなが ら、合意形成するための材料を用意 4⃣ 上記を経て具体策の実行し、これら の活動は目標設定と評価に入っている
31. 「共創型」のマネジメントスタイルの特徴 31 • 対話と協力の重視 ◦ EM全員が積極的に意見交換・協力し相互に補完 することで問題解決や目標達成を目指す • 共同責任 ◦ VPoEや特定EMだけでなく意思決定の責任は全員 • エンパワーメント ◦ 組織として解決したい複数の課題から担当の課題 を選び、その解決業務も担う ◦ EMとしての役割拡大・スキル獲得も担っていく 共創 = EM + VPoE全員で個々の強みを活かしつつエンジニア組織の課題に取り組む
32. なぜ「共創型」としたのか 32 • 各EM内の局所最適化・サイロ化を抑えるため ◦ 専門性が高い故に専門領域に閉じやすく組織が硬直化する、EMどうしのクロス 1on1などあっても、各々できる範囲での取り組みになりがちになる • 課題によっては全体を巻き込んで解決必要なものがあるため ◦ 例: 開発生産性や信頼性の設計、開発プロセス標準化など • EMの役割・マインドセット・獲得するべき能力の標準化のため ◦ なぜ我々が存在しているのか、役割やエンジニア組織のあり方含め考え方の浸透と 能力を標準化
33. 改めてエンジニア組織のビジョンを再考・策定 33 • エンジニアの集合知が集約され戦略や施策に導入されている状態 • エンジニアの創造性が発揮されている状態 • エンジニアのプロダクト参加意識が高まり、プロダクトの自分ゴト化がされてる状態 • 事業戦略・プロダクト戦略とアラインされはじめている状態 • ユーザー体験価値、デリバリー速度・品質・価値の向上が進みはじめている状態 • 開発施策の意思決定機関化や意思決定プロセス化が運用されている状態 • エンジニア組織のワークエンゲージメントが高まり、パフォーマンス向上がされはじめ ている状態 • 開発生産性指標が導入され、合理的かつ生産性高い活動が進みはじめている状態
34. 04 | 「共創型エンジニアリングマネジメント」 による取り組み事例とふりかえり
35. EMグループによる取り組み方のプロセス 35 • 何を始めるにしても、事前の「合意形成」までがとにかく大事 ◦ 状況・背景確認: 現状わかる範囲での確認や他部署や人から教えてもらうなどして、 制約条件・その時の事情など時系列や背景含めた現状理解 ◦ 課題提起と改善提案: 現状の課題や改善事項を明確化したうえ、課題に対する具体的 な解決策を提案する ◦ 合意形成: 上記をもって共通認識を形成したうえ、複数の選択肢から評価し、妥協点 を探しながら関係者全員の合意を得る
36. 事例①: エンジニア組織体制変更
37. 事例①: エンジニア組織体制変更 37 • Feature Team 体制により、システムとチームを紐づける想定で進めてきた • その結果、一定施策のリリース・プロダクトへの価値貢献ができている • とはいえ以下の問題もあらわれてきた ◦ 戦略の進捗と組織がリンクしづらい状況も出てきた ▪ それだけ現在のシステムが組織構造とあっていないことがわかってきた ▪ チームで閉じた開発をすることで素早く価値提供することを想定していたが、 複数コンポーネントに手をいれる必要がわかってきた ◦ 採用難化 (一部チームがフルスタックエンジニアに近しいため人員増加が難しい) • EMグループ組成・役割変更と合わせて、より価値の高い組織のあり方が検討できそう
38. 事例①: エンジニア組織体制変更 38 • 現時点ではFeature Team 体制を廃止し、あえて職能ごとの組織へと変更する ◦ 部署を戦略が作れる単位で分けていく ◦ 経営 - エンジニア組織 - 各部署で戦略と目標がきちんとリンクするようにする ◦ と同時に、横断的な取り組みができるよう組成を考える必要がある ◦ 職能単位でEMをつけ、EMの役割も変更し、1チーム6-8名ずつの組織を目指す
39. 事例①: エンジニア組織体制変更 39 [1] サーバーサイドの「部署を戦略が作れる単位で分けていく」には？ • 特定のドメインや言語に縛られず、役割とキャリアを拡 張していくことで成長促進・サイロ化防止 • 共通の戦略を設定して、各チームで追っていく形へ • モノリスなシステムを徐々にコンポーネント単位分割を 進めていきつつ、知識獲得と生産性向上をねらう ◦ モノリスが解消でき次第チーム組成は再度行う ▶ 各ドメインのメンバーを均等にし、1チームあたりの　 サイズをならして組成し直す形で合意形成
40. 事例①: エンジニア組織体制変更 40 [2] webとモバイルの「部署を戦略が作れる単位で分けていく」には？ • 機能開発と基盤整備のチームを統合・職能ごとへ ◦ 一貫したユーザー体験の提供がしやすい • BFF (GraphQL) も一緒のチームに加える意思決定 ◦ 各PFに適したAPIを設計・開発 ◦ パフォーマンスや使い勝手の向上をねらう • 良い意味でサーバーサイド側の「関心の分離」 ▶ 今後UI/UX体験向上を横断で担うことを前提の組織として合意形成
41. 事例①: エンジニア組織体制変更 41 横断部署や単一コンポーネント担当の特定ドメインチームは続行とし、最終的に以下の設計
42. 事例①: エンジニア組織体制変更 42 • 成功したこと ◦ コミュニケーションパスがシンプルになり、チーム横断で連携もとりやすくなった ▪ キャリアパス、獲得するべき能力のすり合わせがしやすくなった ▪ 職能ごとの採用 ◦ 上記合わせ、体制変更にかけたコストよりもメリットが上回ると体感している • 課題となったこと ◦ 新組織に伴う異動手続きが想定以上よりも遅れた、それだけエネルギーが要ること ▪ 組織構造を変えるにあたって全社としての手続きもあった (組織図反映など) ▪ 意思決定をもとにした行動も適宜ロードマップや締め切りを設定する必要性
43. 事例②: 開発プロセス標準化
44. 事例②: 開発プロセス標準化 44 • エンジニア組織と別にプロダクト組織がある (PdM, デザイナー, CSなど) ◦ 然るべき会議体で定点観測や適切な承認プロセスが整ってきている • 両組織の悩み ◦ 事例①と合わせて、プロダクト側の戦略に則ったエンジニア組織ではない ◦ 事例①と合わせて、開発する際に複数のコンポーネントにまたがる問題があり、 どこがオーナーシップを持てば良いか不明確な状況もみられた ◦ 既存のFeature Teamでカバーしきれない施策のアサインが難しい ◦ 明確なPjMがいないこともあり、どこまでのプロセスに介在するのかお互い遠慮 することもあり、チームや施策によって役割の差がでてしまっている
45. 事例②: 開発プロセス標準化 45 • 職能型組織再編とともに開発プロセス刷新 (コミュニケーションパスの設計が重要) ◦ PjM役をEMが担当し、各チームのコミュニケーションを担う • エンジニア・プロダクト組織とともに開発プロセスを明示化し、意思決定プロセス含む 開発の流れについて開発関係者が共通の理解を持つ ◦ エンジニア組織とプロダクト組織がお互いどこまでのプロセスに介在するのかはっ きりさせる • お互いのやり方を抜本的には変えず、段階的に変えていくことを前提
46. 事例②: 開発プロセス標準化 46 複数部署に跨る施策の共通プロセス策定と共通バックログの作成更新・優先度決定をする • プロダクト組織 ◦ 要求・優先度決定・PRD作成をもってエンジニア組織とどう取り組むか決定 ◦ 施策がはじまったら要件定義・仕様調整・デザイン作成など行いリリース日決定へ 開発プロセスの概念図
47. 事例②: 開発プロセス標準化 47 • エンジニア組織 ◦ 職能グループごとに設計開発・FBを受けての修正 ◦ EMがPjMとしてエンジニア組織の計画・進捗・PdMとのマネジメントを担う ◦ ボトムアップで運用保守で必要な案件があればプロダクト組織側へEMと一緒に提言 開発プロセスの概念図
48. 事例②: 開発プロセス標準化 48 • エンジニア組織・プロダクト組織の取り組みを接続する複数会議体の設置 ◦ PdMとEM (=PjM) による施策提案・進捗共有・優先度決定の会議 (適宜) ◦ エンジニアの職能グループ全体で横断した情報共有の会議 (週次) ◦ 施策単位のPdM/EM/エンジニアによる会議を合意のもと設定 (適宜) 開発プロセスの概念図
49. 事例②: 開発プロセス標準化 49 • 成功したこと ◦ エンジニア組織とプロダクト組織がお互いどこまで介在するかはっきりしたことで、 今どこが待ち状態かわかり、それを支える会議体・可視化も進んできている ◦ 経営層に対して何が課題で進んでいないかEMやVPoEも説明できるようになった ◦ プロジェクトマネジメントもEMの役割として拡張してきている • 課題となったこと ◦ 言葉の認識ズレが発生、例えば「見積もり」でほしい価値が職種ごとに違う ▪ ユビキタス言語や求める価値を認識合わせつつ、メンバーにも周知していく ◦ このプロセスが妥当かの評価指標まで定めきれていない、引き続き要改善
50. 「共創型エンジニアリングマネジメント」を実践してみて 50 • 今日説明した他にも事例は様々あります • 事例もふまえ、どういうとき「共創型エンジニアリングマネジメント」はより機能する？ ◦ 職能ごとEMを跨ぐことでより生産的に解決でき、一方で現場とギャップが生まれな いようにしたい課題が複数ある場合 ▪ エンジニア組織からボトムアップで何かを経営に対して提案したいとき • 制度面の充実やエンジニアのキャリアパス・ラダー形成など ▪ 全社の制度が変わる際にエンジニア組織としてどう解釈するか決めたいとき ▪ 職能ごと共通の課題が見いだせており個別でなく全体で対応したいとき • 小さな課題でも深堀りしてみると、他職種や部門を超えて解決したほうが よりよい形ということもある ◦ VPoEやCTOが課題を持ちすぎてしまって解決に時間がかかってしまう場合　 ◦ 各EMとVPoEの目線が揃っていない・各EMのスキルに差がある場合
51. 「共創型エンジニアリングマネジメント」を実践してみて 51 • 合意形成が想定通りうまく進まない場合もあった ◦ 状況・背景理解や課題・改善提案がズレすぎていることが原因 ▪ 真に求めているのはコレじゃない・以前それはやったという返しはよくある ▪ As-Isを深堀って理解したうえ、期限を適宜設けながら、段階を踏みつつ合意 形成・改善の必要がある • 持続的に生産的になっているかどうかの定量・定性評価は必要 ◦ やりやすくなったという声はいくつかあるが妥当性のある評価までは至っていない ◦ 取り組みがうまくいっているか経営にもわかるような材料が必要 ▪ 鍵は経営からエンジニアまでの「生産性」の定義と可視化 ◦ EMとして主にプロジェクトマネジメント・チームマネジメント・エンジニア組織 として共通課題を解決すること、これらの負荷バランスを考えないといけない ▪ 使っている時間や負荷も集計・可視化したうえでの評価は絶対必要
52. 05 | 皆様へのメッセージ
53. EMConf JP 2025の「テーマ」を覚えていますか？ 53 EM ConfJP 2025より抜粋: https://2025.emconf.jp/
54. 54 • 組織が拡大していけば一定「負の増幅」がなされるかもしれない ◦ サイロ化・組織の硬直化 ◦ 無知・無視・無関心 ◦ 意見対立・責任転嫁, etc. • 人が増えれば「増幅」されるわけでもない (パーキンソンの法則) • 「負の増幅」をできるだけ抑えながらも、同時に個々の生産性を上げる必要がある ◦ ≒「正の増幅」
55. 55 • 「正の増幅」をするのがEMのおしごと ◦ カルチャーやマインドはじめ組織熱量を上げる ◦ 生産性を相互に高め合っていく ◦ 会社の方向性にアラインさせる • 大事なことは「全体最適」 ◦ 解決したい課題が上段・横断が必要と気づいた ◦ その上で「共通認識」と「合意形成」が必要 • 私たちは「共創型マネジメント」で解決しようとしています ◦ 私たちが「触媒」になり組織の熱を広げ、EMスキルをより獲得し、正の循環を
56. 質問です。みなさんは、 • EMの役割をメンバーが理解できていますか？ • 隣の部署・チームの戦略・目標がわかりますか？ • 最近経営層と話したのはいつですか？ • 最近入社した人はどこのチームに属しましたか？ • 実は同じ取り組みを他の部署でもしていませんか？
57. 57 「どのように熱を広げていくか」は考えなければいけません そのためには、自組織がどのような段階にいるか認識すること 組織的な課題解決策が次の組織的課題の要因となることを認識することです 私たちの場合はいまは「共創」することが良いと判断しました 各々のやり方で、私達の想いを全エンジニアにくべていきましょう 熱量はより広がっていくはずです