「いいや、限界だっ、買うね！！！」と心に決めてブラックフライデーに臨んだら欲しかったモニターが売り切れていました。悲しかったです。*1
最近、地元のスクラムコミュニティに参加した際に改めてスクラムガイドを読む機会がありました。
スクラムガイドには「プロダクト」という言葉の定義が書いてあり、その定義を基にすると「プロダクトエンジニアってこういうことなのかもな、普段使いしている「プロダクト」という言葉の解像度が上がって面白いな〜」と気づくことが多々ありました。
なので、今回はその話を書いていってみたいと思います。
プロダクトエンジニアというロールの面白さが少しでも伝わると嬉しいです。
そもそもプロダクトエンジニアとは？
やはり株式会社アセンドさんの記事が有名でわかりやすい記事だと思います。いい記事ですよね。
僕は「プロダクトに対してコミットメントやオーナシップを持ち、価値提供や課題解決を推進するエンジニア」の様なイメージを持っています。また、その課題解決を推進するために技術的な専門性やドメインへの探究力、ビジネスへの関心などのコンピテンシーが求められると思います。
こうしたスタンスでソフトウェア開発をしていると、自分の作ったものの価値や意味を感じられてとても楽しいなぁと思ったり、逆になかなか難しいし大変だなぁと思ったりもしています。
その上で、この「プロダクトエンジニア」という文脈で登場する「プロダクト」は無意識的に「ソフトウェア」あるいは「提供する Web サービス」のことを指していることが多いような気がします。
もちろんこれは偏見混じりかもしれませんが、エンジニアとして直接開発するもの自体もソフトウェアであることが多いと思いますし、直感的には大きい違和感はないかなと思います。
（当たり前すぎてそんな冗長に定義づけをすることがない、ということなのかもしれません）
スクラムガイドにおけるプロダクトとは？
一方で、スクラムガイドを読んでみると、プロダクトとは以下の様に定義されています。
プロダクトとは価値を提供する⼿段である。
プロダクトは、明確な境界、既知のステーク ホルダー、明確に定義されたユーザーや顧客を持っている。
プロダクトは、サービスや物理的な製品である場合もあれば、より抽象的なものの場合もある。スクラムガイド2020 より引用
(https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf)
「プロダクトとは価値を提供する手段であり、より抽象的なものの場合もある」とあり、特にソフトウェアなどに限ったものではないものとして定義されています。
つまり、顧客やサービスに対する価値提供のための手段をプロダクトと呼び、その実態が何であるかは問わない様です。
ちなみにスクラム自体も「複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワーク」とされており、特段ソフトウェア開発に絞ったものとは書かれていません。
この辺りの懐の深さと分野問わずに応用の効く学習サイクルが形式化されているところが個人的にはスクラムの好きなところだったりもします。
ソフトウェアとオペレーションがセットで１つのプロダクト
そんなこんなで久しぶりに先の記述を読んでいると「あ〜、言われてみると普段の開発ってソフトウェアに限らないかもしれない」と自分の中で気づきが生まれました。
弊社でも Park Direct という Vertical SaaS を展開し、 Web アプリケーションを開発しています。 しかし、Park Direct の本質的な価値はビジネスサイドのオペレーションとセットでの収益構造の改善や可処分時間の創出です。
こうして考えるとソフトウェアとオペレーションを合わせて１つの Park Direct というプロダクトであり、セットで価値を提供していると考えることができます。
なので、自然と普段の開発で求められる知識や判断基準はソフトウェアの仕様に限らず、オペレーション側の実運用や業務・業界レベルのドメイン知識を基にしたものになっていきます。
プロダクトエンジニアのコンピテンシーとして求められる「ドメインへの探究力」や「越境」みたいなことは、こうした点から産まれるのでは？と思いました。
エンジニアとして「プロダクト」と向き合う面白さ
そうした目線で普段の取り組みをふりかえると、プロダクトエンジニアの扱う領域の広さや難しさ、面白さも見えてきました。
例えば、直近 PdM の阿部さんと開発に取り組んでいる「分析レポート機能」を作る際、本当にビジネスサイドの人達が営業に使えるのか、機能をリリースした時の社内外にどういうインパクトがあるのかということを常に考えて開発を進めています。
詳しくはリンク先の記事に任せるとして、僕もデモやヒアリングなどに帯同し、課題や解決法等に対して解像度を上げる取り組みをしています。
また日頃から社内の Slack のやりとりを眺めたり、チャンスがあれば営業の方々の現地作業にも参加し、ドメインや課題のキャッチアップに務めるようにしています。
そうしてドメインや課題に対する解像度を上げた状態で行う納得感のある開発・リリースは、自分が作ったものが本当に価値がある、意味を成しているという実感にも繋がっています。
こうした価値提供の実感が得られることが「プロダクトエンジニア」として開発に取り組むことの醍醐味なのかもしれない、と今回改めて思いました。
また、一方で難しさも感じ、何かの機能に関して意思決定する時に常に「定量で考えた時、これはどの KPI にヒットするのか」「あるいは定性で考えた時にどれだけのインパクトがあるのか」という判断が常に求められます。
これはエンジニアとしてドメイン知識や技術面での専門性とは全く別軸の知識・判断基準が求められるので、一筋では身にいかない能力だな~と感じています。
（僕も PdM の阿部さんやビジネスサイドの人に都度相談しながら、考えるように努めています）
まとめ
少し取り留めのない記事だったかもしれませんが、いかがだったでしょうか。
広い意味でプロダクトという言葉を捉えてみると「何故、プロダクトエンジニアはドメインやビジネスに対する興味関心などのコンピテンシーが求められるのか」「何故、それがエンジニアとしての面白さに繋がるのか」ということが見えてくるかな？と思います。
価値提供と成長実感が両立するめちゃめちゃ面白い役割の１つなのではないでしょうか。
もちろん、もしかしたらPark Direct 自体が「顧客の課題解決に向き合っている内に行き着いた領域がたまたま駐車場だった」という出自にあるプロダクトなので、たまたま今回の論調と相性が良かったのかもしれません。
（ちなみに、その辺りのプロダクトの歴史や詳細などはこちらの動画で CHRO の俊樹さんから色々話されていますので、良かったら是非）
また、ニーリーがスタートアップ企業ということもあるかもしれません。
ビジネスサイドと密に連動して事業を進めるスタートアップ特有の一体感はまさしくそれ自体がプロダクト開発だと思います。
スタートアップ企業自体が１つのプロダクトであるとも言えるかもしれませんね。
というわけで、この記事を通してプロダクトエンジニアという役割の意味やプロダクト開発の面白さ、魅力が伝われば幸いです。 読んで頂き、ありがとうございました。
*1:「買うね！！」と心に決めたのなら既にその時に行動は終わっていないといけないよな〜、と思ったので、この記事を書きながら Amazon で新しいモニターをポチりました。
今から届くのが楽しみです。
