さて、第5弾です。

前回でUXデザインとPRDについてお話したので、今回はエンジニアリングのチームとの実装についてです。

Working with Engineers

Product Managerの面接ではよく、エンジニアとうまく働けるかがよく問われます。会社によりますが、Product Managerにもエンジニアが受ける技術的な部分の面接を課すところも多いです。こういった背景があるので、よくProdutct Managerにはテックバックグラウンドが必要だと言われます。僕自身もMBAに入る前はエンジニアをしていたのですが、実際にProduct Managerとして働いてみて、この仕事に必要とされる「テックバックグラウンド」って多くの人が思い浮かべるような「コードが書ける」とか「エンジニアにコードのアドバイスをする」みたいなところとは若干違うことに気づいたので、その辺を紹介してみます。

What & How

PMシリーズの一番初めの回でも書きましたが、Product Managerの仕事はWhatを定義することです。何を解決するべきか、解決策は何であるべきかをAnalytics、デザインと一緒に定義していきます。何を解決するべきで、その解決策は何であるべきかがわかったら、エンジニアの出番です。エンジニアはテクノロジーに関してのHowの専門家で、定義された解決策を実現するために必要なテクノロジーのスペックを定義し、実装していきます。

僕も含めてProduct Managerのいない組織でのエンジニアからProduct Managerにスイッチした人の多くはエンジニアに渡す際、Productの定義領域がHowにまで及んでしまうことがよくあります。これ、僕にとっては結構な学びだったのですが、チームのエンジニアがジュニアな人しかいないときはこういうガイダンスも必要ですが、ある程度シニアなエンジニアになるとProduct Managerが先にテクニカルなスペックを出してくるのを嫌います。

Let builders build
(作る者たちの邪魔をしてはいけない)

Uber’s original cultural values

Product Managerは実装方針に関しては基本的にはサポート役であるべきなので、プロダクトスペック(解決されるべき問題とそれを実現するための機能群をユーザー視点から定義したもの)を定義してエンジニアに渡した後は、エンジニアが模索して持ってきたテクニカルスペックをレビューして、プロダクトの観点からの懸念点(このプロダクトはこういう風に進化させていきたいのでこのアーキテクチャだとこのタイミングでガタがくるとか、そのフレームワークだとこのエッジケースがカバーされないとか、ユーザーがこんな風に増える予定なのでそのQPS (query per second)だとやばいとか)をフィードバックするにとどまります。テクニカルなProduct Managerだと、例えばデータベースの選定や、具体的なロジックに関してのフィードバックも行いますが、フィードバックはあくまでもプロダクト視点でのフィードバックで、実装方針はあくまでもエンジニア主導で決定していきます。

Involve Early

エンジニアと働く中で学んだもう一つの大事なことは、彼らをいかに早い段階からプロジェクトに関わってもらうか、です。

これは二つの点から大事です。

まず一つは問題の解決策としてエンジニアしか思いつかないようなことも結構あるということ。エンジニアに解決しようとしている問題を投げかけてみるとUXデザイナーやProduct Managerでは思いもつかなかったようなテクニカルなアイディアが飛び出してくることがあります。それだけでユーザーエクスペリエンスの全部が解決されることは稀ですが、そのテクニカルなアイディアをコアにしてユーザーエクスペリエンスをデザインしていくということはよくあります。

もう一つはデザインのフィージビリティチェックです。ある程度のデザインのフレームワークができたら、まずはそれをエンジニアに見せ、早い段階でエンジニアの観点からフィードバックをもらうことで、エンジニア的に無理そうなところや実装にめちゃくちゃコストがかかりそうなところがわかります。それを知った上でデザインをすることで、よりリーズナブルなデザインになり、デザイン→エンジニアの受け渡しをスムーズにすることができ、エンジニアの実装速度をアップさせることができます。

Agile

二つほど心得的なことを書いたので 笑
一つだけ、戦術的なところのことも書いてみます。笑

アジャイルは、MBAのインターン時代にも書いたことがありますが、(Summer Internship -Practice 参照)おさらいという感じで。

アジャイルは簡単にいうと、開発時のチェックサイクルを短くすることで、チームとして進捗を管理しやすくして、進捗具合やプロダクトの学びを元に方向修正をしやすくするための手法です。

基本的には1週間から4週間で一つのサイクル(スプリント)として、そのスプリント内の自分の持ち時間から実行可能なタスクを決めて実行していきます。
スプリント内ではスタンドアップと言われる進捗確認をとても短い間隔(毎日とか隔日とか)で行います。これによってチーム間での情報共有や、進捗をブロックしているものを共有して解決できる人に助けてもらいやすくします。
各スプリントの最後には大体デモとレトロ(レトロスペクティブ)というものを行います。
デモはそのスプリントで達成したものをみんなで見るという感じです。どちらかというとレビューというよりは、みんなにできたものを見せて褒めあってモチベーションを高めるとか同じチームのメンバーがどういうものを作ってるのか知るというのが目的な気がします。(レビューは、デモとは別に各プロジェクトで独立して行います。)
レトロは、スプリントの最後に、そのスプリントでうまくいったこと、うまくいかなかったことをチームメンバー全員で出し合って、オープンに話し合う場です。その中で話し合ったものの中で、次のステップを取るべきものはリストアップしてチームの中で誰がオーナーになるかを決めてトラックします。

おおまかにいうとこんな感じでしょうか。チームによって違いますが、スプリントは結構エンジニア主導なところが多い気がします。

Product ManagerのAgileへの関わり方は、

• Agileのタスク用にProductのユーザーストーリーを作る
• スタンドアップ、その他でエンジニアのブロッカーになっているものを取り除く
• デモでちゃんとエンジニアを褒める

とかでしょうか。

Productが定義されたら、機能を元にユーザーストーリーを作ります。ユーザーストーリーはユーザーがその機能を使って出来る一つのシナリオで、「〜が〜することができる」みたいな感じで書くのが一般的です。そして、何をもってそれをできたと見なすかというExit Criteriaを定義して、一つのまとまりとしてエンジニアに渡し、それを元にエンジニアが必要に応じて実装手順ごとにサブストーリー/サブタスクを書いていきます。

スタンドアップの話はそのままなので省略するとして、その次のデモでちゃんとエンジニアを褒めるをもう少し書いてみます。これ、Product Managerとして結構大事です。これもまたPMシリーズの一番最初に書きましたが、Product Managerは製品開発チームの心臓であるべきなので、その製品を作って世に出したいと一番思っている人なはずです。そういう人なので、その製品に関するデモは、それがどんなに些細なことでも、どんなにテクニカルなことでも強い興味を示すべきで、そのタスクが完了したことを喜ぶできです。プロダクトリーダーシップという点で、エンジニアにこういう姿勢が見せれるかというのもProduct Managerの大事な職務の一つです。

Wrap Up

外から見るとProduct Managerってエンジニアと密に仕事をしていて、エンジニアのプロジェクトマネジメントをいかに回すかが主な仕事と思われがちですが、実際はそんなこともなかったりします 笑

ただ、エンジニアとプロダクトは基本的には組織的に独立しているので、特別な権限のない中でいかにエンジニアの士気を高めて効率的に製品開発を回すかであったり、その製品が提供できる価値をいかに低コストで早く世に出せるかというのはProduct Managerの大事な資質なので、そういった観点から、Product Managerとしてのエンジニアとの関わり方を書いてみました！