25分で終わらせるための「開発の儀式」を設計する

儀式をはじめる。そのための準備を行う。

アプリを量産したい、という話ではない。
自分にとって大事なのは「作り続けられる状態」をどう作るかで、そのために開発を儀式化する必要があると考えた。気分や調子に左右されないためには、やることよりも「やらないこと」を先に決めるほうが効く。

40分以上かかったら失敗。例外はない。むしろ完成していなくても、時間を超えた時点で切る。ログは残すが、1週間は触らない。下手をすれば一生触らない。その前提に立つことで、「あとで直せばいい」という逃げ道を最初から消す。

30分は長い。余白があると人は整え始める。25分は、考えるより先に手を動かさないと終わらない長さで、未練が生まれる前に終わる。これは集中のためではなく、判断を減らすための制限だ。

この25分を、さらに5分単位に分解する。
最初にやるのは、毎回「5分ごとのスケジュール」を決めることだ。何分で何をやるかを先に固定し、その時間が来たら内容に関係なく次へ進む。うまくいったかどうかは見ない。時間を守れたかだけを見る。

同時に、「何をするか」も時間ごとに決め切る。
仕様を考える時間、Codexに投げる時間、ローカルで動かす時間、GitHub Pagesまで持っていく時間。それぞれの役割を混ぜない。考えながら作らない。作りながら整えない。すべてを短距離走に分解する。

GitHub Pages公開までを最短にするための型も固定する。
Codexで作る際の仕様書の書き方、map.md・log.md・agent.mdなどの最低限のドキュメント構成は毎回同じにする。考えなくて済む部分はすべて自動化する。これは品質のためではなく、思考を減らすためだ。

同時に、GitHub Pagesで「できること」と「できないこと」を明確にする必要がある。
動的処理、保存、外部依存。そういったことを最初から期待しない。Pagesで動く1ファイルのHTMLを置く。それ以上を求めた瞬間に、この儀式から外れる。

さらに、フォルダを作るところから儀式に含める。
新しいディレクトリを作り、そこに最低限のファイルを置く。この「始まりの動作」も毎回同じにする。開始の手触りを揃えることで、迷いを減らす。

これは開発効率の話ではない。
25分で終わらせるために、思考・判断・期待をすべて削ぎ落とした結果として残った形だ。
この儀式が回り始めれば、出来の良し悪しとは関係なく、作ったという事実だけが積み上がっていく。

次は、この儀式を完全に固定した手順書として落とすか、あるいはCodex用の定型プロンプトに変換する段階になる。
ただし、それはまた別の話。