今回からはゲストに株式会社カミナシのCTO・原トリさんと、株式会社10XのCTO・石川洋資さんを迎えてお送りする。MCはおなじみ、キャディのばんくしさんだ。

【MC】
キャディ株式会社 Tech Lead
河合俊典（ばんくし）さん（@vaaaaanquish）

【Speaker】
株式会社カミナシ 執行役員CTO
原トリさん（@toricls）

【Speaker】
株式会社10X Co-Founder, 取締役CTO
石川洋資さん（@_ishkawa）

【今回の相談】

最近マネジャーになりメンバーを評価をする立場になったことで、エンジニアの評価の難しさを実感しています。

皆さんがエンジニアを評価する際に意識していることや、評価制度の工夫を教えてください。

評価で重要なのは、納得感のある説明をすること

河合：CTOである原さんと石川さんにぴったりの質問ですね。お二人ともこだわりがあるのではないでしょうか。

まずは石川さん、エンジニアの評価についてどのようにお考えですか？

石川：基本的には、「評価を下してやる」といった姿勢ではなく、「その人の成果を他人に説明するための手伝いをする」ような感覚でいます。

10Xでは、部門を超えて評価の目線を合わせるための「キャリブレーション」という場を設けているんです。エンジニアリング部門内でも、さらには職種を超えても共通する評価基準があるので、その人の評価の妥当性を説明する必要があるんですよ。

つまり、評価に論理だっている必要がある。なので私の場合、「キャリブレーションの場に持っていくものとして正当かどうか」ということを判断するために評価をつけるようにしています。

評価の材料は、マネジャー自身よりメンバーの方が多く持っていますよね。ただ、メンバー一人一人が自分の成果を説明できるようにする責務はマネジャーにあるので、マネジメントの立場から見えてるものを付加していくんです。

その結果として、メンバーと協力して部門外の人に対してでも説明できるようにすることを意識しています。

河合：原さんは評価についてどんなご意見をお持ちですか？

原：僕は前職までプレーヤー一筋だったので、 カミナシでCTOになって初めてピープルマネジメントに関わるようになったんです。なので、この相談者さんの悩みにはとても共感します。その上で僕が意識していることをお伝えしますね。

例えば、メンバーが大きな成果をドンっと出したとします。もちろん評価すべきなのですが、大抵の企業にはジョブグレートやジョブレベルと呼ばれるような等級がありますよね。

成果が出たときに等級を上げるという判断になるかというと必ずしもそうではなくて、今回の成果に再現性があるかどうかを見るようにしています。再現性のある成果の出し方をしていたり、動き方ができていたりしたら、それは等級を上げるのにふさわしいですよね。

再現性の有無が怪しい場合は、何度か同じ規模の成果を確認できてから等級を上げることを検討する、といった方針で評価のフィードバックをするようにしています。

原：評価の仕組み作りでいうと、カミナシには全社統一の等級要件があります。技術部門の視点としては、抽象的で判断が難しい場合もあるので、エンジニアのための等級要件のサブセットを作って運用していこうと考えているところです。

これには、マネジャーがメンバーと目標設定をするときに、次の等級を目指すためにはどうすればいいかという話をしやすくする狙いがあります。まずは、マネジャーに対して等級要件のサブセットの背景にある考え方などをインプットしていくところからスタートですね。

河合：お二人とも共通して説明責任を大事にしている点が印象的ですね。

創業者でもある石川さんにお聞きしたいのですが、経営層となると、エンジニアの最終的なアウトプットやその先の利益は見えているものの 、メンバーに対しては相対評価になりがちかなと思っていまして。その対策はありますか？

石川：相対評価への対策は難しいですよね。ですが、原さんの話にも出てきた等級要件が明確に定義されてることが重要かなと思います。

抽象度が高かったとしても、存在すること自体がすごく大事なのではないでしょうか。成果がその等級の要件に当てはまっているかどうか議論ができますから。基準が存在することによって、それを超えていることの説明方法をマネジャーとメンバーが一緒に考えられますよね。

河合：基準が言語化されてることが大事なんですね。

続いて原さんにも伺いたいのですが、先ほど「再現性を計る」と仰っていましたよね。ただ、大きく成果を出したのに給与が上がらなかった場合「なんで？」とメンバーが疑問を抱くこともあるのではと思いまして。その時はメンバーにどう説明しますか？

原：カミナシにはD、C、B、A、S、SSと6段階の評価記号があり、記号が上がれば昇給はするんです。ただ、評価がSだったからといって等級の方が上がるかというと、それはその人の成果の出し方にも関わってきます。

例えば、成果が出しやすいプロジェクトに配属された人もいれば、市場の影響を受けやすい難しいプロジェクトを担当していた人もいる。後者の方が成果の規模は小さいかもしれませんが、仕事の進め方としては高い等級のエンジニアに値すると捉えられるケースもあるはずですよね。

そういう意味で言うと、評価記号と等級が一致しないこともあるので、理由をしっかりとフィードバックするようにしています。

自己成長がモチベーションにならないメンバーの評価、どうしてる？

河合：現時点で、原さんが評価に対して感じている課題はありますか？

原：ありますよ。マネジャーとして、メンバーの成長につながるフィードバックができているかどうか不安になる時があります。

会社の仕組みとしても、評価方法はもっと考えていく余地はあるかなという話が常に出ていますしね。

河合：評価には正解がないので、どこの会社に行っても何らかの課題は出てきますよね。私もフィードバックについて課題を感じているので、ここはぜひ石川さんにアドバイスをいただきたいです。

原：どーんとメンバーが成長するようなフィードバックの方法を聞きたいですね。

石川：すごくハードルが上がってるんですけど（笑）

10Xでも昨年の10月から評価制度が大きく変わり、試行錯誤中のため僕自身もまだ正解は持てていないのですが、次の等級を目指す場合に出すべきインパクトが等級要件で定められているので、そこに意識を向けますね。

石川：10Xでも等級と評価は制度上では別物になっていて、良い成果が出たら良い評価にはなるのですが、等級判定はそれとはまた別で行うんです。等級に関しては、原さんがおっしゃってた再現性のような部分が加味されるようになっています。

上の等級の者に何が求められるのかというと、チームを変化させることであったり、大きい部門のミッションを背負うことであったり。要は、部門全体に対してインパクトを与えるような成果を出すことです。そういった成果が、再現性を持って出せているのかどうかが等級要件で計られます。

求められる成果のサイズが等級ごとに違うため、よりインパクトを与えるためにはどうしたらいいか自然と考えられる仕組みになっているんです。フィードバックがうまいマネジャーは、この部分を上手に使ってると思います。

河合：「別にインパクトを与えるような人になりたいわけじゃない」という人もいるのでは……と思っているのですが、その場合はどうしたらよいのでしょうか？

石川：さまざまなキャリア観を持っている人がいますからね。次の等級には行きたくないという人の考えも尊重されるべきだと思いますし、会社としても受け入れていく前提ではありますね。

全員が「大きなことをやるんだ！」という状況で組織が回るかというと、そうではないとも思っているんです。役割はいろいろですから、自分が動きたいスタイルで成果を出していくことが尊重できるといいなと思います。

原：僕からも聞きたいのですが、責任範囲を自分が快適な位置にとどめたいから等級は上げたくない、という人は一定数どこの会社にもいますよね。ただ、大体の会社では等級に給与レンジがひも付いているので、その働き方を選ぶと給与が上がっていかないという事象が起きてしまうじゃないですか。10Xには、そこがうまくいくような仕組みはありますか？

石川：全ての等級で給与レンジが異なるわけではないんです。つまり、等級の上下の中でも給与レンジがかぶる部分があり、その幅も広くもうけています。なので、今のところそういった問題が起こることは防げていますね。

河合：石川さんや原さんは、大きいことを成し遂げたいというような原動力で事業を立ち上げたり、今のポジションに就いているのかなと思うのですが、成長することに意欲的ではない場合も多様性として受け入れよう、という考え方がお二方にはあるんですね。

石川：より上を目指したい、より大きな仕事をしたいという人とそうでもないという人がいると思いますし、 タイミングにもよりますよね。とにかく仕事で成果を出したい時期と、他のことに集中したい時期、家庭に時間を使いたい時期があると思います。

同じ人であってもおかれてる状況やタイミングによって、 キャリア観も変わってくると思うので、多様性は認められるべきかな、と考えていますね。

原：僕も完全に同意です。僕自身は「もっと難しい課題を解きたい」という気持ちに従っていたら今の状況になっていたのですが、人によって考え方が違うということは意識しています。

河合：エンジニアの評価の難しさと、個人差がある中で納得感のある制度を作っていくことにどの会社も尽力している様子が分かりました。私も非常に勉強になりました。ありがとうございます！

文/まゆ