〜自ら「価値判断」できるエンジニアを育成する！半期に1度の「立候補制」による昇格プロセスをフルオープンにする、GMOペパボのエンジニア職位制度の全貌〜

「人を正しく評価する」ことほど、難しいことはない。

ハンドメイドマーケット「minne（ミンネ）」を始めとする4つの事業と、約100名のエンジニアを有する、GMOペパボ株式会社。

同社では、2012年より「立候補制」を取り入れたエンジニアの職位制度を運用している。

具体的には、8段階あるグレードの4〜6等級について、立候補者に対する昇格審査を半期に一度実施。

審査においては、立候補者が「自分がこの職位に値する理由」を説明する資料を作成し、同社のチーフテクニカルリード（以下、CTL）5名全員との集団面談を行っている。

面談でのディスカッションを通じて「立候補した職位に相応しい」と認められると、昇格する仕組みだ。

同社の技術部長である柴田 博志さんは、立候補制にすることで「エンジニア自ら、課題設定や行動の価値を判断してほしい」と話す。

その価値判断を促すため、立候補資料や面談の講評など、すべての情報をオープンにしているそうだ。

今回は柴田さんと、実際に職位制度を利用してシニアエンジニアに昇格した天野 善彦さんに、エンジニア職位制度の全貌について、詳しく伺った。

▼左：天野さん、右：柴田さん

「追認」で行動を評価。立候補制・エンジニア職位制度の仕組み

柴田　僕は2012年に入社し、チーフエンジニアを経て、現在は執行役員と技術部長を兼任しています。

技術部長として、事業部横断のインフラ周りの責任者を務めながら、エンジニアが働きやすい環境作りや制度設計も担当しています。

弊社では、全社員に共通の評価制度とは別に、エンジニアに対する「職位制度」を設けていて。

これは、8段階あるグレードのうち、4〜6等級については「立候補制」で昇格する評価制度です。ペパボのエンジニア約100名のうち、およそ2割がいずれかの職位に就いています。

▼エンジニアの職位とグレードの関係図

具体的には、4等級をシニア、5等級をプリンシパル、6等級をシニア・プリンシパルと呼んでおり、「課題設定の場所」と「それが解決された時の会社への影響度」を基準として定義されています。

例えば、シニアであれば「部門内の専門領域を理解し、課題に対応できる」、プリンシパルであれば部門内の知識に加えて「会社の3〜5年後を見据え、課題を見つけて実行できる」といった形です。

一方で、7等級以上のチーフ・CTOを除く1〜3等級については、立候補制ではなく上長からの評価で昇格が決まります。

新卒は基本的に1等級からスタートしますが、2等級では「ひとりで仕事ができる」、3等級では「誰かに指導できる」といった共通のガイドラインがあります。

それに基づいて、事業部・職種ごとに定義された要求水準を満たすと昇格します。

また、昇格は必ずしもステップアップではなく、実力があれば2等級から5等級といったように飛び級することも可能です。

この制度の一番の特徴は、目標に対する達成度ではなく、達成した成果に対する「追認的な評価」であることなんですね。

職位に相応しい価値を発揮した人をきちんと評価し、会社の成長につなげることを目的としています。

「この職位に値する理由」を自ら説明する、立候補資料を作成

柴田　元々、この前身となるような仕組みは2012年からありました。当時は技術部門の責任者が面談をして、昇格かどうかを判断する、という簡易的なものでしたね。

それを2014年、現CTOである栗林が技術責任者として就任した際に、制度としてブラッシュアップして。同時に、ペパボにとって「技術力が高い」とは何を意味するのか、改めて言語化をしました。

天野　僕は、元々Rubyという言語が大好きだったのがきっかけで、2014年に中途入社しました。以来、minneで開発に携わっています。

2018年7月に、実際にこの職位制度を利用して、シニアエンジニアに昇格しました。

柴田　半期に1度、2週間にわたる立候補期間がありまして。それに合わせて立候補者は面談で使用するための資料を作成し、選考面談を経て、昇格かどうかを判断されるという流れになります。

資料フォーマットは敢えて自由にしているので、自分自身で何を含めるべきかを判断してもらっていますね。

天野　その資料では、各職位の定義に則って「僕がこの職位に値する理由」を説明します。

▼実際の立候補資料（一部）

例えば、「minneで開発したポイントシステムにおいて、自分がどう考え、どんな行動をしたか」といったことを図や文章で記載します。

実は僕、4度目の挑戦でやっとシニアに昇格したんですよ（笑）。最初は深く考えずに面談で話せばわかるだろうくらいに考えていたので、資料も2〜3時間くらいで突貫で作ったもので。

ですが、面談のフィードバックを受けて、「この機能を開発しました」だけでは自分の技術力の証明にならないと。そこで、開発のプロセスや、その中での役割や行動の意味などを改めて内省して、修正していきました。

昇格審査の面談はCTL全員で。最終の意思決定はCTOが行う

柴田　この立候補資料を提出してくれた全員と、選考面談を実施します。

今年の夏に面談形式をアップデートしたのですが、各部門にひとりずついるCTL全員との集団面談を行っています。

この背景としては、部門間での目線の擦り合わせをしたいと思っていて。というのも、自部門のパートナーがこういう動きをして活躍している、といった時に、それが他部門のエンジニアの動きと比較して優れているのかがわからないじゃないですか。

そのレベル感を、各部門のCTL5人と面談をすることで、相対的に判断できるようにしています。

以前は、僕とCTO栗林のふたりで面談をしたり、技術基盤チームが面談をしたりなど様々な形式を試してきました。ですが、最終判断はCTOの栗林が行う、ということは一貫していますね。

CTL全員が「絶対昇格させるべき」という候補者に対して、僕や栗林が反対意見を持つことはないのですが、例えば2：3に意見が割れて悩ましいこともあるんですよね。

その時は多数決ではなく、最終の意思決定者をCTOの栗林と決めることで、判断を明確にしています。

天野　実際の面談では、資料に基づいて「他のアプローチをしなかったのは何故ですか」といった深堀りされるような質問から始まり、次第にディスカッションみたいになっていくんです。正直それが楽しくて、ダメでも何回も挑戦したところがあって。

僕は、評価制度って「ものさし」のようなものだと思っています。立候補すると、多面から客観的に見てもらえるので、自分に足りていないことに気づけるんですよね。

自分では「これだけ出来るようになった」と思っても、その成長を正しいものさしで知りたい。だから何度も立候補するのかな、と思っています。

立候補資料と講評はフルオープン！エンジニア自ら「価値判断」を

柴田　面談の合否に関わらず、1人ひとりに対して「こういう所が良かったと思います」「こういう所はまだ相当の水準に達していないと思いました」といったフィードバックを丁寧にしています。

こういう評価ってよくクローズにされる情報だと思うのですが、すべての講評は立候補資料も含めて、パートナー全員にオープンにしているんです。

なぜなら、エンジニア自らが「価値判断」してほしいと思っていて。

つまり、会社や部門が取り組むべき課題を自分で判断して行動した結果、会社に価値を生み出す状態が理想なんですよね。それが、プロフェッショナルだと思うんです。

その価値判断できるかどうかを測るためのひとつの材料として、「立候補」があると考えています。

というのも、例えば「自分なんて大したことないですよ」と言う人を、上長が「この人はシニアに相応しいから推薦しよう」といって昇格させたとしても、結局はシニアとして周囲の期待を受けながら仕事をしていくのは難しいじゃないですか。

自分の技術を客観的に評価でき、それをどのように会社に提供出来ているかを述べられる人が、プロフェッショナルとしてのエンジニアなのかな、という風に思っています。

なので、よく「この技術が出来ればプリンシパルになれるんですか」といった質問を受けたりもするのですが、一切答えないようにしていて。

価値を生んだエンジニアに、見合った報酬が与えられる制度にしたいと思っているので、僕から答えは言わないと。

その代わりに、情報をすべて開示することで、会社が求めているエンジニアの動きや価値みたいなものを、自分なりに判断してもらえればと考えています。

他のパートナーの講評などを見て内省し、日々の動き方を1つひとつ見直すことで、次の立候補に向かってほしいと思っていて。結局、それしか答えはないんですよね。

面談前の「コーチング」面談後の「共有会」で立候補者をフォロー

柴田　毎回、3〜8名程度が立候補しているのですが、通過率は半分もいきません。平均すると、半期ごとに2、3名が昇格するくらいのイメージです。天野のように何回か挑戦して、やっと昇格できる人も多いですね。

そんな中で、2年ほど前から立候補者にメンタリングをするエンジニアが現れて。しかも僕や栗林が依頼したわけではなく、ボランティアで立ち上がったんですよ。

何をするかというと、立候補する前にコーチングしてあげるような形で。答えを教えるのではなく「この文章だと伝わりづらいから、ここを説明した方がいいよね」とか「君にはこういう良さもあるよね」といった感じですね。

個人の活動かつ申し込み制ではありますが、立候補者をフォローするひとつの仕組みになっています。

さらに、選考面談後には、同じエンジニア主導で「感想共有会」のようなものを行っています。そこでは、面談で聞かれた内容や感じたことを、立候補した者同士がざっくばらんに共有し合うんです。

そうすると、落ちた人もただ落胆するのではなく、自分に足りない部分を受け入れて、次に向けて何をしようか、というアクションへと繋がっていく。

こうした面談前後のフォローがあることで、職位制度の運用が上手く回っていると感じますね。

組織の変化をベースに、人を後押しできる制度に変えていく

柴田　評価制度って、作った枠組みに人を当てはめがちです。ですが本来は組織の変化がベースにあって、そこに属する人を後押しできるよう変化させていくべきだと考えています。

実際、約6年にわたり立候補による職位制度を続けてきましたが、会社の状況に応じて少しずつ内容を見直してきました。

例えば、2015年頃にminneが急成長した際、エンジニアが扱う課題の大きさが変わってきて。より会社目線を持って行動してほしいという考えから、2016年に元々2段階だった職位の上に、1等級を追加しました。

また、現在では立候補という仕組み自体を見直そうかと考えています。というのも、外国籍のエンジニアが増えている中で、従来の日本語によるディスカッション形式の面談では、どうしても評価されづらくて。

また、ペパボではOSSの開発が推奨されているのですが、国によってはそもそもOSSが普通じゃない場合もあるんですよね。

そうした文化の違いにより正当な評価ができないのは本来の目的に合わないので、ペパボとして技術力をトータルで発揮できるような制度にしていきたいと考えていますね。

また、今後は技術の職位だけでなく、ピープルマネジメントの方でもキャリアパスを整えていきたいと考えていて。

CTLの前身となるような職位を用意して、人のパフォーマンスを最大限に高めて成果を出す、という面でも活躍してもらえるような土壌を用意していきたいですね。（了）