ハコヅミを作る #10：MVPができるまでの振り返り

2026年09月29日

前回（#9）のコンテナの一括チェックで、ハコヅミのMVPの機能がすべてそろい、本番にもリリースしました。今回は、ここまでを振り返ります。（2026年9月時点の内容です）

Notionで困っていた2つのことは、解決したか

#1で、Notionのキャンプ道具リストに不満が2つあると書きました。

チェックリストでは、ギアがコンテナごとにまとまって並び、コンテナのチェックボックスを押せば中のギアがまとめてチェックされます（#9）。戻し忘れが気になるときは、「中身をすべて見る」でコンテナの中身を確かめられます。

チェックの状態はギアではなく、キャンプ1回分のチェックリストに記録します（#8）。次のキャンプでは、プランを選んで新しいチェックリストを作るだけです。過去のチェックリストも残るので、あとから「あのときは何を持っていったか」を見返せます。

GitHubのマイルストーン「MVP」には、Issueが12件入りました。土台づくり（雛形、CI、自動デプロイ）とスキルづくりも含めた数です。すべて閉じたので、マイルストーンも閉じました。

開発プロセスの記事で決めた流れは、そのまま最後まで使えました。ただ、使いながら直したところがいくつもあります。

直したこと	きっかけ
PRには `Closes` ではなく `Refs` を書く。ACのチェックは受入判断の印	マージの時点で、受入の前にIssueが閉じてしまった（#3）
画面から確かめられないACに「（自動テストで確認）」と書く	「他人のデータを操作できない」は、画面を触っても確かめられなかった（#4）
Markdownやスキルだけの変更では、CIもデプロイも動かさない	毎回テストが全部流れて無駄だった（#6）
本番へのリリースは、機能がたまってからまとめて出す	本番を使っているのが自分だけなので、機能ごとのリリースは手間だった（#5）
開発用のD1への読み取りだけの `SELECT` は許可する	マイグレーションが適用されたかを確かめるのに必要だった（#3）

どれも、最初から決めておくのは難しかったと思います。一度流れを通してみて、困ったところを直す。個人開発でも、この順番が合っていました。

直したことは、そのたびにリポジトリの CLAUDE.md と、Claude Codeのスキル（/issue、/implement）に書き足しています。

MVPの間に、D1のマイグレーションを5つ適用しました。

どれも、develop にマージしたら開発用のD1、main にマージしたら本番用のD1に、CIが適用します。 IssueのACにも「開発のD1にできる」「本番のD1にできる」を別々に書き、それぞれのタイミングで確かめてから閉じました。

中でも、テーブルを作り直す 0002 は、前後でギアの件数を比べてデータが消えていないことを、ローカル → 開発 → 本番の3か所で確かめています（#5）。

MVP全体を通しての分担は、次のとおりでした。

作業	自分	Claude Code
何を作るか	一言のメモで伝える	Issueの下書きにして、決めてほしい点を挙げる
AC・仕様の判断	決める	候補を出す。抜けや、見落としやすい点を指摘する
実装・テスト・PR	レビューして、理解してからマージする	書く。セルフレビューする
受入判断	開発環境で触って決める	結果を受けて、IssueのACにチェックを付けて閉じる
Cloudflareのダッシュボード操作	自分でやる（APIトークン、Access、本番のD1など）	手順を案内する。結果を読み取って確かめる
本番のデータを触る	自分でやる（コンソールでSQLを実行）	SQLを用意する

振り返ると、自分が判断したことは思っていたより多くありました。

一方で、D1の値の上限、ハイドレーションの問題、SQLITE_BUSY のような技術的な落とし穴は、Claude Codeが見つけて、原因を調べて直してくれました。

何を作るか・どこで折り合うかは自分、どう作るかはClaude Code。開発プロセスの記事で考えていた分担が、MVPを通して実際に回ることを確かめられました。

MVPはできましたが、決めた方針でいう「使ってくれる人がいて、喜んでもらえている」には、まだ遠い段階です。次は、次のことを考えています。

実際のキャンプで使ってみる：積み込みの現場で使うと、スマホでの使いやすさや、電波がないときの動きなど、次に直すことが見えてくるはずです
UIの見直し：今の画面は、機能を確かめるための最低限の見た目です。技術スタックの方針で決めた「色・フォント・角丸などをサービスごとに定義して、業務システムっぽくない見た目にする」は、まだ手を付けていません。ハコヅミらしい見た目と、積み込み中でも使いやすい画面にしていきます
公開の準備：ベータ版として公開するための、ログインの仕組み、利用規約、サービス終了の方針など
公開日を決めて宣言する：締め切りのない個人開発で、作り込みすぎないために

次回からは、こうした次の段階の記録になります。