ハコヅミを作る #60：料理にカテゴリとおすすめ度を付ける（2つの Issue を1つの PR に、人のレシピをコピーしてよいか）
前回（#59）と同じ日の、続きです。キャンプの前に料理を登録していて、気になったところを直しました。
- 料理にカテゴリを付ける
- おすすめ度の★を付ける
- 2つの Issue を、1つの PR にまとめる
- 人のレシピを、コピーしてよいか
- 書く欄があっても、また書き忘れる
料理にカテゴリを付ける
料理の一覧は、名前順の1列でした。数が少ないうちはよいのですが、朝ごはんも、おつまみも、同じ列にまざります。
ギアと消耗品の一覧は、カテゴリごとに、緑の仕切りで分かれています。料理も、同じ形にします。
名前の下に、カテゴリの欄（架空のデータ）
カテゴリは、決まった選択肢から選ぶのではなく、自由に書きます。前に使ったカテゴリは、候補に出ます。ギア・消耗品と同じ作りです。
リスト表示にも、仕切りを入れるか
カード表示は、ギアと同じように仕切ればよい、とすぐ決まりました。迷ったのは、リスト表示です。1件が1行の一覧に、仕切りを入れると、うるさくならないか。
頭の中で考えても分からないので、Claude Code に画面イメージを出してもらいました。出てきたのは、絵ではなく、実際の画面です。一覧のページを一時的に書き換えて、架空の料理を入れて撮り、撮ったあとでコードを元に戻しています。
リスト表示。カテゴリごとに仕切る
見てみると、うるさくはありませんでした。フリーの料理は 20 件までなので、仕切りで縦に伸びる分も、気になりません。リスト表示にも、仕切りを入れることにしました。
「入れたらどう見えるか」で迷ったときは、言葉で話し合うより、実際の画面を見るほうが早く決まります。
分けないと決めたところ
キャンプの登録の画面には、「作る料理」を選ぶ欄があります。ここも、カテゴリで分けるか。Claude Code の案は「分ける」でした。
わたしは、分けないことにしました。1回のキャンプで作る料理は、せいぜい数品です。選ぶ側の一覧（最大 20 件）が、仕切りで長くなるほうが、使いにくいと考えました。
同じデータでも、画面ごとに、要るかどうかは違います。「一覧で分けたから、ここも」と、そろえることを目的にしないようにします。
おすすめ度の★を付ける
ギアには、おすすめ度（★5つ）と、おすすめ理由の欄があります。料理にも、同じものを付けました。
ギアと同じ、おすすめ度の欄
今は、自分の覚え書きです。「これは、またやりたい」「これは、手間のわりに」を残しておけます。
本当のねらいは、もう少し先にあります。ハコヅミには、ほかの人のギアやキャンプを見られる「共有」の機能を、いずれ作る予定です。そのときに、ほかの人の「おすすめの料理」を参考にしたい。そのための項目を、先に用意しておきます。
欄そのものは、ギアの部品をそのまま使いました。「1〜5 の数であること」「おすすめ理由は 1000 文字まで」という決まりも、ギアのものを使い回しています。新しく作ったのは、一覧に★を出すところだけです。
カード表示。食材の数の右に★
★を付けていない料理（焼き枝豆）には、何も出しません。「☆☆☆☆☆」と出すと、「評価が低い」ように見えるからです。
2つの Issue を、1つの PR にまとめる
カテゴリと、おすすめ度。やりたいことは別々なので、Issue は2つに分けました。
ただ、作るところは、ほとんど重なります。
- どちらも、料理のテーブルに列を足す
- どちらも、登録・編集の画面に欄を足す
- どちらも、一覧の見た目を変える
- どちらも、データの書き出しに項目を足す
別々に作ると、データベースの変更（マイグレーション）が2つ、PR が2つ、リリースが2回になります。同じファイルを続けて触るので、2つ目の PR は、1つ目がマージされるのを待つことになります。
そこで、Issue は2つのまま、実装は1つのブランチ・1つの PR・1つのマイグレーションにまとめました。
| 別々に作る | まとめて作る | |
|---|---|---|
| Issue | 2 | 2 |
| マイグレーション | 2 | 1 |
| PR と CI | 2 回 | 1 回 |
| リリース | 2 回（か、待って1回） | 1 回 |
Issue を分けておくのは、「何を確かめたら終わりか」（受入条件）を、機能ごとに持つためです。PR の本文には、2つの Issue の受入条件を、それぞれ表にして載せました。
「1つの Issue に、1つの PR」は、分かりやすい決まりです。でも、目的は、あとから追えることと、確かめやすいことです。同じ場所を触る小さな機能は、まとめたほうが、どちらも良くなります。
人のレシピを、コピーしてよいか
おすすめ度の Issue を書きながら、もう1つ、先の話を Claude Code に聞きました。
共有された他の人の料理を自分の方にコピーする機能はどうだろうか？ 利用規約などで明記する必要があると思うが、他の人の料理を取り込むことは問題となるか？
返ってきた整理は、こうでした（Claude Code は法律の専門家ではないので、作る前に確かめる前提です）。
問題になりにくいところ
- 材料の一覧と、「切る」「10 分煮る」のようなふつうの手順は、アイデアや事実に近く、一般に、著作権では守られにくい
- 自分のために写して使うだけなら、手で書き写すのを、楽にしているだけ
問題になりうるところ
- 写真。はっきり著作物で、人が写っていることもある。コピーでは、写真を持っていかないのが安全
- 工夫のある文章。もとの人が、本やサイトから写していた場合、コピーで広がってしまう
- 「退会するとすぐ消える」という約束。もとの人が退会しても、コピーは、相手の手元に残る
3つ目は、言われるまで気づきませんでした。ハコヅミのプライバシーポリシーには、退会すると、登録内容や画像はすぐに消える、と書いてあります。コピーの機能を作ると、この文が、そのままでは正しくなくなります。
機能を1つ足すと、すでに書いてある約束が、ずれることがあります。「この機能を入れたら、規約のどの文が変わるか」を、作る前に見ます。
コピーした料理は、共有できないようにする
わたしからは、こう足しました。
ただ、他の人からコピーした料理は共有不可とする必要はありそう（真似しながら新規に作れば回避できてしまうが）
人のレシピを、ボタン1つでコピーして、そのまま自分の名前で共有できてしまうのは、よくありません。料理に「コピーしたもの」の印を持たせて、共有の切り替えを出さないことにします。
手で打ち直せば、すり抜けられます。それは、分かったうえで、よしとしました。止めたいのは、「ボタン1つで、人のレシピが、自分の名前で出回る」ことです。手で打ち直す人まで、仕組みで止める必要はありません（そこは、通報で扱います）。
守りを考えるときは、「完全に防げるか」ではなく、「何を、どのくらい面倒にするか」で考えます。
この機能は、共有そのものがまだないので、今は作りません。Issue にもせず、Notion の「共有」の段階に、案として書いておきました。
書く欄があっても、また書き忘れる
今回のリリースには、データベースの変更が入っています。ハコヅミでは、そういうリリースの PR に、「マージの直前の時刻」を書く欄を用意しています。データが壊れたときに、その時刻の状態へ戻すためです。
#57で、この欄を書き忘れた話を書きました。そして今回、また書き忘れました。
マージのあとで、Claude Code が、空のままの欄に気づきました。前回と同じく、GitHub に残っているマージの時刻を、「あとから書き足した」と分かる形で入れてあります（マイグレーションが当たるのは、マージのあとなので、戻す時刻として使えます）。
2回続いたので、わたしの注意力のせいにするのは、やめます。Claude Code の言葉です。
2回続いたので、欄を書いてもらう形そのものが合っていないと思う。
そのとおりです。PR の本文に欄があっても、マージのボタンを押すときには、本文を読み返していません。次からは、リリースの PR を作るときに、Claude Code のほうから「マージする前に、時刻を書いたか」を一言たしかめてもらいます。
同じ失敗を2回したら、「次は気をつける」では直りません。忘れても困らない形に、手順のほうを変えます。
おわりに
- 「入れたらどう見えるか」で迷ったら、実際の画面を見て決める
- 一覧で分けたからといって、選ぶ欄まで分けるとは限らない。画面ごとに、要るかを考える
- 評価を付けていないものには、何も出さない（空の★は、低い評価に見える）
- Issue は機能ごとに分けて、同じ場所を触るものは、1つの PR にまとめる
- 機能を足す前に、すでに書いてある約束（規約・ポリシー）のどの文が変わるかを見る
- 守りは、「完全に防げるか」ではなく、「何を、どのくらい面倒にするか」で考える
- 同じ失敗を2回したら、気をつけるのではなく、手順を変える
次回は、キャンプで実際に使ってみた話を書く予定です。