プロダクトエンジニアの評価軸【アセンドの場合】
みなさん、こんにちは。物流・運送会社向けにSaaSを開発するアセンド株式会社でCTOを務めている丹羽（@niwa_takeru）です。
年度末の評価シーズンということで、アセンドがプロダクトエンジニアをどういった軸で評価しているか社内向けにまとめた内容を社外ドキュメントという形で１事例を示す目的で公開します。
シリーズAに入ったばかりのスタートアップということで評価軸の粗い点やフェーズによって異なる点はありますが、それを踏まえた上で参考となれば幸いです。また今回は特に評価軸に関してまとめ、妥当性のある目標設定の仕方については別記事に委ねます。
プロダクトエンジニアの評価軸
定性的な成果の比重が高いプロダクトエンジニアをできる限り正しく評価するために、定性である中でも評価軸を整理し明らかにすることとしました。
評価の軸を整理することで、評価に対する納得感を作ることだけでなく、各個人がより具体的にキャリアを設計できるようになり、自身の成長と昇格を早められるようになることを目的としています。
シリーズAのスタートアップはまだまだ事業のボラティリティが高いフェーズです。短期的な新規顧客獲得による業績作りと、中長期的な事業成長につながるプロダクトと組織への投資を同時に進めています。
基本的にプロダクトエンジニアを含めエンジニアはPL/短期軸よりもBS/中長期軸に対する貢献への評価比重が高いものですが、現在は足元の業績貢献も事業を創る者の行動として少なからず見ています。
アセンドの評価制度
■ 年に２回、半期で目標設定し中間と期末で評価とフィードバックを実施
■ 創業当初から等級制度を策定・運用しており、現在は全７等級と各４段階を設定（例、G3-4）
■ 現在は等級に対して報酬を設定
成果評価
運送管理SaaSを開発するアセンドが追っている数値はARR(Annual Recurring Revenue) です。事業としてもプロダクトとしてもまだまだ未成熟であり個人の働きがARRに直結するフェーズにあります。
中長期的な事業への貢献
新しいドメインに対する新規プロダクトや、新しい顧客セグメントを開拓する新機能の提供が本項目の代表的な成果になります。ロードマップに基づいてデリバリーできることだけでなく、高い精度の仮説検証を経て顧客課題を捉えた開発ができたかを成果として見ています。
開発したプロダクトがBS/資産として将来的にどれほどの収益をもたらすポテンシャルを作れたかも重要です（逆を言えば検証が甘く作り直されうる場合はポテンシャルは低く見積もられます）。また資産や収益に直結せずとも事業展開上のブロッカーとなる機能も存在します、その機能を作ることでどれほどの負債や損失を防げたかの観点で評価対象として扱います。
プロダクトの中長期的な成果は事業的な数値には即座に表れないことや、期末に必ずしもリリースされないため評価は難しくあります。そのため仮説検証の精度を評価上の重要な観点としています。正しく仮説検証のプロセスを経てフィードバックを集めることができているか、検証を経て改善のサイクルを回せているかが精度を考える上で見ることになります。
マネジャーに対してはプレイヤーとしての評価に加えて、チームとしての成果も求めています。メンバーをプロダクトエンジニアとしての後述の能力評価軸に基づき育成し、チームとしての成果を最大化することを求めます。またプロダクトロードマップへの提言・議論をし、事業目線でプロダクト開発を推進していることも重要です。
短期的な業績への貢献
新機能や機能改善による新規顧客の獲得が本項目の分かりやすい成果です。顧客の商談・オンボーディングのタイミングに合わせてデリバリーするハードさが求められるフェーズにあり、期限を満たして顧客を獲得できた点を評価しています。
「機能の積み上げ」という面でも評価があります。SaaS開発ではロードマップに基づく逆算による開発が理想系ですが、業務系 Vertical SaaS を開発してきた経験から考えると、顧客業務の複雑さ・深さやセグメントの不明瞭さを背景に積み上げ型の方が結果として早く事業を形作るプロダクトができるため。そのため短期的な新機能・機能改善への評価をする点もあります。
プロダクトが未成熟である故に機能が不十分でエンジニアによる運用サポートが求められる部分もあります。この行動も本項目に含まれる成果です。ただ闇雲に運用サポートをするだけでなく、対応工数が機能化工数を上回っていないか定期的に観測し、機能化を検討する思考を持てていることも１つの観点になります。
能力評価
コンピテンシー（行動特性）
良いプロダクトを作ることができるエンジニアには共通する行動特性＝コンピテンシーがあり、これを獲得できているか・成熟させることができているかを評価の対象としています。
コンピテンシーの獲得は知識やスキルの獲得と比べて、自身の行動様式を忘れるアンラーンを伴った成長が必要であり難易度が高く時間が掛かりやすいものです。そのためジュニアなメンバーに対しても、転職直後のメンバーに対しても早い段階で変容を求めるべく重要な評価観点としています。
プロダクトエンジニアが持つべきコンピテンシーに関して、「プロダクトエンジニアとは何者か」のnoteに詳細をまとめています。
プロダクトマネジメント
プロダクトエンジニアには特にプロダクトマネジメントのソリューション策定と実現の部分の役割を求めています。そのため顧客理解力・発想力・仮説検証力・実現力のスキルの成長と成熟を見ています。
顧客理解力という点では単純にドメイン知識をどれほど蓄積できて来たかという点もありますが、顧客の課題をどれほど解像度高く整理することができるかも重要としています。結果として発想力を表す良いソリューションを創ることができているかの評価観点に繋がってきます。
仮説検証力に関しては、限られたリソースで効率的に検証しプロダクトを実現できているを見ます。MVP（Minimum Viable Product）を作る上で検証のための前提条件を適切に捉え削ぎ落とすことができているかや、機能のコアバリューを捉え検証のクリティカルパスを作ることができているかが結果として表れています。また実現力に関しては技術的な部分だけでなく、効率的に機能提供への最短ルートを歩むプロジェクトマネジメント的な能力を見る部分が大きくあります。
技術力
エンジニアであるため技術的なスキルも当然として評価対象にあります。ただ事業実現のために必要とされるスキルに近いほど評価する対象になるため総合的な技術力ではないことが注意が必要であり、技術的な深さよりも広さの方を先んじて求める傾向になります。
一人で高速かつ負債少なく開発できることが、プロダクトの仮説検証の速さだけでなく検証の質を生み出します。フルスタックで一人で開発ができることや、デザインを含めたフロントエンドの開発力、ドメインを反映したDDDでの開発が特に求められる能力になります。
リードプロダクトエンジニアとなる段階になれば技術的な広さだけでなく、深さも求められるようになります。
＋ その他の評価軸
以上はプロダクトエンジニアとしての評価軸になるため、実際の評価では会社としての評価軸も含まれます。採用への貢献や、会社カルチャー形成のためのバリューの体現。組織を作る上で欠かせないリーダーやマネジャーとしてのチーム構築能力なども評価軸としてあります。
イネーブリングやプラットフォームエンジニアに向けた評価軸はプロダクトエンジニアとは異なる部分があるため、いつかドキュメントにまとめたいと思います。
最後に
今回はアセンドでプロダクトエンジニアをどういった軸で評価しているか整理しました。評価軸に基づいて日頃の動きを細かく調整することは求めておらず、純粋に良いプロダクトを作り産業変革という大きな社会インパクトのある事業を創ることにフォーカスしてもらいたいという思いが中心にはあります。今回整理した軸を元に網羅性があることや力の掛け方がバランスよく適切であるかの参照軸として活用してもらいたいと思います。
また会社のフェーズが変われば評価軸も変わるということで、アップデートがありましたら、また社外ドキュメントの形で公開していきます！
アセンドはプロダクトエンジニアもマネジャーも積極的に募集しています、ご興味を持たれた方はぜひ一度お話ししましょう！
この記事が気に入ったらサポートをしてみませんか？