闇雲なトライ&エラーは禁物 – 意思決定につながるプロトタイプ開発の進め方

昨今、ローコードツールやUI/UXデザインツールの開発・普及によって、システム開発やデザインの民主化が進んでいます。スピーディーかつ安価な開発が可能になったことで、プロトタイプ開発へのハードルは非常に低くなっています。

新規事業開発では、リスクを下げるために、プロトタイプ開発を行うことが多々ありますが、闇雲に取り組んでしまうと、かえってコストや時間を無駄にすることになります。
そこで本記事では、プロトタイプ開発を成功に導くためのポイントをお伝えします。

プロトタイプ開発とは

新しいプロダクトの開発にはリスクがつきものです。特に今までにない価値軸で勝負をする抜本的なイノベーションの場合、不確実性が高いため、いきなり多額の投資をしてプロダクトを開発しても、全く売れない可能性があります。

このようなリスクをあらかじめ避けるために、プロダクトの試作品を開発し、ターゲットユーザーや内部関係者が確認・評価をすることで、仕様を固めていく開発プロセスをプロトタイプ開発と言います。

実施タイミング

プロトタイプ開発は、プロダクトの有効性を判断したり、仕様を確定するために行います。したがって、デスクリサーチやインタビュー、アンケート調査等を通じて、ターゲットユーザーが抱える課題や解決策の方向性に関して、一定以上の確信が得られた後、プロトタイプ開発に取り掛かることが一般的です。

ただし、

• ターゲットの課題が潜在的で言語化されにくい場合
• 解決策がこれまでと大きく異なり、言葉でイメージを伝えることが難しい場合
• プロトタイプを安価で開発できる場合

などでは、早い段階からプロトタイプを開発し、ターゲットユーザーに提示しながら、ニーズの深堀や改善点等を聞き出すこともあります。課題や解決策の蓋然性に加え、言語化やイメージ伝達の容易性、費用やスケジュールなども踏まえて、プロトタイプ開発のタイミングを検討しましょう。

プロトタイプの種類と手法論

プロトタイプには、アナログなプロトタイプやデジタルなプロトタイプなど、制作方法やそのアウトプットのレベルは様々です。「何を検証したいのか、検証結果をどのように生かしたいのか」によって、適したプロトタイプは異なります。本記事ではプロトタイプを、機能型、デザイン型、コンセプト型に分類し、簡単にご紹介します。

• 機能型
  機能型のプロトタイプは、プロダクトの機能の確認を目的とするものです。実際に画面上でどこをどうすればどのように動くのか、などを確かめることができるため、主要な機能に漏れがないか、認識が間違っていないか、などを早期に確認することができます。
  例：インタラクティブワイヤーフレーム、ノーコード/コードプログラミング

• デザイン型
  デザイン型のプロトタイプは、プロダクトのデザインの確認を目的とするものです。見やすさや操作のしやすさなどを早期に確認することができます。
  例：ペーパーワイヤーフレーム、モックアップ

• コンセプト型
  コンセプト型のプロトタイプは、プロダクトの魅力やユーザーの利用イメージなどを、ランディングページや動画で紹介することで、ストーリーや新しい価値に対する共感の大きさなどを確認することができます。
  例：ストーリーボード、コンセプトムービー

このように、プロトタイプのアウトプットの種類は様々です。プロトタイプを開発するにも負担は少なからず存在するため、「ワイヤーフレーム」や「モックアップ」など、簡単な設計書に留め、ターゲットユーザーや内部関係者からのフィードバックをもとに認識齟齬を避けることもできます。検証の目的や求められる精度を加味して、プロトタイプの検討を進めていきましょう。

最近では、デザイン初心者やプログラミング未経験の方もプロダクトの設計・開発ができる優れたツールが充実しています。プロトタイプ開発を効率的/効果的に進めるために利用されている、人気のツールをご紹介します。

▼UIデザインツール

• Adobe XD
  WEBサービスのワイヤーフレームやデザインモックの制作に加え、ブラウザ上で画面遷移などの動きが確認できる人気のUIデザインツールです。Adobe XDで制作したデータを連携し、Adobe PhotoshopやIllustratorでそのまま編集することも可能です。
  https://www.adobe.com/jp/products/xd.html

• Sketch
  操作性やプラグインによる機能の豊富さなどが優れているUIデザインツールです。多種多様なテンプレートが用意されており、iOSアプリを通して、すぐに実機確認をして検証を進めることもできます。ただし、利用できるOSはmacOSに限られているため、Windows環境では利用できないという点には注意が必要です。
  https://www.sketch.com/

▼ノーコード開発ツール

• Glide
  Google スプレッドシートをデータベースとして活用し、プログラミングの知識がゼロでも手軽にアプリの開発を行えるノーコード開発ツールです。様々なテンプレートやデザインが用意されており、デザイン初心者でも十分なレベルのアプリ開発が可能です。
  https://www.glideapps.com/

• Adalo
  豊富なテンプレートや機能をもとに、直感的な操作で簡単にアプリ開発ができる、ノーコード開発ツールです。WebアプリとAndroid・iOS向けのネイティブアプリの両方の開発ができることが特徴で、Webからの利用だけでなく、Google PlayやApp Storeに登録して配信も可能です。
  https://www.adalo.com/

• Yappli
  Android・iOSのスマホ向けネイティブアプリ開発に適したノーコード開発ツールです。アプリの運用や高度な分析もワンストップで行うことができます。継続率99%、450社以上の導入という人気かつ信頼性の高いツールです。
  https://yapp.li/

• Shopify
  デザイン性や機能性に優れたECサイトを構築できるノーコード開発プラットフォームです。Shopifyはサブスクリプションモデルで、ECサイトを開設できる容易さが評価されています。
  https://www.shopify.jp/

プロトタイプ開発で起こり得る問題点

プロダクトに対するターゲットユーザーからの反応や内部関係者の認識齟齬の解消を早急に行えるという点で、プロトタイプ開発は非常に有用なアプローチです。しかし、誰でも簡単かつ安価にプロトタイプを作れるようになったことで、様々な課題が顕在化してきています。ここでは（1）プロトタイプを作ることが目的化している、（2）プロトタイプに要件を盛り込みすぎてしまう、といった2つの問題点に注目し、ご説明します。

（1）プロトタイプを作ることが目的化している

誰でも開発ができ、再現性が高い優れたツールが普及したことで、プロトタイプ開発に対するハードルは非常に小さくなりました。
しかしその結果、目的を十分考えないまま見切り発車的にプロトタイプ開発に着手するケースも多くみられるようになりました。
プロトタイプはあくまで完成形となるプロダクトの仕様検討や、アイデア自体のブラッシュアップにつなげることが目的であり、プロトタイプ開発自体が目的化してはいけません。
作れるから作るのではなく、「なぜプロトタイプを作るのか」「何を検証するのか」「なぜ検証する必要があるのか」等を十分考えた上で、開発を検討すべきです。

（2）プロトタイプに要件を盛り込みすぎてしまう

「せっかく開発するのなら…」「機能を絞るのが不安だから…」といった思いから、プロトタイプであるにもかかわらず、完成形とほとんど変わらない要件をプロトタイプに盛り込みすぎてしまうケースも多くみられます。
要件を過剰に盛り込んでいる場合、ターゲットユーザーや内部関係者に対して確認するポイントが曖昧になり、検証が失敗する可能性が高くなってしまいます。また、プロトタイプ開発にかかる時間や金銭的コストも増加してしまい、プロトタイプが持つメリットも失われてしまいます。
プロダクトの主要な機能や検証が必要な要件、ターゲットユーザーの反応を引き出すために必要な情報等、必要最小限の要件に絞り、プロトタイプを設計していきましょう。

プロトタイプ開発で起こりうる問題点をご説明しましたが、これらの問題の発生を未然に防ぐにはどうすれば良いのでしょうか？
プロトタイプ開発とその検証を成功させるためには、事前の設計と事後の考察と伝達が非常に大切です。プロトタイプ開発の成功の鍵を握る「前」と「後」とは一体何なのかご説明します。

プロトタイプ開発は、「前」と「後」が大事

目的に合っていないプロトタイプは、いくらローコードツールやノーコードツールを活用して安価かつスピーディーに作れたとしても無駄になります。また、検証が失敗するだけでなく、内部関係者との認識齟齬が大きくなってしまう可能性もあります。前述したとおり、簡単かつ安価に開発できるプロトタイプだからこそ「前」の設計と「後」の考察/伝達に注意しなければなりません。

「前」の設計

プロトタイプ開発の前段階でのポイントとして、検証する仮説の明確化とプロダクトのKSF（重要成功要因：Key Success Factor）の特定〜KPI（重要業績評価指標：Key Performance Indicator）の設定を通じた、適切なプロトタイプの選定が重要になります。

例えば、「AさんのBという課題は、Cによって解決できる」のように、ひとまず大きな仮説を言語化した後、仮説の具体化/精緻化を行います。言語化をすることで、この段階でも内部関係者との認識齟齬を解消でき、仮説の検証に必要なプロトタイプの種類（機能型/デザイン型/コンセプト型）や要件が明確になります。

KSFとは、プロダクトの成功を左右する重要な要因のことで、KSFを数値化し、目標を達成する上で、その達成度合いを測るための定量的な指標がKPIとなります。KSFを設計する方法はいくつかありますが、次の3つのプロセスで設計をする方法を簡単にご紹介します。

1. 目標（ゴール）までのステップを洗い出し
2. 各プロセスを数式化
3. 自社でコントロールでき、目標達成への影響度が特に大きいものを選ぶ

例えば、クラウドソーシングサービスで売上を拡大するためには、説明のために非常に単純化しておりますが、次のように考えることができます。

1. サービスが認知され、サイト訪問者が集まり、発注とその引き受けが発生
2. 売上=成約数(発注数×成約率)×平均単価×手数料
3. 専門的知識や特殊技能を持つエキスパートの獲得

クラウドソーシングの市場には、すでに多くのサービスが存在しており、受注者数が多いことから、案件の低価格化が見受けられます。今後自動化が進み、単純作業のニーズが小さくなる可能性が高いことから、高単価な案件の獲得が鍵を握ることになりそうです。したがって、高単価な案件を生み出す「エキスパートの獲得(提携)」がKSFになると考えられます。
この場合、KPIとしては「提携数」や「案件単価」となります。

このように前段階でKSFやKPIを検討/設定することで、プロトタイプを用いた検証の評価観点/基準をすり合わせることができ、プロトタイプの要件が明確になります。

「後」の考察/伝達

プロトタイプ開発において、前段階の設計だけではなく、開発/検証後の考察や伝達といったプロセスにおいても重要なポイントが存在します。
プロトタイプを使った検証結果の取りまとめは当然重要で必要なプロセスですが、その検証結果から「事業上の意味」までを考察して初めて分析といえます。細かい仕様に対するフィードバックや、仮説の検証結果、議論の根拠となるような情報を検証で得られた場合、「仮説が立証できたこと」「根拠が見つけられたこと」「求められる仕様が明確になったこと」で満足してしまう可能性があります。得られた結果を踏まえ、「So what？（だから何か）」を常に意識し、その発見が事業に与える意味/意義を言語化するようにしましょう。

また、ネガティブなフィードバックが返ってきたときは、目を背けてしまい、ポジティブなことだけに目を向けてしまうリスクがあります。「改善点が浮き彫りになった」「プロダクトが全く評価されないことが分かった」ときは、「多額の投資を未然に防ぐことができた」と前向きに捉え、今後のプロダクトの方向性などにフィードバックしていきましょう。

その他に、行った考察結果をもとに意思決定者に伝達することも重要です。検証活動に参加していた内部関係者に対して、得られた示唆を共有/議論しながら、当プロダクトのリリースに関する意思決定者に対しても状況やスケジュール、追加検証の必要性の有無等について、スピーディーに連携を取っていきましょう。

まとめ

プロトタイプ開発はあらゆるリスクを低減するために、非常に有用な手法です。しかし、事前の設計や事後の考察/報告をおろそかにしてしまうと、作ったプロトタイプは無駄になってしまいます。開発ツールが充実している近年だからこそ、ポイントを理解し、意味/意義のある検証を行っていきましょう。