  |
https://b.hatena.ne.jp/entry/s/www.timakin.com/posts/hacker-and-suits/
IT技術者のイメージが確立した頃のITというのは基本的に技術が収益性を決定していた。ビジネスの人間からすれば「おかしなこと」で、普通に考えれば顧客が何を求めているかが問題だ、という意識があったはずだ。
例えば、(フォードの速い馬車という意味ではなく)顧客がミント味のガムを求めていることが判明したとする。当然、ミント味のガムを製造すれば儲かる! のだが、ITでは「ミント味のガムを製造することを認めてよいかどうか」を決めるのはエンジニアであり、そしてエンジニアは実装言語の仕様書を読んでいるだけで、更にその仕様書は半導体ベンダが決定し、加えてその仕様書も主にカリフォルニア辺りの国立大学の発明を言語化しただけのものだ。つまり、ITにおいては、顧客が何を言おうと、経営者が何を提供したくとも、カリフォルニアの国立大学の研究室の学生が決めたルールに逆らうことは許されなかった(経営者的糖衣構文を使わずに言えば、実際に技術的に不可能)し、商業的に成功するプロジェクトとは「ルールの中で安価に実現可能なもの」と「顧客が欲しているもの」の共通部分のみを的確に選んで提供することができたプロジェクトだけだった。「技術が分かる経営者」とは、現時点の最新のルールを深く把握し、損益にどう出るかイメージを掴みながら商品企画を選べる経営者だった。
ただ僕も不思議だったのは、３[他部署を巻きこみプロジェクトを推進できる]にいるエンジニアですら「事業がわかる」エンジニアとしての評価を得られないケースがあると言うことです。ユーザーにいいものを届けたいし努力をしているつもりだけど、膨大な負荷がかかっているし経営層は何もわかってくれないということで、奥歯を噛み締めながらその場を乗り切っている方は少なくないのかな、と思います。
これはまさに「技術が収益性を決定するのは、本来はおかしなこと」という経営層の理解と、「現世で現実的に可能かどうかが最優先」というエンジニア間の乖離ではないだろうか? 経営層は顧客に価値を提供して対価を受け取りたいのであり、学術的な努力目標を数多く達成したいわけでは、本来はないのだ。だから他部署を巻き込んで膨大な負荷を受け止め新しい技術的知見を得ても、まったく意味がない。過去、技術的な制約を解除することには大きな意味があった。今はそうでもない。高い技術それそのものによる金銭的価値は少なくなったのだ。その結果、顧客が支払う金銭を最大化する製品設計の価値は上昇したし、そもそも元から低くはなかった。
そして、もちろん実行力も大事なのですが、彼らとの共通言語を持った上で会話ができる、具体的には採用方針を考えたりビジネスの状況を踏まえた塩梅での技術選定をしたり、さらには企業の将来像を共に議論するというある種の机上のフェーズですら、彼らは欲して止みません。それさえできれば多少の評価が得られるというのが、隠れた事実のように感じています（もちろん、それが良いとは言ってません）。視座が４にあるだけで相当な評価を得られるということですね。当然議論してるとしばらくしたら人事や社内管理、事業のブラッシュアップ、営業など、全ての方面で駆けずり回ることにはなるのですが。
となると、自らのキャリアに集中したい、技術力への危機感がいい意味で強いエンジニアであればあるほど例の三大美徳に殉じた方が技術者として成長するし、それで評価を獲得できる会社に転職するのが良い、となります。そして経営層からしてもそういうタイプの人だと同じレイヤーで議論をしてくれることへの期待値が高くないので、自然と「事業をわかって」くれないタイプだと見做して配置換えを行います。全てではないですが、こうした負の循環によって過剰にテックリードがいる組織が僕の頭にぼんやり浮かぶことがあります。
「優れたエンジニアは汎用的な問題解決能力が高く、その能力を是非とも経営でも生かしてほしい。あとは興味を持ってくれる人がいるかどうかだけなんだ…」という意見を経営層が漏らすパターンはこっち寄りです。そしてあくまで個人の嗜好性の問題なので、解決難易度が非常に高く、共通解も存在しません。１つ目の問題のように配置換えで多少解決できることではありません。
以上のような理由から、経営層はエンジニアにも「事業をわかって」欲しいと思いながら、その期待値を高く設定することができずにいるという印象を受けました。
まとめると、既存製品の改修にしろ新製品の企画にしろ、採用や企業内の人員配置にしろ、サプライヤや親会社との折衝にしろ、まず収益性をKPIに選び、検討項目を洗い出し、貪欲に裏付けを持って改善するエンジニアの能力を活かしてほしいという話だ。顧客からの売り上げを最大化する商品企画ができないエンジニアが多い、それが要点だろう。この文章にはエンジニアと経営者の言語が疎通しない理由が詰まっている。話の要点を短くまとめていない。要点をまとめないことを要求している。要点を省いている。だから技術的な制約と戦うエンジニアには通じないのだ。正直に「企業は顧客からの売り上げで成り立っている。だからできれば商品企画の段階でも収益性第一で企画進行が出来る奴が欲しい。そして社内外を問わずオジサンが求めているのは常に出会いだ。だから収益の話をグダグダ伸ばせること、酌ができることは必須だ」と言えばいいのだ。
ITでは「ミント味のガムを製造することを認めてよいかどうか」を決めるのはエンジニアであり、そしてエンジニアは実装言語の仕様書を読んでいるだけで、更にその仕様書は半導体ベ...
KPI以前で転んでることがあまりに多い気がするのですがそれは視点が低いからですかね たとえばXXを企画担当したのは私ですでどの会社でもツーカーで通じる成功体験をお持ちの方なら...
某フィンテック系のCTOもそんな感じだからビジネスはイケてるのに技術面で思いっきり足を引っ張っている。
難しい問題ですね。顧客のニーズに興味が無い技術者 と 技術が良く分からない経営者。 かてて加えて、顧客自身がどういう商品が欲しいかについて分かって無い事も多いです。 技術...
7
