プログラマの評価軸とは

Question

上長にプログラマの評価軸を調べて自己評価するように言われました。
しかし、私がいくらネットから調べてもプログラマの評価は難しいという
結論にしか達しません。
みなさんは、プログラマの評価軸をどのように考えていますか。
よければ教えてください。

Answer 1

まず、評価が高い ⇒ 有用なプログラマ となるような評価は存在しないといってよいでしょう。
また上長もおそらく「有用さを評価できる軸」よりも「客観的に評価しやすいもの」を求めていると思われます。
ですので、適当なのを見繕ってしまうのがよいでしょう。
（ぶっちゃけ自分で正しい評価軸を出すのが大変だから、丸投げしているんですよ）

客観的に評価でき、自分が得意なものを挙げるのがよいでしょう。例えば

• 書いたコード行数
• 書いたコードに対するテストコードの行数
• 学んだ新しい知識
• 取得した資格数（基本情報処理など）
• 社内勉強会での発表実績
• 残業時間（これは最悪ですけどね）

などです。

Comments

[ucchan]

ありがとうございます！
悩みがすっきりしました。
見繕ってみたいと思います。

Answer 2

参考になるかはわかりませんが、私は以下のような指標で考えます。
・やりたいことに対する実現のスピード
→知識量、コーディングのスピード(これは単純に打つのが早ければよいのではない)
・実績
→どんなプログラムを作成したか、勉強会への参加やオープンソースへの貢献など
・設計ができるか
→汎用性・保守性を考えたコーディングができるか、デザインパターンなどを考慮できるかなど

そもそもプログラマ止まりではなく、上位のシステムエンジニアやアーキテクトなどを考慮してみると良いかもしれませんね。

Comments

[ucchan]

指標ありがとうございます。
参考にさせて頂きたいと思います。

Answer 3

駆け出しのメディアのプロデューサーですが
僕が思うプログラマの評価軸は以下の３つです。
0.ディレクターやデザイナーなどと上手くコミュニケーションが取れ、円滑にタスクを進めるこができる。
0.最新技術を常に勉強し、自分の成果物に組み込む姿勢がある。
0.タスクを進めるにあたっての潜在的なリスクを認識し回避することができる。

Answer 4

プログラマにかぎらず、人の能力を評価するのはひじょうにむずかしいことです。
今回の場合、上長の方が「自己評価するよう」のぞんでいることを考えると、数値化できるような客観的な評価項目が必要になるのではないかと思われますが、僕の考える評価項目についていくつか書かせていただきたいと思います。

１）ソースコードのクオリティは高いか
２）プロダクトを完成させた（または納品した）ことがあるか
３）コントリビューション（寄与・貢献）の履歴や度合（GitHubなどでの活動）
４）チーム開発をしたり、管理システムを有効に活用できているか

エンジニアの仕事は、課題を解決するための複雑な概念を自らが理解することと、それを（たとえば共同開発者などの他者へ）明確に伝えることです。どちらか一方だけでは、ざんねんながらエンジニアとしては不向きといわざるをえません。エンジニアにとって大切なことは、チームの一員として、より大きな（*）、より精度の高いプロダクトをつくりあげていくことだと僕は考えています。（すくなくとも僕にとっては）これがいちばんの要件です。

*大きな：プロダクトのスケールや露出量ではなく、そのアイデアや社会にあたえるインパクトの大きさを指しています。

以上、ご参考いただければ幸いです。

Answer 5

プログラマとはすなわちプログラムを作成する人ですから、評価としては「どんなプログラムを作ったか？」が基準となるかと思います。

となると、「よいプログラムとは何か？」を考えてみましょう。
古くからプログラムの品質の定量化は行われてきました。量的な評価として行数やステップ数（コメント行数も品質強化と言う点で評価対象）、加えてテスト項目の数と質、それに対する質的評価としてバグの発生頻度、そしてバグの対処にかかる期間（調査・修正・リテスト）といったものがよく使われているものでしょうか。
それらを総合して、バグの少ない（ないなんてのは幻想レベルですので）、出たとしても致命的になっていない（調査・改修に時間がかからない）、のが良いプログラムと判断されるかと思います。
となれば、あとは良いプログラムをかけているかどうかを指標とすればよい、のでは。

これらを関わったシステムごとに出して（できれば言語で分類しとくと得手不得手が分かってよいかも）、表とかきれいに整形すれば資料としてはよいのではないかと。
※自己努力（新しい技術を積極的に吸収しようとしている、試験などを受ける）しているかどうか、ってのはまた別の（それも定量化しにくい）指標ですしね……

Answer 6

自分の工数*給料/受けた仕事の金額*自分の作業割合＝価値

これかな…
値が低ければ低い程よし。
1から引けばある仕事の利益率。
これを提出するのは気が引けますけどね。

営業の腕がいいといくらでも水増しされるから、実際には「自分の価値＊営業の価値」だけど。
元々の人工の工数に対して実際の原価の割合を線引きにする。
例えば、3割りなら3割りを線引きにしていて、給料と比較してどれぐらいかなと。

残りの7割りが営業や上長の取り分で、仕事が常にある状態なら3割りに満ちてなければ安く買いたたかれてるってことでもあるし、自分がそれだけ優秀だってことでもあるのかなー、と。

これだと受けた仕事の金額に自分の品質が左右されちゃうけどね。
世の中には技術的に難しそうで、単価の高い仕事っていうのもあるよね。
そういう仕事を安請け合いしていれば営業力が低いとも言える。
難しいことを、高い金額で受けた時に、同じようにこなして、純利が増えるんなら自分の価値は高いだろう、と。

工数で単純に原価計算して利益を乗っける請求方法もあるけど、見積もりが正しい時はないし、それって営業力が低い会社だよね。
最初に営業がいくらって提示したから、そこから利益を出すのが僕らの仕事と考えれば、これが「金額に換算された仕事の価値」なのかなぁ、と。。

うちではそういう評価をしていませんが、考えるようにはしています。

Answer 7

納得できる結果や実績を並べるのがいいのかと思います。個人的な目標は
１．わかりやすいコードを書く。
２．目的までの道のりはなるべく短く。（寄り道して苦労しました）
３．結果（ソフト）が喜ばれるものであること。

あとは上司が喜びそうなことを書いておけばいいのではと。（笑）