SpecteeでVPoEをしております、おーのAです。

エンジニアリング組織の組織マネジメントに携わり始めて2年が経過しました。組織を大きく変化させていきたい気持ちがありつつも、なかなか大きく進むことができずに、難しさを感じる2年間でした。
そんな中での学びをまとめていきたいと思います。

組織変革における課題：組織マネジメント観点でのマネージャー間の連携の難しさ

各チームの状況の把握は必須です。ここにはいくつかの課題があります。
特に、各マネージャーが独自の方法で各チームの運営を担っている状況について話していきます。

チーム文化の違いから情報共有が希薄になる

第一にチーム文化が違うと情報共有が希薄になるという問題です。
ここでは、各チームが個別最適に独自の開発プロセスで開発している場合を想定します。

各チームが独自のマネジメントをしていると、チームの運営自体がブラックボックス化されてしまいます。ブラックボックス化し、透明性が低い状態だと、マネージャーは以下のような考えに陥りがちです。

• チームの組織観点での情報共有しても建設的な議論にならないと考える

• 情報共有しても他のチームのマネージャーは打ち手を考えにくいため共有することに価値を感じない

透明性の低い状態ではこのような考えが自然と起こります。結果的に組織マネジメントを担う人はチームの課題を抽出することが難しくなり、組織全体を観測することが困難になります。

議論が技術・プロダクト観点になる

第二に、議論が技術・プロダクト観点になりがちという点です。特に緊急度の高い顧客対応の話になりがちです。
各チーム運営に課題意識があったとしても、目の前の緊急度の高い課題に対する議論が多くなります。あるいは、そもそもマネージャーによってはプロダクト観点での問題が解決できれば良いと思っている人も一定いるでしょう。このような状況では、組織マネジメント観点の議論に至ることが難しいです。

一方でTeam Topologiesでコンウェイの法則で語られているように、プロダクトのアーキテクチャは組織構造に依存します。技術・プロダクト観点で本質的な解決に導くためには組織構造にも積極的に関与していかなければなりません。

役割と責任の曖昧さゆえに論点がずれる

組織が変化の過渡期であれば、マネジメントは特に役割と責任が曖昧になりがちです。
エンジニアリングマネージャーという役割は、10社あれば10種類のパターンが存在するくらい曖昧な役割です。
当然、文化が異なるチームをマネジメントしているエンジニアリングマネージャーは役割も責務が曖昧になります。

広木さんの紹介するエンジニアリングマネージャーの4つの役割のうち、役割としてどの領域を広くカバーしているエンジニアリングマネージャーであるかによって、どの領域を強く意識しているか異なります。

各エンジニアリングマネージャーが異なる関心領域を持った状況で組織マネジメントの観点で議論をしようとしても論点がずれてしまうのは当然とも言えます。

組織をStep by Stepに変えていこう

私の好きな書籍Fearless Changeのパターンの一つでもあるStep by Stepですが、組織を変えていくことで最も重要なパターンの一つだと考えています。

組織を変えていく上では他社の状況などを参考にし、良いプラクティスを素早く導入していきたいと思いがちです。しかし、説明不要なほどに、大抵難しいです。自身の組織の状況に基づいてStep by Stepで進むほかありません。
私が取り組んできたことに基づき述べていきます。

Step by Stepで開発プロセスの共通化を進める

各チーム文化を寄せていくためのステップとして、まずは開発プロセスの共通化が考えられます。幸いなことに近年ではスクラムなどの開発プロセスを定義したフレームワークがあります。

共通した開発プロセスを用いた場合のメリットをいくつか挙げておきます。

• 全てのチームが同じ用語や概念を共有でき、誤解や混乱を減らすことができる

• プロジェクト/プロダクトの進行状況や問題点が明確になる

• 組織全体で効果的なベストプラクティスを探索できる

• 共通のプロセスを用いることで、メンバーやマネージャーの育成計画も立てやすく、成長に対して頑健になる

私自身は組織にスクラムを導入していきましたが、これらのメリットを得られています。

ここから本項の本題ですが、開発プロセスを変えていくことはパワーが必要です。現在弊社ではスクラムを導入しているチームは5チーム/6チームですが、スクラムの導入を始めてから2年が経過しています。

トップダウン的に素早く導入することも可能ですが、スクラムは自己組織化されたチームを形成することが重要であり、トップダウンで変化を加えることで自己組織化を阻む場合もあります。

組織に新しいプロセスを導入するということは、まさにFearless Changeな取り組みが必要であり、一歩一歩進むほかありません。

Step by Stepで役割と責任を明確にする

マネージャー間の連携が難しいのであれば一つ一つ解決していくしかありません。組織マネジメントを担う役割であれば、マネージャー間の連携をできるようにすることも同様に重要です。しかし、役割と責任が不明瞭な状況では連携を強めることも一定の難しさがあります。
役割や責任の範囲が曖昧であるなら、明確に提示すれば良いと考える人もいるかも知れませんが、多くの場合、簡単ではありません。

例えば、プロダクトマネジメントの比重を高く担っているマネージャーに「エンジニアリングマネージャーとしてピープルマネジメントとテクノロジーマネジメントに比重をおいてほしい」と伝えたとしても、プロダクトマネジメント誰がやるんだ問題が起こります。他の人を立てれば良いかというと、それも簡単な話ではありません。採用するか内部から育成する必要があります。しかし、採用や役割の変更は一朝一夕には実現できません。

組織マネジメントを担う存在として、人に変わってもらうことを期待するのではなく、チームに必要な人材を見極め、採用戦略や育成戦略を立ててStep by Stepで進んでいくしかありません。

（※必要人材を提示することもエンジニアリングマネージャーの役割ではないの？という話もあると思いますが、今回は役割と責任を明確にできていない前提ですので、本記事では割愛します）

Step by Stepで緩やかに組織構造を変えていく

時には組織構造を変えていくことも必要になると思います。
幸いなことに開発プロセス同様、組織構造も世の中にSpotifyモデルやTeam Topologiesといったプラクティスが存在しています。

私は現時点ではTeam Topologiesを参考に組織構造を描いています。素早く価値を顧客に提供するために各チームをどのチームタイプで割り当てていくか、どのようにX as a Serviceのコラボレーションモードを作っていくのかを意識しています。

しかし、組織構造を変えていくことも同様に難しい問題です。
チームを適切な範囲にしようと変化を加えようにも、マネージャー不在になったり、プロダクトオーナーが不在になるような状況も起こります。

ただ、私は適切な範囲であるなら、複数ロールを担わざるを得ない状況であったとしても、構造を変えた方が良いと考えています。あえて複数ロールを持つ状況を作っていくことで、必要人材も明らかになり、採用計画や育成計画を考慮しやすくなります。

組織構造も各チームの状況を観察しながら緩やかに一歩一歩変化させていくことが重要です。

まとめ

この2年間EMを経てVPoEとして組織マネジメントに携わって感じていたマネージャー間の連携の難しさを整理し、緩やかに組織を変えてきたことについて述べました。
あまりまとまりない感じになってしまった気もしますが、どこかのチェンジエージェントの心の支えになれば幸いです。

最後までお読みいただきありがとうございました。