運用管理
こんな「分離」はエンジニアに不幸を呼ぶ!?
「開発」と「運用・保守」を分離することは、「人月商売（にんげつしょうばい）」「多重下請け構造」と並ぶIT業界特有の問題となっている――そういう主張が現場の開発者からなされることがあります。「そもそも開発、運用、保守は別々のものだろう。何が問題なのだ？」と思われるかもしれませんが、問題はそう単純ではありません。今回はエンジニアの立場からこの問題を概観してみましょう。
運用と保守の区別については前回ご紹介しました。しかし、「運用保守」「保守運用」という言葉もあるように、現場ではセットで語られることも多く、しかも「開発」よりも下に見られる傾向があるようです。そして「開発」と並べて語られる時、「運用・保守」は一括りにされることがあります。
ある開発者は、「運用・保守」を抱き合わせで考えるとエンジニアには次のような弊害が生まれると主張しています。
一般的に言って開発チームと運用・保守チーム、どちらのスキルが高いかと言えば、これは開発チームでしょう。運用・保守チームでは、運用は基本的に手順書どおり、保守はバグ対応など最低限のことだけ、といった定型的な業務が多くなります。大規模な仕事は運用保守費用では賄えないため、開発チームが持っていってしまいます。したがって①のとおり、運用・保守チームのスキルアップはほとんど望めなくなるというわけです。
②に関しては、開発チームが「納品第一主義」になっている場合に問題が顕著に現れます。職場に「納品してしまえば仕事は終了」という力学が働いている場合、多少のバグがあっても納品してしまえば後は他部署に任せればいい、ということになりがちです。しかし昨今では、プロダクトを市場に出すことはスタートに過ぎず、どれだけニーズに合わせた改善をできるかが重要になっています。結果として、開発チームのスタンスは“無責任”ということになります。
③に関しては、「サービスをより良いものにしよう」という力学が失われてしまうという問題があります。開発チームはモノを作るだけ、運用・保守チームはモノが動く状態を維持するだけ。すると、お客様のニーズをすくい取る力が弱くなってしまいます。
昨今のビジネスではシステムが売上や収益と直結するようになりました。このため求められるのは「開発」と「運用」の連携です。それなのに、「運用・保守」を担当するエンジニアは成長できない。これではサービスの成長も望めなくなりそうです。
前出の開発者は、「開発・保守チーム」と「運用チーム」を分けることを提言しています。開発者が保守も考えるようになれば、全体として品質・効率が向上する。運用を「IT基盤及びインフラの運用」と考えれば、手続き型の業務はアウトソーシングや自動化でこなせるようになってきたので、開発と運用の連携のために必要な運用基盤の構築に集中できる。素早いリリースが継続できるように、開発と運用はより近い関係になるべきだ、という主張です。
エンジニアにとっては、これからのキャリアを考える上でも、ビジネスへの貢献の仕方を考える上でも、重要な視点ではないでしょうか。
