プレシードで作るべきものは何か

プレシードで最も多く受ける相談は、「最初にどこまで作るべきか」です。この問いに対する現実的な答えは、「多くの場合、まだ作らないほうがよい」です。作らないという結論は、開発を請け負う立場から言うと仕事を減らす話ですが、この段階で作り込んだものの大半が使われずに終わるというのは、よくある展開です。

本記事では、プレシード期に確かめるべきことと、コードを書かずに確かめる具体的な手段、そしてどこから開発が必要になるのかの境目を整理します。

この段階で確かめるのは二つだけ

プレシードで確かめたいことは、突き詰めると二つです。

1. その課題は、本当に存在するか
2. 課題を抱えている人は、解決に対価を払う意思があるか

この二つは、プロダクトの出来とはほとんど関係がありません。逆に言えば、プロダクトを作ったところで、この二つが自動的に確かめられるわけではありません。よくできた画面があるだけでは、人が対価を払う理由にはならないからです。

ここで注意したいのは、「使ってみたい」という反応は支払い意思の証拠にならないことです。無料であれば人は好意的に反応します。確かめるべきは、お金、時間、既存のやり方を変える手間といった、何かを差し出す行動があるかどうかです。

コードを書かずに確かめる三つの手段

手作業で提供してみる

最も情報量が多いのがこの方法です。将来システムがやる処理を、当面は人がやります。マッチングなら手作業で相手を探して紹介する、レポート生成なら手で作って送る、予約管理なら電話とカレンダーで受ける。

この方法の価値は、「本当に必要な処理はどれか」が身をもって分かることです。事前に設計した業務フローは、実際にやってみると使われない分岐が多く含まれています。手で回すと、毎回必要になる処理と、想定していたが一度も起きなかった処理がはっきり分かれます。その結果が、後で作るものの仕様になります。

想定例として、事業者向けの紹介サービスを構想したケースを考えます。最初に検索機能とメッセージ機能を含むシステムを作る計画でしたが、まず手作業で紹介してみたところ、依頼者が本当に欲しかったのは候補の一覧ではなく「あなたにはここが合う」という一つの結論でした。検索機能は当面不要と判断でき、作らずに済みました。

表計算ソフトと既存サービスで運用する

手作業を少し効率化する段階です。表計算ソフトでデータを持ち、フォームで受け付け、既存のチャットツールで連絡する。この組み合わせで回るなら、当面それで運用します。

この段階で覚えておきたいのは、「表計算ソフトで回っている」という事実自体が有用な情報だということです。表計算ソフトで回るなら、業務の複雑さはまだ低いということです。破綻する理由（件数、同時編集、履歴の追跡、権限）が具体的に現れたときに、その理由を解消する形で開発を始めるほうが、仕様を外しません。

説明ページと申込フォーム

課題と解決策を言葉にして提示し、反応を見る方法です。ここで重要なのは、公開する前に判断基準を決めておくことです。「どのくらいの反応があったら進める」「なかったら仮説のどこを見直す」を先に書いておかないと、結果を都合よく解釈してしまいます。

なお、まだ提供できないものを提供できるかのように書くことは避けてください。事前登録である旨を明示する、提供時期を断定しないといった配慮が必要です。表示や勧誘の適切さについては、内容によって関連する法令が異なりますので、判断に迷う場合は専門家にご確認ください。

それでも作ることに意味がある場合

作らない判断が基本ですが、例外もあります。次のいずれかに当てはまるなら、小さく作る価値があります。

• 体験そのものが仮説である場合。「この操作感なら続けられるはずだ」という仮説は、説明では確かめられません。ただし、その場合でも作るのは操作を体験できる最小の画面であり、裏側の処理は手動でも構いません。
• 手作業が明確に破綻している場合。件数が増えて回らない、ミスが起きて信用に関わる、といった具体的な破綻があるなら、その破綻を解消する範囲だけを作ります。
• 技術的に成立するかが未知の場合。連携したい外部システムがそもそも繋がるのか、必要な精度が出るのかが分からない場合は、小さく試して可否だけを確認します。この場合の成果物は、製品ではなく確認の結果です。

三つ目に関連して、AI機能を含む構想の場合も同様です。既製のAIサービスで必要な品質に届くのかは、実際のデータに近い条件で少量試せば比較的早く分かります。届かないなら構想を変えるべきですし、届くなら当面は手元で試した結果をもって進められます。この判断はシード期にAI機能を載せるべきかでも扱います。

作らない期間に何を残すか

作らないと決めた期間にも、残すべきものがあります。作っていないからといって、何も蓄積しないわけではありません。

• 話を聞いた相手と、そのとき出てきた言葉の記録。後でペルソナや画面の文言を決めるときの根拠になります
• 手作業で回したときの手順と、実際に発生した例外のリスト。これがそのまま仕様の下書きになります
• 想定が外れた点と、そのとき何を変えたかの履歴。同じ判断を繰り返さないために効きます

この記録があると、次のシードでMVPを作るときに、ゼロから要件を考える必要がなくなります。調査の進め方はスタートアップの市場リサーチ、利用者への聞き方はUXリサーチの基本手法で扱っています。

開発に移る判断のしかた

手作業から開発に移るタイミングは、「作りたくなったとき」ではなく「手作業が特定の理由で回らなくなったとき」です。判断のために次を書き出してみてください。

• 今、手作業で何時間かかっているか
• そのうち、繰り返しで機械に置き換えられる部分はどこか
• 置き換えないまま件数が倍になったら何が起きるか

この三つに答えられれば、最初に作る範囲は自然に絞れます。逆に答えられないなら、まだ手作業の期間が足りていない可能性があります。

プレシードの検証設計や、手作業から開発へ移る範囲の相談は、市場リサーチやWebシステム開発とあわせてお問い合わせよりご相談ください。ご相談・お見積りは無料で、打ち合わせはオンラインで全国対応しています。

本記事は一般的な情報であり、個別の事案は専門家にご確認ください。