プロダクトエンジニア組織を支えるイネーブルメントの役割とは

2024年8月16日 20:15

はじめに

こんにちは。プロダクトエンジニアの宮津(@kenshiro382)です。
アセンドのプロダクト組織は、現在進化の真っ最中で、組織の形を大きく変えていこうとしています。
これまで1桁だったエンジニアメンバーも拡大を計画しており、それに伴いイネーブルメントの役割の重要性が増すと考えています。
今回は、イネーブルメントの役割、そしてプロダクトエンジニア組織とイネーブルメントの高い親和性について紹介します。

プロダクトエンジニア組織におけるイネーブルメントの重要性

技術を課題と思わせない役割

まず、アセンドのプロダクト組織の核である「プロダクトエンジニア」について簡単に説明します。

プロダクトエンジニアは「チームトポロジー」でいうところのストリームアラインドチームの機能を持っています。特徴として、プロダクトエンジニア一人一人が顧客課題解決のために、フロントエンドやバックエンド、インフラといった技能領域の隔たりを厭わず、プロダクトの提供価値の仮説設定からソリューションまで一気通貫で行います。

プロダクトエンジニアが課題を解決できるプロダクト作りをするためには、技術自体を立ち向かう課題とするのではなく、課題解消のツールとして技術を扱えるようになることが望ましいです。その点においてイネーブルメントの価値は非常に高いと考えられます。自然とパフォーマンスが発揮できるような土台やレールを敷くことこそ、プロダクトエンジニア組織のイネーブルメントとして求められる大きな役割です。

アセンドにおいても、「ストリームアラインドチームの各メンバが必要なスキルを身につけるためのあらゆる支援を行う」という一般的な役割の定義とあまり変わりません。しかし、支援するストリームアラインドチームがプロダクトエンジニアということから、よく言われるイネーブルメントの領域からはみ出すような領域もあります。
例えば、プロダクトマネジメント領域です。プロダクトエンジニアは、一人一人が課題設定や要件定義、仕様設計を行うため、プロダクトマネジメントの能力が求められます。全員にプロダクトマネジメントスキルが求められる時、各自が独力でスキルを身につけるのではなく、横断的にスキル習得を支援するイネーブルメントのポジションがあれば、効率よく知識を継承できるはずです。

広く効果をもたらす親和性

プロダクトエンジニア組織こそ、イネーブルメントの役割を設置するべきだと私は考えています。その理由は圧倒的なレバレッジです。

一般的なプロダクト組織では、フロントエンド、インフラ等と職能が分かれています。そのチームでフロントエンドのイネーブルメントを実施する際には、ストリームアラインドチームのフロントエンドエンジニアのみを支援します。バックエンドエンジニア、インフラエンジニアにはあまり関係ありません。

プロダクトエンジニア組織においては、プロダクトエンジニア全員がフロントエンド、バックエンド、インフラ等すべての職能を持っているため、どのイネーブルメントも全エンジニアへ影響します。限られた領域のエンジニアだけでなく、すべてのエンジニアにイネーブルメントの効果が波及します。

アセンドにおけるイネーブルメントの動き

具体的なアセンドでの取り組み

ここまで、イネーブルメントそのものや、プロダクトエンジニア組織とイネーブルメントの相性について紹介してきました。
アセンドでは、プロダクト立ち上げ当初からプロダクトエンジニアが課題解決をしやすい環境を整える活動を行ってきました。
例えば、フロントエンド・バックエンド・インフラへ越境しやすくするFull Stack TypeScriptの取り組みや、共通的なUIコンポーネントの作成などがイネーブルメントの一例です。

私自身、アプリケーションアーキテクチャのスペシャリティを生かしてイネーブルメントの活動を行っています。例えば、

アプリケーションのパフォーマンス問題が起きた際の壁打ち相手として、フロント・バック・DB・インフラを総じた観点でアドバイスを行う。
コネクションプールの管理、デッドロック時の挙動、タイムアウトなどの設計を意識せずにトランザクションの仕組みを利用できる汎用部品の作成。これによりトランザクションの設計に頭を悩ます時間が減った。

このようにして、プロダクトエンジニアが技術課題に悩む必要がなく、課題解決のツールとして使える形に昇華させることで、顧客の課題に向き合う時間を増やすことを可能にしています。

将来のイネーブリングチームに向けて

現在、アセンドにはまだ明確なイネーブルメントチームはなく、各人がプロダクトエンジニアをしながら、スペシャリティを生かしてイネーブルメントの役割を担っています。
そんな中、私はイネーブラーがプロダクトエンジニアの課題について解像度高く知ることの必要性を痛感しています。各エンジニアが課題解決に至るほどの能力を身につけるには各レイヤの技術知見を必要とし、膨大な学習量が求められるためです。
そのため、まずは技術のスペシャリティを持った方にも、プロダクトエンジニアとしての開発サイクルに慣れ親しんでもらった上でイネーブリングチームを作り上げていきたいと考えています。

現在のイネーブルメントの課題

現在、特に求めているスペシャリティは、以下の２つです。

(Full Stack) TypeScript
プロダクト立ち上げ当初はJava経験者が多かったこともあり、Classベースで構築されてきた。型演算の旨みを活かしきれないシチュエーションも多く、もっとライトに型の力を活かしたコーディングにアップデートしていきたいと考えています。（※ 過去登壇資料参照）

UX/UI Design
今までは物流ドメインのユーザーが求める業務体験を、エンジニアが作り上げてきた側面はあるものの、「日本で最もデジタル化の遅れた物流産業で、最高の業務体験を作る」目標には及んでいません。ユーザーの想像を超えて使いやすい業務SaaSのUX/UIを、プロダクト横断で使えるようにしていきたいと考えています。

おわりに

今回は、プロダクトエンジニア組織におけるイネーブルメントの役割と親和性、そしてアセンドにおける実例と今後の課題について紹介しました。記事を通じて、プロダクトエンジニア組織でイネーブラーとして活躍する具体的なイメージとその楽しさについて感じ取っていただければ幸いです。
アセンドでは将来のイネーブルメントチームのメンバーや、プロダクトエンジニアを募集しています！ご興味持っていただけた方、ぜひカジュアル面談をお願いします！！

TypeScriptのテックリードを切実に求めています！！！！！ #tskaigi_aftertalk
— 宮津ケンシロウ | アセンド株式会社 (@kenshiro382) June 4, 2024

■ TypeScriptテックリードの求人はこちら

■ UI/UX Designerの求人はこちら

■ その他、職種問わずカジュアル面談はこちら

この記事が気に入ったらサポートをしてみませんか？