新しいWebアプリを作ろうとしたとき、まず何をするか。多くの場合、要件をまとめて、見積もりを取って、仕様書を作る。そこまではごく当たり前の話だと思う。
ただ、僕がこれまで何度も目にしてきたのは、その段階で「やるかやめるか」を決めてしまうケースだ。仕様書に書かれた文字列と、見積もりの金額だけを見て、Go/No-Goを判断する。
これが想像以上にリスクが高い。
文字だけでは「使い心地」が見えない
仕様書には画面の構成や機能の説明が書いてある。でも、実際にそれを触ったときの感覚は、文字からは伝わらない。「一覧画面があります」と「一覧画面をスクロールして目的のデータにたどり着けます」は、まったく別の話なんですよね。
ボタンの位置ひとつで操作の流れは変わるし、画面遷移の速度ひとつでユーザーの印象はがらりと違う。これらは仕様書に書きようがないし、書いたとしても読む側の解釈は人それぞれになる。
だから「仕様書で合意したはずなのに、出来上がったものが期待と違った」という事態が起きる。合意した事実はある。でも認識はズレていた。そういうパターンは珍しくないと思う。
見積もりの数字が判断を歪める
もうひとつ厄介なのが、見積もりの金額が判断を支配してしまうこと。
300万円という数字を見た瞬間、頭の中は「この投資に見合うか」に切り替わる。機能の中身や使い勝手の話はどこかに行ってしまって、コストパフォーマンスの議論だけが残る。「300万円なら3ヶ月で元を取れるか」とか、そういう話になりがちだな、と。
もちろんコスト判断は必要だ。でもそれは、何を作るかが明確になってからの話じゃないかな。何を作るかが曖昧なまま金額だけで判断すると、結果的に「安かったから進めたけど使われなかった」みたいなことが起きる。
実物を見てから判断するという選択肢
僕が「なのかデモ」というサービスを始めたのは、この問題をどうにかしたかったからだ。
やり方はシンプルで、本開発に入る前に、7日間で動くデモを作る。ブラウザで実際に触れるWebアプリのプロトタイプを先に用意して、それを見てから「進めるか、やめるか」を決めてもらう。
仕様書を何回レビューしても見えなかったことが、5分触るだけで見えたりする。「この画面、思ったより使いにくいな」「あ、この機能いらないかも」「ここはもっとシンプルでいいね」。そういう判断は、実物がないと出てこない。
やめる判断も立派な成果
デモを見た結果、「やっぱりやめよう」となっても、それは失敗じゃない。
本開発に数百万円かけた後に「これ違ったね」と気づくよりも、デモの段階で方向転換できたほうがずっといい。むしろ、やめる決断を早い段階でできること自体に価値がある。
判断の精度は、手元にある材料の質で決まる。文字だけの材料と、実際に触れる材料。どちらが判断しやすいかは明らかだと思う。
発注前に確認しておきたいこと
アプリ開発を外注しようとしている人に、ひとつだけ伝えたいことがある。
仕様書と見積もりだけで判断しようとしていないか、一度立ち止まって考えてみてほしい。実物を見る手段があるなら、見てから決めたほうがいい。
それが7日で手に入るなら、試してみる価値はあるんじゃないかな。