ネタ元: 「エンジニアをつくる」という理念掲げていたら、エンジニアが社内からいなくなった件 | 新田章太の「エンジニアをつくる」ブログ
話の発端は、 俺がDMTCについて知ってること，またそれに対する所感 - 職質アンチパターン がFacebookで話題になっていて、やばいなぁと思っていたら主催者もやばかったみたいな話。
内容自体ただヤバイんだけど、その中でも明確にツッコミを入れておきたい部分があった。
僕らの強みはDMTCを通じて、沢山のお客様とのつながりがあること
このつながりを活かして、
国内外のIT企業で働くエンジニアのスキルを定量化しよう
というひとつのテーマにいきつきました。
http://maximum80.me/archives/821
この部分についてFacebookで俺はエンジニアをバカにしてるって書いたけど、もうちょっと具体的に落としこもうと思った次第です。
ものさしに対するwizardとかguruとかの存在
定量化となると数量などで物事を測る必要があります。
ものさしですね。
例えば、AさんのLDAPのスキルは80ポイントとか。
上限を持つかどうかによっても変わるんだけど、上限を持ってるパターンと上限がないパターンを両方想定してみる。
ハッカソンをやってるっていうことは当然ある程度ハッカー文化についても調べていると思うんだけど、世の中にはwizardとかguruみたいな人がいます。
仮に僕のLDAPのスキルが100ポイントだとします。
僕のLDAPの経験は20台ぐらいの仮想サーバで構築されているWebサービスを僕だけで構築した上にLDAPでアカウントとかを適切に設定するとかそんな程度です。
わりと普通のインフラエンジニアのスキルです。
この場合で上限がないパターンを考えた時に、僕の知る限り一名ほど5000ポイント超えてるよねみたいな人がいます。
誰とは言いませんが、普通のエンジニアに比べるとどうしてもそのぐらいのスキルだよねーみたいな人結構います。
でも、その人が僕の約50倍働くというわけではないです。
あくまでスキルの違いがそれぐらい差があるというだけです。
エンジニアのスキルは天井がないようなものです。
そういう人たちがwizardやguruという人たちです。
さて、次に上限を設けた場合がもっと嫌なパターンです。
たぶん、この手の経験でいうとわりと現場で使えるレベルのものを僕はやっているので、一般的な求人とかで上限maxぐらいの位置にはいそうです。
しかしながら、さっき言った上限のないパターンで5000ポイントある人も僕と同じ条件になってしまいます。
ですが、明らかにやれることが全く違います。
むしろ同じにされると困るのです。
だって、「同じ数字だからお前を雇ったのにぜんぜん違うじゃないか」とか言ってくるんでしょう？
じゃ、そうならないように上限をそのwizardの人に合わせてみましょう。
wizardの人が100ポイントで、僕が2ポイントとなります。
カスですよね。
結局このような数字があることは雇う側も雇われる側も不幸なだけです。
そして、これらの数字は雇う側の都合でしかないのです。
スキルの上下
次に僕が言いたいのはエンジニアのスキルがあっさり上下するということです。
僕はさっきLDAPの例で仮に100ポイントとしましたけど、この数字自体は僕がその現場に居た頃の話です。
二年半ぐらい立ちますので結構忘れてることが多いのです。
たぶん、40ポイントぐらいまで下がってると思います。
しかし、またその現場に戻れば100ポイントに戻せる事ができるという自負はあります。
それでも、それは「その現場」の数字です。
例えばLDAPでも要求されることが変わればある程度やらなくて済むところも出てきますし、台数とかでもコツとか変わってきます。
それこそもっと大規模な構築が必要とされる現場に行けば200ポイントとか300ポイントとか行くんじゃないでしょうか。
つまり、スキルというものは外的要因が強くあるところがあります。
それによってあっさり上下するものです。
ポテンシャルの話
スキルの上下と同じような話なんだけど、エンジニアのポテンシャルについても言及する必要があると思います。
僕自身Ruby on Railsをメインとして扱っていて、経験も豊富な方です。
ここでも仮に僕のスキルを100ポイントとしましょう。
ですが、仮に僕の知ってるとあるAさんが仕事で必要だったりして一週間Ruby on Railsについて勉強しだしたりします。
勉強前はまったく経験がないので0ポイントであっても、その一週間で500ポイントぐらい行くだろうと思います。
そもそもバックグラウンドが全然違いすぎます。
経験豊富なエンジニアでかつ恐ろしく高度なところで戦ってる人はわけがわからないぐらいポテンシャルを持っています。
正直、そんな人を定量化とかしたって意味が無いんです。
だって、その人できるんだもん。
現場の話
最後に現場の話をしましょう。
ここは完全に僕の経験からの話です。
若いエンジニアと一緒に仕事をした時のことです。
そのエンジニアは周りの人はそこまでいい評価をしていませんでした。
今でも良い評価はほとんど耳にしていません。
しかし、僕はそのエンジニアと一緒に仕事をしたときに長所と短所がありました。
短所はよくミスをすることです。
たぶん、それが周りの評価が悪い原因だと思います。
しかし、長所は恐ろしくコードを書くスピードが速いのです。
僕が考えてる間にコードが出来上がってることがしょっちゅうでした。
ただし、僕の場合は考える時間が長い方というか考えすぎなところもあったりします。
周りがどう思ってるかわからないのですが、僕は仕事が遅い方だと感じています。
しかし、そのエンジニアとペアを組んだ時に良い作用が働きました。
そのエンジニアがコードを書いて、そこから間違えを見つけたり設計手法でより良いものを教えたりと、懇切丁寧にやっていきました。
すると、一緒のペアの時にそのエンジニアが少しずつバグが少なくなり、書くコードも良くなっていきました。
結果としてこのペアが相性が良かったと思います。
そのエンジニアがひっぱっていくことで、仕事もわりと順調に進み、すごく良い仕事ができました。
この成功体験の結果、ついでに僕のうつ病も治りました。
現場ではいろんな作用があります。
一緒にいる人が良ければ良くなることも、悪ければ悪くなることも、どっちでもないこともあります。
仕事をしている以上アウトプットは必要です。
そのアウトプットのためにいろんなできることがあります。
現場では常に工夫が必要です。
工夫次第ではダメなこともあります。
「これこれができるエンジニアを連れてきた」
よくある話だけど、「これこれができる」からと言ってその後一緒にプロダクトを作る能力があるとは限らないのです。
定量化された数値を元にエンジニアを連れて来られても、その人が書いたコードが駄目すぎて「なんで雇ったんだクソが！」みたいなのはしょっちゅうです。
でも、ダメなコードを書いていても現場で育てることができればそれは勝ちですし、価値があります。
数字ではその人の長所短所は示せないのです。
システムはエンジニアがというよりも「人」が作ってるものだということをちゃんと理解しましょう。
