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

Matzの部屋第3弾 泉川
目次

ようこそ、Matzの部屋へ!

プログラミング言語Rubyの生みの親にしてエンジニアの憧れの存在であるまつもとゆきひろ(Matz)さんが、ホストとしてファミトラの開発部メンバーを迎え入れ、1on1セッションを通じて様々な話を紡ぐ本企画。

第3弾である今回は、独学でプログラミングを学び始め、若くしてテックリードへとキャリアアップを遂げつつある泉川が、Matzさんに開発部における評価制度や若手エンジニアへの教育のあり方について相談します。

数値や成果で計ることが難しいエンジニアの評価について話し込んだ非常に奥深い内容となっていますので、是非最後までご覧ください!

エンジニアの評価について

ソフトウェア開発において適切なKPIは存在しない

泉川

それではお願いします!僕からは、エンジニアの教育や評価についてお話を伺いたいと思います。

Matz

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

泉川

今後、ファミトラの人事制度が少し変わるみたいな話がありまして……具体的には「行動量」で評価しようみたいな方針なんですね。

行動量って、例えば営業だったら「どれだけアポイントを取った」とか計れると思うんですけど、エンジニアの稼働量とか行動量って、「テストコードを1000行書きました」「それはすごいですね。評価アップです。」とはならないじゃないですか。

Matz

ええ、そうでしょうね。

泉川

それこそ「すごくクリティカルなバグを3行くらいで直しました」とかの方がバリューが高かったりするので、行動量という軸で考えた時、どうやってエンジニアを評価したらいいのかなぁって悩むんです。

Matz

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

Matz

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

泉川

なるほど。

Matz

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

Matz

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

泉川

そうですね。

Matz

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

泉川

本当にそうですね。「あいつ成果出してないのに、なんでそんなに評価されてるんだ」って感じちゃいますね。

Matz

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

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

Matz

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

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

泉川

なるほど(笑)

Matz

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

泉川

エンジニアが意外と一番アナログな評価をせざるを得ないっていうことですか(笑)

Matz

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

泉川

そうですね。やっぱり360度評価みたいな仕組みを導入している企業もありますけど、そういうもので評価していくのがいいんですかね。

Matz

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

泉川

ありがとうございます。人事チームにも伝えて、次の評価制度見直し時に意見として取り入れてもらおうと思います!

エンジニアの教育について

チームならチームで「どういうエンジニアであるべきか」みたいなことが、やんわりと定義されているのが理想

泉川

ここまでは人事評価の話だったんですが、もう一つのテーマはエンジニアの教育についてです。

泉川

僕は新卒の子のメンターみたいな形で教える立場に立つことが多いんですが、新卒の子たちが学ぶ時と、逆に僕らのような2年とか3年とかやってきたメンバーが経験豊富なシニアメンバーから学ぶ時とで気をつけないといけないことって若干違うのかなと思っていて……。
それぞれの立場において、何に気をつければいいのかみたいなお話をお伺いできればと思っています。

Matz

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

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

Matz

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

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

泉川

なるほど。

Matz

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

泉川

そうですよね、ペアプログラミングは良い方法ですよね。

Matz

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

泉川

あっ、そうなんですか?

Matz

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

泉川

(笑)

Matz

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

泉川

確かに。まだ僕もペアプログラミングしていただくとありがたい時もあるので、僕はまだまだジュニアだなと思いました(笑)

Matz

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

泉川

たしかにそうですよね。
まとめると、心構えとしてはレベルに関わらずどんどん自分で考えて前に進めていく意識を持つべきだけど、実務にあたってはレベルや好みに合わせてチームの中でいろいろなサポートをできる体制があると良いということですね。今日は貴重なお話をお聞かせいただきありがとうございました!

Matz

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

対談者プロフィール

まつもとゆきひろ
Rubyアソシエーション理事長

スクリプト言語Rubyの生みの親であり、一般財団法人Rubyアソシエーション理事長、株式会社ZOZO技術顧問、Linkers株式会社技術顧問などを務めている。オープンソース、エンジニアのコミュニティ形成などを通じて、国内外のエンジニアの能力向上やモチベーションアップなどに貢献している。自称「世界的にもっとも有名な日本人のプログラマ」。日本OSS貢献者賞初代受賞者。

泉川 開(いずみかわ かい)
プロダクト開発部 エンジニア

学生時代にオンライン家庭教師サービスmanaboを運営する株式会社マナボ(現 株式会社manabo)にインターンとして入社。事業部から営業部へ異動し、プログラミングと法人営業を経験。

2021年4月、株式会社ファミトラにエンジニアとして入社。メインサービスの開発に従事。趣味はポーカー。42Tokyo在学中。東京農工大学農学部卒業

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!
目次