ハコヅミを作る #41：ベータ版の前に、もう1つ機能を足すと決める（段階の組み替え）
前回（#40）までで、ベータ版の前の洗い出しも、ほぼ済みました。今回は、コードを書かない回です。
ベータ版を始める直前になって、気が変わりました。もう1つ、機能を足したい。
足したくなったのは、料理
キャンプで作る料理を、登録できるようにしたい、と思いました。
- 料理に、レシピを書ける
- 食材は、消耗品（#16）から選ぶ
- キャンプで作りたい料理を選ぶと、その食材が、持ち物チェックの項目になる
キャンプで作る料理は、数品です。「今回は、カレーとホットサンド」と選べば、要る食材が、忘れ物のチェックに入る。ハコヅミの「忘れ物をなくす」に、まっすぐつながります。
今の段階の分け方では、入れる場所がありません。そこで、こう組み替えることを考えました。
| 段階 | 今まで | 考えた案 |
|---|---|---|
| ステップ2 | 公開の準備（ベータ版まで） | マルチユーザー対応（今できているところで締める） |
| ステップ3 | 共有 | 料理 |
| ステップ4 | 機能の拡張 | ベータ版の公開 |
| ステップ5 | — | 共有 |
相談する
「どうだろう？」と、Claude Code に聞きました。
答えは、「その流れでよい。ただし、条件を2つ付けたい」でした。
賛成の理由
- 持ち物チェックの中身に関わる機能だから。料理を選ぶと持ち物が増える、というのは、ハコヅミの中心に足す話になる。テスタには、これが入った形で触ってもらうほうが、意見が的を射る
- 紹介の文と、上限の検討に響くから。先に入れておけば、二度決めずに済む
- 今の進み方なら、遅れは小さい
2つの条件
- 料理は、最小の形で入れる
- 料理のあとは、ベータ版まで、機能を足さない
2つ目は、耳の痛い話です。「もう1つだけ」をくり返すと、いつまでも、人に見せられません。まさに今、その「もう1つ」を言い出したところです。
気になる点も、挙がった
賛成のあとに、気になる点も、2つ挙げてくれました。
1つは、季節です。持ち物チェックは、実際にキャンプに行かないと、試せません。10〜11 月は、まだ行く人が多い時期です。ベータ版が冬にずれ込むと、春まで、本番の使われ方が見られません。「最小の形で」という条件の、いちばんの理由が、これでした。
もう1つは、正直な指摘でした。
技術的には、ベータ版のあとでも入れられる。料理は、今のテーブルを作り替えずに、足すだけで作れる見込み。つまり「先に入れないと、あとで困る」機能ではない。先に入れるのは、入れた形で見せたいから、という判断になる
先に入れる理由を、技術のせいにしない。「見せたいから入れる」のだ、と分かったうえで決めるのは、大事なことだと思いました。
最小の形を決める
「最小の形」とは、どこまでか。Claude Code は、決めることを表にしてくれました。その中から、いくつか。
食材の登録の手間
食材は、消耗品から選びます。そのままだと、肉や野菜を1つずつ消耗品に登録してからでないと、料理を作れません。
料理の画面に、「新しい食材」の欄を付けることにしました。1行に1つずつ、名前を書くだけです。保存のときに、消耗品として登録されて、その料理に付きます。
チェックの並べ方
最初のイメージは、「料理1品＝カテゴリの1つ」でした。持ち物チェックに、「カレー」という見出しがあって、その下に、じゃがいも・にんじん・ルーが並ぶ形です。
これは、やめました。今のチェックは、コンテナごとに並んでいます（#9）。車に積み込む動きに、合わせるためです。食材は、クーラーボックスに入れて積みます。料理ごとに並べると、この並びと、ぶつかります。それに、玉ねぎを、カレーとホットサンドの両方で使うとき、どちらに出すかが、決まりません。
チェックは、コンテナごとのまま。料理は、キャンプの画面に、別のまとまりとして出します。「カレー：食材 3 / 5」と、そろった数が分かり、押すとレシピが開きます。キャンプ場で、レシピを見ながら作れます。
あとに回すもの
- 数量の足し算（卵を、2つの料理で 2個ずつ使うとき）
- 買い物リスト
- 料理の画像
- 献立（何日目の朝・夜に、どれを作るか）
どれも、欲しくなりそうなものです。だからこそ、先に「入れない」と書いておきます。
組み替える
方針が決まったので、片付けました。
- 開発環境まで済んでいたもの（ログ、お知らせ、エラーの画面、小さな直し）を、本番に出す
- マイルストーン「ステップ2」を閉じる（Issue は 20 件）
- 料理を「ステップ3」、ベータ版を「ステップ4」、共有を「ステップ5」にする
- Notion の段階を直す
- 料理の Issue を、2つ作る（登録と、キャンプでの選択）
トップページのメニューは、5つから6つになります。絵のアイコンは、自分で用意しました。
メニューのアイコン。左から4つ目が、新しい「料理」
5つは、3列に並べると、1つ余っていました。6つなら、3列2段に、ちょうど収まります。
おまけ：Stripe の話
段階を考えているときに、ふと、気になりました。将来の有料プランは、月ごとに、自動で引き落とせるのでしょうか。
聞いてみると、できる、とのことでした。Stripe には、サブスクリプションの仕組みがあります。申し込みの画面も、解約やカードの変更の画面も、Stripe が用意してくれます。冬のあいだだけ休む「休止」（#27で考えたもの）も、支払いの一時停止で作れます。
手数料の数字も教えてくれましたが、「私の知識の時点のものなので、料金を決めるときに、確かめたい」と添えてありました。こういう一言があると、数字を、そのまま信じずに済みます。
おまけ：思い込みに、振り回される
最後に、困った話を1つ。
ハコヅミでは、手元の道具（wrangler）を、開発用のアカウントにだけ、ログインさせておく決まりです。本番を、手元から触らないためです。
このところ、Claude Code から、何度も言われました。
手元の wrangler が、本番用のアカウントにログインしたままのようだ。開発用に戻してほしい
戻しました。確かめました。開発用です。それでも、また言われます。
原因は、Claude Code の思い込みでした。ログインの表示に出るメールアドレスを見て、「これは本番用だ」と決めつけていたのです。アカウントの中にあるデータベースの ID を見比べたら、開発用で合っていました。Claude Code は、「私の言っていたことが、間違っていた」と訂正して、CLAUDE.md に書いた見分け方も、直すことになりました。
#37では、「人の言葉より、実際の状態を先に確かめる」と書きました。今回は、Claude Code が、状態を確かめたつもりで、見るところを間違えていたことになります。慎重な側に倒れた間違いなので、害はありませんでした。ただ、何度も確かめ直すのは、少し疲れます。
間違えたときに、理由を付けて訂正してくれること。これは、ありがたい点です。
おわりに
- 直前に機能を足したくなったら、理由を、技術のせいにしない。「見せたいから入れる」と分かったうえで、決める
- 足すなら、最小の形で。あとに回すものを、先に書いておく
- 「このあとは、もう足さない」を、先に約束する
- 季節のある道具は、季節を逃さない
- 最初のイメージ（料理ごとに並べる）が、今の形（コンテナごと）とぶつかったら、どちらが使う場面に合うかで決める
- 確かめるときは、何を見れば分かるのかを、先に確かめる
次回は、料理の登録です。