最初に決めるのは機能一覧ではありません
依頼前に決めたいのは、実装したい機能の数ではなく、今回の検証で何を判断するかです。操作感、テンポ、画面遷移、調整幅など、答えたい問いを絞るほど小さく作れます。
- 何を判断できれば次へ進めるか
- 仮素材でよい範囲
- 今回は作らない範囲
確認ビルドの使い方を先に決めます
プロトタイプはレビュー方法まで決めておくと効果が出ます。誰が触るのか、どの端末で見るのか、調整値をどこまで変えるのかを先に共有します。
- 確認する人
- 対象端末や入力方式
- 調整したいパラメータ
捨てる判断を前提にします
プロトタイプで作ったものをそのまま本開発に流用できるとは限りません。残すもの、作り直すもの、捨てるものを分ける前提で依頼すると、後の開発判断が軽くなります。
実務例：検証範囲の切り分け
相談前にここまで分けておくと、プロトタイプの見積範囲と確認方法をそろえやすくなります。
| 検証したい問い | 作る範囲 | 作らない範囲 | 成果物 |
|---|---|---|---|
| 移動とカメラの手触りは楽しいか | 移動、カメラ、仮UI、調整値 | 本番アート、全ステージ、セーブ | 確認ビルド、調整メモ |
| 仮UIで操作フローが伝わるか | 主要画面の仮導線、入力確認 | 最終デザイン、演出作り込み | 画面フロー、残課題リスト |
| 本開発に残す仕様を決められるか | 比較できる2案、確認手順 | 全機能実装、長期バランス調整 | 残す / 捨てる / 再検証リスト |
よくある相談例
Unityプロトタイプの相談では、完成版の開発よりも先に、判断材料を作りたいというケースが多くあります。
- 新しい操作感だけ先に試したい
- 企画書だけでは面白さを判断できない
- 本開発前に削る機能を見極めたい
依頼前に決めること
依頼内容を広げる前に、今回の確認で答えたい問いと、仮でよい範囲を決めます。
- 検証する操作やテンポ
- 仮素材でよい画面・演出
- 確認ビルドを見る人と頻度
失敗しやすいパターン
プロトタイプを完成版に近づけすぎると、判断より作り込みが重くなります。
- 最初から製品品質を目指す
- 仮素材でよい範囲を決めていない
- 誰が確認するか決まっていない
Nobilwingで支援できる範囲
小さく動くものを作り、確認結果を次の開発判断につなげる支援ができます。
- Unityでの確認用ビルド作成
- 調整パラメータや検証項目の整理
- 実装メモと次フェーズ候補の共有
相談前チェック
- 検証したい問いを1〜3個に絞る
- 仮素材でよい範囲を決める
- 対象端末と入力方式を決める
- 確認ビルドの頻度を決める
- 本開発へ残す条件を決める