質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

90.12%

プログラマの評価軸とは

受付中

回答 7

投稿 ・編集

  • 評価
  • クリップ 10
  • VIEW 3,425

ucchan

score 27

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

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 7

+4

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

客観的に評価でき、自分が得意なものを挙げるのがよいでしょう。例えば
  • 書いたコード行数
  • 書いたコードに対するテストコードの行数
  • 学んだ新しい知識
  • 取得した資格数(基本情報処理など)
  • 社内勉強会での発表実績
  • 残業時間(これは最悪ですけどね)
などです。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2014/10/24 11:39

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

    キャンセル

+4

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2014/10/24 11:40

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

    キャンセル

+1

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

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+1

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

0

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

0

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

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

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

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

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

0

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 90.12%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる