なぜあなたの会社はエンジニアが辞めてしまうのか？その⑤

はじめに

この記事はその①、その②、その③、その④の続きのお話です。まだ読まれてない方は必ず先にその①、その②、その③、その④を読んでから読んでみて下さい。

登場人物の紹介

その①でも紹介しましたが、今回は対話形式で書いてみたので、登場人物だけ紹介しておきます。３人登場します。（②話目以降はほぼ2人ですが…）

エンジニア：Eさん
Eさんの評価者：Sさん（非エンジニア）
Sさんの友人のエンジニアマネージャー：Mさん

簡単なあらすじ

Eさんやエンジニアから退職され、途方に暮れたSさんは、元同僚で今は別の会社でEM（エンジニアマネージャー）をやっているMさんと飲みに行って相談して、これまでの経緯を聞いてもらって、コミュニケーションを中心にいくつかアドバイスを貰ったのでした。詳しくはその①、その②、その③、その④を読んで下さい。

「実はさ・・・カクカク・シカジカ・・・何が駄目だったのかな・・・」

そのあとMさんからいくつか意見（その②、その③を読んで下さい）を貰ったあと、その意見を元に実践してみたのですが、エンジニアの退職が止まらず、もう一度Mさんを誘って話を聞いてもらった（その④を読んで下さい）のでした。

Mさん：「他の事例も紹介しとこうかな。
Sさんと同じく元営業の事業責任者でエンジニアのマネジメントをやっていたHさんという人がいてね、その人がすごく上手だったんだ。多分立場が同じで参考になるかもなので厚めに話そっか。」

Sさん：「おお、ぜひぜひ！」

Mさん：「Hさんも、自分からエンジニア側を理解しに行く人だったんだけど、EMの僕から見ると『エンジニアを甘やかしている』と他部署から非難が無いか心配したくらい極端に取りに（聞きに）行っててさ、でもそうはならなかったんだよね。
エンジニアの言葉にできない不満や課題を吸い出した上で、技術も他の人に説明できる程度には理解して、得意な言語化と説明でマーケや営業に伝える部分を代行してくれたり、逆にマーケや営業の言い分や温度感をエンジニアに分かりやすく伝えてくれてて、その上で自分が意思決定した理由も伝えてて、やっぱりコミュ力高いってすごいなーと思ったよ。その時はほんとに事業部全体の納得感や一体感があったので、見本にしてるんだ。」

Sさん：「分かったような分からないような・・・」

Mさん：「ちょっとイメージしにくいと思うので、そのバランスを図にしてみよう」

と言ってMさんはノートを取り出した。

Mさん：「まず、事業責任者としては、両方の言い分や不満をフラットにヒアリングして、フラットにジャッジしたいよね。だから理想の状態はこうなるかなと。」

Mさん：「でも実際は、何も意識してなければ、普通はコミュニケーションのベースに近い方が強くなり不満が出やすく、遠い方が弱くなって不満が出にくくなる。」

Mさん：「Hさんはこの現象を知ってか知らずか、近い方は控えめに聞き、遠い方はわざわざ厚めに取りに行って、理想としての『偏り無く事業状況を把握する』に近づけてたわけだね。これを少し極端にやったとしても、甘やかしてるように見えても、あくまで事業としてフラットに判断するためという目的さえぶれなければ、結果的に納得感がある、そういうことなのかなと思うんだ。」

Mさん：「Hさんの場合は大丈夫だったけど、これも行き過ぎて、近い方の事実（青いところ）を押さえつけて、離れてる方は大げさに上乗せしたりしたりすると、さすがに懸念した非難につながるんじゃないかなと。」

Sさん：「なるほど、ここまで考えたことなかったな。でも、同じ立場の人がそんな上手にやってるなら、ちょっと元気を貰えたわ。みんな苦労してるんだな・・・
ちなみに、悪い方の事例もあるかい？俺以外で（笑）」

意志決定をしない責任者だと現場が不幸になる

Mさん：「うーん、そうだなー。
あ、意志決定をせず、火消しで終わる人がいたね。不満や言い分が出たら、両方の言い分をものすごい良く聞いてくれるんだけど、同じ場で公に意思決定を言うのではなく、またそれぞれ個別に時間を取り、相手が納得するようなニュアンスで話をしてとりあえず火を消すタイプ。」

Sさん：「え、でも、火消しって結構大事じゃない？」

Mさん：「確かに炎上させちゃう人もいるからねー、そういう人に比べれば、火を消せるってだけでもすごいとは思うんだけどさ、両方の言い分を聞く必要がある不満や要望って、あちら立てればこちらが立たぬ系の、相反する事が多いよね。だからこそ、責任者としての意志決定とその理由が必要で、さっきのHさんはそこまでをしっかりやってたんだけど、その場限りの火消しをするだけだと、大抵はまた再発する」

Sさん：「あーそういうことか、意志決定をしてるかしてないかね」

Mさん：「そうそう、意志決定をせず、一時しのぎ的な対処をするからいつまでたっても同じような事が起こっちゃうんだよね。火消しを目的にしてしまうと、手段としては、まずはコミュニケーションのベースが強い方や多数派に自分の意見を寄せるというのが多かったかな・・・弱い方からはすぐ主張しなくなるから早く鎮火できる。プラスで弱い方に『気持ちは分かるよ』という理解を示しておけば『評価者は分かってくれるいい人』になるので、関係性も悪くならない。」

Sさん：「確かに、状況は変わらないけど一見収まりそう・・・」

Mさん：「『現場が起こした』問題を『上司がきちんと処理（火消し）した』になるから、経営からの信頼は上がるし、現場の信頼も上がる。だからこの問題は結構見えにくいんだよねー。まぁでも実際は何も決めてないので、プロフィット部門だと実際の数字が落ちたりして気付く機会はあるけど、間接部門だとほぼ気付かないかな。」

Sさん：「俺も知らない間にこれやってそう・・・」

Mさん：「あとは『現場同士でうまくやりなさい』と現場に丸投げする責任者かなー。上司が意思決定をしないという意味では同じだね。
そういう対応をした場合は良い意思決定は生まれず、単にベースではない方が黙る（今回だとエンジニア側が黙る）だけになる事が多いかなぁ。まぁそういう傾向だけでも知っておくといいのかも。こういうタイプは、さっきのHさんのようにフラットな意志決定ができる事がまずないね。」

Sさん：「弱い方の意見をフラットに引き出すには、歩み寄って取りに行かないとだめか。甘やかすとか贔屓（ひいき）するとかではなく、あくまでフラットに意志決定をするためだね。エンジニアに特別扱いしないといけないとかではなく、そういう傾向になる事を知っておくことが重要って言いたいんだね。」

強い方と弱い方をコントロールする

Sさん：「ちなみにさ、そもそもの文化で、強い方とか弱い方とか出ちゃうのって何でなんだい？そこはコントロールできないものかな。」

Mさん：「コントロールはしようと思えば出来ると思うよ。経営陣がこのバランスを良く見えてれば、の話だけどね。まず、前提としてさっき言ったような『ビジネスモデル的にどの職能の影響度が高いか』を理解しておく必要があるよね」

Sさん：「それはさっきも聞いたやつだね。で、うちは営業寄りだと思ってたけど、最近はプロダクトやシステムもすごく大きいということを肌で感じてる」

Mさん：「であれば今回はエンジニア強めで考えようか。考える時に僕が大事にしているのは『人』ではなく『仕組み』で解決する、だね。
プロセス改善やセキュリティなどでもよく言われるかな。最近SRE界隈でポストモーテムって言葉が出てきてるんだけど、そこでも重要視されてた気がするなー・・・」

Sさん：「なんかさー、さっきからちょいちょいテクハラしてきてない？ｗ」

Mさん：「まぁまぁ、つい出ちゃっただけだってｗ　悪かったよ。
つまり、組織課題においても、意識改革とかさ、そういうのって長続きするイメージが無いので、こういうのも仕組みで解決したいなーって思っちゃうわけ。」

Sさん：「なるほどね、で、どういう仕組なわけさ」

Mさん：「仕組みといっても単純な話なんだけど、ベースのコミュニケーションや文化において、特に影響を与えるのは、この3つだと思うんだよね。
・会社の持ち主（オーナー）の影響
・会社の偉い人（ボードメンバー）の影響
・会社の社員の多数派
他のもあるかもしれないんだけど一旦こんな感じ。」

Sさん：「あー、確かにこの3つに集約されそう。でも当たり前な気はするかな」

Mさん：「だから、これをコントロールすればいいのさ。とはいえ、オーナーは正直コントロール出来ない事が多いので『意見聞いてくれる人であることを願う』くらいかなｗ」

Sさん：「まぁ、それは仕方ないか」

対策その① ボードメンバーにIT系が強い人材を増やす

Mさん：「で、意見聞いてくれるオーナーであれば、その下のコントロールは可能だね。例えば、今のSさんの会社だったら、もう少しエンジニアの文化や発言力を強くした方が機能すると思うわけでしょ？であれば、会社の偉い人の比率にエンジニアロールの人を増やす。CTOとかVPoEとか、あとは厳密には役割違うけど、CISOとかCDOやVPoPもロールとしては近いかもね。そういう人を増やすだけでだいぶ変わってくると思うよ。政府が、女性の活躍を推進するために、実際に上場会社における女性役員数の割合とかを指標に置いたりするでしょ。あれと同じ感じかな。派閥とかとも似てるのであんまり好きではないんだけど・・・」

Sさん：「なるほど、そういうことか。確かに意識しなくても、人数比率に応じてある程度改善される気がするかも」

対策その② 社員のエンジニア比率を高める

Mさん：「あとは、多数派のコントロールで一番大きいのは社員数の調整だね。単純に、社員の中のエンジニアの比率を高めればいいという話。エンジニアチームの人数を増やせたりする？」

Sさん：「うーん、うちの会社エンジニアへの投資は結構削られるんだよね・・・人数も『そんなにいる？』と言われる事が結構強くて・・・」

対策その③ 他の職能チームのエンジニア比率を上げる

Mさん：「まぁ、よくあるパターンか。それもさっきの、ボードメンバーの比率が高ければ変わってくるんだけどね・・・
どうしても難しければ他の職能チームのエンジニア比率を上げる、というやり方でも効果はあるかも。」

Sさん：「え？他の職能チームのエンジニア比率を上げる？ちょっと意味が分からないぞ・・・」

Mさん：「確かに分かりにくいか。ちょっと背景から説明した方がいいかな。4人の営業チームがいたとするよね」

Mさん：「例えばマーケとかなら、AnalyticsやAdWordsもJavascriptなどを設定できたり、MAツールやCMS、DWHなどいわゆるシステムやプログラムを理解していた方が成果が上がる時代になってきてると思うし、営業もザ・モデルみたいな考え方も進んできてるから、SFAやコールシステム、CRMなどを駆使して効率化している時代だよね。SFAで有名なSalesforceはJavaに近いプログラムを書けるので最近はSalesforceエンジニアとか特化型のエンジニアも増えてきてるよ。大量のデータから戦略を検討する時とかは、SQLを覚えて、エンジニアに頼まず資料作成用のデータを取ってこれる営業とかも出てきてるよね。コーポレート部門でもさ、時代はどんどんペーパーレスになっているから、ETLなどを駆使して連携強化したらだいぶ効率化図れるしね。
という感じで、どの職能でも、エンジニアを入れるメリットは実は結構あるんだよね」

Sさん：「ぎゃーーー、また難しい用語がいっぱい！絶対わざとやってるだろｗ
まぁ悔しいけど言いたい事は分かる。営業でもシステム入れてやっていく時代だなってのは実感あるしね。」

Mさん：「でしょ。だから『エンジニアチームに人が必要』という文脈ではなく『マーケにエンジニアが必要』或いは『営業にエンジニアが必要』という感じで、エンジニアの人件費をプロフィット部門にしておくのさ。こんな感じだね」

Mさん：「そうすれば、経営陣も営業／マーケは経営的に数字に跳ね返りそうな見え方になる事が多いので、『ああ、リターンも見込めそうならいいんじゃない？』となりやすい。」

Sさん：「あー確かに、それは通る想像が付くな。でもそうなると各職能チームのトップがエンジニアをマネジメントするってことだよね。俺みたいに失敗する人続出にならないかな・・・」

その⑥に続く・・・