第3回 「アプリケーション開発と運用管理の関係は？」
前章ではITIL®というキーワードから、運用管理はビジネスに視点を置いたサービスを管理するものとしてお話を進めてきました。それでは運用管理のスタートポイントはどこにあるのでしょう？ここで少し視点を変えてアプリケーション開発と運用管理の関係について見ていきましょう。
※ITIL（Information Technology Infrastructure Libraryの略）
現場でよく聞く課題とその原因
みなさまは、アプリケーション開発と運用管理をどのように運営されていますか？
一般に運用管理と言うと、アプリケーション開発されてサービスインした直後から運用チームに引き渡されて、日々の運用に入れられているのではないでしょうか？
そこで現場でよく聞く課題を挙げて少し掘り下げて見ていきましょう。
現場でよく聞く課題
- サービスインした直後、初期トラブルが多く運用に耐えない。
- 障害の原因がつかみにくい。
- 修正プログラムを適用すると、別のトラブルが発生する。
- プログラムリリースの基準がなく、なし崩し的に運用チームに押し付けられる。
- サービスイン後、数ヶ月経つとプログラム仕様書と実際に稼動しているプログラムに乖離が生じている。
上記は一例ですが、このようなことがよく起こっていませんか？そのため、開発チームと運用チームの関係が悪化し業務に支障をきたすケースも出てきているのではないでしょうか？
では、なぜこのようなことが起こるのでしょう？原因をうかがうと以下のような回答をよくいただきます。
現場でよく聞く課題の原因
- アプリケーション開発の品質が悪い
→開発の課題 - 十分なテストが実施されていない
→開発の課題 - 日々の運用のための運用管理基準が明確になっていない
→運用から開発に対する課題 - プログラムと仕様書類が関連をもって管理されていない
→開発の課題、サービスイン後は運用の課題 - 運用への受入れ基準が明確になっていない
→運用から開発に対する課題 - 障害発生時にアプリケーションを開発した担当者がいないため問題判別が遅くなる
→運用から開発に対する課題
このように原因を見ていくと、一概に「運用管理プロセス自体ができているから」と言うだけでは解決しそうもありません。運用チームと開発チームとの取り決めだけではなく、これらの原因を根本的に取り除くにはどうしたらよいでしょう？
管理項目の確立
ここで少し、開発フェーズで運用に関係する項目について見てみましょう。
例えば、運用フェーズである障害が発生した場合、事業継続の観点で即時復旧は運用プロセスで対応できますが、恒久的な対応を取り上げた場合は問題管理プロセスに入り原因究明をします。
その後アプリケーション・プログラムの問題と判断された場合、仕様書等を参照することになります。そして開発チームに依頼すると言う手順になり、そこから開発チームはプログラムの修正／テストを繰り返し運用チームへ引き渡してリリース／変更を管理することになります。
このとき、対象となるプログラムのソースプログラムや仕様書が散在していたり、開発者が協力会社のため担当者をアサインしづらかったりと、対応が遅れることが想定されます。
この例の改善点として、ソースプログラム、仕様書やテスト仕様書／テストケースのバージョン管理などが適切にトレーサビリティー（監査証跡）の観点を持って、管理されているでしょうか？
この点は、IT内部統制の観点からも現状の運用管理をより改善するためにも、運用チーム、もしくは開発チームと運用チームが協力して問題管理／変更管理／アプリケーション管理／リリース管理をシームレスなプロセスで管理運営していくことが求められます。
すなわち以下に示す管理項目を確立する必要があります。
管理項目
- アプリケーション・プログラム／仕様書等の管理をする
- ビルド（バージョン・リリース）の管理をする
- テストの管理をする
- リリース（展開）の管理をする
- 問題／変更を運用／開発に渡って管理する
- 各作業の監査証跡を残すように管理する
図3：運用管理のライフサイクル
拡大図
これはアプリケーション開発時に管理すべき項目かもしれませんが、運用フェーズに入ってからも密接に関係してくる項目になりますので、ある程度運用チームが主体性をもって開発環境に関しても運用すべき部分になってきています。
別の観点で見ても開発チームは開発期間終了／サービスインと前後して解散／縮小されますので、アプリケーション資産に関しても他のIT資産とともに管理されるべきものと定義付けられます。
ここまで運用管理とともに管理できるようになりますとアプリケーションのライフサイクルとして左の図にあるように運用管理のライフサイクルが実現できます。
このように、アプリケーション開発におけるアウトプットと監査証跡の管理は、後々の運用管理を楽に効率的に管理運営することに大きく寄与するということが、ご理解いただけるかと思います。
現状を考えると開発チームと運用チームの関係で組織も異なりなかなか実現するのが難しいと考えられます。しかしながら高所に立った考え方に改善されない限り企業がビジネスに柔軟に対応する、すなわちIT部門が柔軟に対応できる環境に移行できないことも事実であることをご理解ください。
図4：ソフトウェア構成管理スターター・
パッケージ導入サービス
拡大図
前章でも述べましたがその際はやはり第三者の目で自分のIT部門の成熟度などを分析してもらい、まず着手すべき効果の高い管理項目を選定することが重要になります。また実装するときは常にIT部門メンバーの意識統一を図るための合意形成も重要です。
IBMでは、このアプリケーション開発と運用管理に関してプロセスを見直したいお客様向けには前章にあるサービスをご提供しております。アプリケーション管理をツール実装により改善したいというお客様向けには「ソフトウェア構成管理スターター・パッケージ 導入サービス」をご提供しておりますので、是非お役立てください。
次回は「4.運用管理を効率化する方法は？」と言うテーマでTCO（Total Cost of Ownership）について見ていきたいと思います。
IBM, IBMロゴ, ibm.com,は、世界の多くの国で登録されたInternational Business Machines Corporationの商標です。
TILは英国Office of Government Commerceの登録商標および共同体登録商標であって、米国特許商標庁にて登録されています。
他の製品名およびサービス名等は、それぞれIBMまたは各社の商標である場合があります。
現時点でのIBMの商標リストについては、www.ibm.com/legal/copytrade.shtml（US）をご覧ください。
