アプリケーション開発者には、プロジェクトが終わっても次のプロジェクトが待っています。最後は誰もができるだけ早く検収や引き継ぎを終えてすっきりした気持ちで次の仕事に取り組みたいと考えます。

一方、プロジェクトの成果物を引き継ぐ運用の担当者は、アプリケーションやマニュアルが十分な品質を維持し、余裕を持って引き継がれることを期待しています。

開発プロジェクトから引き続き運用業務に参加される方は、期待と不安が入り混じった複雑な心境でサービス・リリースの当日を迎えます。

利害が対立する開発と運用の両組織にはそれぞれの立場がありますが、投資をする顧客にとってサービスプロバイダの事情は関係ありません。顧客は約束したサービスが、合意通りに供給されることをサービスプロバイダに要求します。

このような状況の下でサービスプロバイダは、顧客の期待するサービスを効率的に供給するために、開発と運用の連携を高める必要に迫られています。

ITIL がＩＴサービスマネジメントのベストプラクティスを提唱してから２０年が経ち、時代と共にその内容も広がりを持つようになってきました。最新版であるバージョン３では、サービスはライフサイクルの観点から管理されるべきであるという主張がなされています。

運用で発生している不具合の多くは、運用時の活動で生み出されるのではなく、それ以前になされている開発や構築、そしてリリースの結果から生み出されています。運用で得られた情報を設計や開発に反映させることができれば、サービスはより事業側のニーズに沿ったものに変えていくことができるという主張です。

ITIL にとって、アプリケーションはサービスを提供するための１つの構成要素です。それぞれのアプリケーションが、ビジネスに影響を与えた障害の頻度や程度を、数値によって管理します。

サービス供給時の不具合や障害の発生傾向を分析した結果、特定のアプリケーションに起因するエラーが他と比較して多いとなれば、開発組織がビジネス上不利な立場に追い込まれるかも知れません。

今まで運用に携わったことのないアプリケーション開発者もまた、サービス品質という観点から自分自身が関わっているプロセスや成果物を継続的に評価し改善する時代が来るのではないか、あるいは既に来ているのではないでしょうか。

永続出来る種は｢変化に適応する種｣であり｢大きい種｣｢強い種｣ではない。

ダーウィン「進化論」

「開発者のためのITIL」は、今回を持って最終稿とさせていただきます。１年と少々ではありましたが、興味を持ってアクセスいただき誠にありがとうございました。読者の皆様が「変化に適用する開発者」として、末長くご活躍されることを願って止みません。