ウェブサービスを開発しても、使われないことがあります。せっかくつくったのに使われないのは、開発者としてとても心苦しい状況です。集客をがんばって一時的にユーザーがふえたとしても、なかなか継続してくれません。この原因のほとんどは、開発する前に解決策を検証していないためです。
解決策とはつまり「ユーザーの課題をどう解決するか」ですが、この解決策を開発前に検証することで、使ってもらえる可能性を大きく高めることができます。この解決策の検証に用いるのがプロトタイプです。この記事では、プロトタイプとはなにか、つくる目的やつくりかたについて書いていきます。
テクニカルライター。元エンジニア。共著で「現場で使えるRuby on Rails 5」を書きました。プログラミング教室を作るのが目標です。
プロトタイプとはなにか
プロトタイプとは試作品という意味ですが、プロダクト開発においてはどういう解決策を提供するのかが視覚的にわかるものをいいます。プロトタイプを使うのは主にユーザーインタビューのときです。ユーザーがプロトタイプを使ってみて、「このプロダクトは自分のこの課題をこうやって解決してくれるのか」と思えるような、プロダクトの意図が伝わるようにつくります。
ペーパープロトタイプ
プロトタイプにはいろんな種類があります。その中でもかんたんに作成できて修正しやすく、プロダクト開発にもっとも適した手法がペーパープロトタイプです。ペーパープロトタイプはその名のとおり紙でつくった試作品です。ノートにペンで画面を書いていきます。これだけでも十分「プロダクトがどういう解決策を提供するのか」がわかります。
ペーパープロトタイプをユーザーに見せて、必要に応じて修正していくことで解決策を継続的に改善することができます。
なぜプロトタイプをつくるのか
プロトタイプは、プロダクトが提供しようとする解決策を検証するためにつくります。プロダクトのつくりかたとしては、はじめにアイデアを出し、ユーザーの課題を検証し、課題の解決策を検証した上で開発に入ります。
課題や解決策の検証前に開発に入ってしまうと、「本当にその解決策でいいのか？」がわからないまま開発することになります。つくっても結局使われなかったら、開発した時間が無駄になってしまいます。
開発に入る前にしっかりと解決策を検証して、「この解決策ならユーザーは使ってくれる」ということを確認した上で開発に入るべきです。この検証をする上で重要な手法がプロトタイプです。
プロトタイプの完成度を高める
解決策をプロトタイプとしてつくり、ユーザーインタビューでプロトタイプを使ってもらいます。解決策に問題があればプロトタイプを修正し、またインタビューします。このプロセスを繰り返すことでプロトタイプの完成度が高まり、開発しても失敗しづらい解決策ができあがるのです。
プロトタイプは、プロダクトが提供しようとする解決策を検証し、実際に開発するときの手戻りをなくしたり、よりよいユーザー体験を提供できるという役割をもっています。
プロトタイプのつくりかた
では、プロトタイプの具体的なつくりかたについて書いていきます。
ユーザーストーリーマップを準備する
プロトタイプをつくるときは、まずユーザーストーリーマップを準備します。プロトタイプは「解決策をどう画面にするか」なので、まずプロダクトがどういう画面をもつかを整理しておく必要があるのです。
ユーザーストーリーマップはプロダクトにおけるユーザーの行動を整理したものです。これをもとにプロトタイプをつくります。ユーザーストーリーマップについては、「ユーザーストーリーマップの書き方」をご覧ください。
ペーパープロトタイプをつくる
次にプロトタイプのつくりかたです。ここではペーパープロトタイプのつくりかたについて示します。ペーパープロトタイプは、紙とペンを用意し、ユーザーストーリーマップをもとに画面を書いていきます。
このとき、どの画面を紙に書けばよいのでしょうか。書く画面は、「この画面がないとプロダクトとして成り立たない」というような、プロダクトの主要な画面、主要な機能だけを書きます。また、画面や機能自体もできるだけシンプルに書きます。すべての画面、たとえば利用規約だったりヘルプページまで書く必要はありません。
プロトタイプでやりたいことは、プロダクトの主要な機能がそれでよいのかどうかを、ユーザーインタビューをとおして検証することです。細かいところは一旦無視しましょう。ひとつだけでなく、いくつかのパターンをスケッチしてみます。もっとも課題をシンプルに解決できているものをプロトタイプとして採用します。
ユーザーインタビューをとおして修正する
このプロトタイプをユーザーに見せて意見をもらい、プロトタイプを修正します。このプロセスを何度も繰り返します。最初のころは問題がたくさん見つかり大きく修正する必要がありますが、そのうちインタビューをしても修正の必要がないタイミングがきます。
ここまでくればプロトタイプは完成です。ユーザーインタビューについては、「ユーザーインタビューのやり方」をご覧ください。
プロトタイプをツールでつくる
ここではペーパープロトタイプについて書きましたが、ほかにもAdobe XDやSketchなどのツールを使ってつくる方法もあります。ツールを用いると、たとえばPCやスマートフォンなど実機で画面を操作できます。リンクを押したら次の画面に行くなど、画面遷移まで体験できるので、より詳細な検証が可能です。
検証はしやすいですが、その分作成の時間や費用などのコストがかかってしまいます。どちらに比重を置くかによりますが、プロダクト開発ではスピードがなにより重要なので、基本的にはペーパープロトタイプでよいでしょう。
ほかの手法との違い
プロトタイプと似た用語として、モックアップとMVPがあります。ここでふたつとの違いについて整理してみます。
モックアップ
プロトタイプは試作品という意味でしたが、モックアップは模型という意味をもちます。モックアップは実際のプロダクトのような見た目をもちますが、動作はしません。モックアップは主にデザインの検証のためにつくります。解決策の検証のためにつくるプロトタイプとは、役割が明確に異なります。
MVP
MVPは実用可能な最小限の製品をいいます。MVPはそれ単体で実用的である必要があります。つまり動作する必要があるのです。プロトタイプはあくまで解決策の検証が目的です。解決策さえ体験できればよく、実用的である必要はありません。プロトタイプで解決策を検証した上で、MVPの構築につなげます。
まとめ
プロトタイプは、プロダクト開発においてユーザーの課題をよりよい方法で解決するために重要な役割を果たします。プロトタイプは、ユーザーストーリーマップをもとに紙とペンで画面をスケッチします。ユーザーインタビューをとおしてプロトタイプを何度も修正し、よりよいプロトタイプを目指します。
完成したプロトタイプをもとにMVPや実際のプロダクトをつくることで、よりよい体験をもつプロダクトにつながります。
