はじめに
- 評価はフィードバックを組織運営に反映していくうえで大切な項目である。
- にもかかわらず、のぞましいとは思えない評価の状況が続いていると思う。
- 技術者（もしくは技術経験者）が、その会社での開発・組織運営に対して適切なフィードバックをできるようにしていくためには、適切な評価が大事である。
- 以下は、技術者の評価を間違えやすくする要因についてのメモ書きである。
望ましくない状況
恣意的な評価基準
- 「あなたは○○屋なんだから、その範囲で話をしてほしい」と「全社的な視点で、何をどうしたらいいのかを考えてほしい」とが、その人の気分や、その部署の担当者によってコロコロ変わる。
- そのため、もう少し広い視点で物事を述べたときには「それは＊＊の役職のものが言うことじゃない」と批判される。
- そして、その物言いを避ける行動をとったときには、「全社的な視点が欠ける」という人事評価で知らないうちに減点されている。
評価に反映されない期間が発生する。しかも、結果ができる時期において
- 評価は、期間を区切ってなされるものである。
- 成果主義の評価の開始は、年度の部署・個人の計画が立案されたタイミングに始まり、人事の評価作業の集約開始までの期間での間になされる。
- 人事はその年度内に評価を完了させる必要があるため、年度内の担当者の作業の完了を待たずに評価を実行してしまう。
- 年度末の状況：
- 担当者にとっての外部への依頼先からの納品が、年度末の２週間前だったりする。
- それが人事への提出書類と同期間になっているから、結果の書きようがない。
- 担当者が、社内の別部署に提出して、その結果を評価してもらう必要があるものの場合、別部署による評価が定まらないタイミングに人事への評価用の資料を作成しなければならなくなる。
- そのため、技術者は、確認できた範囲で割り引いて成果を書かなければならなくなる。
- （該当期間に開発した技術についての社内での評価が定まるにはもっと時間がかかる。しかし、評価が定まることには、人事での評価対象外の古い時期の結果となっている。）
前年度の人事評価用の資料作成と成果主義の年度の目標立案時までの間に確定した成果の扱い
- この期間に確定した成果が反映できない人事資料
- 特に年度の目標の作業が、前年度の作業と関連がないと、成果として書きようがない（記入欄そのものがない。）
- 成果主義の目標設定時点に、既に達成できていることをどこまで含めていいか？
- 立場１：前年度の達成成果時点での目標として記述する。
- この場合、記入時点で達成していることも年度の成果として主張できる。
- 立場2：目標設定時点での状況を開始位置として目標を記述する。
- この場合、前年度の人事資料と成果主義の目標設定資料作成時期に確定した成果は、年度の成果に反映できない。
新しい技術・少数者が利用する分野は、スキル項目に用意されない。
- 例：プログラマのスキルの入力欄にMATLABは存在しない。
- 例：Rustもいまの時点では入力欄が存在しないだろう。
- １０年前のPythonの扱いもそんなだった。
- そのため、新しい技術を積極的に使いこなしている技術者ほど無能に見えてしまう。
成果主義は、手柄を自分のものとしたいように記述を歪めてしまう。
- 例：コアの実装者と利用側の実装者とでの成果の分配
- 最終成果としてアピールしやすいのは利用側の実装者（「○○万台の製品に反映して、他社製品に対する優位を築きました。」）
- コアの実装者には、どの機種から累積何１００万台に利用されたのかという、営業情報が伝わることもないので、そのような成果のアピールは不可能。
達成率の評価と韓非子の洞察
ある種の評価主義では、事前に達成可能な目標を低めに設定しておいて、達成率を高めに主張することを可能にしていると弊害も見られた。
成果主義では、成果をあげることで評価をうけることができますが、年々より高い難易度の目標が求められ続けるため、能力を出し惜しみする社員が出てくる可能性があります。
高すぎる目標を設定してしまうと、達成が難しくなり、評価が下がってしまうため、達成できる目標をわざと設定してしまう場合があるでしょう。
引用元(https://go.chatwork.com/ja/column/efficient/efficient-542.html)
アイディアを共有できる社内の部署が制限される過ぎるときに、可能性は制約される。
- 例：チーム外へのアイディアの共有を禁止する閉塞的な組織運営
- 例：所属長より上の人へアイディアを共有するルートがない閉塞的な組織運営
過去の達成した実績を、いまの基準で評価する
- 技術に中途半端に詳しいときに起こりがちのことである。
- その時点では、当たり前のことになっていないことを、工夫して達成したことを、いまの基準で「そんなの当たり前じゃない」と判断してしまうこと。そして「当たり前のことをすごいことを言うような人」と矮小化してしまう。
- そのため、その人が独自に改良を重ねてきた、重ねていける技術者であることを見失ってしまう。
- 「ものごとは、成し遂げられた瞬間から、あたかも昔から当たり前のごとく存在していたように受け取られる。世の中の認識は、往々にしてそういうものだったりする。」
伊藤智義『スーパーコンピューターを２０万円で作る』p.160
「発生したトラブルをどのように対処したか」を重視しすぎる評価項目
- 劇的なエピソードを期待しすぎる評価項目では、「トラブルを未然に防ぐためにどう取り組んでいるのか」の改良の蓄積よりも、発生させてしまったトラブルに対する対処を高評価させてしまう可能性がある。
- 浪花節が好きすぎる。
トラブルを未然に防止するための取り組み
- 製品やサービスをリリースしていく中で、トラブルを未然に防止する仕組みを作り上げて事前に共有していく日々の取り組みを適切に評価に反映していくこと。
- できて当然、トラブルが発生すると評価を下げるだけしかないのは、制度設計として間違えている。
最短でも３年かかる開発の中間年度の評価
- こうすればよいという評価方法のアドバスを見つけていない。
- 最終年度で、３年間の目標を達成しても、途中の年度で100%と認められないので、累積での評価が不足してしまう問題
指標化した値の改善した割合（〇〇ポイント）を、どの項目についても同じように考える、均一化した判断基準
物体検出を１０ポイント向上させることと
正面顔の検出を１０ポイントをさせることは同じではない。
既に、正面顔の検出率は、100%に近い水準になっているはずだ。
だから、ほとんどのデータセットについては、顔検出率を10ポイント改善する余地はない。
一方、検出の学習が十分にされていないカテゴリは、１０ポイント、２０ポイント上げる余地がある。
一律に達成率を指標化すると、実用性の乏しい対象物の検出率が２０ポイント上昇したことを、実用性の高い顔検出が５ポイント上昇したことよりもいい結果を出したとして評価してしまうことになる。
所属部署ごとの平均を均一化させる評価方法
- 先行的な技術をリリースし続けている部署でも、従来の延長上であまり変わらない部署と給与水準が同じになってしまう。
- 「人事評価（人事考課）の基礎知識 - 人事評価の甘辛調整」の例にある平均値調整・正規分布調整をするかぎり、どんなに優秀な人員をある部署で集中的に集め「今年度の売上の向上・利益の向上に「今年度の売上の向上・利益の向上に「今年度の売上の向上・利益の向上に「今年度の売上の向上・利益の向上に、開発に成功させてても、不十分な評価と報酬しか与えられないことになる。
- 売上を30%拡大する新技術を開発したエンジニアよりも、自分の分の30%増の売上を達成した営業の方が、直接的な評価を得られやすい。
矛盾した評価基準
・類例がないと、判断できない。
・類例・先行例があると、「似たものが既にあるじゃないか」と言って、相違点・改良の内容（あるいは改良のもくろみ）を聞かずに否定的な判断をする。
この２つの傾向を持つのが、組織の中に同時に存在すると、何かをやり遂げることは不可能になる。
やっかいなことは、評価を行う側のチームに、自分たちの評価基準の中には矛盾があることに無自覚であることだ。
しかも、評価される側は、評価者に反論の機会は与えられていないのがふつうだ。
何も述べていない「適正な評価基準」
適正な評価基準は、社員の納得を生むために不可欠です。
部署や業務の特徴を明確に把握したうえで、適正な評価基準を設定することを意識しましょう。
では、「適正でない評価基準」は何なのかを述べていない限り、何も言っていないと同じです。
経営者の文字通りの表現を忖度する人事
- 「○○歳以上の社員はいらない」という発言をした社長に対して忖度するから、文字通りの行動を人事が行う。それがどんなに事業の成長分野に対して寄与してきて、寄与を今後も期待できる人員であっても。
- 社長の発言という方針に対して、無視して行動できる人員は、人事部や担当の部署の上層にもいない。
再教育を実施しないままの「能力不足」
- 不思議なことは、「能力不足」を理由にあげてリストラを実施している企業が必要な再教育を実施している痕跡が見られないことだ。
- 企業が新しい領域・新しい時代に適応していくためには変化することは必須だ。
- だが、必要な再教育を実施していない企業が多い。
- 製品に性能の不足があれば、それを改善するループを開発・製造部署が行い続けるのは当然の理屈だ。
- 不思議なことに社員の「能力不足」を改善するためのループを日本の従来型の企業の多くが行っていない。
新しい技術の仕込みを過小評価する
- 「今年度の売上の向上・利益の向上にどれだけ貢献できましたか」という評価をしている限り、新規開発をしている部署の評価は報われない。
- 「今年度の売上の向上・利益の向上」に貢献できていない部署は縮小しましょうとなるのは自然だ。
- その結果、10年たっても技術水準が向上していないということが起こる。
過度に協調性を重視する
- 見解の違いは、対立でもなんでもない。
- 技術的なバックグラウンドの違い、視点の違いがあれば、見解の相違を生じるのは当然。
- 多数派との見解の違いを生じた時点で、「協調性がない」という決めつけをしてはならない。
失敗の原因が担当者に起因しないときの評価が難しい。
失敗の原因を担当者に押し付けたいという誘惑
- 企業の開発技術者が、自分だけの判断で年度の開発課題を設定できることはない。
- また、開発のための前提条件を担当の開発技術者が設定できることもない。
- 開発目標、前提技術、割り当てられる開発リソース、納期、これらの諸条件は開発の担当者が設定できる項目ではない。
- にもかかわらず、開発の担当者への評価主義だけで、開発の成否の理由を当てはめようとしてしまう。
- 担当技術者への技術上の評価者は、担当者の上司である。
- そのときに、上記の誘惑を生じやすい。
評価の目的はなにか。評価を行う組織の規模はなにか。
評価主義の導入の場合
- 個人への評価制度としての成果主義は、組織の運営の改善に結びついていない。収益についても人件費の抑制以外で改善に寄与していないように見受けられる。
- 目標を設定したあとのフィードバックも半年後、そして年度末の評価にする。
- この個々人の目標設定が、事業の収益や将来性に改善するものであるか、
- 個々人の目標設定の全体が、整合性があって、事業の収益や将来性に改善するものであるか
- そういった情報が共有されていない場合が多かった。
ある人の見解
- 「そもそも成果主義人事システムは、年功序列と職能資格制度によって肥大化してしまった人件費を（企業の都合の良いように）抑制することが目的で導入が進んだものです。」
- 「自分の相対評価を上げるために、他者（同僚や後輩）への情報提供やナレッジ共有をしなくなるんです。」(同上)
- 「社会人経験25年、会社経営を13年やってきた僕の現時点でのファイナルアンサーは、「良いときはみんなで喜ぶ、駄目だったときはみんなで反省する」という極めて集団主義的な評価思想です。」(同上)
別のアプローチ
- 評価・分析を事業の単位で行う。
- 結果をその組織単位で共有する。
- リーダーに権限を委任する。
客観的な冷静な自己評価は、新規開発の役に立つか？
自分が有能であると信じ込もうとしないエンジニアに何ができるだろうか
- はじめは、誰も何者でもない。
- 新規の未検証の技術要素がある開発は、開発に成功する客観的な裏付けはない。
- 自分がそれを解決できると信じるからこそ、問題解決のためのアプローチを取り続けることができる。
- 自力で解決できない可能性が高いのにもかかわらず、自力で解決できない場合の可能性を考慮せずに、組織の行動を歪めてしまえば問題だろう。
- しかし、解決できる信じて、同時に解決できない場合の対策を考慮していれば、どれほど問題があるだろうか。
- ソフトウェアエンジニアAさんと、電気回路設計のエンジニアBさんとで、どちらが優秀かを冷静な自己評価をする必要性はどれだけあるだろうか。
「人は自分の能力を過大評価する傾向」は、どれだけ実害を生じているだろうか。
最後に
- 誰に何を任せるのかという判断はとても大事だ。
- そのためにも人事評価は重要だ。
- いま抱えている困難に対して立ち向かうべき力量を持たない人を、その職責に与えてしまうことは不幸だ。
- 問題の分析を間違え、対処方法を間違え、もっと悲惨な状況を作り出してしまう。
- あなたの組織が抱えている問題や、あなたの組織が選びうる対処方法は、同業他社とさえ違っている。
- そのことを念頭に、考え抜いて方策を選んでほしい。
付記
CNNの主要な創始者の一人ヤン・ルカン 氏のような優れた方でも、日本企業の北米の研究所の職を失っている。
企業の業績が良くないときには、一律に人員削減するという考えが、北米の研究所の運営にも波及したのだろう。
だから、業績が良くないときに冷遇されることは、その人の才能とは別と考えたほうが良いだろう。
不十分な技術をどう評価するか
技術は常に不十分な状況ででてくる。
その不十分な技術を"half full"と考えるか"half empty"と考えるかで、その結果の活用の仕方は変わってくる。
この文章では、"half full" と考えることのほうがはるかに有意義であることを主張する。
いつもどこかで起きていること
例
- 「単独のプログラムとしてPCで動作させている分にはいいんだけど、他のプログラムと一緒に動かすと処理が間に合わないんだよね。」
- 「典型的な見え方だとうまくいくんだけど、ちょっと見え方が変わると性能が落ちるんだよね。」
- 「このプログラムが使っているライブラリのバージョンが、既に使っているライブラリのバージョンと一緒に動かないんだ。」
こういった理由のために、あなたが開発したライブラリが先送りされて、あなたのしたことは、会社への寄与として十分に認められないことが起こりえます。
本当は、評価してほしいこと
例：
「このロジックは、いままで作られていなかったものです。処理が間に合うような状況ならば、これだけの価値を持ちます。まず、その価値を認めてほしい。
計算量の削減は、この新規開発ライブラリだけの問題ではなく、既存ライブラリの方も同時に検討してほしい。」
「この時点では、典型的な見え方をサポート対象にしています。その時点で価値を見出せることを最初の判断ポイントとしています。もし、これで価値があると判断されれば、ちょっと見え方の変わった状況にでも対応するように、学習用・評価用データの拡大を行います。ちょと見え方の変わった状況にも対処できるようにする開発に移行してもいいですか。」
「依存ライブラリのバージョンの問題は、残念なことです。依存ライブラリの問題は、このシステムの今後のメンテナンスにも関わる問題です。新規に開発したライブラリ、開発済みライブラリの両方について、依存ライブラリを減らせないか、依存ライブラリを共通のバージョンにそろえられないかを検討しましょう。」
half fullと考えることで可能性は増える。
- half full と考えると、できることが明確になる。その明確な情報をもとに次の手を考えることができる。
- 「処理時間が改善されれば使い物になる。」と理解されれば、計算量を削減するアプローチ・プログラムの並行性をあげて、マルチコア・GPUなどのデバイスの性能を引き出すという次の手段の検討の価値が出てくる。
- 「典型的な見え方についてうまくいっていて、それが価値を持つのならば、あとはちょっと見え方が変わったときの性能が確保できるようにできます。」
- half empty と否定的に考えると、その情報を適切に活用することができなくなる。
- 人は、否定を含む文章を簡単に理解できるようにはなっていない。
技術者の評価の問題は、以下の２つの評価がある。
- 結果を出した技術者を認めること
- 結果を出せるはずの技術者としてチャンスを与えること
この２つは、別物である。
1の方は、結果を評価できる力量があれば、データはでそろっている。
何を価値があると判断して、どのように見返りを与えるかという経営上の価値判断こそが重要である。
経営上の価値判断からの整合性があれば、どれが正しい・どれが間違っているとは一概に言えないものである。
2.の方は、将来に対しての期待である。
そのため、その開発を指揮する人の価値観に大きく依存する。
その判断が正しいかどうかを、客観的に判断方法があるようには思えない。
将来への期待であるから、プロジェクトへの参加の可否の判断であることが多い。
将来への期待であるから、その時点では必ずしも待遇の改善を意味しない。
将来への期待であるから、「期待している」ことを伝えることで、その人の可能性を引き出すきっかけになれば幸いである。
Q: 失敗したプロジェクトの参加者をどう考えるか？
次にどのようなチャンスを与えるかという視点でどう考えるか？
A:個人の資質は、その個人の技術、アプローチの方法などで考えるべきだと考える。
そのプロジェクトが成功しているに越したことはないが、成功したからといって、その人が有効な寄与をしたのかはわからない。
同様に、失敗したプロジェクトにいたからといって、その人が無能なことの根拠にならない。
失敗したプロジェクトの中で、問題意識を持っていたり、別のアプローチをするための構想を持っているかもしれない。
追記(2024)：
アイディアは常に不十分な状況で最初のかたちとなる。そのため、どんなに有用なアイディアであっても、欠点をあげつらう限り、欠点しか見えない。
科学史を知っている人にとっては当たり前かもしれないが、新しいものは不完全な状況から始まる。
量子力学にしたって、十分に定式化されるのは、量子力学の緒(いとぐち)となる黒体輻射や光電効果の理論よりだいぶ後だ。
例 トロイの部屋のコーヒーポット
- あげつらう視点に立てば：
- 「コーヒーポットの画像をInternet にあげて何の意味があるというんだ」
- 「ネットワークの無駄遣いだ」
そういう意見ありそうな気がする。
- 積極的な意義：
- ディジタルネットワークに接続したカメラを作り出したこと。
- 公開先が制限されたものではなく、だれでもが同じカメラの画像を共有できるようになったこと。
- 画像・動画というものが、インターネットの主要なコンテンツとなる最初のきっかけを作ったこと。
- 動画をインターネットで配信するためのデータ圧縮技術、QoS(Quality of Service) 、配信技術などを開発させる必要性を作り出していったこと。
- ネットワーク越しに取得した画像に対する画像情報処理の可能性を必然的に呼び起こしたこと。
その技術の価値は、ユーザーいない状況では評価してもらえない。ユーザーが評価してくれるまで技術の評価はなかなか定まらない。
- 社内でのエンジニアへの評価は、年度末にされるのが通例であろう。
- そのときには、そのエンジニアが開発した技術は、ようやく社内での納品が済んだばかりだ。
- そのため、社内のユーザーによる実際の評価、使い物になるのか、約立たずなのかはまだされない。
提案：リリース済み技術に対する年度遅れの評価
- リリース済み技術を利用している部門に対して、過去5年内に開発された技術で役に立っているものを、リストアップしてもらう。
- その技術を開発した主たる人物・チームを表彰する。
- 過去の技術を評価する理由：
- 開発直後には、まだその技術が使われていないので、評価しようがない。
- 年度内の開発は年度内の評価で評価するという視点だけは、ノーベル賞の受賞を過去1年の論文に対して行うようなものである。
- それがどれだけ難しい評価かわかるだろう。
エンジニアの価値
例: 4004 の開発者 嶋正利 氏
Intel 4004 の主たる開発者の１人である顧客会社の出張社員 嶋 嶋正利 氏の価値を知っていたのは、Intelだったということ。彼がロジック設計の中心 となって進めたIntel 8080の開発の成功ががIntel の現在の地位を作った大きなターニングポイントだろう。
参考記事
- 日経XTECH 成果主義の弊害と弊害と弊害 2007年
- 「能力開発と成果主義：電機・電子・情報関連産業の技術者のケース」 pdf