見出し画像

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

はじめに

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

登場人物の紹介

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

エンジニア:Eさん
Eさんの評価者:Sさん(非エンジニア)
Sさんの友人のエンジニアマネージャー:Mさん

簡単なあらすじ

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

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

そのあとMさんからいくつか意見(その②を読んで下さい)を貰ったあと、少し疑問が湧きました。

エンジニアにコミュニケーションコストをどれくらい支払わせるか

Sさん:「ちなみにEMとしてエンジニア側にコミュニケーションコストを支払わせる場面ってどんな時なんだい?」

Mさん:「EMは会社から開発効率を求められたりする立場だから、この辺は結構考えるんだけどね、まぁ『エンジニアに、営業が分かるような説明をさせるコスト』なんかは、元が取れることはほぼないと思ってるよ。それに時間を使わせるくらいなら、技術や開発に時間を使って欲しいと思うんだよね。そもそも技術や開発が本業でそれを期待して採用してるわけで『エンジニアに向いている人』ってこと自体が貴重な、誰でもできる事じゃない領域だからね。他の職種も同じだと思うけどさ、だからその課題の重要度を落とすとか、ギリギリまで無視するとか、コスト自体を無くす方向で考えるかな。どうしてもの場合は僕が代行するようにしてる。伝わらない場合のストレスは僕がかぶれば済むからね。
すぐに採用できる職種であればこんなに考えないけど、エンジニアの採用難易度は年々高まってるから、業務時間に貴重な工数を使って何をさせるのかは結構気にしてる。」

Sさん:エンジニア採用の難易度は絶賛自分も実感中だ。これも実際にやってみてやっと分かった。抜けられた今だからこそグサグサくる・・・

「そんな大きいコストなら、開発スピードが上がらなかったのも、こういう理由なのかな・・・」

Mさん:「ありそうな気はするよー。開発スピードの低下の2大原因は、コミュニケーションコストと、技術負債だと個人的には思ってる。しかも、技術負債を説明するのにコミュニケーションコストが結構かかるという問題もある。辞めたEさんは、技術負債を説明するのもきっと苦手だったんじゃない?」

Sさん:「あ、そういえば・・・」
Eさんが、いろいろ言いかけて口をつぐんだ場面を思い出した・・・

Mさん:「上司がEMだったらさ『そろそろここ保守入れないとまずいんですよね』って言われて『あー確かに危ないね、優先度上げようか』で伝わる話だけど、Sさんだと判断難しいでしょ。」

Sさん:「確かに、一回相談された覚えがあるけど『それって要はどういうこと?』『数字でインパクトとか出せる?』『ってことはやっても見た目何も変わらないってこと?』みたいに返してたかも。少し口をつぐんだあと、インパクト算出してみますって言って、でもそのあと来てないな・・・」

Mさん:「あはは、それはもう来なさそうw 苦労して出したとしても『ちょっと分からない』とか『もっと分かりやすくできる?』などと言われた日には、悪意が無いと分かっていてもドッと疲れるんだよね。しかも正しく出せるわけでもないし。僕自身『こんな算出とかしたくてエンジニアになったんじゃねーー!』とか『この調査や算出に使った工数を保守に使えばかなり進めれたのに・・・』内心キレてたときもあったよ。今はEMだから多少我慢できるけど、言った方は軽く言うけどさ、説明する調査や資料作成って結構エネルギー使うんだよねー
ちなみに、保守の大事さ、考え方みたいなのは前に非エンジニア向けに記事書いてみたからこういうのも参考にして勉強してみてよ。」

https://note.com/gonjyu/n/nd7bf3efa0728

Sさん:確かに最近は昔より説明しにきてくれる事が減ってたかもしれない。ただ質問してただけのつもりだったけど、疲れさせてしまってたのか・・・
「でも分からないと判断できないし、どうしたらいいんだい?」

Mさん:「結局どちらかがコストを支払わなければいけないからどうすれば、というのは難しいけど、エンジニアに説明させるのではなく、Sさんなら割と理解速そうな気がするからSさんから理解しに行った方がいいんじゃないかな。これも人によるけど、非エンジニアでも技術や特性の理解が速い人がいるからね。経験としてはコミュニケーションや言語化が得意なエンジニアより、技術を理解できる非エンジニアの方が多い印象があるかな。まぁあくまで僕の経験の範囲でしかないけど・・・。

それやらせる間に保守できたんじゃね?

Mさん:「それに、Eさんにしてみれば、Sさんに分かってもらえたとしても、次に他の関連部署に説明する作業もあるんだよね。Sさんが一回理解してあげれば、他部署への説明はSさんの方が上手にできると思うし、レポートライン的にも上位であればマーケや営業も聞いてくれやすいでしょ。エンジニアから話しに行くと、そもそも聞く姿勢になってもらう事すら大変な時もあるからね。
あと、Sさんから理解しに行った方が、多少、理解範囲の効率もいいというのはあるかな。エンジニアにお願いすると、判断に必要な部分が分からない事が多いので、範囲的には全部説明するしかなくなるんだけど、」

これ全部説明するのか・・・

Mさん:「Sさんなら判断に必要な部分が分かるから、理解の浅くていい箇所と深く理解しないといけない箇所を判断してコントロールできるといいうか、重要な部分だけ重点的に理解すればいい・・・判断さえしたらあとは任せればいいからね。」

理解すべき箇所のあたりをつけれる

Sさん:「なるほど、まぁそうなるか・・・分かるんだけど、なかなか時間取れないんだよな。」

Mさん:「そうだよねー、事業責任者って時間無いよね。であれば『判断の移譲度合いを変える』かな。その工数が正しくなかった時のデメリットより、正しいかを判断するためのコミュニケーションや調査コストの方が高くつく事も多いというのはなんとなく分かったと思うので、であれば『やってみていいんじゃない?』で任せちゃうのも一つの判断だね。エンジニアは合理的で慎重な人が多いので、わりと現場に判断を任せても派手にコケたりはしない感触はあるよ。どうしても許容できない経営的なリスクのラインだけ伝えて、そこに抵触しなければOK、みたいなのもありかもな。ガードレールだけ示しとくイメージだね」

Sさん:「なるほど、ガードレールと信頼でカバーするのか。今も技術は分からないところは任せてるからイメージはできるな・・・それなら時間使わずに済むけど、大丈夫かな・・・。」

Mさん:「不安な気持ちも分かるよ。小さいものから何度か試して、大丈夫そうだったら範囲を広げる、とかでもいいかもね」

逆にエンジニアが強すぎる会社もある。強い側と弱い側

Mさん:「なんかエンジニアを擁護してるように受け取られるかもしれないので、逆のケースも言っておこうかな。つまりエンジニアが強すぎる会社。」

Sさん:「え、どういうこと?そんな会社もあるの?」

Mさん:「例えば最新の技術をビジネスにしてるようなスタートアップとかは社員の比率もエンジニア比率が圧倒的に多かったりするんだよね。そういう会社のコミュニケーションのベースはエンジニア側になってるので、暗黙的に非エンジニア側がコミュニケーションコストを支払ってる感じだね。
ちょっと仕事でお手伝いしたことがあるけど、確かにエンジニアはすごく伸び伸びやっているように見えたよ。
そして営業やマーケは、そもそもエンジニアに対して『専門用語が多すぎる』という不満は持ってなさそうだったかな。というより持ってても言えない感じだったのかもしれない。実際必死に勉強してエンジニアの会話についてきてるし、知らない言葉があったら『僕の勉強不足なんで』と下手に出る人が多くて、エンジニアからすると『めっちゃいい人多いな』という感じだと思う。」

Sさん:「なんか今まで聞いてきた中で考えると理想なようにも聞こえるけど・・・」

Mさん:「でも、こういう環境が当たり前になると、エンジニアが気軽に不満を言いやすくなって、行き過ぎた人は、専門用語バンバン使って高圧的な雰囲気出てくる人も出てきたりもするんだよね。[テクハラ]って言葉が出てきたのもそういう背景からかなーって思うね。そうすると、今度は営業やマーケが居づらい状況が生まれるよね。
僕も圧大きかった時があったと思う。今までさ、めちゃくちゃ工数かけたのにビジネス的にコケた、みたいなのをたくさん経験してきたからさ、ビジネスサイドからの『これ作って』はすごく懐疑的だった時期があって、Sさんが『数字のインパクトとか出せる?』って言ってたのと同じくらいの圧で『ほんとに儲かるの?』って突き返して、調べさせて、不確実性をとにかく下げないとエンジニアの工数は使わせない、みたいにしてた時期もあったよ。自分で言うのもなんだけど、怖いよねー(笑)」

ほんとに儲かるの?

Sさん:「Mさんこわっ!今のMさんと一緒に働きたくないわー(笑)」

Mさん:「いやいや、最近は理解ある人も増えてきてるのでそこまでしないってw
でも、一度『Mさん通すと何にも作ってくれないですもん』って皮肉めいた冗談を言われた事があってさ(笑)それからは理解ある人に対してもやりすぎは気を付けてる。
ほんとにバランスが悪いと思ったら今でもそのスタンス取る時もあるけどね。
あと聞いた事があるケースだと、インフラエンジニア(いわゆるハード系)だと圧倒的にエンジニア側に力があって営業が病んでやめるというパターンが多いって聞いたことがあるよ」

Sさん:でも、なるほど、そっちも起こり得るわけだ。つまり大事なのは、ベースがどちらにあるかを知っておくことと、それが行き過ぎていないかという事なのだろう。
「うちの会社が『営業やマーケは不満を言ってくるのに、エンジニアからはあまり言ってこなかった』のは、会社のコミュニケーションスタイルのベースが営業側だったからなのかな。」

Mさん:「そうだと思うよ。ベースになっている側は不満をあげやすくなるからね。だってベースに関しては社内やその組織で当たり前になってるから、説明する必要がないもんね。あとは不満をダイレクトに言えば理解してもらえる。上司が同じ職能であれば、理解してもらうためのコストは更に低い。
逆側にいる職能は、まずその当たり前と僕らが違うという説明をして理解してもらうところから始めないといけないから労力がかかる。2枚分の壁があるので『その壁を超える労力をかけてまで伝えるべき不満か』という判断が無意識的に入ってしまうので理論的には数が減るはずだね。あと、労力だけでなく、軋轢を生む可能性もあるからね・・・エンジニアは対立を嫌う人も多いから余計言えないって人も多いかも。」

Sさん:上司が同じ職能・・・特に自分は営業なので分かるが、営業は交渉が上手な人も多いので、言い方や圧、感情表現も含めてたくみにアウトプットする事を考えると、より自分に刺さりやすい表現で不満を主張している可能性は高い。それに比べると、エンジニア側は確かに難易度が高いかもしれない。

Sさん:「あ、もしかして、最近『エンジニアは◯◯なので』って文脈を多く使ってきたのは、そういうことなのか。『エンジニアを特別扱いするような表現でよくないよ、営業やマーケはそんな事言わないでしょ』って言っちゃったよ・・・」

Mさん:「あー、それは八方塞がりになるかもね。頑張って前提を説明しようとした勇気を折っちゃったかもね。別にさ、Eさんも好きで言ってないと思うんだ。というか、むしろ本当は言いたくないんじゃないかな。なんか言い訳に聞こえるし、印象悪くなるリスクあるからさ。でもそれを越えて説明しようと思ったEさんはなかなか勇気ある良いエンジニアだね。
でもさ、指摘には納得してたでしょ」

Sさん:「納得してた・・・」

Mさん:「この前提を分かってもらわないと本題に入れない。でも違いを理解してもらうための説明は特別扱いになってしまう。そして自分自身も指摘の通りあまりよくないと思っている。加えて元々苦手なコミュニケーションで時間もかかってしまう。そんな中、本業の開発も進めないといけない、となれば、結構辛いね・・・」

Sさん:何も言わない、というより言えないのか。頑張って説明の仕方を考えても矛盾しているので答えが出ないだけで疲弊する。でも納得はしてて不満ではない状態・・・想像するとなかなか苦しい。不満は無くてもなぜか辛い状況という感じかな。

「・・・それは、退職したくなるかもしれない。」

Mさん:「まぁ退職要因がそれかどうかは決めつけられないけどさ、少なくとも影響はあったかもね。いろいろやってみても『これを説明できない自分のせい』と自分に返ってくるので次の挑戦もしにくくなる。結構辛いんだよね。あとさっきチラッと言ったけど、コミュニケーションが苦手になったキッカケが『人との対立が苦手』という事も多いので、できるだけ円満な形で退職しようとする場合が多いから余計に本当の事は出にくいかもね。
中には対立する勇気あるエンジニアもいて、Sさんが求めてるようにしっかり不満を言ったりする事もあるよ。ただ、その場合は評価が下がる覚悟をした上でやるしかないので、基本的には退職を考えてると思う。」

Sさん:「そうか、Eさんには申し訳ないことをしてたかもな・・・反省💦
今日はいろいろありがとね。結構勉強になったよ。」

Mさん:「それは良かった。といっても、まだいろいろあるけど・・・?」

Sさん:「いやいや、ちょっと今日はおなかいっぱいだよ。これ以上いろいろ聞くと吸収しきれそうもないや。
それにそろそろ酔っ払ってきたしね。」

そのあとは仕事と関係無い話で飲んだあと帰宅した。Sさんは酔ってふらつきながら、Eさんみたいな人をこれ以上出さないために、明日からさっそく、エンジニア達にもっと寄り添ってみようと決心したのだった。

その④に続く・・・



この記事が気に入ったらサポートをしてみませんか?