リリース管理の必要性をDevOpsと事例から考える

リリース管理とは？

リリース管理とは、新しいITサービスの導入や既存システムの更新が、無事に本番環境に展開されるよう管理していくことです。具体的な管理としては、計画・スケジューリング・作業範囲の策定・進捗管理などのプロセスが含まれます。ソフトウェアやアプリケーションをリリースする場合は、テストもリリース管理の工程の一つになります。

例えば、業務システムの一部をリプレースする場合、変更管理プロセスにおいて変更計画・承認・レビューが行われます。本番環境に展開して問題ないと承認されると、次にリリース管理のプロセスに移り、リリースのスケジューリングやタスクの割り当て、テスト、制御と進みます。業務システムを本番環境で実際に稼働させる際には、展開管理のプロセスとなり、ユーザーがPCやタブレットで新しい業務システムを使えるように準備、実行を計画します。

リリース管理の目的

仮に、業務システムの一部のアプリケーションだけを入れ替える簡単なリリースであっても、関係部署間の連絡ミスやスケジューリングの衝突などで、リリース・展開が遅れてしまう場合があります。あるいは十分に検証しないままアプリケーションをリリース・展開したことで、不具合や問題が多数発見され、ユーザーからクレームが寄せられる事態も考えられます。

このような問題発生やリリースの遅延、業務に影響を及ぼすダウンタイムの発生、アプリケーションの品質の低下などを防ぐためにも、適切なリリース管理が必要となります。

参考ページ：リリース管理はなぜ必要なのか？

DevOps時代のリリース管理

DevOps（デブオプス）とは「Development（開発）」と「Operations（運用）」を組み合わせた造語で、システムやソフトウェアを開発する際に、開発チームと運用チームが同時に協力して動き、スピーディーに開発を進める手法のことです。この方法を採用すると、スピード化はもちろんですが、開発チームと運用チームが同時に動くことで、効率の良い開発ができ、提供するITサービスの質を向上させるメリットがあります。

従来型のシステム開発では、開発チームが先にシステムやソフトウェアを開発し、その後に運用チームがリリース後の問題が発生しないように運用テストを実施。そのレポートを開発チームに渡し、修正や改善が行われると、再び運用チームが検証するという流れが一般的でした。しかしこの手法では、高速化の時代への対応が難しくなります。そこで、システム開発の手法として定着しつつあるのが、DevOpsです。

このDevOpsの手法なら、運用テストを効率的に実施できソフトウェアの精度も高められるため、リリース管理は不要ではないか？と考えますが、それは早計です。DevOpsを導入した場合でも、チーム間の調整やスケジューリングの管理は必要になり、サービスの品質を保つためには変わらずリリース管理は必要です。むしろ開発をスピードアップできるDevOpsだからこそ、問題の検出も頻繁になり、その問題発生に迅速に対応するためにもリリース管理の重要度はより高まっているのです。

事例でひも解く「リリース管理」

リリース管理と展開管理は「新しいITサービスの導入や、既存サービスをアップグレードする際、本番環境に展開するための管理・計画・スケジューリングのプロセス」と定義しています。

ソフトウェアやハードウェアが確実にリリースされるよう計画し、最終的にはITサービスの品質を維持・向上させることがリリース管理の目的ですが、どのようなプロセスなら成功するのでしょうか？事例をもとに解説していきます。

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

「リリース管理」のプロセスを検討する際に、よく混同されるのが「変更管理」です。まずは、この2つの違いを知ることで、「リリース管理（および展開管理）」が少しわかりやすくなります。

あるチームに新しい従業員が加わり、PCを追加したいという依頼がありました。

「変更管理」…そのPCを追加して、障害やダウンタイムなどの問題が発生しないかどうかを評価し、許可を出すのが変更管理。
「リリース管理」…許可を受け、実際にPCをセッティングし、本番環境に接続して、新入社員にPCを渡す一連のプロセスがリリース管理。

【よくある事例】ソフトウェアのリリース遅延

では、実際の例から「リリース管理」の効率的なプロセスを考えていきましょう。

【A社に起きたこと】
某通信企業A社では、CRMソフトウェアのリリースが完成後約2カ月間も滞留。わずか3カ月で25％近い顧客を失いました。リリース遅延によって、顧客はサービスクレジットや返金をタイムリーに受け取ることができず、リクエストのステータスを追跡できる仕組みもありませんでした。

リリース管理の成功事例

リリース遅延を招いた主な原因

ハードウェア調達、テスト環境、リリースサイクルにおいて関係者間の合意がとれていなかった
最新のテスト環境が準備できず、本来必要なテストを実施できていなかった
構成管理とリリース管理で統合された変更管理プロセスが存在しなかった

他にもソフトウェアのリリースの際に、多くの不具合や遅延が発生していたため、チームの士気が下がっていたことも、遠因の一つとして指摘されました。

無料Ebook リリース管理の成功事例～３つのプロセス連携が生み出す相乗効果～

続きを読む≫

リリース管理を改善するプロセス

A社は次に紹介する7つのステップで、現状のリリース管理のプロセスを改善していきました。

Step 1：既存のリリース管理プロセスを見直す

既存のリリース管理のプロセスの詳細を分析し理解することで、上記のようなリリース遅延を引き起こしたいくつかの要因を突き止めました。

Step 2：是正方針の決定

要因から今後の修正の方針を打ち出します。

承認されたリリースサイクルの決定と確立
プロセスの簡略化
タイムリーなテストの実施
CMS（構成管理システム）を活用したITインフラの制御

あわせて測定結果とメトリクスを評価に取り込むことや、リリース管理の研修会の開催なども決定しました。

Step 3：新しいリリースサイクルの決定と確立

関係者間で合意したリリースサイクルを定義します。A社の場合は最初1週間のリリースサイクルを試験的に運用しましたが、うまく行きませんでした。そこで2週間に変更し、このリリースサイクルが妥当だと判断しました。

他にも

関係者間で、リリース情報を共有する工程管理表を作成・共有
マーケティングや技術チームを含めたすべてのチームが連携できる作業の確立

なども決定しました。

Step 4：リリース管理プロセスを簡略化する

最小限の情報で適切な承認が行えるように、リリース管理プロセスを簡略化することも大事なポイントです。ただし、適切な簡略化のためには、何かしらの記録によって関係者間の情報共有を確実にする必要があります。「何が、どのように実行されたのか」をしっかりと記録し、共有していきます。

Step 5：確実な記録と情報共有のためツールを使用

A社は技術者・非技術者を含めた関係者が記録文書を基準に作業ができるよう、記録文書を基準とするリリース方針を決定しました。そこで必要になったのが記録のためのツールです。

【Tips：ツール選びのポイント】

ポイント：各サイクルで開発した内容を最小限の情報で効果的に記録できること

ServiceDesk Plusは、次のように正確で迅速なリリース管理ができます。

変更からリリースの起票が可能なため、ITインフラのアップグレードを簡素化
リリースに関するテンプレート・役割・ステータスを設定することで、リリース管理プロセスを細かくカスタマイズ
ワークフローと通知を設定し自動化することで、各関係者へ正確な情報提供が可能
カレンダー表示により、各リリースのスケジュールの衝突を回避

Step 6：CMSによるITインフラ制御の確立

A社はCMS（構成管理システム）を開発し、ツリー構造とCI（構成アイテム）階層を構築。これによってリリース管理されたITインフラによってソフトウェアを展開でき、すべてのアイテムを適切に配置してソフトウェアを使用することで、予期せぬトラブルを防ぎやすくなります。

Step 7：確実なリリース管理のため人材にも投資

ここであらためて、リリース管理でよく問題になる点を振り返ってみましょう。

どんなに簡単なリリースであっても、複数の担当者やチームが関わることで、コミュニケーション不足が発生するおそれがあります。そこでA社は構成管理、変更管理、リリース管理のチームを集めて研修会を開催しました。内容はリリース管理の基礎の復習やメトリクスの導入、各チームの役割や責任の確認など。構成管理、変更管理、リリース管理、そして人材の相乗効果によって、A社はリリース管理の改善に成功しました。