【CTO of the year記念リレー】 プロダクトエンジニアのコンピテンシーと育成
こんにちは。アセンドのプロダクトエンジニア 坂本(@motikoma) です。
先日開催された「Startup CTO of the year 2024」にてアセンドCTOの丹羽(@niwa_takeru)がオーディエンス賞を受賞しました。応援・投票していただいた皆さま、本当にありがとうございます！
この受賞をきっかけに、ピッチの中で時間の都合上深掘りできなかった部分について、リレー形式でお届けしていきます。
前回は宮沢によるFull-Stack TypeScriptの選択をお届けしました。
今日は第4弾としてプロダクトエンジニアのコンピテンシーと育成についてご紹介したいと思います。
プロダクトエンジニアのコンピテンシー
アセンドではプロダクトエンジニアに共通したコンピテンシーとして5つの特性と求めています。弊社CTO丹羽が執筆した「プロダクトエンジニアとは何者か」という記事から引用しつつ、自身が実際に体験したことなどを踏まえて解説できればと思います。
課題へのオーナーシップ
プロダクトエンジニアが最も無くしてはならないのが顧客課題解決に対するオーナーシップです。仕様策定から実装、機能検証を含めてプロダクト価値を最大化するためにあらゆることを行い、ステークホルダーを巻き込んだ推進力を持ちます。リリースは完了ではなく、継続的に顧客のサクセス状況を確認し、期待を満たさない場合は原因を分析し改善を進めます。この反復的な学習サイクルを通じてプロダクトとドメインに対して深い洞察を持つエンジニアへと成長していきます。
アセンドではビジネス面を理解するための全社的なオンボーディング期間が1ヶ月間設けられています。この期間中、Bizメンバーと一緒に商談や展示会に参加することができます。こうした活動の結果、顧客の課題に関する理解が深まり、課題解決へのモチベーションも高まると感じています。
また、新しくジョインしたメンバーには配属領域のリードエンジニアがバディとして設定され、オーナーシップを持った振る舞いを横で見ることができます。そういった取り組みもあり、他メンバーと話をしていても、リードエンジニア問わず全員が顧客の課題解決に対して情熱をもって取り組んでいるなと感じています。
越境とキャッチアップ
広く領域をカバーすることが最適な設計へ繋がることを知っているため、領域の越境を易々とするのがプロダクトエンジニアです。技術を課題解決のためのツールとも見做しています。一般的な技術軸での学習に比べて極めて実践的で目的意識を持って行われるため学習効率は高く、エンジニアとしての成長も意外にも速くあります。
アセンドのプロダクトエンジニアは要件定義、デザイン、フロントエンド、バックエンドと職域を限定せずに顧客の課題に対し一気通貫で開発を進めます。現在、エンジニアのFigma利用促進プロジェクトを推進しており、副業デザイナーの方に相談しながらモックデータを元にデザイン演習する機会が用意されています。自分も入社当初はFigmaの使い方がよくわかっていませんでしたが、デザイン演習や新規プロダクトのデザイン作成などを経験して、かなり慣れてきました。
迅速な仮説検証
優れた体験を生み出すためには数多くの失敗が必要となることをプロダクトエンジニアは知っています。プロダクトとは不確実性の塊であり、検証を経ることでしか確実さは得られません。リーン開発・MVP（Minimum Viable Product）の手法を活用して積極的に顧客へ仮説を当て、小さく開発し小さく失敗することでプロダクトの価値を積み上げます。
アセンドではプロダクトエンジニアがセールスやカスタマーサクセスと一緒に顧客にヒアリングしつつ、要件定義を担当します。私自身も現在新規事業担当しており、顧客がプロダクトにお金を払っても良いと思えるにはどういった機能が必要かといった観点を持ちつつ、初期リリースに向けて整理している最中です。前項目でも記載したようにプロダクトエンジニアがFigmaによるUIモックを作成できるようになったおかげで仮説検証のスピードが明らかに速くなりました。また、UIモックで初期仮説を検証した後は、実際のプロダクトをリリースして仮説検証を行うことになります。そのための土台としてFull-Stack TypeScriptやChat Opsが開発速度に寄与していると感じています。
アンラーンとコミュニケーション
自身の成果ではなく、顧客課題の解決に対して忠実であることも特徴です。優れた仮説を立てるために健全な対立的な議論をする一方で、自身が立てた仮説が誤りであることを素直に認め、課題解決を第一とした素直なコミュニケーションをとります。自身の誤った学びを正しく捨てるアンラーンに対しても積極的です。多様な観点が最良なプロダクトを創ると知っているため、ステークホルダーに対しても積極的に仲良く会話し関係を構築しています。
ドメイン知識が少ない状況では初期仮説が間違っている可能性が高いです。UIモックを用いた顧客へのヒアリングを通して徐々にドメイン知識を増えていく過程で、初期仮説にこだわらずアンラーンすることが重要です。当然ながらある程度の拡張性を踏まえて設計・開発を進めますが、プロダクトを実際にリリースした後もさまざまな顧客に利用いただく過程で現状の設計では吸収しきれない要件が出てくることもあります。顧客から選ばれるためには痛みは伴いますがコストを払って再設計のために時間を取ることが重要です。その際には社内メンバーに対して説明責任を果たす必要があると考えています。
アセンド最大のアンラーン事例として3度にも及んだデータモデルの刷新が挙げられるかなと思います。当時私は在籍していませんでしたが、大変さがひしひしと伝わってきます。しかし、これをやり切る力こそが開発組織の底力であり、競合優位性となりうるなと感じています。
ドメインに対する好奇心
プロダクトエンジニアは技術だけでなく顧客ドメインやビジネスに対しても高い好奇心を持ってプロダクト開発を楽しみます。プロダクトのアイデアは思いつきではなく、顧客課題の解決・ゴールから逆算されるものと認識しているため、ゴールを何と設定すべきか高い解像度を持って理解するために時間をかけます。またドメインに対する情報を事実と仮説に切り分け、エンジニアならではの科学的なアプローチで理解を深めることも特徴です。
プロダクトエンジニアは技術に対する研鑽は当然として、それを顧客の課題解決のために使うことに情熱を持っている人が多いと感じています。そのためにはドメインに対いてディープダイブする必要性があり、社内のメンバーは誰から言われるまでもなく自然とできていると思います。私も入社後に物流に関する書籍や運行管理者に関する書籍を読んだり、展示会やカスタマーサクセスの顧客訪問に同席したりと楽しくディープダイブできています。運送会社が法律上求められることや経営観点でどのように情報を管理したいかといったドメイン知識を蓄積していく過程で、自身が担当している新規プロダクトがどんな課題を解決するのかといった点について未来を語れるようになりつつあります。
結びに
アセンドがプロダクトエンジニアに求めるコンピテンシーとして5つの特性を紹介してきました。このように言語化されることでプロダクトエンジニアとして望ましい振る舞いが意識できるので働きやすいなと感じています。コンピテンシーに共感していただける方は、ぜひアセンドで一緒にプロダクトエンジニアとして成長していきましょう！
ここまで読んでいただき、ありがとうございました。