転職用のポートフォリオとして、個人でWebアプリ「Hubpin」を作っています。
制作の経緯は「Hubpin 開発記録」に時系列でまとめています。
設計と判断は自分で行い、実装も原則自分で書いています。AIには手順書・レビュー・調査を任せています。
制作中の自作アプリの開発記録から。
転職用のポートフォリオとして作っているので、面接で説明できるかが判断軸になっています。
目安1.0時間の作業に、4.8時間かかった
ログイン画面を1つ作る工程です。手順書には 1.0h と書いてありました。実績は 4.8h。
コードを書いていた時間ではありません。**分からないところで止まって、質問して、
納得してから進んでいた時間**です。丸写しなら1時間で終わっていました。
代わりに増えたもの
同じ工程で、説明できる概念が11個増えました。
'use server'は公開範囲の宣言だった（実行場所の指定だと思っていた）- 型エラーが指していたのは「今のバグ」より「将来のバグ」だった
matcherが決めているのは実行の範囲で、保護の範囲ではなかった
どれも詰まったから分かったことです。通過していたら存在しなかった。
裏づけがある
前の工程で、RLS のポリシーを7本書いても1行も読めない、という状態に4時間詰まりました。
原因は GRANT（テーブルに触れる権限）と RLS（どの行を見せるか）が二段構えだったこと。
この4時間があるから、面接で「RLS だけでは読めません」と話せます。
詰まらずに通過していたら、そのネタは存在しませんでした。
判断の言葉
当時のメモにこう書いていました。
分かったふりして飛ばしたら、理解しないまま完成しそうで、それだと面接でも説明できない。
速さを取るか、説明できることを取るか。ポートフォリオでは後者しか意味がないと思っています。
完成したアプリを見せる場ではなく、作った人の判断を見せる場なので。
ただし、これはコストでもある
工程1〜4（準備・設計）は見積25hに対して実績12.1h。48%で終わっていました。
初の実装工程である工程5は、見積6hに対して最終的に 10.8h。180%に逆転しています。
倍率は下がっている
同じ工程の中で、手順ごとの倍率を並べるとこうなりました。
| 手順 | 新しく踏むもの | 倍率 |
|---|---|---|
| 3 | Server Action・'use server'・useActionState |
4.8倍 |
| 4 | proxy・matcher | 2.2倍 |
| 5 | なし（3と4の組み合わせ） | 1.5倍 |
| 6・7 | なし | 0.3倍前後 |
手順4で新しく踏んだのは proxy と matcher だけで、'use server' や <form action> は手順3で覚えたものを使い回せました。
回収の証拠もあります。ログアウトの実装で
「useActionState は要らない（戻り値を画面に出さないから）」を自分で判断できました。
手順3の 4.8h が効いています。
落としどころ
AI に書かせれば速い、は本当。ただし残るのは動くコードだけ。
自分が売りたいのは動くコードではなく、判断の理由なので、遅いほうを選んでいます。
「AI を使うな」という話ではありません。使いながら、どこで止まるかを選んでいるという話です。
そして止まった時間は、倍率が下がる形で戻ってきています。
