ソフトウェアにしてもハードウェアにしても、定期的なアップデートなど手を加える必要があります。アップデートは業務を効率化できる可能性があるのと同時に、様々なリスクも孕みます。新しいシステムが機能しなかったり、逆に非効率を生み出したりする原因にもなります。そのようなリスクを最小限におさえて、新しいシステムを導入するプロセスが「リリース管理」です。

今回はリリース管理とは実際に何を行うのかご紹介します。その重要性やKPIについても解説するため、システム担当の方は参考にしてみてください。

ITサービス管理やITILについて詳しく知りたい方はこちらの関連記事もご覧ください。

リリース管理とは

リリース管理とは、ITシステムの変更を安全・無事かつサービスの品質を落とさずに行うプロセスのことを指します。

詳しい手順に関しては後ほどご紹介しますが、ここではリリース管理とともに語られることの多い「DSL」と「DHS」についてもご紹介します。

DSLとは

「DSL」とは「Definitive Software Library（確定版ソフトウェアの保管庫）」の略で、新しいソフトウェアが実装された際に、そのコピーを保管しておく書庫のことです。「書庫」というのは比喩的表現で、物理的に保管する場合もあれば大規模なストレージの場合もあります。実環境やテスト環境とは物理的に異なる場所で厳重に管理されるのが一般的です。

DHSとは

「DHS」とは「Definitive Hardware Store（確定版ハードウェアの保管庫）」の略で、DSLのハードウェア版といえます。ただしハードウェアという「モノ」を保管するため、物理的に部屋に保管する必要があります。DSLはソフトウェアをコピーして保管して置けるのに対し、DHSは余分に1台ハードウェアを購入して保管しなければならないため、購入にも保管にもコストがかかります。

リリース管理とDSL・DHS

ソフトウェアにしてもハードウェアにしても、しっかりリリース管理を行なっていれば実際に使用したシステムはDSLもしくはDHLに全て保管されます。もしもシステムを変更した際に不具合や不都合があり、以前のシステムに戻したい場合はDSLかDHLを確認すれば戻せます。結果として、事業に対するリスクを最小限におさえることができます。

DSLやDHLへの保管はリリース管理の一側面でしかありませんが、重要なプロセスです。このように「新しいITシステムを実装する際、ビジネスへのリスクを最小限におさえる」ということがリリース管理となります。

リリース管理の目的

リリース管理の目的は「ITシステムの品質を一定に保つこと」です。新しいITシステムを導入することで品質が落ちないように、計画の立案やトラブルが起きた時のためのリスク管理をしています。ITシステムの変更において、技術的な面で確実に実装することもリリース管理の目的といえます。

正しいフローで稼働状況やITシステムを守り、実装やそれによって起こりうるトラブルをおさえることがリリース管理の主な目的です。

リリース管理と変更管理の違い

リリース管理と混同しやすいプロセスに「変更管理」があります。

変更管理とは、ITシステムに変更を及ぼす際に「その変更が本当に必要なのか」、もしくは「変更をしても問題ないのか」を管理します。対してリリース管理は、システムを変更することを前提に「どうすれば品質を保ったままITシステムを変更できるか」、もしくは「どのようにしてリスクを最小限におさえるか」を管理するプロセスとなります。

どちらも「ITサービスの品質を保つために、既存のシステム環境に加える変更を管理する」という目的は同じため、実際に現場に導入する際にプロセスの区別が曖昧になりがちです。ただし2つのプロセスに求められる役割や手段は大きく異なるため、明確に区別して管理しなければなりません。いずれも管理フローが曖昧になりがちなので、できれば担当を別にして運用しましょう。

リリース管理の2つプロセス

リリース管理は「リリース管理プロセス」と「展開管理プロセス」の2つのプロセスに分かれます。ここでは、2つのプロセスを理解するために「リリース」と「展開」の違いについてご紹介します。

「リリース」とは開発したソフトウェアに対するテストが成功して、製品版（リリース版）を出荷することを指します。この段階ではまだ「展開」はしていません。「展開」とは製品版を本番環境に導入してユーザーが利用できる状態のことをいいます。

「リリース管理プロセス」と「展開管理プロセス」の違い

上記の説明をもとに「リリース管理プロセス」と「展開管理プロセス」について詳しくご紹介します。

リリース管理プロセスとは「既存のシステムにどのような計画で手を加えるのか」といったタイミングやシステム単位などを決めていくことです。

ユーザーがシステムを使えるようにする「展開管理プロセス」では、「きちんと全てのシステムのテストが完了しているのか」という点や、変更作業が失敗した際のバックアッププランなどを確認・検討します。

2つのプロセスに区分する意義

もともとリリース管理は「リリース管理プロセス」のみでしたが、本番環境に展開する際の管理が明確でなかったため、後から「展開管理プロセス」と明確に区分するようになりました。リリース管理プロセスと展開管理プロセスを明確に区分することで確認事項などが明確化され、本番環境へ導入する際のリスクをよりおさえることができます。

管理結果を見る方法

リリース管理が機能しているかどうか判断するには、数値をとって可視化することが重要です。KPI（重要業績評価指標）として効果的なものには「予定通りにリリースが完了した件数」や「リリース後に発生したトラブルの件数」などがあります。

前述したようにリリース管理は範囲やプロセスが曖昧になりがちです。変更管理との区別を行い、担当者や管理フローを明確にしたうえでリリース管理を行うようにしましょう。そうすることで、確実にインシデントや問題の数、テストされていないソフトウェア数を減らすことができ、結果的にITシステムの品質を一定に保つことにつながります。

随時リリース管理がうまく進んでいるか、正しく管理フローが整っているかを確認するため、必ずKPIを設定しながら運用しましょう。慣れてきたら「顧客満足度」をKPIにすることで、より直接的な効果を生むリリース管理が行えるでしょう。

まとめ

リリース管理は変更管理と混同しやすく、成果が見えにくいなどの理由から、的確に運用されていないケースも多いです。「なんとなく管理している状態」にならないよう、どのタイミングで何をするのかを明確にし、KPIを設定して成果を可視化しましょう。

リリース管理にツールを利用し、時間を有効活用したい方にはIvanti Software株式会社のITILサービス管理ソリューション「ITSM SERVICE MANAGEMENT」がおすすめです。ハードウェアの交換時期の決定など、リリース管理における重要な役割を果たしてくれます。詳しくはこちらもご覧ください。