近年、モバイルアプリの作成プロセスは大幅に進歩しました。以前は、アプリ開発は着想、デザイン、開発、ユーザーテストという一連のサイクルを経て行われました。 今日ではユーザーテストが占める割合が大きくなり、デザイナーも開発者も着想の段階で既にアイデアの有効化が必要になっています。
アプリのアイデアとデザインを有効化するのに最も実用的なやり方は、プロトタイプすることです。正しく行えば、プロトタイプは時間とお金の両方を節約してくれます。ですから、ラピッドアプリプロトタイピング、つまりアプリのプロトタイピングプロセスをいかに速く回せるかが、現在のアプリデザインおよび開発においてのキーとなります。
これからラピッドプロトタイピングとは何か、そして何故ラピッドプロトタイピングが必要なのかについて考え、アプリ作成プロセスを改善するためのヒントを５つ紹介したいと思います。
ラピッドプロトタイピングとは？
プロトタイプは、概念実証、MVP（Minimum Viable Product＝最低限の機能をもった製品）、モックアップ、ワイヤーフレームなど、様々な単語と同義にされがちです。あなたが以上のうちどれを指していても、その目的は皆同じです。
つまり、実際のユーザーでテストするために実際の製品版に近いものを作成することです。これは、見せることが説明することよりも効果的だという考えに基づいています。従ってラピッドプロトタイピングは、変更もテストも簡単に出来るアプリの初期バージョンを手早く作成し、実験を繰り返すことを指します。
何故ラピッドプロトタイピングなのか？
ラピッドプロトタイピングが現在アプリ作成において重要な部分を占めるのにはしかるべき理由があります。
まずはアプリにおけるプロトタイピングはお手軽だということです。アプリは手持ちのデバイスのスクリーンに収まるバイトサイズのソフトウェアですし、基本的には軽量でタスクもはっきりしています。
もし飛行機のプロトタイプを作るとなれば、ハリウッド映画の大道具のようなものを作らねばなりません。それではラピッド（迅速）とは言えませんね。
ラピッドプロトタイピングは大幅にコストとリスクを削減します。アプリをゼロから作成し、アプリの主要機能がユーザーが求めているものと違ったら無駄になります。デザイナーも開発者も作業のほとんどをやり直さなければならないでしょう。ラピッドプロトタイピングなら、開発プロセスの初期段階でアプリをユーザーに手渡し、上記のリスクを回避することが可能です。ユーザーフロー、UI要素、新機能をテストできますし、変更も簡単なので、テストに耐えうることが証明されるまで何度でも再テストすることが出来ます。
ですが、実のところこのプロセスは言うは易し、行うは難し、なのです。ここで紹介する５つのヒントは、効果的なラピッドプロトタイピングを行うためのガイドであり、あなたのアプリが市場で成功を収める手助けとなるでしょう。
１. 失敗を喜びとする
ラピッドプロトタイピングは、実際のアプリがリリースされるまでに失敗する余地を沢山与えてくれます。テストをやっていく中で何がうまくいくか解明するまでは失敗は屈辱なものですが、実際にはありがたいものなのです。アプリを最後まで完成させる以前から、新しいことを試行し、有意義なフィードバックを得てデータ駆動型の決定をすることが可能になります。これがラピッドプロトタイピングのメリットの一つであり、全身全霊をかけ掴みとらなければならないものです。
失敗してもその失敗を喜びとして下さい。がっかりしないで下さい。あなたのプロトタイプは破棄してもいいものであって、目的達成のための手段に過ぎません。ですからそのように取り扱って下さい。最初のデザインが問題なしということはまずあり得ませんし、それはリリースされたソフトウェアの最初のバージョンにバグがないなんてことが滅多にないのと同じです。
失敗を軌道修正してより良い物を作るための機会だと見ることが出来れば、ラピッドプロトタイピングのメリットについて納得できるでしょう。
２. 再利用すること、そして再利用可能なものを作成することを念頭に置くこと
あなたがプロトタイピングのフェーズにある場合は、前回デザインから引き継いだテンプレートやUIエレメント、パターンを再利用してみて下さい。今回ように新しいUIを作成しなければならないこともあるでしょうが、その場合は再利用を出来るものを作成することを念頭に置いて下さい。
この段階では速さこそが全てであり、プロトタイピングに費やしている時間をデザイン細部を洗練することに割いてはいけないからです。細部がテスト項目の本質に関わらない場合は特にそうです。
Proto.io のようなラピッドプロトタイピングツールは、UIコンポーネントが最初から組み込まれているので、いくつかのアプリスクリーンと組み合わせることは数時間で可能です。これはユーザーフローやコンテンツレイアウトをテストする際にとりわけ便利です。これならボタンを10px大きくしたい、または小さくしたい、などといった細かい点は問題ありません。
開発者コミュニティのとある本にはこうありました：自分で同じ作業を繰り返すのはいけない、可能な限り再利用すべきである。
３. 全てをプロトタイプしようとしないこと
ラピッドプロトタイピングはあっと言う間に立派なプロジェクトへと進化します。プロトタイピングとテストが順調に進む中で、何でもテストしなければ、という意識になってしまうこともあるでしょう。気づけば１アプリをまるごとプロトタイピングしているかもしれません。
プロセスを開始する前から、何をプロトタイプしなければならないかを綿密に計画しておいて下さい。複雑なフィーチャーを注意深く管理し、必要な場合はいくつかのプロトタイプに分割して下さい。
例えば複雑な検索機能は可能なシナリオが何重にもなる場合があります。必要な場合はそれぞれのシナリオを別個に組み立て、後から組み合わせた方が、実際のアプリのシミュレーションとしてはより適しています。
いつでもそれぞれのプロトタイプの目的に焦点を定めて下さい。ラピッドプロトタイピングの目的は、当然ながらフィードバックを得ることにあります。しかし、得るのは誰のフィードバックでしょうか？ どのようなフィードバックですか？ プロトタイプを見せる相手がユーザーとクライアントと投資家では状況が著しく異なります。それぞれに求める誠実さのレベルが異なります。プロトタイプは誰に見せるべきかビルドする前に決めておいて下さい。
４. 全員と作業すること
ユーザーからビジネスのステークホルダー、アプリ開発者までラピッドプロトタイピングのプロセスはその全員と協力して努力するものです。スピードを求めるあまり、プロセスをユーザーとのテストだけに絞ってしまいがちだと感じることがあるかもしれません。しかし時には、会社の重役も開発者も、フィードバックとして何を求めているかを正確に理解した上で貴重な洞察を与えてくれる場合もあるのです。彼らはまた、アプリのオーナーシップをより強く感じてくれるでしょう。
ネイティブアプリではなくデザインツールを使ってプロトタイピングをしている場合は、ラピッドプロトタイピングのプロセスに あなたの開発者を早い時期から関わらせましょう。何度も繰り返しをしてやっと各機能の仕上げに奮闘する段階で、開発者が申し訳無さそうにあなたを見て「申し訳ありませんが、これは技術的に不可能です」などと言う事態は避けたいですよね。
プロセスの各フェーズで期待値と締め切りを設定して下さい。開発者やその他のステークホルダーとの短いミーティングを定期的に行うことを計画しておいて下さい。彼らには、これはあくまでラピッドプロトタイピングであることを確認し、自分はそれをラピッド（迅速）に行うのであまり長い時間を取らせるつもりはないことを伝えて下さい。
５. インタラクションを最後まで後回しにしないこと
インタラクションデザイン はモバイルアプリを生かしも殺しもします。あなたのアプリにユーザーが何かした際に起こることは、そのアプリを使うときの全てのエクスペリエンスに影響します。アプリの動的なプロトタイプを静的なモックアップに優先する重要なメリットは、前者のモーションやインタラクションの有用性を検証できるところにあります。
ネイティブアプリでプロトタイプを組み立てる場合、ラピッドプロトタイピングフェーズ中は静的なものに留めておきたいと考えるのは理解できます。インタラクションを記録するのは少々面倒くさいものです。UIアニメーションやスクリーントランジションのコーディングにあまり多くの時間をかけたくはありません。ラピッド（迅速）な状態を維持したいわけですから。
しかし、それではあなたのアプリデザインにおけるキーとなる要素、つまりあなたのアプリをその他大勢から真の意味で突出させるということを忘れてしまっていることになります。
この難問を解決する一つの方法としてProto.ioのような、完全インタラクティブプロトタイプの作成に耐えられるぐらいにパワフルなラピッドプロトタイピングツールの使用が挙げられます。
こちらはProto.ioでPandoraというアプリの再現をした例です（実際タップできます）。Proto.ioの15日お試しはこちらから。
