何故エンジニアの上司はエンジニアである必要があるのか？

組織の話をしていて、何故、エンジニアの上司はエンジニアである必要があるのか？

CTOはいるがCDOがいない会社は多い。マーケティングという専門職の上司が永遠にマーケティングというわけでもない。もちろんCMOもいるだろうが、CTOに比べて常識化しているわけではない。

CTOがいる企業は増えているが、製造業の歴史的に成功した大企業がCTOがいるわけではない。

ただのエンジニアのワガママやエゴなんじゃないか？と思うことも多々ある。だから、たまに迷いが生じる。もちろん採用市場における業界の常識というのがあるので、それを無碍に無視するわけでもない。

いずれにせよ何故、エンジニアの上司はエンジニアであるべきなのか？ということを言語化できることが重要だ。

ー・ー

いろいろ考えた末に、僕が一つたどり着いたものは、

・いわゆる組織図ツリーは、ビジネスを実現するための組織図である。ビジネスが第一義になるので、ビジネス起点で始まり、グラデーション的にコミュニケーションを変換する中間管理職を経て、専門職に繋がる。それ故に、CTOやEMはビジネスと技術の論理の変換ができなくてはいけない。

・それに対して、技術者にはもう一つの仮想的な組織ツリーが必要で、それは「ソースコードリポジトリを適切に守るツリー」である。

つまり守るべきストックがあって、それを組織として対応しないと維持できないと考えるので組織図が必要になる。

ここには必ずしもビジネスへの適応力は存在する必要はない。機能実現、セキュリティ、スケーラビリティを兼ね備えたソースコードの集積体を作り続け、最適な生産性とクオリティでリファクタリングするだけのノウハウを兼ね備えた組織、ガバナンス構造が必要になる。組織というからには、もしビジネスが成長するのであれば、採用力、人材育成力は最重要組織課題である。

と考えた。この２種類の組織構造を両立させないといけない。このバランスが崩れると、いわゆる「技術的負債などにより、技術組織の生産性、発展性、継続性が脅かされる」ことなどが起きる。

これまでも直感的に、エンジニアの評価を、ビジネス成果に連動させてはいけないという話があったが、その理由は適切に言語化してこれてなかった。

ソースコードリポジトリの良し悪しとビジネスの成果は別物で、もちろん給与原資を稼ぐのはビジネスになるわけなので、昇給原資となるバジェットそのものがビジネスの成果に影響を受けるのは仕方ないが、そのバジェットの中から投資として、ハイスキルエンジニアなどに優先的に配分を行い、投資として成果に結びつけるのは経営者やプロダクトオーナーの仕事であって、成功も失敗も関係なく、まずは良い実装しなくては話にならないエンジニアの仕事ではない。だから、そことそことを混同してはいけないし、その投資判断をするための役割がCTOという経営クラスの責任を持つ人の仕事になる。

ー・ー

その際の上司の視点としては、

もし失敗するなら誰に賭けるならば後悔しないか

こんなことを考えている。すべては投資という名目で一枚フィルターがかかっていて、常に失敗することを前提に期待値設定またはリスクヘッジを考えることが重要であって、孫さんではないがA案、B案を常に考えながらということになる。その関係性の中で成果に結び付けざるを得ない。そもそも誰かにタスクを振ったら、期待するアウトプットがそのまま、もしくは、それ以上のものが問題なく出てくるのであればマネジメントなんてものは必要ない。現実的には、技術というのはどうにも複雑で、お気持ちの都合やクラス構造、ソースコードクオリティ等々、さまざまな要因で簡単にはいかないから、何に困っているか？を常にポーリングして、メンバーを支えていくためにマネジメントが必要になる。この上司という役割も、人的資本を最大化させるエンジニアリングの仕事である。だからエンジニアの上司はエンジニアじゃないとできない。

経営者視点を持てみたいな言葉が炎上しがちなのは、この辺の理屈をスルーして経営者としての都合だけを社員に押し付けようとして、人的投資の概念が一切ないというか、そう言うのであれば、お前は一切無駄なディシジョンをしないんだろうな？、無駄な実装をさせられるのはこっちやで、みたいなところで戦いになってしまったり。そことそことのギアを直結させて、遊びがない組織だと殺伐としてしまい良いことがない。

ー・ー

思い起こせば、製造業がクラウドサービスが苦手という理屈も、このソースコードリポジトリを守る組織構造が意識されてなかったせいではないのだろうか。もっと言えば、ソースコードというストック構造から売上を生み出す思考回路にはなっておらず、その場その場のトレンドのフローの中で、市場のニーズにアプライする製品をつくり続ければいいという話になるのであれば、そりゃまあ手間や時間がかかる製造の部分を外注化して、ファブレスにしてみたり、コストだけを追い求めてみたくなるのはわかるというか。一度、技術力の維持性能を現状最適してしたとして、もしパラダイム・シフトが生まれた時に失われてしまった何かがキーファクターになってしまっていた際には、子会社でも作ってインキュベーションして、成功事例を元にリファクタリングするしか手がないのでは？とは思ったりはします。

でも、なにげにアップルとかはM1チップを作ってイノベーションを生んだりしてて、設計力を維持する源としての製造力を外注しても設計力を維持するだけの胆力がどうやって実現できているのか？みたいなのは、製造業は製造業で考えるところが多そうとか思ったりしてみました。それを見越してM&Aなどをするのでしょうけどね。だから日本の会社法だと(ry....

ー・ー

と、ここまで書いてきて、何を残して何を捨てるかというのは、その都度その都度の選択であり、結果として残してきた組織が負債化するのか、新たな卵を生み出す資産として生きるのかは、まあ、よくわからんというか。言うてiOSでは光り輝いていても、未だMacOSでは別にどうでもいいやと思われる技術もあったりするわけだし、ないがしろにしてきたと叫ばれる金型技術が、突如、大貧民 / 大富豪のようにパラダイム・シフトすることもあるかもしれないし、それらもすべて結局、プロダクトとビジネスの力じゃん、というところに立脚するのは変わらず。なんにせよ投資としての技術組織を、どう活かすのか？というバランスさせて考えるべしってのが一番大切なのだろうなと思うわけではあります。