「エンジニアを確保しやすい」という理由でプログラム言語を選んでいいのか?

感想おまちしてます!

Twitter    daipresents  チームは今Rubyと戯れているけれど「なんでRuby ...

昨日、プログラム言語についてつぶやいたら、いろいろFBを頂きました。ありがとうございます。つぶやきのきっかけは、ちょうどエンジニアと言語の選択について話をしたからでした。

チームは今Rubyと戯れているけれど「なんでRuby」と聞かれたので「まつもとさんとFBで友だちになった」と答えている 「そんな理由で」っていうけど「初めて配属されたところがJava使ってた」とかいう理由でJava始めるのよりはよっぽどいい話だと思うけどなぁ

よく聞く選定の条件や理由として、「エンジニアを確保しやすいかどうか」というものがあります。これは言語だけでなくフレームワークでも言えることかもしれません。

組織的な視点で考えると、なるほど。気持ちはわかる気がします。ただ、「エンジニアを確保しやすい=いいエンジニアがいるわけではない」ので、「確保できる=プロジェクトが成功する」というわけでもないでしょう。ふと「マンパワーでなんとかしよう」とか「なんとかなる」という楽観的な考え方になってしまっているのではないかと不安になりました。発想が現状維持だから面白みにかけるのかな。

さらに、こういった選定が、若いエンジニアに影響を与えることもあります。例えば「現場がPHP」の場合、入ってきた新人は「PHPを勉強してね」といわれて、PHP人生が始まり、確保しやすいエンジニアに仲間入りします。

私も、はじめの現場がJavaだったからJavaエンジニアからスタートしました。違うのやりたいなぁと思っても、なかなか導入は難しい。かといってずっとJavaエンジニアでやっていこうというほどの気持ちもありません。

結局、言語の選択は何でもいいんじゃないでしょうか。

理想を言うと、作る早さならRuby!安定性ならJava!とか、作るものにマッチした言語を選べばいい気がしますが、そうすると選択肢が限られてくる気がします。選択肢がしぼられるとわくわく感やチャレンジする気持ちが萎えてしまう。

だったら、目的や情熱を持っている人が決めて、それをチームが共感できるのであれば、その言語を使えばいいんじゃないかなぁと思うのです。

ちなみに、「まつもとさんとFriendになったからこれからはRuby!」と僕が宣言したとき、チームはざわざわしましたが、1週間後に簡単なツールのデモを見ることができました。しかもよくできてた。そんなもんなのだと思います。

* 「速さ」は「作る早さ」でしたので追記