システムの運用保守の難しさ :運用保守作業と並行で動く大規模案件のコント ロール

過去の記事に書きましたが
【あわせて読みたい】
システムの運用保守の難しさ:初めに
システムは導入だけではなく、運用保守も非常に大事な仕事です。

導入チームと保守チームという形で
IT部門内の役割を分けている会社でありがちというか見落としがちなんですが
運用保守に入っても、大規模案件は動きます。
(当たり前ですが)

これは運用保守をやっていく中での難しさの最たるものとも言えます。
運用保守として細々した案件対応を行いながら
息の長い大規模プロジェクトが動き出すとどういう事が起こるかというと、

①大規模案件で変更をかけようとするオブジェクトと、運用保守で触らないといけないオブジェクトが重複する。
(※ここで言っているオブジェクトというのはプログラム等の事を言います。)

これは代表的な現象で、大規模プロジェクトでも、運用保守でも同じシステムを触っている以上、同じオブジェクトを触るというタイミングが必ず発生します。
問題は大規模プロジェクトはそのオブジェクトを拘束する時間が長いことが多いという事です。
例えば大規模プロジェクトで、ある機能Aに修正を入れることになったとします。
修正を入れることが決まったのは4月ですが、修正にはかなり時間がかかる為、完了するのは6月という事がわかっています。
しかし、一方同じ機能Aに対し、運用保守の方で5月に不具合が発見されたので、すぐに修正を入れないといけなくなりました。
しかし、上に書いた通り、機能Aには4月から大規模プロジェクトの方で修正が入っているので、すぐには手を入れることはできません。
こうなった場合、どうするか?という事を運用保守チームは常に考えさせられることになります。

やり方の一つとして、大規模プロジェクトで入れていた修正を一旦なかったことにして(修正前の状態に戻す)、その上で不具合の修正を入れる。そして、不具合の修正が終わった後に、再度大規模プロジェクトの修正を入れるというやり方もありますが、これもそう簡単ではありません。
不具合修正前に入れていた大規模プロジェクトの修正は、不具合修正を入れた後では違ったやり方をしなくてはいけないかもしれないからです。そしてそれは往々にして起こります。
こうなると当初、不具合が発覚する前に見積もっていた工数を大幅に超過して、予算を圧迫したりしますし、この対応により、また違った不具合を招いたりすることさえあります。

②大規模案件用に新しい環境が出来上がり、ダブルメンテナンスをしなくてはいけなくなる。
これもあるあるですね。
目的は様々ですが、大規模案件用に運用保守をしている環境を丸ごとコピーして別の環境を用意する場合、同じオブジェクトが複数の環境に存在することになる為、どちらかで修正した内容を、別の環境に存在する同じオブジェクトにも反映して整合性を維持したり、はたまた意図的に反映させなかったりします。

いずれにせよ、同じオブジェクトにも拘わらず、それぞれの環境においてどういう状況になっているかをきちんと管理しなくてはいけませんし、本来どれが正しい状態なのか?意図的にずらしている理由は何なのか?も合わせて管理し続けなくてはいけません。
これは非常に面倒な上、精緻な管理が必要になるので、容易に運用保守の工数を膨らませる要因になります。
そもそも運用保守の事だけ考えたらやらなくてもいい事をやっているので、完全に余分な作業です。
つまり運用保守のチームは運用保守の事だけやっているわけではないという事でもあります。

③大規模案件により、新しい機能が追加され、その機能が既存環境に及ぼす影響を調査し、害のないように改修する。
これは、保守の知見のないメンバーが導入を行う場合に起こります。
導入チームは今動いているシステムに対しての知見が深くないことが多いです。
その為、新しい機能を実装するとなった場合、それが既存のシステムにどういった影響を及ぼすか?その調査は運用保守チームにお任せとなることが多いです。
そうなると、運用保守チームからすると、その調査という予期せぬ仕事が舞い込んでくることになります。
しかも、調査する内容は自分たちが作っていない機能についてなので、修正内容だけでなく、その目的まで抑える必要があります。

このいずれのケースが発生するにせよ、運用保守チームにとって大変なのは
今現在動いているシステムに対し悪影響を及ぼさないように、新機能を追加できるように完璧にコントロールしなければならないという事です。

ここまで書いた内容でわかるように、
これらの作業は非常に繊細で判断力を求められる作業になるので
かなり堅実にしかも精密に管理作業を行える人でないとデグレと呼ばれる現象を頻発させてしまったり、酷い時にはどれが最新のオブジェクトかわからなくなってしまったり、どうしてこの機能が実装されたのか、その理由もタイミングも不明
というような事態を引き起こす為、責任も重大です。

このように導入プロジェクトにおける難しさとは全く違う種類の、しかし非常に難易度の高い仕事を求められるので、導入プロジェクトしかしたことないという人には相当ハードルの高い仕事になります。

社内SEとして一人前になる為にはプロジェクトの導入だけでなく
運用保守の経験は必須となりますし、運用の期間の方がはるかに長い事を考えれば
その影響も大きいという事を踏まえておいた方がいいでしょう。

コメント

このブログの人気の投稿

Stories 5話:今までの経緯を知らないまま、運用設計をする

社内のコミュニケーションを活性化!グループウェア導入のススメ

ITにどう向き合う?どう向き合ってもらう?