なぜあなたの会社はエンジニアが辞めてしまうのか？その②
はじめに
この記事はその①の続きのお話です。まだ読まれてない方は必ず先にその①を読んでから読んでみて下さい。
登場人物の紹介
その①でも紹介しましたが、今回は対話形式で書いてみたので、登場人物だけ紹介しておきます。３人登場します。（本記事以降はほぼ2人ですが…）
エンジニア：Eさん
Eさんの評価者：Sさん（非エンジニア）
Sさんの友人のエンジニアマネージャー：Mさん
簡単なあらすじ
エンジニアのEさんに退職されてしまい、途方に暮れたSさんは、元同僚で今は別の会社でEM（エンジニアマネージャー）をやっているMさんと飲みに行って相談して、これまでの経緯を聞いてもらったのでした。詳しくはその①を読んで下さい。
Sさん：「実はさ・・・カクカク・シカジカ・・・何が駄目だったのかな・・・」
Mさんは一連の話を一旦だまって聞いたあと、まずは
Mさん：「本人で無い以上、本当に不満があったのかどうかは分からないし、退職理由とかは実際に人によって違うと思うし、一つじゃないだろうし、言ってない事もあると思うから、正解は分からないって前提でいい？」
と前提を念押ししてくるので
Sさん：「そりゃもちろんだよ」
と伝えて、続きを待ちました。そして最初に言われたのが
Mさん：「Sさんの指摘内容に出てきた人としての部分やコミュニケーションの諸々って、Sさんや多くの職種にとっては当たり前かもしれないんだけどさ、エンジニアは苦手な人多いと思うんだよなー・・・いや、でも、Sさんみたいな、非エンジニアなのにエンジニアのマネージメントする時は技術は分からないからそういう部分でしか評価できないのも分かるんだけどね・・・」
という言葉でした。
「人」や「コミュニケーション」は職種関係ない？
どういうことか聞くと、
Mさん：「僕みたいなエンジニアがベースの人からすると、Sさんのベース職種である営業は、いわば［人］を専門としている専門職だと思うんだよね。交渉とか人付き合いとか社内政治とか見てても上手だし、いつ見ても俺にはあんな上手にできないなーと思ってたよ💦
Sさんから見れば開発の事が専門的で分からないって言うのと同じように、［人］という分野は僕からすると結構苦手でさ。プログラミングは一度書いたら同じように動くけど、人はそうもいかないしね。だからSさんから［人として共通］って言われても、実は、一緒にされたら困るという感覚なんだ。まぁ、あんまり共感されないから、声を大にして言えないんだけどねｗ」
Sさん：「えっ？そうなの？Mさんは全然その辺出来てる感じするんだけど・・・」
Mさん：「まぁ、僕は数年EMやってきて、人を観ている立場ではあるし、Sさんみたいな他の部門の人ともよく話をしてるので、いろいろ頑張って人について経験したから、少しはマシになってるかもしれないけどね。でも昔はもっと酷かったよｗ。少なくとも、今も「好きではない」かな💦
だから似たようなことは俺も昔は結構指摘されてたよなーと思いながら聞いてたよ。もちろん中には得意なエンジニアもいるけどさ。僕は苦手だったかな・・・」
Sさんが当たり前だと思ってフィードバックしていた論点は、実はエンジニアにとっては当たり前ではない可能性があるということだ。 そもそも、コミュニケーションや人付き合いが苦手なのがキッカケでエンジニアやものづくりを選んでいるという人も多いとのことだし、対面よりもリモートやテキストコミュニケーションを好む人も多い。そういう特徴は、営業と一緒にしてもらっては困るというわけだ。
そう聞くと、学生時代にそれに似た友人がいたことを思い出し、少し分かるところもあった。
不満ではなく納得する。でも疲弊する。
Sさん：「でも、フィードバックはみんな納得してたみたいで・・・」
Mさん：「そうそう、人やスタンスの一般論って、社会通念的な［当たり前］に属する指摘だし、ビジネスや仕事はみんなでやる事が基本なので、反論がしずらく、エンジニア自身も本当に納得している事が多いんだ」
Sさん：「なるほど、じゃあ、俺からの指摘はみんな本当に納得していた可能性はあるのか・・・」
Mさん：「エンジニアにとって当たり前である［技術］については『分からなくても仕方ない』『むしろ分かるように説明すべき』って、Sさんだけじゃなく結構いろんな会社で言われる事が多いんだよね。対して［人／コミュニケーション］については当たり前という位置付けだからさ、改善して当然となりがち。エンジニア自身もそう思ってる事も多い。
でも、非エンジニアが技術の理解に時間がかかるように、多くのエンジニアにとって、人やコミュニケーションスキルを高めて使いこなせるようになるのは、Sさんが思っているより難易度が高い人もいると思うんだよね。うまく伝えられないとか、逆に詰問になってしまって怖がられるとか。
でも人としてなどの指摘は正論なので、言われたとて明確な不満として表に出してくるエンジニアはほとんどいないし、何なら納得して自分を責めて改善しようとさえする。そして疲弊していくんだよね。EMでやっていても、エンジニアのその真面目さが仇となって潰れていく（病む）のをよく見かけるので『そんな難しい事、辛い思いして頑張らなくていいよ、得意な技術やっていいよ』って声かけるんだけどね・・・」
Sさん：「え、そんな大げさな・・・そんな大変なの？」
Mさん：「いやーコミュニケーションは結構大変だよ。コード書いてる方が全然楽しいｗ」
Mさん：「その大変なコミュニケーション力付けるのと、開発スピード両方の指摘をされたってことだよね・・・この難易度をどう説明したらいいかな・・・
ちょっと極端だけどさ『営業として数字のノルマは絶対に達成しなさい』という中で、同時に『技術も全部理解して何なら簡単なシステムも作れるくらいになってエンジニアと専門性の会話についていかないとダメだよ』って言われたら辛くない？いやほんと極端なのは分かってるんだけどさｗ それくらいの難易度なエンジニアもいるってことさ」
Sさん：「いや、まぁ、確かにそれを両方やれって言われたらちょっと自分にはできる自信がないな。技術の理解ってあの黒い画面を理解するってことだよね？分からなすぎて怖いというか、なんか拒否反応出る感じする・・・俺は絶対向いてないって肌でわかる。ノルマがある中でそれやれって言われたら尚更無理だなぁ」
Sさん：「えー、でも、それと一緒？それと一緒のこと言ってたの？そんなに？もしそうならかなり苦しい課題を突きつけていたことになるけど、本当にそんな難しいのかピンと来ないな・・・」
Mさん：「誰だって自分が当たり前にできてることは、他人にも出来ると思いがちだからピンときにくいとは思うけど、確かに、Sさんが、黒い画面に感じる拒否反応に近いかも。まぁ、そういうのも人によるしさ、Eさんにとってもそうだったかは分からないし、少し極端には言ってるけどね。
いやーしかし、コミュニケーション改善を求めつつ、開発スピードは速くしてほしいのか。なかなか現場は辛そうだねー」
Sさん：「おいおい、まるで俺が鬼のような言い草じゃないかｗ」
まぁでも、気を付けているつもりでも、実は知らない間に自分の当たり前という物差しで評価していたのかもしれないわけか。
コミュニケーションコストをどちらに持たせるか
Sさん：そういえば、さっきの極端な例？を聞いた時に、営業やマーケからあがった「専門用語が多すぎる」みたいな不満は「君たちが専門用語を勉強して理解しなさい」と営業やマーケに指摘しする事もできたんだよな・・・当時は全く思いつきもしなかったけど。
Sさん：「でも、であれば、実際にはどっちを指摘するべきだったんだろう」
Mさん：「そこは正解が無いところだよね。考え方がいろいろあると思うけど、僕は結構ドライに考える事にしているんだ。営業に専門用語を理解させるのか、エンジニアに説明力を問うのか、どちらに指摘するにしても［コミュニケーションコスト］の一種だと思うんだよね。コストなのであれば、ビジネス的な側面で考えてる。つまりそのコストをどちらが払った方が合理的なのかはビジネスモデルによって違うはず。それを考えてるかなー」
Sさん：「それでいくと、うちの会社は営業が重要だから、そのコストはエンジニアに払わした方が合理的、つまり合ってたということになるのかな。
いや、でも、今回Eさんが辞めてしまった結果、思っていた以上に『作り手がいなくなると経営にインパクトが出てきてしまうビジネスモデル』だった事を、今は実感してるんだよね。エンジニアにコストを払わせすぎだったのかな・・・分からなくなってきた。」
Mさん：「ま、正解は分からないからね。でも見直すにはいい機会なんじゃないかな。事業も会社もフェーズが変わっていくので、昔合ってたものが、今合ってるとは限らないし。こういう議論を定期的に行う事が大事だと思うよ。」
コミュニケーションコストの大きさ
Mさん：「あと、コストの大きさも考えた方がいいかなー。特にエンジニアとのコミュニケーションと他の職種はかなり文化のギャップが大きい。例えばテキストコミュニケーションで考えると、今でこそSlackとかは営業側でも使うようになってきてるでしょ？」
Sさん：「確かに社内はほとんどSlackになってきたね。取引先とのやりとりも、メールでなくSlackでお願いされることが増えてきてるよ。」
Mさん：「最近はそうだよね。でもエンジニアはもっと前からSlack結構使ってたんだよね。早い人は2013年に出てきたときにすぐ触ってる。10年前だよね。あと、Slackが生まれるずっと前からIRC（1988年）とかコマンドライン上でできるチャットを仕事で使ってたりもしてたので、それでいくとビジネスチャットの文化の開きは30年？
仮にIRC使ってた時代に営業に説明しても必要性含めて理解させるのは難しかったんじゃないかなー。少し極端な例を出したかもしれないけど、まぁ、10年単位でコミュニケーションの文化が違ったりすることもある。他だと、リモートワークとかもエンジニアは早かったかな。」
Sさん：「確かに30年のギャップって聞くと相当だな・・・」
Mさん：「全部がそういうわけではないけどね。でも『理解させる』か『説明させる』か、どちらにしても、そのギャップを埋めるのは思っているより馬鹿にできないコストだって思う。その分負担も大きいし、場合によっては何時間かけても理解してもらえないこともある。10年前の営業に『社内のコミュニケーションはSlackにしましょうよ！効率上がりますよ！』と提案しても興味すら持たせる自信ないなー。どう思う？」
Sさん：「10年前か・・・取引先とは対面で会いに行くのが基本だったし、社内も顔を合わせて話するのが常識だったなー。メールでさえ大変だった記憶があるから、そんな提案、正直やめてくれって感じだろうな・・・
Slackを数年前に初めて聞いた時、メールとの違いが分からなくて捉えるの苦労してた人がそこそこいたんだよね。数年前でそれだから、10年前だと何時間かけて説明してもらっても理解できなかったかもな。なんというか、Slackって文化も含めて使ってみないと分からないとこあるよね。」
Mさん：「その『使ってみないと分からない』ってやつは多いね。エンジニアは結構使って体感してみる事多いからね。でも10年前に『使え』って言われてもSさんは拒否反応出ちゃうと思う。だから触らないでも分かるように説明させたくなると思うんだけど、それをやらせるのって結構時間かかる・・・なんとなく分かる？」
Sさん：「ああー、それはなんというか、あの当時の俺に良さを説明させるのは不毛というか、時間の無駄というか、多分聞く気もないだろうし、やめとけって思うな・・・なんとなく分かってきたかも。」
Mさん：「という感じで、文化や違いを理解させる事自体が難しい上に、エンジニアはそもそもコミュニケーションが苦手な人が多いので、それを求めるのは相当なコストと引き換えになる覚悟をして求めた方がいいと思うんだ。エンジニアであれば引き換えになるのは技術や開発に割く工数だね。だから、それを求めるなら、求めた分の開発スピードの低下は大目に見てあげてほしいかなー」
Sさん：「うーむ…」分からんでもないが、たかがコミュニケーションで少し大げさな気もした。そう思ってしまうところが既に違うのかもしれない。
その③に続く・・・
この記事が気に入ったらサポートをしてみませんか？