この記事は？
とある企業のWebエンジニアが、プロダクトエンジニアリングに興味を持ち、その第一歩目を企業の中で実践した体験記をシェアするものです。
ハイライト
- プロダクトエンジニアとは、開発の目的を「プロダクトを通じたユーザーへの価値提供」と定義するエンジニアロールである
- ユーザーへの価値提供のためには、How（どう作るか）の問いも、What（何を作るのか）やWhy（なぜ作るのか）の問いに答える能力を求められる
- 「自社プロダクトの既存UXを実際に体験し、それを精緻に言語化すること」が、プロダクトエンジニアリングの第一歩目である
あなたは誰？何をしている会社?
はじめまして！株式会社サイキンソーにWEBエンジニアとして勤務している@ddpmntcpbrです。
弊社は、「細菌叢で人々を健康に」 をミッションとして掲げているヘルステックベンチャーで、主に腸内フローラ検査事業を展開しています。
事業領域は BtoC・BtoB 両方にまたがっており、例えば BtoC ビジネスとして個人向けの腸内フローラ検査キットのオンライン販売を行っています。
その中でも私は、BtoC領域におけるWebプロダクトの新規開発・運用保守をメインに行っています。 例えば、上記の検査キットは商品購入から検査結果閲覧までをすべてオンラインで完結できるサービスとなっており、マイページの登録や検査結果画面などのあらゆるWeb上のユーザー体験が、私の業務スコープです。
プロダクトエンジニアとは？
昨今、業界各所で「プロダクトエンジニア」「プロダクトエンジニアリング」という言葉を聞く機会が増えてきました。
プロダクトエンジニアの定義や生まれた背景については、以下の記事で整理されています。同記事では、プロダクトエンジニアを 『開発の中心にプロダクトの価値追求を置くエンジニア』 と定義しています。
みなさんは"プロダクトエンジニア”という職種を聞いたことはあるでしょうか。一般的なフロントエンドエンジニアやフルスタックエンジニアに比べると聞き馴染みはない一方で、開発の中心にプロダクトの価値追求を置くエンジニアを指すといえばしっくりくる方も多いと思います。プロダクト志向を持つエンジニアは体感的にも増加しており、採用の面でも国内外の企業でプロダクトエンジニアの職種を定義し始めています。
従来、エンジニアの区分けといえば「フロントエンド」「バックエンド」「インフラ」といった技術領域に基づいたものとなっていました。 これは、各領域の専門性が高く、ひとりのエンジニアが複数領域を同時に修得することが難しい（フルスタックエンジニア、はそうそう生まれてこない）ことが理由でした。
しかし、生成AIに代表される新規テクノロジーにより、技術の一般化が徐々に進みつつあります。これにより、ひとりのエンジニアが複数領域を修得するハードルが相対的に下がり、エンジニアの種類を技術領域で区分けする必要性が薄れてきました。この流れに先に、プロダクトエンジニア、という新しい括りのポジションが生まれたとされています。
同記事をもとに、私なりにプロダクトエンジニアの特徴を整理すると、
- プロダクトを通じたユーザーへの価値提供こそが開発の目的であると考える。一方、プロダクトを構築するための技術は、あくまで目的を達成するための手段だと考える。
- 自身の専門性や業務範囲を**「フロントエンド」「バックエンド」「インフラ」といった技術領域では区別しない**。プロダクトの価値向上につながるならば、なんでもやる。
- メイン領域はあくまでエンジニアリング（＝プロダクトの開発）ではあるが、従来のエンジニアが必ずしもカバーしていなかったプロダクトマネジメントやUXデザインにも、サブ領域として手を伸ばす。
といったイメージかと思います。詳しくは、ぜひ同記事を参照いただけたらと思います。
AI時代に求められるプロダクトエンジニアリング思考
私がこの言葉に注目をしている理由は、AI時代にバリューを発揮し続けるエンジニアの在り方のひとつが、このプロダクトエンジニアというロール だと考えているからです。
生成AIの登場は、私たちエンジニアの働き方やキャリアビジョンなどに大きな影響を与えつつあります。
巷では、「コードはすべてAIが出力するから、エンジニアはいらなくなる」というエンジニア不要論が唱えられることもあります。個人的には、「一足飛びでそんな世界になることは、さすがにないんじゃないかな」とは思いますが、
- AIを使いこなせるエンジニアとそうではないエンジニアでは「生産性」に大きな差が生まれる
- AIが人の仕事を奪う世界よりも先に、AIを使いこなす人がそうではない人の仕事を奪ってしまう
という未来はすでに到来しつつあると思います。「エンジニアをひとり雇うことに比べたら、月額$500の Devin AI ってコスパいいよね」 という風潮は、まさにそれを象徴しているのではないでしょうか。
ここで、「エンジニアが発揮できるバリューとは何であるのか」を改めて問い直すにあたり、一度、先に述べた「生産性」という言葉に注目してみたいと思います。
生産性という言葉は、しばしば定義が曖昧なまま使われてしまいがちです。エンジニアは「生産性を高めること＝サイコーによいこと」と考えがちですが、そもそもエンジニアに求められる生産性とは、一体何を生産することを指しているのでしょうか？
例えば、ある機能を実装したいとします。従来は10の時間がかかっていたところが、生成AIを活用することにより5の時間で実装できれば、「生成AIの活用により、生産性が2倍になった」と表現できるかもしれません。
しかし、その機能が世の中の誰にも使われることがないものだったとしたら、どうでしょうか？
ユーザーからすれば、特に価値を感じないもの、経営者からすれば、ビジネスに貢献しない（お金稼ぎにつながらない）もの。それを生み出す速度が高まったことを「生産性があがった」と表現するのは、さすがに違和感を感じますよね。
つまり何が言いたいのか。生成AIによる技術の一般化が進む現代において、エンジニアとしてバリューを発揮し続けるためには、How（どう作るか）よりも、What（何を作るのか）やWhy（なぜ作るのか）に答える能力が強く求められるようになる というのが、私の考えです。
「こんなプロダクトを作ってください」と生成AIに命じれば、ソースコードが返ってくるような時代が、部分的には到来しつつあります。
しかし、
- 「このプロダクトで、ユーザーの課題は解決できますか？」
- 「そもそもユーザーは、どんな課題を抱えていますか？」
- 「このプロダクトを作ったら、うちの会社は儲かりますか？」
という質問には、生成AIはうまく答えられないでしょう（正確には、最も無難で面白みのない答えが返ってくるだけで、事業の意思決定に活用できるような答えは返ってこないはずです）。
プロダクトは必ず「こんなプロダクトを作りたい」という誰かの想いから始まります。それは、経営者だったり、プロダクトマネージャーだったり、クライアント企業だったりしますが、「言われた要件にそのまま忠実に開発をする」というバリューの出し方のみを続けると、いずれ生成AIとの真っ向勝負を強いられることになると思います。なぜなら、How（どう作るか）という、生成AIが最も得意な領域で戦うことになるからです。
そうではなく、
-
Why（なぜ作るのか）
- そもそもユーザーは、どんな課題を抱えているのか？
- ユーザーは、その課題をお金を払ってでも解決したいのか？
- 既存の競合プロダクトと比べて、ユーザーが自社プロダクトを選択する理由はあるか？
-
What（何を作るのか）
- このプロダクトや機能は、本当にユーザーの課題解決につながるのか？
- 自社で内製化せず、外部SaaSを組み合わせた方が安く作れるのではないか？
- このドキュメントに書かれている要件は、本当にプロダクトマネージャーの頭の中の構想が正しく言語化されたものか？
といった問いに対して参加し、技術的に実現可能なものとしてプロダクト完成までのロードマップをひけること。そして、AIを活用してHowの問いに高速に答えながら、実際に開発完了まで完遂できること。このような能力が、AI時代を生きるエンジニアに求められるものになるのではないでしょうか。
そしてこれは、AIの登場により、エンジニアに求められる生産性の定義が変わってきている、とも表現できると思います。かつては、エンジニアの生産性=Howの問いに回答する質・速度の高さであったのが、徐々にエンジニアの生産性=WhatやWhyの問いに回答する質・速度の高さに移り変わりつつある、ということでもあります。
そして、この思考をひとことでまとめたのが、プロダクトエンジニアリング思考だと言えるでしょう。先のnoteでは、「プロダクトエンジニアリング＝開発の中心にプロダクトの価値追求を置くエンジニア」という定義でしたが、私は 「プロダクトエンジニアリング＝Howの問いよりも、WhatやWhyの問いに答えることに重きを置くエンジニア」 とも定義できるのはないかと考えています。
今日からあなたもできる。プロダクトエンジニアの第一歩目は？
プロダクトエンジニアリングを実践するための第一歩目として、具体的にどのようなことができるのか、を私なりに考えてみました。
その答えの一つが、自らが自社プロダクトのユーザーとなり、UXを追体験して、それを徹底的に言語化することでした。
UXデザインの関連書籍を読むと、ほぼ共通して「ユーザーの声を聞くことが一番大事」と書かれています。ユーザーインタビュー、アクセス解析など手法が様々ありますが、そもそも「ユーザーに話を聞くよりも前に、エンジニアとして働いている自分は、自社のプロダクトが提供するUXのことをちゃんと理解できているのだろうか？」という疑問を改めて持つようになりました。
企業規模が大きくなるほど、ある一人の社員が自社プロダクトの全体像を把握することが難しくなります。エンジニアは、自身が担当した機能について誰よりも詳しいかもしれませんが、「その機能は本当に必要なのか？」という問いに正確に応えるためには、UXの全体像を知っておく必要があります。
エンジニアの目線だと、ついついUX≒UIと考えてしまいがちです。「ボタンが押しやすいのか」とか「画面設計は直感的か」とか。
もちろん、それもUXの中の重要な要素なのですが、事業インパクトが大きいのは、もっと前提にある「そもそも論」なこともしばしばあると思います。
- そもそも、自分は何をきっかけにこのプロダクトのことを知るだろうか？
- そもそも、このプロダクトに興味を持つとしたら、どんな流れがあるだろうか？
- そもそも、自分はこのプロダクトを、この値段を払ってでも欲しいだろうか？
UXの全体像を俯瞰しておくことによって、より経営にインパクトのある提案を行うことができるようになったり、企画の段階で主体的に参加をする土壌が整うかと思います。
体験記
ここからは、弊社プロダクトである個人向けの腸内フローラ検査キットを対象に、私が「自身がユーザーとなることを通じて、現状のUXを徹底的に言語化する」というワークを実践した体験記をシェアしたいと思います。
実際に、私も検査キットを使って自身の腸を定量化してみることにしました！どんな結果が出るか楽しみですね。
STEP1 UXフローのステップ分割整理
まず初めに、自社プロダクトがユーザーに提供するUXフローを、いくつかのステップに分割して整理しました。
| ステップ | 詳細 | アプリ内外 |
|---|---|---|
| 1.認知・興味喚起 | メディア、広告、口コミ、などを通じてプロダクトを認知する | アプリ外 |
| 2.購買 | ECサイトで商品を購入する | アプリ内 |
| 3.検査キットの到着・開封 | 自宅に、検体を採取するためのキットや各種説明書類が届く | アプリ外 |
| 4.検体の採取 | 検査キットに同封されている説明書を読みながら、検体を採取する | アプリ外 |
| 5.アカウント登録 | 検査キットに同封されているQRコードからマイページにアクセスし、新規アカウント登録を行う | アプリ内 |
| 6.検体の返送 | 採取した検体を同封された返送用封筒に入れ、自宅近くの郵便ポストに投函する | アプリ外 |
| 7.質問票への回答 | マイページ上から、生活習慣などに関する質問に回答をする | アプリ内 |
| 8.検体受領メールの受信 | 検体が解析施設に届くと、アカウント登録したメールアドレスに、検体受領を知らせるメールが届く | アプリ内 |
| 9.結果公開メールの受信 | 解析が完了し、マイページ上から検査結果を閲覧できる状態になると、その旨を知らせるメールが届く | アプリ内 |
| 10.検査結果の閲覧 | マイページ上から、検査結果を閲覧できる | アプリ内 |
| 11.アンケート回答 | マイページ上から、ユーザー満足度などのプロダクトに関するアンケート回答を行える | アプリ内 |
| 12.改善アドバイスの実践 | 自身の検査結果に基づいて提案された腸活アドバイスを実践する | アプリ外 |
| 13.リピート購入 | 再度、検査を実施する | アプリ外 |
- ステップ1つ当たりの粒度は、UXフローをフローチャートに書き起こしたときの1工程分くらいの大きさにしました。
- ステップの入り口を「認知・興味喚起」とすることで、未顧客が新規顧客となっているUXフローを表現しました。
- ステップの出口は、売り切りのプロダクトなら「リピート購入」、サブスクのプロダクトなら「契約の継続」にすることで、LTV（顧客生涯価値）の向上につながる改善点を見つけやすくなると思います。
- アプリ内外＝エンジニアが普段の業務で直接的に関与する領域か否か、も付け加えておきました。エンジニアが思いつく改善点は、どうしてもアプリ内の話に閉じてしまいがちですが、「アプリが提供する体験は、あくまでUXの一部分である」という視点も、この施策で得られるもののひとつだと思います。
STEP２ 認知・興味喚起の深掘り
ここから、各ステップごとに課題や改善点を洗い出していく作業に入るのですが、ステップの最初においた「1.認知・興味喚起」だけは、別のワークをする必要があると考えました。
理由は単純に、自分はもう自社プロダクトを知ってしまっているので、プロダクトを認知するユーザー体験をそのまま追従することは難しいからです。
ここでは代わりに、私がこの商品を自腹を切ってでも欲しくなるとしたら、それはどんな見せ方をされたときだろうか？、を考えてみることにしました。
具体的には、以下の言語化を試みました。
- ちょうど自分が当てはまるようなペルソナの設定
- プロダクトによって満たされるペルソナの欲求
ペルソナの設定
自分自身の中にある要素（性格、習慣、生活環境、思考など）のうち、プロダクトとの関わりがありそうな部分を思いつく限りリストアップすることで、擬似的なペルソナイメージを構築してみました。
- ペルソナイメージ
- エンジニアとして働いている30代男性
- 新しいものに対する興味関心が強い。最新の技術トレンドを追うのは、仕事・趣味どちらのモチベーションも含まれている。
- 健康に対する意識は、平均的なビジネスパーソンよりは高いと自負している。
- 有酸素運動、睡眠時間のウォッチ、サプリメントの摂取など、いくつかの健康習慣への取り組みはしているが、効果の実感はあまりない。「健康に対してちょっとだけ高い意識を持っている自分」という自己肯定のために続けている側面がある。
- 筋トレや食事制限のような、ちょっとでもキツさを感じるものは三日坊主で終わりがち。定量的な結果が出るよりも先に、「これを続けて本当に意味あるのかな」という疑問が浮かんでしまって、辞めることを正当化してしまいがち。
- 健康に使うお金は投資だと考えていて、ある程度のお金は出していいと思っている。
- 腸活が大事らしい、ということはなんとなく知っている。インターネットで誰かが勧めていたサプリメントをとりあえず飲み続けている。
- 生産性というワードには敏感。健康維持は仕事の生産性にもつながっていると考えている。
- 物欲はあまりなく、普段はそんなにお金を使わないが、興味のある最新ガジェットに対しては数万円の金額を躊躇なく支払える。
...なんだか、書いているうちに恥ずかしくなってきましたね。。。
プロダクトによって満たされるペルソナの欲求
先のペルソナイメージを前提に、ペルソナが持っている欲求が何であるのか を考えてみました。
- 腸内フローラ検査に基づく具体的な健康習慣アドバイスを知ることで、実践する健康習慣に自信を持ちたい
- 生産性を高めるために実践している健康習慣の確らしさを客観的に評価することで、自分の行いが間違っていないんだと安心したい
- 健康習慣を維持していることを他人に見える形で定量化することで、周囲から意識の高いビジネスパーソンであるという承認を得たい
プロダクトの機能的価値はそのままでも、ブランディングやプロモーションなどで上記の欲求に訴えるような見せ方をされたら、「きっと、自分は買うだろうな」と思いました。
この記事をここまで読んでくださっている勉強熱心なエンジニアの方であれば、共感してもらえる部分もあるのではないでしょうか...?
STEP3 課題・改善点のリストアップ
「2.購買」以降のUXフローを追体験しながら、感じたことや改善できそうなことを、スプレッドシートに書いていきました。
| ステップ | 課題・改善点 | 経営影響度 | 実現容易度 | 優先度 |
|---|---|---|---|---|
| 2.購買 | 商品画像について... | 1 | 1 | 2 |
| ... | ||||
| 7.質問票への回答 | ボタンのUIが... | 1 | 3 | 4 |
| ... | ||||
| 8.検体受領メールの受信 | メールの文面について... | 2 | 3 | 5 |
| ... | ||||
| 13.リピート購入 | 次回検査目安のタイミングで... | 3 | 3 | 6 |
- 「経営影響度」は、KGIやKPIなどの経営指標に直接的な影響を及ぼす度合い。1~3の三段階評価で、3の方が高い。
- 「実現容易度」は、改善を実現するためにかかるコスト（開発や社内意思決定など）の度合い。1~3の三段階評価で、3の方が簡単。
- 経営影響度と実現容易度の和を「優先度」と定義しました。リストが書き終わったら、優先度順にソートすることで、まず最初に手をつけるべき課題が整理できます
- プロダクトの裏側を知っているエンジニアだからこそ気づくこともありましたが、なるべく自腹を切ったユーザーになりきるということを意識してみました。
STEP3までで、個人としてのワークは完了になります。ワークを実践する前と比べたら、現状のUXに対する理解は深くなっていると思います！
STEP4 改善の実践
さらに周りを巻き込むように広げていこうとするのであれば、
- 改善リストをエンジニアチームや、PdM・マーケティングメンバーにシェアして、フィードバックをもらう
- 優先度の高い課題をチケット化して、開発・リリースまで行う
というところまでできると、よりプロダクトエンジニアリングの実践を進められるかと思います。
単なるエンジニアの目線での提案ではなく、UX全体を俯瞰した上での改善提案になるので、エンジニア以外の役割のメンバーにも意義を伝えやすいかと思います。
「経営影響度」はそのまま、「この改善にリソースを割くことに対して、社内からの理解を得やすい度合い」にもなります。
個人ワークだけで完結させずに、周囲に影響範囲を波及させることで、自らプロダクトエンジニアリングの起点になるような動きにもつながると思います。
まとめ
今回、「自身がユーザーとなることを通じて、現状のUXを徹底的に言語化する」というワークを行ったことによって、UX全体のことが俯瞰的に理解できるようになりました。
今後、ユーザーインタビューなどに参加させてもらった場合も、より高い解像度で情報を得られるようになるかと思います。
プロダクトエンジニアリングを小さく実践する第一歩目として、ぜひ皆さんにもトライしてもらえたらなと思います。
ところで、あなたの検査結果は？
なんとびっくり、総合判定が堂々のE判定！（A~Eの最低ランク）。
「健康に対する意識は、平均的なビジネスパーソンよりは高いと自負している」とは、一体どこの誰が言ってたんですか...？
とはいえ、裏を返せばここから伸びしろしかないということなので。ポジティブに考えていくことにします。
当検査では、「有用菌を増やすアドバイス」と「要注意菌を減らすアドバイス」がそれぞれ提案される仕様になっているのですが、私にはいずれでも「果物の摂取」が提案されていました。
確かに、果物を食べる習慣が全くなかったので、これは取り入れがいがありますね。そもそも、腸活＝「〇〇菌入りと書かれている食品またはサプリメントの摂取」というイメージがあったので、普通の生活の延長でできることがあるというのが、意外な気づきでした。
あなたも腸を見てみませんか？
最後まで読んでいただきありがとうございました！面白いと感じていただけましたら、いいね や Xでのシェア をしていただけると、大変励みになります。
もし、弊社プロダクトにも興味を持っていただけましたら、ぜひお手に取ってみてもらえたらと思います！
Discussion