「成果主義はまだ人類には早すぎる」を読んで、強く同意した一方で、
仕事の成果はどう測るのか？
ということを自分なりに考えていく必要があると思ったので、今の時点での考えをまとめてみた。
前提
- エンジニアの成果に限定する。（他の職種のことはわからないので）
- 時間給はなし
結論
実現していることに対して値付けをする
考察
定量は評価は難しい
まず、コード量や実装した機能数で測るのはなし。 これは根本的には時間給と同じだと思います。
実装した機能の難易度を加味すれば、もう少し妥当な評価方法になるかもしれないが、 実装する機能にいちいち難易度を付けるのは意外と難しく、開発速度も落ちるので、ゆくゆくは形骸化する可能性が高いと考えている。
次に、売上にどれだけ貢献したかで測る方法もなし。 ある機能を実装して売上が上がったかどうかを測定することは可能だが、それがいくらなのかを正しく評価するのは難しい。
例えば、キャンペーンページへの導線を改修して、アクセス数が伸びたとする。 売上に貢献したのは確かだが、ではいくら分かというと一概には言えない。 キャンペーンに関わる企画、広報、その他の大勢の人たちの仕事が複合的に成果に反映されているので、完全にエンジニアの仕事による成果を切り出すのは難しい。
また、よく言われることだが、新規事業などのまだ売上を上げていない仕事やインフラのような必要だが基本的に直接売上への影響ない仕事には適用できない。
そのエンジニアが何を実現しているのかを評価する
今の時点での私の結論はこれです。
そのエンジニアがいることで、何が実現されているのかを明確し、それに対して会社としていくら払うのかを決めるという考え方です。
これはフリーランスの人では、当たり前の評価方法かなと思っている（たぶん）が、 リソースが流動的な正社員にはあまり適用されていないように思う。
この方法では、まず会社としてエンジニアに何を求めるのかを具体的に定義する必要がある。
自社サイトのパフォーマンスを上げて欲しいのか、決済システムを含むシステム開発をしてほしいのか、 デザインを向上してほしいのかなどなど、今の会社にとって必要な成果を常に定義する必要がある。
「実現評価」にするとどうなる？
上記の方法を便宜的に「実現評価」と呼ぶとして、導入するとどうなるか推測してみた。
- 給与を上げたければ、実現できることを増せばよい
- 会社にとって必須であったり、実現するためのハードルが高いものほど高く評価される
- 自分が何を実現したのかを常に記録として残す必要がある
日報のような量的に読むのが難しいものではなく、より要約された記録が必要
実現して欲しい内容が更新されなかったり、難易度の割に評価が低かったりするとシステムが崩壊し始める
- 実現してほしい内容が細分化されすぎたり、多すぎたりすると誰も目を通さなくなる
逆に抽象的な実現内容ばかりだと、何をもって実現したと言えるのか分からなくなる
システムのことをわかって居ない人が作った実現内容ばかりだと評価に齟齬がでやすい
エンジニアが作った実現ばかりだと会社のビジョンや売上目標などとの乖離が起こりやすい
長時間働いても実現内容がしょぼい人より、短時間で高度なことを実現する人の方が評価されやすい
- 保守系のエンジニアなど、常にコンタクトを取れることが価値になる人もいるので、時間給は完全に排除しづらい
感想
ざっと思いついたことを書いてみたが、「これ普通にやっている会社多いのでは」というのが正直なところ。
新しいアイディアが必要というよりは、既存のやり方で形骸化しているところやミスマッチを起こしている箇所を地道に潰していく。 そのために必要な仕組みやコミュニケーション環境があるかどうかが大事かなと思った。（小並感）
3/7にあるエンジニアの評価に関するイベント前に一度頭を整理できたようで、書いてよかった。
