真に偉大で、革新的で、価値に富んだアイデアの根源は大きく２つある。それは、あなたのユーザと、あなたと共に働く人たちだ。"プロダクトマネージャ"の帽子をかぶった人がそうだとは限らない — Agile Greece Summit 2019で、Yariv Adan氏は、このように発言した。アイデアを実際の製品やテクノロジに具現化するには実験が有用だが、その前に何を試みるのかを決めなくてはならない。問題点を洗い出し、データを使用して、MVPを定義することが、イノベーションにおける成功のチャンスを大きくする上では有効だ。
我々の役割は、ユーザを重視した問題解決を行うことにある。必要以上にソリューションに拘るのではなく、ユーザにとって最良の方法で問題が解決できたかどうかを常にチェックするべきだ。そうすれば、新たなアイデアやニーズといったものは自ずと明らかになる、とAdan氏は主張する。"象牙の塔で自分たちが行うブレインストーミングでは、決して思いつかないようなアイデアやニーズはそこにある"。
組織の人々から得られるアイデアについて言うならば、その多くは上級者やプロダクトマネージャではなく、製品やメカニズムやユーザといった、過酷な現実に直面する人たちからのものだ、とAdan氏は言う。例えばそれは、比較的若いエンジニアであり、カスタマサポートであり、アカウントマネージャなのだ。
Adan氏が提案するマネージャの役割とは、組織内のデータとコミュニケーションのフローを確実にして、ジョブのレベルに関わらず、あるいはヒエラルキの各層においてフィルタされたり誤解されたりすることなく、企業が達成しようとしていることは何なのかを従業員が理解できるような、十分な戦略的コンテキストが存在することにある、とAdan氏は示唆する。
試してみる価値のあるアイデアがどれなのかは、試してみなければ分からない。Adan氏はそれを、"信頼に値する水晶玉をまだ持っていないから"だ、と表現する。ただし、成功のチャンスを大きくできるような、優れたプラクティスはいくつか存在する。
- ターゲットとするユーザの問題について、明確な枠組みを持っていること。起業家は往々にして、自分たちのソリューションの"クールさ" — 巧妙さや技術的革新性、あるいはデザインアピール — に、必要以上の執着を持つものだ。しかしながら、ユーザにとっての真の価値は、ユーザの問題を解決できるかどうかにかかっている。それが他の方法では克服困難なものであれば理想的だ。だから、ユーザにとってリアルで、大きく、さらに拡大しつつある、未解決な問題を明確にするところから始めることだ。
- データを決定通貨(decision currency)にすること。すなわち、進むべき方向を決定するものは、意見や階級ではなく、データでなくてはならない。これはつまり、(品質や関与、ユーザ満足度といった)測定可能な目標をターゲットとして定義した上で、試験においてそれらを測定可能な技術的インフラストラクチャを構築し、その測定値を最大にするようにプロダクトを最適化する、ということだ。当然ではあるが、健全な常識や批判的思考といったものも必要になる。
- これらを踏まえた上で、最も重要なのは、自らのMVP、すなわち最小限実行可能なプロダクト(Minimum Viable Product)を定義することだ。ターゲットとする中核的ユーザ価値に対して100パーセントではない機能やUIを排除することに、躊躇してはならない。バージョンを可能な限り早くユーザに手渡し、それを繰り返すことが必要だ。
ユーザの問題を解決しようとする場合の我々には、問題を必要以上に単純化する傾向があり、ソリューションが問題の一部にのみ対処していたり、考慮外であった別の問題によってブロックされたりすることが少なくない、とAdan氏は言う。しかし、"落胆することはない"と氏は言う。"問題とは、あなたの友人であり、あなたの要件であり、あなたの価値機会"なのだ。 特定のソリューションに必要以上に執着せず、問題に執着すべきだ、と氏は示唆する。
Google AssistantのプロダクトリーダであるYariv Adan氏は、Agile Greece Summit 2019で、Googleにおける大規模なイノベーションについて講演した。InfoQは、ユーザ問題の枠組みについて、氏にインタビューした。
InfoQ: どのアイデアを試すべきか、試験する価値があるのかを決定するためには、対象となるユーザの問題に対する明確な枠付けが重要だという話がありましたが、具体的に例をあげることはできますか？
Yarin Adan: 私がよく引き合いに出すのはGoogle検索です — 誰でも知っていますから。LarryとSergetが最初にGoogleをローンチした時、彼らのソリューションとその大きなイノベーションは、結果をランク付けする新手法にありました。まさに魔法だったのです。しかしすぐに、それだけでは十分ではないことに気付きました。ユーザは相変わらず、求めているコンテンツにたどり着けませんでした — ランキングとは別の問題があったのです。ユーザの検索クエリを調べたところ、ユーザがスペルを間違えていて、正しいコンテンツを得られていないことが分かりました。そこで彼らは、自動スペル補正機能と"もしかして(did you mean?)"をローンチしました。さらに、一部のユーザは単にクエリの方法が分かっていない、ということも分かったので、検索候補(search suggestion)をローンチしました。その後、いくつかのデータがwebから欠落している点にも気付いたため、マップ、ニュース、イメージ検索、書籍などをローンチしました。これらはいずれも最初の計画にはありませんでしたし、彼ら自身で思い付いたと言えるものでもありません。ですが、Google検索を現在の地位まで高めたのは、これらを含む多くのイノベーションなのです。問題を抱え込まず、ユーザに注意深く耳を傾けなければ、できなかったことです。
InfoQ: 実際のプロダクトやテクノロジにおいて、アイデアは、どのように生かされるのでしょうか？
Adan: 理想的には、アイデアや仮定を短期間で手軽にテスト可能な方法が見つけることで、プロダクトへの移行が可能になります。指針となる原則となるのは、可能な限り早い段階で、開発プロセスにユーザからのフィードバックを組み込んでいく(測定し、分析する方法を確立しておく)、ということです。これは、以下のいずれかの方法で実践できます。
- 小規模な定性的ユーザ研究を実施して、仮定を検証し、ニーズや製品、UIに対する直接的なフィードバックを獲得する — 簡単なプロトタイプとモックがあれば実現可能です。
- 中核的なユーザ価値のプレアルファ版を対象としたサニティテスト(sanity test)を、チームないし企業内部で実施する — スケールや配布や検出といったことの心配をせずに、さらには重要機能のブロックにならない既知の問題や不足機能を無視して、中核となる機能に集中することが可能になります。
- 数パーセントのユーザを対象として、運用環境で定量的なA/B試験を行う — 成功測定基準を監視し、最適化することができます。
一般的には、機能のフルローンチの前に、これらの2,3項目を行えばよいでしょう。
InfoQ: Googleでのイノベーションからは、どのようなことを学びましたか？
Adan: 次のようなことです。
- イノベーションを意識的に発生させることはできませんが、発展し、組織的に繁栄する環境を作ることは可能です。イノベーションを促進するには、企業規模で大きな投資を続けることが必要です。そこで重要な柱となるのは、
- 適切な人材を採用し、イノベーションを認識する。
- イノベーションのインスパイアを使命とする。
- エンパワーメント環境を持つ。これは最も重要な要素であり、私の目標でもあります。
- 優れたアイデアは、次のような方法で得られます。
- ユーザをプロセスに関与させる
- ユーザと、彼らの抱える問題を重視する
- プロダクトを早期にユーザに手渡して、フィードバックを得る
- 企業ないし組織をより広範にプロセスに関与させる。
- アイデアが自由にフロー可能な、オープンな環境を構築する
- データを決定通貨として使用する
- アイデアの追求を容認する
- 破壊を容認する — イノベーションは本質的に破壊的なものなのです。
- リスクテイクと失敗を容認する
- プロセスに柔軟性を持たせる
- アイデアに伴う軋轢を受け入れる