「監査が入ります」という連絡が来たとき、心拍数が上がった。相手は大手製薬メーカーの品質保証部門。治験データを扱う自社の治験CRMシステムが、GCP（Good Clinical Practice）に準拠した運用をしているかを確認しに来る、というものだった。
技術面の対応は自分が担当することになった。
監査当日に気づいたこと
当日の部屋には、相手側が一人、こちらは自分と品質管理の部長の二人だった。
質問が来る。答える。それだけだった。
緊張感はあった。慣れない場だから当然だ。でも終わってみると、やっていたことはシンプルで、自分たちがやってきたことをそのまま話すだけだった。嘘をつく必要も、かっこつける必要もない。会社の要件と違うことを言う必要もない。自分たちが実際にやってきたフローを、そのまま話す。それだけだった。
あとは知らない、というスタンスだった。自分の範囲を正直に話す。それ以上でも以下でもない。
「こうなる」とわかっていた理由
なぜそう割り切れたか。日頃からそうやって仕事をしていたからだ。
監査が入ると聞いて「まずい」と思う状態は、日常の運用と監査対応の間に乖離がある状態だ。普段やっていないことを急に取り繕う。書いていないことを書いたように見せる。そういうことが必要な状態は、そもそも日頃の仕事が監査に耐えられないということだ。
規制産業でシステムを管理するということは、常に誰かに見せられる状態で仕事をするということだと理解してからは、監査の怖さが変わった。
事前準備でやったこと
とはいえ、準備は3週間かけてやった。
ログ設計の見直しと証跡の整備
監査証跡（Audit Trail）として「誰が・いつ・何を変えたか」が記録されているか確認した。一部のテーブルで変更前後の値が記録されていないことが判明し、スキーマを修正した。
変更管理ドキュメントの整備
GitLabのマージリクエストと変更管理台帳を対応づける仕組みを整えた。「いつ・誰が・何を変更したか・承認者は誰か」が追跡できる状態にした。
SOP（標準作業手順書）の確認と更新
実際の運用と文書が乖離していないかチェックした。古いSOPが放置されていると「文書と実態が違う」という指摘が入る。これは技術の問題ではなく、運用管理の問題として重大視される。
当日に聞かれたこと
実際に聞かれた内容はこういうものだった。
- 「ユーザーアカウントの権限管理はどうなっていますか？退職者のアクセス無効化フローは？」
- 「バックアップはどの頻度で取っていますか？復元テストは実施していますか？」
- 「システム変更時の承認フローを見せてください」
- 「本番環境と開発環境は分離されていますか？」
- 「システム障害が発生した場合のエスカレーションフローは？」
技術的に難しい質問ではなかった。「それが文書化されているか」「実際に運用されているか」を確認するものがほとんどだ。コードの品質より、ドキュメントと証跡が問われる。
当日、退職した業務委託スタッフのアカウントが一件、無効化されずに残っていることが発覚した。その場で無効化し、発生原因と再発防止策を口頭説明して、後日文書提出で対応した。慌てず、淡々と。
監査後に変わった視点
「信頼できるシステムとは、動くだけでなく、追跡できるシステムだ」という感覚が強くなった。
何が起きたかを後から確認できる証跡、変更の理由が残る変更管理、実態と一致したドキュメント。これは規制対応のためだけじゃない。インシデント対応でも、チームの引き継ぎでも、同じように機能する。
規制産業でのエンジニアリングは、「正しく動く」だけでは足りない。「正しく動いていることを証明できる」状態を維持することが仕事だ。
それを理解してからは、監査は怖いものではなく、日頃の仕事を確認してもらう場になった。