こんにちは。 @katzchangです。
VOYAGE GROUPでは人事評価制度の一つとして技術力評価会というのが年に2回ほど開催されて、半年くらいの仕事から何かテーマをピックアップしつつ、別チームのエンジニア2名とお話をしつつ、なんと評価までされてしまうという、とても楽しい会があります。
評価する側のエンジニアも多様で、ある程度の評価軸はありつつも、それぞれの質問や評価はそれなりに個性が出るものだろうなーと眺めています。ということで、私なりの質問や評価のポイントをいくつか挙げてみます。
例えば「キャッシュの有効時間はどれくらいか？」みたいな質問をすることがあるとします。当然、「わかりません！」で終わると残念なのは皆知ってるので、頑張って答えようとします。しかし、その場で「xx分です！」みたいに答えることに、ほとんど価値はありません。
重要なのは、どこにどのように書いてあるかを追うことができることです。予め把握してたとしても、実際にコミットされたコードや場合によってはサーバの設定まで追って、先の答えが妥当かを確認し、説明してもらいます。追った結果、先ほど即答したものが間違いだったとしても、それほど問題にはしません。追えることが大事です。
例えば言語の選定だったりスケジュール的な制約だったりについて、その理由を問います。ここで、「◯◯さんの判断です」や「経営層の会議で決まったので」という回答は無意味です。その人達が判断した理由を把握していて、説明ができることを求めています。
システム開発業はかなり複雑な問題故に絶妙なさじ加減が必要で、「x月x日までにhoge機能をリリース」だけだと、情報があまりにも少なすぎます。その機能はどこまで作りこむのが妥当か、今後の運用タスクをどこまで見据えるべきか、そもそもその期限はプレスリリースなのか他社連携試験開始なのか。など、午前3時の眠い頭でもそのくらいの心配がすぐに出てくるし、これらの質問が明確になれば大丈夫かなんて誰も知りません。多くの情報から総合的に見解を出すことが必要です。
逆に言うと、実際には◯◯さんの判断だったとしても、自分で受けた説明をそのまま説明できれば、まぁそれはそれで良しなわけです。「◯◯さんはこう言ってました」みたいな説明だと「じゃぁ、あなたはどう考えるんですか？」という次の一手が待ってます。自分が納得したものは、自分の言葉として語れば大丈夫です。
スケジュールの制約、やりたいことの困難さからくる制約、サーバやミドルウェア、フレームワークなどの環境の制約などを把握しているだけではなく、回避することが重要です。もちろん、チームで定めたルールも制約の一つです。制約を作る（＝増やす）のではなく、シンプルに保つ（＝減らす）ようなことができていれば、私は高く評価します。
制約の中で頑張るのはそれはそれで美談かもしれないですが、動かせない制約はクソコードのようにチームの動きを止めていきます。制約を作るのは誰でも出来ます。しかも、それがクソかどうか、後になってようやく気づきます。まさにクソコードの如し。不要な機能を削るように、不要な制約をなくしましょう。
シンプルかつ疎結合で独立した強いシステムを作るプログラマとして、自分たちのシステム（ソフトウェアシステムに限らず）をシンプルに保つ能力も求めます。ドッグフーディングの一種。
間違った知識を正しいと思い込んでいないか？チーム内外に助けを求め、修正することができているか？自らの不安を解消する行動をとれているか？
私はこんな感じでやっています。エンジニア/プログラマ評価の観点も色々あると思うので、皆さんはどうお考えでしょうか？
さて、この記事はVOYAGE GROUP Advent Calender 2014、12/4の記事でした。
次はガイアさんらしいので、驚愕な記事を書いてくれるはずです！！！！！！！！！！