Sam、本日はお招きいただきありがとうございます。Samと私は古くからの知り合いで、出会ったのは彼が新進の起業家だった頃でした。
本日の講義で話してほしいと彼から頼まれたのが、プロダクト作りにおけるハードウェア面についてです。
まず、私たちがしていること、私たちが世界をどう考えているか、それに基づいてどのようなプロダクト作りをしているかといったJawboneの概要を少しご説明したいと思います。
次に、私たちの設計や開発、そしてカテゴリを変えながらそれらをいかに一体化させているかというプロセス面についてお話ししたいと思います。
私は常に大局的な思考からスタートします。私たちの世の中の捉え方として、機能性、そしてデザインという点においても、それらを超えたユーザーにはほとんど見えないエンジニアリングにおける実に精巧なイノベーションの交点に今私たち自身がいると考えています。
私たちはプロダクトの設計に10年以上携わっていますが、人々が口にすることはデザインをも超えて美しさにシフトしていると思います。つまり、今やエンジニアリングと美しさがある一点で交差しているわけです。一番大切なことは、人々がテクノロジーを活用してより良い生活を送るサポートをすることにあります。
大まかに言いますと、私たちは今でいう「モノのインターネット（IoT）」という世界で、このIoTという表現が生まれる前から活動しています。私たちが扱っているのは、コンピューティングパワーとあらゆることを測定するセンサーとの連結性を兼ね備えたスマートデバイスです。
それらのデバイスはワイヤレスで接続され、いずれもユーザーに話し掛けてきます。私たちがこの道を志したのはかなり初期の段階で、当校（Stanford大学）の工学部を卒業した直後でした。そこで開発していたコアテクノロジーを軸に消費者プロダクトを開発しようと決意しました。
私たちが最初に開発した消費者プロダクトはウェアラブルコンピュータとなるヘッドセットでした。これは初の持ち運び可能なヘッドセットで、この時から私たちはウェアラブルコンピューティングについて考え始めました。
次に開発したのがBluetoothとオーディオを利用したワイヤレススピーカーでした。その経緯については後ほどお話しします。
最近力を注いでいるのが、ウェアラブルを活用した健康革命と、第一世代のヘッドセットで行った多くのセンサーの活用、そしてユーザーをより良く理解するために身体の様々な部分へそれらを応用することです。
私たちが長年いるこの世界は、今ちょっとした混乱期にあります。
IoTの世界では、あらゆるものがスマート化し、連携され、アプリが搭載されていますが、それはユーザーにとって快適という意味ではありません。
皆さんが使う電子レンジや冷蔵庫、車、Xbox、ComcastのXfinityなどあらゆるものにアプリが搭載されています。それらは互いに応答し合うことはありません。
これはユーザーにとって実に厄介です。
それらすべてを統合するための原則が切実に求められていると私たちは思いました。このことは私たちがプロダクトを創り出す機会をいかに生み出すかを考える際の中核となっています。
世界はどこに向かっているのかを考えてみるのです。IoTを誰もが口にするような世界が訪れるとしたら、もうすでにそうなっていますが、ユーザーがこれらのサービスがどのように機能し連携するのかを容易に理解できるよう、それらを統合する原則が確実に必要となります。
つまり、これは実際のモノは極力少なくしようとする考え方から個々のユーザーにもっとフォーカスしようとする考え方へのシフトだと思います。
ウェアラブルが世間の話題となり、Google GlassやApple Watchなどのプロダクトが出てくると、常に体に装着している物はそのユーザーを取り巻く世界のあらゆるものに関する完璧なコンテキストエンジンになると私たちは考えています。
私の携帯電話は体に装着されていません。ジャケットに入っているか充電器につながれています。しかし、私のUPは体に装着されています。装着者の心拍数や呼吸などを記録するUPは、現在起きているあらゆることを理解しています。
コンテキストエンジンに関しては、私はNestのスマートサーモスタットに暑いか寒いか言うことができますが、デバイスはそれを理解しません。私は「暑い」と言えますが、デバイスは私が暑いのは病気だからか、走ってきたからか、外が暑いからかということまでは識別できません。私は皆さんの車に、皆さんが居眠りしているか、興奮しているか、イライラしているかを言うことができます。
これがつまり、私たちが考えている世界の向かう先です。
ウェアラブルは、連携されたスマートな機能を持つあらゆるものに関するこの革命の中心になるでしょう。私たちは、こうした多くの相互作用が何をもたらすか、どのように機能するかを追求しているのです。「物事はどこに向かっているのか？」、「私たちは何を作るべきか？新たなカテゴリに関してどう考えるべきか？」ということが私たちの考える第一原則なのです。
このビジョンを実現させるには、実際にあらゆることに長けている必要があります。
私たちがフルスタックと呼ぶことに秀でていなければなりません。ハードウェア開発に優れている必要があります。
これらは人が常に持っているべきハードウェア体験です。これらは常に装着されていなければなりません。なぜなら、常に装着されていない場合、私が話していることはすべて幻想になってしまうからです。
優れたハードウェアがなければ、人に利用してもらえる、またはあらゆることを動かし得る多くのデータを収集するサービスを実際に創り出すことはできません。つまり、私たちはここをスタート地点として、ソフトウェアを搭載したハードウェアの世界でこういった魔法の体験を創り出そうとしているのです。
私たちは世界有数のソフトウェアアプリケーションに関する専門知識を蓄積してきました。私たちは、InstagramやWhatsAppのようなエンゲージメントの観点からもそれらに長けている必要があるのです。
データ面では、こうした大量の情報の扱い方を理解する必要があります。処理方法やプッシュ通知の仕組み、ユーザーのために活用する方法を理解しなければなりません。
私たちは、まさにハードウェア、ソフトウェア、データの交点にいると考えています。これら3つはそれぞれが、人が装着して何が起きているかを把握し、世の中に配信するという体験を開放するために一体となって機能すべき軸足となるのです。
これは私たちの仕事における重要な部分で、多くの会社がしていることとは異なりますが、あらゆるレベルのスタックで機能し活用される必要があるのです。
私たちにとって、能力の結集は複雑なことでした。なぜなら、ハードウェアに精通している人たちは機械工学や電気工学、それらの相互作用、そして大規模なツールの作り方を理解していますが、ソフトウェアやサービスの作り方はあまり理解していないのが一般的だからです。
ハードウェアとソフトウェアはまったく異なる分野であり、まったく異なるスキルセットが必要とされます。私たちが最初にこれらの人材を結集させた時、社内に多くの興味深い衝突が生まれました。当社のソフトウェアチームやアプリケーションチームは非常に迅速に仕事を進め反復することに慣れています。
一方、反復サイクルをより慎重に行うハードウェアの世界では、腰を据えて仕事をする必要があります。工作機械の据え付けに16週間も掛かる世界では、物事の微調整やちょっとした工夫は通用しません。
こうした異分野の人材を結集させた時、ハードウェア畑の人間がより迅速に仕事をすることを学ぶ姿を見られたのは興味深いことでした。ソフトウェア畑の人間は、とにかく何かを提案してA/Bテストをするのではなく、実際のプロダクト出荷前に体験をいかに向上させるかについて熟考するようになりました。そしてデータサイエンスは、意思決定を行うためのより多くの情報を提供すると共にこうしたすべてのことを教えてくれるのです。
では、プロダクトについてどう考え、どう作るべきなのでしょうか？どのようにカテゴリを変更すべきなのでしょうか？
まず、私たちにとってシステムがすべてであるいうことです。
私たちはハードウェアやアプリケーション、プラットフォームを個別に捉えず、それら全体で考えています。UPの事例を紹介しましょう。私たちはユーザーが装着し体のリズムを記録するトラッキングセンサーを携帯電話と接続し、ユーザーがアプリケーションサービスを体験できるようにしました。
携帯電話に搭載されているセンサーを活用したのです。ここからあらゆる情報を得るために私たちがクラウドで展開している多くのことに情報が送られ、それに関する洞察が深まり、何千ものデベロッパーが活躍する巨大なプラットフォームが誕生したのです。
このプラットフォームからは何千ものアプリやプラグインが開発され、さらなる体験も生まれています。このように、私たちは全領域にわたり思考を巡らせているのです。このシステム的思考については後ほどお話しします。
では、実際の創造プロセスはどのようなものでしょうか？
これについて私たちが語ることはほとんどありませんのでワクワクしています。これまで社外秘としてきたことを初めて話し、さらにはライブキャストでも配信されているというのは実に楽しいことです。
創造とは非常に入念なプロセスです。
このマップはそれを簡単に示したもので、探求フェーズでは自由な想像力が求められます。ここでは幾つかのコンセプトの検証し、アイデアの絞り込みが始まります。
そして、実際のプロダクト作りから発売、反復へとつながっていきます。これがこのプロセスのもっともシンプルな形です。では、各ステップについて説明していきましょう。
探求フェーズは自由闊達かつ想像力が発揮されるステップで、私たちはここでこの世界の向かう先についてのビジョンや当社の戦略を考えます。そのブランドは何を表しているのか？夢想する相手を自分はどのように妨害できるか？未来はどのようになっているのか？
このように、ここではちょっとした科学プロジェクトのように話し合います。着想や洞察力、率直な創造性を基に、良しとする形態を作り出そうとします。なぜなら、それは多くの場合社内において忘れられがちだからです。
そして、初期検証が始まります。ここで私が「みんな聞いてくれ、この件ではこれらのコンセプトを博士論文でするように証明する必要がある」と言うと、社員は結論をまとめ、経験的データを収集し、「現状はこうなっています」という報告が始まります。これが探求フェーズの流れです。ストーリーの概要をまとめるのです。
このフェーズが承認されたら、体験と可能なことについて実際に考える調整フェーズに移ります。
このフェーズは、「これはどのように力を発揮し、この体験をどのように売ることができるか？」、「このストーリーをどのように伝えるか？」といった具体的なレベルでイノベーションを実現させるためのもう1つの興味深い機会であると言えます。
次に、そのためのプログラムを決定し、入念な計画フェーズに移ります。「よし、こうして始まったからにはプロダクトを発売にこぎつけなければならない。もう後戻りはできない」といった具合です。
「あらゆる創造性、私たちが実現させたいあらゆるアイデアと物理的制約とのトレードオフは何か？」、「私たちが直面している様々な制約は一体何であるか？」と妥協点を模索すると共に、どのように組み合わせるかを検討します。
次に、開発フェーズに移ります。ここで各種ステージ間と非常に機能的な社内チーム間での移管が行われます。共に力を合わせ、実践・着手しながら問題を解決し、学習し、ユーザーが考えていることを理解します。
そして、この世界が向かう先を想像し、その体験の連鎖の中でそのプロダクトがどの位置にあるのかと考えます。「自分たちが達成したことは？達成していないことは？」、「ユーザーから学んだことは何か？それによって自分たちの思考はどう変わったか？」と考えながら、また最初からやり直します。
これはもっとも大局的な考え方です。
探求フェーズは建設・修繕プロセスとよく似ています。その多くは、自分の仕事を披露する場であるデモ・フライデーズで決定されます。これは物事を組合せ、他者に理解してもらいフィードバックをもらう形態に昇華させる絶好の場であると私たちは考えます。
これはまさに発表会で、ハッカソンはその重要な一翼を担っていることは確かです。多くのデータが扱われるこのフェーズを主導するのが、かつてはR&Dチームと呼ばれていた「戦略的開発チーム」です。
このチームには、プロダクトやエンジニアリング、ハードウェアとソフトウェア両方の人間が参加しています。しかし、彼らはどちらかと言えば脇役としてそれらの探求内容がどういうものなのか眺めています。
このフェーズでは会社のエグゼクティブが主役となり、「これについて考えてみなさい」とか「これは試しましたか？どのような具合ですか？」のようにあれこれ質問を投げかけ、担当者の尻を叩くのです。
このフェーズでは、次の段階に進むために、「自分はこの相手に5万ドル出すだろうか？」と考えます。これはエンジェル投資のようなものです。「これを探求させて何か手掛けるべきものがあるか確認させるために、自分はこの相手に5万ドル出すだろうか？」と考えるのです。
そして、最終的な決定は当社のCTOが行います。彼はプロジェクトを精選し、「いいかね、私はあらゆるフィードバックを好む。このまま進めてどうなるか見てみたいと私が思ったのはこれだ」と社内に告げるのです。
次に検証フェーズに移ります。
ここは非常に興味深いフェーズです。引き続きR&Dチームが主導しますが、彼らは「これはどう機能するのか？クロスファンクショナルチームが参加する幹部会議で、私は結果を報告する必要がある。科学的プロセスを経て『これはいける』という理由を説明する必要がある。なぜこれをやろうとしているのか？」とアイデアを詮索します。
ここからWHYSと呼ばれる社内の重要なツールの策定が始まります。「これが存在する理由は？」、「これが解決する問題は？」と自分たちは何のためにこれを行っているかを定義するのです。このWHYSについては後ほどまたご説明します。
この時点ではまだR&Dチームが主導していますが、ここでインダストリアルデザインチームと数人のプロジェクトメンバーが加わり、「ハードウェアの場合、このコンセプトをどう現実化できるか？システムの他のパートとどんな相互作用が見込めるのか？」と考えます。
ここではまだ当社のプロダクト体験チームが多くのコアバリューやストーリーボーディングを担当していますが、より現実的な話として、「これをどのように作るか？幾らくらい掛かりそうか？予算はどれくらいになりそうか？」と考えます。
この時点で、「これを実現させるためにはバッテリーに関して3年待つべきか？」、「他のイノベーションが生まれるのを待つべきか？」、「予算面から待つべきか？」、「事業実現性はあるか？」とこれを実際に作ることが可能かという検証をします。
次に、ブリーフスケッチが始まります。ここで私が加わり、最終決定者として「これはいけそうだ。次のレベルに進めることにしよう」といった決断をします。
次にコンセプトフェーズに移ります。ここで責任はR&Dチームから当社で言うプロダクト体験チームに移ります。Jawboneでは皆、プロダクト体験を慣用的設計と考えています。ここにはインダストリアルデザイン、ソフトウェアデザイン、オーディオデザイン、そしてこの体験に関係するあらゆるものが含まれます。
チームにはライター、ストーリーテラー、天才的クリエイターであるEveのようなIDスタッフ、優秀なアプリレベルデザイナーやグラフィックデザイナーがいます。このようにあらゆる人材が結集した集団を当社はプロダクト体験チームと呼んでいます。
彼らの仕事は私たちを1つの組織として束ねることであり、ここから地歩を固めWHYSを本格的に追求します。
彼らは何が可能かを考えます。どのようにプロダクトを製作・創造するかという実装過程では多くのイノベーションや創造性が必要となります。私たちは、「プロダクトにおいてもっとも重要なことは何か？」、「解決しようとしているもっとも重要なことは何か？」と問います。当社はこれを「ヒーロー体験」と呼んでいます。「自分たちは何をしようとしているのか？」、「許容し得る障害は何か？」と考えるのです。
この時点でWHYSの解決が始まります。これについては後ほどご説明します。
これが競合プロダクトと異なっている理由は？カテゴリと異なっている理由は？どこに向かっているのか？私たちは物事を単独で捉えることを好みません。より広範なビジョンで捉える必要があるのです。
これは創造体験の一部です。世界がどこに向かっているかを見据え、どのようにその最終的なビジョンへの足掛かりとなるかを考えるのです。ここがロードマップの起点となります。繰り返しますが、この段階でチームの最終決定権を持っている私が「よし、次のフェーズに進めよう」と決断します。
ここでも幾つかのことについて検討します。幾つかの具体例で説明しましょう。
当社にはファストトラック（迅速化）プログラムがあります。JAMBOXを例にしますと、このフェーズにおいて私たちは「これを世に発表し、テストし、市場に投入し、迅速に事を運びたいので、もう他のフェーズに進むことはせず開発プロセスに直接進もう」と話し合いました。つまり、所定のプロセスを経ずに迅速に事を進め、市場投入の可能性を再検討するのです。
この段階を経た後、担当はプロダクト体験チームからプロダクトマネジャーに移ります。プロダクトマネジャーは、「いつ発売するか？」、「小売店のカレンダーにいつ載せるか？」、「ソフトウェアのリリースサイクルは？」と実際に事業計画を定義します。
彼らは試作品を作ります。そして、「私たちが作りたかったものはこれだが、今のままでは作れない。しかし、こうすればできる。だからこの方法で進めたい。これらの機能体験を盛り込みたい。バッテリー寿命などはすべて断念しよう」と様々な点に関して妥協点を模索します。様々な意思決定や検討が始まるこの段階は、実に困難な状況と言えます。
これを担当するのがプロダクトチームです。
ここで再び私たちがまとめ上げたあらゆることを検討・統合し、「これは実際にリストアップしたことを解決しているか？ミニマムバイアブル(実用最小限)になっているか？」と考えるのです。
お分かりのように、私たちは常に「何が可能か」「自分たちには何ができるか」に関する膨大な要望リストからスタートするのです。そして、リストの項目を順番に見ながら、「これは私たちが追求すべきと考えている価値基準を十分に満たしているか？」と自問するのです。
ここでプロダクトマネジメントチームが再び主導する開発フェーズに進むことができますが、ここでは本格的な掘り下げ作業が始まります。
エンジニアリングスタッフが加わり、制作が承認されます。これは出荷までのスケジュールです。
プロダクトチームはどのように掘り下げていくべきかを考察します。
「エンゲージメントを向上させる方法は？」、「わずかなイノベーションは何か？」、「チューニングとは何か？」、「これらすべてを実現させるためにすべきことは何か？」と考えるのです。
幸いにして、私たちのプロダクトには多くのすばらしい反応が寄せられています。私たちはこの開発・調整フェーズにおいて、魔法の体験を生み出す細かい部分に多大な注意と時間を費やしています。
例えば、JAMBOXの電源を入れると、「ウー」という実にかっこいい音が聞こえてきます。この絶妙なオーディオチューニングには数か月掛かりました。私たちはこの音を創り出すために多種多様な音響作家と協働しましたが、誰かが電源を入れるたびに微笑んだり笑ったりしている姿を目にします。
ゴムのプロトタイピングについてお話ししますと、初代JAMBOXのために私たちが求める品質と色のゴムを作ることができたメーカーは世界で1社しかありませんでした。こうした細部のすべてが魔法の体験につながるのです。
ソフトウェアではこうした問題をどう解決するのでしょうか？初代UPでは、接続するとスリープグラフが表示されました。バー表示のアニメーションとカードが表示されるのですが、これが「これはどのような相互作用をするか？」、「ユーザーはこれをどのように体験するか？どのように感じるか？」と私たちが考えていた細部なのです。
プログラム承認の段階でさえ、こうした多くのことが起こるのです。あらゆる段階でそうした意思決定を行い、妥協点を模索し、大局的に物事を考えていくのです。イノベーションとは、あらゆる物事を洗練し続ける機会なのです。
これをより広いレベルでどう考えますか？
ユーザーの特徴的体験を考えるためのフレームワークとは何でしょうか？
私たちはまずWHYSについて考えることから始めます。それによって解決する問題が明確化されます。
次にいかにしてこれらを実施可能なコンセプトにするかというテーマについて考えます。
そして、プロダクト体験チーム、ハードウェアエンジニアリングチーム、ソフトウェアエンジニアリングチーム、データチームから1名ずつ集めたクロスファンクショナルチームを編成します。このチームがそのテーマや道筋を基に、ヒーロー機能や内部機能を盛り込んだプロダクトを作ります。
では、私が多くの時間を費やしているWHYSに関するより具体的な話をしていきましょう。
疑問をぶつける場であるWHYSは、私たちが後で戻ってきて「自分たちが挙げた疑問点に答えているか？実際にそれを解決するものになっているか？」と問うための実に興味深いフレームワークとなります。さらに、私たちが持っている多くの創造性やイノベーションを自由闊達なものとするためのすばらしい指針にもなっています。
これは「この体験を通じて私たちが解決するユーザー側の問題とは何か？」というシンプルな質問で表すことができます。ハードウェアの問題であろうと、ソフトウェアの問題であろうと、データの問題であろうと、プラットフォームの問題であろうと、ひとたび解決できれば、人々はそれなしでは生きていけなくなります。
彼らは問題を解決したいという実に切実なニーズを持っていながら、解決できないでいるのです。彼らがソリューションを求めているか、こちらがその必要性を感じなかったが、今やそれなしでは生きていけないかのいずれかです。
繰り返しますが、JAMBOXはその好例です。私たちはこのプロダクトの企画時に何人かに話を聞きました。
その時のことを少しお話ししましょう。2010年秋にJAMBOXを発売した時、スピーカー市場全体に占めるワイヤレススピーカーのシェアはゼロ％でした。ゼロ％ですよ。
ところが、この前のクリスマス、つまり2013年のクリスマスですが、その時のワイヤレススピーカーのシェアは78％でした。私たちは数年のうちに50～60年代から続く業界を一変させたのです。
あの当時、多くの人に「携帯電話と接続して使う199ドルのスピーカーを欲しい人はいますか？」と尋ねたらどうだったでしょう。「そのプロダクトが欲しい。それを必要としている。ぜひとも買ってみたい」と答える人は1人もいなかっただろうと私は断言できます。しかし、JAMBOXの発売によって業界は一変したのです。
ここでWHYSが非常に重要となります。自分のしていることにフォーカスするのです。
では、オーディオ分野における1つの事例、つまりJAMBOXの事例を紹介したのち、UPの事例、特にUP24について少しお話ししたいと思います。
その起点となるのが体験に関するフレームワークで、私たちがカテゴリ戦略と呼ぶものです。
あらゆるコンテンツ体験やメディア体験は、もはやiPadやiPod、コンピュータではなく、携帯電話で行われると考えた私たちは、モバイルデバイスの携帯性、そして高品質を備えた異なる連携方法が必要だと思いました。これが私たちの根本的思考でした。
そして、その体験は時空を超えたシームレスなものである必要があると考えました。つまり、違う車に乗る時でも、旅行中でも、家の周りにいる時でも、どこでも使えるようなプロダクトです。
これが私たちがまず取り組んだことで、そうした理由からこのカテゴリが存在すべきであると考えました。これが人々の問題だったのです。
私たちは次に、「これはJawboneにとってどんなメリットがあるか？」、「私たちがこれに取り組むべき理由は？」と考えました。より広義のマクロ的視点で考えた時、家庭へのエントリーポイントとなったのがIoTでした。
これが照明からサーモスタット、冷蔵庫まで家庭内で接続されているあらゆるものが世間で話題にされている理由であり、メディアは今なお家庭内でのキラーアプリとなっています。ここで私たちのプロダクトが何百万個と売れているのです。
そこで私たちは、スピーカーがこのようなユーザーの周りにある世界へのエントリーポイントになり得るもの、家庭内でソフトウェアとサービスという観点から私たちが目指すものになり得ると考えました。
ユーザーが抱える問題を解決する興味深い戦略でありながら、これがJawboneにとって重要となる理由は何でしょうか？1つ目に私たちは慈善的な非営利業界にいるのではないこと、そして2つ目にこれに成功した場合、優れたプロダクトを作り続け、前進し続け、興味深いことをし続けることができること、これら2つを両立させる必要があります。これが私たちが物事を組合せた方法なのです。
そこで私たちは、体験連続体と呼ばれるものを作りました。
これは今日どこにあるのか？私たちが始めた時、それはBluetoothスピーカーでした。いいですか？Bluetoothは他のモノへの接続を可能にする中核的実現技術でした。これは明日にはどこへ向かっていると思いますか？将来の夢を見られる時には何が起きているでしょうか？
私たちは、ユーザーがある場所からスタートして動き続けるための漸進的な足掛かりとして、私たちが今日作ったものを基に明日や未来に生きようとし始めています。
これは妥協点を模索する方法も私たちに教えてくれます。先ほどお話ししたように、私たちはこれを今のプロダクトに組み込まないが次のプロダクトに組み込む機会があるといった考え方です。
私たちはユーザーをそこまで連れていけると思っていますし、ユーザーはそれに備えていることでしょう。私たちが行う物作りの多くは、そうした体験に含まれることを定義することなのです。
私たちはこのことについてよく話をしています。
私たちは自身をハードウェアチームやソフトウェアチーム、データ企業ではなく、体験企業だと考えています。これは単に物理的デバイスや機能ではなく、システムに関すること、物事の組合せ方に関することです。
つまり、これらのWHYSを定義する時、それらはプロブレムステートメントとなります。私たちは、「ハードウェアをどう使うか？クラウドのサービスをどう使うか？アプリケーションをどう使うか？音は？ボタンは？ユーザーが体験しているこの問題をどう解決するか？システムにおける適切な配分は？問題をどこから取り組むべきか？イノベーションが求められる場所、それらをまとめ上げるべき場所はどこか？」と考えます。
これこそが私たちの仕事をサポートする思考の非常に大きな部分なのです。
これらの体験について考えることは、ユーザーにとって何故それが魅力的となるのかを考えることと言えます。先ほどお話ししたように、システムがもっとも重要であり、それがないと喪失感を覚えるほどの感情的結び付きを感じるレベルまで到達する必要があります。
それを忘れた時は、自宅に戻って取ってくるといったことです。これらはあらゆることに適用される原則なのです。「それはこれをしているか？」という風に、私たちはこれらの問いを自問し続ける必要があります。
私たちはこれらすべてのことを組合せ、体験フレームワークを創り出します。これはエンジニアリングチームやデザインチームにとってまさに要点であり、彼らが後でそこに戻って「自分たちは何をしているのか？なぜこれをしているのか？どのように機能するのか？それを生み出す方法は？」と自問することができます。
次はプロセス全体です。
Blueberryは社内のコードネームの1つです。ユーザー体験プロセスはより豊富なリソースから始まるため、私たちは実際にユーザーの声に耳を傾け、彼らと話をします。私たちは非常に具体的な方法で話をしながら重要な洞察を探します。そしてこれらをコンセプト化し、作ります。
これこそ消費者が抱える問題のリストを探しに行く理由です。大原則として「それへのアプローチをどう考えるか？ソリューションは何か？これを実現させるためにプロダクトで必要とされていることは何か？」と考えるのです。何でしょうか、Sam？
Sam Altman
先ほど「ワイヤレススピーカーに200ドル払うユーザーはいないだろう」という話がありましたが、その事実をどのようにバランスさせているのかを聞かせてもらえますか？
Hosain Rahman
はい。私たちはこのプロセスの前にユーザー調査を行っています。ユーザー調査には多くの段階があります。非常にいい質問です。
皆さんはまだ馴染みがないかもしれませんが、フォーカスグループでは人々の行動に関する一般的なツールがあります。「あなたはこれを試しますか？」、「これにお金を払いますか？」、「この機能が欲しいですか？」、「あなたが重視することは何ですか？」と尋ねるのも1つの方法ですが、有益な回答が返ってこないのが一般的です。
そこで私たちは、「他の人と一緒にいる時、どれくらい音楽を聴きますか？」、「音楽を何で聞きますか？」、「音楽を聴くのはヘッドフォンですか、携帯電話のスピーカーですか？」、「他の人と一緒にいる頻度は？」、「自分だけの体験をしたい頻度は？」、「シェアしたい頻度は？」、「～の頻度は？」のように様々な質問をします。
私たちは多くの質問をします。とにかく様々な質問をします。「これは欲しいですか、あれは欲しいですか？」のような具体的な質問はせず、「どんな行動をしていますか？」、「どういう暮らしをしていますか？」と尋ねます。その好例がiPodです。「ポケットに千曲入れてどこかに行くとしたら～」と尋ねます。「携帯型のデジタル音楽プレイヤーは欲しいですか？」という聞き方ではありません。
繰り返しますが、200ドルは携帯電話を上回る価格でした。つまり、自分のテーマに関する理解を深めるために尋ねることができる質問と、自分のために誰かにそれを検証してもらうための質問とを分ける必要があるのです。
この区別は実に重要です。何を作るべきか誰も教えてくれません。それを教えてくれるとしたら、自分ではなくその人自身がやるべきです。意思決定をし、テーマを持ち、創造的なアイデアを持ち、イノベーションを行うのは自分なのです。
自分のしていることをより良いものとし、自分の思考を洗練させるために人々を活用する必要があります。こういった違いがあります。ご理解いただけたでしょうか？
UP24の話に移りましょう。UP24は私たちが発売したワイヤレス接続のヘルストラッカーです。
UP24のWHYSは実にシンプルです。まずはUPのWHYSからご説明しましょう。TwitterやFacebook、ソーシャルメディア、インターネットへのアクセス、Googleなどを通じて私たちが現在の世界について理解していることは沢山ある一方、私たちは自分自身について何も知らないと感じていました。
私たちは8時間の睡眠で気分がすぐれない時もあれば、3時間の睡眠ですっきりした気分の時もあるのはなぜなのか分かりません。
私たちは、多くのセンサーテクノロジーを活用することで、人々が自分自身をより理解し、それによってより良い人生を送るためのより良い決断をする手助けができるのではないだろうかと考えました。それが最初のプロダクトでした。
そして先ほどお話しした2つ目のプロダクトでは、ワイヤレス接続ができるのであれば、単にBluetoothかワイヤレスかということではなく、リアルタイムで収集される情報を活用することで自分に起きていることを理解し、それに基づく行動が可能になると考えました。
必要な時に、より有意義で、関連性がある適切な方法でデータを収集できるわけです。私がどのような行動をとればよいか計画的な方法で指導を受けることもできます。
そこで継続的な励ましが必要になります。なぜなら、誰もがもっと良くなりたいと理解していながら失敗するからです。人々が求めているのは、スムーズな情報のやり取りなのです。
これは私たちがUP24に盛り込んでいることです。私たちには、このプロダクトを作っている理由とこれに取り組んでいる理由に関する非常に明確な5つのWHYSがありました。
先ほどお話ししましたように、私たちがUPでしているすべてのことはあらゆるデータの収集およびそれらの知識化であり、それを通じてユーザーが自分自身を追跡・理解することをサポートするという体験フレームワークであるという根本的な考え方が私たちにはありました。
3つ目は行動、つまり追跡、理解、行動という一連の流れです。
これは私たちがウェアラブルヘルスプロダクトで行うあらゆることに関する考え方であり、私たちがすることのすべてになります。この一連の流れにより、人々は結果に関するより多くの情報を得ることができます。
データは有益なものですが、それを理解することがより重要です。それを後に行動の基盤とし得る真の知識を生み出してくれるものに変換するのです。
デバイスを使い続けてもらい、より多くの情報を収集し、ユーザーのエンゲージメントをサポートし、そうした行動へ導く方法を見つけるために私たちができることは非常に興味深く、今やシステムのフレームワークとなっています。
ここで、デザインについて考え始めます。データインフラや洞察システムをどう作るか、どう処理するか、それらを表面化させたアプリケーション体験をどう作るか、ということです。
ここでは追跡、理解、行動についてもう少し掘り下げて考えることになります。追跡というのは、本質的にはハードウェアにも関係する部分です。「バッテリーのデザインをどうするか？」、「内蔵システムや原材料のデザインをどうするか？」、「習慣的に装着してもらえるような装着方法は？装着し易さはどうか？」というように考察を深めます。
そして、あらゆるデータを入手する必要がありますが、それは単に情報を視覚化するということではありません。私が皆さんに「あなたの心拍数は75です」と伝えたとして、それは良い数値なのでしょうか？悪い数値なのでしょうか？その質問には誰が答えられるのでしょうか？私には分かりません。
その良し悪しは皆さんが何をしているか、どんな人か、何が起きているかによって変わってきます。データを表面的に理解するだけでは不十分です。なぜそれが重要であるかを説明し、行動に変えてもらう必要があります。これが3つ目です。行動が重要なのです。
あなたのデータについてご説明しましょう。あなたは4時にワークアウトすると夜にさらに4時間熟睡できます。素晴らしいことです。それでは4時になったらワークアウトの時間だとリマインドしましょう。これが私たちが作っているものです。多くのインフラを使ってそうした体験を生み出しています。私たちはこのようにソフトウェア、ハードウェア、そしていわゆるシステム全体を作っているのです。
私たちは様々なタイプのユーザー、彼らが重視すること、当社のユーザー基盤の構成についてよく話し合っています。
減量に興味を持っているのは誰か、社会的受容を求めているのは誰か、虚栄心が強くてとにかく良く見られたい人は誰か、といった具合に世の中には様々なことが存在します。医療上の理由から当社のプロダクトを使っている人もいます。
私たちは異なる体験をデザインします。
携帯電話などのプラットフォームの活用やシステムの一環としてのプッシュ通知の方法について考えます。私たちは通知を行動を変化させるためのツールとして考えています。
そして、実際にこれらのことについて精緻な計画を立てます。
スマートな行動とは何か？リアルタイムであるか？カスタマイズ可能と感じられるか？革新的と感じられるか？自分をサポートしてくれるか？自分用にカスタマイズされているか？
このような特定のユーザーに関しては、実際にストーリーボードを作ります。
そしてこのストーリーボードは当社のデザインエンジニアリングチームに渡されます。私たちは協働しながら実際にそこからプロダクトを作り出します。これによって一連の制約が生まれるのです。
私の経験から申しますと、制約は実に有益です。
なぜなら、制約は、決定する機会、洗練する機会、簡略化する機会、そしてもっとも簡単な方法でユーザーの問題を解決する適切な答えを発見する機会となるからです。
私たちが行っていることにおいて、こうした制約が多く生まれています。
これは誰かに目標を達成させるための方法、そして私たちが使用するものをリアルタイムで表したストーリーボードです。
次に、「私たちはこれが可能か？それにフィットさせることができるか？」、「あまりに乱雑またはややこしくなければ追加しよう」と考えながら二次的体験を加えます。
これは私たちのプロダクト作りを描いたスナップショットのようなものです。
残り数分となりましたので、ここからは質疑応答に入りたいと思います。
受講者1
例えば、あるプロダクトがあり、作りたい機能が沢山あるとします。今まさにデザインプロセスに進もうとしている時、問題全体にどのようなアプローチを採りますか？問題をどう解決すべきかをどのように細分化しますか？
各々の設計特性は相互排他的ではありませんので、全体的にはどのようなアプローチを採るべきでしょうか？様々な特性や機能を作ろうとしている場合、システム全体におけるトレードオフを理解するために縦割り型ではなくシステムレベルでどのような検討をしますか？
Hosain Rahman
それがまさにあなたの質問に対する答えです。あなたのおっしゃるとおりです。縦割り型で考えてはいけません。
少人数のチームの場合、話は実に簡単です。皆が1つのテーブルに座り、互いの顔を見ながら、リアルタイムで意思決定ができるからです。しかし組織が大きくなるにつれて、皆を強制的に招集して会議を開かなければなりません。
ある社員は「これを盛り込むのなら、このように私に制約を加えるのなら、あなたが私に求める品質仕様は実現できない」と言い、別の社員は「それでいくなら、あなたが求めるバッテリー性能ですべてのリズムをフィットさせることはできない」と言うのです。
システム全体を考える時は、「私がここで妥協すると、あの部分に影響が出る」と理解できるように、各自が抱える苦労や問題点を全員で共有する必要があります。全員を部屋に集めて、徹底的に話し合う必要があります。
これはあらゆるボードや壁に書かれていることで、私たちが目指していることです。そのトレードオフはすべての部門において満足できるものだろうか？皆自分なりにトレードオフを考えていて、自分が達成すべきことを理解しています。しかし、全体にどう影響するかが重要なのです。
私たちは、ちょうどUP3でこれを経験したところです。UP3はウェアラブル型ヘルストラッカーの分野で起きる次の波を定義するようなプロダクトで、数週間後に発売される予定です。
私たちはまったく新しいセンシングシステムを発明しました。いいですか？私たちは以前から開発されていたこの科学にいち早く目を付け、電極材のトレードオフを見つけました。
それは信頼性、ソーシング、シグナル性能にどのような影響を与えるのか？社員はそれまであまり話し合うことがありませんでしたので、1つの部屋に集めました。そして、自分たちの仕事について毎日3時間電話で一つ一つ話し合いました。
うんざりしますね。しかし、私たちは解決策を見つけ、対処したのです。
少人数の場合は、描いて見せるだけで良いので実に簡単です。しかし、システム内で自分がしようとしていることを常に定義できるようにする必要があります。
私が本日話していたことの多くが、「私たちが解決している問題は何か？」、「どこに向かっているのか？」、「それらすべてがどのように組み合わさっているのか？」といったより高度なレベルの問題なのです。
受講者2
1つの小さなことにフォーカスすべきでしょうか？それともシステム自体にフォーカスすべきでしょうか？
Hosain Rahman
システムとはいわゆる思考であり、実際にはシステムではありません。単純なシステムもあれば、複雑なシステムもあります。飛行機は非常に複雑なシステムです。自動車も非常に複雑なシステムです。
私たちが作るプロダクトにはもっと単純なものもあります。携帯電話は複雑なシステムです。アプリケーションはシステムとして考えるべきです。ストレージやフロントエンド体験など、皆さんがしていることは接続です。
これらはすべてシステムなのです。それが私の言うシステムなのです。私たちの場合、システムとはハードウェアやソフトウェア、データですが、あらゆるものの中にシステムがあると思います。それは、一体となって機能する異なる部分に関してどんなトレードオフが生じるかと考えることと言えます。
受講者3
JAMBOXには様々なバージョンがありますが、関連のないプロダクトを製作することと、フィットネストラッカーのためにスペースを確保することに関する意思決定プロセスはどのように行われているのでしょうか？
Hosain Rahman
私たちにはこれらの体験の融合に関する大前提の理論があります。自分の周囲の世界のあらゆることをよりスマートにし得るものを体に装着している場合、そこで起こっていることはコンテキストエンジンにも関連してきます。
ユーザーの情動状態が分かれば、JAMBOXでどんな曲を流すべきかSpotifyに伝えることができます。ユーザーはあのCMが嫌いなので次のCMに早送りするようテレビに伝えることができます。あるいは、睡眠不足になるので日曜の夜に『Game of Thrones』を見ないようユーザーに伝えることができます。
私は冗談を言っているのではありません。これらは関係しているのです。私たちはこのようなレベルで物事を考えています。
「目的を達成するための構成要素は何か？」、「どのように信頼を得るか？」、「流通システムをどのように構築するか？」、「製造規模をどう設定すればよいか？」、「これらをどのように組み合わせるべきか？」と考えるのです。
記事情報
この記事は原著者の許可を得て翻訳・公開するものです。
原文: Lecture 17: How to Design Hardware Products (2014)
