アジャイル変更リリース管理の ベストプラクティス 文責：Ben Cody、Julian Fish、Amita Abraham 2012年 11月

ホワイトペーパー

目次 ページ

変更管理の不備によるサービスデスクのインシデント数の激増 . . . . . . . . . . . 1

開発と運用間のプロセス断絶の問題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

アジャイル変更リリース管理のベストプラクティス . . . . . . . . . . . . . . . . . . . . . 2

結論 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1www.microfocus.com

変更管理の不備によるサービスデスクの インシデント数の激増

開発と運用間のプロセス断絶の問題

ビジネスではオンライン化が進んでいます。競争力を維持するために、IT 組織は革新的な

アプリケーションやサービスを継続的に提供する必要があり、多くの場合、そうした革新

的な製品がビジネスの顔になります。インフラの安定性を損なうことなく、アプリケー

ションを迅速に変更していく能力は「あれば望ましい」というレベルではなく、もはや必

須です。

開発チームはアジャイル手法を導入することで、このニーズに対応してきました。その結果、

新たなアプリケーションやサービス、あるいはその更新版を IT 本番環境にすばやく適用で

きるようになりました。しかし、IT 運用チームは、こうした変更を迅速にデプロイしなが

らも、変更に伴い追加のリスクが発生しないように配慮しなければなりません。ほとんど

の組織において、この 2 チーム間の引き継ぎは完璧ではありません。最近の調査 * によると、

サービスデスクに報告されるインシデントの 40% 以上がアプリケーションやサポートイン

フラへの変更不備に起因しています。開発チームと運用チーム間のプロセスが断絶してい

ると、組織が収益を創出する能力に深刻な影響を与える恐れがあります。

競争力を維持するために、IT組織は革新的なアプリケーションやサービスを継続的に提供する必要があり、多くの場合、そうした革新的な製品がビジネスの顔になります。

サービスデスクのインシデントの40%はアプリケーションやそのサポートインフラへの変更不備に起因しています。

__________

* Forrester/itSMF Q2 2011 US ITSM Online Survey (Forrester/itSMF 2011年 第 2四半期 US ITSMオン ラインアンケート )

図 1

出典：Forrester/itSMF Q2 2011 US ITSM Online Survey (Forrester/itSMF 2011年第 2四半期 US ITSMオンラインアンケート )

2

ホワイトペーパーアジャイル変更リリース管理のベストプラクティス

こうしたプロセスの問題をさらに悪化させるのが、ほとんどの IT 運用チームが IT インフ

ラに関連するインシデント、問題、変更を管理するために独自のシステムを使用している

という事実です。通常、こうしたシステムは、アプリケーション開発チームが要件、イン

シデント、機能強化、変更要求を追跡するために使用しているシステムとは異なります。

多くの場合 IT 運用チームは、アプリケーション開発チームが行った修正や変更にアクセス

することも、それらを確認することもできません。同様に、開発チームは、IT 運用チーム

がインシデント、問題、変更の追跡に使用するツールにアクセスできるケースはほとんど

ありません。このように機能ごとにサイロ化されたシステムが問題をさらに難しくしてい

ます。

プロセスとツールの断絶が生む問題を明らかにするために、通信プロバイダーの新しいオン

ライントランザクションポータルの事例を紹介します。開発チームは IT 運用チームに、本

番環境に別バージョンの Oracle データベースが必要になることをリリース数日前になるま

で通知しませんでした。IT 運用チームはリリースの詳細を確認できないため、デプロイメン

トプロシージャやデータベースアップグレードの必要性を知ることはできません。事態を

さらに複雑にしたのは、問題の Oracle データベースインスタンスを共有していた他のアプ

リケーションが新バージョンに対応していないことでした。その結果 IT 運用チームは、急

遽追加のハードウェアを調達し、新しいデータベースインスタンスを立ち上げることにな

りました。これによりアプリケーションリリースに追加コストと遅れが生じ、収益に影響を

与えたばかりか、開発チームと運用チーム間の溝はさらに深まったのです。

開発チームと運用チームの人員、プロセス、システムが統合されていないことがビジネス

に及ぼす影響は、変更やリリースの失敗によってビジネスの主要アプリケーションに不具

合が起きたときに明らかになります。

では、開発チームと運用チームにまたがるプロセスを合理化するにはどうすればよいので

しょうか。どうすれば、環境の安定性と制御を低下させることなく、変更リリース管理を

改善し、高速化できるでしょうか。

アジャイル変更リリース管理のベストプラクティス

すべてのインシデントを集約する単一の入り口を作成顧客がアプリケーションの問題に遭遇したり新機能を要求したりする場合は、電子メールを

送信するか、スプレッドシートや Word ドキュメントにニーズをまとめて提出するのが一

般的です。このアプローチで問題となるのは、こうした要求や問題の見落としが発生する

ことです。顧客は自分の要求のステータスを容易には追跡できません。顧客が自分のチケッ

トを送信してステータスを追跡できる中央ポータルがあれば、顧客満足度の向上に役立つ

でしょう。たとえば、リリース準備の段階で、アプリケーション開発マネージャは、アプ

リケーションの再設計に対応するために既存のサーバークラスタに新たな Web 階層の追

加をインフラチームに要求する場合があります。

_______________________________________________________________

統合された要求ポータルは問題の迅速な解決のためにインシデントを開発チームと運用チームの双方に割り当てます。

3www.microfocus.com

関連するサービスレベル契約 (SLA) を表示し、チャージバックと承認のために必要なコス

トセンター情報を収集する中央ポータルがあれば、アプリケーション変更をロールアウト

するプロセスをさらに合理化できます。加えて、統合された要求ポータルで、アプリケー

ション開発グループや運用グループ内でインシデントを適切なチームに自動的に割り当て

ることができれば、要求に迅速に対応して問題を解決できるようになります。

変更リリース管理プロセスを統合変更リリース管理プロセスを統合し自動化することで、複雑なデプロイメントスクリプトを

記述する必要がなくなり、変更を本番環境にリリースする際の人的ミスの可能性を排除で

きます。

重要なのは、運用チームと開発チームが、計画されている変更とそのロールアウトスケ

ジュールを完全に把握できるようにすることです。変更と不具合修正の要求は、開発チー

ムに割り当てられます。開発チームは、事前定義された本番環境への変更適用スケジュー

ル (「リリーストレイン」) を明確に把握することで、こうした変更を本番環境にロール

アウトしやすくなります。リリーストレインでは、アプリケーションと運用上の変更要求を

適用スケジュールと組み合わせて、両チームに最適なタイミングでロールアウトできる

ように支援します。

開発チームと運用チームが利用可能なリリーストレインを明確に確認できれば、機能と計

画された運用上の変更を容易に結合し、リリースの進捗状況を開発 / テスト / 本番環境まで

追跡できるようになり、変更不備の可能性を大幅に下げることができます。最初の要求に

対する変更を追跡することで、IT 組織は正確かつ詳細なステータス更新を相手先に提供で

きます。

_______________________________________________________________

統合された変更リリース管理はアプリケーション変更を本番環境に迅速に適用します。

図 2

インシデントを収集して SLAを表示する中央ポータル

4

ホワイトペーパーアジャイル変更リリース管理のベストプラクティス

統合されたプロセスを通じて開発チームと運用チームの協働を可能にすることで、本番環境の安定性を損なうことなくビジネスをサポートするアプリケーション変更を迅速にロールアウトするための態勢を整えることができます。

連結されたプロセスを得ることで、開発チームは、開発段階からテスト環境、本番環境まで、

要求に関連する変更をソースコードレベルで追跡できます。アプリケーションが本番環境

にデプロイされると、更新はアプリケーションの確定版メディアライブラリ (DML) エント

リに自動的に作成されます。こうしたアプリケーションプロセスをインフラ管理用の構成

管理データベース (CMDB) に関連付けることで、変更がリリースされると同時に更新が自

動的に項目に適用され、本番環境での動向に関する完全で一貫した記録が得られます。

統合されたプロセスを通じて開発チームと運用チームの協働を可能にすることで、本番

環境の安定性を損なうことなくビジネスをサポートするアプリケーション変更を迅速に

ロールアウトするための態勢を整えることができます。

完全な可視性を得るために統合カレンダを提供開発チームと運用チームの双方がアクセスでき、計画されている変更のすべてが週または

月単位で表示される統合カレンダは、両チームにアプリケーションアップデートのスケ

ジュールに対する注意を喚起するのに役立ちます。

_______________________________________________________________

図 3

アプリケーションと運用上の変更を単一のリリーストレインに結合

5www.microfocus.com

特定のリリーストレインの影響を受けるさまざまなアプリケーションを表示し、変更要求

の詳細までドリルダウンできるようになれば、開発チームと運用チームの双方に多大な価

値がもたらされます。この情報には、アプリケーション変更の詳細からデプロイするアー

ティファクト、さらにはインフラの変更情報を含めます。統合された変更カレンダにより、

開発チーム、リリースマネージャ、運用チームは、ソフトウェアとインフラに対し計画さ

れている変更をすべて 1 つのビューで確認できます。

統合カレンダを利用することで、開発チームとリリースチームは、利用可能な変更適用ス

ケジュールとともに、スケジュールされている本番環境のダウンタイムを完全に把握でき

ます。こうした情報を確認することで、両チームは、直近のアプリケーションパフォーマン

ス問題の解決など、インフラ変更の要求に適したタイミングを選択できます。運用上の変

更をリリーストレインに関連付けた場合は、変更の制御をそのトレインに委ねることにな

ります。トレインが承認され、実装準備完了のフラグが立つと、SLA に従って必要なイン

フラ変更を行うように運用チームに自動的に通知されます。このプロセスは、リリースト

レインの変更がすべて実装されるまで継続します。実装後レビューの後、CMDB および

DML を構成する構成管理システムに更新が適用されます。

承認済みの開発リリースを既存の運用保守スケジュールと関連付けることで、チームはリ

リース遅延とデプロイメントの混乱を回避できます。

統合カレンダは変更リリース用に利用可能なスケジュールの可視性をもたらします。

図 4

開発チームと運用チームに完全な可視性をもたらす統合カレンダ

6

ホワイトペーパーアジャイル変更リリース管理のベストプラクティス

結論

ビジネスのオンライン化が進む中、変更管理のスピードアップは必須条件です。企業は、

リリース管理チームや DevOps チームを開発チームと運用チームの橋渡しとして利用する

ことでメリットが得られます。開発チームと運用チームの人材やプロセスを連結するツー

ルとシステムは、両チームに必要な可視性をもたらし、アプリケーションに対する変更要

求を収集して高速化を図る上で役立ちます。統合された変更リリース管理戦略も、インシ

デント数の削減に貢献します。調査によると、全インシデントの 40% は変更の不備に起因

しています。開発チームと運用チームの枠を越えてプロセスを接続することで、業務部門

の IT 満足度が向上します。インシデントと問題を解決まで追跡することが可能になり、

アプリケーション変更が迅速になり、ビジネスユーザーは問題がいつ解決されるのか事前

に通知を受け取ることができます。

開発チームと運用チームの枠を越えてプロセスを接続することで、業務部門の IT満足度が向上します。インシデントと問題を解決まで追跡することが可能になり、アプリケーション変更が迅速になり、ビジネスユーザーは問題がいつ解決されるのか事前に通知を受け取ることができます。

162-JA0086-001A | S | 06/18 | © 2017 Micro Focus. All rights reserved. Micro Focusおよび Micro Focusロゴは、英国、米国、およびその他の国における Micro Focus、その子会社、関連会社の商標または登録商標です。その他すべての商標は、該当する所有者に帰属します。

お問い合わせ先：www.microfocus.com