検証に通らなければ、公開できないようにする
正確さを気合いで保つのは無理です。仕組みで落とすようにした話。
旧暦カレンダーを作るとき、最初に考えたのは「間違えたらどうやって気づくか」でした。旧暦の計算は、ほとんどの年で正しく、たまにずれます。たまにずれるものは、目視では見つかりません。正しい年を10個確認しても、ずれる年が11個目にあれば意味がないからです。
そこで、計算結果を国立天文台の暦要項と機械的に突き合わせる検証を書き、それが通らない限りビルドが完了しないようにしました。検証が落ちればサイトは生成されず、公開もされません。
なぜ「あとで確認する」ではだめか
確認を人の手順として置くと、忙しいときに飛ばされます。飛ばしても何も起きないので、飛ばしたことにも気づきません。そして事故は、飛ばした回の中で起きます。
手順を仕組みに変えると、飛ばせなくなります。ビルドが通らなければ公開できないので、確認を省略したまま先に進むという選択肢が消えます。規律を意志で保たず、通り道の形で保つという考え方です。
他のサイトでも同じ形にしている
- データベース型のサイトでは、データファイルの型検査をビルドの通過条件にしている。必須項目が欠けたデータは公開されない
- リンク切れの検査を用意し、外部リンクが死んでいれば気づけるようにしている
- 表記の揺れの検査を通し、意図しない表記が混ざっていないかを見る
いずれも派手な仕組みではありません。ただ、人が疲れているときに効くという一点で、書く価値があります。
この仕組みの限界
検証が守れるのは、検証が見ている範囲だけです。「この数値が暦要項と一致するか」は見られますが、「この文章の主張が妥当か」は見られません。実際、機械検査を通り抜けた種類の誤りに後から気づいたこともあります。
だから、仕組みで落とせるものは仕組みで落とし、落とせないものは人が読む、という分担にしています。仕組みを入れる目的は、人が読むべきものに集中できるようにすることです。
この記事の元
この記事は、「沖縄こよみ」と「おきなわビーチナビ」の制作で実際にやったことから書き起こしています。 方針そのものは運営方針にまとめています。