「SELECK miniLIVE」は、注目企業からゲストスピーカーをお招きし、X（旧Twitter）スペース上で30分間の音声配信を行う連載企画です。

2024年3月28日に開催した本回のゲストスピーカーは、株式会社ココナラで執行役員 兼 VP of Engineeringを務める村上 正敏さん。

SELECK編集部では、過去に同社の等級制度について取材させていただいており、今回はそこからさらに発展して、「エンジニア評価制度」の現在地にフォーカスして詳しくお話を伺いました！（聞き手：株式会社ゆめみ / Webメディア「SELECK」プロデューサー 工藤 元気）

本記事は、2024年5月15日に開催したSELECK miniLIVEの生配信を書き起こしした上で、読みやすさ・わかりやすさを優先し編集したものです。当日の音声アーカイブはこちらからお聞きいただけます。

組織課題や技術課題などを管轄し、エンジニア評価制度を設計

工藤　SELECK miniLIVE、第2回目のゲストは株式会社ココナラで執行役員 兼 VP of Engineeringを務める村上さんです！よろしくお願いします。

村上　よろしくお願いします。

工藤　まず、村上さんの現在のポジションや担当されている業務スコープについて、簡単にご紹介いただけますか？

村上　私はココナラに入社して5年目になります。入社前のフリーランス時代から1年ほどプレイヤーとして関わっており、今は執行役員として組織課題や技術課題などを管轄しています。

何かトラブルがあると私のところに話が来るのですが、必要に応じて現場に入って手を動かすこともあるので、社内の「何でも屋さん」という感じです。

工藤　課題解決屋さんのような位置づけなんですね。続いて、ココナラさんの開発組織について伺えればと思いますが、現在エンジニアの方はどのくらい在籍されていますか？

村上　4月に新卒メンバーが入って約80人になりました。そのうちエンジニアマネージャーは8人ほどなので、自分も含めてマネージャー1人あたり10人弱のチームを見ているという構成になっています。

技術力に焦点を当て、6段階のグレード定義でエンジニアを評価する

工藤　では、本日のテーマである「エンジニア評価制度」のお話に入らせていただきます。

実はSELECKでは、2018年に当時ココナラのCEOだった南さんにインタビューさせていただき、全社の評価制度について伺っておりました。そして今回、当時からさらに変化した形の「エンジニア評価制度」ができているとお聞きしたので、本日はそちらについて詳しくお伺いできればと思っております。

このエンジニア評価制度は、村上さんが設計や立ち上げをされた取り組みになるのでしょうか？

村上　はい。私が部長だった2021年頃に、元創業者の1人から「エンジニアに特化した評価制度を作った方がいいのではないか」と相談を受け、私自身もエンジニアの評価について課題感をもっていたので、ゼロベースから着手しました。

工藤　エンジニア評価制度がどういう設計になっているかについて、ご説明いただけますか？

村上　大きな特徴は、「エンジニアグレード」というグレード定義があることです。グレード1からグレード6まで6段階に分かれており、段階ごとに基準や指標を設定し、各エンジニアの成長過程を評価していく設計になっています。

評価については、エンジニアマネージャーによる「技術評価委員会」をつくり、半年ごとのサイクルで委員会メンバーが行っています。

加えて、以前からある全社共通の評価も続けており、そちらとエンジニア評価制度をハイブリッドで運用している形です。

全社共通の評価は、職種に関係なく「プロジェクトを予定通りにバグなくリリースできたか」「心がけとして、あるべきスタンスを発揮できているか」などの基準になり、エンジニア評価制度は、そちらにアドオンする形で主に技術力に焦点を当てた評価基準になっています。

工藤　元々ある全社共通の評価では、カルチャーフィットの部分や行動規範などを評価し、エンジニア評価制度はそれにアドオンして技術力の面を評価する、ということですね。

指標は「Before、After、During」の問題解決能力と、採用・育成能力

工藤　技術力を評価する際には判断が難しい部分もあると思うのですが、評価指標はどのように定義されているのでしょうか？

村上　確かに、技術力は測るのが難しい側面があるのですが、私たちは4つの指標を設定して評価を行っています。

まず、1〜3つ目の指標として、問題に対して技術を通して解決できる能力を、Before、After、Duringに分けて設定しました。

1つ目の「Before」は、問題が起きる前に対処できる力です。つまり、起きうる事象を先読みした設計力ですね。

2つ目の「After」は、問題が起きた後に対処する力です。問題発生後、迅速に原因を切り分けられるか、応急処置的な対処ができるかを見ています。

3つ目の「During」は、問題が継続的に発生している中で、より良い運用へと改善していく力です。

この3つの指標で、技術を通した問題解決能力を評価しています。

工藤　これは新鮮ですね！一般的に言われている技術力というものを、どの時間軸で起きた問題に対して発揮する能力なのか、という観点で細分化・言語化されていると感じました。

村上　おっしゃる通りです。そして4つ目は、採用・育成能力の指標です。1〜3で挙げた問題解決能力をもつ人材を採用して確保したり、育成したりすることができるかですね。

工藤　先ほどの6段階のグレードで言うと、上に行けば行くほど、採用・育成能力の高さが見られていくわけですね。そうなると、エンジニア全員が採用・育成のポイントを意識する文化も作られますね。

村上　そうです。ただ、そもそもグレードの低い方は採用面接に入る機会が少ないので、例えばテックブログを書いたり、イベントに登壇したりなど、技術広報的な取り組みも間接的に採用に繋がると考えて、評価軸に含めています。

エンジニアも多種多様。職種ごとに求める能力の具体例を示すことが大切

工藤　エンジニア評価制度の運用開始から2年半〜3年経ったフェーズかと思いますが、その中で変化してきた部分はありますか？

村上　ひとことでエンジニアと言っても、フロントエンド、バックエンド、アプリ、インフラ、情シス…など職種が幅広くなっているので、エンジニアの共通評価はなかなか難しくなってきている面がありますね。

先日、他社の方と評価制度に関してディスカッションした際にも、「細かく明文化し過ぎると当てはまらない人が出てくるので、どうしても曖昧な表現にせざるを得ない」という話が出ていました。

この課題に対しては、共通の定義は曖昧に置きつつ、職種ごとに6段階のグレードに沿って具体例を示しておく、という形で対応を進めています。

例えばフロントエンドエンジニアなら、「1グレード目ではこういうことができたら良いよね」という具体例を挙げ、イメージしやすいように落とし込んでいくやり方です。手間はかかりますが、落としどころとしては良いのではないかと考え、今取り組んでいるところです。

工藤　共通定義はあえて抽象化しつつ、目的や目標に対して具体的には「こういうことができれば1個上に進む」と、分かりやすく設計されているわけですね。

村上　ポイントとして、この具体例についてはトップダウンで決めるのではなく、現場で考えてほしいとお願いしているんです。やはり、目指す姿は自分たちで定義できた方がワクワクすると思いますし、「これが俺たちの目指したい姿だ」というものを宣言してもらいたい気持ちもあるんですよね。

バイアスを防ぐため、「成果物＝ファクト」に基づいた評価を心がける

工藤　評価については、エンジニアマネージャーによる「技術評価委員会」のメンバーが半年ごとに実施するということでしたが、こちらの評価プロセスについて教えていただけますか？

村上　技術評価委員会では、各マネージャーが自チームのメンバーの評価を持ち寄り、他のマネージャーたちにプレゼンを行って、合議して評価を決めていきます。このとき大事なのが、別グループの同じグレードの人としっかり相対的に比較することです。

工藤　確かに、そこは「主観が入らないのかな」と気になっていました。

村上　まさにそうで、主観によるバイアスがかからないように、2つのポイントに気を付けています。

1つ目は、別部署の同グレードのメンバーと横軸で比べたときに、成果発揮レベルが同じかどうか、という点です。これに関しては基準値を共通定義しているので、そこからずれた解釈をしていないかを見ています。

2つ目は、評価対象者本人に成果物を用意してもらっている、という点です。例えば、ソースコードやドキュメント、プロジェクトや障害に対応したSlackの履歴など、必ずファクトを用意してもらい、それに基づいて評価を行っています。

工藤　成果物を用意するということは、評価会議の前に各マネージャーは自チームのメンバーと1on1を実施するなどの事前準備をされるのでしょうか？

村上　1on1は実施していますが、評価の事前準備という位置づけではないですね。成果物は後でまとめると忘れてしまう場合があるので、いつでも提出できるように、普段からスプレッドシートに記入するよう習慣化してもらっています。

とは言え、負荷がかからないように、基本的にはタイトルとリンクだけを記載することにしています。ドキュメントやSlackのリンクなどを貼り付けてもらい、あとはタイトルをつけてもらえれば、気軽に登録できるという形です。

工藤　それならマネージャーも把握しやすいですね。シンプルでメンバーの負荷が少ないけれど、アピール材料として十分なファクトが用意できるところに設計の妙を感じます。

村上　評価サイクルが半年ごとなので、評価の直前にまとめようとすると最初の1〜2ヶ月の成果物は忘れられてしまうことがあるんです。それはもったいないですし、そういうものも評価から漏れないよう、定期的に更新するようアナウンスしています。

今後の大きな成長を見据え、全面刷新もいとわない姿勢で進んでいきたい

工藤　では、最後の質問です。エンジニア評価制度について、今後の展望や工夫していくポイントがあれば教えていただけますでしょうか。

また、私個人として、ココナラさんの採用TOPページを拝見して「非連続な成長の実現」という言葉が非常に印象深かったんです。今後の展望に関して、非連続な成長という観点からもお聞かせいただいてもよろしいでしょうか？

村上　まず、「非連続な成長」についてお話しますね。弊社は上場を果たしたものの、まだ第2創業期と位置づけており、これからユーザー数も1桁アップするぐらいのプロダクトに成長させていきたいと考えています。

そのためには、現状の延長線上にある安定した道を歩むのではなく、攻め続けなければいけません。仮に今の仕組みが上手くいっていたとしても、中長期的にはそれを壊して、新しくより良いものを作っていくスタンスをとる必要も出てきます。そう考えて、「非連続な成長の実現」という言葉を使っているんです。

エンジニア評価制度の今後の展望についても、もしワークしなくなってきたら全部壊して、新しいものを作る可能性もあり得ると考えています。

実際に、私としては「この制度は未完の状態である」と定義しているんです。常にアップデートし、最新化したり別の手を打ったりしながら、作り変えて進めていく制度である、と。

ですから、必要であれば全面刷新もやっていきます。すでに1度大幅なバージョンアップをしているので、今後もその姿勢を継続することが大切だと考えています。

工藤　「上場したけど、第2創業期」というメッセージは非常に印象的ですね。安定路線ではなく攻めていく、場合によっては全面刷新もやっていく、というのはメンバーの方にも伝えているメッセージなのでしょうか？

村上　先日の全社キックオフでも伝えましたし、きっかけがあれば言っています。スタートアップ気質というか、泥臭く、常に見直しながらやっていくという姿勢は発信していますし、メンバーにもそうした気持ちで成長していってほしいですね。

工藤　ちなみに、この4月でエンジニア組織が約80人になられたとのことですが、今後どのくらいの規模になったタイミングで、エンジニア評価制度のリニューアルが必要になりそうだと想定されていますか？

村上　他社さんの状況などから判断すると、200人規模になってくると必要になりそうだと感じています。その規模になると、部署が分かれたり細分化したりして、今の制度ではワークしない部分も出てくるのではないかと思うので。とは言え、その規模を超えるくらい、もっともっと採用して組織を大きくしていきたいですね。

工藤　ありがとうございます。これからも上限を設けずに、攻めの姿勢で組織を拡大していくということですね。

さて、今回は30分の対談をお届けする企画ということで、お時間もあっという間に過ぎてしまいました。村上さんから読者の方々へ、お伝えしたいことがあればお願いします。

村上　最後に少しココナラについてお話しさせてください。実は今、弊社はめちゃくちゃ面白いフェーズに入っているんです。

これまでは「ココナラ」というプロダクトで成長してきて、上場も果たしたのですが、今は「ココナラ経済圏」という形で、多角化路線に切り替え始めたタイミングです。多角化といってもミッションは変わらず、「スキルや知識、経験を軸に、それをあらゆる人に届ける」という価値観のもと、さらに大きな「ココナラ経済圏」を作っていこうと考えています。

そのために新しいシステムをゼロベースで作りこむなど、なかなか味わえない面白い取り組みが進んでいますので、興味のある方はぜひご連絡いただければ、と思っております！

工藤　今がまさに入り時ですよ！ということですね。

村上　エンジニアとしての職務経歴やトラックレコードを作る上でも、良い経験になるのではないかと思います。

工藤　それは素晴らしいチャンスですね！気になるエンジニアの方は、ぜひココナラさん、村上さんにお問い合わせいただければ、と思います。

第2回SELECK miniLIVE、本日のゲストは株式会社ココナラの執行役員 兼 VP of Engineeringの村上さんでした。本当にありがとうございました！

村上　ありがとうございました！（了）