リリース管理と展開管理のベストプラクティス文責 : Serena Software (現Micro Focus®)、 プロダクトマーケティング担当シニアマネージャ、 Mark Levy氏

ホワイトペーパー

目次 ページ

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

リリースと展開の変革 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

自動化は最適な着手ポイント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

リリースアーティファクトの制御とセキュリティ保護 . . . . . . . . . . . . . . . . . . . . 6

展開 / 配布ツールチェーンの統合 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

運用前環境の管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

非効率な引き継ぎの廃止 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

リリースプロセスの集中制御 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

結論とまとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1www.microfocus.com

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

今日の厳しい環境で競争力を維持するには、市場の変化に迅速かつコスト効率よく適応し

ていかなくてはなりません。このようなビジネスの機敏性を追求することで、IT 部門への

変更要求が大幅に増加することになります。この「スピードのニーズ」を満たすためには、

アジャイル手法と持続的な統合を導入することが論理的な第一段階ですが、多くの場合、

運用工程の後方にボトルネックを先送りするに留まっています。

ソフトウェアのテスト環境への展開や運用環境へのリリースをこれ以上早めることはでき

ません。リリースプロセスの管理の不備、チーム間のコラボレーションの欠如、手作業で

の展開のすべてがリリースの質を低下させ、ビジネスに高いコストを課す結果となってい

ます。開発チームと運用チーム間の引き継ぎは完璧とはいえず、最近の調査で、複雑な ITサー

ビスを運用している大規模組織で 2016 年中に発生した本番運用インシデントの最大 80%

がリリースの適切な管理の欠如に起因するという結果が出ても驚きではありません。開発

チームと運用チーム間のプロセスが断絶していると、組織が収益を創出する能力に深刻な

影響を与える恐れがあります。

このようなプロセスの問題をさらに悪化させるのは、運用前環境と運用環境でのリリース

および展開の管理に IT チームと開発チームがそれぞれ別のツールセットを使用することで

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

セスしたり確認することはできません。同様に運用チームが運用システムや、運用環境の

管理や保守のために IT チームが使用するナレッジベースにアクセスできるケースはほとん

どありません。このような機能的なサイロが問題をさらに難しくしています。

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

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

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

で通知しませんでした。IT 運用チームはリリースの詳細を見ることができないため、展開

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

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

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

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

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

響を与えたばかりでなく、開発チームと運用チーム間の溝がさらに深まりました。

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

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

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

ではどうすれば、環境の安定性と制御を低下させることなく、リリースや展開の品質とス

ピードを向上させられるでしょうか。そして開発チームと運用チームにまたがるプロセスを

合理化するにはどうすればよいでしょうか。

複雑な ITサービスを運用している大規模組織で2016年中に発生した本番運用インシデントの最大80%がリリースの適切な管理の欠如に起因してい ます。 ̶Gartner社

__________

* George Spafford、Ronni J. Colville、『How IT Operations Can Set Up an Effective, Centralized Release Management Process.』、Gartner社、2013年 6月 3日

2

ホワイトペーパーリリース管理と展開管理のベストプラクティス

リリースと展開の変革

アプリケーションソフトウェアのリリースと展開の方法を向上させたり変更することは容易

な作業ではありません。組織はサイロに分断され、いくつものツールが組み込まれ、現行シ

ステムをサポートするために開発された多くのプロセスが存在します。そのようなシステム

は、何かが変わると安定性を失い、使い物にならなくなる傾向があります。リリース管理は、

誰もが ( 多くは週末に ) 備えなければならない恐ろしい作業となってしまうのです。

運用環境へのリリースの品質とスピードを高めるには、何から始めればよいのでしょうか。

まずは、どのようにビジネスに価値を提供するかを理解し、無駄を排除し、小さく段階的

な変更を実行し、継続的な改善に焦点を当て、クイックウィン ( 短期の成果 ) を提供できる

よう、アジャイルなリーンアプローチを採用します。小さなアクションと変更が驚くほど

大きな成果をもたらします。大改革や大規模なロールアウト、長期にわたるプロジェクト

は必要ありません。どのようにビジネスに価値を提供するか、現行の環境、成功の基準値を

明確に理解するだけです。

ビジネスを可視化し洞察を得る最初に、ビジネスにとって本当に重要なのは何なのかを理解する必要があります。目的や目

標、ビジネスの観点から見た IT 部門の位置付けや役割を知ることが重要です。まずはすべ

ての関係者に話を聞いて、意見を集めます。異なる見方があることに驚くことでしょう。

ビジネス部門や財務部門の関係者から始めて、IT 部門に戻ります。アプリケーション開発

とトリアージチーム、運用チーム、運用環境サポートの意見も収集し、インシデントおよび

問題管理レポートを確認します。相互関係を把握し、クイックウィンを特定するためには、

他部門の文化を理解し、目的や目標および改善の優先順位について話し合うことが必要です。

成功をあらかじめ決めるあなたはビジネスに対して何を確約していますか。組織にとっての成功を定義してみましょ

う。成功を数値化し、その数値に対する達成度を計測できますか？どのようなリリース頻

度を確約し、実際にサポートしていますか。計画と現実の状況を数値化し、レポートを作

成できますか。展開サイクルタイムの計測についてはどうでしょう。ビジネスの最重要事

項をサポートするメトリクスを開発する必要があります。また共通の用語や概念を確立す

ることも重要です。

_______________________________________________________________

アプリケーションソフトウェアのリリースと展開の方法を向上させたり変更することは容易な作業ではありません。

相互関係を把握し、クイックウィンを特定するためには、他部門の文化を理解し、目的や目標および改善の優先順位について話し合うことが必要です。

3www.microfocus.com

システムを把握する「システムを把握」し、現行のリリースプロセスの詳細な見取り図を入手して、現状がビジ

ネスの目標とリリースポリシーにどの程度一致しているかを知る必要があります。ビジネ

スの要求から本番運用までのプロセスフローに着目し、どのようなフィードバックループ

が必要なのかを特定します。

_______________________________________________________________

図 1

リリース管理ダッシュボード

4

ホワイトペーパーリリース管理と展開管理のベストプラクティス

プロセスの情報フローと展開可能なすべてのアセットの存在箇所およびターゲットとなる環境を把握しなくてはなりません。

プロセスの中で最も時間がかかっている箇所、および品質の問題となっている箇所はどこ

ですか。情報とアーティファクトのさらに詳細なフロー解析には、バリューストリームマッ

ピングなどのリーン手法を活用するとよいでしょう。プロセスの情報フローと展開可能な

すべてのアセットの存在箇所およびターゲットとなる環境を把握しなくてはなりません。

リリースと展開のプロセス全体でリードタイムを短縮する目標を設定しましょう。自分が

担当する領域内で、スループットを最適化し、プロセスを簡素化し、応答性を高める方法を

見つけます。無駄やシステムの長い待ち状態をなくします。

_______________________________________________________________

図 2

リリース管理のプロセスフロー

図 3

ベーシックなバリューストリームマップ

5www.microfocus.com

リーンインとリーンアウトこの評価により、時間を費やしている箇所、最適化と簡素化が必要な個所がよくわかります。

規範となる順序や出発点はありません。手作業でのコード展開を自動化することから始め

るケースが多いですが、承認経路を自動化することで大きなメリットを即時に得られる場

合もあります。目標は、ビジネスの理解とシステムの把握による「リーンイン」と、リリー

スライフサイクル全体の無駄を特定して排除することによる「リーンアウト」です。グロー

バルに考え、ローカルに行動しましょう。システムには多くの停滞箇所があるものです。

スピードと制御を高めると同時に、アプリケーションの展開とリリースの品質の維持およ

び向上を可能にする、いくつかのベストプラクティスを紹介します。

自動化は最適な着手ポイント

自動化することで、貴重な人的リソースを忙殺することなく反復タスクを実行できます。

スタッフが移動してコードを展開しなくても、コンピュータが人間よりもはるかに上手く

一貫した方法でアプリケーションを展開します。手動タスクや引き継ぎの自動化は、最初

に検討すべき課題の 1 つです。自動化によって多くのクイックウィンが得られます。この

ようなボトムアップアプローチはインクリメンタルな実行が可能で、組織に大きな変更を

行うことなく速やかに導入できます。

_______________________________________________________________

目標は、ビジネスの理解とシステムの把握による「リーンイン」と、リリースライフサイクル全体の無駄を特定して排除することによる「リーンアウト」です。グローバルに考え、ローカルに行動しましょう。

手動タスクや引き継ぎの自動化は、最初に検討すべき課題の 1つです。自動化によって多くのクイックウィンが得られます。このようなボトムアップアプローチはインクリメンタルな実行が可能で、組織に大きな変更を行うことなく速やかに導入できます。

図 4

アプリケーション展開の自動化

6

ホワイトペーパーリリース管理と展開管理のベストプラクティス

リリースアーティファクトの制御とセキュリティ保護

コード展開の自動化とバージョン管理の導入は、業績の高い組織が導入しているベストプ

ラクティスの 2 つと考えられてきました。バージョン管理を信頼できる唯一の情報として

使用すると、エラーをピンポイントで特定したり、既知の状態に簡単にロールバックしたり、

新規アプリケーションを素早く展開することが可能になります。インフラや設定コードを

含む、アプリケーションのサポートと実行に必要なすべてをバージョン管理する必要があ

ります。またそれらのリリースコンポーネントはすべて、バージョン管理をサポートする

セキュアなリリースリポジトリに保管しなくてはなりません。

_______________________________________________________________

このリリースリポジトリにより、展開されたコンポーネントが運用前環境でテストしたも

のと同一であることが確認されます。リポジトリを使用しない場合、ネットワーク共有や

他のシステムからアーティファクトを取得しなければならず、セキュリティリスクやエラー

の発生率が高まります。

バージョン管理を信頼できる唯一の情報として使用すると、エラーをピンポイントで特定したり、既知の状態に簡単にロールバックしたり、新規アプリケーションを素早く展開することが可能になります。

図 5

リリースアーティファクトリポジトリ

7www.microfocus.com

変更プロセスとリリースプロセスが 2つのプロセス間で状態を遷移できる必要があります。リリースプロセスの状態に基づいて他のツールやプロセスを集中制御できるリリース管理ツールは、大きな利点となり ます。

リリースの展開の成功には、テストおよびステージング (運用前 )環境の効果的かつ効率的な利用が不可欠です。

展開 /配布ツールチェーンの統合

ツールチェーンの考え方では、タスク固有の補完的なツールセットをエンドツーエンドプ

ロセスの自動化と併用することを推奨しています。リリースと展開のプロセスには、それ

ぞれ異なる API が使用された複数ベンダーの複数のツールが存在します。重複する可能性

もあるため、これを管理する必要があります。組織全体で共通のツールセットを使用する

ことが好ましいものの、ツールの選定を管理できないことが多いため、各種ツールをまと

められる柔軟性を持つことが重要です。

リリースプロセスでは、リリース管理ツールを変更管理システムと統合できるようにする

必要があります。変更要求とビジネス要求をリンクさせることが非常に重要です。変更要

求からアーティファクトの展開までを完全に追跡できるようにしなくてはなりません。変

更プロセスとリリースプロセスが 2 つのプロセス間で状態を遷移できる必要があります。

リリースプロセスの状態に基づいて他のツールやプロセスを集中制御できるリリース管理

ツールは、大きな利点となります。

_______________________________________________________________

前述のとおり、1 つの展開プロセスが数多くの利益をもたらします。問題は、アプリケー

ション展開プロセスで複数の展開ツールや社内で開発されたスクリプトが使用されるのが

多いことです。既存のサードパーティ製品と統合可能な 1 つのプロセスで統合と展開を推進

する能力が必要とされます。このようなツールチェーンの統合は、複雑なアプリケーション

やコンポーネントの自動化プロセスを異なるツールや環境にまたがって一貫性があり繰り

返し可能な方法で集中制御したり自動化することを可能にします。

図 6

サードパーティ製ツールを統合して、展開ツールチェーン全体を自動化

8

ホワイトペーパーリリース管理と展開管理のベストプラクティス

運用前環境の管理

リリースの展開の成功には、テストおよびステージング ( 運用前 ) 環境の効果的かつ効率的

な利用が不可欠です。リリースの速さ、アプリケーションの数、アプリケーションインフ

ラスタックの複雑さの高まりが重なって、これらの環境の管理は急激に複雑化しています。

使用可能なテスト環境がなかったり、環境の競合があると、リリースを遅延させたり、リリー

スの展開コストを増加させる可能性があります。

オフィス生産性ツール (Excel、Word) の使用は、大規模なテスト環境では有効とは言えま

せん。リリースライフサイクルのテスト環境と運用前環境のすべてのスケジュール、管理、

追跡、制御を 1 つのプロセスで処理できるようにする必要があります。自動化およびセルフ

サービスの環境プロビジョニングを導入するとプロセスがさらに合理化され、サイクルタ

イムを短縮できます。

カレンダ形式のビューにテスト環境のスケジュールをまとめて表示でき、誰がどの環境で

何を予定しているかが一目でわかります。このスケジュールビューには、スケジュールさ

れている展開作業、保守の予定、各環境のリリース時間帯も表示される必要があります。

_______________________________________________________________

環境の管理はリリースと展開のライフサイクルの重要な部分です。これにより、適正なチームが適正な環境を適正な時間に使用することが確実になります。

図 7

環境スケジュールカレンダ

9www.microfocus.com

環境のメトリクスに基づくダッシュボードとレポートは、運用前環境の計画、スケジュール、

調整を簡単かつ効率化してリリースライフサイクルをサポートします。環境の状態に変更

が生じた場合や要求した変更が実行された場合は、関係者に自動通知が送信されます。環

境の管理はリリースと展開のライフサイクルの重要な部分です。これにより、適正なチー

ムが適正な環境を適正な時間に使用することが確実になります。

非効率な引き継ぎの廃止

1 つのプロセスから別のプロセス、あるいは同じリリースに関与するあるチームから別の

チームに情報やリリースアーティファクトを移転するにはかなりの量の作業を要し、これ

がリリースフローの大きなボトルネックとなっています。少しでも曖昧さがあればその解

消にチーム間でのやりとりが必要になり、その結果、多大な遅延やコスト、リリースの失敗を

招く可能性があります。

引き継ぎの問題は、会話、電子メール、社内文書、チケット発行システムのどれを介して

も発生します。残念ながら、言葉や図で確実に伝えられる情報はそれほど多くはありません。

書いたり話したりすることでは伝えるのが難しい、言葉で明示できない多くの知識があり

ます。引き継ぎが下流工程に進むにつれて、子どもの頃にやった伝言ゲームのように実際

の知識が抜け落ちていくのです。引き継ぎ情報が次のチームに移るときには、元の意図が

失われてしまいます。

非効率な引き継ぎをなくすことはリリースの成功に不可欠です。前述のバリューストリー

ムマッピングを実行すれば、排除可能な引き継ぎについて有効な洞察を得られるでしょう。

引き継ぎを排除できない場合、その引き継ぎの実際のパッケージとプロセスが形式化され

ているか確認してください。一貫性を確保し、誰もが理解できるセマンティクスのセットを

採用することで、誤った解釈の可能性を減らすことができます。

_______________________________________________________________

非効率な引き継ぎをなくすことはリリースの成功に不可欠です。

図 8

反転展開の自動化

10

ホワイトペーパーリリース管理と展開管理のベストプラクティス

可能な限り的確に知識を文書化します。内部でしか通じない知識は除外し、知識の情報源を

集約し、「ランブック」の概念を使って展開のプロセスとタスクを文書化および標準化しま

す。ランブックは、展開プロシージャや、それぞれの関連アプリケーションの展開タスク

のベストプラクティスを取得する作業を 1 カ所で参照できるようにします。

リリースプロセスの集中制御

自動化された正式なリリース管理プロセスを導入することは、既存の IT スタッフの価値の

最大化に役立ちます。リリース管理は、アプリケーションコード開発からテスト、運用に

至る IT 作業の指針となるアプリケーションライフサイクル管理プロセスです。これにより、

ビジネスが必要とする機能をタイムリーに提供することにリソースを集中させることがで

きます。適切に設計された包括的なリリース管理プロセスにより、以下が可能になります。

プロジェクトのタイムラインと進捗の可視化が向上してより有益な知見を得られるようになるため、予期せぬ事態を防ぎ、すべての関係者が共通認識を持つことができます

リリースフローを増加させて、既存のリソースまたはより少ないリソースで重要な変更をより早く運用環境に展開できます

リリースの品質を向上させることで、展開の成功率を高め、計画および予定外のダウンタイムを縮小します

一貫性の確保と変更追跡管理の適用により、コンプライアンスを簡素化します

まずはリリース管理プロセスのベストプラクティスをカスタマイズしてお客様独自のリリー

スポリシーに適合させることから始めましょう。『ITIL V3 Service Transition book』(ITIL V3

サービス移行ブック ) をお読みになることをお勧めします。手始めとしては、お客様のビジ

ネスをサポートするようにカスタマイズできる合理化された軽量なプロセスが最適です。

_______________________________________________________________

まずはリリース管理プロセスのベストプラクティスをカスタマイズしてお客様独自のリリースポリシーに適合させることから始めましょう。

11www.microfocus.com

統合されたプロセスを通じて開発チームと運用チームが協働できるようにすることで、運

用環境の安定性を損なうことなくビジネスをサポートする変更を迅速に展開するための態

勢を整えることができます。

開発チームと運用チームの双方がアクセスできる１つに統合されたカレンダには、計画さ

れている変更のすべてが週または月単位で表示され、両チームにアプリケーションアップ

デートのスケジュールへの注意を喚起するのに役立ちます。

_______________________________________________________________

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

図 9

ベストプラクティスによるリリースプロセス

12

ホワイトペーパーリリース管理と展開管理のベストプラクティス

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

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

価値をもたらします。情報には、アプリケーションの変更の詳細から展開するアーティファ

クトまで、およびインフラの変更情報も含める必要があります。統合された変更カレンダ

により、展開チーム、リリースマネージャ、運用チームは、ソフトウェアとインフラに計

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

リリース管理チームに必要なのは、アプリケーションリリース手順の計画と追跡のための正

式なプロセスとツール、それらプロセスの適切な可視化、リリースポリシーを確実に適用す

る手段です。このようなツールとプロセスを使用することでのみ、複数のチームが同期を取

りながらビジネス部門の要求に応える作業を進め、リリースしたアプリケーションの品質を

確保し、ミッションクリティカルな運用システムの整合性を保護することができます。

結論とまとめ

ビジネスが新たな経済状況に適応するにつれて、アプリケーションリリースの速さと複雑

さも高まる一方です。手作業での展開、チーム間のコラボレーションの欠如、リリースプ

ロセスの管理の不備のすべてがリリースの質を低下させ、ビジネスに高いコストを課す結

果となっています。より高いパフォーマンスを達成するには、リリース管理にアジャイル

なリーンアプローチを採用する必要があります。

品質とスピードを高める自動化は、高いパフォーマンスを実現する最短の方法です。しか

し自動化は必要ではあるものの十分ではありません。適切な自動化をベースとして、ツー

ルチェーンの最適化と統合、開発チームと運用チーム間の引き継ぎとコミュニケーション

の簡素化、リリースと展開の単一プロセスに基づく標準化を実現することが重要です。

特定のリリーストレインの影響を受けるさまざまなアプリケーションを表示して、変更要求の詳細までドリルダウンできるようになれば、開発チームと運用チームの双方に多大な価値をもたらします。

適切な自動化をベースとして、ツールチェーンの最適化と統合、開発チームと運用チーム間の引き継ぎとコミュニケーションの簡素化、リリースと展開の単一プロセスに基づく標準化を実現することが重要です。

図 10

リリーストレインのタイムラインカレンダビュー

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

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