プロダクトエンジニアの役割
の時間がやってまいりました。 本日は、プロダクトエンジニアについてのお話となります。
夢見では、9月の1日に職位ガイドラインを 大きく変更しました。特にですね、
アプリケーションエンジニア職位ガイドラインという 名称だったのが、プロダクトエンジニア職位ガイドライン
という名称に変わりました。 3名称が変わっただけというよりは、
そもそもの夢見におけるエンジニアの 位置づけ定義というのが、本本的に変わりました。
具体的には、夢見で言うエンジニアといえば、 プロダクトエンジニアの施設という形で、
そういうぐらいですね、位置づけが 大きく変わったんですけれども、
じゃあ、プロダクトエンジニアとは何ぞや という話で、具体的に説明をしたいと思います。
プロダクトエンジニアの定義と役割というのを、 ノーションのボックスにもお伝えしていますし、
内容のほう、画面でも表示できるように しているんですけれども、
まず、プロダクトエンジニアの 夢見というのを定義に関しては、
特定領域の技術力と周辺領域への 影響力、その2つをもってプロダクトの成長を達成する。
越境するスキルセット
プロダクトの成長の目的に技術力と 影響力で目標を目指す。
というところが大きな特徴です。
なので、目標とか目的がプロダクトの 成長であることというところと、
影響力というのが技術力に加わる新たな 力ですよというところが、
大きなこれまでとも違いですね。
影響力の定義なんですけれども、 影響力とは、これまでだとアプリケーションエンジニア、
WebOpsエンジニアの主な担当領域である、 設計や開発や運用といった領域の周辺、
隣接領域へ役割を拡張することができる力。
隣接領域へ役割を拡張することができる力が 影響力というふうに定義しています。
飛び越えという感じですね。境界を飛び越える。
じゃあその境目を飛び越える中で、 隣の隣接、周辺領域というところがありまして、
大きく6つあります。
1つ目がビジネスドメイン理解ですね。
ビジネス、特に顧客のビジネス、 ビジネスモデル、
ドメインですね、業界、業務、 知識というところを理解していく。
まるでドメインエキスパートみたいな 役割ですよね。
ドメインエキスパートにはもちろんならないけれども、 そこにはみ出していくんですね。
そういった協力を発揮する。
2つ目が顧客ユーザ体験設計。
これある意味サービスデザイナーみたいな役割ですね。
サービスデザイナーにはもちろんならないけれども、 はみ出していく。
3つ目がUIデザイナー。
UIデザイナーの本部ですよね。
4つ目がアーキテクチャー設計。
これもアーキテクト。
5つ目がデータ分析。
データ分析ですよね。
6つ目がプロジェクトリード。
プロジェクトリードエンジニアリーダーですね。
そういった形で設計とか開発とか、 特に開発ですけども、
運用というデブロックしてるエンジニアの 中核となる領域っていうところを、
もちろん守備班として推行責任を負いながらも、
ドメインオフィスパートやサービスデザイナーや、
UIデザイナーやアーキテクトやデータアナリストや、
プロジェクトリーダー。
そこまではみ出していく。
何のために?
その成長のために。
それは何でそれが必要なの?っていうところ。
その前に、
影響力あるいは影響性っていうところについては 補足なんですけれども、
フルスタックエンジニアなんですか?
フルサイクルエンジニアですか?っていうところの 疑問があったんですけれども、
そうではない。
フルスタックではなくて、
特定の技術スタックに専念する。
っていうのでもいい耳ですよ。
いい耳においてはOKですよ。
したがって、フロントエンドっていう領域に 特化をする。
専門性を、技術力を持って身につける。
けれども、もう一方の技術力に加えた 影響力ですね。
影響力っていうところでいうと、
先ほどの、特にフロントエンドだと、
UIデザインとかにはみ出していくことって 重要じゃないですか。
デザイナーとの連携性、重要ですよね。
デザインを実際に見てみて、
動きを特に触ってみて、やっぱ違うな、 みたいな形で。
デザインとフロントエンドの エンジニアリング実装っていうのを
行ったり来たりするのがどんどん 重要になってきますよね。
そうすると、私、僕、
デザイナーじゃないんで、 みたいなことを言ってられない。
そういう事情も多くなってくる。
そうすると、フロントエンドの エンジニアもUIデザインの動きに
はみ出していかないといけない、 影響していかないといけない
わけなんですよね。
なので、フロントエンドプロダクト エンジニアっていうのは、
影響力を発揮して、例えばUIデザイン はみ出していくっていう意味では
整理するんですよね。
ただし、フロントエンドのエンジニアの人が、
ラックエンドのインストラも インスケアしないといけないかというと、
そうではない。
ですね。
なので、iOSプロダクトエンジニアとか、 アンドロイドプロダクトエンジニアとか、
サーバーサイドプロダクトエンジニアとか、
いう形で特定の技術スタックを 専門性の軸としながらも
影響力を発揮していくという形で、
いわゆるフルスタックエンジニアとは 違うわけなんですよね。
一方、フルサイクルエンジニア、 フルサイクルっていうのは、
工程のすべて、規格から分析までを 一貫して主担当するエンジニア、
フルサイクルと定義した場合に、
これのすべてを担当するわけですね。
主担当で担当するわけじゃないんですね。
ある意味、ドメインエキスパートとして、
ドメインエキスパートとして、 ドメインを理解して、
サービスデザイナーとしてサービス企画をし、
サービスデザイナーとしてUIを設計して、 アーキテクチャを設計し、
そして実装して、デプロイして、 データを分析してっていう形で、
フルサイクルの工程を、
臨接領域は持っているんですけれども、 主担当ではないんですよね。
フルサイクルエンジニアって、 主担当者として、
すべての工程を自分で実施するわけなので、
あくまで影響力という形で、
それぞれの領域に、 企画であったり、分析であったり、
UIの設計であったり、
はみ出して、それぞれの専門家がいるので、 それぞれの臨接の専門家、
周辺にいる専門家の人と、
重なりを持っていくっていうところはあるものの、
主担当としてすべての工程を 担当するわけじゃないので、
もちろんフルサイクルとも違うという形になります。
越境の領域として、いくつか書いたんです。
6つほど書いたんですけれども、
特にプロダクトエンジニアならではの 越境の対象というのがあって、
それが1から3番目。
具体的にはドメイン理解であったり、 UIデザインであったり、
親子体験設計、ユーザー体験設計というところが、
これまでのアプリケーションエンジニアとも、 ちょっと違いかなと思ってますね。
これまでのアプリケーションエンジニアも、
例えばアーキテクチャの設計であったり、
データ分析であったり、プロジェクトリードに、
越境していくっていうのはあったと思うんですよね。
ただ、ドメインエキスパートや、
サービスデザイナー、UIデザイナーの領域まで 踏み出していくっていうのはちょっと遠い。
ただ私ではないっていう、 エンジニアではないっていう形で、
線を引いてた可能性があるけれども、
より連携していくっていう意味で、
越境力が期待されますよっていうのは、 ちょっとポイントとして違う点ですね。
プロダクト思考の重要性
MIMIならではの越境領域っていうのは、 実は7つ目の領域として加えていて、
MIMIも会社はプロダクト、 会社というのはプロダクトとして規定してますので、
プロダクトエンジニアとしても、 プロダクトの成長を目的にして、
越境していくことで、 組織のプロセスマネジメントですね。
そこに越境していくっていうのが、 他社との違いになっています。
具体的にはマーチャリングであったり、 採用であったり、委員会活動と呼ばれる、
組織運営の取り組みに越境していきますし、 実際に越境すでにしています。
ここではあえて、組織のプロセスマネジメントに 越境していきましょうっていうのは、
強く期待する状況をするわけではなく、 MIMIの場合は組織にも越境してますよね、
っていうのが1つ目になります。
ただこの組織への越境っていうのは、 実は顧客とのプロダクトチームにおける
プロセスマネジメントの改善にも役立つことが、 結果としてプロダクトの成長に、
特に中期的な成長に役立つ部分とか、 組織のプロセスが光と構築されていないので、
ボトルデックになる場合もあるので、 こういったものは付加価値になるのかな、
というところですが、必ずしもプロダクトによっては 関与が難しい場合もあるので、
関係において必須ということではないので、 MIMIの場合という形での集めの組織、
プロセスマネジメントというのを 対象としているということになります。
そもそもなぜこのプロダクトエンジニアとしての定義を 改めて規定したのかという形で背景があるんですけれども、
関係には4つあります。
何かというと、1つ目が分業の弊害ですね。
規模が大きいプロジェクトとか、 企業が大きくなると分業化が進む中で、
どうしてもプロダクト思考が失われる 弊害があることを持っています。
特にMIMIの採用の予定でも、チェック思考が 強い人を採用するというので、
プロダクト思考というのが、 顧客への提供価値によって
重要になる中で、そこでどうしても 弊害が生まれる可能性がある。
これらが以前からあった話ではあるので、 急にこういうことが起きたわけではないですけれども、
背景の1つにはあります。
2つ目が、DMCの重要性が分業化に対して高まっている。
プロダクトの規模複雑性がどんどん高まる中で、 どこまで行っても最後は、
PDMの意思決定に委ねる中で、 PDMに責任が集中するというのはあるべき、
仕方がない部分なんですけれども、 そういったPDM対変問題というところを解決するために、
さまざまな分業がこれまでも起きてきた。
PEO、EDMの二等体制、分業もそうですし、 ペーチャーチームでチームを分割する。
ただ、最後の最後までどこまで行っても PDMが意思決定するという中で、
PDMをどう支援するかという中で、 エンジニアがプロダクト志向として、
PEO、EDMを支援するというアプローチが 今回の背景になっていますね。
細かな仕様に関しては、むしろエンジニアに お任せみたいな形で、
微細かな仕様に関しては、ドメイン理解とか、
ある意味プロダクトの哲学とかも含めて、 しっかり理解して、
UIエンジニア、デザイナーと連携して、
やってくると、めちゃくちゃ PDM感するとありがたいですよね。
細部にエンジニアを宿す必要があるけれども、 それを任せられるというのはすごいありがたい。
このPDM支援というところの重要性が 業界で高まる中で、
プロダクトエンジニア、 エンジニアのプロダクトエンジニアの
位置づけになっていく必要がありますね。
というのが理由の二つ目ですね。
理由の三つ目が、イメミの顧客からの問題。
内製化支援を進める中で、 よりプロダクト主化が求められてきます。
具体的に、プロダクトの取引が かなり増えているんですけれども、
中にプロダクトが命だと。
ビジネスの成功要因、 製品を分けるポイントが、
プロダクトの提供価値、 プロダクトの成長というところになる場合に、
本当にプロダクトからは全てになるので、 プロダクトに向き合ってほしい。
という顧客からのニーズが大きいわけだ。
どんどんどんどん、 このニーズが高まってますね。
それに答えを聞かないといけない。
けれども、テック志向ということが、 軸になるので、
一興性というところがまとめられている。
これは直近、この1年とか数年の中で、 どんどんニーズが高まっているので、
これに対応しないといけないのではないか。
ただ、これもこの数年の中で、 起きている変化ではあるので、
プロダクトエンジニアの重要性
急激な変化ではないんですね。
一番なぜ、このタイミングでプロダクトエンジニア、 プロダクトの成長目的に
力を発揮してはみ出していこうというふうになったか、 というトリガーですね。
きっかけというのがありますと。
それが、はい、そうです。 既成AIの影響ですね。
はい、そうです。
この収録をしている9月23日、 オープンAIのオーワンも発表されて、
既成AIの変化、進化が非常に大きく なっていくだろうという中で、
いよいよ既成AIによって、実装者、 いわゆるハウですね。
どのようにフォードカップかというところの 専門性が高かった人が、
いや、それももちろん重要だけれども、 より重要なものが、
仕様を決めていく。
ワットのことですね。
何を作っていくか。
これを決める役割を担う。
そういった位置づけがどんどん、 ますますエンジニアに期待されていると。
逆に、それができないという意味では、 もしかしたら価値が下がっていくかもしれない。
というのは、今後数年間、もしかすると1年、 2年の中で急激に変化が訪れるかもしれない。
というですね、予測するしかないんですけれども、 そういうシナリオがあるというところで、
そこに対して、 対応していかなきゃいけないというところで、
仕様を決めていくには、もちろん顧客体験とか、 ビジネス力やドメイン依頼が必要なので、
その一挙のセーフというのが、 重要になってくるわけなんですね。
そういうことです。
仕様を決める。
良い仕様、プロダクトの成長、 成功にとって良い仕様を作れる。
ファットを定義できる。
そういうエンジニアが必要になってくる というところが、トリガーですね。
トリガーですよね。
こういった、ある意味、機関を前提にして、
君々のエンジニアは、プロダクトエンジニア じゃないとダメだよというですね、
ゲームを持たれて、みんな職員さんになったという形で、
アプリケーションエンジニア職員 ライブラリーの名称が変わりました。
これに伴って言うと、新卒の求人の、 採用のポジションの名称も変わりました。
今までは26卒、エンジニア採用という形で 募集していたんですけれども、
これが26卒、プロダクトエンジニア採用 という形で募集が変わったんですよね。
これもですね、今言ってペック仕様の人が 当たるんじゃなかったのという中で、
もちろん専門性の、技術的な専門性というところを 軸とした上で、
技術力と影響力の必要性
技術力はあった上で、影響力も重要なんですよ という形で、あるべき姿を目指す。
まだ現時点で、いやもう影響力、あれあれ、 すごいですよという形で必ずしもですね、
言えるわけではないけれども、 先んじて早めにですね、
目指そうという形で明確化したというのが ポイントですよね。
ただ、改めて説明したいのが、
低領域の技術指向が高い人を これまで採用してきた中で、
これからの技術力いらないよ、 というわけではないんですね。
特定の技術力に関して、やっぱり強みを 大切にすることは変わらないと。
これ、生成案によって生成される行動、 もう100%品質が補充できるわけではなくて、
最後、人間がアクセプトしていく、 人間が手を加えていくという、
ラスト5%というのはやっぱり 人間がやるべきという部分が残るので、
その向き合い目的ができるという意味では、
特定の領域の技術の専門性の高さって やっぱり必要ではあるので、
そこは変わらないと。
それがあった上で、 使用の策定という前工程にはみ出しているし、
その前工程に関わりながらいいプロダクトを 作るための使用策定をしていくには、
ビジネス理解、ドメイン理解、 UIデザインなどの影響をしていくというのが
重要になっていくということなんですね。
そういった部分で、 テック思考を止めたのっていうことでも、
影響力はさらに加わっていくんですよ、 というところになっていくというところなんですね。
この辺りに関して、 少し解像度高く定義したのが、
職位ガイドラインの中のリード職位。
リード職位の職位に対して求められる リーダーシップのあり方を、
実際に定義している図の中で説明できています。
リード指向性ベインズ、 ちょっと言葉がややこしいんですけれども、
リード指向性を表すベインズというのを 用意していて、
大きくはプロジェクトリード指向、 それからプロダクトリード指向、
テックリード指向というのがあって、 この3つの円が重なるベインズを
用意しているんですけれども、 これちょっと画面見てもらうと
かなり難しいんですけれども、 画面見てもらうと分かるんですけれども、
いわゆるテックリード指向ですね。
技術をリードしていこうという 指向性が何かしらあるところの
領域が意味の採用の範囲です。
逆に言うと、いくらプロダクト指向が高い、 プロジェクトリード指向が高くても、
テックリード指向との重なりがない、 テックに関して関心や興味がない、
専門性の関係に関心がないと判断される人に関しては、
作業の対象外にしているというところが ポイントなので、あくまでテックリード指向
というのは変わらないんですね。
ただ、過去の世代の変化によって、 本当にテックリード触ですね。
テックリード指向の牙に似たような テックリード触という人というのは、
結構レアな触手になるんじゃないかな というふうに思っています。
なので、すべてがすべてですね。
テックリード指向一本ですというよりは、 テックリード指向を持ちながらも
プロダクトリード指向を持つ。
テックリード指向を持ちながらも プロダクトリード指向を持つ。
どちらかというと、重なり。
テックリード指向と他の指向性の 重なりのところというのが、
大部分の人の立ち位置になっていくのかな というところで、
より解像高く耳のリーダーシップのあり方 というところで指定している感じですね。
もちろん、全部の指向性を持っています という人は素晴らしいですし、
このベンズでも書いてあるんですけども、 すべての指向性をバランスよく持つべき
触手というのはアーキテクトですよね というふうに指定したりもしています。
この辺りですね、かなり細かく 規定をしているんですけども、
ポイントとしてはテック指向を やめるわけではないですよと。
むしろ、技術力とか技術の専門性というのに 興味があるテック指向なので、
影響力というものもある意味一つの 技術力というふうにみなして、
影響力も技術力だと。
なのでテック指向の私たち、我々にとっては そういう影響力もどんどんやっていこうと。
そもそもドメイン理解であったりとか、 まずはドメインモデリングもそうですし、
UIも最近UIエンジニアがいるというふうに 言われたりしますし、
海外とかのUIデザイナーの 求人とか見てみると、
UIエンジニアというふうに募集していて、 コンピュータサイエンスの学技を求めたりとかしていて、
エンジニアも近いところに なってきたんですよね。
顧客体験設計とかユーザー体験設計とか、 ドメインモデリングであったり、
UIエンジニアリングもむしろエンジニアリングですと、 技術力ですという形で捉えてみて、
興味を持ってみたりしていくのが結構ポイント なんじゃないかなというふうには思っています。
こういった形での影響性、 影響というのが非常に重要になり、
おそらくこの影響で意味の育成とか研修とか、 こういったやり方も少し変わっていくんだろうなと、
あえて研修プログラムを用意して しっかり研修を行っていくとすれば、
研修と育成の変化
この影響する隣接領域ですね、
ドメイン理解、ビジネス理解、 UIデザイン、ユーザー体験設計、顧客体験設計、
そういったドメインエキスパートやビジネスデブであったり、 サービスデザイナーやUIデザイナーが持っている、
専門的な知識とか経験とかフレームワークとか、
そういったものを実はエンジニアの人に 研修していく必要もこれからあるんじゃないかなというところで、
新卒や中途の研修のやり方も 変わっていくんじゃないかなというふうに思っています。
こういう形で、いよいよエンジニアといえば、 プロジェクトエンジニアを指すということで、
プロジェクトエンジニアの定義、 区割期待について記述したプロジェクトエンジニア
区割期待についての説明でした。
