DEVELOPER'S JOURNAL
NOTE 04 · HOW I KNOW
証拠フロー雑記——自分のスクリーンショットを信じない理由
ひとりのプロジェクトが自分を騙さないために。証拠は追記のみで書き換えない、スクリーンショットは証明にしない、指標は合格ラインにすぎない、そしてこの流れが実際に止めた事故。
ここにあるのは自分で書いた記録で、失敗や迷い、まだ終わっていないことにも触れています。書いているのは現在の状態で、最終形でも、いかなる発売の約束でもありません。
はじめに
ひとりで作っていていちばん騙しやすいのは自分です。同僚もコードレビューも QA もなく、「それはまだ終わっていない」と言ってくれるのは自分だけで、その自分がその一言をいちばん言いたくない。頼む側、作る側、受け入れる側の帽子を三つ一つの頭にかぶっていて、最後の一つが最初に落ちる。
だからこのプロジェクトでは「できた」は感覚ではなく、証拠を伴って現れる状態です。この一編はその証拠の流れがどんな形か、実際に何を止めてきたかの記録。
追記はする、書き換えはしない
ルール一つ目、受け入れた証拠は変えない。正式なキャプチャのたびにディレクトリが一つできる——スクリーンショット、ログ、性能サンプル、ファイル一覧——封印されたらスクリプトはその中への書き込みを拒否し、新しい仕事は新しいディレクトリへ、失敗した試みは消さずに開示する。
実際にはこれで居心地の悪い場面がいくつか出ます。7 月 15 日に町から町への一局が初めて通り、試遊後の受け入れの一文は「試遊してみて特に問題ないと思った」——そして封印された受け入れチェックリスト十六項目、一つも埋めていなかったので、いまも 0/16 のまま。恥ずかしいけれどルールはルール、承認はあとから追記した別の記録で、0/16 を 16/16 に書き換えにも戻らないし、「当時観察した十六項目」をでっち上げもしない。最初は厳しすぎると思ったこのルールが、いまでは工程全体でいちばん価値があると思っています。記録しているのが実際に目の前に置かれたものであって、あとから審査したことにしたいものではないので。
スクリーンショットは証拠にならない
被写界深度
翌日、けっこうな事故が起きました。事後の監査で、すでに承認を通った一組の画面の静止画キャプチャに被写界深度の更新不良があった——つまり承認の判断に使ったスクリーンショットそのものが間違っていた。組はもう承認済み。対応は直すことではなく、修正した新しい組を独自の一覧つきで追記し、古いほうは一バイトも触らないこと。この日からスクリーンショットへの態度が変わりました。スクリーンショットは見るためのもので、証明のためのものではない。証明は検証器が出す OK の一行、ハッシュの一覧、計算し直せるもの。
同じ日にあと二つの失敗が記録に残っています。一つは劣化させたネットワークでのオンラインテスト、十分間走り切ったのに二つのクライアントがイベントを一つも受け取らず、終端処理は原因をでっち上げずに実行を却下して消去した——当時は本当に推定できなかったので。もう一つはもっと奇妙で、正式テストで二つのクライアントがきれいに終了したのに、締めで「読めない確認ファイル」が一つあったために実行全体が却下された。強い疑いとしては macOS がファイルに拡張属性を遅れて付けてタイムスタンプを動かした——でも強い疑いは証明ではないので、その二つのファイルにだけ最小限の補強(二回読む、少し間を空ける、全項目を比べる)をして、関連テストを全部やり直しました。記録では「原因はこれだと思うのでこう直した」と「原因はこれだと証明した」を分けています。
指標は合格ライン
ルール二つ目、機械の指標は必要条件であって十分条件ではない。新しい候補はどれも同じ形で来る——新しいファイル、ランタイムのスイッチ、専用の検証器、専用の証拠ディレクトリ——指標が全部緑になったあと、名前のついた人のゲートを通って初めて既定値を変えられる。
だからリポジトリにはこういう状態が長く存在します。ある照明方式は六つの指標が全部基準内、性能も予算内、証拠もそろっている、それでもランタイムの既定値は古いままで新しいほうは選択式。指標を通ることと目を通ることは別で、前者が自動的に後者になるべきではない。守護像のときがいちばんわかりやすかった——数千項目のチェックが全部通って、画面は祠の一部に見えた。機械は教えられたものしか見ません。
ロールバック ≠ 復旧
東京
8 月 10 日、東京のサーバーを前回の安定版に戻そうとして失敗、証明書チェーンの検証が通らず、自動ロールバックは成功、サービスはオンライン。記録は二文だけ、「復旧は成功しなかった。ロールバックは成功した。」あいだに「だから」は入れない。「ロールバック成功」を「旧版の復旧に成功」に言い換えるのはいちばん手軽な自己欺瞞で、嘘をつく必要すらなく、二つのことを一文にまとめるだけでいい。
このサイトの画像
同じ理屈でこのサイトについても。画像の大半は「ゲームプレイ映像をもとに再レンダリング」——開発中の実機画面から出発して雰囲気と構図のために描き直したもので、生のスクリーンショットでも最終画質でもない。少数は「実機スクリーンショット · 開発中ビルド」、エンジンからそのまま撮って縮小しただけ、たとえば下の一枚。あちこち粗いけれど、再レンダリングしていないからこそ証明できることがある——この場は存在する、このキャラクターたちは存在する、覇者は門の向こうに立っている。
実機スクリーンショット · 開発中ビルドおわりに
このやり方は遅い。検証器を書く時間が機能を書く時間を上回ることはよくあり、「できた」のたびに連鎖をもう一度走らせてからでないと口に出せない。それでも実際に止めてきたものがあります——向きを間違えた候補の連鎖は高くつく正式キャプチャの前にプローブが止め、イベントゼロのオンライン実行は説明されるのではなく却下され、欠陥のあるスクリーンショットの組は書き換えではなく追記で直され、東京の復旧は失敗として正直に記録された。成功しか記録しない工程だったら、全部消えていました。
引き換えに得たのは、ひとりで作る人間にとっていちばん希少なもの。五週間前に自分が書いた結論を、いまも信じられる。ゲームはまだ作っています。この一編は何ができたかではなく、どこまで来たかをどう知るかの記録です。