エンジニア離脱の原因
ふて寝するほど話したい。この番組は、システム開発25年の株式会社プラムザが、赤坂より開発現場の今と本音をざっくばらんに話していこうという番組になります。
進行は私、鴨志田と、代表の島田と、賑やかし役の辰巳です。よろしくお願いします。
では今回のタイトルなんですが、「エンジニアがいなくなるプロジェクトの特徴」というタイトルになります。
ちょっとこの収録を始める前に、少しだけ打ち合わせをさせていただいたんですが、今回に関しては、システムを作っている開発会社の話ではなく、新しく社内の業務施設を自分たちで作ってみようという会社さんがプログラマーとかエンジニアを雇ってやる際に、
こういうことの、こういうプロジェクトだったり、こういうたてつけだったりとかするとエンジニアいなくなっちゃうんじゃないの?みたいなことを話していければというふうに思っているんですが、この認識で合ってますかね?島田さん、合ってます?
そういう話だよね。
実際やっぱりエンジニアが離脱してしまうっていうことは、経験上あるものなんですかね?どうでしょうか?辰巳さんお伺いしてもよろしいですか?
いや、全然ありますよ。我々は開発会社なんで、ちょっとこれから話していこうとするパターンとは違いますけど、全然あります。
こちら側からちょっとごめんなさいすることもあれば、あちら側からごめんなさいされることもあるっていう感じですかね。
今はそんなこともほぼほぼ減りましたけど、昔は私も若かったんで、衝突はたまにありましたね。
そうですね、新しく自分たちで作ってみようという会社さんの話をしていこうということなんですが、そもそも開発会社の中でもそんなことがあるので、
一通に考えたら経験がない会社さんであれば、なおさら気をつけるところが多いのかなと思うんですが、島田さんいかがでしょうか?
上流工程と評価
エンジニアがいなくなってしまう、もしくは業務システムを自分たちで作ってみようという時に、こういうプロジェクトだとエンジニアさん離れてしまうんじゃないかみたいな、
実例は難しいかもしれないですけど、特徴とかあればお伺いしたいんですが、いかがでしょうか?
そうですね、いなくなっちゃったんで、うちに後お願いしたいとかっていう話も結構来るんですよね。
なるほど、なるほど。
基本的に開発会社じゃない会社がエンジニアを雇って作ろうというのはよくあって、その方がお金を払っているから融通効くんじゃないかみたいな、そういう発想でチームを作っていくんだと思うんですよね。
一番そこが普通の一般の会社さんにとって魅力的なところだと思うんですよね。
開発会社だと契約書を作って、こういうシステム作りますみたいな、いつも言ってるけど要件提示して三つ文字書いて、そこでスタートするんだけど、実際エンジニアといえばそんなことないので、開発の企画からずっとエンジニアに参加してもらって、いくらでも時間をかけていいしということになりますよね。
そこがエンジニアの考えていることと、エンジニアじゃない会社のエンジニアじゃない管理職の方が考えているのとちょっと違って、結構乖離がありますよね、随分ね。そこでうまくかみ合わないと辞めちゃうってことなんじゃないですかね。
なるほど。乖離っていうのはシステム的にどうできるのかというのと、こうしたいっていうことの相互がやっぱり大きいっていうことになるんですかね。
エンジニアの人はエンジニアなんで早く作りたいわけですよね。決めてくれと何作るのか、そしたら作るからみたいな、そうなりがちですよね。
だけどそうじゃない管理職の人とかは、そういう話の前にシステムどうあるべきかみたいな、今何がどう困ってるんだっけみたいなね、そういうところをじっくり詰めていきたいと思うわけですよね。
だから全然興味の対象は違うっていうか。
基本的にエンジニアさんでそこら辺のいわゆる上流工程っていうことになるんですかね。要件を決めたり、こういったものが必要だよねって詰めていくことができる人の方が基本的に少数だと思っておいた方がいいんですかね。
それはそうですね、と思いますよ。いますけどね、そういうのが得意な人もね。うちのCTOとかそういうのが得意なんですよね、あれね。
でもやっぱIT人材の一番不足しているポジションは上流の人らしいですね。
上流と下流が両方できるってすごいレアだからね。
レアですね。
僕もそうですね、島田さんのお話を聞きながら自分の考えを整理してまして、マクロの要因とミクロの要因に大きく分けられるかなと思っていて。
例えばですけど、新しく入ってくる人とかはエンジニアは特にそうだと思うんですけど、やっぱりカルチャーフィットしなかったりだとか、どうしてもやっぱり正社員で入ってくると思うんで。
SESとかだったら別かもしれないですけど、それは想定しないで考えると、エンジニアってとても評価軸が曖昧と言いますか、営業とかの人に比べるとですね、成果が出にくいんですよね。
プルリクエストとかコミットの数が多ければよかったかっていうと、それもそうではないと思いますし、それを人事の人たちがうまく評価軸で言語化、数値化するってかなり難しいと思うんです。
なので頑張ったことがちゃんと評価されなかったりだとか、あとはそもそも頑張れる環境がないっていう状態は結構危険信号なのかなっていうのがマクロ側でございます。
マクロでいうと、先ほど島山さんがおっしゃったように、仕様がプロジェクトとして決まってなかったり、方向性とかゴールが見えなかったりすると、エンジニアだけに限らないかもしれないですけど、疲弊しやすいんですよね。
何やってんだろう、今みたいな。結局責任の所在がないんで、じゃあこのコードを書いてけれども間違ってるじゃんみたいな、全然意図通りになってないじゃんってなった時に、じゃあこれは誰の責任なの?
ところになったりすると、そこで不要なコミュニケーションが発生してしまう。戦争になりますよね。
なるほど。一つ島山さんの話からは、上流工程と実際の構築っていうんですかね、エンジニア下流工程ができる人がいれば、もちろんそれはベストだと。
基本的には少ないので、そこでミスコミュニケーションが出てしまうっていうのが往々にしてある。そういうプロジェクトではエンジニアが離れていってしまうと。
最近こういうことをやるよっていうことを詰めてくれっていう現場というか、プログラマーさんの要望が最初に整わないということと、
成長と責任の所在
辰巳さんが話していただいて、すごく納得感があったのは、確かに評価はとてもしづらい。特に経験がない。
上流工程ができるとか、こんなことをしたいっていう設計とかがあったとしても、それを評価できる人間もなかなか普通はいないというところは、確かにミスコミュニケーションの温床になるとか評価しようがないですもんね。
バグがないシステムを作るとか、実装が早いとかっていうのも定量化しにくい気がしますけど、それこそプラムザって昔社員を抱えてましたけど、その当時どういうふうに島田さんは評価してたんですか。ちょっと観点が違うかもしれないですけど。
開発会社は違うんで、やっぱり対応できる言語が多いとか、バグがないとかってそれは見てればすぐ分かるので、ソースの中を見てるからね。一般企業の場合って基本的にソースの中を見てる人がいないので。
だいたいスタートするまでにすごい時間がかかるし、成果物を評価するまでに至らないよね。アルファ版、ベータ版ってできてくるまでにやっぱり2年とかかかったりするんで。普通じゃないけど、エンジニアは飽きちゃうっていうからずっと同じシステムばっかりやらされて、あれもない、これもないっていう会議に付き合わされてるとね。
それでいて上流の仕様決めとかに踏み込んでいけなかったら、結局何してるのお前って言われかねないですよね。
そうそう。だから自分でも成長してる感じが実感が全く湧いてこないっていうのもあるだろうし。
確かにその上流好転を受ける責任の所在っていうところも辰巳さんから話が挙げていただきました。確かにそれはすごくありそうですよね。
ある種エンジニアさんのケツを叩くとか、クオリティを担保するっていうところができる人、ソースコードの確認も含め、バグとかの確認も含めできる人がやっぱり普通の会社にはいないんだろうなという印象ですね。
そこでかつて話した気もしますけど、コンサルト雇ったりするとそれでさらにこじれちゃうケースもあったりするんで。
なかなかですし、以前飛ぶエンジニアの特徴みたいな話をした気がしますけど、そういうエンジニアがいてしまうともうがんじがるめになってしまいますよね。飛んでしまうよね。プロジェクトとしてもそうだし、エンジニアとしてもそうだしみたいになってしまうので。
これでも一般のシステム開発の経験がない会社さんが直接エンジニアを雇ってうまくいく方法とかってあるんですか?どうなんですかね?
うまくいくんですかね?これね。うまくいく気がなんか話しててしないですよね。
分かってる人がいるっていうのは強いですよね。例えば重役の中に一人でもあいつの経験があるとかですね。そういう視点で会議でもまとめていってぐいぐい進んでるというのが実感できれば、あの人がまとめてくれるから力になりたいなって思うかもしれないですけどね。
それかやっぱり開発ができる段階になったら短期的にSESでエンジニアのリソースを確保するとか。
大きな要因として責任を持てる上流工程の人間がいないっていうところがすごく大きそうだなって思いましたね。
島田さんの今何とかする案として、社内にいい人いればいいよねっていうところはまさしく上流工程の責任者がいるっていうことだと思うんですけど、そこがないと厳しいものなんですかね?
そうですね。だけどそういう発想のない会社だと、ワンマンのちょっと大きい中小企業とかだとそういうことはなくて、技術がわからないから社員のエンジニアを雇って会議に参加してもらおうっていうそういう発想になってるんで、そこは初めからミスフィットしてる気がしますけどね。
最初から上流工程までできる、その会議に参加してもらったエンジニアさんが上流工程も理解して下流工程もできるっていうことであればうまく回るのかもしれないですけど、それはそもそも確率がかなり低そうっていうところですし、やっぱり分かる人間を入れる、外部にしろ内部にしろ分かる人間を上流工程に置く、その人に責任を持ってもらうっていうことなんですかね。
それがないとエンジニアが飛ぶというか、プロジェクトはそもそも進まないっていうところですよね。
そうですね、確かに。
実装に入っていくまでにすごい時間がかかるだろうね。
でもさっきも言ったけど、エンジニアは本当に成長してないと成長が実感できないと焦ってくるんで、それはやめるパターンですよね。
確かに。
プロジェクト何年も関わったのに何も身につけられなかったっていう。
そうそう。
感じになっちゃうと、客観的に見てもダメだから全然使われなかったのかなって思われかねない、いろいろマイナスな面が出てくると思うんで、早々にやめて他のところに行ってしまうってあるかもしれないですね。
確かに、ちょっと仲良くなった、腕が良いなと思うプログラマーさんって飽きるとか飽きちゃうんだよねっていうことを結構言うような気がしていて。
やっぱり成長とかやりがいとか、そういうところが優秀な人ほどそういう要素というか性質強いのかなっていうのは個人的に思っていますね。
いろんなことやってみたいっていう人がやっぱり力つけてくるしね、エンジニアとしてはね。飽きるってのはあると思いますけど。
だいぶ話は飛んだり、いろいろ移動したりしてますが、エンジニアがいなくなるプロジェクトの特徴っていうふうに考えると、今のところかもしれない中では上流肯定ができる人間とかそこの責任の所在があっていうところかなと思ってるんですが、他にこういうプロジェクトは危ないよみたいなものとかってあったりします?どうでしょう?
プロジェクトのリスク
丸投げされてそれを拾ってくれないみたいなね、いうのもありますよね。
それはあれですかね、例えば社長さんがここをやっといてっていうところをするされるみたいなことですかね。
よくわかんないけど、ちょっと一回作ってみてとか言って、一生懸命作ってみたら違うなーみたいな。
確かに、これ普通にクライアントさんから言われることですけど、なんかいい感じにしておいてって言いますよね。
我々は臆病っていうか、なるべくロスが出ないように作り込んでいかないじゃない。そう言われてもワイヤーで済ますとか。
そういうことがなくて、社員だからね。ガーって突っ込んでいっちゃうと思うんだよね。今時間中だからさ。やるのが仕事って言われたら。
それで一生懸命作ったけど全く違うなーみたいな感じで、お前業務わかってないだろみたいなこと言われるとあれだよね。相当ショックを受けるよね、きっとね。
それはもういなくなるプロジェクトの特徴と言ってもいいかもしれないですけど、評価軸がはっきりしてないとか。
プロジェクト全体としてコスト感覚がないっていう感じですかね。
なるほど。では、もろもろザックバラに話してきたわけですが、こういう問題を解決するためにプラムドがあるのかなと、ざっくり言うとそう思ってしまうっていうところがありますかね。
やっぱり第三者が入る、そこの誰が責任を負うのかっていうことを明確にしとくってことはすごく大事なんだなって改めて思いましたが、島田さん認識ずれないですかね。
うちにお任せください。
ありがとうございます。本日はいかがでしたでしょうか。楽しんでいただけましたらフォローや評価をお願いします。また、Xでも最新情報を順次発信していますのでよろしくお願いします。
システム開発に関するご相談がございましたら、公式ホームページからお気軽にお問い合わせください。それではまた次回お会いしましょう。
ありがとうございました。
