フレームワークの経験で採用して空振り三振

エンジニアの採用ジレンマ

エンジニアの採用というのは難しいものです。
エンジニアがエンジニアを採用するのも難しく、
エンジニアじゃない人がエンジニアを採用するのは
さらに難しいと考える人もいるでしょう。
現場で使うツールはすぐに身につけます
そこで頼られるのが、
エンジニアの特定の技術に対する経験です。
Java言語を使っている現場であれば、
Java言語を使った開発を何年やっているか?
まあ当然の自然なこととも言えます。

今日の焦点は、
「うちで使っているフレームワークの経験が
三年あるらしい、これは良い人材では!?」
というような採用基準です。

ここでは、仕組みを構築するアーキテクトではなく、
「業務画面を開発するディベロッパー」
を想定しています。

Emptyなんとかフレームワーク経験三年

人によって変わるので一概に言えず、
断言できないからこそ声を上げづらいのですが、
jfluteの経験から、
なんとかフレームワーク経験三年と言っても、
そのフレームワークに本当に詳しい人は一割くらい...
と言えるような気もします。

色々と聞いてみると、
「開発するための最低限のこと」
だけを知って開発してきただけで、
そのフレームワークのことはほとんど知らない。
A社の車を運転してきただけで、
A社の車に詳しいわけじゃない。

会社は、スキルの低い人、発展途上の人であっても、
成果が出せるような仕組みを作り上げようとします。
きっちり開発できるようになってから仕事では、
ひたすら教育コストばかりがかかってしまうからです。
これも当然の流れです。
なので、(ある程度の研修はしつつも)わりと早い段階で、
現場で成果を上げてもらいながら育てようとするわけです。

なので結局、追求心が高い人かどうか?
その心の強さによって、
その経験三年からどれほどのスキルを積み重ねたのか?
これが大きく変わりますので、
経歴書に「とあるフレームワーク経験三年」
とあっても、着目するモチベーションが
ほとんど上がらないのです。

わずかなコストカット

そのフレームワークを使って開発をしていれば、
そのフレームワークを使った開発がわかっているので、
わりとすぐ現場に投入できるという論理があります。
ただそこは、プログラミング言語に比べれば、
ほんのわずかなコストカットに過ぎないと考えます。

なぜなら、昨今のフレームワークは随分と洗練され、
どんなフレームワークを使っていても、
わりと同じようなインターフェースをしています。
ちょっと表現が違うところはありますが、
それは、車のハンドルの形やアクセルの場所、
ギアの変更の仕方が違うのと同じようなもの、
ちょっとやればすぐに適用できます。

結局、現場フィットレイヤがある

また、実際の現場には現場フィットレイヤがあります。

// フレームワーク選び、現場フィットレイヤを忘れずに
http://d.hatena.ne.jp/jflute/20161214/genbafitlayer

なので、実際には、
同じフレームワークだったとしても、
その現場の独自のルールや、
独自のクラスがどうしても存在します。
減らそうと努力はしていたとしても、
やはり現場は千差万別ですから、少なからず、
その現場を最適化する現地化ロジックが存在します。

なので、結局...
「同じフレームワークの経験者だから、
すぐに現場に突っ込んで開発してもらう」
とはいかず、
どんなフレームワーク使ってようが、
現場オリエンテーションが必要です。

他に大事なポイントいくらでも

フレームワークの経験を全く見ないわけではないですが、
そのほかの要素に比べれば優先度は低と考えます。

コミュニケーションがスムーズに取れるか?
仕事に対する意欲が高いか?
技術に対する意欲が高いか?
チーム開発に向いている性格か?
自ら考えて行動する人か?
仕事の正確性が高いか?
などなど...

(jfluteは、"受け応えができる人か?"
ってのをとっても重視します)

そのときどきによって、
どういうタイプの人を求めるかって変わりますが、
いずれにせよ、フレームワークの経験に比べれば、
遥かに優先度の高いポイントがたくさんあるかなと。

まあ、これらを見極めるのが難しいから、
フレームワークの経験に、
ついつい頼ってしまうのかもしれません。
これは永遠のジレンマとも言えるかも。

すべて程度の問題なので、
フレームワークの経験を見るのがダメでもないです。
単に、そこが強い主軸で他のポイントに
目をつぶってしまうことがデンジャラス。

追求心があるかどうか?

使っているプログラミング言語の経験は、
「フレームワークに比べればさすがに大事...」
ってところはありますが、
でもたとえ、プログラミング言語だとしても、
経験があまり関係ないというケースもあります。

Java言語を使っている現場で、
"Java言語初めて" で入って来た人が、
大活躍してるケースをたくさん見て来ました。
純粋にプログラミングの能力が高いわけですね。
逆にいうと、Java経験三年って言っても、
プログラミングの能力が低ければ意味ないです。

「それを見極められればこんなに楽なことはない...」

「まあ、確かに...」

jflute個人的に大切にしている
ポイントがあります。

追求心があるかどうか?

その心があるひとであれば、
その現場で使うツールはすぐに身につけます。
そういったオリエンテーションを用意していれば、
その吸収スピードはさらに上がるでしょう。
(逆に追求心がなければ、
立派なオリエンテーションを用意していても...)

そして...

経験を考慮するにしても、
その経験をどれだけ語れるか?

聞いてみたいところですね。

...

実際に、PHPしかやったことがないという人が...
「入社前にできるだけ家でJava勉強して来ました!」
そして、jfluteが一週間Javaフレームワークの
現場オリエンテーションをさせてもらったのですが、
あっという間に現場に馴染んでしまいました。

言語もフレームワークも初めてなのに、
おおよそのポイントは抑えていてそれなりの判断もできてる。
フレームワークのコンセプトがすぐに理解できるんですね。
"何か疑問に思うこと" や "教えたこと以上の深いところ" も、
気になったら、すぐに質問してくれて吸収してくれました。

Java経験ないからって採用していなかったら、
ちょーもったいなかったでしょう。

採用とフレームワーク

採用自体の課題はなかなか解決できません。
どうやって見極めるのか???

でも、その見極めの難しいポイントから目を背けて、
単純にフレームワーク経験に引っ張られても、
あまり良い結果がでないだろうと思っています。

一方で、そういうことから、
"採用のしやすいから、このフレームワークを選ぶ"
というのも、(ディベロッパーに関しては)
あまり強い意味がないことだなぁと感じます。

...

アーキテクトは除外した話にしていますが、
ディベロッパーに比べればアーキテクトの方は
もう少し重視したいポイントではありながらも、
"このフレームワークでしかアーキテクチャを
構築できないアーキテクト"
だと。またちょっと弱いかなと。

もちろん、
このフレームワークだとやりやすいとかやりにくいとか、
やりたいかやりたくないとか、色々と偏りは出るでしょうが、
要は、覚悟決めて追求してくれる人かどうか?
jflute個人的には、アーキテクトであれば、
こういう "ちから" がある人を重視しています。

// アーキテクトのちから | jfluteの日記
http://d.hatena.ne.jp/jflute/20150113/architect

...