リリース判定とは｜本番移行の前に決めておく判定基準と、監査で見られる記録

リリース判定とは、開発・変更したシステムを本番環境に出してよいかどうかを、あらかじめ決めた基準に照らして判断する手続きです。IT全般統制の変更管理では、「承認されたものだけが本番に反映されているか」を確かめる最後の関門にあたります。

テストが終わっていても、リリース判定がなければ、本番に出すかどうか確定することができません。監査人が変更管理で確かめたいのは、まさにその判断が誰の承認で、何を根拠に行われたかです。

この記事では、日本公認会計士協会東京会テクノロジー委員会の報告書「公認会計士のためのQAで学ぶテクノロジー」（2024年6月）のQ10をもとに、リリース判定の進め方と、監査で見られる記録をまとめます。

---

リリース判定は変更管理の最後の関門

システムの変更管理は、「チケットを用いたタスク管理」「ソースコードの変更管理」「リリース判定の実施及び本番環境への反映」の3段階で進みます。リリース判定は、この3段階目にあたります。各段階で残る証跡は「IT全般統制（ITGC）とは」の変更管理の章で整理しています。

1段階目と2段階目では、変更の要件が記録され、コードの変更がレビューされて承認されます。しかし、レビューで承認されたコードが、そのまま本番に出てよいとは限りません。複数の変更を組み合わせたときの動き、データの移行、利用者への周知など、コード単位のレビューでは見えないことが残っているからです。

リリース判定は、そうした残りを確認したうえで「本番に出してよい」と組織として決める場面です。ここが機能していないと、レビューは通っているのに本番で障害が起きる、あるいは承認の記録がないまま本番が変わる、という状態になります。監査で「承認後に本番反映されているか」が問われるのは、この段階です。

判定の前に終わっているべきテスト

リリース判定は、テストの結果を材料にして行います。本番環境とは別の環境で行うテストには、一般的に次の4つがあります。

ここで押さえておきたいのは、テストを行う環境の違いです。単体テストからシステムテストまでは、バグや問題点を見つけるための「検証環境」で行います。運用テストは、ハードウェアやOS、ネットワークまで本番に近づけた「ステージング環境」で行うことがあります。

検証環境では問題がなかったのに、本番で初めて不具合が出る。この差を小さくするのがステージング環境の役割です。リリース判定では、どのテストを、どの環境で、どこまで消化したかが判断の材料になります。

判定基準は会議の前に文書で決めておく

リリース判定で最も大事なのは、判定基準を先に決めておくことです。冒頭の報告書は、判定基準について次のように書いています。

どのような否認条件に該当した場合に、その時点でのリリースを厳格に否認するのか明らかな基準を設けるべきである。

さらに、この基準はリリース判定の会議が開かれる前に、理想的にはプロジェクトの開始時点で、関係者に共有されていなければならないとしています。

基準を先に決めるのは、リリース直前になってから考えると、その時点の状況に合わせて基準が緩みやすいからです。「重大な不具合が残っていたらリリースしない」と決めていても、何を重大とするかが決まっていなければ、判断は会議の場の空気に左右されます。

リリース判定のチェックリスト（判定基準の例）

判定基準には、たとえば次のような項目を入れます。会議に持ち込む資料も、この項目に沿って揃えておくと判断がぶれません。

• 計画したテストケースの消化率と、未消化のものの扱い
• 残っている不具合の件数と重要度の上限
• 利用者・業務部門による受入れの承認があること
• 切戻し手順が用意され、確認されていること
• 本番移行の手順書が承認されていること

どの項目を入れるかは、会社やシステムによって変わります。否認する条件が文書になっていて、判定の前に関係者が知っていることが大事です。

リリース判定会議は客観的な根拠で決める

判定基準を決めていても、実際の会議でそれが守られるとは限りません。報告書も、リリース判定の会議で起こりうることとして、次の場面を挙げています。

締め切りに間に合わないなどの理由で、あらかじめ決められた判定基準等を満たさない状態でもリリースをしかねないケースなどが起こることがある。

リリース日は、利用者への告知や業務の切替日と結びついていることが多く、後ろにずらしにくいものです。だからこそ、会議には判定基準とテスト結果という客観的な材料を出し、それに照らして判断した記録を残す必要があります。

例えば、機能が揃っていないのに、リリース日に間に合わせることを最優先してリリースしたシステムがありました。一応稼働はしていたものの、機能が足りず、利用者からの印象が落ちる場面もありました。

基準を満たさないままリリースすると決める場合もあるでしょう。その場合でも、どの基準を満たしていないか、なぜそれでも出すのか、誰が承認したかを記録しておけば、後から判断を検証できます。監査で問題になるのは、基準を外れたこと自体よりも、外れた判断の記録が残っていないことです。

リリース計画に入れておく項目

受入れが終わったシステムは、あらかじめ決めたリリース計画に沿って本番に移します。リリース計画に含める要素については、報告書が日本システム監査人協会の「システム管理基準ガイドライン」を引いて例を挙げています。大きく分けると次のとおりです。

このリリース計画そのものを権限者が承認することも、組織に組み込むべき統制活動の一つです。

あわせて、リリース後の運用準備も確認しておきます。運用手順書や保守マニュアル、リリース直後の切戻し手順、セキュリティインシデントの対応手順などです。特に切戻し手順は、リリース判定の基準に入れておくと、「戻せない状態で出す」ことを防げます。

リリース後の稼働後評価

本番に出したら終わりではありません。リリース後は、計画に沿って稼働後評価を行い、すべての機能が本番で過不足なく正確に動いているかを検証して、その結果を文書にしておきます。

理由は、後から不具合が出たときに、それがリリースに起因するものかどうかを切り分けられるからです。稼働後評価の記録がなければ、「リリース直後は正しく動いていた」ことを示せません。そのため、稼働後評価の結果を権限者が承認することも、大切な統制活動の一つとされています。

会計の目線で言えば、稼働後評価は「新しいシステムで最初に締めた月次の数字が、旧システムと整合しているか」を確かめる場面でもあります。データ移行を伴うリリースでは、移行前後の件数や残高の突合を、稼働後評価の中に入れておくとよいでしょう。

監査で見られる証跡

IT全般統制の変更管理で、リリース判定に関して監査人が確かめるのは、おおむね次の記録です。

すべてのリリースで、ここまでの記録を紙で揃える必要はありません。承認と本番反映の順番が、記録から確かめられることが重要です。承認の日時より前に本番が変わっていれば、どれだけ丁寧なテストをしていても、変更管理の不備として指摘されます。監査で実際に多い指摘は「監査で指摘されるIT統制不備トップ10」にまとめています。

▶ IT全般統制チェックリスト（自己点検用）をダウンロードする

プルリクエストとCIで開発している会社の場合

ここまでの話は、判定会議を開くような比較的大きなリリースを想定しています。一方で、プルリクエストとCIで小さな変更を毎日のように本番に出している会社では、変更のたびに会議を開くことはできません。

この場合は、リリース判定の役割を、開発の仕組みそのものに持たせます。

• 判定基準：マージの条件（レビュー承認の人数、CIのテストが通っていること）として、ブランチ保護の設定に書く
• 判定：条件を満たしたプルリクエストだけがマージされ、本番に反映される
• 記録：プルリクエストの承認記録、CIの実行結果、デプロイのログがそのまま残る

つまり、判定基準が「人が会議で確認するもの」から「システムが毎回確認するもの」に変わります。そのぶん、ブランチ保護やCIの設定そのものを誰が変えられるか、という点が監査で見られるようになります。設定を変えれば、判定基準を黙って緩めることができるからです。GitHubでの具体的な設定は「IT全般統制の変更管理｜GitHubのプルリクエストが監査証跡になる仕組み」で解説しています。

---

リリース判定に関するよくある質問

Q. リリース判定とは何ですか？

開発・変更したシステムを本番環境に出してよいかどうかを、あらかじめ決めた基準に照らして判断する手続きです。IT全般統制の変更管理では、承認されたものだけが本番に反映されているかを確かめる最後の関門にあたります。

Q. リリース判定会議では、何を確認しますか？

テストの消化状況、残っている不具合の件数と重要度、業務部門による受入れの承認、切戻し手順、本番移行の手順書の承認などを、会議の前に決めておいた判定基準に照らして確認します。どの項目を基準に入れるかは、会社やシステムによって変わります。

Q. 判定基準を満たさないままリリースしてもよいですか？

満たさないまま出すと決める場合もあります。その場合は、どの基準を満たしていないか、なぜそれでも出すのか、誰が承認したかを記録に残します。監査で問題になるのは、基準を外れたこと自体よりも、その判断の記録が残っていないことです。

Q. プルリクエストとCIで開発している会社でも、リリース判定は必要ですか？

必要です。ただし、変更のたびに会議を開くのではなく、マージの条件（レビューの承認やCIのテスト）としてブランチ保護の設定に判定基準を持たせる形になります。そのぶん、設定そのものを誰が変えられるかが監査で見られます。

まとめ

リリース判定は、変更管理の流れの最後で「本番に出してよい」と組織として決める手続きです。判定基準を会議の前に文書で決めておくこと、判定と承認の記録を残すこと、リリース後に稼働後評価まで行うこと。この3つが揃って初めて、監査で「承認後に本番反映されている」と示せます。会議で回す会社でも、プルリクエストとCIで回す会社でも、基準を先に決めて記録を残すという考え方は変わりません。

リリース判定の基準づくりや、変更管理の記録の残し方を見直したいという方は、オントロジーへ気軽にご相談ください。

---

参考資料

• 「公認会計士のためのQAで学ぶテクノロジー」Q9・Q10（日本公認会計士協会東京会テクノロジー委員会 研究報告書、2024年6月）