棟梁エンジニアの人事評価制度

はじめに：「信託」の構造

メドピアのプロダクト組織は、「指揮者」と「棟梁」の存在によって作られることを理想形としています。

指揮者と棟梁－プロダクト組織の理想形｜メドピアのnote

指揮者と棟梁－プロダクト組織の理想形｜メドピアのnote

後藤です。第5回目のレターでは、プロダクト組織の理想形について書いてみたいと思います。このプロダクト組織の形を表現するために、「指揮者」と「棟梁」というちょっと馴染みのない言葉を導入してみたいと思います。 プロダクト組織の理想形 まず最初に、なぜこの話をしようと思っているのか少し説明します。 私はプロダクトというものが本当に好きです。メドピアはヘルステック企業ですが、テック企業の一番の中核はプロダクトを創造することにある、と私は考えています。どんなに強いセールスチームやカスタマーサクセスチームがいても、根本のプロダクトが素晴らしいものでなければ、テック企業として中長期的に成功する

style.medpeer.co.jp

指揮者はUser/Client Valueに奉仕し、棟梁エンジニアはProduct Valueに奉仕する。 だから指揮者はProduct Valueの実現を棟梁に「信じて託す」——この関係性が、メドピアのエンジニア人事制度の根幹にあります。

信託──指揮者と棟梁を繋ぐもの

AIがレバレッジの定義を根本から変えたパラダイムシフトの中で、なぜこの制度が必要になったのか。「信託」という概念を軸に、代表の後藤が伝えているものです。

信託　－指揮者と棟梁のあいだにあるもの｜メドピアのnote

後藤です。メドピアでは、2026年4月からエンジニアの人事制度を刷新しました。 そのベースとなる考え方は、昨年10月に投稿した「指揮者と棟梁」というプロダクト組織に対する考え方にあります。この後、エンジニアの人事制度の策定に携わったプリンシパルエンジニア陣たちの記事がリリースされるということで、私の方で、この人事制度刷新の背景とその根幹にあるコンセプトについて、Letterとして書き残しておきたいと思います。 一人のエンジニアの退職意向がきっかけだった 半年前、「指揮者と棟梁」のLetterを書いたのには一つのきっかけがありました。その話を最初にしたいと思います。 実はこのL

style.medpeer.co.jp

信託の範囲がGradeを決める

この「信託」の考え方をそのまま等級に落とし込んだのが、新しいエンジニア人事評価制度です。このエンジニアにどこまでの開発を信じて託せるか―すなわち信託の範囲が、そのままキャリアの段階になります。

本制度は2026年4月よりプレ運用を開始しており、正式移行は2026年10月を予定しています。

5段階のGrade

G4以上が「棟梁」。G1〜G3は棟梁になるための過程であり、信託の範囲が広がることでGradeが上がります。

3つの要件軸

Gradeが上がるにつれ、3つすべてが高い水準で求められます。

1. Quality — 信託の基礎

中長期の時間の審判に耐える品質。技術者倫理、保守性の高い設計、リスク管理、問題解決力、未踏領域の探究。指揮者が「この人なら任せられる」と判断する、エンジニアリングの聖域です。

2. AI Leverage — 圧倒的なアウトプットを生む力

AIを「大工」として使いこなし、コーディングエージェントのパフォーマンスを最大化する。AIが出力したコードの正誤を判断する眼力。AIが自律的にロングランできる環境を整備し、暴走しても回復可能な仕組みを構築する力。

3. Direction — プロダクトの北極星を示す力

技術の力で、プロダクトが進むべき方向を指し示す。ユーザー・クライアントの体験への理解、戦略の言語化と意思決定、組織の変化のモメンタムを生むフォロワーシップ、本質を見抜き「あるべき未来」を描くビジョン。

評価の考え方

従来のMBO（目標管理制度）は廃止し、月報とGitHub等のログによる事実ベースの評価に移行しています。期初にプロダクトディレクターや事業開発者とプロダクト開発方針をすり合わせ、期中は月次で事実を蓄積し、期末にその実績をもとに評価を行います。

評価基準は固定ではありません。組織・業界の技術水準が上がれば、求められる水準も上がる——進化を前提とした動的な基準です。

制度設計の経緯