プロトタイプを短い周期で公開する理由

完成度を上げる前に、実際に操作できる状態を作ってレビューする開発サイクルについて。

仕様書で正しくても、触ると成立しないことがある

ゲームやインタラクティブなUIでは、レイアウト図だけを見ると問題がないのに、実際に触るとボタンが遠い、アニメーションが長い、対象が見えない、といった問題が起きます。これらは実装ミスとは限らず、仕様そのものの問題です。

そのため、細部を作り込む前に最低限操作できる状態を作ります。完成品の縮小版を目指すのではなく、次の判断に必要な部分だけを実装した検証物として扱います。

一回の公開で、UI、ゲームバランス、演出、性能をすべて評価しようとすると、何を直すべきか曖昧になります。今回はカメラ、次は入力、というように、公開ビルドごとに主な確認事項を決めます。

ただし、対象外の問題を無視するわけではありません。操作不能や画面崩れのように検証を妨げる問題は先に直し、主目的を評価できる状態を保ちます。

ローカル環境は開発者ごとに条件が違います。公開URLを共通の観測点にすると、『いま何が動いているか』を同じ対象で確認できます。スマートフォンや別ブラウザから試すことも簡単です。

短い周期で出すためには、デプロイ手順も短くなければなりません。ビルド成果物を機械的に公開できる構成にしておくことで、公開そのものを特別なイベントにせず、日常のレビュー工程へ組み込めます。