プロダクトエンジニアになってまず初めにやったこと

こんにちは、アドプラットフォーム事業でシニアプロダクトエンジニアをしている本間です。
自分が所属している部署で新しくできた職種、プロダクト・エンジニア(以降ではPdEと呼びます)になってまず初めにやったことを紹介します。

プロダクト・エンジニアとは
プロダクト・エンジニアとして動けるように環境整備
やったこと
まとめ

プロダクト・エンジニアとは

PdEはプロダクトの企画・仕様定義についてプロダクト・マネージャー(以降ではPdMと呼びます)と共に行いながら、自らプロダクトの設計・開発を行います。
プロダクトの企画・仕様定義から設計・実装まで一気通貫で行うことでプロダクトの仮説検証サイクルを高速化できます。

プロダクト・エンジニアとして動けるように環境整備

PdEとしての職務を全うするためには以下の課題がありました。

開発ロードマップの決定に開発チームが関わる
- 問題：開発ロードマップはプロダクト・マネージャーが決めて開発チームはそれに合わせて設計・開発を行っていた
プロダクトの問題の可視化や仮説検証の結果を俯瞰して見れるようにまとめていなかったので資産として蓄積する
- 問題：プロダクト・マネージャーが数年で何人か変わったが過去の課題や仮説検証の結果などが纏まっていなかったためプロダクトの状況を把握するのに苦労していた
営業、デザイナー、エンジニアで同じ基準で仮説を立てて優先度を決める
- 問題：営業が求める機能開発とギャップがあり、開発した機能をうまく展開できないことがあった

やったこと

今後の開発ロードマップを作成するための課題、仮説の整理をPdM、営業、デザイナー、エンジニアで行うためのフレームワークの提案とワークショップを行いました。
※プロダクト目標設定と問題整理は事業目標・戦略にも依存するため今回のスコープからは除外しました。
※目標と問題が設定された状態で2のソリューションの整理から始めました。
0. プロダクト目標を決める(今回スコープ外)
1. プロダクト目標を達成できない原因(問題)を整理する(今回スコープ)
2. 問題を解決するためのソリューションを整理する
3. ビジネスに与える影響と労力からソリューションに優先度をつける

1. 問題の整理

今回はスキップしてしましましたが、今後は事業目標・戦略と方向性を合わせて事業目標達成のために営業と共に動いていけるように事業目標に対してプロダクトが抱えている問題を整理する手法を検討しました。
アブダクション(思考方法)とロジックツリー(表現方法)を使って問題を整理します。

アブダクションｘロジックツリー

アブダクションとはロジカルシンキングの一つで帰納法、演繹法と並ぶ第三の論理展開手法です。

アブダクションの定義「起こった現象」に対して「法則」を当てはめ、起こった現象をうまく説明できる仮説を導き出す思考フレームワーク

以下の例のように大元の事象からその事象が起こった原因をツリー状に思考していきます。
例１では大元の事象の原因(問題)を仮説として立てています。

例1	売上が下がった
事象	売上が下がった
法則	販売数が減ると売上が下がる
仮説	販売数が減った

例２では例１で立てた仮説(問題)をさらに深掘りして原因(問題)を仮説として立てています。これを繰り返していきます。

例2	販売数が減った
事象	販売数が減った
法則	競合他社の類似品を買う人が増えると自社の販売数が減る
仮説	競合他社の販売数が増えた

また、例３では大元の事象から例１とは別の切り口で原因(問題)の仮説を立てて深掘りしていきます。

例3	売上が下がった
事象	売上が下がった
法則	販売単価が下がると売上が下がる
仮説	販売単価が下がった

それぞれの切り口で深掘りして行った仮説をツリー状に繋げてアウトプットを作成します。
過去に行った調査・分析・仮説検証を行っている問題については色分けしリンクを貼っておくことで今後問題を整理するときに参考にできるようにします。
例えば、問題に対して調査済みで対策を実施して結果も分析済みの場合は赤色にし、調査結果や対策の結果の数値を確認できるリンクを貼るなどします。

2. ソリューションの整理

問題とソリューション(MVP)をセットで整理します。始めは発散から行っていき、KJ法にならってグルーピングと文章化します。

3. 優先度付け

時間管理マトリクス(影響x労力)を使って優先度を決めます。
基本的にはソリューションの整理でグルーピングした粒度で評価しています。グループ内で切り出して評価した方が良いものがあれば切り出して評価を行います。
基本的には左上に近いものの優先度が高くなりますが、青と緑のゾーンについては開発リソースや外部環境を考慮して柔軟に判断する必要があります。
例えば、開発リソースを増やして工数を減らせる場合は価値が高い方を優先するなどです。

影響について

厳密な収益性などはこの時点は考えないですが実際に着手する前には早い段階で考える必要があります。

判断基準

エンドユーザ価値
- エンドユーザが嬉しい/助かるまたは嫌な体験を減らす/防ぐ
収益価値
- 会社/顧客にとって収益に触接的に繋がる

労力について

リリースプランニングなどはせずに大まかな労力について考えます。

判断基準

開発コスト
運用コスト
顧客トレーニングコスト/移行コスト
リスク(コア機能、新技術導入、法的、想定外のユーザー行動、etc)

まとめ

実際にワークショップを行ってみてPdEとして動けるように環境整備に対して以下の効果があると感じました。

開発ロードマップの決定に開発チームが関わる
- 効果：なぜその機能のが必要か背景が分かるようなったので要件や仕様を決めるときに開発コストを減らす提案や課題を解決するための効果的な機能の提案ができるようになる
プロダクトの問題の可視化や仮説検証の結果を俯瞰して見れるようにまとめていなかったので資産として蓄積する
- 効果：フォーマットの決まったアウトプットを出すことで成果物に対して理解・更新できる人が増え組織として学びを蓄積できるようになる
営業、デザイナー、エンジニアで同じ基準で仮説を立てて優先度を決める
- 効果：各ロールが参加することで多角的な視点で仮説を立てることができ、尚且つ同じ尺度で仮説の価値、労力を評価できたので温度感のズレがなく連携が取りやすくなる

また、参加者からフィードバックを得て以下の問題点が見えてきました。