プロダクトマネジメントはPMだけの仕事ではない。すべてのエンジニアが持つべきPM視点について

こんにちは。snaq.meでプロダクトマネージャーをしている渡邉(@nabepiyoo)です。

プロダクトマネージャーたるもの日々プロダクト開発をうまく進めたいと考えていて、どういうビジョンを持って、どうやって目標達成するか、そのために優先順位をどうするべきかみたいなことを考えています。

そして、デザイナー・エンジニアの協力がないと良いプロダクトはできないと考えており、PM視点を持ったエンジニアってすごく良いなと思ったので、エンジニアのスキルをちょっと向上させるかもしれないPM視点について書いてみようと思います。

スナックミーでは「何を作るかをエンジニアも考える」文化がある

一般的なエンジニアの主な業務や役割はこのようなものかと思います。

1.  設計: 新しい製品やシステムの設計、機能、性能などを決定します。
この業務は、製品やシステムの要件を分析し、それに基づいて設計を行います。

2. 開発: 設計に基づいて、製品やシステムを開発するためのコードの作成、テスト、デバッグなどを行います。
この業務は、プログラミングやハードウェア開発に携わるエンジニアが行います。

3. テスト: 開発された製品やシステムをテストし、品質、機能、性能などが要件を満たしていることを確認します。
この業務は、品質保証エンジニアやテストエンジニアが行います。

4. メンテナンス: 製品やシステムを維持管理し、必要に応じて修正やアップデートを行います。
この業務は、メンテナンスエンジニアが行います。

5. サポート: ユーザーからの問い合わせや問題に対応し、解決策を提供します。
この業務は、サポートエンジニアが行います。

6. プロジェクト管理: プロジェクトの計画、予算、リスク管理、チームの指導などを行います。
この業務は、プロジェクトマネージャーが行います。

組織の規模や文化によってどこまで誰がやるかを明確に分けているところもありますよね。上の切り方だとスナックミーでは1.〜4.は一通り個人で担当しているかと思います。 5はカスタマーサポートチームからシステムについての問い合わせがあれば対応しています。

また、スナックミーにはエンジニアがWeb開発以外のすべての工程に関わる「サービス・フルサイクルエンジニアリング」という考えがあります。

labs.snaq.me

プロダクトマネージャーがリサーチした結果や社内の業務担当者からどんな課題があるか、解決策のたたきを持ってきて、デザイナー・エンジニアも含めて何をどう作るかということを考えています。

PM視点を持たないエンジニアによる開発の弊害

ここではPM視点を持たないエンジニアによる開発の弊害について考えていきたいと思います。

局所最適になりがち

1箇所で解決できる機能を作れた場合でも、他の影響箇所ではすごく開発が大変になってしまったり、そもそも解決できなかったり、実は他にもそれを使い回せるところがあった、ということが考えられます。

技術的な側面だけでなく、スケジュール的にいつまでにここまでは進めていないといけないという感覚を持っているのかどうかということも大事な点です。

プロダクト開発はアウトカム思考で行うため、物ができたら完成ではありません。1回出してみて反応が悪ければ別バージョンを試すということも可能性として考えた上で行動する必要があります。そのため、夏休みの宿題を最終日に提出するパターンでバージョン1を最終日に出しても確度が低いものであれば失敗するケースもあるので、早めに出して様子を見る必要性もあります。

これは個人的な感覚ですが、全体を俯瞰できるようになると、物事が面白く見えてきます。弊社の場合、ユーザが利用するマイページだけでなく、おやつの製造〜出荷、おやつの選定、CRMなども自社システムなので、ここは大丈夫？ここは大丈夫？といくつも考える必要があります。もちろん各所理解している人がいるので確認することは可能です。

開発で無駄な手戻りが出てくる可能性がある

前述した1箇所で解決できる機能を作っていたら実は他にもそれを使い回せるところがあった、などもそうですが、リーンスタートアップの観点でMVPを作るということが考えられます。初めから大きく作ると大きく手戻りが発生する可能性がありますが、作る前にまず一番先に検証すべき仮説は何なのか、どうやってジャッジするのか、そのために何を作れば良いのかと逆算で考えていくことで、リスクは最小化した上で良いプロダクトを作ることができるようになります。

自ら事業をドライブしている感覚が少なくなる

何を作るか自ら考えていない場合、事業の成長に貢献できていると感じられるでしょうか？開発の優先順位を簡単にできそうだからという理由で決めていないでしょうか？事業インパクトが低いところを先に解決して、結果的に事業があまり成長していないということにならないでしょうか？

スナックミーではエンジニアがどのようにPM視点を持って開発しているか

ここではスナックミーで行っているPM目線を持つための取り組みについてお伝えしていきます。

事例紹介

VOCやテスト結果を共有

私のチームでは毎週火曜日にMTGを行っており、そこで解決策のたたき付きでユーザからのフィードバックを共有し、どうやって解決しようかと話し合っています。

※ たたきの部分については非公開にさせていただきました。

テスト結果についても同様で、何かA/Bテストを実施した場合、MTGの際に数値の振り返りもしています。

一喜一憂することなく、どういう結果になって、その結果になった理由はなんだろうねと話し合っています。

施策のシミュレーションをする

これは私が行っている作業ですが、数値を見ながら期待効果、開発工数、確度でシミュレーションしています。RICEやICEと考えは近いですね。期待効果についてはアクセスログを見たり、GAを見たりしながら数値を拾っていき、不明点に関しては変数を置いて計算しています。

メリット

複数の視点で考えると考慮漏れも減らせる
当事者意識ができる
フィードバックがもらえると喜び、やりがいにつながる

このようにメリットがあり、議論の価値があるかと思っています。

また、これに関して先日嬉しかった出来事がありました。

以前同じように議論していた内容の1つに、snaq.meのストアで売り切れの商品が多くて困っているというユーザの声がありました。

売り切れの商品はたしかに場所を占有してしまうのですが、こんな商品があったんだと気づいてもらえる機会にもしたいと考えており、ただ単純に売り切れを非表示にするという選択が良いとは考えていませんでした。

そこで考えたのが販売中のみ表示するオプションでした。

ユーザの皆さんからいただいているアンケートも読んでいて、機能リリース後に「今回追加された機能の中で個人的に一番嬉しかったのは販売中のみ表示の機能でした。」という声もいただいて、すごく嬉しかったのを覚えています。

デメリット

システム規模によっては考えるべきことが広範囲になる。
プロジェクトの目標や優先順位を過度に優先するため、技術的な問題や改善点が見逃される可能性がある。
具体的な技術的問題について語ることができなくなり、開発チームとのコミュニケーションが困難になる可能性がある。
時間や予算の制限を過度に重視するため、開発チームのクオリティーや効率性に影響を与える可能性がある。
プロジェクトの成果物が、技術的な観点から不十分である可能性がある。
開発チームのモチベーションが低下し、生産性が下がる可能性がある。
デザインやUXに関する観点が欠け、プロダクトの魅力が低下する可能性がある。

どんな人にも強み・弱みがあると思います。

スナックミーでも誰かの弱みは誰かの強みで補うように考えており、UI/UXに関してもデザイナーと一緒になって考えることで元のアイデアをブラッシュアップしたり、こういうアニメーションだったら意外と簡単に実装できるよとエンジニアが提案したり、こういうことをしたいけどこのあたりに問題があって今の状態では難しいよ等、全体のクオリティが下がらないように心がけることでデメリットを解消しています。

また、月に1日KAIZENタイムを設けることで、技術的負債の解消に取り組んだり、通常業務では取り掛れないことを行っています。