25分でアプリを作る。
この話をすると、時間管理や手順の話になりがちだが、実際に考え続けてわかったのは別の点だった。
一番大切なのは、最初の5分をどう回すかだ。

この5分が弱いと、その後の20分は必ず迷う。
逆に、この5分が強ければ、残りはほぼ自動で進む。

この5分は「考える時間」ではない

まず前提をはっきりさせておく。
この5分は、仕様を詰める時間でも、設計を考える時間でもない。

判断をせずに、言葉を外に出し切る時間だ。

雑でいい。
矛盾していていい。
哲学的でも感情的でもいい。

重要なのは、頭の中にある「作りたい」「面倒」「ここは捨てたい」という断片を、止めずに出し切ること。その量が、そのまま25分全体の安定性になる。

mdファイルは「考えるため」ではなく「流すため」にある

spec.md、agent.md、map.md、log.md を用意しているのは、
思考を整理するためではない。
必要があるまたは、もっとやりつづけるならtask.mdを置く。

出てきた言葉を、迷わず置くための器として用意している。

どの言葉をどの md に入れるかを、その場で考えない。
それは呪文として身体に覚えさせておけばいい。
5分のあいだにやるのは、分類ではなく出力だ。

まず出す。
あとで置く。
置き方は毎回同じ。

この順番を崩すと、5分はすぐに判断の時間に変わってしまう。

それでも「形」が必要だと感じた理由

態度や哲学を語るだけでは、最後に形に回収される保証がない。
だから不安が残る。

そこで一つだけ、出口の型を固定することにした。

5分で出した言葉は、最終的に必ずこの3つに落ちる。

• Input：何を受け取るか
• Transform：どう変えるか
• Output：どう返すか

この3点が揃えば、必ず index.html は書ける。
GitHub Pagesで公開できない形にはならない。

まずは何を入れてどう変換してどういうアウトプットになるかという一連の流れを頭の中に描いて言語化することが大切だ。

この5分で実際に作っているもの

この5分で作っているのは、アプリでも仕様書でもない。
25分を迷わず走り切れる最小構造だ。

やることはシンプルだ。

1. Input を一つに決める
2. Transform を明確にする。
3. Output を一つに固定する

正しさはいらない。
精度もいらない。
一つにしぼり何を出すかを明確にする。

5分の最後に、

「〇〇を入力すると、△△して、画面に表示する」

この一文が言えれば成功だ。

哲学を語ってもいい理由

この5分で「なぜやるのか」を語ってもいい。
むしろ語ったほうがいい。

人は納得していない制約を、無意識に破る。
だから哲学は、自己満足ではなく実用的な燃料になる。

ただし、哲学は設計図にしない。
Input / Transform / Output より上位に置かない。
役割は一つだけだ。

「今日はこれで行く」と、自分が腹をくくれる状態を作ること。

それができたら、哲学としては十分だ。

迷いを生む概念を先に潰しておく

この5分で特に危険なのは、次のような概念だ。

• ちゃんとしたものを作ろう
• あとで使えるかもしれない
• 最適なやり方があるはず
• 今は仮でいい
• mdの使い分けを考え始める

これらはすべて、評価・将来・最適・整理の匂いを持っている。
この匂いがした瞬間、5分は壊れる。

だから最初にこう宣言していい。

今回は評価しない。
今回は続けない。
今回は最適化しない。
今回は整理しない。

5分の正体

結局、この5分でやっているのは仕様決定ではない。
削減だ。

一つに減らす。
さらに一つに減らす。
最後に一つだけ残す。

判断ではなく、切り落とし。
選択ではなく、剪定。

だから「判断なし」で回せる。

25分開発の成否は、技術ではなく、この5分の使い方で決まる。
ここが固まれば、Codexもテンプレも、GitHub Pagesも、すべて自然に噛み合う。

この5分をどうやって確実に「判断なし」で回すか。
だがそれは、また一段先の話になる。