こんにちは、内藤です。

ここ2年くらいでウェブサイトやアプリの制作ワークフローにプロトタイプを導入する機会が増えました。POPやProttなどのプロトタイプツールも多く見られるようになったので、そういう流れなんだなーっと感じている方も多いと思います。

でもみなさん、このプロトタイプをうまくプロジェクトの中で活用できているでしょうか。
実は私も、何回かプロトタイプを取り入れたプロジェクトに携わったのですが「うまく活用できている」と自信を持って言えなかったというのが本音です。どのサイトもクオリティには問題なくリリースされているのでプロジェクトとしては成功なのですが、リリース後の振り返りをした時に「プロトタイプをうまく活かせなかった」という反省がいつもついてまわりました。

そんな中、先日担当した案件で取り入れたプロトタイプは「なかなか良かったんじゃないか」と自分を評価できるように活用できました。
ということで、今回これまでのプロトタイプの導入案件で学んできたことを振り返ってみたので、皆さんにも共有したいと思います。プロトタイプを制作フローに導入するかどうか迷っている方には1つの参考に、すでに導入したことのある方には共感し振り返りのきかっけになるといいなと思います。

プロジェクトにプロトタイプが必要なのかを検討することが大事

これだけプロトタイプ、プロトタイプと言われていると制作フローに取り入れなくてはならない気がしてしまいます。プロトタイプはアプリ制作や自社サービスに限定したものではなく汎用性も高いため、メリットを考えるとどのプロジェクトにも導入できそうな気がします。もちろんそれは間違いではありません。ただ、プロトタイプがあまり向かない場合もあると思います。

クライアントによって向き不向きがある

例えば大企業などで多いのですが、何かの決定をするための社内承認プロセスが複雑、または、色々なことの決定は数ヶ月に1度の社内プレゼンで行われるようなクライアントは、あまりプロトタイプを導入した制作フローに向いていないかもしれません。この場合はプロトタイプに時間を割くよりも、少しでも早くサイトをプレゼンできる状態に近づけて、承認フローのどこでひっくり返っても対応できるリソースを確保することを優先した方がいいと思います。

また、クライアント側の担当者が決済権を持っていても、その方のリテラシーによって慎重に判断する必要があるとも思いました。ウェブサービスをいくつも経験している方が担当だといいのですが、初めての方も多くいらっしゃいます。プロトタイプという単語の意味を知っている方は多いのですが、制作経験がない限りそれがどのようにプロジェクトの中で活用されるのかをイメージできる人は多くないです。
プロトタイプにはペーパープロトタイプという手書きで作成する簡単なものから、htmlとcssで実装する本格的なものまで様々な種類がありますが、クライアントのプロトタイプに対する理解が追いついていない場合、いずれのプロトタイプでも検討してほしいことよりも違ったものにとらわれたり（色がついていないと最終的にどうなるかイメージできない等）、「プロトタイプ」ということに安心して仕様に曖昧さを残してしまう等、うまく進まないことの方が多かったです。

この場合、もちろんそのクライアントが悪いのではなく、プロトタイプの進め方を導入したのにうまくサポートできないディレクターに非があると思います。ただディレクターのサポートスキルが十分でも、クライアントとどこまでプロトタイプの活用イメージを共有できるのかはクライアントのリテラシーが肝になってくるので、そこのコミュニケーションコストがかかってもプロトタイプを導入するべきなのかは、十分な検討が必要です。

プロトタイプですべてを作成する必要はない

まずプロトタイプですべて作ってサイトが意図するものにできているのか検証する、、、ことができればいいのですが、多くのプロジェクトにはスケジュールと予算があるため、そうも言っていられません。特に受託で開発を行っている場合は、リリース日と予算を当初の契約から動かすことができないことがほとんどです。その場合、サイトやサービスの要となる部分を見極めてプロトタイプを作るのが良いと思いました。

プロトタイプでサービスの要を検証する

「ユーザーにこのサイトで何をしてほしいのだろう」「このサービスの存在意義はなんだろう」等、コンセプトをプロジェクトの初めに定義すると思います。そのコンセプトを軸にユーザーとのタッチポイントで重要な箇所をリストアップし、重要度の高いものからプロトタイプを作成するのが効率よく、パフォーマンスも高いものでした。

例えば、サービスを説明して資料請求をしてもらうサイトがあるとしましょう。サイトの目的は「サービスの理解」なのか、「資料請求をしてもらう」なのか（またはどちらが優先順位が高いのか）を決めます。「サービスの理解」であれば1ページの長さとスクロール量、最適な文章量とビジュアル表現などの検討用にプロトタイプを作るべきですが、「資料請求をしてもらう」とするならば資料請求ボタンを押すまで如何に敷居を低く簡単に案内してあげるのかを検討するためのプロトタイプをつくるべきです。

また、言うまでもありませんが、一番もったいないのは検証することがないのに何となく流れでプロトタイプを作ってしまうことです。要の機能に関連している箇所でも検証する必要がないのであれば、プロトタイプを作成する必要はありません。

検証したいことを具体的にしなければいけなかった

目的を持ってプロトタイプを作成しても、検証したいことの定義が抽象的だと開発メンバーやクライアントとのディスカッションのポイントがずれてしまいました。
例えば、上述した例の引き続きでお話すると、「資料請求をしてもらう」ためにお問い合わせフォームの入り口からフォームの完了ボタンまでのフローで検証したいことを「使い心地」とかにすると（これはちょっと極端ですけど）、「フォームに入力するのに面倒くささを感じさせない検証」なのか「フォームに不慣れな人がわかりやすく使えるための検証」なのか、みんなそれぞれの視点から色々な意見が飛び交います。そして実際にその意見をとりまとめてプロトタイプをブラッシュアップしようとすると、なんだかとってもカオスなことになるのは、きっと想像がつきますよね。

1つの機能の中にも確認したいことがたくさんあります。ただ、確認したいことがたくさんあるが故に、それらに共通する抽象化したお題を検証に持ってくると混乱を招きました。1つのプロトタイプで1つしか検証してはいけないという話ではありません。実装やディスカッションの時に検証したいこと、確認してほしいことを具体的に明確に伝えられたのか、ということが重要でした。

「今回のプロトタイプでは、ターゲットユーザーである"企業のマーケティング担当者"がお問い合わせをするのに面倒に感じない入力項目を検証します」などの具体的なお題があれば「企業のマーケティング担当者は忙しく外出してることも多いだろう。その場合、スキマ時間でこのようなお問い合わせフォームを使うことが想定されるが、スマートフォンでは自由入力はつらいのではないか。」など、ブラッシュアップに活かせそうな意見を引き出せるのですが、お題が抽象的だと「使い心地はあまり良くない。面倒くさいと感じる。」など抽象的なものが返ってきてしまいました。何を検証したいのか、何のためにプロトタイプを作ったのか、ここに具体的な意思を持たなければいけません。

まとめ

いかがだったでしょうか。読んでいると「けっこう当たり前じゃん」と感じるかもしれませんが、プロジェクトの渦中にいると中々分からないものでした。もちろん私の経験則で書いているので、うまくはまる人はまらない人もいるかと思います。これからプロジェクトにプロトタイプを導入しようと考えている人は、こういう事例や考え方があるんだと参考になればうれしいです。