「ISO20000の規格について（21）」

それでは、今回は、「10.１リリース管理プロセス」についてお話したいと思います。 ISO20000規格要求事項、最後の要求事項です。

「10.１リリース管理プロセス」の概要を簡単に説明すると、「9.2変更管理」で 変更作業の承認が得られたものに関して、確実に本番環境へリリースつまり 「導入」できるような体制・ルールづくりが求められています。

具体的にはどのようなことが求められているかというと、以下の通りです。

1．リリースに向けた方針の策定と合意
2．リリース計画の作成、関係者との合意
3．リリース失敗時の対応
4．リリース後の成果物／記録の作成
5．リリースにおけるテスト環境の確立
6．リリース手続きの策定
7．リリースの失敗／成功の分析

これらは自組織で、明確にはなってはいなくても、 実施されている企業も多いのではないでしょうか。

例えば、「2．リリース計画の作成、関係者との合意」の計画であれば、導入作業で 必ず計画を策定しているかと思いますし、「7．リリースの失敗／成功の分析」のリリースの分析であれば、 導入作業に問題点があったか、なかったかについて報告を関係者へ行っているかと思います。

このようにみなさんが普段の業務で実施されている導入作業を対象に、実現方法を考えるとよいでしょう。

ただ、難点なのが、「1．リリースに向けた方針の策定と合意」になります。 規格では、「リリースポリシー」という表現で要求事項があり、単語だけ見るとなかなかイメージしづらい 内容に見えます。

この要求事項の目的は、導入作業にあたって、関係者とトラブルが起きないように事前に 導入作業の体制（年XX回の導入作業、導入時期、導入に対する連絡方法、導入作業体制など）を 納得してもらい合意を得るためです。

アプリケーションの開発・保守を実施されている組織であれば、 例えば、「年間のバグ及びメンテナンス作業をXX回実施します。メンテナンスは、XX月、XX月に実施し、 XX前に連絡通知します。」といったようなことが、仕様書などに含め合意することがあるかと思います。

リリースポリシーとは、いわばこのようなものです。

ただ、上記のように定期的に行うような作業がない、つまり、オンデマンドに対応する作業がほとんどの 組織では、リリースポリシーの策定はなかなか難しいかと思いますが、柔軟に考え実現することが重要です。

規格要求事項は、「リリースの頻度、タイプを記述したリリースポリシーを作成して、関係者と合意すること」を 要求していますので、これにあたるような作業を自組織で行っているかどうか考えてください。

例えば、パッチの適用やシステムの改修作業などでは、必ずXX月XX日XX時からXX時まで メンテナンス作業として事前に連絡をすることがあるかと思います（いわゆる計画停止等のご連絡）。

これは、システム停止や変更にともない、関係者にシステムが使用できなくなることを通知し、 ご理解いただくことが目的になります。

もし、メンテナンス作業、導入作業などの連絡メールや連絡文書をその都度作成されているのであれば、 これを、リリースポリシーと定義して、実現することができます。

規格のイメージは、導入体制の文書化ですが、これも規格要求事項の実現となります。 規格は、「～すること」や「～しなければならない」という要求になります。 具体的にどのようなやり方で実現するかは、組織で考えることができますので、皆様の運用に合った。 そして、お客様へ提供するサービスにあった実現方法にすることが重要です。