相談前の整理が不足していると、見積、検証、実装、引き継ぎのどこかで手戻りが起こりやすくなります。よくあるつまずき方と、避けるための準備をまとめました。
Failure Patterns
すべてを完璧に決める必要はありません。まず、判断したいこと、作る範囲、後回しにする範囲を分けるだけでも相談は進めやすくなります。
01
原型検証では、完成度よりも何を判断するかが重要です。最初から演出や細部まで含めると、検証したい問いが見えにくくなります。
Unityプロトタイプを依頼する前に、完成品ではなく何を判断したいのか、操作感、素材、確認ビルド、捨てる範囲を整理します。
02
実績、ランキング、ストア文言、テスト権限は後からでも追加できますが、公開直前にまとめると確認時間が不足しやすくなります。
Steamworks連携は公開直前だけでなく、実績、ランキング、ローカライズ、ビルド、権限、テスト手順を早めに整理します。
03
通常データだけで作り始めると、運用開始後に列名変更、空欄、表記ゆれ、手修正データで止まりやすくなります。
ExcelやCSV業務を自動化する前に、作業頻度、例外、確認条件、出力形式、人が残す判断を整理します。
04
画面ができてから権限を考えると、表示範囲、更新範囲、履歴、CSV出力の扱いを作り直すことになりがちです。
管理画面開発では画面デザインより先に、権限、操作履歴、CSV入出力、検索条件、例外対応を決めると運用しやすくなります。
05
既存コードの一部だけを依頼する場合、担当範囲、レビュー方法、テスト、引き継ぎ条件が曖昧だと境界で止まりやすくなります。
既存プロジェクトの一部だけ外部に依頼する場合、境界、レビュー方法、ブランチ、テスト、引き継ぎ条件を先に決めます。
06
大量の資料やログを送っても、何を判断したいかが曖昧だと調査結果を実装判断に使いにくくなります。
技術調査を依頼する前に、判断したいこと、既存環境、再現手順、ログ、コード範囲、NDAと権限を整理します。
まだ資料がそろっていない段階でも、近いパターンを選ぶと初回メールに必要な前提を確認しやすくなります。
