Matzの部屋 vol.3（まつもとゆきひろ氏 × 泉川開）

はい。ぜひ聞かせてください！

ええ、そうでしょうね。

わかります、そうですよね。正直言うと私もこれに関してクリアな答えがないんですよ。というのは、評価したい時って、やっぱり指標が欲しいじゃないですか。そうすると例えばKPIみたいなものを設定したいみたいな話になるんですよね。

KPIって「Key Performance Indicator」なんで、数字が伸びるほど成果が上がったっていう指標じゃないとまずいんですよ。結局、その定義から言うと成果と直結する指標じゃないといけないっていうことなんです。
それで私もいろいろ考えたんですけど、ソフトウェア開発において適切なKPIって存在しないんだろうなぁと思います。

例えば単純にコードの行数の多寡を指標にするみたいなのがありがちですけど、コードの行数とコードの難しさ・価値って全然比例しないじゃないですか。コピペばかりして書かれたプログラムは、行数だけはしっかりあっても、コピーしたコードにバグが潜んでいるかもしれないし、結局のところトータルの生産性として落ちてる可能性があるわけです。

でも「数字がないと困るから」って言って、無理やりKPIという数値指標を導入しちゃうとモラルハザードが起きるんですよね。例えばコミット数をKPIに設定した場合、本来一つでいいはずのコミットを二つ三つに分割してコミット数をかさ増しすることもできるじゃないですか。

すると、本当は仕事が進んでないのに、コミット数は伸びるということが起きてしまう。当然その数値は嘘というか、本当の成果を表していないわけだけど、KPIとして設定されているからその人にはプラス評価が与えられる。それが見えてしまうと、チーム全体の士気には大きな悪影響を与えてしまいますよね。

なりがちですよね。そういう意味で言うとエンジニアの業績を定量的に計るって難しいんですよ。

私はオープンソース活動をメインにしているので、組織の中で成果を評価して給与に反映することが無いということもありますけど、この問題に関しては私の中では答えがないんですよね。

あえて言うとするならば、オープンソース活動における評価っていうのは名誉の獲得みたいな感じなんですよね。その名誉っていうのはなにか定量的に計るわけではなくて、一緒に活動に参加している仲間同士の「この人はできる」「この人はあんまり貢献していないな」みたいな肌感覚によって形成されていって、それがそのままその人の評価になっていく。それはそれで良い側面があると思っています。

通常の会社でも細かい定量的な評価はせずに「トータルとして会社全体の売上が上がったから、みんなの評価にも反映しよう」っていう形にした方が、むしろ不平不満が起きにくいんじゃないかなと（笑）

本当のことを言えば「あの人は頑張ってて、この人は頑張ってないから、頑張ってない人は下げて」という相対的な評価ができればいいんですけど、そのための客観的な指標を設定することは難しい。そうすると、マネージャーがいろんな人の話を聞いて、例えば「泉川君が頑張ってるみたいだから、ちょっと給与をあげよう」みたいに、感覚に頼る昔ながらの評価方法以外は思いつかないなと感じます。

そうなんですよね、エンジニアって基本的に評価ができないんですよ。
営業とかだとその人経由の契約数みたいな指標がありますよね。こういう指標はコミット数とか行数ほどモラルハザードは起きづらいとはいえ、ごまかそうと思えばごまかせる成果なわけで……ってことを考えると、エンジニアの評価を客観的な指標で出すのは、やっぱりすごく難しいことだなって感じますね。

ただ、それで得られる情報はあくまで参考程度にして、例えば「この人がいたので次のリリースの機能が実現できました」みたいな大きな成果があった時以外はそんなに個々に差をつけずに「ファミトラ全体の業績がすごい伸びたからみんなの給与あげましょう」みたいな評価になった方が、エンジニアの不満ってのは起きづらいんじゃないかなという気はします。

そうですね。基本的には例えばファミトラならファミトラ、チームならチームで「どういうエンジニアであるべきか」みたいなことは、やんわりと定義されているといいなと思いますね。

私は、上からいちいち言われなくても決められた方向性で行動ができる人と一緒に働きたいなと思うので、上から”〇〇仕様書”みたいなものを受け取って「関数仕様やモジュール仕様が決まっているので書けます」っていう人では、求めている人物像とはちょっと異なるんですよ。

それよりも「ファミトラに新しくこんな機能が必要だと思ってるんですけど」って誰かが言った時、「こういう風にするのはどうでしょうか」みたいな形でチームで合意ができたら、そこから先は誰かにいちいち細かくチェックされなくても、どんどん作ってレビューにかけましたっていうことができる人たちがいいなって思うんですね。

新人はもちろん、中堅メンバーもそこを目指してほしいなと。そういう意味では経験年数によって気をつけることに、あまり差はないんじゃないかなという気がします。

とはいえ、 新人は「やってみたけどできませんでした」ってことが起きがちなので、そこはケアできるように途中で「分かりません」って言ってもらうとか、あとは例えばペアプログラミングであるとか、レビューを細かくしてあげるとか……形は様々ですけど、先輩にガイドしてもらって「こうすればいいんだ」という感覚から自分で学んでいってほしいなっていう風には思いますね。

私自身はペアプログラミングはあんまり好きじゃないんですよ（笑）

自分で思う通りに開発したいのに、横に誰かいたらうるさいじゃん（笑

まぁそれは私の話であって、特に新人で右も左もわからない時って、本当にわからないからわからないんですよね。そういう時に隣にドライバーがいるってことは本当にありがたいことだと思います。ペアプログラミングが必要な人とそうじゃない人っていう差はあって、そこが初級と中級の違いになるんじゃないかなっていう気がします。

ペアプログラミングしたいと思う頻度が変わるとかはあると思いますよ。
コーディングするときはいつもペアプログラミングしてもらった方がありがたい人と、レビューの時とかコードの最終チェックの時だけドライバーに来てもらって一緒にやってもらいたいけど、それ以外は一人で、という人もいると思いますし、最初から最後まで一人の方が良くて最後レビューする時だけお願いしますっていう人もいるだろうし……。その辺の密度とか粒度とかは、人によって変わってくると思います。

こちらこそありがとうございました！