日本のソフトウェア企業でよく見るエンジニア組織の構造と、近年推奨されるエンジニア組織の構造について
はじめに
恥ずかしながらスクラム開発の開発チームへの導入を何度も経験しているのだけれど、どうしてもチームの成熟レベルが高い位置までもっていくことができませんでした
なぜうまくいかないのか？
これを深掘りする過程で教科書どおりに実行するには組織の構造がスクラムガイドで書いてある構造と根本的に異なっているのではないか？と考えるようになりました。
よくあるエンジニア組織の構造
大きめのWebソフトウェア企業の内製型エンジニア組織の構造はだいたいどこもこのような感じになっています
この組織構造の問題点
スクラムを導入する場合、リーダー自身かあるいはメンバーの一人がスクラムマスターとなります
リーダー自身がスクラムマスターになる場合でもアンチパターンと言われる開発者との兼任になります。
スクラムマスターの最も重要な職務である「観察」が行えなくなります。
スクラムマスター自身が観察を行わない場合、各メンバーが「観察」した内容にすべてが頼りきりになります。
つまり時間的余裕がなく、洞察力と知識と経験に劣るメンバーの乏しい「観察」によって得られるインプットを元にチームの「改善」が行われるわけです。
プロダクト投資はともかく、チームへの投資は恐ろしく効率が悪いものとなるでしょう
リーダー自身がスクラムマスターにならない場合
リーダー自身がスクラムマスターにならない場合はもっと問題が深刻です。
スクラムガイドにおいては３つのロールが定義されています。
プロダクトオーナー、スクラムマスター、開発者です。
（このうちプロダクトオーナーはチーム内にいる必要はありません）
スクラムガイドにない役職であるリーダーとスクラムマスターの二重権力が発生します。
多くの場合利益相反した場合はスクラムマスターが抑えられ、リーダーが勝ってしまいます。
せいぜいスクラムマスターにできる仕事は、ファシリテーターレベルになるでしょう。
この状況の問題
これはアンチパターンというレベルではなく、守破離の「守」もまともにできていないことになります。
スクラムチームがまともに機能することを期待するほうが間違いでしょう。
導入程度で満足していいのであればそれでも良いのですが……。
近年正しいとされている組織構造
Amazonの2枚のピザ理論、スクラムガイド、エンジニアリングマネージャーのしごと
どれを見てもこのような構造にすべきと書いてあります。
スクラム開発だろうとそうでなかろうと、EM1人＋IC6~10人が推奨される、としています
しかしこのやり方は浸透していない
例えばスクラム開発の場合、スクラムガイドという一番守るべき「守破離」の「守」の教科書的な部分にそういう構造にしろと書いてあります。
（他はそこまでがっちり書いてないし、教科書でも「守破離」の道も示されてないから一番うるさくやり方を指図するスクラムを例に採用）
スクラムの「守」を始めたいのであれば、このチーム構造に組織を改変する必要があります。
もちろんEMはスクラムマスターとして機能できるだけの経験と知識と視座、権限が必要です。
認定スクラムマスター研修(例えばこういうの)を受けて、名刺に認定スクラムマスター資格のかっこいいロゴを刻めるようになっただけでは全く不足であることは言うまでもありません。
CSM資格を持っていてもこの構造を守らないことは、「守破離」の「守」をせずに「離」を始めていることになります。
伝統的なエンジニア組織の構造の長所
先ほどの図のような組織構造には長所があります。
経験の浅い人間でもワークする点と、それによるスケーラビリティです。
- マネージメントする人数が少ないので、人事評価が高い者＝優秀なプレイヤーを抜擢しやすい
- 進捗が遅れたら一番馬力のあるリーダーが最初に気付けるので巻き返しやすい
- 間接統治になる分、EMのマネジメント負荷が低いのでEMの経験が浅くても回る
これらがあるために組織としてのスケーラビリティが高いのが長所です。
スクラム開発の導入との相性の悪さ
ただしスクラム開発には向きません。
観測範囲では以下の問題が出ます
- 過小なチームサイズ
- チームの権限の不足
- SMに徹する人材がいない＝観察を誰もしない、せいぜいファシリテータレベルの仕事しかできない
- 権限、経験、視座、知識の不足した人材しかSMにできない
私の考え
進捗をバリバリ出す＝アウトプット重視のやり方であれば前者のやり方でもいいかもしれません。
しかし近年マネジメントの良いノウハウやベストプラクティスが出てきており、そのやり方を取り入れたいのなら後者のチームの自律性が高いやり方のほうが適していると考えます。
なにより大事なのはこの点です。
Amazonの2枚のピザ理論、スクラムガイド、エンジニアリングマネージャーのしごと
どれを見てもこのような構造にすべきと書いてあります。
いずれも共通していると言うことは、これが「教科書に載ったベストプラクティスである」という認識がアメリカ西海岸ではあるのかもしれません。
海外のブログや書籍、カンファレンスの基調講演で「良いマネジメントのテクニックはXXだ」と言う場合、暗黙的にこの構造になっていることを要求される可能性もあり得ます。
いちどエンジニア組織の構造を決めたら変えられない
これは想像がつくと思います
エンジニア組織の規模が一定規模、おそらく５０人程度を超えたらもうあとは全てがその構造のまま拡大する形になってしまいます。
よほど大なたを振るわない限りこれは変えられず、そしてほぼ全てのケースにおいて大なたを振るう機会もリスクを負いたがる経営者も出てきません。
すなわち変更することは不可能です。
本当に変えられないの？
もしあなたが必要とする人材が必要とするだけ必要な分、即戦力人材がどこからともなく生えてくるのであれば問題ないでしょうね。
あるいは、社長が「ウオー！うちの組織構造は今Qからこうだ！」と四半期定例全社集会で絶叫すると、社員の何人かがピカッと輝いて必要なスキルが付与する感じの組織なら。
そのような会社は見たことがないのでそうはなりません。ですから問題はありません。
ヒラのメンバーは相対的には問題ではありません。
問題はマネージャー、そして組織の文化です。
伝統的な構造では能力の低いEMでも仕事が回る構造になっています。（それが最大の強みなので）
一方で近年推奨されている構造ではEMに要求される能力水準は高いレベルになっています。
しかもEMの人数が約５割増で必要になります。
質と量が大幅に増えますが、それを供給する体制をどこから持ってくるのかが問題になります。
仕事のやり方が大きく変わるのも問題です。
６〜１０人のメンバーを直接配下におさめてプロダクト/プロジェクト/ヒューマンをマネジメントできる専業マネージャーというものを伝統的な構造では育てていません。
高度なスキルを持たない人材でもスケーラビリティを確保するためのやり方だからです。
また「直接統治でマネジメントに専念すること」と「間接統治でマネジメントに専念＋直接統治でプレイングマネージメント」の転換は相応に難しいです。
プレイングマネージャーの何割かはヒラメンバーと「同列」になります。
これも降格と感じたり、権威勾配に悪影響は出るでしょう。
偉い人がエイヤッ！って組織構造を変えればできるんじゃないの？
できますが組織はしばらく大規模な混乱状態に陥り機能しなくなります。
しばらく経てば機能し始めるでしょうが、それがどれだけの期間かもわかりません。
機能し始めて成果が出るかも分かりません。
T2D3やYonYで数十%のARRの伸びを課せられている組織でそれができますか？
当然ARRの成長は鈍化させないか、あるいはステークホルダーを説き伏せて、です
その難易度を考えれば「理論上は可能だが現実的には投機的に過ぎる」と言えると思います。
一番の問題は組織の文化
自転車や原付が１８０度転回することと、大型トレーラーが１８０度転回する難しさはイコールではありません。
蜘蛛と巨像、水上バイクと巨大タンカー。
サイズや質量が大きければ大きいほど、取り回しには困難が生じます。
従来型の構造だった組織は今まで「間接統治でマネジメントに専念＋直接統治でプレイングマネージメント」に最適化して
- 人事目標やOKRの管理
- 人員育成や採用
- 指揮系統や会議体の整備
を行なってきています。
当然価値観も文化もすべてが従来型構造に最適化されています。
この最適化された組織と文化自体が新しいやり方と猛烈な摩擦を起こします。
今までのやり方を否定し、新しいやり方に変える。ルールを変更する。評価ルールが変わる。
今まで行われてきたことが越権行為になり、今までしなかったことをしなければならなくなる。
この難しさは経験したことのない人間には想像が難しいかもしれません。
@tokorotenさんがよくJTCについて話をしていますが、巨大組織にやり方を変えさせることには困難が生じます。
我々は後出しジャンケンができる
一時期SaaS市場を沸かせた、あるいは今も沸かせている某大手SaaS会社。
彼らはすでに「もう組織構造を変えられない」閾値を超えています。
彼らがエンジニア組織の構造を決めた時には、エンジニアリングマネージャーのしごともユニコーン企業のひみつも日本で出版されていなかったので当然のことです。
そして我々は後から出てきたよりよい知見をもとによりよいエンジニアの組織構造を決めることができます。
最後に
何も考えずに組織の拡大に対応しようとすれば、プレイングマネージャーを軸に小分けにした伝統的な構造に回帰するでしょう
なにしろ皆そのやり方しか知らないし、なによりそれが直感的だからです。
実行力と発言力、胆力に優れたエンジニアマネージャーだけが先進的でフラットなエンジニア組織の構造を採用させることができます。
追記
Q：なんで唐突に実在の社名出していたの？
A：「大手がそうしているんだからそれがデファクトスタンダードで正しいんだよ、俺たちもそうしようぜ」といわれるから。その発言に対して「なんで古いやり方に合わせようとするんだよバーカバーカ」と俺が言い返したいから
Discussion
こんにちは。興味深い記事ですね。
ひょっとすると言い回しの差なのかもしれないですが、「Dev: 開発者 ヒラのメンバー」と「IC: Individual Contributor 開発者やデザイナー」の間にはどのような差があるのでしょうか？
例えば、スキルレベル、職責などです。
特に、直ちに相互の置き換えが可能か否か、という事が気になっています。
私がコメントをしてから、記事の分量が倍ぐらいに増えました。個人的には一部回答が得られたと思っており、追記ありがとうございます。↑の質問の背景も含め整理させていただきます。
（コメント欄でこのような事を深堀りするのは望まれていないかもしれませんが）
全体的に、この記事の"結論"については個人的にはある程度同意しますが、「では我々は実際にどうするべきか」という事が気になっています。
＜同意できること＞
＜根拠を正確に確認はできないが、多分そうだろうと思うこと＞
＜よくわからないこと＞
私はスクラムは採用していませんが、チームの構造としては「近年正しいとされている組織構造」に該当するチームで働いていて、EMに近い立場で、かつ自分の開発チームのメンバーを集める権限があります。いわゆる事業会社の、一事業における開発チームの長です。
最近は特に開発を要する案件が増えていて組織を拡大する必要があり、まずEMを増やす必要があると感じていて、それが相対的にICよりも重要であるという事には同感でした。ただ、それと同程度という程ではないにしても、ICを集める事にも苦労しています。そのため、採用に苦労するために理想的な組織構造を選択できない場合がある という事を感じており、「後から出てきたよりよい知見をもとによりよいエンジニアの組織構造を決め」ようとしてもうまくいかず、それで仕方なくベストプラクティスから外れる組織構造を選ばざるを得ない事もあるのでは、と思ったりしました。
つまり、この記事の内容はそれ自体理想的であるとして、
というのが気になったことで、特にその中で一番気になっていたことを端的に書いたのが↑の質問でした。
長文失礼しました、もし気が向いたら本文に反映ください。
まず答えられないことを書きます
まず書かれていないことを読み取られているように感じます
私はICよりEMを増やすことが重要と書いた覚えはないです。
強いていうならICもEMも専業で全く別職種の仕事、というつもりで書きました。
上部構造に関しても同様です。
ある程度以上の規模になればEMの上には必ず何かしらの意思決定者や意思決定機関が存在しますし、レポートラインを形成しています。
採用に関してはこの記事のスコープ外です。
私なりの考えはありロジティクスの確保できるあてはありますがそれ自体は記事にすると数万文字になるので絶対にここには書きません。
次に答えられることを書きます
最低限、CTOの直属配下やVPoEクラスの権限は欲しいですね。
実績と信頼を積み重ねて「理解のある経営陣」に提案通して組織変革のトライする必要があります。
絶対にアンロックすべき項目として、権力と地位、組織構成の戦略策定への発言力の確保があります。
だからこそ「何やら忙しく動き回っているみたいだが、結局お前はこの組織をどうしたいんだ？」と他人に思われた時に、そのゴールをはっきりさせるためにzennで記事を書いているんです。
@shin_semiya
コメントありがとうございます！
読解力がなくすみません、私が
と書いたのは、以下の記述を受けての記述でした。
ヒラのメンバーは相対的には問題ではない、ということで、この記述を私は「組織を変えようとした場合に、IC/ヒラのメンバーについては相対的には問題ではない」と解釈しました。
また、
ここの部分から、この記事では（仮に組織の体制を変更しようとした場合には）質のよいEMをかなり増やす必要があるという事を書かれていると理解していました。
この２点を以って、（近年推奨されるエンジニア組織の構造を作っていく上では）「EMを増やす必要があると感じていて、それが相対的にICよりも重要であるという事には同感でした。」という記述になりました。
これについては誤解があったとすれば申し訳ありませんが、ただ私の興味の本質とはあまり関係がなく、かつ、おそらく私が元々思っていた事と「この記事で表現されていたが私が読み解けなかったこと」は似たような結論なのではないかと思ったので、一旦読み捨てて頂いて差し支えないかと思います。（書いておいて失礼かもしれません。すみません。）
上部構造については、この記事が何を伝えたいのかを私が読み解けずによくわからないこととして記載したものですが、これもあまり本質的ではないので（少なくとも私の一番の関心事ではないので）、こちらも読み捨てて頂いてよいかと思います。
採用に関しては、そうですね、私もこの記事が採用をスコープにしているとは思っていなくて、私が気になったのは"一般論としては"「理想の組織構造が分かっていても採用がボトルネックになってそうできないケースが多数あるのでは」という事でした。なので、これもこの記事で説明する想定がないという事であれば、これも承知しました。
私としては、以下の回答でこの記事の目的が理解でき、色々と合点がいきました。
つまり、この記事は「一般論としてどうあるべき」という事について言及しているというよりは...
言い換えると、具体的にどうすればこの状況が解決するかを単独で直接的に示すための記事ではなく、その背景にある筆者の行動のモチベーションや目的を説明するための記事であるという事なのだと理解しました。
そのような文脈も含めまともな読解をできず、私の力不足に対してお時間を頂き申し訳ありませんでした。私としては理解が深まり、また参考になりました。
（例えば、上で"一般論としては"「理想の組織構造が分かっていても採用がボトルネックになってそうできないケースが多数あるのでは」と書きましたが、この記事がそもそも一般論を扱っていなくて、特定の組織やご自身の周辺での相手を念頭に置いたものであるとすれば、合点がいきました。）
その上で、私が思ったこととしてはやはり最初の端的な質問のようなことで、例えば仮に @shin_semiya さんの周りにおいても、ヒラは直ちにICになれるのか？なれないとすればどういった教育が必要なのか？というのが気になったことでした。
あーたしかに。この記事は一般論ではなく、コンテキストがあるのですがそれを明記してないですね・・・
反省するところしきりです。
上部構造について
・伝統的なツリー型にする
・プロダクト中心に規模と層の深さを一定にしないツリー構造にする
・マトリックス型にする
・「ユニコーン企業のひみつ」的なこみいった構造にする
という方法があります。
選択肢があるのとコンテキスト次第なので私は扱わないつもりでした。
ICとEMについて
伝統的な組織であればメンバーはリーダー > マネージャーへの昇格を前提としています
ライン工の発想で、ヒラ工員が班長になってライン長になる、という考えです。
（そのメインストリームから外れたエースにはスペシャリストとしての道もあるらしいですが）
私の考えではICとEMは全く別の職種です。
そもそも記事の前提として「複雑なことを扱える高度で自律的な組織を作るために」
・チームの権限を増やし
・チーム内に有力なEMを置き
・チームの規模を増やす
という話をしています。
必然高度なチームを扱う「EM」もメンバーとは別職種です。
EMは泥臭いことを泥臭くやる職種であるため職種間転換も泥臭くなります。
つまり伴走期間を長く設けて前任のEMとOJTで長く作業させ、そこで学ばせて育てる他にないと考えています。
解説ありがとうございます。
そうですね、上部構造に関しては、いくつかの上手くいきそうなパターンがあるかと思います。
総じて、日本によくみられる構造と、近年良いとされる構造（を積み重ねたり並べたりしてできるアメリカ等にある組織）の二つの構造の差は、ピラミッド型的なカタチの構造の問題というよりは、「各ピラミッド/ツリー構造のノードにおける職責や役割」という意味での構造の問題なのかなと思いました。すごく雑な言い方をすると、整列時の見た目のフォーメーションは２つとも似ている場合があって、しかし役割や動きが根本的に異なる、というような事かなと思います。
また、EMは基本的にICの延長や上位という事ではなく、EMの業務も育成も泥臭いというのはその通りだと思います。（ICが泥臭くないかどうかは私にはわかりませんでしたが）
最近、ICもEMもむしろ数年かけて育てた方が早いのではと思う事がしばしばあり、採用ロジ確保のあてがあるのは大変うらやましく思いました。感想ですみません、勉強させていただきました。