Blog

前回（#6）までで、ギアとコンテナの機能がそろいました。 ここからプランやチェックリストを作っていく前に、実際のデータを入れることにしました。 #1で書いたとおり、今の持ち物はNotionのデータベースで管理しています。これをハコヅミに取り …

前回（#5）のコンテナの機能を作っている途中で、E2Eテストが通ったり落ちたりするようになりました。 落ちるテストが実行のたびに変わる、いわゆる「不安定なテスト」です。 原因は1つではなく、4つありました。今回は、その見つけ方と直し方の記録 …

#1で書いたとおり、ハコヅミの一番の売りは「コンテナを積めば、中のギアもまとめてチェックされる」ことです。 その前提になる、コンテナの機能を作りました。 コンテナの登録・編集・削除 ギアがどのコンテナに入っているかの紐づけ Issueは2つ …

前回（#3）で、Issue → 実装 → PR → 受入 → 本番リリースを一周しました。 今回は、その手順を Claude Code のスキルにした話です。 開発プロセスの記事では、「Claude Codeへの具体的な指示の出し方やスキル …

前回（#2）で開発の土台がそろったので、いよいよ最初の機能を作りました。 ギアの一覧と登録です。 機能としては小さいのですが、決めた開発の流れを初めて最後まで通したことで、流れそのものにも直すところが見つかりました。今回はその記録です。

前回（#1）で紹介したキャンプ道具のチェックリストアプリ「ハコヅミ」の、開発の土台を作りました。 やったことは次のとおりです。 GitHubのリポジトリ作成と、Issueのテンプレート SvelteKitの雛形 PRごとの自動テスト（CI） …

前回の記事までで、「なぜ作るのか」「何を作るのか」「どう作るのか」がひと通りそろいました。 今回から、最初のサービスの開発記録「ハコヅミを作る」シリーズを始めます。 作るのは、キャンプ道具のチェックリストアプリです。名前は**ハコヅ …

前回の記事では、サービスを作るための技術スタックを決めました。 今回は、その道具を使ってどう開発を進めるかです。 個人開発で開発プロセスを決めるのは、やりすぎではないか。最初はそう思いました。 それでも、機能ごとにIssueを作り、受入条 …

前回の記事では、作るサービスを選ぶ6つの基準を決めました。 今回は、それらのサービスを何で作るかです。これから作るサービスすべてに共通する技術スタックを決めたので、その中身と選んだ理由をまとめます。 （2026年9月時点の方針です）

前回の記事では、定年後は案件を受けずに、自分のWebサービスを作っていくことにした経緯を書きました。 では、具体的にどんなサービスを作っていくのか。今回は、作るサービスを選ぶための基準を整理します。 （2026年9月時点の方針です）