「何から書けばいいか分からない」の正体は、完成形を一気に書こうとしていたこと

転職用のポートフォリオとして、個人でWebアプリ「Hubpin」を作っています。
制作の経緯は「Hubpin 開発記録」に時系列でまとめています。
設計と判断は自分で行い、実装も原則自分で書いています。AIには手順書・レビュー・調査を任せています。

制作中の自作アプリの開発中、空ファイルの前で止まった話です。

空の page.tsx の前で止まった

ログイン画面を作る番でした。手順書も読んである。やることは分かっている。
なのに1文字も書けませんでした。

頭にあったのは完成形です。'use client' が要るのか、useActionState はどう使うのか、
Supabase のクライアントはどれを呼ぶのか、Server Action は別ファイルにするのか。
全部を同時に決めようとして、どれも決まらない。

4段階に割ったら動き出した

段階1は数行のフォームで終わりました。

止めていたのは「正しい助言」だった

作業前に「先にファイルを分けるか決めよう」という助言を受けていました。
正しい助言です。 でも必要になるのは段階3から。着手の時点では決めなくてよかった。

正しいが、早すぎる。 これが一番止める力が強いと思いました。
間違った助言なら無視できるけれど、正しい助言は無視できないので、そこで考え込んでしまう。

副産物: 詰まったとき原因が1つに絞れる

段階ごとに「完成の合図」を先に決めておくと、動かないときに直前の段階だけ疑えばいい。
実際、段階1で action="{login}" と引用符を付けてしまうミスを踏みましたが、
段階1の範囲しか触っていないので、すぐ見つかりました。

1ヶ月前にも同じことをしていた

教材が15章あると聞いて手が止まり、2章に縮小した瞬間に集中できたことがあります。
「ここまでって考えると集中できた」「15章あると嫌になる」と当時のメモにあります。

変えたのは教材でも時間でもなく、ゴールの置き方だけでした。今回もそうです。

落としどころ

「何から書けばいいか分からない」は、知識が足りないサインだと思っていました。
実際はゴールが遠すぎるサインでした。手前に1つ置くだけで動き出す。

そして自分の場合、それを止めていたのが正しい助言だったのが面白いところです。
助言する側に回るときは、「正しいか」だけでなく「今か」を見ようと思いました。