2020-10-02

事業が分かるエンジニアがいない

https://b.hatena.ne.jp/entry/s/www.timakin.com/posts/hacker-and-suits/

IT技術者のイメージ確立した頃のITというのは基本的技術収益性を決定していた。ビジネス人間からすれば「おかしなこと」で、普通に考えれば顧客が何を求めているか問題だ、という意識があったはずだ。

例えば、(フォードの速い馬車という意味ではなく)顧客ミント味のガムを求めていることが判明したとする。当然、ミント味のガムを製造すれば儲かる! のだが、ITでは「ミント味のガムを製造することを認めてよいかどうか」を決めるのはエンジニアであり、そしてエンジニア実装言語仕様書を読んでいるだけで、更にその仕様書半導体ベンダが決定し、加えてその仕様書も主にカリフォルニア辺りの国立大学発明言語化しただけのものだ。つまりITにおいては、顧客が何を言おうと、経営者が何を提供したくとも、カリフォルニア国立大学研究室学生が決めたルールに逆らうことは許されなかった(経営者的糖衣構文を使わずに言えば、実際に技術的に不可能)し、商業的に成功するプロジェクトとは「ルールの中で安価に実現可能もの」と「顧客が欲しているもの」の共通部分のみを的確に選んで提供することができたプロジェクトだけだった。「技術が分かる経営者」とは、現時点の最新のルールを深く把握し、損益にどう出るかイメージを掴みながら商品企画を選べる経営者だった。

ただ僕も不思議だったのは、3[他部署を巻きこみプロジェクトを推進できる]にいるエンジニアですら「事業がわかる」エンジニアとしての評価を得られないケースがあると言うことです。ユーザーにいいものを届けたいし努力をしているつもりだけど、膨大な負荷がかかっているし経営層は何もわかってくれないということで、奥歯を噛み締めながらその場を乗り切っている方は少なくないのかな、と思います

これはまさに「技術収益性を決定するのは、本来おかしなこと」という経営層の理解と、「現世で現実的可能かどうかが最優先」というエンジニア間の乖離ではないだろうか? 経営層は顧客価値提供して対価を受け取りたいのであり、学術的な努力目標を数多く達成したいわけでは、本来はないのだ。だから部署を巻き込んで膨大な負荷を受け止め新しい技術的知見を得ても、まったく意味がない。過去技術的な制約を解除することには大きな意味があった。今はそうでもない。高い技術それそのものによる金銭価値は少なくなったのだ。その結果、顧客が支払う金銭を最大化する製品設計価値は上昇したし、そもそもから低くはなかった。

そして、もちろん実行力も大事なのですが、彼らとの共通言語を持った上で会話ができる、具体的には採用方針を考えたりビジネスの状況を踏まえた塩梅での技術選定をしたり、さらには企業の将来像を共に議論するというある種の机上のフェーズですら、彼らは欲して止みません。それさえできれば多少の評価が得られるというのが、隠れた事実のように感じています(もちろん、それが良いとは言ってません)。視座が4にあるだけで相当な評価を得られるということですね。当然議論してるとしばらくしたら人事や社内管理事業ブラッシュアップ、営業など、全ての方面で駆けずり回ることにはなるのですが。

となると、自らのキャリアに集中したい、技術力への危機感がいい意味で強いエンジニアであればあるほど例の三大美徳に殉じた方が技術者として成長するし、それで評価を獲得できる会社転職するのが良い、となります。そして経営からしてもそういうタイプの人だと同じレイヤー議論をしてくれることへの期待値が高くないので、自然と「事業をわかって」くれないタイプだと見做して配置換えを行います。全てではないですが、こうした負の循環によって過剰にテックリードがいる組織が僕の頭にぼんやりかぶことがあります

「優れたエンジニアは汎用的な問題解決能力が高く、その能力を是非とも経営でも生かしてほしい。あとは興味を持ってくれる人がいるかどうかだけなんだ…」という意見経営層が漏らすパターンはこっち寄りです。そしてあくま個人の嗜好性の問題なので、解決難易度が非常に高く、共通解も存在しません。1つ目の問題のように配置換えで多少解決できることではありません。

以上のような理由から経営層はエンジニアにも「事業をわかって」欲しいと思いながら、その期待値を高く設定することができずにいるという印象を受けました。

まとめると、既存製品の改修にしろ製品企画しろ採用企業内の人員配置しろサプライヤや親会社との折衝にしろ、まず収益性KPIに選び、検討項目を洗い出し、貪欲裏付けを持って改善するエンジニア能力を活かしてほしいという話だ。顧客からの売り上げを最大化する商品企画ができないエンジニアが多い、それが要点だろう。この文章にはエンジニア経営者言語が疎通しない理由が詰まっている。話の要点を短くまとめていない。要点をまとめないことを要求している。要点を省いている。だから技術的な制約と戦うエンジニアには通じないのだ。正直に企業顧客からの売り上げで成り立っている。だからできれば商品企画の段階でも収益性第一企画進行が出来る奴が欲しい。そして社内外を問わずオジサンが求めているのは常に出会いだ。だから収益の話をグダグダ伸ばせること、酌ができることは必須だ」と言えばいいのだ。


昭和はそれで済んでいたはずだ。いつから日本語はこんなに空疎になった?

  • ITでは「ミント味のガムを製造することを認めてよいかどうか」を決めるのはエンジニアであり、そしてエンジニアは実装言語の仕様書を読んでいるだけで、更にその仕様書は半導体ベ...

  • KPI以前で転んでることがあまりに多い気がするのですがそれは視点が低いからですかね たとえばXXを企画担当したのは私ですでどの会社でもツーカーで通じる成功体験をお持ちの方なら...

  • 某フィンテック系のCTOもそんな感じだからビジネスはイケてるのに技術面で思いっきり足を引っ張っている。

  • 難しい問題ですね。顧客のニーズに興味が無い技術者 と 技術が良く分からない経営者。 かてて加えて、顧客自身がどういう商品が欲しいかについて分かって無い事も多いです。 技術...

記事への反応(ブックマークコメント)

ログイン ユーザー登録
ようこそ ゲスト さん