家を建ててから初めて見えるもの
自分のサイトを他人の目で見る方法 — ignoreBuildErrors、セキュリティの穴、Git二重構造まで。作ることと維持することは別の筋肉だ。
unstackd.ioがオンラインになった。
ドメインを接続し、ネームサーバーを変更し、ブラウザにアドレスを入力した。見慣れた画面が表示された。ヒーロースローガン、タイムライン、フッター。すべてあった。気分が良かった。
しかし、気分が良いことと、きちんとしていることは別の問題だった。
サイトを一つの「プロダクト」として見て、四人の専門家の目で点検してみた。シニアウェブ開発者、UI/UXデザイナー、セキュリティ専門家、サービス開発者。もちろん四人ともAIだった。しかし、それぞれの視点から出た指摘は本物だった。
結果は予想より長かった。
最初の指摘：ignoreBuildErrors: true。
これは数週間前、ビルドエラーが出るたびに追加した設定だ。「エラーがあってもとりあえずビルドしろ。」プログラミングを知らない人の論理では合理的だった。エラーが出ればサイトが表示されず、サイトが表示されなければ進められないから、とりあえず表示させよう。
問題は——これがシートベルトを切って運転するのと同じだったということだ。
TypeScriptはコードの型が合っているか検査するツールだ。「この変数は数値でなければならない」と定めておけば、誤って文字列を入れた時にビルド段階で警告してくれる。その警告をすべて無視する設定をオンにしていたのだ。
修正に10個のコミットが必要だった。
二番目の指摘：セキュリティ。
管理者APIに入力検証がなかった。つまり——誰かがサーバーにデータを送る時、送るべきフィールド（「タイトル」「内容」「状態」のようなもの）以外に任意のフィールドを紛れ込ませることができたということだ。
一人運営のサイトにハッカーが来る確率は低い。しかし「確率が低い」は「やらなくていい」という意味ではない。
ホワイトリストというものを作った。許可されたフィールドのリストをあらかじめ決めておき、リストにないものはすべて捨てる。
一行も自分で書いていない。AIが書いた。私がしたのは「このセキュリティ脆弱性があるから直せ」と指示しただけだ。
三番目は少し恥ずかしい問題だった。
ホームページの下に巨大な空白があった。エントリーが9個しかないのに、フッターに辿り着くまで延々とスクロールしなければならなかった。原因は二つ。ヒーロー領域に「最小高さ75%」が設定されており、コンテンツ領域に「残りのスペースをすべて埋めろ」という属性がついていた。
作っている時は気づかなかった。「こうすればきれいに見えるだろう」と入れた属性が、エントリーが少ない時に空白を生み出していた。完成してから初めて見えるもの。
そして最も混乱した問題：Gitの構造。
プロジェクトフォルダの中に.gitが二つあった。ルートに一つ、site/の中に一つ。両方とも同じGitHubリポジトリを指していたが、それぞれ異なる時点のコードを追跡していた。ある修正はsite/site/のパスに適用され、あるものはsite/に適用されていた。
これは最初にプロジェクトを作った時に構造をちゃんと整えなかったから生じた問題だ。Episode 02で「計画がコードより先だ」と学んだのに、その教訓がここでも繰り返されたのだ。
今日、重複したsite/.gitを削除し、不要なファイルを整理した。旧バージョンのプロトタイプ3個、完了した作業指示書3個、複製された文書7個、空のフォルダ、キャッシュファイル。全部合わせると20個以上の不要なファイルがプロジェクトに溜まっていた。
この過程で気づいたことが一つある。
作ることはワクワクする仕事だ。機能を追加し、画面に何かが現れ、デプロイボタンを押せば世界に公開される。そこには達成感がある。
しかし点検することは退屈な仕事だ。型エラーの修正、セキュリティ検証、空白の除去、フォルダの整理。これは新しいものを作ることではなく、すでに作ったものを磨く作業だ。画面に見える変化がない時もある。
夕方の時間しかない人にとって、この退屈な時間を別に確保するのは難しい。限られた時間で新しい機能をもう一つ作りたい誘惑がある。
だからこれをルールにすることにした。 新機能を三つ作ったら、一回は点検の時間を持つ。 3:1ルール。
家を建てたら、たまには屋根を見上げなければならない。