個人開発では、すべての機能を完成させてから公開しようとしがちです。しかし、長く作り込むほど「本当に必要だったか」を確認する時期が遅れます。
小さな変更を、確認できる形で出すことも開発の一部です。
小さく出す目的
早く見せる目的は、作業速度を自慢することではありません。
- 想定した操作が伝わるか確認する
- 本番に近い環境で動作を見る
- 間違った方向への作り込みを減らす
- 問題が起きた時の影響範囲を狭くする
- 次に作るものを事実から決める
公開後に得る情報が、次の設計材料になります。
機能を縦に薄く切る
Todoアプリなら、画面だけを全部作ってからAPIへ進む方法もあります。しかし、最初に一件だけ追加できる流れを通すと、早い段階で全体の接続を確認できます。
| 段階 | 公開する範囲 |
|---|---|
| 1 | 一件追加して画面に表示する |
| 2 | 再読み込み後も残るようにする |
| 3 | 完了状態を変更できるようにする |
| 4 | 削除と確認表示を加える |
各段階が利用者から見て意味のある小さな完成になります。
戻せる範囲で試す
小さなリリースには「戻せること」が必要です。
- 変更前のコミットを残す
- DBの破壊的変更を避ける
- 新旧どちらでも動く期間を作る
- 設定で機能を止められるようにする
- 公開後に見るログや指標を決める
結果がすぐ分かり、簡単に戻せる変更は試しやすくなります。戻せない変更や影響の大きい変更は、事前確認を厚くします。
「出した」で終わらせない
公開前に、何を確認するか決めます。
仮説: 入力欄の近くに例を置くと送信エラーが減る
確認: バリデーションエラーの発生回数
期間: 1週間
判断: 減らなければ文言か入力条件を見直す
観測方法がなければ、公開しても学びに変わりません。
参考リソース
次に読む記事
← 一覧に戻るPR
PR
