エンジニアとビジネスの距離感の難しさ
はじめに
タイトルの通り最近「ソフトウェアエンジニアがビジネスの話をする」って極論かなり難しくねと思っており、まだまだ自分の中にも答えはないが書いてみる。
逆に読むと良い記事、書籍、論文があるなら教えて欲しい。
背景
近年「エンジニアは事業貢献してこそ」「エンジニアもユーザファーストでビジネス貢献」といった言説がIT界隈で増えて来ている感じがしている。
これは本当に良いことだと思っていて、技術や業界全体の経験の積み重ね、研究活動によって、技術やノウハウがコモディティ化したことで、より本質的なエンジニアリングが提供すべき事を考えられるようになっている結果の1つだなと思う。私がエンジニアリングを最初に学んだ頃なんかは、ソフトウェアエンジニアはキツいみたいな文脈で3K職だと言われていて、高専でも「電気系に行ったほうが安泰だぞ」と先生が言うほどだった。GitHubやCI/CD、クラウド、OSSだったり、ハードウェアだったり、エディタだったり、書籍だったり、様々なものの積み重ねによって「プログラミング」に掛ける時間は少しずつ減り、その分「エンジニアリング」とは何か、価値を提供するとは何かを考えられているんだよなとよく思う。
人が秘めていたポテンシャルが、技術によって解放されているなと。
もちろん、事業貢献にも色々な形があって、研究だとか間接的な技術、直接的な技術、マネジメント、どれもが貢献だと心から思っているし、技術者以外の事業貢献にもリスペクトの心がある事を最初に明記しておく。
エンジニアがビジネス価値についてやり取りをするのって難しい
時代もついてきているし、エンジニアも色んな形でビジネス貢献していこう！とは言え、じゃあ具体ビジネスにどう寄り添うんだいという話は尽きずあるとも思う。
ビジネスについて考えてみる。
ビジネス（英: business）は、経済行為を表す用語であり、狭義から広義まで様々な意味を持っていて、1つの日本語に置き換えて表現することはできない。
「狭義」「広義」はあるものの、やはりビジネスとは経済行為であり、極論お金のやり取りで成立している。
その前提に立つと、エンジニアは残念ながら多くの場合、ビジネス職に比べて所謂狭義の経済行為の渦中に居る時間が短い（広義では居ると言えるかもしれないが）当然だ。ビジネス職が営業や責任者をやる中で新卒から長い時間を掛けて顧客に触れてお金に触れてビジネスマンとしてプロに育っていく中で、多くのエンジニア職はそうではない（エンジニア職、ビジネス職といっても様々ではあるしバックオフィスなども含めると複雑になるがここでは安易に表現する）。この差は大きくて、エンジニアが強く大きな価値と考えているビジネス貢献、事業貢献が、プロのビジネスマンから見て小さいなんてことはよくある事だと思う。結果的に評価されなかったりだとか、ズレた施策や案件が飛んできたりはあるあるだよね。
逆に唐突に、エンジニアがビジネスに近い様々な会社の例にも触れてみる。
私がエムスリー AIチームに居たころの話だが、そこでは期の個人目標の中に必ず「貢献金額」が入っていた。何億円分の事業貢献をするか計画を立てて、そのための戦略を考える事、それらを達成するために動く事が個人の目標におかれていた。社内外の営業やPdMを含むプロのビジネスマンを巻き込む必要があるので、とにかくエンジニアリングというコンフォートゾーンから出て経済行為上でのお金の計算方法を知り、リーダーシップを発揮しなければいけない。これにはエンジニアとしても良いことがいくつかあって、当然お金ベースで話が進むので「自分の技術的にやりたい/やるべきだと思っていること」をお金に換算して説明して進められるようになる。例を出すなら、リファクタとかも「中長期で見ればこれだけの工数価値がある」だとか「金額は小さいが先を見据えてこのプロジェクトを立てて内包してもらおう」だとかで進められる。他にも「最もインパクトが大きい仕事は何か」だとか「ユーザ体験やデザインとビジネスを両立させる」だとかを真剣に考えるようになる。お金が共通言語でありベースにあると、周囲や経営層からも理解を得やすくなる。逆にこの文化の中では、お金の事を考えて抽象化と具体化を繰り返して言語化して話して社内外の経済を動かせないと大変で、どれだけ良いアイデアや技術があっても何一つ進められない。"そろばん弾き"とか"鉛筆なめなめ"とかで軽く見てる場合ではないというワケ。
他の会社だと、私の友人のエンジニアにサイバーエージェントの社内制度で起業した人が居る。彼は幼少期からずっとPCに触れているようなギークもギークで公に様々な賞も貰っていたりするが、今では経営とお客様とのやり取りを卒なくこなすビジネスマンになっている。彼の組織も聞くに、エンジニア個人にも事業関連の数値ベースで説明を要求するようにしているらしい。彼が言うには、CAの制度上での事業の売上報告が必要になるが、エンジニアリング組織が不透明だとエンジニアリングの優先度がそもそも上がりにくい。コストと貢献のROIが整理されていないと、採用人数でも制度でも文化でも技術投資でも経営でアクセルを踏むための説明責任が取れない、とのこと。逆にエンジニアはディティールを整理して数字を出してくれる分、事業価値換算しやすいので、少しでもフォーマットを用意すれば良いとも言っていた。
より広く話を広げると、これは実は「ビジネスとの橋渡し」を謳っているようなエンジニア組織の長でも、ちゃんとできてない人は多かったりする。人数と工数とコストと投資技術と経営事情が分かってるなら少なくとも何かしらは出せる事実はどこでもある訳だけど、エンジニア出身のギークな人で興味がない場合もあれば、経験不足で経営層から見た時稚拙だったり、文化とか制度とか違う所を見ていたりとか色々事情があったりして出来てない事がある。実際「うちの会社はbizの会社なんで…」と制度等に不満を漏らすエンジニアからよく話を聞いてみると、経済行為の中でエンジニア組織の価値を経営に伝えられてないだけだったという事はよく聞く話でもある。
つまり何が言いたいかって、エンジニアの事業貢献を口にし始た時、誰かがお金の事を考えないと自分たちエンジニアが経済行為の中で不利になる、でもそれってめっちゃコンフォートゾーン出ないといけないからしんどいよなって話。
とはいえ、エンジニアはビジネスのプロじゃなくて技術のプロだし、分業の考え方、全ての職種を互いに尊重するのも大大大前提として大事にはしたい訳だけどね。
難しいね。
さておき組織ってものがあるよね
さておき、先に挙げた2つの企業事例はビジネスに寄っていて、逆に組織の長の例はエンジニアに寄った、あくまで極端な例になる。実際はグラデーションになっていて、エンジニアでも営業行ってお客様とお金のやり取り当たり前みたいな会社もあれば、エンジニアに事業貢献感を持たせるに留めている組織もあれば、DXとお金を切り分けている組織、CTO含めエンジニア組織は全員がスペシャリストとして技術に特化してくれという所もあるはずだ。
上流、下流と分けて上流の中で工数やお金の計算や顧客調整の経験を積ませるSEのような形式もあるし、CTOとVPoEとCPOとで役割を分けて居るような会社もあるだろう。今は明確にIT業界共通の定義がなくても、将来的にビジネスと橋渡し専門のスペシャルな役割がブームになるやもしれない（すでにある所にはあるかもしれない）。技術特化な会社では、私も時雨堂さんとかはよくウォッチしている。技術者＝経営者だとまた話は変わってくるというか圧倒的にスムーズだろうし、個人個人のビジネスというモノに対する解像度の高さ要求も変わってくる。そうでなくても、ちゃんと儲かっていたりする会社もあるわけで、在り方というか思想次第だとも思う。
思想という意味で少し話を広げけおくと、このビジネスというかお金とエンジニアをどこまで紐付けるんですか/やらせるんですかという話は、メンバーであるエンジニア社員1人がどうこう思っても、会社の思想や成り立ちがあって変えられない事の方が多いとは思う。
もちろんビジネス経験以外にも技術や開発体制など色々な視点があると思うが、実は"組織課題"と呼ばれる物事の殆どが、この思想と実情のバランスが取れてなかったり、思想がなくて不安定だったりする事にあるんじゃないかなと最近は考えている。エンジニア個人では変えられないと書いた手前悲しいが、開発者の数、技術投資、制度、エンジニア文化みたいなものの中心に居る大事なコアなissueである事が多いなって思いながら記事を書いている。
だって経営者の多くはビジネスのプロで、彼らがエンジニア組織をどう見ているかに依存して全てが決まっているのが会社なのだから、彼らに事業価値を示せるかはハッピーに働けるかどうかのポイントの1つでないはずがない。
なんで今こんな話するんだっけ
特に直近USから不況の波が来て、IT企業ではレイオフだ採用フリーズだ筋肉質化だみたいな話が後を絶たない。そういった中で、今後IT企業のエンジニア組織が問いただされる事になる話題なんじゃないかなと思って書いている。
IT企業だけに技術で成り立ってるのは間違いない訳だけど、先に言った通りその人数とか選定、文化とかに影響する話題であると思うし、どこかでエンジニア組織としてのビジネスに対するスタンスを考えて示せというブームが来るんじゃないかなってのが仮説で、色々考えたり調べたりしていて記事を書くに至っているというワケ。
この話題、エンジニア個人として変えるのは難しいと書いたけど、自分の働きやすさのために知っておくと良いとは思っていて、「どこまで求められてるか」がズレると働き方としてもカルチャーマッチとしてもしんどくなると思っている。ビジネス貢献が強く求められるなら開発の割合は減るし、逆に開発から出ない方が良いことだってある。まあ後知ってるからといって、そこを変えに行くのは、それはそれで大変なんだよねという事も含めて知っておくと良さそう。
何より今後話題が増えそうだと思っているし。
おわりに
長文になってしまったのが、この話は難しいということを現してる。
何となく思っているのが、幼少期からプログラマで20年以上PCと共に成長してきたとかの人もいるわけで、（現に私がそうだったんだけど）この話を続けていくと時にエンジニアの尊厳みたいなものに触れることがあるのが難しい。スペシャリストとして尊重したりもそうだし、個々にキャリアプランがあるわけでタイミングとして噛み合わないとかもある。バックグラウンドや技術に対する訓示のようなものでも反応が違ってくると思う。ちなみに私は最初は普通にハードシングスだった。
故に企業として途中で変えるとか不安定とかだと良くなかったりする。エンジニアからは「ビジネスできるエンジニアってもはや経営者じゃん独立した方が早い」みたいな言説もたまに見るから、体感としてラインや順番を読み違えると組織崩壊しちゃう系の話なので注意しよう的なやつだと思う（流石に独立した方が早いは経営者バカにしてると思うけど）。
まあ、結局単一の正解はなくて、各会社や個人が自分たちの中でそれぞれ正解を探すんじゃないかなというのはある。そこの方針や取り扱い方が合わないと就労してもつらいので、転職就職の時に噛み合わせる要素の一つにしてみてはどうだろか。
エンジニアがビジネスの話をするのはむずい。
リスペクトも大事だし、向き合うのも大事。
自社と自分はこうだけど良い感じ、というのあれば教えて欲しい。転職活動の参考にします（？）。
サポートよろしくお願いします