ハコヅミを作る #54：テスタを待つあいだの、最初の直し（消耗品のまとまり、表示を覚える、レシピの並べ替え）
前回（#53）で、GitHub Actions の使う分を減らしました。今回は、テスタを待つあいだに入れた、最初の直しです。
- 段階を組み替える
- 持ち物チェックに「消耗品」のまとまりを足す
- 一覧の表示を、覚えておく
- レシピの手順を、つまんで並べ替える
- 手元で通って、CI で落ちる
- リリースの順番を、間違える
段階を組み替える
これまでの予定では、ベータ版の次は「共有」でした。ほかの人のギアやキャンプを見られるようにする、大きな機能です。
ベータ版を始めてみて、順番を変えることにしました。新しい大きな機能に進む前に、テスタに使ってもらって分かったことを直す段階を、1つ挟みます。
| 段階 | 中身 |
|---|---|
| ステップ4 | ベータ版を始めるまで |
| ステップ5 | テスタの意見を直して、一般に公開するまで（新しく挟んだ） |
| ステップ6 | 共有（見るだけ） |
| ステップ7 | 課金 |
一般に公開する前に済ませるもの（依存パッケージの版上げ、料理の画像など）も、ステップ5 に移しました。テスタの意見は、まだ届いていません。そのあいだに、自分で使って気になったところを直します。
持ち物チェックに「消耗品」のまとまりを足す
持ち物チェックは、コンテナごとにまとめて並べ、最後に「コンテナなし」をまとめて出しています。この「コンテナなし」に、ギアと消耗品（薪、氷、料理の食材など）が混ざっていました。
最初に頼んだのは、「コンテナなしと食材は、別のタブで分けて出す」でした。Claude Code は、タブを3つ（コンテナ／コンテナなし／食材）にする案を書いてきました。「食材」に何を入れるか、コンテナに入っている食材はどちらに出すか、など、決めることが7つありました。
読んでいて、思っていたものと違うことに気づきました。タブにしたかったわけではありません。今の並びの最後に、まとまりを1つ足したかっただけです。
そう伝えると、決めることは2つに減りました。
- コンテナに入っていない消耗品だけを、「コンテナなし」の下の「消耗品」にまとめる
- コンテナに入っている消耗品は、今までどおり、そのコンテナの中に出す（コンテナをまとめてチェックしたときに、一緒にチェックされるように）
「コンテナなし」の下に「消耗品」
言葉が短いと、AI は、ありそうな形を広く拾います。こちらの頭の中にある絵を、先に言葉にしたほうが早いことがあります。
一覧の表示を、覚えておく
ギアとキャンプの一覧は、リスト表示とカード表示を切り替えられます。ところが、ほかの画面に移ってからメニューで戻ると、リスト表示に戻ってしまいます。表示を、URL だけで持っていたためです。
覚えておく場所は、3つの案がありました。
| 案 | 弱いところ |
|---|---|
| ブラウザの保存領域 | サーバーから読めないので、いったんリストで出てから、カードに切り替わる |
| データベース | テーブル、書き出し、規約の直しまで要る。表示の好みにしては大げさ |
| クッキー | 端末ごとに覚える（スマホと PC で別） |
クッキーにしました。端末ごとに覚えるのは、むしろ合っています。スマホではカード、PC ではリスト、と使い分けたい場面があるからです。
ただ、プライバシーポリシーには「クッキーは、ログインのためだけに使います」と書いてあります。使いみちが1つ増えるので、ポリシーを直しました。制定（ベータ版を始めた日）の翌日の、初めての改定です。
小さな使い勝手の直しでも、利用者との約束に触れることがあります。
レシピの手順を、つまんで並べ替える
料理のレシピは、手順を1つずつの欄に書き、欄の下の「↑」「↓」で入れ替える作りでした（#46）。
使っていて、Google マップの経路の欄のように、つまんで動かして並べ替えたくなりました。ここは、画面のイメージを先に作ってもらいました。
欄が狭くなる
最初の案は、Google マップと同じく、左につまみ、番号、欄、右に消すボタンを1行に並べる形です。
最初の案
並べてみると、欄が狭くなります。「↑」「↓」を欄の下に置いていたのは、もともとこれが理由でした（#46）。Google マップは中身が短い地名なので気になりませんが、レシピは文です。
そこで、つまみと番号を、1つの札にまとめてもらいました。欄が 20px ほど広がり、例の手順は、4行が3行に収まりました。
選んだ案（つまみと番号を1つの札に）
できあがり
できあがり
つまんで動かしている途中
並べ替えのための部品は、たくさんあります。ただ、ハコヅミは「依存パッケージは増やさない」方針です。ブラウザに標準で付いているドラッグの仕組みは、スマホの指の操作では動きません。指やマウスの動きを自分で追う形で、作ってもらいました。キーボードでは、札にフォーカスを当てて、上下の矢印キーで動かします。
つかんだはずの指が、外れる
作っている途中で、1つつまずきました。
画面の端まで動かすと、自動でスクロールする、という動きを、E2E テストで確かめていたときです。途中で、スクロールが止まりました。
調べると、つまんでいる札が、ポインター（指やマウス）を「つかんで」いました。つかんでおくと、指が札の外へ出ても、動きが札に届きます。ドラッグを作るときの、よくある書き方です。
ところが、並び替えが起きると、札そのものが画面の中で別の場所へ移ります。移った瞬間に、つかみが外れていました。その後の動きは、どこにも届きません。
ポインターの動きを、札ではなく画面全体で受ける形に直しました。並びが変わっても、画面全体は動かないので、外れません。
テストで、自動スクロールまで確かめていたから、気づけました。指で少し動かすだけなら、外れる前に放してしまうので、見えなかったはずです。
手元で通って、CI で落ちる
3つの直しのうち、表示を覚える E2E が、CI で落ちました。手元では通っていたものです。
原因は、テストが自分でデータを用意していなかったことでした。リストとカードの切り替えは、一覧に1件以上あるときだけ出ます。手元のデータベースには、ほかのテストが作ったギアやキャンプが残っていたので、切り替えが出ていました。CI では、E2E を3つに分けて流すので、このテストが走った時点で、キャンプが1件もありませんでした。
テストの最初に、ギアとキャンプを1件ずつ入れるように直しました。そして、手元のデータベースを消して、CI と同じ「空」の状態でも流しました。
次からは、新しく書いた E2E は、データを消した状態でも流してから出します。
リリースの順番を、間違える
使う人に見える変更を本番に出すときは、アプリの中の「お知らせ」にも1件足す決まりです。今回は、お知らせを足す PR と、本番リリースの PR を、同時に並べました。
本番リリースのほうを、先にマージしてしまいました。
壊れたものは、ありません。お知らせは、アプリの動きとは切り離されたファイルです。機能が先に出て、お知らせがあとから、別の小さなリリースで出ただけでした。
ただ、同時に2つ並べたのは、こちらの段取りの失敗です。次からは、お知らせの PR がマージされてから、リリースの PR を作ります。間違えられる形にしておくと、いつか間違えます。
おわりに
- 言葉が短いと、AI は広く拾う。頭の中の絵を、先に言葉にする
- 小さな使い勝手の直しでも、利用者との約束（ポリシー）に触れることがある
- 画面のイメージを先に作ると、作ってから気づく問題（欄が狭い）に、作る前に気づける
- つかんだ要素が DOM の中で動くと、つかみが外れる
- 手元で通っても、ほかのテストのデータに頼っていることがある。データを消して流す
- 順番を間違えられる形にしておくと、いつか間違える。間違えられない順番で、並べる
次回は、テスタからの最初の声を聞く予定です。