「面白いサービスだと思ったけど、具体的にどう使えばいいのかわからない」。なのかデモについて、そういう声をもらうことがある。サービスの仕組み自体はシンプルなんだけど、初めてプロトタイプ検証をやる人にとっては全体像が見えにくいのかもしれない。
この記事では、リクエストの出し方から、デモを受け取った後にどう活用するか、本開発に進む場合と進まない場合それぞれの流れまでを書いておく。
なのかデモとは何をするサービスか
ひとことで言えば、Webアプリのプロトタイプを7日間で作るサービスだ。
「こういうアプリがほしい」というリクエストを受けて、ブラウザで実際に操作できるデモを作る。仕様書や設計書の代わりに、動くものを先に見てもらって、本開発に進むかどうかの判断材料にしてもらう。
ポイントは、これが「開発の契約」ではなく「判断のための検証」であること。デモを見た結果「やっぱり違うな」と思ったら、そこでやめていい。むしろ、やめる判断を安全にできることがこのサービスの価値だと僕は思っている。
リクエストの出し方
フォームからリクエストを送ってもらうんだけど、ここで完璧な要件定義は必要ない。むしろ、固まりすぎていないほうがいい場合も多い。
書いてもらいたいのは、大きく3つ。
まず「誰が使うのか」。社内の営業チームなのか、お客さん向けなのか、経営層が見るダッシュボードなのか。ここがはっきりしているとデモの方向性がブレない。
次に「何に困っているのか」。Excelでの集計に毎週3時間かかっている、顧客からの問い合わせ対応が属人化している、といった具体的な困りごと。機能の羅列よりも、課題の記述のほうがデモの精度が上がる。
最後に「どうなったら成功か」。作業時間を半分にしたい、誰でも対応できるようにしたい、といったゴール。ざっくりでいい。
逆に、書かなくていいこと。画面のワイヤーフレームや、データベースの設計や、技術的な要件。そのあたりはこちらで考える。
7日間で何が起きるか
リクエストを受けたら、僕のほうで内容を整理して、デモの構成を決める。その過程で不明点があれば確認の連絡をすることもあるけれど、基本的に7日間はこちらで手を動かしている。
作るのは、ブラウザで操作できるWebアプリのプロトタイプだ。見た目だけのモックアップではなく、ボタンを押したら画面が遷移して、データを入力したら保存される。実際のアプリに近い操作感を体験できるレベルのものを目指している。
7日後にURLを共有するので、PCやスマホのブラウザからアクセスして触ってもらう。インストールは不要だし、特別な環境も必要ない。
デモを受け取ったらやるべきこと
デモのURLが届いたら、まず自分で触ってみてほしい。5分で構わない。仕様書を読むのとは全然違う感覚で、「ここは使いやすい」「ここは違和感がある」が直感的にわかるはずだ。
その次にやってほしいのが、実際に使う人に触ってもらうこと。経営層だけで判断すると、現場とのギャップが後から問題になる。営業チーム向けのツールなら営業メンバーに、バックオフィス向けなら経理や総務のスタッフに、5分でいいから触らせてフィードバックをもらう。
ここで集まる声が、本開発の判断材料として一番価値が高い。「これは毎日使いたい」なのか、「悪くないけど今のやり方で十分」なのか。リアルな反応は、仕様書のレビュー会議では絶対に出てこない。
社内での見せ方のコツ
デモを社内で共有するとき、ひとつアドバイスがある。「完成品」として見せないこと。
「これは検証用のデモで、本開発前に方向性を確認するためのもの」と前置きする。そうしないと、デザインの細部や機能の不足に対するフィードバックばかりが集まってしまう。見てほしいのは細部ではなく、業務の流れとしてこのツールが機能するかどうか、という大きな方向性だ。
予算会議や役員報告で使う場合も同じで、「これに300万かけて本開発する価値があるか」の判断材料として位置づけると、議論が建設的になる。
本開発に進む場合
デモを見て「これをちゃんと作りたい」と判断したら、次のステップに進む。デモの段階で得られたフィードバックを踏まえて、本開発の要件を固めていく。
ここでの利点は大きい。「動くもの」をベースに話ができるので、仕様の認識ズレが起きにくい。デモで「ここは違う」と感じた箇所は既に洗い出されているし、「ここは想像以上に使いやすい」という箇所はそのまま踏襲できる。ゼロから仕様書を書くのと比べて、本開発の手戻りリスクが格段に小さくなる。
開発会社の選定にもデモは使える。「こういうものを作りたい」と口頭で伝えるよりも、「このデモをベースに本開発してほしい」と見せたほうが、見積もりの精度が上がるし、認識のズレも起きにくい。
本開発に進まない場合
デモを見て「やっぱり今じゃないな」「思ったほど効果がなさそうだ」と判断することもある。それはまったく問題ない。
本開発に数百万円を投じた後で「使われない」と気づくよりも、デモの段階で撤退できるほうがずっと合理的だ。判断材料が増えた結果として「やめる」を選べたのだから、検証は成功している。
デモで得た気づきは、半年後や1年後に改めてシステム化を検討するときの資産になる。「あのとき触ってみて、ここが課題だとわかった」という経験は、次の判断を確実に精度よくする。
まとめると
なのかデモの使い方は、3ステップで整理できる。リクエストを出す、デモを社内で触って回す、進むか止まるか判断する。どのステップでも、完璧である必要はない。リクエストは粗くていいし、フィードバックは直感でいい。判断は「やめる」でも全然いい。
大事なのは、数百万円の意思決定をする前に、実物に触れる機会を作ること。それだけで判断の質は変わる。