はてなでスキルの数値化について考えたこと
先日、はてなさんでランチをごちそうになりました。
なんの話かというと、Twitter経由で参加者募集の記事をみつけて、CodeIQの仕掛け人であるサカタカツミさんのお話がきけて、噂にきくはてなランチが食べられて、Tシャツがもらえて、参加費無料とかめっちゃおいしい話じゃねーの！ と思って、募集枠が15人だけだからどうせ無理だろうな、と思いつつ応募してみたら、なんか当選メールが届いたので行ってきた、ということです。
まあ、めっちゃおいしい話には裏……じゃなくて、ちゃんとスポンサーさんがついてるわけですが、そこは、参加者募集の記事を読んでいただければわかります（←こういうことを事前にチェックしとくと後で腹を立てずにすみます）。
まかないランチはとてもおいしかったです。料理上手なお姉さんが丁寧につくってくれた手料理って感じです。このランチ目当てに転職したい、って言われたら納得する！
はてなにお勤めの皆様は、いつもあんなにすてきな風景を眺めながら、あんなにおいしいランチを食べていらっしゃるんですね。本当にうらやましいです。
ここからは、イベントのメインだったサカタさんの「エンジニアのスキルと給与の相関性（仮）」という講演について、ちょこっと書いてみようかと思います。
給与というものははっきりとした指標です。しかし、エンジニアのスキルというものに、今のところ誰もが納得できる指標はありません。
「スキルと給与の相関性」という話をする場合、スキルの方もある程度、数値化できていないと、相関性があるのないのという話にもこぎつけられないということで、企業側はエンジニアのスキルを評価するのに苦労している、というお話がメインでした。
ここででてきた、最新のプリクラなみにデコった業務経歴書に振り回されることにうんざりしている人事サイドのお話には、苦笑させられました。わたしもみたことがありますよ。「ぎりぎり嘘じゃないような気もするけど……う～ん……」ってやつ。
資格試験は「どれだけ覚えているか」くらいしか測れない、最近よくみるコーディングスキルのテストはプログラムを書く能力くらいしか測れない。でも、エンジニアのスキルを構成するものはそれだけではないから、そこだけで判断するわけにもいかず、デコられた業務経歴書からなんとか真実を読み取ろうと必死になっている、という状況に採用サイドは不満を抱えている。それを打開するために、複数の企業がエンジニアスキル計測用のテストを開発していて、いずれ皆さんが目にすることになるだろう、という話でした。
これって、ちょっと実験台になってみたい気もしますね。どんなテストを持ち出してくるのか興味あります。
それで思い出したのが、ジェラルド・M・ワインバーグという方の『プログラミングの心理学』という本でした。この中に、プログラマに向いている人を探すための性格診断テストをつくろうとする人たちと、それを鼻で笑ってるプログラマたちのエピソードが出てくるんですが、この本の初版が1971年で、つまり40年も前のアメリカでも似たようなことをやっているんですよ。
コードの自動生成と、プログラマのスキル可視化は経営者の夢なんですかね。どんだけプログラマの扱いに困ってるんだよ、って感じですが。
このテストに対する今からできる対策は実にシンプルで、「がんばって仕事をしてスキルを身に付ける」だけだそうです。
テストの判定結果が意外と確度が高いものだとしたら、それなりに仕事ができる人なら特別なことをしなくても高い点がとれるし、確度が低かったらテスト自体がすぐに廃れるから問題ないわけですね。
さて、次に紹介された、エンジニアスキルの数値化の手法は、海外では実際にサービスが開始されているらしい、ブログ、Twitter等のSNS、QA@IT等の質問サイト、その他もろもろのネット上にころがっている情報をがさーっと集めてきて解析、ポイント化して、エンジニアをランク付けする、というものでした。
これはテストと違って本人の同意なく行われますから、知らないうちに数値化され、採用や査定の判断材料として使われていた、なんてこともありえるようです（←ちょっとコワイ）。
この数値をあげる対策としては、ネット上に自分の足跡をつけていくしかないとのことで、それをしないでゼロ査定になるのが一番まずいというお話でした。
わたしなんてこのコラム以外ではアニメとマンガのことしか書いてないから、ゼロ査定になるんじゃないの？ と思ってめっちゃ心配になりましたよ。これからはTwitterでもプログラマっぽいことをつぶやいてみます。「C++さんがわたしに冷たい！」とか（←ゼロどころかマイナス査定になりそう）。
テストにしろネット情報のポイント化にしろ、ある日、突然がんばってどうにかなるもんではなく、地道にこつこつ積み上げるしかない、ということのようで、なんだかんだでものすごくあたりまえのところに落ち着くもんなんですね。
まあ、そうでなかったら困る、という気もしますが。
エンジニアスキルを数値化するという話が、エンジニアを幸せにするのか不幸にするのかは、正直わかりません。けれど、参加者の方が「基準がよくわからない上司の評価だけで全部が決まるよりはましだと思う」的なことをおっしゃっていて、これにはものすごく納得しました。
他にもいろいろなお話をうかがったんですが、ヤバいんで書かないでねって言われたとか、細かいとこ忘れたとか、いろいろあるんでここらへんで切り上げておきます。
エンジニアをどう評価するのか、という問題は、いろいろと文句は言いつつも真面目に考えたことがないテーマだったので、いい機会をいただけました。
信頼性の高い指標が出てきてくれれば、年齢の壁が少しは下がってくれるんじゃないかな、という希望も湧いてきましたし（笑）。
イベント関係者の皆様、いろいろとお世話になりました。本当にありがとうございました。
サカタさんや他の参加者の皆様と、おしゃべりができて楽しかったです。ではでは。
コメント
仲澤＠失業者
老人プログラマの仲澤です。
当たり前ですが、低スキルの人は高いスキルを持つ人を「どのくらい高いか」判定できません。
物差しの長さが足りないからですね。
逆に高みから望めるならば、その人のスキルはわかります。
以上の事実から、全ての人のスキルを測る物差しを持っている人は、
測定対象の全員より高いスキルを持つ人である。
ことが導けます。
これは、なかなか難しいですが、まったく不可能というわけでもありません。
そういった高スキルの人の、知識ベース程度のAIを作成し、
対象者の発言を明文化する音声認識とを組み合わせます。
質問に対する対象者の応答の結果を判定して数値化できれば、
このモデルが最も手っ取り早く実現できるかもしれません。
有り合わせの技術でなんとかなりそうですが、
平凡すぎてつまんないシステムですね(vv;)。
。
ひでみ
こんばんわです。ひでみです。
仲澤＠失業者さん
テストに音声認識を使うというのはおもしろそうです。
応答スピード等のペーパーテストにない付加情報がありますからね。
高スキルでコミュ力高めの人を面接の場に連れ出す、というのがエンジニアを見極めるのには一番、確実なのかもしれませんが、へたすると、そのエンジニアが好むタイプの人ばかりになってしまいそうです。
個人的には、はずれを引かないためのテストをつくるよりも、雇う側と雇われる側の双方が「はずれだったね」と認め合ったら、次のチャレンジにスムーズに移行できるような仕組みをつくる方が、効率がいいんじゃないか、と思うんですが。
アラファイブ
ひでみさん、こんにちわ。自分も常々この事は考えていました。
思いますに、情報関係のエンジニアのスキルは全て「荒い近似」だという特徴が
有ると思います。
お客さんから聞き取りをするにしても、それをコード化するにしても、その
コードを使うにしても、それを検証するにしても、すべてアウトプットは
インプットの荒い近似（10の桁は合っても1の桁は（不確定になり原理的に）
合わない、になります。
精密加工の様に全体の大きさの数万分の1まで（指で触って）合わせるとかの
世界とは別物だと思います。
そこで、そこでのスキルは「言われたことより多めにやる」事が肝要になります。
言われたことの10倍やれば、擬似的にインプットの要求に合う筈ですし、練達の
エンジニアとはそういう事を、期限内に出来る人だと思います。
それは良いのですが、
その性質が「スキルの数値化」の測定に大きなダメージを与える事になると思います。
言われても居ない事をするのは失点で、それをギリギリで守るのが最高得点と
言うのが測定の通り相場だと思いますが、それで高い御点を取っても使い物にならない
というシナリオはよく有る話です。
さらに、
荒い近似より先は不確定というのは、純粋な測定（ノギスを使ったりレーザー光線を
使ったり）に限っても、不利な条件です。
＃まぁ、もっともその測定に対するダメージをうまく使って、ひいきをする道具に
＃出来るので、簡単にはいかないでしょうけど。
アラファイブ
兎角なのでもう一言言わせていただきます。
最近、「実はオブジェクト指向ってしっくりこないんです！」が
再度ランキングに上がっていますが、その筆者のコラムニストの
みながわさんが上流畑の人（これは正しいと思います）だとすると
しっくりこない理由もわかります。
上流畑の人は、自分らの成果物の不確定性は得心しているくせに
下流は完全に確定された世界だと思い込んでいる節があります。
だからオブジェクト指向はしっくりこないのだと思います。
それは、
もちろんオブジェクト指向といえども、インプットに対する
アウトプットの不確定性を取り除く技法では有りませんが、
（それが出来れば苦労しない。）
不確定性を軽減するために、多めに作業する際の複雑さを軽減
する、優れた技法だからです。
オブジェクト指向を敗者のものだという方が敗者です。たしかに
物理世界ではサブナノでしかおこらない様な現象が身近で起きて
いるというのは直感的に誤りに見えて当然ですが、それを克服しない
と、スキルの数値化は難しいかと思います。
いかがでしょうか？
ひでみ
こんばんわです。ひでみです。
アラファイブさん
「言われたことより多めにやる」事が肝要になる、というのは意識したことがありませんでしたけど、言われてみれば確かにそうですね。
無意識に保険をかけているというか、バッファを多めにとるクセがあるというか。
多分、いろいろと痛い目をみすぎて、リスク回避の習性がついてしまったんだと思います。
それで救われたことが何度もあって、やめるにやめられなくなっているという（苦笑）。
> 不確定性を軽減するために、多めに作業する際の複雑さを軽減する、
> 優れた技法だからです。
オブジェクト指向をきちんと使いこなせるプログラマが使えば、確かにおっしゃる通りの効果が期待できると思います。
しかし、それができなくて、なんとなくオブジェクト指向っぽいコードが氾濫しているのが、現状だと感じています。
それだったら使わないで欲しい、というのが私の本音です。
オブジェクト指向なんて道具に過ぎないのだから、static の方が使いこなせるというのなら、それを選択するのはマネージャとしては正しい判断だと思います。
しかしながら、使わなければ使いこなせるようにもならないわけで、「今、使えるものだけを使っていろ」というのは、プログラマにしてみれば「それで自分を一生、養ってくれるのならね！」となります。
プログラマのスキルの数値化のむずかしいところは、スキルとして「不動」のものと「流動」するものの混在っぷりが複雑なところではないか、と感じます。
ですから、「今使える人」をみつけだすためのテストなら、「流動」部分を無視できるので、数値化はそんなにむずかしくないのかもしれません。
アラファイブ
ひでみさん。
＞しかしながら、使わなければ使いこなせるようにもならないわけで、
＞「今、使えるものだけを使っていろ」というのは、プログラマにして
＞みれば「それで自分を一生、養ってくれるのならね！」となります。
オブジェクト指向については、混乱があると思います。オブジェクト指向
なんて「長いソフトウェア技術の革新の一歩」に過ぎないと思っていた
（自分も思っていました）が、どうもソフトウェア技術界のLTE（当面、次が
見つからない、ハードの性能が今より千倍上がれば別だけど、当面は
無い。）の位置づけっぽくなってきた点です。
その結果、オブジェクト指向の次の技術をにらんで様子見をしてきた人が、
実務が出来ない宙に浮いた状態になったまま身動きが取れないで塩漬けに
なっているのを見かけます。
＞プログラマのスキルの数値化のむずかしいところは、スキルとして「不動」
＞のものと「流動」するものの混在っぷりが複雑なところではないか、
＞と感じます。
まったく同意です。たとえば、
・単体テストは直感的理解に反して「大まかで決定的な」テスト
・結合テストも直感的理解に反して「細かく非決定的な」テスト
となり、それゆえ、単体テストは組織的にやりたがらない（演繹的に何とか
出来、少量のテストで網羅可能）、結合テストは必須中の必須（非決定的で
あるが故、論理的、演繹的に正しさを検証する事が不可能で、試してみる
（テストしてみる）のが唯一の検証方法）なのでみんなやる、様な点です。
混在っぷりは、今後、是非解きほぐさなければ「未来は無い」位の問題だと
自分も考えています。
長文失礼。