運用管理
費用の都合で運用・保守が抱き合わせになる？
前回は「アプリケーション『開発』と『運用』『保守』を分離すること」と題し、「運用・保守」を抱き合わせで考えた場合の弊害を紹介しました。
前回ご紹介した開発者の主張では、「開発・保守チーム」と「運用チーム」を分けることを提言していましたね。しかし、そもそもなぜこのような問題が生まれたのでしょうか。
前出の開発者によれば、開発と保守運用の分離が進んだ要因の一つは、内部統制の強化でした。2002年にSOX法という企業改革のための法規がアメリカで成立しましたが、これをきっかけに開発と運用の分離がより明確になったというのです。1人のエンジニアが開発と運用の権限を握っていると、プログラムを自分の都合で書き換えたり、データベースの情報をいじってしまうといったことが起こり得るから、というのがその理由です。ただしこの文脈では、開発と運用を分ける必要があるのはわかりますが、保守と運用を一緒にする必然性が明確ではありません。これはおそらく運用保守費用の取り方によるものが大きいのだろう、と前出の開発者は述べています。
アプリケーション開発を受注した側は、納品後に開発費の何％かを運用保守費として毎月の収入とする。その運用保守費の中でバグの修正やユーザーインターフェイスの改善などを行っていくわけです。一方、ユーザー企業から見ると、軽微な修正で毎回見積もりが必要になるのは煩雑です。それならば、毎月の運用保守費の中で対応できる部分は対応してもらった方が楽だ、ということになります。すると費用の取り方の都合上、運用と保守はセットで扱われるようになり、運用と保守を同じチームで賄うようになってしまうのです。サービスとして、より良いモノを作るために運用と保守が同じチームで対応しているわけではありません。
もちろん、巨大なシステムを作る場合は「モノを作る」システム開発が主たるビジネスになるので、「開発」と「運用保守」を分離することは必要悪かもしれません。しかし、企業にとって最適な形態だからと言って、働き手にとっても最適だとは限りません。開発チームならまだしも、運用保守チームにいては成長が望めないことは前回も述べたとおりです。成長が望めない職場にいることは、ドッグイヤーで物事が進むIT業界においては市場価値の低下を意味します。年を取るほど不利になりますから、エンジニアの中には転社・転職を考える人も出てくるでしょう。エンジニア個人も、企業の側も、対策をなおざりにしていてはビジネスの将来を危うくするかもしれません。
