エンジニア組織のデザインパターン
エンジニアリングマネージャー（EM; engineering manager）にまつわる最大の課題はなんだろうか、それはエンジニアはそのキャリアにおいて、別にマネジメントをやりたいわけではないということだ。実際、トッププレーヤーであることとマネジメントを両立するのはほとんど不可能である（プロスポーツの世界を考えればわかる）。
これはエンジニアリングマネージャーの採用はエンジニアの採用よりも難しいというさらなる困難も引き起こす。マネージャーは必要ない？エンジニアリングマネージャーがいない状態とは、それはエンジニアではないマネージャーがエンジニアを管理している状態だ（これはおそらく望んでいない事態だろう）。
エンジニア組織のデザインを考えるとき、こういう話は避けて通れないが全くやりようがないわけではない。本稿では、いくつかの典型的な組織のパターンとともにこの問題を考えてみよう。
Pure hierarchy
とりあえず最初はクラシックな組織を考えてみる。
経験を積み能力が上がればポジションが上がる。わかりやすい。わかりやすいがこの組織にはわかりやすい問題もある。
プレーヤーとしてのキャリアパスが存在しない
マネジメントのスキルはエンジニアのスキルではない
かくして優秀なエンジニアは組織から去っていくのだった。
Pure flat
次は真逆の組織を考えてみる。マネジメントをやりたくないならマネージャーをなくしてしまえばよいのだ。そもそもなぜスタートアップに上下関係が必要なのだ？
上のポジションはCTOでもCEOでも取締役会でも何でも良いが、ここではCTOとしてみよう（株式会社ではメンバー全員が株式を均等に所持しているという状況でない限り完全なフラットは無理だ）。
この組織の問題もわかりやすい、それは極端に負荷が大きい箇所が一つあることだ。誰が見てもわかるくらいにfat controllerで、ボトルネックで、SPOFな箇所がある。CTOがマネジメントを放棄するという手段もあるがこの場合、n(n-1)/2の依存関係が生まれる。nが小さいときは良いが大きくなると地獄へ一直線だ。
Role-based hierarchy
クラシックな組織のなにが問題なのだろうか？プレーヤーとマネージャーは仕事が違うということだ。そうであるなら、プレーヤーとマネージャーを分業すれば良いのではないか。
これは自然である。プロスポーツの世界でプレーヤーとマネージャーを兼任することはほとんどない。
これで問題は全て解決しただろうか？残念ながらそうはならない。
組織の意思決定は以前としてヒエラルキー構造をもつ。これはトッププレーヤーの貴重な能力が組織の意思決定に反映されづらいことを意味する。
エンジニアリングマネージャーの採用が困難であることをなにも解決しない。採用が無理なら自前で用意すればよいが、プレーヤーとしてのキャリアパスがあるためマネージャーとしての訓練を積むことにインセンティブがない。また、「すでに席が埋まっていてマネージャーとしての訓練を詰めない」か「マネージャーが足りなくマネジメントが壊れている」という状態になりやすい。
Office of CTO
重要な意思決定の近くに特務的な部署を作ったらどうか。
組織にL1 cacheを導入するのだ。CTOがいる組織ならこれはCTO室と呼ばれることが多いだろう。これによって先の問題に対処する。
トッププレーヤーの能力を意思決定に反映しやすい、また逆に重要な意思決定をトッププレーヤーに反映しやすい。
エンジニアリングマネージャーを「バッファ」できる。メンバーのいないマネージャーを置いても良いし、訓練が必要なマネージャー候補を置くこともできる。
問題は先のフラットな組織と同様にCTOがfat controllerになりやすいことだろう。
Office of engineering management
これまでプレーヤーとマネージャーを縦に分けたが、これは縦である必要があるのだろうか？横に分けても良いのではないか。
例えば、総務とか人事のような管理部門は普通は横に分けるだろう、これも同じ発想で、CTO室の役割を分割して部署とする。
これは良い構造だと思うが、組織が（最初のクラシックな組織と比べても）複雑化することと、小規模なスタートアップでこれを実現するのはおそらく無理だろう（そんな人的余裕はないだろう）ということは考える必要がある。
Lightweight manager
そもそもなぜ多くのエンジニアはマネージャーになろうとしないのだろう。
技術が好きでエンジニアになったのであって偉くなりたいわけではない
ずっと手を動かしたい、マネジメントと開発を両立するのは無理
マネジメントをやっていると腕が落ちる、プレーヤーとして死ぬ
人事は面白くないし大変なことが多い
なるほど。ということはプレーヤーとして問題が出ない程度にマネジメントの負荷を落とすことができればマネージャーになっても良いはずである。
20人のメンバーの面倒を見ろと言われたら嫌だろうが、1人か2人の面倒を見ろと言われたら大抵のエンジニアは了承する（誰もが後輩の面倒を見た経験を持っているはず）。
マネージャーの責務を小さくし、明確にし、登用のハードルを下げ、管理するメンバーを少なくするのだ。しかもこうすることで「相談できるマネージャー仲間」も増えるから負担はさらに小さくなる。
Rolling manager
エンジニアリングマネージャーの有用なプラクティスとして、プレーヤーとマネージャーのキャリアを行ったり来たりすると良いというのがある。これを組織に組み込もう。
マネージャーを時限付きの持ち回りにするのだ。これはマネージャーの仕事を時間的に軽量化しているとも言えるし、プレーヤーにマネジメントの経験を積ませているとも言える。
これを突き詰めるとメンバー全員がマネージャー経験者になるからマネジメントの負担はさらに小さくなり、マクロに見るとフラットな組織になる。
おわりに
ソフトウェアのデザインパターンと同じで組織デザインにも「よくある型」があり、多くの失敗とプラクティスがあり、流行り廃りがある。問題を完全に解決するわけではないが知っておけば役に立つことはあるだろう。