「棟梁」という新定義が、物差しを作り直す必然を生んだ

── 新しい人事制度の設計に関わることになった経緯を教えてください。

PEの体制が立ち上がった時点で、「評価制度を変えよう」と明確なミッションがあったわけではありませんでした。「棟梁」という概念を軸に、エンジニア組織として何をやらなければいけないかをブレストするなかで、評価制度の話が自然と出てきたんです。グループリーダー制（マネジメント制）を廃止する議論とも絡んで、「これは人事制度を大きく変えないとダメなんじゃないか」と。これは僕ら棟梁エンジニア起点の発信だった気がしますね。

僕は元々いちエンジニアとして医師プラットフォームの機能開発に携わっていたのですが、昨年9月の全社ミーティングのフォローアップ会で、組織デザインの方向性に疑問を投げたのがきっかけでした。そこから僕と人事責任者の山際さんと社長の後藤さんとの対話が始まって、PEの一員として制度設計に加わることになりました。現場として感じた疑問が経営との対話につながり、そこから制度設計が動き出したという流れです。

僕の場合は、役割分担のなかで自然と加わった形です。PEのメンバーのなかで、大企業での人事制度を知る人が少なかったので、「こういうやり方もありますよ」という選択肢を提示できるのは自分の役割になるかなと思って引き受けました。

── 既存の制度には、どんな限界があったのでしょうか。

既存の制度でも、運用の工夫次第では棟梁的な人を評価することもできたかもしれません。ただ汎用化された制度だったので、「新たなエンジニア組織としてどの方向に進むのか」を既存の人事制度のなかでは表現しきれない。エンジニア像を「棟梁」と新しく定義した以上、それを真正面から測れる物差しが要る。だから明確に舵を切って、制度そのものに指向性を持たせる必要がありました。

運用で補える部分はあっても、公平性・公正性には限界がありました。棟梁像に沿って「どう伸びればどう評価されるか」を明確にするには、評価軸自体を作り直す必要があったと思います。

既存の制度が、マネジメントラダーを前提にした等級設計だったことも大きいですね。「棟梁として開発をどれだけ任せられるか」という、本来いちばん測りたい部分が、そもそも等級のなかに組み込まれていなかったんです。

Qualityを土台に。3つの軸はこうして決まった

── Quality・AI Leverage・Directionという3軸は、どのように決まっていったのですか？

最初の2〜3ヶ月はPE内で議論しながら制度を組み立てていたのですが、ポリシーの大上段がうまく定まっていなかったんです。形としてはまとまっていても、この制度をもってどんな方向に進みたいかがはっきり見えないものになっていました。あるタイミングで「やはり、無難すぎないか」と気づいてから、後藤さんからあらためてポリシーを提示してもらい、仕切り直すことにしました。
ポリシーは経営が示し、PEがそれを実装するという役割分担は後からクリアになった部分ですが、実はこの制度設計のプロセス自体が、制度が表現しようとしている「信託」の構造そのものだったと思っています。

後藤さんに提示してもらった、人事制度の大上段となるポリシーの型が、Quality・Speed・Directionの3要素でした。そこからPEの議論で微調整が入って、「Speed」を「AI Leverage」に置き換えた。スピードを支える手段がAIの登場で根本から変わったので、そちらを明示すべきだろうということで。

個々の要素で見ると、実はそこまで目新しくはないんです。クオリティもディレクションも、エンジニアとして従来から大事だったこと。他社の人事制度でも近いキーワードは見かけます。ただ、元々は真ん中にあった「人をうまく束ねてレバレッジを利かせる」というマネジメント要素が、AIによるレバレッジに置き換わっている。そこが今回の制度のいちばん新しいところだと思います。

しっくり来たのは、3つの軸が同列ではないという点でした。クオリティが土台にあって、その上にAI LeverageとDirectionが乗る。棟梁の定義である「長期耐性」を支えるのがクオリティだから、ここが最重要。この構成が、指揮者としての後藤さんがエンジニアに何を信託したいのかを、端的に表していました。

クオリティって、作っている人以外からは見えにくいものなんです。スピードは目に見えやすいけれど、長期にわたってプロダクトを支える品質は、中の人間にしかわからない。それを評価軸の土台に置くと決めたことが、指揮者から棟梁への信託の象徴だと思っています。

── 議論のプロセスで、葛藤もあったそうですね。

自分が痛感したのは、「変化の痛みに対して防御的になっている自分」でした。組織としてこの規模の変化を一気に加えるとハレーションが起きる、という懸念は何度も議論した。でも振り返ると、譲れないと思っていたポイントは、変化の痛みに自分が防御的になっていただけで、誰のためにもならないものでした。それを自覚してからは、受け入れられるようになっていきました。

僕はずっと引っかかっていた論点が一つあって。当初は「今後はマルチスタック・フルスタックがより必要であり、本制度でも強く言及する」という流れで議論が進んでいたのですが、その“フルスタック”という要件そのものが目的化してしまっている印象があった。重要性は理解しつつも違和感があって、PEメンバーに何度も壁打ちしてもらったんです。

Slackのスレッドが長くなるやつですね。50件くらいやりとりしちゃって。

（笑）。最終的には、要件の手前にある「今後エンジニアが果たすべき責務は何なのか」をはっきりさせるところから整理し直しました。小さな違和感を逃さないことは、制度設計の過程でかなり意識していました。
▼ 関連記事はこちら
第二創業期のメドピアが定義する、次世代エンジニアの「三つの責任」

「信託の範囲」で測る。ジャンプが必要な成長を求める

── 新制度では、ジョブグレードを5段階とし、「信託の範囲」で分けることにしていますね。

従来の制度は大きく9段階、その中にさらに細かいクラスもあるなだらかな階段型でした。ちょっとずつステップを踏んで登りやすいようになっていましたが、それをやめました。

やさしい制度ではあったので、なんとなく成長している気になれてしまうんですよね。マネジメントラダーも設定されていたので、ピープルマネジメントを通じて成果のレバレッジを効かせる道も存在していました。でも、このAI時代に「価値を十分に発揮できる人材」の再定義をしてみたら、マネジメント要素がそぎ落とされて、グループリーダー制を廃止すべきという結論にもつながり、すごくシンプルなものが残ったんです。

それで「信託の範囲」に準じて分けた5段階にしたら、足をかける幅もすごく大きくなりました。今後それくらいの壁を乗り越えられる成長幅がなければ、エンジニアとして価値発揮が難しくなる——そういう前提で、あえて振り切っています。

逆に言えば、棟梁性のある、信託される範囲の広いエンジニアが報われる制度になったので、「棟梁」にあたるG4以上のグレードは従来より高い給与レンジになっています。

── 評価の方法も大きく変わりました。目標管理型（MBO）を廃止して、月報とログによる事実ベースの評価に。

もともと一次評価者だったグループリーダーが事実ベースのログを手動で収集していたのですが、グループリーダー廃止に合わせて、その業務自体を廃止するためにも自らの月報とGitHub等のログベースの評価に作り変えました。

結果として、どの信託の範囲でも自分で問いを立て、その問いに技術で答えや解決策を見出していける人が重要視され、間違いなく評価されるようになったのではないかと思います。月報のフォーマットも、自分のグレードと照らし合わせて「こういうことをやらなければいけないからやりました」と書いてもらう形にしています。どんな問いを立てたかも、月報から自然に見えてくるようになっています。

不確実な時代に、自ら答えを出しに行く

── この制度を見て、どう感じるエンジニアに来てほしいですか？

エンジニアは皆、AIに淘汰されずに残る道を探していると思うんです。この評価制度は、AI時代に必要なエンジニアのあり方を体現する方向を一つ示している。漠然と不安を抱えて働くよりは、明確な方向性のもとで自分を磨きたい——そういう人に来てほしいですね。

自分は何をもって価値を発揮するのか——その問いを立てられる人。AI時代に必要なのは、変化のなかでも自分の定義を更新し続けることだと思っていて。メドピアは、その問いに正面から向き合える会社だと思っています。

会社として、評価制度という形でこの方向に全振りしている。そのメッセージにポジティブに反応できる人ですね。プロダクト開発に集中したい、指揮者と棟梁の関係性に共感してくれる人であれば、エンジニアとして働きやすく、活躍しやすい場所だと思います。
一方で、この制度が一つの答えではあるけれど、生き残り方の唯一解というわけでもありません。プロダクトディレクターやビジネスオペレーションエンジニアのような、エンジニアリングだけに拠らない方向に進む選択肢もある。どの道を選ぶかは、個々のエンジニアが主体的に判断することです。

キャリア形成って、結局そこに行きつくと思うんです。自分は何がしたいのか、何に向いているのか。その問いに向き合える人に来てほしいですね。

── AIによる環境変化が著しい今、人事制度をエンジニア当事者の手で変革したことは大きな意味があると思います。

そうですね。一方で、最先端を行っているとも思っていませんし、これが完成形でもないと思っています。単純に、AIとエンジニアが共存しようとするこの時代は「分からないことだらけの道のりだ」とは思います。でもいま、制度の刷新もそうですし、僕らなりの答えをちゃんと作っていくこと自体は、楽しいと思っていますね。

もちろんこの制度も固定するのではなく、新たな問いを立てながらどんどん変えていくべきだと思います。不確実性のなかで「どうなるんだろう」と不安がるだけではなく、自ら一度答えを出して前に進もうとする——そういう姿勢が必要なのかなと思います。

── 半年後のプレ運用を終えたとき、この制度が「成功した」と言える条件は何でしょうか？

自分はどういう価値を実装する存在なのか——そのスタンスを取り、アクションにまで落とし込めている人が増えていること。たとえば成長角度が上がっているとか、一人ひとりが自分の答えを行動で示している——その状態が作れていれば、成功だと思います。

棟梁性の高いエンジニアが、その能力を十分に発揮して正当に評価される状態。そして、その傾向がエンジニア全体に浸透し、各エンジニアが次のステップへ進む方法を自分で認識できていること、ですかね。

うまくいくか、正直、確信はありません。でも、今回のプロセスで一番大きかったのは、評価制度を自分たちで一から作ったことでした。人事が発信するのではなく、エンジニアの口からちゃんと話さないといけない。だから自分たちがちゃんと納得しきらないといけないと思えた。変にオブラートに包まず、素直に伝えられるものが作れたこと自体が、一つの成果だったと思います。

▼ この制度が生まれた背景（代表 後藤のnoteより）
「信託——指揮者と棟梁を繋ぐもの」

▼エンジニア向け人事評価制度の骨格について
Engineering at MedPeer「棟梁エンジニアの人事評価制度」