【ITニュース解説】Your draft changed. Why is it still approved?

この記事は、ソフトウェア開発における「承認」の扱い方、特に「一度承認された内容が変更された場合、その承認状態はどのようにあるべきか？」という重要な疑問について深掘りしている。システムエンジニアを目指す上で、このような設計の考え方は、信頼性の高いシステムを構築するために非常に役立つため、具体的なテストの事例を通してそのポイントを理解することは重要である。

著者は、ローカルで動くドラフトレビュー用のプロトタイプを開発していた。このプロトタイプは、作成されたドラフト（下書き）をレビューし、「承認済み」とマークされたものだけをエクスポートする機能を持っていた。ここで問題提起されたのは、「一度承認されたドラフトの内容を編集した場合、その以前の承認はそのまま有効であるべきか？」という点である。もし内容が変更されたにもかかわらず、以前の承認が維持されてしまうと、承認された内容と実際にエクスポートされる内容が食い違うという深刻な問題が発生する可能性がある。

この問題の核心は、「承認」というものが、単なるデータベース上の「承認済み」という状態を示すマークではなく、「特定のテキスト内容に対して適用されるもの」であるという原則に基づいている。つまり、承認の対象となるテキストが少しでも変更されたならば、それまで有効だった承認は無効になるべきだ、というのが著者の主張である。これは、例えば契約書の内容を承認した後に、その内容が密かに書き換えられたとしても承認済みとみなされるのは不適切である、という直感と共通する考え方である。

著者はこの原則を検証するため、プロトタイプに対して様々なテストを行った。まず、ブラウザ上での動作を確認するテストを実施した。プロトタイプには、各ドラフトに対して「ソースチェック済み」「クレームチェック済み」「承認済み」の三つのチェックボックスが用意されていた。著者は、ブラウザの操作を自動化するツール（記事中ではPlaywrightとされている）を用いて、特定のドラフトのテキスト内容を編集する操作を実行した。その後、これらの三つのチェックボックスが全てリセットされ、未チェック状態に戻っていることを確認した。これは、テキストが変更された場合、それに伴って関連する全てのチェック状態（承認状態を含む）が自動的に解除される、という望ましい挙動がブラウザの画面上で正しく反映されていることを示す。しかし、画面上の表示がリセットされたことが確認できたとしても、実際にエクスポートされるファイルの内容も同様に変わっているかまでは、この段階ではまだ保証されない。

そこで次に、実際にダウンロードされるファイルの中身を検証するテストに進んだ。著者はまず、テキストを編集する前の初期状態で、承認済みのドラフトをプロトタイプからダウンロードした。ダウンロードされたファイル（CSV形式のファイル）を読み込み、その内容が期待通りの特定の文字列（例えば「$7.91」のような承認済みの情報を示す文字列）を含み、一方で承認されていない古い情報（例えば「earned $0」のような文字列）を含まないことを確認した。このように、単に「エクスポート完了」というメッセージが表示されることを信用するだけでなく、ダウンロードされた成果物そのものの内容を検査することが非常に重要である。

その後、先ほどと同じようにドラフトのテキストを編集し、ブラウザ上での承認状態がリセットされていることを再度確認した。そして、テキストを編集した後に再度全ての三つのチェックボックスをチェックして再承認し、その上でダウンロードを実行した場合に、新しい編集済みテキストがファイルに含まれていることを確認した。これは、「編集によって承認が無効になり、その後改めて承認を行うことで新しいテキストが有効な承認対象となる」という一連の流れが正しく機能することを示している。また、新しいドラフトを追加した場合、それが初期状態で未チェック状態であることも確認された。プロトタイプは、行った変更をメモリ上にのみ保持し、ブラウザをリフレッシュすると初期状態に戻るという制限があったことも記事で触れられている。これは、本番のアプリケーションではデータベースなどへの永続的なデータ保存機能が必要になる点と理解できる。

著者は、これらのテストをGoogle Chrome（記事中ではChromiumとされている）で実行し、全て成功したことを報告している。ただし、これはプロトタイプレベルでの検証であり、他のブラウザでの互換性、ウェブアクセシビリティ、見た目の品質、スプレッドシートのセキュリティといった側面については検証されていないことも明確に述べている。また、未承認状態のテキストがダウンロードされないことを検証するテストは直接は行われなかったようだ。

これらのプロトタイプの開発とテストを通して、著者は実際のアプリケーションに適用すべき重要なルールを見出した。それは、「承認は、特定のコンテンツバージョン（内容）に厳密に紐付けられるべきであり、そのコンテンツバージョンが変更された場合には、承認はクリアされるべきである」というものである。もし複数のユーザーが共同で作業するようなアプリケーションであれば、単にブラウザ上でチェックボックスを操作するだけでなく、サーバー側でもこのルールを徹底する必要がある。具体的には、サーバーがエクスポート処理を行う際に、現在保存されているテキスト内容と、承認が紐付けられている時点のテキスト内容が一致しない場合は、エクスポートを拒否するといった仕組みが必要になる。著者は今回、このサーバーサイドの設計やテストまでは実施していないと述べている。

最終的に、著者はこのドラフトレビュープロトタイプを製品化することなく一時中断したそうだが、この開発から得られた「テストパターン」は非常に価値があるとしている。そのテストパターンとは、「まず内容を承認する」「次にその内容を編集する」「その編集によって承認が無効になったことを検証する」「必要であれば再度承認する」「そして、最終的にダウンロードされる成果物（ファイル）の中身まで検査する」という一連の流れである。単にユーザーインターフェース（画面上の表示）が正しく動いているように見えても、実際にシステムが生成する最終的なデータが正しいかどうかを検証することの重要性を、このテストパターンは教えてくれる。システムエンジニアとして、このような深いレベルでの検証を行う視点は、信頼性の高いシステムを開発するために不可欠なのだ。