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

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の一部となり、今後はそのビジネスをさらに拡大、加速させていきます。 求める人材 …

プロダクトやサービス開発における様々なズレを解消するためのフレームワークの一つとして「キャンバス」があります。この記事を読まれている方であれば一度は耳にしたことがあるかもしれませんが、Business Model Canvas(ビジネスモデル・キャンバス)Lean Canvas(リーン・キャンバス)などが有名です。キャンバスは、複雑な情報を一枚絵に構造化してわかりやすくしてくれているので、意思決定を加速させてくれる非常に便利なツールです。

他にはどんな便利なキャンバスがあるんだろう?と興味本位で2〜3年かけて情報収集をしてみたところ、約200種くらいありました。時代の変化と共にインスピレーションを受けながら増えていったことを想像すると、多分もっとあるでしょう。それらは自身の Pinterest でコレクションとして今も集めています。キャンバス集めは、もはや趣味です。

その中にはあまり知られていないけれども、あらゆる課題を解決してくれるキャンバスが沢山埋もれています。ただ、あまりにも数が多いので、今回はその中でも自分の中でヒットだった5つのキャンバスをご紹介したいと思います。

  1. Social Media Strategy Canvas(ソーシャルメディア戦略・キャンバス)
  2. The Brand Canvas(ブランド・キャンバス)
  3. Team Canvas(チーム・キャンバス)
  4. Project Canvas(プロジェクト・キャンバス)
  5. Workshop Preparation Canvas(ワークショップの企画のためのキャンバス)

それでは一つ一つ見ていきましょう。

1. Social Media Strategy Canvas

ソーシャルメディアは今となってはビジネスにとってクリティカルな、かつゲームチェンジャーともなり得るマーケティングチャネルです。なぜなら、ソーシャルという文字通り、自社とクライアントやユーザーを繋ぐ大事な接点となっているからです。プロダクトマーケティングの観点からも、PSF(Product-Solution Fit)を探る上で重要な役割を果たします。

Social Media Strategy

Copyright © 2015 Marketing Solved

  • どのソーシャルメディアから始めればいいかわからない
  • どれが相性がいいのかわからない
  • 何を投稿すればいいかわからない
  • 以前かじったことがあるけれど、うまくいかなくて辞めた

このキャンバスは、上記のような身近な課題をシンプルに解決してくれます。プライベートではソーシャル・ネットワーク・サービスを使い倒しているけれども、事業戦略の位置付けでいざ初めてみるとなると、どうしたらいいかわからないときがあります。僕自身も以前 Facebook マーケティングをやったことがありますが、四苦八苦してしまい、今これがあったら便利だったんだろうな、と思いました。

このキャンバの考案者によると、3ヶ月もすれば効果が見え始めるとのこと。Twitter のフォロワーが何千人増えたとか、ソーシャルメディア経由の収益をデイリーで挙げることができた、とかとか。

キャンバスにまとめられている項目一覧:

  • ユーザー情報(デモグラに加えて、好むブランドや興味など)
  • 月間目標(何を達成したいか、何をPRしたいか)
  • 目標を達成するための月次・週次・日次タスク
  • 投稿する内容やコンテンツ
  • 投稿するタイミング(過去のデータを元に最適化)
  • 投稿する頻度
  • 投稿先のプラットフォーム

テンプレートのダウンロード:

How To Create a Fail Proof Social Media Strategy That’s Simple and Gets Results – Marketing Solved

If you’ve decided it’s time to get serious about social media, I’m here to tell you – YES, it is time! Social media has been a real game changer for businesses and for one reason, it’s SOCIAL. It really is the connection between you and your future clients.

2. The Brand Canvas

ブランド戦略という言葉を耳にすることがありますが、ブランドの範囲がかなり広いため、どのようなアクションが求められ、実行されるべきなのかイメージが湧かないときがあります。

ブランドと聞くとロゴ、つまりは CI を真っ先に想起しますが、モノよりもコトの時代となった今、Apple Watch に代表されるようにシンボルだけではなく、人の生活をより豊かにするためのストーリーであったり、人々の生活に根付いたコミュニケーションが求められます。

Lean Branding Canvas

Copyright © IGNITION Framework

このキャンバスは、それらを構成する要素を細かく分解して一つのブランドを作り上げることができると思います。ガイドラインに等しい項目もあるため、デザイナーやマーケティングの部署と協業しながら埋めていくといいかも?

キャンバスにまとめられている項目一覧:

  • ストーリー
    • プロダクトが置かれているポジション(インセプションデッキのような扱い)
    • 顧客への約束ごとを一言で
    • ブランドを擬人化した時のパーソナリティ
    • ペルソナ
    • ストーリーボード(ソリューションがユーザーの目標をどのように助けるか)
  • シンボル
    • タイポグラフィ
    • カラーパレット
    • ロゴ
    • 使用する画像
  • 戦略
    • 認知度向上のための施策(チャネルやコンテンツなど)
    • 収益につなげるための施策
    • マイルストーン(メッセージを発信するタイミングなど)
    • 継続的なコミュニケーション手段(シェアの促進など)

テンプレートのダウンロード:

The Brand Canvas – How To Create and Communicate A Compelling Brand – Ignition Framework

Why does Apple’s brand mean so much to so many people? How is it that they seem to sell their products almost effortlessly while other manufacturers are constantly clamoring for our attention and we give them no heed? When it comes to innovation, invention is only half of the equation.

3. Team Canvas

チームワークはプロダクトの成功を左右します。

全社のミッションやプロダクトの戦略を共有することはチームのコミュニケーションを円滑に進めるために、最低限必要であることは誰もが認識していることだと思いますが、実は普段会話しない内容がチームワークを良くする上で大事だったりするのではないでしょうか。これは僕の経験なのですが、個人には強みや弱みがあり、やりたいこととやりたくないことがあり、それを理解せずに進めてしまうと本当のチームとして機能(ワーク)しないことがあります。僕自身もやりたくないことがあるので、それは周囲に明示するようにしています。

Team Canvas

Copyright © 2015 The Team Canvas

そこで目に止まったのが「Team Canvas」です。これはワークショップ形式で、約1時間ほどかけてチーム全体でまとめると効果的だそうです。結構踏み込んだ会話が求められるので、アイスブレイクも兼ねて進めるといいかもしれません。

キャンバスにまとめられている項目一覧:

  • チームメンバーと役割
  • チーム共通のゴールと個人としてのゴール
  • 目標を達成するために活かせる強みやソフトスキル
  • チームと個人の弱みと直面しうる課題
  • チームとしての行動規範
  • 個々のニーズやチームへの期待
  • チームが大切にすべき価値
  • 目的(なぜしているのか、何をしようとしているのか)

テンプレートのダウンロード:

Learn about Team Canvas – Team Canvas

Years of observing, leading and consulting small teams made us realize that it’s not the lack of knowledge that makes effective teamwork so hard. It’s the hard questions themselves that are not being asked at the right time.

4. Project Canvas

「Project Canvas」は、プロジェクト全体におけるコミュニケーションをシンプルに、そして明確にするためのキャンバスです。プロジェクトのキックオフや、プロジェクト途中のチェックイン、そして振り返りの際に利用することを想定されています。インセプション・デッキと重複する要素はあるものの、正式文書ではなくビジュアル化することで、相互理解を促すことができるのでいいなと思いました。

Project Canvas

Copyright © 2016 Project Canvas Creators

これも自身の経験ですが、過去のプロジェクトではこのキャンバスと似たような項目をワークショップを通じて外部化したものをプリントして、壁に貼り付けたりしました。データとして格納するよりも、目に見えるところにあるとプロジェクト中に迷子になりづらいので、おすすめです。また、希かもしれまぜんが、複数のプロジェクトにアサインされている状態の場合、より効果が発揮されるかもしれません。

キャンバスにまとめられている項目一覧:

  • プロジェクトの目的
  • プロジェクトのスコープ
  • 成功指標(プロジェクトの成功を定めるための指標)
  • 主要なマイルストーン
  • 主なタスク(やるべきこと、方針など)
  • アウトカム(最終的に成し遂げられるもの、成果)
  • チームメンバー
  • ステークホルダー
  • ユーザー
  • リソース(予算など)
  • 制約事項(外的要因による弊害など)
  • リスク

テンプレートのダウンロード:

Project Canvas – Visual project communication and overview

Project Canvas is made by project facilitators and project management professionals, who seek to simplify the challenge of project communication – before, in and after project execution: project kickstart: pitching and project initiation. project overview: project briefing and status. project management: task assignment and project progress.


5. Workshop Preparation Canvas

過去にワークショップを企画並びに実施した経験はありますか?

その時その時の関係者を巻き込みながら、プロジェクトを効率的に進める上で様々なワークショップを開くことがあります。ワークショップの落とし穴は、ただ楽しいで終わってしまわないことです。楽しいのはいいことなのですが、目標が達成できたかどうかがワークショップの成功を判断する上で重要となります。このキャンバスでは、ワークショップを成功させる上で必要な「6つのP」をまとめてくれています。

Workshop Preparation Canvas

Copyright © 2018 Toby Sinclair

ロジスティックな部分など、基本中の基本についての明記を促していますが、疎かにしてしまうことがたまにあるので埋めておいて損はなさそうです。

キャンバスにまとめられている項目一覧:

  • Purpose(目的、なぜやるのか?)
  • Practicalities(いつ、どこでやるのか?どのようなセットアップでやるか?)
  • Participants(参加者はだれか?各人のニーズは何か?)
  • Products(事前に準備すべきものは何か?題材は何か?)
  • Process(アジェンダは何か?)
  • Principles(どのように意思決定が行われるか?ワークショップの価値は?)

テンプレートのダウンロード:

Workshop Preparation Canvas

“Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” ― Abraham Lincoln I have run many workshops and by far the most important part to a successful workshop is the preparation. From my experience a one day workshop requires at least three days preparation and maybe…

番外編:ユニークなキャンバス2選

以上、キャンバス・コレクターの僕がオススメする5つのキャンバスでした。本当はもっと紹介したいのですが、たださえ長い記事なのに、更に長くなってしまうので最後に2つだけ、番外編としてとてもユニークなキャンバスをご紹介します。もはやプロダクトやサービス開発に関係がないかもしれませんが、悪しからず。

Negotiation Canvas(ネゴシエーション・キャンバス)

誰かとネゴシエーション(交渉)するときに、自身の考え方を整理するのをサポートしてくれるキャンバスです。みんながハッピーになり得るアイディアを複数考え、上手くいかなった時の対処法まで考えるというバックアップ付き。

Check out Negotiation Canvas, a free workshop template!

One-page tool for success in any negotiation.

Life Canvas(ライフ・キャンバス)

その名の通り、人生について考えることができるキャンバスです。自身のビジョンやスキルが世界のニーズとマッチしているかどうかを測るために活用することができますが、今話題の Ikigai についても触れられているので個人ワークでやってみる価値はありそうです。

The Life Canvas

The Life Canvas is a framework that provides a simple, visual method of defining, understanding, and utilizing your unique capabilities and desires to build the future of your dreams.

まとめ

こうやって一つ一つのキャンバスに目を通してみると、キャンバスというフレームワークはとても奥が深いです。

今回のように、高度な思考技術によって整理された構造をリバースモデリングすることで、意図が汲み取りやすくなり自分自身の頭の整理にも役立ちます。また、いざ埋めようとしても、埋められない項目があったりします。つまりそれは、情報が欠落しているということです。欠落しているということは、失敗する可能性があるということです。キャンバスのいいところは、一枚絵にすることで、欠落した情報を見逃すことができないところだと思います。

一つでもいいので、試しにやってみませんか?

もし、微妙だな〜と感じられた方がいれば、実用性が比較的高い以下のキャンバスから始めてもいいかもしれません。実際にやってみましたが、難易度は高めです。

はじめに

仮説検証学習サイクルを可視化するためのツールを「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 の目的です。一つ一つ潰すことで、安心感が得られるのも、いいところです。

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

この記事では「ローマ式投票法(Roman Vote)」という意思決定を支援するためのアクティビティの一つをご紹介します。ローマ式投票法の導入によって、チームは様々なメリットを得ることができます。チームのコンセンサスが得やすく、サポートしあえる関係を構築できたり、チームの心理的安全性を担保できる、など。みなさんは、普段からどのように周囲のコンセンサスを得ていますか?

意思決定の場でよく起こること

複数人で何か意思決定をするときに、困った経験は誰にでもあると思います。それが例え仕事だとしても、プライベートだとしても。さぁ、意思決定をしようとするときに静かになる。そこで口にする「みなさん、これでいいですか?」それに対して、コクリと頷く人もいれば、異論がなければそれは賛成という都合のいいように解釈して、その場を締めちゃうなんてことはありますが、それは周囲のコンセンサスが得ているとはとても言えませんよね。

どうすればもっと効率よく合意することができるのか?よくある模範回答は以下の2つではないでしょうか。

  1. 多数決によって決める
  2. 相談や話し合いの場を設けて偉い人が決める

これでもし、周囲のコンセンサスを得ることができたのなら、それは嬉しいですよね。二人とかだったら争いはないのでしょうけど、それがプロジェクトチームのように複数人が関与していた場合、多くの意思決定の場が懸念点の洗い出しやアイディアの出し合いで終わってしまい、次に持ち越されることもしばしばあるのではないでしょうか?私はよくありました。「また別途お時間を調整して相談させてください」は一時、私の中での流行語大賞になっていました。

「賛成」や「反対」の文脈で許容してしまうと、結果に対するサポートであったり、より良い提案が生まれにくくなってしまいます。決定事項に対して納得して熱量が半端ない人もいれば、しらけている少数派の人だっているでしょう。このような意思決定方法論が続くと、中長期的に見るとプロダクトや組織に関する課題は徐々に表面化してくる恐れがあります。

そのため、最適なアプローチはどれほどのコンセンサスが周囲から得られているのかを見える化することにあり、最終的な意思決定の前に不明点や反対意見をも受け入れることです。ここでご紹介する手法は「ローマ式投票法(Roman Vote)」です。

ローマ式投票法とは?

古代ローマでは、剣闘士であるグラディアトルが戦った闘技会のコロッセウムにて、その場を埋め尽くしていた民衆の意見を「Thumbs-up」または「Thumbs-down」で判断し、意思決定をしていたと言われています。20年ほど前に公開された映画「Gladiator(グラディエーター)」で、当時のローマ皇帝が敗北した剣闘士の始末を決定する際に、これを用いているシーンがあります。

  • Thumbs-up(親指を立てる):賛成します、または受け入れます
  • Thumbs-side-ways(親指を横にする):マジョリティの意見に乗ります
  • Thumbs-down(親指を下向きにする):受け入れません、意見があります

もし全員が Thumbs-down だった場合、その案は却下ですよね。もし、複数の意見が対立した場合、Thumbs-down の意見をまずは聞いて同意した内容について振り返りを行います。そうすることで、Thumbs-up がマジョリティでも Thumbs-down が複数見られる場合は、その意見を参考にする機会が与えられます。但し、大半が Thumbs-side-ways だった場合は注意が必要です。あまり参考にならないことが多いです。どちらでもないが多いと、論点の再整理や条件の見直しを推奨します。

ローマ式投票法の流れ

ローマ式投票法は実はプライベートな場でも用いることができます。ここでは、高校時代の同級生5人と一白二日の旅行を計画するときのシチュエーションを想定したときの、ローマ式投票式の流れをご紹介したいと思います。

  1. ファシリテーターを決める
  2. 決めたい内容の共通認識を合わせる
  3. 前提条件を整理する
  4. 会話のための時間を設ける
  5. 意思決定に必要な情報を整理する(候補など)
  6. ローマ式投票法で決める

ファシリテーターは旅行をしよう!と提案した人です。わかりやすくFさんとしましょう。Fさんは、来週末の旅行先を決めるために、4人をカフェに誘いました。Fさんは先ず、集まってもらったメンバーに趣旨を伝え、移動手段や一人当たりの予算を提案します。それを聞いてメンバーは旅行先の候補を挙げていきます。行動範囲、混雑状況、当日の天気などから絞られていきましたが、会話が行ったり来たりで収集がつきません。幾つか優勢な案が出たところでFさんは会話を切り、ローマン式投票法を実施することにしました。

Fさん「では、旅行先を軽井沢にするかどうかで、みんなの意向を聞きたいと思います。では、せーのって言ったら親指を立てるか、横にするか、下げるかで教えてください。いいですね?では、せーの!」

(親指を立てた人:二人、親指を横にした人:二人、親指を下向きにした人:一人)

Fさん「割れましたね〜。まずは親指を下向きにした人の意見を聞いてみましょう。それを踏まえて、横にした人の考えも聞いてみたいと思います。では…」

ビジネスの現場はこんなに軽くないですが、一通りの流れとローマン式投票法の意味についてご参考になると嬉しいです。

ローマ式投票法をプロダクト開発に取り入れる

これはプロダクト開発を進める上で、日々の小さな意思決定をする場でも役立ちます。デザインコンセプトを決める場であったり、バックログの優先順位をチームで合意するときであったり。決定が明確なシチュエーションにおいては毎回実施しなくてもいいと思いますが、ポイントは周囲の、みんなからのコンセンサスが十分に得られているかどうかです。

コンセンサスが得られているということは、周囲からのサポートが得られるということです。例え、それが反対していた案であったとしても自分の意見をも受け入れた上での結果であれば主体性が生まれます。最近よく心理的安全性という言葉を聞きますが、それに近いと思います。

いずれ、ローマ式投票法が要らなくなる状態に持っていくことが、チームとして目指すべき姿なのかもしれませんね。

導入にあたってのアドバイス

もし、ローマ式投票法に興味があるのであれば、最後に二つのアドバイスがあります。

  1. なるべく早い段階で取り入れることを推奨します。なぜなら、既に特定の人物によって意思決定の場が支配されている場合は、あまり効力がありません。時間が過ぎれば過ぎるほど、チームのコンセンサスが得にくくなります。振り返りになりますが、そうなると、チームはどうなるでしょう?
  2. どの場でも取り入れようとしないこと。時間などの期限を設けて、それまでに明確な意思決定ができなかった場合にローマ式投票法を用いると、客観的に見ることができるのでオススメです。ローマン式投票法だけでしか決めれないチームは、逆に疑った方がいいかもしれません。

個人的に学んだのは、ローマ式投票法は全てを解決してくれる訳ではないということです。最も重要なのは、自分自身が下した意見から一歩引いて、見る姿勢を持つことです。頑固はよくないです。チームで前に進むためには、頑固者はいない方がいいです。

この空気に任せる曖昧な意思決定に終幕を!

プロセスやツールよりも個人と対話を

アジャイルソフトウェア開発宣言の一文です。アジャイル開発を継続するための重要なファクターの一つに、コラボレーションがあります。同じ場所(環境)に身を置くことで、より高い生産性とより早い意思決定が可能になることは既に多くの研究や事例によって明らかになっています。私がいる会社でもそのようなモデルでクライアント・ワークをしていますが、私もそう思います。

ただし、それはオフラインに限った話であって、今回のようにコロナウイルス(COVID-19)の拡大に伴う在宅勤務の推奨によってオンライン環境を余儀なくされた場合はどうすればいいのでしょう?私自身も初めてだったため、戸惑いはありました。それは自分だけではないと思います。生産性も落ちました。ただ、それはある意味オンラインにおけるコラボレーションは本当に有効であることの裏返しでもあります。むしろ、視点を変えればリモートワークはアジャイルなチームと相性が良いのではないか、とも思うようになってきました。これは錯覚なのでしょうか?確かに外の空気をたまに吸いに出ないと頭がおかしくなりそうなときはありますが、そうではないと願いたい。

私の場合、リモートワークはプロジェクトの開始とほぼ同時に始めたため、幸いにもいろいろ試行錯誤をする余地がありました。結果、比較的効果が見込める取り組みがいくつか見えてきたので、参考になればと思い、いくつかご紹介したい。

何ごとも優先度をつける、徹底的につける

これは何もバックログに限った話ではなく、ユーザーリサーチのためのリクルーティングや日々のTodoまで、チームとして、または個人として今優先すべきことは何か?と問い続けることで、価値を見失わないでいられる効果があります。

リモートだとどうしても一定の距離ができてしまうため、ある種の「許し」が無意識に生まれてしまう。ペースを維持しようにも、心情が相手に伝わらないときがあります。そのときは、私が率先して「嫌な役」を演じ、優先度が徹底されているか、チームに問うようにしています。悪いことはしていない(と思う)。より悪くならないようにしているだけ。

小さなチームで柔軟に動く

現状、クライアントとのコミュニケーションは常に Zoom で接続しながら進めています。そんな働き方です。元々オフラインではコミュニケーションコストがかかるため、大勢の人を招いたミーティングを開催しないように調整はしていますが、オンラインになるとそれが途端に楽になります。MAX 8人までで、良く接続するメンバーは4人と抑えているため、必要であればプロジェクトのロードマップも変更しますし(これは最近あった)、アイディエーションもその場でやってしまうこともあります。

オンラインに移行したことで、多くの人は気付き始めたのではないでしょうか。メールって何でこんなに面倒なんだ。このミーティングって必要なのか?多くはなくても成立します。

先を見据えて計画立てて動く

これはプロダクトマネージャーとして気をつけていることなのですが、オンラインで繋ぎながら作業をしていると、オフラインよりも集中力を使うため、つい手元の作業に没頭してしまいがちです。

何のためにやっているのか?最終的なアウトプットは何か?ミーティングだろうが、作業だろうが、ゴールとアウトプットの認識が揃っていなければ、共通のビジョンに向かって歩むことはできません。それを常に頭に入れ、逆算して組み立てるようにしています。それができていないと、たださえ公私混同しがちなリモートワークでだらけてしまい、つい残業、なんて目に見えています。

チームメンバーに奇想天外な役割を与えてみる

役職や職種としての役割ではありません。どちらかと言えば、チームビルディングの一環として取り入れる文化的要素に近しいです。

私がいるチームでは、以下の役割をそれぞれに割り振り始めています。名前のセンスはさておき:

  • 仕分け人:チームが不必要な話題に時間を費やしている場合にカットインする人。「それ、あとにしましょう」な人。
  • タイムキーパー:そのままの意味で、チームで行う様々なアクティビティの時間を管理する人。時間を過ぎたら容赦なく切る人で「はい、タイムアーップ!」が口癖。
  • Zen マスター:チームメンバーの疲労具合を見て休憩するタイミングと時間を決める人。この人の発言には注目だ。「とりあえず、休憩しますか?(^ ^)」救われる。
  • エンターテイナー: 一番ハードルが高いのだが、チームの雰囲気を明るくするための取り組み(ゲームやソフト)を紹介する人。最近、私は Snap Camera をチームに導入して大ヒット中。

順調そうに思えるが、苦労するポイントはたくさんあります。最も難しいと思ったのは、メンバー間の Empathy(共感)です。リモートという環境要因もあると思いますが、オフラインのときとは違い、口数が少なくなったり、思うように聞こえなかったりすることでイライラしやすくなった人もいます。

私も場合によっては当てはまるかもしれませんが、相手が今どのような状況下にいて、どんな心境でこの話を聞いているのかを理解してあげなければ、伝わるものも伝わりません。

Transparency(透明性)の維持。これも難しい。オンラインだとどうしても構えてしまいます。正面を向いているからでしょうか。初対面の人との会話だと、面接のような空気を醸し出すときもあるし、無駄に緊張してしまうこともあります。その場合、思っていることや考えていることは発信しにくい。それを回避するために、どうでもいい話題を投げかけてみんなが参加できる安全地帯を作ってあげることが大事だったりしますl。

そう、リモートワークで大事なのは、1) 人を思いやる優しい心2) 安全地帯の確保なんだと思います。ハードよりも、ソフトだと思います。

僕がいるんだ、みんないるんだ、愛はここにある、君はどこへもいけない。

どうでもいいけど、リモートワークを8時間も続けていると、Zoom に接続する度にリンクスタート!している気分で、ある意味気持ちがいい。

プロダクト開発に携わっている人であれば、MVP という単語を一度は耳にしたことがあるかもしれません。これは最優秀選手を表彰するときの名称ではなく、起業家であるエリック・リース氏が彼の著書『リーンスタートアップ』で紹介したコンセプトです。彼の著書が出版されてから8年も経っていますが(いま調べて驚き)、プロダクト開発を続けていると、MVP という言葉だけが一人歩きし、誤った理解や解釈がそのままに、現在に至ってしまっているように思います。その理由は後ほど。

問題は、MVP の訳し方にあったと考えます。MVP は Minimum Viable Product の頭文字をとったもので、Wikipedia で以下のように訳されています。

実用最小限の製品(じつようさいしょうげんのせいひん、Minimum Viable Product、MVP)は、初期の顧客を満足させ、将来の製品開発に役立つ有効なフィードバックや実証を得られる機能を備えた製品のバージョンを指す。

別の言語のニュアンスを細かく汲み取って、万人が理解できるように意訳することは難易度がとても高いです。私の場合も『Lean UX』という書籍の監訳を担当させていただきましたが、どうしても「最小限」という単語が印象的なのか、組織にとって都合がいい言葉なのかわかりませんが「最小限の機能を搭載した製品」のことを指す言葉として使われることが多い印象を受けます。

このようなシーンを目の前にしたことがあります。

新規サービスを立ち上げることになりました。様々なステークホルダーの協議した結果ぎ開発したい機能リストとしてエクセルにまとめられていて、その中でも優先順位が高いものには「高」というラベルが付けられています。それも、約3分の1が「高」だったりします。最悪なケースは、機能価値が未検証のまま優先度が割り振られているときです。根拠がないとなると、更にヤバイ。この「高」に分類されているのが、MVP だと言い張る人がいます。そもそも「中」とかあると、曖昧すぎてよくわかりません。

MVP の V を「実用的な、実行可能な」として直訳することができますが、これはサービス提供者視点ではなく、ユーザー視点に立ってみると、捉え方が変わってきます。誰にとっての最小限なのでしょうか?機能的な最小限を意識しすぎてしまうと、何の価値もない出来の悪いプロダクトになってしまうことがあります。

ああ、だから新しい手法を取り入れると失敗するんだよ。

このようになってしまいます。ポイントはユーザーの立場から見た場合の実用的なプロダクトとはなにか、を考えてみることです。

実用的、という言葉が意味するところを説明するのは大変難しい。そのため、私はよくこの絵を見せて関係者の理解を得ようとしています。

 

元々は米コンサルティング会社に勤めているアジャイルコーチがブログで紹介した図から来ています。この人は MVP を正しく理解するために Viable を Usable / Loveable と置き換えていることが素敵です。

このユーザーは、いまいる地点から目的地まで移動するまでにかなりの時間がかかってしまっています。不便ですね。MVP を最小限の機能と認識し、機能単位でプロダクト開発を進めていくと、最小限の線引きが時間の経過とともにわからなくなり、実用性を高めるためにはつくりきるしかなかったりします。それが上段です。

一方で、下の段のスケートボードはユーザーが抱える問題への最初のアプローチとして、ユーザーがそのプロダクトに価値を見出してくれているかどうか、日常生活において実用的かという観点で検証をすることができます。まだまだ満足ではないかもしれませんが、ユーザーが価値を見出せて課題の解決に至りそうなのであれば、移動時間を短縮するための次のアイディアにステップアップすることができます。

MVP には目的があります。リーンスタートアップという開発手法の一部なのだから、一人歩きは危険です。最小限の機能は作れた。MVP は完成だ。これで一区切り、なんて終わり方はしてはいけません。もしそうなっていたら、誰にとっての最小限であって、誰が喜ぶ MVP なのか、を再確認したほうがいいかもしれません。

Tips: 機能リストがもし手前にあるのであれば、そのリストを半分に減らしてみてください。そして、更に半分にしてみてください。そこから始めてみましょう。

はじめに

9月上旬に、 UX MILK 主催の「UX MILK Fest 2019」という大きなイベントに登壇させていただく機会がありました。「2軸で考えるプロダクトデザインのシンプルな意思決定方法」と題した当日のセッションでは「2x2」という手法をご紹介しました。セッションでお伝えしたかったのは、この手法を取り入れることで、様々な角度から軸となる考え方を UX デザイナー含めチーム全員が持つことができ、優先順位を徹底してプロダクト開発に関わるすべての意思決定をすることができるということです。

結果として、ステークホルダーや他のメンバーになぜ、その決定に至ったのかがロジカルに説明しやすくなり、説得力が生まれ合意形成がこれまで以上に効率化されます。この記事では、当日のセッションの様子を振り返ります。導入のハードルは低いと思いますので、当日参加できなかった人にとっても、お役に立てれば幸いです。(プレゼンテーションのスライドはこちらでもご覧いただけます)

なぜ 2×2 か?

このテーマを取り上げたいと思った背景には、以下の課題を多く耳にすることがあったからです。

開発したいデザインアイディアやソリューションが多すぎて、どこから着手していいかわからず、UX デザインが組織に浸透しづらい…。

2x2は、まずはじめに何を着手すべきかをチームで意思決定をする手助けをしてくれる手法です。 この2x2という手法を用いることで、UX デザイナーのみならずチーム全員が意思決定に関わることができ、ユーザー視点を維持することができるようになることで、上記の課題を解決してくれます。

2×2 の特徴

2x2は四象限のマトリクス構成になっています。意思決定をする際に必要となる観点を2軸(縦と横の軸)に設定することで、対象となる要素をセグメントごとにマッピングし、まずやるべきことをロジカルに決めることができます。これは、優先度を決めるときに効果を発揮します。

2つの軸で意思決定の対象となる要素を相対的にマッピングするとこのようになります。この絵では、4つの各セグメントごとの意味を説明しています。当然ながら、右上にあるセグメントはそれぞれの軸にとって優先度が高い要素が集まっているので、やらない理由はありません。逆に言えば、左下にあるセグメントは優先度が低いため、前述したデザインアイディアやソリューションはやらない方がいいという判断ができるようになります

ケーススタディ:ユーザーリサーチからアイディエーションへ

実際のプロジェクトでは、ユーザーリサーチの結果からアイディアを創出するために以下の2軸を設けて整理することができます。

ユーザーリサーチの結果であるインサイト(課題)をカードに書き出し、それぞれのセグメントにマッピングしていきます。尚、このときはチーム全員が参加することを推奨しています。なぜなら、マッピングには様々な角度から物事を捉え、優先順位を決める必要があるからです。

次に、解決すべき優先度が最も高いユーザー課題を対象に、アイディエーションのステージへと移っていきます。弊社ではデザインスタジオと呼んでいますが、プロダクト開発に関わるチームメンバー全員が参加し、ユーザー課題を解決するためのアイディアを発散する時間を設けます。

今度は以下を軸として、開発するソリューションを決めて次に進みます。

  • 縦の軸:ビジネス・インパクト(または価値)が高い / 高くはない
  • 横の軸:実現性が高い / 高くはない

2x2を用いることで、優先順位が高いユーザー課題とそれを解決するための最善のリューションが決定しました。今回はプロジェクトの2つの状況下における優先度づけと意思決定の一例をご紹介しましたが、軸は臨機応変に変えることができるため、プロジェクトのどのフェーズにも適応可能です。例)リスクが高い / 高くはない、確度が高い / 高くはない

2x2をより効率的に進めるためのアドバイス

  1. 右上に偏らないようにする
    よくあるケースは、すべてが大事と思っているが故にポストイットのほとんどが右上 偏ってしまうことです。2x2はあくまでも相対的なので、各セグメントに同じ数のポストイットを貼るように意識するとうまくいきます。
  2. 高い・低いといった二極化した表現を多用しない
    例えば、低い/少ないと言い切ってしまうと、そのセグメントにポストイットを貼るときに 戸惑ってしまいます。ステークホルダーによっては反発をくらいます。高くない/多くないといった 表現を用いることで、対立緩和を促すことができ、効率がよくなります。
  3. ポストイットを重ねない
    ポストイットを1枚1枚ボードに貼っていく際に、同じ優先度だからといってお互いを重ねないこと。必ず、ポストイットの上か下か、左か右に貼るようにして優先度の設定を徹底しましょう。
  4. まずは縦軸で整理し、そこから横軸で整理する
    いきなりそれぞれのセグメントにポストイットを貼っていくのは難しい作業です。 まず、縦軸に従って上から下まで一列で優先度を決めることをオススメします。そのあとに、 横軸に従って左右に貼っていくとスムーズにいきます。

まとめ:2x2を取り入れることによって得られた成果

積み上がったデザインアイディアやソリューションを計画的かつ論理的にアプローチする方法がなければ、半ば強引に社内政治や声が大きい人の判断で決まってしまって、結果ユーザー視点が抜け落ちてしまったりすることがあります。それでは、デザイナーの価値が十分に発揮されなくなってしまい、ユーザー視点を取り込むことは難しくなるでしょう。

  1. この手法を取り入れることで、対立する様々な軸とバランスを取りながら優先度を設定することができるため、なぜ、その決定に至ったのかがロジカルに説明しやすいため、プロダクト開発に関わる全ての人の理解が得やすくなりました。
  2. 「この機能を追加して」といった急な相談や依頼が来ても、2x2を組み直したり、他の要素と相対的に比較して着手する順番を改めて決めることができるため、優先度の取り引きが可能になりました。結果として、チームも柔軟に対応できるようになったと感じます。

前述したように、導入のハードルは低いと思いますので、ぜひ身近なものから少しづつ挑戦してみてください。無駄のないユーザーのためのプロダクトを開発するために、常に優先順位を徹底してみましょう!