プログラマの能力評価は難しい

仕事でプログラミングを教えつつ開発を行なったり PM したりと色々小忙しく稼動していたりする (週 3 労働だけど) 中で、ふと思い至った事を残しておこうと思う。 今回はプログラミング学習者 ~ ある程度の開発経験者までの中で属性というか、パターンがあるなぁと感じた事をまとめておく。

プログラマの能力とは

プログラマの能力と言った話は巷 (まぁ大体 Twitter なんだけど) では良く話題になっており、自分も良く話題に乗っかるネタではあるんだけど、最近は未経験者 (未経験の定義については 未経験から1000万を真面目に考えてみる でやったので、そちらを参照して欲しい) でスクール卒が戦力になるか、採用時や採用後の負荷などが議論のネタになっている。

その中でも、最近盛り上がっていたのはエンジニアの適正という話で、個人的には適正 (向き不向き) なんて気にするだけ無駄だし、他人が誰かに向かって「アイツは適正が無い」というのも余計なお世話だろと思っている。なぜなら、自分は良くやれていると思っている人間も誰かに「アイツは適正が無い」と言われている可能性があるからである。

プログラミング自体は、母国の自然言語が読み畫きできているのであれば、時間を掛ければ誰でも出来るようになる (なぜなら言語なので、自然言語が使えてるなら使えない道理はない) 訳で、そう大層な話ではないと思う。 そういう話題を見つつ仕事に目を向けた時に、ふと、適正では無いけども、その人の「今」居るステージをある程度把握するためのパターンはあるな、と思い至った。

先ずはプログラマの能力とは？というあたり前に出てくる疑問からまとめる。大体下記リストの通りが能力としての評価項目かなと思う。

1. 動くプログラムが畫ける
2. プログラムが読める
3. ライブラリ、フレームワークが使える
4. ライブラリ、フレームワークのプログラムを修正できる
5. 言語仕様を知っている
6. プロトコルを知っている
7. プロトコルを読んで実装できる

上記項目がそれぞれどの程度出来るのか? という部分を見る事が多い。計算機科学に根差した知識や技術という点についてはここでは記載せず、アプリケーションの開発現場で良く求められる能力にフォーカスした。 この中でも、1~3 くらいが基本的に求められる能力で、他はあったら嬉しい位置付けになる所が多いだろうとは思う。

プログラマ (エンジニア) 採用に力を入れている企業では、上記を確認出来るような面接を実施したり、実装課題を与えたりしていると思うし、コーディングテストなどを実施したりしているかもしれない。

多分だけど、スクールの排出するプログラマは 1 を担保しているが、2 は担保できないというレベル感かなと思う。2 が担保できないという事は、プログラムが読めないので、自分が書いたプログラムも良く分かっていないという事になる (Rails チュートリアルを講師に従いつつやって、テキストとテンプレのポートフォリオ作成程度だとそんなもんだとも思う)。そこから先が出来る人も勿論居る筈なので、あくまでもスクール卒が担保できている (と思われる) 能力の話となる。

4 以降の程度については、実例ベースで話を確認する事ができるため選別は比較的楽な筈で、問題は 1~3 という事になる。つまり、求められる能力なのに能力を測る事が非常に難しい部分であるという話になる。

ではなぜこの能力を測るのが難しいのか、考えてみる。

プログラミング基礎力の評価の難しさ

そもそも「動くプログラムが書ける」と「プログラムが読める」を分けたのは何故なのか。それは、単純に読むと書くでは別能力を要するためでかつ、プログラミングにおいては意味解釈は言語が行なうため、書き手が意味を理解していなくても目的を達成するプログラムを書く事は簡単だからである。

特に、最近は動的型のインタプリタ系言語が WEB では良く使われるため、型を合わせないと動かない (それでも緩いだけで実行時にエラー吐いたりして止まるわけだけど) という問題などにも直面しづらくなっている。
プログラミングを指導していて良く遭遇するのは「あれ？これで動く筈なんだけど」とか「なんでコレ動かないんですか？」という質問で、その多くが自分が扱おうとしているものがどういう型であるのかを理解せずに使おうとするからである。

それでもプロダクトは生産できたりするので、プログラミングにおいて「言語」「文法」「型」などといった瑣末な物は必要ないんだろうと思う (少なくとも彼らにとっては…)。多分、本当に必要なのは、Qiita やブログで公開されているコードのテンプレやイディオム、実装例とエラーの修正記事なんだと思う。
そして、こういった人材の存在が駄目とかではなく、時代の流れでそういう人材がプログラムを書く仕事をするようになったと流れを受けいれるしかないとも思う (元々ある程度いたと思うけど、割合的には増えたんだろうと思う)。

なので、最初に評価すべきは「書ける」「読める」かどうかという点だ。

そのためにはプログラムを書いて貰う必要があるし、読んで貰う必要がある。あとは、選考で残したい人材のレベルに合わせた問題設定にするだけで良く、採点時にはある程度絞れる筈である。読めるかどうかは、プログラムを読んでどの程度理解しているのかを確認するだけで良い。

また、自分が書いたコードを説明させるのもやった方が良い。読めない人はだいたいが自分の書いたコードを説明できないので、何故そういうコードになったのかを確認するだけでも多くの事が見えてくる。

では、これをやっている所がどれ程あるか？というとあまり無かったりはする。何故ならノウハウが無かったり、余裕がない (という言い訳だと思うけど) 事が理由にあるから。そういった所は、人材の能力を把握するのに業績や経験年数をベースに話をして鵜呑みにしてしまう。

こういった事は転職や SES、派遣などでも良くあるミスマッチで、どこも悩まされていると思う。ただまぁこのミスマッチの問題についてはそれぞれの達成目標が微妙に異なるため、同一の方向を向いておらず発生するものなので、能力評価の点だけでは解消でないのでここで言及するのは割愛する。

とにかく「読み書き」を評価する事にまず注力するべきで、もっというと、自分達が求めているレベル感を明確にするべきである。これが出来ない (それが難しい訳であるけど) からこそ、能力評価に困っているという具合である。

これが社内に入るとある程度評価が適切になってくる訳だけど、それは直接的な業績が付くため、貢献度や業務遂行能力を確認する機会が増えるからとなる (それでも完璧ではないし、エンジニアリング能力の評価は難しいけど)。

技術者のパターンについて

基礎力については、どの程度「読み書き」ができるかで測れるし、4~7 までの項目を確認していけば持っている知識や経験も判断できるが、最後は成長がどの程度見込めそうかという点も気になってくる。

成長の期待度については、ある程度パターンが見えたというのがこの記事の冒頭で記載した話である。

そのパターンは下記 4 点があるように思う (どのパターンも持っていたりするので、どの傾向が強いか、というレベルの話だけど)。

1. 過去の体験からパターンで解決
2. 問題を理解して解決方法を調査、身に付ける
3. 他人の問題を解決する
4. 問題が発生していなくても情報収集と研鑽を行なう

1 から順に自身へのフィードバックが大きくなる行動パターンとなる。

つまり 1 は 4 点の中でフィードバックが 1 番少なく、パターン蓄積の量に問題解決の時間が依存する形になり易い。これはプログラミングでは、言語である程度書ける場合、仕様の調査やリファレンスを読まないという傾向が多い。

リファレンスを読まないというのは、関数やメソッドの使い方を調べないという話ではなく、仕様がどうなっているのかを理解するつもりが無い人に多いという事で、つまりは自分の中でロジックを組み立てる必要がない (つまりパターンで解決している) という事に他ならないと思う。

これを直す為には、公式のリファレンスやドキュメントを読む癖を付ける事と、(できれば) 言語の内部処理や自身の加工しているデータの状態まで意識した上でコードを書くようにする必要がある。プログラミングをする上ではあたり前といえばあたり前ではあるが、これが出来ていない人は残念ながら (本当に残念) 本当に多い。そして、業績や経験年数に関係なく能力が低い。

2 の傾向が強い人は、プログラミングを続けていけば順当に成長するため、業務で発見を得られる現場にあたり続けられればその分だけ身につけていく。ただ、問題は、与えられた問題のみを解く傾向が強いという事でもあるため、所属組織の色が強くでてしまう。
これは、組織が用意仕事が安定だけをとるような方針の場合、若くして成長が止まる可能性はある。

3 は単にお節介焼きに見えるが、その実問題を解く事が好きで顔を突っ込むタイプで、直面している問題に依存せず成長できる可能性が高い。色々な問題を探しては解決するという事を繰り返したりするので経験は豊富だったりする。本人にその気がなくても頼られた結果そういう状態になる人も多くいるので、以外とどの組織にも 1 人はこういう人が居たりし、大体社内のなんでも解決人みたいになる。

最後に 4 は実利に関係なく、好機心のみで行動していたりするのでどんどん成長していくため、説明の必要もないと思う。こういう人が居たら離すべきではないし、社内に居るなら大事にすべき。こういう人を意図的に作るのは非常に難しいと思う。多分ここの人材を量産できる方法があればそのノウハウで起業するべきだと思う。

まとめ

プログラマの能力評価という事で考えてみたが、個人的には納得感のある内容になった。

実際、評価に困るという話や見極めに困るという話は良く聞くし、雇用した人に対しての評価が「何となくイケてない気はするが何が駄目か不明」みたいな状態みたいな話も良く聞く。今後スクールみたいな業態のものはもっと増えると思うし、開発業を行なう組織も増えると思うので、しばらく評価に対して考察を続けてみようと思う。