「プロダクトエンジニア」の、次。 リードという役割を考える
こんにちは。「物流の真価を開き、あらゆる産業を支える」というミッションのもと、物流業界向けにオールインワン運行管理SaaSを開発しているアセンド株式会社 リードプロダクトエンジニアの @moeka__c です。
以前インタビューしていただいた記事がありますので、どんなやつかはこちらから。
私がアセンドにプロダクトエンジニアとして入社して、早くも2年と少しが経ちました。当時4人目エンジニアとして入社したわけですが、それから3名の新規メンバーを迎え、現在は7名体制。私も社内のグレードで5段ほど昇格し、「プロダクトエンジニア」の上に「リード」という冠がつく立場になりました。
リードプロダクトエンジニアという役職は、プロダクトエンジニア組織を掲げるアセンドが独自に作ったポジションです。一般的に良く使われるテックリードやリードエンジニア、EMといったポジションとは少し違う期待値を込めて、あえてこの呼び方が採用されています。
日々、リードプロダクトエンジニアとはなにか、目の前の開発への関わり方をどう変えていけばいいのかという命題に、CTOの丹羽さんや同じリードプロダクトエンジニアの宮津さんと想いをぶつけ合ったり、試行錯誤しながら向き合っている最中ですが、リードになって約半年が経とうとしている今、改めて現時点での自分自身の整理を言語化してみようと思います。
まだまだ自分自身も道半ばで、ここで挙げていることがすべて出来ているわけでは当然ありませんが、自分自身の目標、そしてリードというポジションにどう向き合っていきたいかという志を表明する意味での整理になっています。同じような悩みを持っている方だけでなく、リードが何を考えながら仕事をしているのか知りたいなと思っているすべての方々に、広く参考になれば幸いです。
前提：「プロダクトエンジニア」とは
プロダクトエンジニアという言葉の火付け役はおそらく、弊社CTOのこの記事でしょう。プロダクトエンジニアは「プロダクトの成長を軸にオーナーシップを持って追求、越境していくエンジニア」であると謳われています。
少し補足をすると、アセンドでプロダクトエンジニアというときには、大前提として以下の２つの意味を含んでいます。
フルスタックであること。
つまり、1つの機能を分業せず独力で作り上げる技術スキルがあること。フルサイクルであること。
つまり、1つの機能の企画・仕様策定から開発、QA、リリース、その後のサポートや改善要望のウォッチ・対応まで、ソフトウェア開発のすべてのフェーズに一貫して関わっていること。
エンジニアが1人格でフルスタックかつフルサイクルに開発を行う。つまり「作る人」が情報と権限を握り、よりドラスティックな判断が素早く適切に行える体制を作る。これこそが、プロダクト志向なエンジニアのポテンシャルを最大限活かし、圧倒的に高い開発生産性で価値あるプロダクト作り続けられる原動力になっています。
リードプロダクトエンジニアの3つの役割
圧倒的に高い開発生産性で価値あるプロダクト作り続ける。これがプロダクトエンジニアの役割なのであれば、リードプロダクトエンジニアはそれをリードするという役割を担っていることになります。
すでにプロダクト志向を兼ね備えた素晴らしいエンジニア達を、事業にアライメントさせながら望ましい成果を上げていけるようにリードする。それには、自分個人の成長をこえた、チーム、組織、そして事業という高い目線と影響力が必要です。
私は大きく3つの軸で役割を整理しています。
技術( =プロダクト開発)
ハイスキルプレイヤーとして難易度の高い課題を上手く解決させるとともに、開発生産性が高い状態の維持にコミットすること事業
PjM、PdMとして事業上の課題を認知し、適切に人を巻き込みあらゆる手段を用いて事業上の目標、ミッションを達成すること組織
EMとしてメンバーにプロダクトエンジニアのマインドと文化を根付かせ、次のリードを育てると共に、視座が高くミッションドリブンな開発組織を作ること
『技術( =プロダクト開発)』をリードする
リードプロダクトエンジニアは、新規ドメイン領域の0→1立ち上げ、複数ドメイン領域にまたがる知見と視野が必要な機能開発の推進、すでにPMFしたコア体験にインパクトがあり慎重な意思決定が必要な要望への対応のような、不確実性が高く高難易度な課題を担当することが多くあります。
これらを安定的に、適切に解決することがリードに求められる役割ですが、ただ担当するだけであれば、当然メンバーにもチャンスは巡ってきます。目の前の課題を確実に解決していくことは、リードかどうかに関わらず全員が一丸となって取り組んでいくものです。一方で、リードとしての責任は、課題の表面上の難易度に関わらずプロダクト品質に対する意識を周囲より二・三段高く持ち続けることだと私は捉えています。
SaaS事業の成長にとって、プロダクト品質が最重要課題の1つであることに疑いの余地はありません。特に内部品質は、経営レイヤーで行われる投資判断の判断材料となる「開発コスト」の予測可能性に大きな影響を与えます。予測が上振れるとビジネスチャンスを逃し、下振れると炎上リスクに直結します。
コードの品質はビジネスに影響を与える。そしてコードの品質を維持できるのは、BizでもPdMでも、ましてやCTOでもありません。どうあがいても現場の第一線で手を動かすエンジニアしかいないのです。
そしてこの重い責任を果たすにはディープなドメインダイブの経験と、強いオーナーシップに基づいた中長期的な意思・決断力という、一朝一夕にはいかない能力が必要であるはずです。
※ ドメインへのダイブが設計・開発フェーズにどう影響するのかは過去こちらの記事にまとめています。
目に見える成果と同じくらい、将来の開発生産性の維持にコミットする。これが、リードに求められる1つ目の役割です。
『事業』をリードする
リードプロダクトエンジニアには、課題に対するソリューション考案・構築を超え、「事業上の目標・目的」をゴールに人を巻き込みとにかくプロジェクトを前に進める力が求められます。PjM、PdMの知見や視座が必要な分野で、「フルサイクル」をより上手く回す能力とも言えるでしょう。
事業目標達成に向けて、チームが行くべき方向を決断し、周りを走らせ、何よりも自分が爆走することになるのですが、リードするにあたっては、何よりもまずBizを含めた周囲からの信頼を得る必要があります。エンジニアとして「プロダクトを作る」ことを通して事業をリードしていく、それに足る人物として周囲から信頼されるためには、まず第一に圧倒的な開発素手力、第二に正しく深いドメイン知識に基づいたソリューション考案力、そして仮説検証をベースとしたスピードと質の両立、この3点が特に重要ですし、磨き続けるべきスキルであることは間違いありません。
そのうえで、さらにリードとして周囲を導くためには、下記のようなハードルをクリアしていく必要があります。
どの方向に進むかの判断精度を上げること。そのために事業やプロダクトのAsIsとToBeの解像度を高く保つこと。
自分の専門領域外の人のパフォーマンスを上手く引き出せるようになること。掛け算による組織力を発揮すること。
とにかくスピード感を持って物事を前へ進める気概と気合いを持つこと。それを維持する自己マネジメント手法を確立すること。
プロダクトエンジニアの議論にもあったように、技術の平易化が進んだことで「作る」役割を持つエンジニアがここまで越境できるようになりました。これが、リードに求められる2つ目の役割です。
『組織』をリードする
組織開発にも色々ありますが、リードプロダクトエンジニアには明確にプロダクトエンジニアを増やし、次のリードを育成するという役割があります。目標は、「良いプロダクトを素早く提供する」ことの再現性を作ること、そのために視座高くミッションドリブンに動けるメンバーが自然発生する文化を作っていくことです。
リードプロダクトエンジニアは、EMの役割の一部を担い、実際の業務を通した1on1のピープルマネジメントによるメンバーの育成をしていくことになります。
EM自体の基本に関してはO'Reillyから「エンジニアリングマネージャーのしごと」という素晴らしい書籍が出おりますのでそちらに譲るとして、私が育成という観点でメンバーと関わっていくにあたって重視している3点に関して言及しておこうと思います。
■ 良いアサインをする
やはり、真に人を育てるのは意義と難易度のある仕事の経験です。
しかし、意義と難易度のある仕事なんて簡単には落ちていません。当たり前です。目標達成までの道のりを分解して「仕事」の単位にし、それに意義を付与するのはマネジメントの仕事だからです。難易度も絶対値ではありません。ある人にとっては簡単でも、ある人にとっては全く新しい経験で難しい。達成すべきことを見据え、道筋を描き、仕事に意義を付与し、アサインして意味のある人に渡す。そうしていくために必要な視座と視野と権限を自ら獲得する。マネージャーとしての格が試される仕事だと思っています。
■ 良い権限委譲をする
権限を渡す。個人的には、責任を渡す、と捉えたほうがしっくりきます。つまり、あなたにどこまで責任を持ってもらいたいかを設計し明示する行為が先にあり、その責任を果たすために動きやすい権限のレベルがどこにあるかをお互いで話し合う、という順番です。育成という観点では、責任設計はメンバーをストレッチゾーンに置き続けるために行います。人の状態を見極める力と、メンバーとの信頼関係が試される仕事だと思っています。
■ 良いフィードバックをする
フィードバックは最も難易度が高いと同時に、メンバーの成長幅を決定づける重要な仕事であると、私はアセンドで実感しました。フィードバックの意義は、メンバーが自らの行動をメタ認知して「外からは一体どう見えているのか」の自覚を促すと同時に、視座と期待値の引き上げを行う点にあります。メンバーは日々、次々に来る開発要望や迫りくる期日に追われながら開発に励んでいます。足元のタスクに全力で取り組んでいると、「足元のタスクに全力で取り組んでいる自分」でつい満足してしまうものです（私もそうです）。そんなメンバーに、足元のタスクで満足するな、もっと先にはこんな面白い課題が待っていて、それに立ち向かうにはもっとこうなっておく必要があるぞ、と上を向かせる。そんなフィードバックができるように、自らこそ常に上を向き、自分なりの強みと自信を持っておくことが求められる仕事だと思っています。
おわりに
本記事では、リードプロダクトエンジニアに求められる役割を「技術」「事業」「組織」の3軸で整理し、それぞれの向き合い方について現時点の考えを述べました。テックリードやEMとも少し違う、プロダクトエンジニアのリードならではの幅の広さや観点をお伝えできていれば幸いです。
冒頭で書いた通り、これは私の目標、そして志であり、まだまだ道半ばです。アセンドは、共にリードプロダクトエンジニアというキャリアを作ってくれる方を募集しています。
少しでも共感して頂ける方、逆にもっとこうなんじゃない？と思う方、よくわからないけど興味はあるという方、ぜひカジュアルにお話しましょう！
この記事が気に入ったらサポートをしてみませんか？