なぜ私たちはプロトタイプを作るのか

こんにちは@hatuyuki4です。普段はiOSエンジニアをしたり、ガラル地方を旅したりしています。

先日Creative Selectionという本を読みました。この本は元Appleのエンジニアが自身のプロダクト開発プロセスについて書いていて、特にプロトタイプを作成してデモを行うプロセスが詳しく書かれていました。この本が非常に面白かったので、読了後ロコガイドのサービス開発にも意識的にプロトタイプ作成を取り入れるように働きかけました。

今回はそういった経緯から、なぜプロトタイプを作るのか、どのようにプロトタイプを作っていけばよいのかについて書いていきたいと思います。

サービス開発の苦悩

サービス開発は苦悩の連続です。自分たちが開発している新機能がユーザにどのように受け入れられるのかは、実際にリリースしてみないとわかりません。それまでは暗中模索の連続です。そんな答えのない開発を健全に続けていくには、リリースするまでのプロセスが重要になってきますが、そのプロセスの中にも、難しい問題はたくさんあります。

1.最高な仕様を描くことは難しい

どんなに優秀な人でも、最高の仕様をいきなり決めることは困難です。それは企画者の能力が足りないというわけではなく、サービス開発においては、表示ケースが多数あったり、前後のコンテンツの兼ね合いがあったり、事業上の戦略的制約があったりなどなど、様々な要素が絡むので実装してみたらどうしても想定通りにいかないということが多々あります。

そんな状況で実装が進み、完成間際で実際に触ってみて想定と違った場合、手戻りが発生するか、妥協してそのままリリースするか、リリースを延期するか・・・いずれにしても苦しい決断を迫られます。それは仕様が大きければ大きいほどギャップは大きくなり、修正するコストも大きくなります。

2.根拠のない議論

具体的なプロトタイプがないまま仕様の良し悪しを議論すると、議論が空転してしまうおそれがあります。仕様だけを見た段階で「○○のほうがいいと思う」とか「○○のリスクがあると思う」というのは、一見それらしいことを言っていたとしても、明確な根拠がない場合があります。そもそも、頭の中だけで最高な仕様を描くのが難しいのに、頭の中だけで最高なフィードバックを返すのもまた難しくなるのも当然です。

根拠のない議論におちいると、コミュニケーションコストは高くなるけど明確な結論はでなくなってしまい、疲弊はするけど開発スピードがでないという事態に陥ってしまうかもしれません。

プロトタイプのメリット

そんなサービス開発の苦悩を解決するアプローチの一つとして、私たちは積極的にプロトタイプ作成を行っています。プロトタイプ作成の目的を一言でいうとサービス開発を前にすすめるということです。例えば、以下のような利点があげられます。

1.具体的なフィードバックと明確な意思決定

プロトタイプをする上で一番重要なポイントかもしれません。根拠のない議論におちいるとコミュニケーションコストがかかる割に話は前に進まなくなってしまいますが、具体的なプロトタイプが存在すると、おのずとフィードバックも具体的になってきます。

良い点、悪い点、改善案などなど・・・意見の種類は様々ですが、どれも具体的なフィードバックが返ってきます。そして具体的なフィードバックは、具体的な意思決定に変わります。開発していても、次はどのように改善すればいいかが明確になるので、それは明確な進捗として現れます。

プロトタイプ初号機	フィードバック	改良後

例えば、これはトクバイアプリで検索改善のプロトタイプを行ったときのフィードバックなのですが、具体的なフィードバックが返ってくるので、どのような改善を行えば明確になり、次のアクションへの移行が非常にスムーズに行えました。

2.共通認識

開発メンバーが増えると仕様の認識を揃えるのも大変になったりします。言葉の仕様だけだと、デザイナーやエンジニア、その他のステークホルダーでの認識の齟齬が生まれてしまうことがあります。認識の齟齬が開発の後半に発覚すると、それを立て直すのも大変です。

具体的なプロトタイプがあれば、コンテンツの見え方からアニメーションや細かなレイアウトまで、開発初期に認識がそろい、手戻りの発生も抑えられます。

3.正しく諦める

プロトタイプを作成していると、想定と違ってあまりユーザ体験が良くないということがわかることがあるかもしれません。その際も、どの点が良くないのかというのが具体的なフィードバックとして得られるのもポイントです。

たとえ良くないアイディアが出たとしても、具体的な理由をもって諦めることができ、その理由が共通認識としてチーム内で共有されます。理解しがたい理由で否定されることがないので、精神的にも楽です。

答えが見えないものを探る過程では、一点の正解を探るよりも不正解であるルートを見つけるほうが近道であったりもします。プロトタイプを作成して、アイディアを正しく諦めましょう。

プロトタイプのポイント

プロトタイプの利点をあげましたが、ただ闇雲にプロトタイプを作ればいいわけではありません。どのようにプロトタイプを作ればいいのか、そこにはいくつかポイントがあります。

1.現実じゃないものを現実に見せる

プロトタイプの目的が具体的なフィードバックをもらうことなのですから、どのくらいの精度のプロトタイプを作るかは重要です。プロトタイプがツールを使うのか、コードを書くのか、どのような方法で実現されていてもかまわないのですが、重要なのはそのプロトタイプを触った人が現実のものだと感じるかどうかです。

さわった瞬間にハリボテだとわかってしまうと、プロトタイプを触る人はハリボテであることを意識しながらプロトタイプを触ってしまいます。偽物だとわかっているので、見た目上のフィードバックしか得られません。

どれくらいの精度のプロトタイプを作ればいいか悩んだら、触ってもらう人のことを考え、どのようなフィードバックが欲しいのか考えましょう。

2.現実に見える最短ルートを考える

プロトタイプでは触った人が現実に思えることが重要なのですから、そこから使用するツールを考えます。基本的には現実感を与えられる最短ルートを狙います。ウォークスルーやキャンペーンなど静的なコンテンツならプロトタイプツールで十分ですし、検索やコンテンツの登録など、動的なものならば実際コードを書いたほうが早いでしょう。

動的なコンテンツをプロトタイプツールだけで作成しようとすると、決まった動きしかプレビューできなくなり、画面遷移の共通認識を得ることはできますが、体験に関するフィードバックまで得るのは難しくなってしまいます。

ロコガイドではよく、見た目上のデザインを確認する際はfigmaでプロトタイプモックを作成し、体験を確認したい場合は簡易的なコードを書いて確認しています。

3.実際の体験を試す

試作機なのですから、何かを試さないと意味がありません。では、何を試すべきなのでしょうか？ サービス開発では、体験を試すべきでしょう。体験上問題がないかの確認ですから、架空のデータで触ってみても意味がありません。自分がユーザとして普段利用しているような状態を再現してプロトタイプを触るべきです。

トクバイは各地域の特売情報が見られるサービスなので、住んでいる地域が違えば表示される情報も違ってきます。なのでトクバイアプリでは自分の地域の店舗情報を一括でフォローできるデバッグメニューを用意しています。様々な人が開発機でプロトタイプを触る際にも、自分の地域の情報を見ながら確認できるようにして、ユーザ体験を試せるようにしています。

4. 頭の中のかわいいわんちゃん

冒頭でも紹介したCreative Selectionに非常に興味深い例え話が乗っていたので、一部紹介したいと思います。

「可愛い子犬を1匹、思い浮かべてほしい。目を閉じてもいい。できるだけ具体的なイメージを思い浮かべよう。少し間を置こう。そう、可愛い子犬だ」

二人の人間が、このように可愛い子犬を頭に思い浮かべたとします。さて、ここで問題です。 二人が思い浮かべた二匹の子犬、どちらの子犬のほうが可愛いのでしょうか？

可愛さを説得する議論を続ける？　ホワイトボードに子犬の絵を書く？　上司が可愛いといった意見に賛成する？　それは弁論や絵の上手さや肩書の違いによって結論が変わるだけで、本質的な子犬の可愛さ以外の要素が大きく働いていてしまいます。

もしそこに、子犬の写真があったとしたらどうでしょう？ 「耳が最高にかわいい」「幸せそうな表情がかわいい」など、具体的に可愛さを指摘できて、それが他者にも伝わります。難解だった議論が、子供の遊びのような簡単な議論に変わります。

そういう経緯もあり、ロコガイドではプロトタイプ作成して実際触ってみることを(一部の人の間で) 🐶ちゃんと呼んでいたりもします。少しずつ、積極的にプロトタイプ作る文化が育っていっているようです。

サービス開発を前にすすめる

サービス開発は様々な要素や制約が絡む中、課題を解決する方法を模索しなくてはいけません。一気に課題を解決する素晴らしいアイディアや仕様をひたすら考えたり議論ばかりしていると、進捗が停滞してしまうこともあるかもしれません。

そんな状態をいかに素早く解決に導くことも、サービス開発エンジニアの仕事だと思っています。なので今後も、サービス開発を前に進められるような開発プロセスを心がけていきたいです。