![見出し画像](https://assets.st-note.com/production/uploads/images/136352759/rectangle_large_type_2_1a162249001fde2b7b751c28b2c86b6c.png?width=1200)
なぜあなたの会社はエンジニアが辞めてしまうのか?その⑥
はじめに
この記事はその①、その②、その③、その④、その⑤の続きのお話です。まだ読まれてない方は必ず先にその①、その②、その③、その④、その⑤を読んでから読んでみて下さい。
登場人物の紹介
その①でも紹介しましたが、今回は対話形式で書いてみたので、登場人物だけ紹介しておきます。3人登場します。(②話目以降はほぼ2人ですが…)
エンジニア:Eさん
Eさんの評価者:Sさん(非エンジニア)
Sさんの友人のエンジニアマネージャー:Mさん
![](https://assets.st-note.com/img/1707124931383-I4GxUF2EnZ.png)
簡単なあらすじ
Eさんやエンジニアから退職され、途方に暮れたSさんは、元同僚で今は別の会社でEM(エンジニアマネージャー)をやっているMさんと飲みに行って相談して、これまでの経緯を聞いてもらって、コミュニケーションを中心にいくつかアドバイスを貰ったのでした。詳しくはその①、その②を読んで下さい。
Sさん:「実はさ・・・カクカク・シカジカ・・・何が駄目だったのかな・・・」
![](https://assets.st-note.com/img/1707124931302-wiaRpyaDaD.png)
そのあとMさんからいくつか意見(その②、その③を読んで下さい)を貰ったあと、その意見を元に実践してみたのですが、エンジニアの退職が止まらず、もう一度Mさんを誘って話を聞いてもらった(その④、その⑤を読んで下さい)のでした。
強い方と弱い方をコントロールする 続き…
対策その③ 他の職能チームのエンジニア比率を上げる 続き…
Mさん:「『エンジニアチームに必要』という文脈ではなく『マーケにエンジニアが必要』或いは『営業にエンジニアが必要』という感じで、エンジニアの人件費をプロフィット部門にしておくのさ。こんな感じだね」
![](https://assets.st-note.com/img/1707125229159-tFfLLpH64k.png?width=1200)
Mさん:「そうすれば、経営陣も営業/マーケは経営的に数字に跳ね返りそうな見え方になる事が多いので、『ああ、リターンも見込めそうならいいんじゃない?』となりやすい。」
Sさん:「あー確かに、それは通る想像が付くな。でもそうなると各職能チームのトップがエンジニアをマネジメントするってことだよね。俺みたいに失敗する人続出にならないかな・・・」
Mさん:「確かにそれは気をつけておかないといけないよね。でも、もうSさんは大丈夫でしょw 一つは今回みたいに、非エンジニアの上司の理解度を上げることからかな。
とはいえ、理解できない人が多いのも現実だと思うので、そういう場合は、例えば所属は職能チームでも、技術評価のラインはCTOやEM、VPoEとかにお願いするとか、横串の交流を制度的に増やしておくとか、いくつか手はあるよ。」
Sさん:「ぬぉー、結局それをやるにもまずはCTO、EM、VPoEを増やさないとってことじゃないか!」
Mさん:「まてまて、よく聞いて。確か今ってSさんの会社にもCTOはいるんでしょ?もしCTO配下に全員付けるとパンクするけど、レポートラインはマーケや営業にしておいて、CTOは『技術などのエンジニアの特徴に関連した評価のみを兼務』みたいに分散すれば、CTO1人の見れる評価範囲を増やせるということもあるよ。レポートラインだけ作っておけば、いけてない非エンジニア上司の不満もCTOに言いやすい。
あと、やっぱりエンジニアは技術を評価されたいという気持ちも強いので、CTOに評価に絡んどいてもらうのはオススメだよ。」
![](https://assets.st-note.com/img/1707125524093-YgU2Zue9dr.png)
Sさん:「そうか、それならできそうな気はする・・・」
Mさん:「あと、そうやって分散して、上司からのストレスを軽減できても、例えばマーケの中に1人ポツンとエンジニアがいる状況は孤立してストレスを吐きにくい可能性はあるので『勉強会』などの横串の交流を制度的に増やす、という手も有効だね。こういった企画は、ほんとはEMがいるとやりやすいけど、いなくても、現場のエンジニアに聞くと結構いいアイディアが出てくると思うので『勉強会やりたい?やっていいよ』と言ってあげるだけである程度カバーできるかな。」
![](https://assets.st-note.com/img/1707125625670-bN7noh4wwA.png?width=1200)
Sさん:「なるほど、でも業務時間内にやらせるのはうちだと厳しいかもなー💦
あーでも、僕の管轄の中ならある程度はいけるかな、頑張ってみるか」
対策その④ 他の職能チームのITリテラシーを上げる
Mさん:「頑張ってみてよ。あとは、それでも人数がどうしても増やせないなら、マーケや営業一人ひとりのITリテラシーのベースを底上げするという方法も少しは効果はあるかな。例えば今こんな感じだったとするよね。営業としての専門性のみ持っている状態。」
![](https://assets.st-note.com/img/1707125693839-uGrks6UFtB.png)
Mさん:「その一人ひとりのITリテラシーを増やすという作戦だね。具体的には、採用や評価基準にITリテラシーを組み込んでおく。採用であれば『SQL書けるマーケ』とか『元エンジニア出身のマーケ』とか、『エンジニアとしては経験が不足しているけど、マーケとしてはITリテラシーある方』みたいな人を採用して、そこに苦手意識のある人とを入れ替えていく。評価も同様だね。ITリテラシーを持ってる人をプラスαで評価していく。こんなふうにしていくイメージ」
![](https://assets.st-note.com/img/1707125731162-ZxSxcT47pm.png)
Mさん:「最近は市場にもこういう人が結構増えてきてるし、一人前のエンジニアを採るのとは別のセグメントとして募集を出せるので、採用面でもメリットがあると思う。まぁそうなると、もちろん『評価する側の上司もITリテラシーが高くないとだめ』というのはあるけどね。でも一応、同じ職能として評価できるから、マネージメントの難易度は下がると思うよ。」
Sさん:「なるほど『5人の営業チームそれぞれに、エンジニア要素が0.2ずつ増えれば合計で1人分のエンジニアになる』みたいなイメージかな。人だからそんなにうまく割れないとは思うけど、専門のエンジニアをマネージメントするよりは想像しやすいかも。
しかも、そういう層が市場にも増えてるのであれば尚現実的かもな」
Mさん:「結構増えてるって聞くよ。最近も情シス互助会Slackのコミュニティでさ、経理の人が入ってきて
『今後は経理もIT設計をできるようにならないと考え、経理×ITのキャリアを歩もうと試行錯誤し始めたところです(だから情シスのコミュニティに来た)』
という挨拶をしてて、数人が『私も今経理で・・・』と共感コメントしてた。
経理ですらそれだから、マーケや営業はもっと進んでるんじゃないかなー。」
Sさん:「なるほど、うちだとまずそれが現実的かなー・・・。ってことは俺が覚えないといけないのかw」
Mさん:「ま、そういうことだね。頑張って(笑)Sさんなら大丈夫さ。」
Sさん:「また他人事だと思って(笑)」
Mさん:「ちなみに、ついでなんで、どの職種でも必要という考え方をいくつか紹介しておこうか。ポール・グレアムという人が書いた『Yahooに起きてしまったこと』という記事があるんだけど、その中で、マーク・ザッカーバーグ(訳注: Facebook開発者)が2007年に起業スクールで『Facebookは早い時点から、人事やマーケティングのような、プログラミングが主な仕事ではない職種についても、プログラマーを採用すると決めました』と言った事を紹介してる。」
Sさん:「うわ、2007年って相当前じゃん・・・さすがアメリカ、早いな」
Mさん:「日本でも、最近の大手のIT企業だと、実際に人事の中にエンジニアチームがあったりしてるね。サイバーエージェントさんとか。」
Sさん:「なるほど、日本でもIT企業は進んでるね。ってうちもIT企業のはずなんだけどな・・・」
Mさん:「あとはオバマさんが大統領だった頃の演説だね。この動画も2013年でそこそこ古いけど有名かも」
『 コンピュータ・サイエンスのスキルを身につけることは、皆さん自身の未来のみならず、私達の国の未来にとっても、大事なことです。アメリカという国が最先端であり続けるためには、皆さんのような 若いアメリカ国民に、今後の世界のあり方を変えるようなツールや 技術について学んでもらわねばならないのです。初めからコンピュータ・サイエンスの専門家の人なんていません。 しかし、少しの努力と数学と科学の知識で、誰でもコンピュータ・ サイエンティストになることができます。コンピュータは皆さんの未来の大部分を占めることになります。』
Sさん:「あーこの動画見たことあるかも」
Mさん:「あとは、昔、僕と一緒に仕事をしていた、めちゃくちゃ成果を残したマーケのスペシャリストの人がGoogleに引き抜かれた事があってね、その人にGoogleの感想を聞いてみたらさ『Googleのエンジニアの方が僕よりマーケティングに詳しい』って言ってたんだよね。つまりさ、Googleのそのエンジニアは、開発とマーケティング両方の知識があるってことだよね。まぁ、もちろん人によると思うし、若干極端ではあるけどね。」
Sさん:「まいったなー。アメリカはだいぶ前からそれが当たり前になってきてるってことか。日本は遅れてるってよく言われるけど、ほんとだね。俺もやらないとだめか。
いやー勉強になったけど重いな・・・とりあえず今日はありがとうと言っておこう。」
Mさん:「うん、どういたしまして。あー、でも、これだけやったとしても、退職者は出るかもね」
Sさん:「おいおい!!??ちょっとまて!どういうこと?
今までの説明はなんだったんだよ∠( ゚д゚)/ どういうことか教えろ!」
Mさん:「あはは、ごめんごめん、今までの話が無駄ってことじゃないんだ。
今までの話は言うなれば基本っていうかさ、エンジニアの特徴や、技術/ITを『分かろうとする』とか『興味を持とうとする』っていうものだったと思うんだけど、もう一つ重要な要素があるんじゃないかなと思ってるんだ。」
Sさん:「重要なこと?」
新しい挑戦ができる環境か
Mさん:「Eさんの退職理由、新しい挑戦って言ってたんだよね」
Sさん:「そうそう、でも今まで話聞いてきたら、平穏に退職するために、俺の納得しやすい理由を作っただけで、本当はコミュニケーションとか辛いところがあったのかなって思ったんだけど」
Mさん:「それがあながち、コミュニケーションだけでもなくて、本当に新しい挑戦がしたかったんじゃないかな、というのがもう一つの観点だね。」
Sさん:「挑戦?でも、内容聞いたら、うちでも出来そうな事だったんだけどな」
Mさん:「それそれ。『うちでもできそう』と『君にお願いしたい』は全然別ものだからね」
Sさん:「どういうことだい?」
その⑦に続く・・・
この記事が気に入ったらサポートをしてみませんか?