一時期から比べればだいぶ暖かくなってはきたものの、暖かくなったり寒くなったりの繰り返しで、体調を崩しやすい今日このごろですが、みなさんはどのようにお過ごしでしょうか？特に今年のインフルエンザはバージョンアップされ、だいぶたちが悪いようですので、期末・年度末を迎えられ作業の追い込みに入られている方は、体調には十分お気をつけください。

さて、運用ゲンジンの掲載も九回目を迎えましたが、運用方針に始まり、運用の現状把握や分析、問題点の発見から改善課題の策定、そして所々昨今のオープン系を意識しながらの運用設計と、運用の全般について話を進めてきました。今回は話としてはあたりまえで根付けば簡単なことではあるのですが、｢業務リリース｣について話を進めてみます。

 

どんなに良いシステムを開発・構築したとしても、運用に入ってくる過程によってそのシステムの良し悪しが決まると言っても過言ではありません。運用設計が行われているか、どの時点で運用設計、あるいは運用引継ぎがなされ、さらにリリースに対する手続き／手順がきちんと行われるかによって、開発・保守してきた作業の成果や結果が評価されます。　こういったことはシステムを開発される方からすれば煩わしいことではありますが、それを計画がきついからという理由で少しでも手抜きをすれば、その結果として必ずどこかにしわ寄せが行き、大きな影響として現れてくるものです。特に、短期間で構築しなければならない最近のオープン系システムは、そのような面が多々見受けられます。こういったシステム開発においては、開発・運用・管理が必要である以上、メインフレーム、オープン系に関わらず、運用設計や業務リリースの手続き／手順、運用引継ぎについては同じです。　オープン系になってからの違いは、運用部門の運用設計に対する入り込み方です。メインフレームに対しては運用部門が中心になってできたものが、オープン系ではインフラ役割が中心となって行うケースが多く、運用の声が反映されないまま構築が進むという大きな違いがあります。最新の技術を導入していながら、運用作業は昔に戻っている感さえあります。このような運用部門の役割の変化が今後の運用部門を大きく左右するものと思われます。その現れとしては、運用部門の縮小化、インフラ・ヘルプデスクの増強化、インフラ役割の運用部門への取り込みなど、従来の運用のイメージとはだいぶ様変わりし始めてきています。　役割や組織としては、大きくは従来の開発・運用から、開発・インフラ・運用と明確に変化してきています。このインフラの人材がかなり不足しており、しばらくはインフラスキルを持った人材の売り手市場が続くものと思われます。

 

さて、本題の上流の運用設計から業務のリリースについてですが、どうしても運用設計の抜けがあったり、余裕を持つことができずに緊急リリースという形になり、結果的に初期トラブルやつまらないミスが生じて運用でカバーするということがままあります。さらには運用での作業ミスの誘発などを繰り返すこともあります。運用設計がされていない、あるいはきちんとしたリリースの手続き・手順が踏まれていない、さらにはそういったルールなどが明確でないとか、これから整備しなければならないというユーザ企業がまだまだ多数あるということを見聞きします。以前にも増して運用の現状の厳しさを痛感させられます。そんな中で「あるべき論」になってしまうかも知れませんが、開発から業務のリリースまでの流れについて記載しておきます。簡単ではありますが、この中では全体の流れや運用の加わり方を示しています。使用するドキュメントや成果物などがセットになって初めてこの流れが生きてきます。