ハコヅミを作る #65：プロフィールにアイコンを付ける（絵で選んだ大きさは、実物で見ると小さかった）
#62・#63で、ギア・キャンプ・料理を共有できるようにしました。共有のページには、表示名が出ます。でも、名前だけが並んでいると、だれがだれなのか、ぱっと見分けがつきません。
そこで、アイコンを登録できるようにしました。
- 共有を作る前に書いた Issue を、読み直す
- Google の画像は、使わない
- 画面イメージの案から、選ぶ
- 実物を見たら、小さかった
- 透けた画像で、線が見えた
- 「今は見えません」を、その日のうちに書き換える
- 直しを小分けにして、Actions の予算が減った
- 確かめたあとに、直しごと戻してしまった
共有を作る前に書いた Issue を、読み直す
アイコンの Issue は、1週間ほど前に書いてありました。共有の機能を作る、ずっと前です。そのときは、「料理のあとは、ベータ版まで機能を足さない」と決めていたので、後回しにしていました。
取りかかる前に、Claude Code が Issue を読んで、こう言いました。
Issue を書いたのは共有を作る前で、「ほかの人にアイコンを見せること」は対象外になっている。今は共有があるので、アイコンがいちばん役に立つのは、みんなの共有の一覧と、共有のページになる。
そのとおりでした。Issue の「対象外」には、こう書いてあります。
ほかの人に、アイコンを見せること（共有）
書いたときは、正しい線引きでした。共有がまだないのだから、見せる先がありません。でも今、この Issue のとおりに作ると、「自分にしか見えないアイコン」ができあがります。ヘッダーの右上に自分の顔が出るだけの機能です。
かといって、Issue の対象外を、黙って対象にするわけにもいきません。見せるほうには、規約とプライバシーポリシーの改定が要ります。通報の扱いも、共有を止めたときの扱いも、決めることがあります。
2つに分けました。
- 1つ目（もとの Issue）：アイコンを登録できる。自分にだけ見える
- 2つ目（新しい Issue）：共有のページに、アイコンを出す
そして、本番には、2つをまとめて出すことにしました。規約の改定を、1回で済ませるためです。
古い Issue は、書いたときの前提で書かれています。前提が変わっていたら、取りかかる前に、読み直す。当たり前のことですが、Issue に「対象外」と書いてあると、それ以上考えずに進めてしまいそうになります。
Google の画像は、使わない
ハコヅミのログインは、Google アカウントです。Google からは、名前と、プロフィールの画像の URL が届きます。
アイコンを登録していない人に、この Google の画像を出す。よくある作りです。登録の手間がなくて、最初から顔が出ます。
ハコヅミでは、使いません。未設定の人は、人の形の絵のままです。
理由は、表示名を作ったときと同じです。Google の名前は、本名のことが多い。プロフィールの画像は、本人の写真のことが多い。それが、本人の知らないうちに、ほかの人に見える場所へ出てしまうのを、避けたいからです。
「見せるものは、本人が、見せるために登録したものだけ」。表示名で引いたこの線を、アイコンでも守ります。
テストでも、確かめています。テスト用の利用者に、Google の画像の URL をわざと入れておいて、ヘッダーにも、アカウントの画面にも、ページの中身のどこにも、その URL が出てこないことを見ます。
切り取るのは、ブラウザ
画像を選ぶと、ブラウザの中で、まん中を正方形に切り取って、256px に縮めてから送ります。切り取る場所を自分で動かす機能は、作っていません。
サーバーは、画像の種類と大きさは確かめますが、「正方形かどうか」は見ていません。Cloudflare Workers の中で画像を読み解く処理を、入れていないからです。代わりに、画面で出すときに、いつも丸く切り抜きます。正方形でない画像が直接送られてきても、見た目は崩れません。
画面イメージの案から、選ぶ
Issue には、こう書いてありました。
文言と見た目は、取りかかるときに、画面イメージの案を出して、人が選んでから作る
ヘッダーの右上は、今、人の形の絵と表示名が、枠の中に並んでいます。ここにアイコンをどう入れるか。Claude Code が、実際の画面に案をはめた絵を、3つ出してくれました。
上から、今の形・案A・案B・案C（架空のデータ）
- 案A：今の枠のまま、人の形を、小さなアイコン（20px）に替える
- 案B：枠をなくして、アイコンを少し大きくする
- 案C：アイコンだけを大きく出す。名前は出さない
わたしは、案A を選びました。今の見た目からの変化が、いちばん小さい。未設定の人と、並びが同じになる。Claude Code のおすすめも、案A でした。
アカウントの画面のほうは、「表示名」のまとまりを「プロフィール」に変えて、アイコンと表示名を1つのカードにまとめる案を選びました。
アカウントの画面の「プロフィール」（最初に作った形）
実物を見たら、小さかった
案A で作って、開発環境に出しました。自分のアカウントで、自分のアイコンを登録して、見ました。
小さい。
案A で作ったヘッダー（架空のデータで撮り直したもの）
絵で見たときは、これでよいと思いました。実物を、自分のアイコンで見ると、何の絵なのかが、分かりにくい。20px の丸は、人の形の線画なら読めますが、写真や絵には、小さすぎました。
こう頼みました。
案Cのアイコンサイズにして、その横に名前を出すイメージ案を出して。丸のアイコンの背後に現在の枠＋名称を出して、枠の左端はアイコンの背面にあるイメージ（伝わる？）
伝わりました。
直したあと。アイコンから、名前の札が出ている形
アイコンは 34px。その右に、今までの枠と表示名を置いて、枠の左端は、アイコンのうしろに隠します。アイコンを登録していない人のヘッダーは、今までのままです。
なぜ、絵で決めきれなかったか
案の絵は、ちゃんと、実際の画面の大きさで作ってありました。それでも、決めきれませんでした。
絵を見るときは、3つを見比べています。「どれが、今の画面になじむか」という目です。その目で見ると、変化の小さい案A が、よく見えます。
実物を見るときは、使っています。「これは、自分のアイコンだと分かるか」という目です。見ているものが、違いました。
それに、案の絵のアイコンは、はっきりした色の、単純な絵でした。自分で登録したアイコンは、もっと細かい絵です。小さくしたときに、つぶれ方が違います。
小さい部品の見た目は、絵では決めきれない。実物の大きさで、自分のデータで見て、はじめて分かる。そう割り切って、「選ぶ → 作る → 見て直す」の1回分を、最初から見込んでおくほうが、よさそうです。
透けた画像で、線が見えた
直したものを開発環境で見て、もう1つ、気づきました。
わたしのアイコンは、背景が透けた絵です。その丸の中に、うしろにある枠の、左端の線が、透けて見えていました。
アイコンを枠のうしろに「重ねた」ので、アイコンが透けていれば、うしろが見えます。案の絵のアイコンは、背景まで塗ってある絵だったので、気づきませんでした。
丸の中を、ヘッダーと同じ緑で塗るようにしました。
背景が透けた絵をアイコンにしたところ。丸の中に、線は見えない
テストも足しました。全部が透けた画像を登録して、枠の線が通るはずの場所を撮り、その絵が1色だけであることを確かめます。線が見えていれば、色が2つになります。
「今は見えません」を、その日のうちに書き換える
1つ目の Issue では、アイコンは、自分にしか見えません。アカウントの画面の説明には、こう書きました。
今は、ほかの利用者には見えません。
プライバシーポリシーの「共有にしても、見えないもの」にも、アイコンを足しました。
その数時間後、2つ目の Issue で、共有のページにアイコンを出しました。
みんなの共有の一覧。アイコンを登録していない人は、人の形
1人の共有のページ
説明の文は、こうなります。
ギア・キャンプ・料理のどれかを共有すると、表示名と一緒に、ほかの利用者に見えます。
「見えません」と書いた文を、同じ日に、「見えます」に書き換えたことになります。ポリシーの「見えないもの」からも外して、「見えるもの」に移しました。
これが本番で起きていたら、困ります。「見えません」と読んで登録したアイコンが、あとから、見える側に変わるからです。
そうならないように、2つをまとめて本番に出すと、最初に決めてありました。「見えません」の文は、開発環境にしか出ていません。本番の利用者が最初に読むのは、「共有すると、見えます」のほうです。
Issue を分けることと、リリースを分けることは、別の話です。作る単位は小さく、約束が変わる単位は1回で。
アイコンだけのスイッチは、作らなかった
ギア・キャンプ・料理には、種類ごとのスイッチと、1件ごとのスイッチがあります。アイコンにも、「アイコンを見せる・見せない」のスイッチを付ける手は、ありました。
付けませんでした。アイコンは、表示名と同じ、その人の「顔」です。共有をオンにしている人は、表示名が見えます。アイコンも、一緒に見えます。見せたくない人は、アイコンを登録しなければ、人の形のままです。
切り替えを増やすと、「何が見えていて、何が見えていないのか」を、覚えておくものが増えます。#62 で、スイッチの形を3回変えて、身にしみました。
代わりに、共有をオンにするときの確認に、1文を足しました。
表示名と、アイコン（登録していれば）も、見えます。
規約は、同じ日の3回目
共有にすると見えるものが増えたので、利用規約とプライバシーポリシーも、直しました。同じ日の、3回目の改定です。「最後に改定した日」の表示は、やはり変わりません。
前回、「同じ日に2回改定するくらいなら、まとめて書いておけばよかった」と書きました。その日のうちに、3回目です。反省が、まったく活きていません。
ただ、今回は、言い訳ができます。1つ目の Issue だけで本番に出していたら、4回目があったはずでした。まとめて出したので、3回で済んでいます。
直しを小分けにして、Actions の予算が減った
ヘッダーの直しは、2回ありました。大きくする直しと、緑で塗る直し。それぞれ、別の PR にして、出しました。
その夜、GitHub の請求の画面を見ると、Actions の予算の残りが、10% を切っていました。
ハコヅミの CI は、PR を1つ出すたびに、約 13 分を使います（型チェックと、3つに分けた画面のテスト）。マージすると、デプロイで約 2 分。小さな直しでも、1本で 15 分です。Claude Code に数えてもらうと、今月は、13 日で、CI が 156 回、デプロイが 143 回、流れていました。
無料の枠（月 2,000 分）は、最初の1週間で 90% を使い、そのあと使い切りました。そこからは、使った分だけの請求です。金額は大きくありませんが、予算に達すると、CI もデプロイも止まります。本番に、出せなくなります。
予算を上げたうえで、進め方も変えました。2つ目の Issue では、機能、規約とポリシーの文、使い方のページ、お知らせ、プロジェクトのメモを、全部1つの PR に入れて、push は1回にしました。見た目の確認は、push の前に、手元で撮った絵で済ませます。
受入の直しを小分けにしたくなるのは、「言われたことを、すぐ直して、すぐ見せたい」からです。気持ちは分かりますが、1回ごとに 15 分が流れます。ヘッダーの2つの直しは、1つ目を見たときに、もう少し触って、透けた画像にも気づいていれば、1本で済みました。受入で見るときは、1つ見つけても、そこで止めずに、ひととおり触ってから伝える。これは、わたしの側の直しどころです。
確かめたあとに、直しごと戻してしまった
最後に、小さな失敗を1つ。Claude Code の失敗です。
透けた画像のテストを書いたあと、Claude Code は、「このテストは、本当に、直しがないと落ちるのか」を確かめました。直した1行を、わざと元に戻して、テストを流します。落ちました。テストは、ちゃんと働いています。
ここまでは、よい進め方です。問題は、そのあとでした。
元に戻した1行を、もう一度直すために、Claude Code は、Git で「そのファイルを、最後に記録したときの状態に戻す」操作をしました。ところが、直しは、まだ記録（コミット）していませんでした。戻った先は、直す前の状態です。直しごと、消えました。
Claude Code は、すぐに気づきました。戻したあとに、直しの行があるかを数えていて、それが 0 だったからです。同じ直しを入れ直して、テストを流し直しました。失ったのは、数分です。
「直しを外して、テストが落ちることを確かめる」のは、よい習慣です。ただ、外す前に、直しを記録しておく。そうすれば、戻す先が、ちゃんと「直したあと」になります。
そして、何かを戻したら、戻ったあとの状態を、見る。今回、被害がなかったのは、そこを確かめていたからでした。
おわりに
- 古い Issue は、書いたときの前提で書かれている。前提が変わっていたら、取りかかる前に読み直す
- 「対象外」を、黙って対象にしない。分けて、別の Issue にする
- 見せるものは、本人が、見せるために登録したものだけ。Google の画像は、代わりにも使わない
- 小さい部品の見た目は、絵では決めきれない。実物の大きさで、自分のデータで見る
- 重ねたものは、透ける。背景まで塗った絵だけで試すと、気づかない
- 作る単位は小さく、約束が変わる単位は1回で。Issue を分けても、リリースはまとめられる
- 切り替えを増やすと、覚えておくものが増える。同じ「顔」なら、同じスイッチで動かす
- 受入で1つ見つけても、そこで止めずに、ひととおり触ってから伝える
- 直しを外して確かめる前に、直しを記録しておく。戻したら、戻ったあとを見る
アイコンは、今日、本番に出ました。本番の「みんなの共有」の一覧には、まだ、だれも並んでいません。
テスタを募集しています。キャンプに行く方、よければ、最初のアイコンになってください。