こんにちは、fluct SSP開発本部の@saxsirです。
今年の4月に入社した新人ですが、職場ではgolangとかAWSとかを使って社内向けのプロダクトをゴリゴリと開発しています。
さて、VOYAGE GROUPでは人事評価制度の一つとして技術力評価会という相互評価の仕組みがあります。 これは年に2回ほど開催されており、直近半年くらいの仕事から何かテーマをピックアップし、別チームのエンジニア2名（評価者）に「私はこんなすごいことをやったんだよ、どやっ」とお話しながら自分の技術力を評価してもらうという場になります。
もちろん、新卒も例外なく技術力評価会を行います。
今回は初めての技術力評価会を終えて私が学んだこと、を社外の方向けに書こうと思います。（言うまでもなく、私は被評価者です）
※以下、「技術力評価会」を「評価会」と略して表記する場合があります
TL;DR
- 「なぜやったのか」を説明するのは難しい
- 素振りはいいぞ
- 評価会とは評価制度であると同時に、成長する仕組みでもある
前提
技術力評価会は90分です。何が言いたいかと言うと、その場で自分がやったことを語り評価者とディスカッションするには全然時間が足りません。
そこで、事前に「評価会資料」というものを作成し、評価者にはそれを読んできてもらってから当日に臨むような流れになっています。
なにをやったのか／なぜやったのか／どうやってやったのか等、いくつかのポイントを含むように（なるべく既存のドキュメントを流用しながら）Markdownで書くようになっています。（テンプレートは一応ありますが、ポイントは抑えつつ各自が書きやすいように書きます）
「なぜやったのか」を説明するのは難しい
たとえば今回私は「クローラーのキューイングを外部キューにした」という内容で評価会をやりました。
評価会資料をつくるかー、と思って書き始めて思ったことは「やったこと」と「どうやってやったのか」はスラスラ書けるけど「なぜ」の部分はすごく難しいということでした。
- 「なぜ」外部キューにする必要があるのか？
- 無数にある方法の中で、あなたは「なぜ」方法Aを選んだのか？
ということを自分の言葉で説明できなければなりません。
今回の例で言うと、実は私が外部キューにする必要がある！と提案したわけではなく suzuken (@suzu_v) | Twitter が、これはやった方がいいという判断をして、それを私が実装したものです。
開発自体は、まぁドキュメントを調べたり試行錯誤していればできるでしょう。
しかし、その妥当性を他人に伝えるためには（仮に）組織的な決定事項や自分の判断ではないとしても「自分の言葉で」説明できなければなりません。
これが説明できないとちょっと残念だなぁ（なんであなたはそれをやっているの？）となってしまうので、まず大前提の部分でこれができていないエンジニアは一人前とは呼べない。というのが弊社のエンジニア文化なのだなぁと感じた評価会でした。
たとえば、私はこんな図をホワイトボードに書いて
- そもそもこういう構成になっていて
- 今回ここを変更したんです
- で、その理由は云々…（ここが大事）
みたいなことを話しました。（これの前にどういうシーンで使われてるかーとかも図に書いて説明した気がするけど画像がなかった…）
素振りは大事
ここまで読んでいただいて、そもそもクローラー…なんで？そもそも全体の仕組みが分からない…という感じになると思います。 社内でもだいたいそうです。ただ自分は詳しいので、なんとなくそのへんはいいかーという気になって進めてしまいがちです。
なので発表前に素振り、と呼ばれる「論点を明確にするための練習」みたいなことをやる人もいます。 私は初めての評価会ということもあって不安だったので、今回素振りをやりました。
これはとても良かったのでオススメです。
- 自分では分かりやすいつもりでも、だいたい伝わらない
- 素振りを見に行くと副次的に、別チームのエンジニアが何をしているのか知ることもできるので楽しい
- 人の素振りを聞いていると質問力も鍛えられる（評価者目線でも見られる）
ので、結構楽しいです。 素振りは業界一般的にやられていることなのか分かりませんが、これはみんなやるといいんじゃないかなーと思います。
別に評価会とかがなくても別部署の同期に自分がやっていることを飲みながら説明する、とかでもいいと思います。
ちなみに素振り最中の走り書きメモがあったのでペタッと。（字が汚くてすみません…）
などなど…話しながら自分でも気づいたりするんですが、人に伝えるのは本当に大変だなぁと… あとは、そこは頑張ってたところだしアピールすれば？と言われると、あーなるほどなぁ（嬉しい）と思ったりもできて素振りは良いです。
評価会は評価されるだけじゃなくて成長する仕組み
これは新卒目線かもしれませんが、評価会という場を通じて普段の行動が変わりました。
たとえば、私は開発に入る前に手元のホワイトボードにシステム全体像ややるべき理由を書いてみて、自分に対して説明できるかどうか考えたりします。
これ自体は元からやったりしていたんですが、それだけだとその思考過程が残らないので、それはチケットなりIssueなりに残すべきです。
これは評価会後、意識的にやろうと変わりました。（元々まとめだけは書いていたが、過程も残すように意識し始めた）
やっておくと、将来の自分がありがたいというのもあるし、これは自分だけじゃなくて後から見る人はチケットなりIssueを見れば経緯がわかるので良いです。
たとえば方法Aも試したけど、こういう理由でダメだったからBになったんだなぁを知ることができるし、もしかしたら将来の時点では事業フェーズ的に方法Aの方が良い、となるかもしれません。
あとは、別に「評価会」と言う名称だけど評価者と議論する場なので、実は自分が知らなかった機能やサービスがあったり、経験的な知見からこの辺りのエラー処理はしっかり見た方がいいよ、とか学びの場にもなります。
基本的にチケットに残す文化なのですが、もうちょっと「過程」を含めてしっかり残すようにしよう…と思った評価会でした。
まとめ
やる前はgkbrしてたけど評価会楽しかった。
弊社のエンジニアの技術力の評価制度はこんな感じですが、みなさんどうなのだろう…
なにか気になるところとかあったらTwitter（https://twitter.com/saxsir256）なりで気軽にメンションください。
