プロトタイプの作り方とは？モックアップやMVPとの違い【ツール】

ウェブサービスを開発しても、使われないことがあります。せっかくつくったのに使われないのは、開発者としてとても心苦しい状況です。集客をがんばって一時的にユーザーがふえたとしても、なかなか継続してくれません。この原因のほとんどは、開発する前に解決策を検証していないためです。

解決策とはつまり「ユーザーの課題をどう解決するか」ですが、この解決策を開発前に検証することで、使ってもらえる可能性を大きく高めることができます。この解決策の検証に用いるのがプロトタイプです。この記事では、プロトタイプとはなにか、つくる目的やつくりかたについて書いていきます。

Hiroki Zenigami

テクニカルライター。元エンジニア。共著で「現場で使えるRuby on Rails 5」を書きました。プログラミング教室を作るのが目標です。

Follow @zenizh

プロトタイプとはなにか

プロトタイプとは試作品という意味ですが、プロダクト開発においてはどういう解決策を提供するのかが視覚的にわかるものをいいます。プロトタイプを使うのは主にユーザーインタビューのときです。ユーザーがプロトタイプを使ってみて、「このプロダクトは自分のこの課題をこうやって解決してくれるのか」と思えるような、プロダクトの意図が伝わるようにつくります。

ペーパープロトタイプ

プロトタイプにはいろんな種類があります。その中でもかんたんに作成できて修正しやすく、プロダクト開発にもっとも適した手法がペーパープロトタイプです。ペーパープロトタイプはその名のとおり紙でつくった試作品です。ノートにペンで画面を書いていきます。これだけでも十分「プロダクトがどういう解決策を提供するのか」がわかります。

ペーパープロトタイプをユーザーに見せて、必要に応じて修正していくことで解決策を継続的に改善することができます。

なぜプロトタイプをつくるのか

プロトタイプは、プロダクトが提供しようとする解決策を検証するためにつくります。プロダクトのつくりかたとしては、はじめにアイデアを出し、ユーザーの課題を検証し、課題の解決策を検証した上で開発に入ります。

課題や解決策の検証前に開発に入ってしまうと、「本当にその解決策でいいのか？」がわからないまま開発することになります。つくっても結局使われなかったら、開発した時間が無駄になってしまいます。

開発に入る前にしっかりと解決策を検証して、「この解決策ならユーザーは使ってくれる」ということを確認した上で開発に入るべきです。この検証をする上で重要な手法がプロトタイプです。

プロトタイプの完成度を高める

解決策をプロトタイプとしてつくり、ユーザーインタビューでプロトタイプを使ってもらいます。解決策に問題があればプロトタイプを修正し、またインタビューします。このプロセスを繰り返すことでプロトタイプの完成度が高まり、開発しても失敗しづらい解決策ができあがるのです。

プロトタイプは、プロダクトが提供しようとする解決策を検証し、実際に開発するときの手戻りをなくしたり、よりよいユーザー体験を提供できるという役割をもっています。

プロトタイプのつくりかた

では、プロトタイプの具体的なつくりかたについて書いていきます。

ユーザーストーリーマップを準備する

プロトタイプをつくるときは、まずユーザーストーリーマップを準備します。プロトタイプは「解決策をどう画面にするか」なので、まずプロダクトがどういう画面をもつかを整理しておく必要があるのです。

ユーザーストーリーマップはプロダクトにおけるユーザーの行動を整理したものです。これをもとにプロトタイプをつくります。ユーザーストーリーマップについては、「ユーザーストーリーマップの書き方」をご覧ください。

ペーパープロトタイプをつくる

次にプロトタイプのつくりかたです。ここではペーパープロトタイプのつくりかたについて示します。ペーパープロトタイプは、紙とペンを用意し、ユーザーストーリーマップをもとに画面を書いていきます。

このとき、どの画面を紙に書けばよいのでしょうか。書く画面は、「この画面がないとプロダクトとして成り立たない」というような、プロダクトの主要な画面、主要な機能だけを書きます。また、画面や機能自体もできるだけシンプルに書きます。すべての画面、たとえば利用規約だったりヘルプページまで書く必要はありません。

プロトタイプでやりたいことは、プロダクトの主要な機能がそれでよいのかどうかを、ユーザーインタビューをとおして検証することです。細かいところは一旦無視しましょう。ひとつだけでなく、いくつかのパターンをスケッチしてみます。もっとも課題をシンプルに解決できているものをプロトタイプとして採用します。