基礎: ビルドの検証記録を読む

3週間前、ヨガスタジオを経営する友人のために予約ウィジェットを作りました——チャットがあり、別の作業に気を取られながら急いで承認したプランがあり、実行があり、そしてちらっと見て流した緑のチェックマーク付きのバージョンカードがありました。火曜日、彼女から「もう一つのスタジオのサイトから同じビルドを使ってもいい？」とメッセージが来ました。「いいよ」と答える前に、3週間前の「検証済み」が実際に何を意味していたのかを確認しに戻り、そこで初めて、チェックマークを信用するだけでなく、こうした記録の一つを実際に読んでみたのです。

その記録はバージョンカード上、プレビューとコードアクションのすぐ隣——再デプロイやロールバックをするときに行く場所と同じ場所にあります。まず気づいたのは、それが会話全体ではなく、その一つのバージョンだけに紐づいているということでした。壊れた日付ピッカーを直そうとしてこのビルドを5回反復したので、記録がその一連のやり取り全体を語ってくれるのではと半ば期待していました。でも違いました。バージョン4の記録はバージョン4についてしか語りません。バージョン2がログインフォームが静かに失敗する状態で出荷されたことも覚えていませんし、バージョン5がバージョン3の何かをこっそり直したことも教えてくれません。それぞれの記録はスナップショットであり、差分でも変更履歴でもありません——リリースごとの変更履歴が欲しいなら、それはまったく別のビューです。この記録が答えるのは「このバージョンは大丈夫か」という一点だけです。

下にスクロールすると、記録は6行に分かれています。

6項目すべてが緑で、最初の直感は多くの人と同じ間違ったものでした。セキュリティが通ったから安全、アクセシビリティが通ったからアクセシブル、という思い込みです。どちらも、実際のチェック内容と照らすと成り立ちません。セキュリティチェックが意味するのは、表面的な問題——クエリへの文字列連結、クライアントバンドルに露出したAPIキー、ユーザー入力に対するevalなど——が見当たらなかったということです。侵入テスターと過ごす一日とは違います。友人のスタジオはこのウィジェットで決済を扱っておらず、名前と時間枠だけなので、その水準で十分でした。もしこれが決済フローだったら、それ以上のものを求めていたでしょう。

アクセシビリティは実際に立ち止まって調べる気にさせられた項目でした。「axeが通った」は網羅的に聞こえますが、実際はそうではないからです。裏側で動く自動化エンジンaxeは、WCAGの達成基準のおおよそ3分の1から半分程度——alt属性の欠落、コントラスト比の不備、ラベルのないフォームフィールド、明白なARIAの誤用——を確実に検出します。ただし、私が依頼したカスタム日付ピッカーのドロップダウンがスクリーンリーダーで使えるか、複数ステップの予約フローをTabキーで移動したときにフォーカスがまともな場所に着地するか、緑と黄色で色分けした「確定」対「保留」のステータスが赤緑色覚異常の人にとって問題ないかまでは分かりません。それらは、実際に障害のあるユーザーが頼っているツールを無効化した状態で、人がビルドを操作して確認する必要があります。axeは何もないよりはるかにましな本物のシグナルです——アクセシビリティにおけるスペルチェッカーの層であって、編集者ではありません。

適合性は、危うく読み飛ばしそうになった項目でした。「プランが約束した内容を含んでいる」というのは官僚的に聞こえます——自分が承認したプランを、気が散っている最中に書いたことを思い出すまでは。メール確認を頼んだのか、それともSMSだけだったのか、正直思い出せませんでした。この層はビルドを私の本当の意図ではなく、プランと照合するものであり、これが通ったということは、ビルドが私が言った「イエス」に一致していたということであって、必ずしも私が意図していたことに一致していたわけではないと分かりました。機能的にも堅牢でセキュアなビルドが、時間的な圧力で機能がひっそりと削られたことでこの層だけ落ちる、という話も聞いたことがあります。この層は、たとえ会話自体が多少ずさんであっても、ビルドをその会話に対して正直に保つためのものです。

6行の下には、二つのバケットに分かれた長めのリストがあり、そこに最も時間をかけました。「必修修正」項目は、現在ビルドに問題があることを示すものではなく、領収書のようなものです。ある一行には、レビュー層が日付の文字列がクエリにそのまま埋め込まれているケースを検出し、このバージョンが完了とマークされる前にすでにパッチが当てられていた、と書かれていました。私が見ていたのは開いた傷口ではなく、傷跡でした。この区別は重要です。必修修正の項目を現在進行中の警告として読んでしまうと、すでに解決済みの何かについて余計な心配をすることになるからです。

推奨事項リストはもっと長く、大半は、私が同僚のコードをマージをブロックしたくない立場でレビューするならば自分でも言いそうなことでした。「繰り返し出てくる時間枠レンダリングのブロックを共有コンポーネントに切り出すことを検討」「このエンドポイントにはレート制限がなく、内部の予約ツールとしては問題ないが、公開する場合は再検討の価値あり」。このリストには欠陥は一つもありませんでした。プランとコードだけを頼りに検証者が下した判断であり、ヨガスタジオの社内スケジューラーとしては、そのどの判断も妥当な側に着地していました。もし友人のスタジオがフランチャイズで、このウィジェットを50の店舗ページに埋め込んでいたなら、レート制限の件には異議を唱えたでしょう——その分類は検証者が推測するしかない文脈に依存しており、その推測があなたから見て間違っていると感じたら、正しい対応はラベルを最終決定と見なすことではなく、チャットでそう伝えることです。

きれいな必修修正列の隣にそれなりの分量の推奨事項リストがあるのを見て気づいたのは、その長さを危うく悪い知らせと読み違えそうになったことです。実際は違います。推奨事項がゼロのビルドは、狭い範囲しか見られなかったか、単に運が良かったかのどちらかです。「検討すべき」項目が積み上がっていて、必修修正には何も残っていないビルドこそ、実際に丹念に見てもらったビルドです。推奨事項の列は、本当の問題が取り除かれた後に残るべきものなのです。

もう一つ自分に課したのは、この記録が3週間前のものだったため、判定を信用する前に、実際にどのレイヤーが実行されたかを確認することでした。ここでは6つすべてが揃っていましたが、以前、あるビルドではアクセシビリティが合格・不合格のマークすらなく、単にリストから丸ごと欠けているのを見たことがあります。それは重要でないからスキップされたのとは違い、そのサイトの種類やフラグ設定ではそのチェックが実行されなかったという印です。この欠落をひそかな合格として読んでしまうのは、ざっと目を通しているときにこの形式がまさに誘発しやすい間違いです。

この記録は、ヨガスタジオの予約フローが実際にコンバージョンにつながるか、人々が時間枠選択のステップで離脱していないか、そもそもCalendlyへのリンクではなくカスタムウィジェットにしたのが正しい判断だったかどうかは何も教えてくれませんでした。検証が証明するのは、ビルドが約束通りに動くということであり、その約束自体が正しかったということではありません——これらは別の問いであり、あらゆる層をきれいに通過したビルドが、それでも実際のユーザーの前で失敗するのを何度も見てきました。「正しく動く」ことと「正しい問題を解決している」ことは、期待するほど重なっていないからです。この後半の問い、つまり2つ目の問いに実際に答えるのが計測ループであり、この二つは合わせて読むべきものです。誰も予約しない機能に対するきれいな検証記録は、それでもやはり誰も予約しない機能のままです。