プロダクトマネージャーとしての学び

Pivotal Labs で働いて4年が経とうとしています。本題に入る前に、Pivotal Labs という会社を知らない人が大半だと思うので、弊社のこちらのブログ記事に詳しく書かれていますので、ご参考ください!

Pivotal Labs はクライアントから依頼を受けて、ソフトウェアを開発しています。しかし、受託開発を行っているわけではありません。私達のゴールは、案件終了時にはクライアントが自分たちのみで持続的に良いプロダクト開発のプロセスを継続することができ、かつ新しいメンバーにその手法を教えることができる状態になっていることです。

Pivotal Labs のプロダクトマネージャーとしての経験は非常に貴重で、今後の自分のプロダクト開発との向き合い方を改めてくれたような気がします。この学びをプロダクト開発に携わる、主にプロダクトマネージャーのみなさんにご紹介したいと思い、この記事を書いています。この会社に入った当初は働き方含めてすべてが新しくて、軽いパニックになっていたのですが、その中でもとびっきりの学びをひとつだけ。それは「何を作るかよりも、何を作るべきではないのか、という視点に比重を置いてプロダクトを開発すること」です。

計画は信頼できなくなる

VUCA ー Volatility(変動性・不安定さ)、Uncertainty(不確実性・不確定さ)、Complexity(複雑性)、Ambiguity(曖昧性・不明確さ)時代の到来とよく言われています。様々な業界、業種、組織、文化をお持ちのクライアントとお仕事をさせていただいていると、本当にその通りかもしれないと実感することが多々あります。同僚とも話していて感じたのは、これまでの経営哲学は結果を予測可能にするために計画とコントロールを重視してきたが、変化の早さが最大の脅威となったとき、計画や予測は信頼しにくくなる、ということです。それはとても身近な問題として、表面化してきているように思えます。現に、PDCA について指摘されているこちらの記事はとても腹落ちしました。

PDCAが前提としているのは、あくまで “想定外のことが起きない” 世界。つまり、「常に安定しており、かつ心理や感情など人間的要素が関わらない環境」の中で継続的に改善を繰り返して品質を高めていくというシーンで使うのであれば、確かに有効なのです。しかし、“いつも想定外のことが起きる” “昨日と今日で状況が変わる” といった「先がまったく読めない」環境では、そもそも最初の「P(計画)」の立てようがありません。そこでPDCAにこだわりすぎると、かえって物事が前に進まなくなる原因にもなり得るのです。

そのため、新規事業であれ、新しい機能開発であれ、プロジェクトの上流で市場調査やユーザー調査の結果をもとにした要件定義に膨大なコスト(時間や予算)をかける傾向にあります。なぜなら、失敗するリスクを避けるためです。

ところが、時間の経過と共に変化の早さに対応することが困難となるため、後工程にしわ寄せが生じてしまい、プロダクト開発そのものがコントロール不能となってしまうという別のリスクが姿を現します。そのため、「この先の全体像が見えなくて不安」「どんなモノがいつできるかわからない」と言った心配が絶えなくなります。

プロダクト開発は賭けである

プロダクト開発は賭けのようなものです。それは避けられません。なぜなら、世に出さないとわからないことが多いからです。できることは、賭けを小さくして失敗するリスクを可能な限り低くすることです。

多少編集しましたが、ぼくが尊敬する上司の言葉です。ここで記載の失敗するリスクとは、ものを作るまでの時間に対して間違ってしまうものを作ってしまい、結果としてユーザーに使ってもらえないリスクのことを指します。小さな賭けで、小さな成功を積み重ねることが、現代のプロダクトにおける生存戦略なのかもしれません。

Pivotal Labs は、Lean XP という開発手法を用いて上記の実現をサポートしている会社です。そのような働き方を4年も続けていると、自分の中でプロダクト開発に対する価値観が変わっていることがわかりました。これまでは、誰に何をどのようにプロダクトやサービスを届けるべきなのかを強く自問しながらプロダクトデザインやプロダクト開発に携わってきました。

ところが、Pivotal Labs のミッションである『Transforming How the World Builds Software(世界中のソフトウェア開発そのものを変革する)』を体現するためのアプローチや手法を学んでいく中で、徐々に自分のとってのプロダクトマネジメント論が確立されていきました。

 

ぼくが考えるプロダクトマネジメントとは、仮設検証という小さな賭けを繰り返しすることで「つくるべきではないもの」は何かという学びを最大化し、失敗による被害を最小限に留めてプロダクトを成功させること。そして、実現に向けてチームの強みを活かしながら、ユーザーに価値を提供し続けることができるような組織文化を浸透させること。

 

プロダクトマネージャーの Job Description(職務内容)は様々で十人十色ですが、ぼくが大切にしているプロダクトマネジメントはこの通りです。今の会社には、本当に感謝しています。

何を作るべきではないのかを考える

話を戻しますが、Lean XP の実践的なアプローチやマインドセットはこれまでのブログ記事などでもご紹介していきましたが、本質にあるのは「何を作るかよりも、何を作るべきではないのかに比重を置いてプロダクトを開発すること」です。世の中的にみても、同じ思考に傾いてきている気がしなくもないです。

当時話題になった、Microsoft Work 2000 の UI

当時話題になった、Microsoft Word 2000 の UI

よくあるプロジェクトのケースだと、要件をできるだけ盛り込み、完成形と呼ばれるアウトプットが始めに描かれることが多く、あとはその実現に向けて「どう作るか」という思考のみが働き、約束という名の計画が練り上げられていくことが多いようです。

ここでの落とし穴は2つあります。

  1. 一度決めたアウトプットに対して疑いを持たなくなること(持つことができないこと)
  2. 計画通りに行かないとコントロール不能になり炎上すること

Lean XP ではこの落とし穴にはまらないように、開発をしながら先行してユーザー調査を繰り返し、想定されるアウトプットに対しての評価を元につくるべきではないもの(機能含む)を特定し、排除すること&新たなる課題やソリューションの種を拾いながら検証済みのモノを開発します。結果として、より良いモノが生まれやすくもなります。

下記のアーミーナイフの図がとてもわかりやすいです。右が必要だと考えている最終形のアウトプット、左は実際にユーザーが求めている理想的なモノの対比です。

Copyright (c) Anton Nikolov 2017

つまり、先に作る予定のモノは、必要であることがわかっている物のみに絞られていきます。これを次々と繰り返すことで、何を作るべきか、必要なもののみを積み上げた理想形に近づけることができます。

どう作るかにプロダクトの運命を委ねない

完成形は存在しないと思っています。それは、サービス提供者側が勝手に考えたアウトプットにしか過ぎません。重要なのは、ユーザーが頭に描いているアウトプットなのではないでしょうか。

生活様式が変わったり新しいサービスが次々と登場する世の中において、変化が早いのは当然だと思っています。そして、計画や予測は信頼しにくくなるのは当たり前だと思っています。だからこそ、賭けに出る姿勢(アプローチ)が必要なのです。

Lean XP は奥が深く、現代に求められている開発手法だとは思いますが、他の開発手法と比べて最も優れているとは思っていません。そう言ってしまってはもともこうもありませんが、プロダクトの運命を「どう作るか」に委ねるのではなく、「何を作らないで、何を作るべきか」に全ては掛かっているのです。

最後に…Pivotal Labs Tokyo ではプロダクトマネージャーを募集しています(2020年8月時点)もしご興味があれば以下のリンクよりご応募いただくか、このサイトのコンタクトフォーム経由でぼくの方までご相談ください!お待ちしてます。

Product Manager: Pivotal Labs (VMware Tanzu) in Tokyo, Japan | main

プロダクトマネージャー Product Manager (Pivotal Labs) VMware Pivotal Labsについて1989年に設立されたPivotal Labsは、数々の大手企業に対してアジャイル型ソフトウェア開発のコンサルテーションを提供してきました。2019年にはVMwareの一部となり、今後はそのビジネスをさらに拡大、加速させていきます。 求める人材 …

はじめに

仮説検証学習サイクルを可視化するためのツールを「Experiment Board」と呼んでいます。2年ほど試行錯誤を重ねましたが、今は納得して運用することができているので、世のプロダクト開発をよりよくするためにも、参考になるかわかりませんが公開したいと思います。

なぜ、この Experiment Board が必要だと思ったのかと言うと、過去にこんな悩みがあったことがきっかけでした:

  • ユーザーリサーチの際に、過去の質問や検証内容と重複してしまうことがあって、時間の無駄だと思った
  • どこまでが未検証で、どこまでが検証済みだったかわからず、迷走することがあった
  • 価値ある学びやインサイトが多くあった場合に、まとめて管理したり記録する方法がわからなかった
  • 仮説検証学習のために実験を繰り返す習慣を身につけたかった

これらのモヤモヤを解消してくれたのが、Experiment Board でした。根底にあるのは、リーンスタートアップの「Build-Measure-Learn」のフィードバックループです。

Learn:思い込みや仮説、Build:実験、Measure:検証可能な指標

この図の通り、実験(Experiment)を通しての仮説検証の結果から得られる学びを切り取り、形式化することが鍵となります。

なぜ、実験なのか?

上記で「実験」という言葉を使いました。科学のように、仮説を検証するために積み重ねる実験は、正にプロダクト開発においても同じだなと思います。なので、仮説検証学習サイクル=実験と呼んでいます。

なぜ実験が必要かというと、プロダクトを開発する上で最も高いリスク、それはユーザーに使われないものを作ってしまうリスクを可能な限りなくすためです。リスクを低減するためには、早期に「いま」検討中ないしは開発中のプロダクトを試すことが重要であり、同時にその行程を管理し、修正していくことです。

あと、「リリースをする」という表現よりも「実験をする」と言い換えたほうが目的が明確で、意思決定のスピードや検証サイクルも早くなる気がします。心理的構えもなくなるので、安定します。

なにを、検証するのか?

左が課題の優先順位付を行う「2×2」、右が Experiment Board です

実験をはじめる前に、答えるべき問いを設定します。この問いに対する解を得るために、実験をします。問いは多きく分けて2つのカテゴリに分類することができます。

  1. ユーザー&課題
  2. プロダクト&ソリューション

(1)については、

  • 実際にユーザーは存在するか?
  • 解決「すべき」課題か?

などが代表例です。これらの問いに対する解を見出すことができれば(2)に進みます。

  • ソリューションは課題を解決するか?
  • 使いやすいか?

などが代表例です。これらの問いを検証可能な仮説に落とし込んで実験することで、以降はより詳細な仮説検証学習サイクルに進むことができます。仮説の設定方法については過去のエントリーが参考になると思います。

仮説駆動型UXデザインのススメ | mariosakata.com

先月末に NIJIBOX 主催のイベント …

どのような、流れで行うか?

プロダクト開発手法に左右すると思いますが、私が慣れ親しんでいるアジャイル開発では、イテレーションごとに以下の流れで実験を行っています。

イテレーションごとの流れ:

  1. 問いの設定
    ユーザー&課題について?プロダクト&ソリューションについて?
  2. アサンプションを洗い出す
    最もリスクが高い思い込みは何か?
  3. 仮説化する
    検証可能な仮説にする
  4. 実験方法を考える
    何を検証するためにやるのか?どのようにやるのか?
    例)ペーパープロトタイプ、ABテスト、ランディングページ、インタビューなど
  5. 実験する、試してみる
    どれくらいの期間やるのか?何人に対してやるのか?
  6. 結果を測る
    仮説は検証できたか、間違っていたか?
  7. 振り返って学びをシンセサイズ(統合)する
    何を学んだか?
  8. 繰り返す

実験は繰り返すものです。次に何を検証しようと悩んだ時には、以前ご紹介した「2×2」というフレームワークを取り入れてみるといいかもしれません。

2軸で考えるプロダクトデザインの シンプルな意思決定方法

9月上旬に、 UX MILK 主催の「 UX MILK Fest 2019」という大きなイベントに登壇させていただく機会がありました。「2軸で考えるプロダクトデザインのシンプルな意思決定方法」と題した当日のセッションでは 「2x2」という手法をご紹介しました。セッションでお伝えしたかったのは、この手法を取り入れることで、様々な角度から軸となる考え方を UX …

Experiment Board の例

先ずは準備です。実験を進めるための必要項目を記載していきます:

  • フェーズ(実験の回数やプロダクトのライフサイクルなど)
  • ペルソナ
  • 期待する成果(アウトカム)
  • 検証したい仮説
  • 実験方法
  • 成果指標(Key Result)
  • 学び

Google が主催したイベントに登壇した際にも紹介した、Experiment Board の事例です。ちなみにこれは、実際に Zappos が実践した実験そのものです。多少編集しています。

  • フェーズ:Beta
  • ペルソナ:レイシーさん
  • 期待する成果:ユーザーはいつでもどこでも靴を買うことが出来る
  • 検証したい仮説:ユーザーはオンラインで靴を買いたいだろう
  • 実験方法:オズの魔法使い
  • 成果指標(Key Result):50%のユーザーは一足以上の靴を買う
  • 学び:女性はドレスにあう靴をオンラインで購入する傾向にある

仮説があっていたかどうか、また指標が達成できたかどうかをステッカーを使って管理してたりします。赤はアラートなので、やり直す必要があるのか、そもそも辞めるか、といった決断をする材料となります。

Experiment Board の導入によって、いつ、誰に対して、何のために、そしてどのような実験をするのか?そして、その結果はどうだったか?この一連の問いをこの順番で可視化することで、論理的に物事を考えることができ、情報の整理が容易になりました。

仮説検証学習サイクルも回り続けます。

上記が一応テンプレートのような役割を果たしていますが、ホワイトボードに縦に貼り付け、その横に実験ごとの結果を記録していくだけでも済みます。実験の回数が多くなってきたら、エクセルでもいいので、デジタルに移行することをオススメします!

まとめ:やってみてよかったこと

インサイトや学びの抽出がしやすくなった

可視化のメリットはやはり大きいです。特に、今回ご紹介したようにホワイトボードなどを用いることができれば、何が検証できて、何が間違っていたのか、どのような学びがあったのかを項目ごとにすぐに確認することができるので、取りこぼしが減ったように思います。

次のアクションに繋げやすくなった

学びはチームを前進させてくれます。普段であれば、見ていないところや諦めているところをすくい上げて、新しい価値を見出すこともできます。他にも、ターゲットユーザーのアップデートであったり、課題の優先度の変更といった本質的な議論が展開されるようになります。それは、中長期的に見るととても有益な情報だったりします。

過去の実験がまとまっていることで自信がつく

プロダクト開発では、生産性に直結するアウトプットに注目することが多いです。でも、Experiment Board のようにこれまで実験した回数であったり学びの数が可視化されていると、それだけ良いプロダクトに向けて突き進んでいることがわかり、一人一人の自信につながり、チームの士気も上がります。このような質的なイニシアティブが得られることも、メリットの一つです。

早い段階でいくつかの仮説や思い込みが間違っていたことがわかる

最もリスクが高い思い込みを優先して検証可能な仮説に思い込み、実験によって検証することで、それがあっていたか間違っていたかを測ることが Experiment Board の目的です。一つ一つ潰すことで、安心感が得られるのも、いいところです。

全ては、実験です。このフレームワークの導入も、実験です。導入コストは圧倒的に低いので、ぜひやってみてください!