こんにちは。エンジニアの川島です。
都内はすっかり梅雨入りしましたね。今年の春は一瞬で過ぎ去ったような気がします。

さて、ノンスタのWebアプリ開発フローについてご紹介する特集、第四回です。
前回の記事では、課題の前提条件を検証する手法「ジャベリンボード・KJ法」を紹介しました。ここまでの一連で、「誰の、どんな課題を解決するのか」は明確になりつつあります。次は、「何によって、その課題を解決するのか」を掘り下げてゆきます。

「何を作るのか」を決定する過程においても、検証はとても大切です。
課題も想定ユーザーも前提も確かめられたからと、早々にアプリ制作に取り掛かったとしても、完成したアプリの使い心地が悪かったり、ユーザーの求めていない機能が中心になったりしたら——そのアプリが広く受け入れられることはありません。

そこで、私たちは、まずプロトタイプやMVP（※Minimum Viable Product＝必要最低限の機能を備えた製品）を作り、開発着手前にユーザーから意見を聞く工程を設けています。
この段階で、ユーザーに求められる機能を検証しておくことで、着手後の手戻りやリリース後の失敗を減らし、より効率的にアプリを制作できます。

プロトタイプの種類と特徴

Webアプリにおけるプロトタイプとは、文字通り、アプリにとっての試作品を指します。
プロトタイプにも様々な種類があり、完成度も一様ではありません。
アプリ制作において用いられるプロトタイプには、たとえば下記のようなものがあります。

開発が進み始めてから、後追いで画面を変更したり機能を追加したりすると、いったん作り込んだデザインやプログラムが無駄になるだけでなく、再設計による費用増加や、納期の遅れが避けられません。
その点、プロトタイプは試作を前提としたものです。実作よりもずっと短期間で作成と修正を繰り返せるため、ユーザーの意見を取り入れながら、存分に機能や画面の試行錯誤を行えます。開発着手まで時間はかかりますが、手戻りやリリース後の失敗が少なくなるぶん、結果的には効率的なのです。

発注者にとってのプロトタイプのメリット

また、アプリ制作を発注するクライアントの方にとっても、プロトタイプ工程を挟むことで、実際に制作されるアプリのイメージを持ちやすいというメリットがあります。

会議を重ね、設計図やデザインを何度となく確認していても、それだけでアプリの動作を思い描くのはなかなか難しいものです。
プロトタイプは実際に触って確かめられるため、画面遷移などの動作がぐっとイメージしやすくなっています。「この動作はいらない」「あの機能はメニューから飛べた方が便利」など、新たな課題が見つかっても、この段階ならばスムーズに要件として盛りこむことができます。開発後に「なんだか思っていたのと違う」と修正するより、費用と工数はずっと少なくなります:)

設計の過程を可視化する「プロトタイプカンバンボード」

そんなプロトタイプにも、設計の工程が必要です。
ここまでの検証過程で生まれたアイデアを何もかも詰めこんだら、プロトタイプは破綻し、ユーザーからフィードバックを得ることも難しくなってしまいます。
機能の取捨選択や、画面レイアウト設計を経てこそ、プロトタイプは検証に適した土台になるのです。

プロトタイプ設計を進めるにあたって、私たちは「プロトタイプカンバンボード」を活用しています。
プロトタイプカンバンボードとは、田所雅之さんの著作『起業の科学』で紹介されている、プロトタイプの作成・検証に最適化されたカンバンの運用手法です。

カンバンにはホワイトボードが多く用いられますが、私たちはnotionというワークスペースアプリを活用しています。メンバー一人一人の操作がリアルタイムで同期されるため、大きな画面で一つのボードを見ながら、手元のパソコンでカードを記入・移動することできます。
以下は、私たちがnotion上で実際に運用しているプロトタイプカンバンボードです。

効果的な工程でプロトタイプ作成を進める

プロトタイプカンバンボードは、ボードに沿って作業を進めることで、効率的にプロトタイプを作成できます。
その作業フローは、大まかに三つのステップに分けられます。

本当に必要な機能の検証

一つ目のステップでは、プロトタイプに組み込むべき機能の取捨選択を行います。
ここまでの検証で明らかになった課題のカードを、起点となるレーンに配置し、チーム内で課題の解決策をブレストします。そして、リストアップされた解決策のうち、本当に必要と思われる機能のカードを取捨選択し、二つ目のレーンに配置します。

この段階で、ボードには「解決すべき課題」「必要と思われる機能」の情報が出揃いました。
これならすぐに設計へ進めそうですが、ここで一度、ユーザーへのインタビューを行います。
私たちが必要と考えている機能が、本当にユーザーによって喜ばしいものなのか、どの機能がもっとも必要とされているのかなどを、インタビューを通じてさらに検証します。

インタビュー結果が出揃ったら、ユーザーの需要が確かめられた機能のカードに優先順位をつけ、三つ目のレーンに配置します。
これで、アプリに盛り込むべき機能の枠組みが見えてきました:)

プロトタイプ設計・作成

アプリに盛り込む機能が決まったら、次のステップに進み、プロトタイプの画面設計を行います。
この段階でデザインに取り掛かる訳ではなく、あくまでも、画面に配置する要素の設計です。
最初の画面では何が可能なのか、優先度が高い機能がどの画面からアクセスできるようにするのか、アプリ全体の画面遷移はどのようにするのか……など、いくつかの設計案を作成します。

設計案の情報は、四つ目のレーンに配置します。
そして、設計案が出揃ったら、案に基づいてペーパープロトタイプを作成します。
これはチーム全体で行い、作成できたペーパープロトタイプの情報は、五つ目のレーンに配置します。
※ペーパープロトタイプ作成については、次回の特集記事で詳しく紹介予定です

ペーパープロトで、アプリのおおよその形が見えてきたら、より詳細なツールプロトタイプに落とし込みます。
ツールプロトは、スマートフォンやPCを実際に操作しながら画面遷移などを確かめることが可能です。こちらの情報は六つ目のレーンに配置します。

プロトタイプインタビュー

最後のステップでは、ふたたび、ユーザーインタビューを行います。
前ステップで作成した、実物に近い操作感を持つツールプロトに触れてもらい、操作上の疑問点や、不満点がないかどうかを検証します。
ユーザーのフィードバックに基づいてプロトタイプを修正するのはもちろん、もし新たな機能を取り入れた方が良さそうであれば「必要と思われる機能」のレーンにカードを追加し、改めてプロトタイプ設計の工程を繰り返します。

これらのステップを実作で行えば膨大な時間が必要ですが、プロトタイプなら短期間で作成できるため、インタビューと修正を繰り返しながら、よりユーザーに必要とされるアプリへ近づけてゆくことができるのです。

おわりに

「プロトタイプ」というと、なんだか機械っぽいというか、Webとはあまり関わりがなさそうに感じられるのではないでしょうか。実際のところ、私たちも、Webサイトの受託制作においてはプロトタイプ工程を設けていません。

ただ、情報提供が主目的であるWebサイトとは違って、Webアプリには様々な目的があり、それを叶えるための機能が必要です。
会員登録、ログイン、決済、メッセージのやりとりなど……その多くは開発・デバッグに時間が掛かります。
そのため、開発が進んでから「やっぱりこの機能はいらなかった」「代わりにあの機能が欲しい」という状況になったとき、容易には方向転換ができず、発注してくださった方にも私たちにも負担が発生してしまいます。

だからこそ、Webアプリ制作では、実作よりもずっと短期間で制作できるプロトタイプが効果を発揮します。
プロトタイプを用いて機能・画面の試行錯誤を繰り返し、この段階でユーザーの声を存分に取り入れることは、遠回りのように見えても、よりユーザーから求められるWebアプリの効率的な制作に繋がっているのです。

本記事ではプロトタイプの特徴と、運用手法としてのプロトタイプカンバンボードについて紹介しました。
次回は、具体的なプロトタイプの作成手順、「ペーパープロトタイプ」をご紹介します。