paiza開発日誌

IT/Webエンジニア向け総合求人・学習サービス「paiza」(https://paiza.jp ギノ株式会社)の開発者が開発の事、プログラミングネタ、ITエンジニアの転職などについて書いています。

SIerの「開発」と「運用保守」分離がまねく3つの弊害

f:id:paiza:20161213121157j:plain
Photo by Photo4jenifer

f:id:paiza:20130918201254g:plain今回のpaiza開発日誌は片山がお送りします。

近年Webビジネスにおける開発業務は、システムが売上や収益と直結しているため、素早い開発が求められるようになり、開発と運用が協力する継続的インテグレーションやDevOpsという概念が重要になってきています。

逆にSIerでは開発と運用・保守の分離がされたままで、特にITエンジニアの成長阻害要因になっていると考えられます。この「開発と運用保守の分離」は、SI業界で働くITエンジニアにとっては、「人月商売」「多重下請け構造」と並ぶ三つ目の問題になっているのではないかと思います。

そこで今回はITエンジニアがキャリアを形成していく上で、開発と運用保守の分離がもたらす弊害について考察してみたいと思います。


■運用・保守とは何か?

SIerではシステム開発の場におい、大きくは「開発チーム」と「運用・保守チーム」という仕事に分離してチームを分ける事が一般的です。「運用・保守チーム」のほうは「運用」と「保守」という二つの概念が一つにまとめられています。

Webサービスの開発で一般的になってきているDevOpsという概念では、Dev(開発)とOps(運用)が密接に連携しようという事であり、「保守」については触れられていませんが、開発、運用、保守とはそれぞれ何を指すのでしょうか。

◆運用 = 主にIT基盤、インフラの運用
◆保守 = アプリケーション保守(バグ修正、追加開発)

開発は言わずもがなとして、運用と保守について、人によってさす部分が違う事もあると思われるので、今回は運用と保守を上記の定義でとらえて考察を進めていきたいと思います。

■「開発」と「運用・保守」分離の弊害

開発と運用・保守分離の何が問題かというと、「運用」と「保守」は全く性格の異なる仕事であり、「保守」はむしろ「開発」とほぼ同じ内容なのに「開発」と「運用、保守」と分けてしまっている事が大きな問題です。

この「運用・保守」というおかしな抱き合わせによって、そこで働くITエンジニアは次のような弊害が発生します。

  1. 運用・保守にいると技術力が身につかない
  2. 開発側が保守性を考えなくなる、無責任になる
  3. サービスを作るのではなく物を作るだけになってしまう

これらの弊害について順番に見ていきましょう。

◆弊害1.運用・保守側にいると技術力が身につかない

SIerの「運用・保守チーム」に良いイメージを持つ人は少ないでしょう。SIerでは基本的に「開発チーム」が花形で、「運用・保守チーム」はスキルの低い人が回されがち、という事が多く見受けられます。

そのイメージ通り、SIerの「運用・保守」は、本番環境へのデプロイを手順書に従って行い、問題が起きた場合には、申請書に書かれた手順に従った対応をしたり、上手くいかなかったらアップ前の元の状態に戻し、連絡して仕事終了というような、手順書に従った部分的な仕事が多く見受けられます。

保守の面でも、月の運用保守費用決まっており、その費用内(業時間内)でバグ対応などの最低限の事を行う、というレベルにとどまる事が多くなります。またある程度の規模の追加開発は月の運用保守費用で収まらないため、開発チームが担当する事になり、運用保守チームは技術的なスキルアップはほとんど望めない、作業的な仕事が殆どになっていまいます。

◆弊害2.開発側が保守性を考えなくなる、無責任になる

Webサービスであればサービスローンチはスタート地点にすぎず、その後どれだけ市場ニーズにフィットできるようプロダクトを改善できるかが勝負どころになりますが、SIerだと開発チームは「納品したらそこで仕事は終了」です。

「納品したら仕事が終わる」という立場だったら、多少保守性が悪かったり、スパゲッティコードになっていも、納品する事が第一義に来るという力学が働くため、コード品質はどうしても悪くならざるを得ません

悪くいってしまえば「多少バグの有るコードでも納品時に発覚しなければ、あとは知った事は無い」という人が現れてもおかしくないのです。性善説に任せるしかない仕組みとなっています。

◆弊害3.サービスを作るのではなく物を作るだけになってしまう

開発チームはローンチしたら仕事は終了であり、また運用保守チームは何故このシステムが作られたかもよくわからず、月額運用保守費用の中でだけ仕事をしているようになると、サービスをより良い物にしようという力学は全く働きません

開発チームは「物」を作る事が目的になり、運用保守チームは「物」が動く状態を保つだけが目的となってしまいます。物を作る事もそれはそれで一つ大きな価値ではありますが、より良いサービスを作れるという事のほうが、ただ物を作るより価値が高いのは明らかです。


このように「開発」と「運用保守」の分離した体制では、特に運用保守チームでは技術力の向上は望めず、開発チームもITエンジニアの本質的な価値である「より良いサービスを生み出す能力」を高める事が出来ない構造となっています。


■なぜそうなるのか?

SIerで開発と運用保守の分離が進んだかというと、一つの要因としては2002年のSOX法に端を発する内部統制の強化というのがあげられるでしょう。

開発と運用の権限を1人のエンジニアが持っていると、プログラムを自分の都合の用意用に書き換えてしまったり、本番のDBの情報を勝手に書き換えてしまったりといったことが起きえるため、SOX法をきっかけとして開発と運用の分離がより明確になったと言えます。

しかしSOX法の話のみで考えると、開発と運用が分かれている必要は有りますが、保守と運用が一緒である必然性が殆どありません

◆費用の取り方による分離

保守と運用が一緒になった経緯としてはSIerの運用保守費用の取り方によるものが大きいと考えられます。

f:id:paiza:20161213121344j:plain
Photo by Joe Goldberg

一般的にSIerでシステムを受注した際には、納品後も運用保守費として開発費の○○%という形で毎月一定の費用をとり、バグの修正や、開発時には予見しきれなかった追加仕様の開発、UIの改善等を運用保守の中で行うというものがあります。

またユーザー企業側からみても、都度見積りだと軽微な修正に対しても毎回見積もりが発生し煩雑という事で、毎月の運用保守費用の中である程度対応してもらった方が楽、という事で運用と保守がセットになる事があります。

こういった流れから、運用と保守が月額固定費用の中で賄われるようになり、その費用の取り方の都合上、運用と保守は同じチームで対応するようになってしまう訳です。つまりサービスとしてより良い物を作るための体制として運用と保守は同じチームで対応しているわけではなく、費用の取り方の都合上一緒にしている訳です。

SIerはビジネスモデルの特性上、構築したプロダクトが生み出すエンドユーザーへのサービスの質を保証するビジネスではなく、「物を作る」という意味でのシステム開発サービス提供が主たるビジネスとなっているため仕方ないのかもしれません。

SIerは官公庁や銀行、保険など巨大なシステム(物)を作るのに特に最適化されたビジネスモデルです。巨大なシステムを作るニーズは一定数存在しているため、多重下請け構造でどんなに叩かれても必要悪としてSIerが存在している様に、「開発」と「運用保守」分離も必要悪として存在します

それはそれで社会のニーズ答えた一つの形では有りますが、その形態が働き手にとっても最適とは限りません。多重下請け構造でエンジニアから中間搾取が行なわれているように、「開発」と「運用保守」分離もエンジニアの成長にとっては害悪になり得るため、成長したいエンジニアはあえてそういった構造の中に身を置く必要性はないと言えます。

◆ビジネス都合によるエンジニア成長機会の阻害

ただそれでも開発チームに居れば、要求されたプロダクトを納期までに動くものを作り上げるという力は身に付きますが、運用保守チームにいるだけだと半端な仕事ばかりとなってしまうため成長は少ないでしょう。

もしこれを読んでいる方が運用保守チームにいるのだとしたら、今後も運用保守チームに留まる事のプラス面はほとんどないと言ってしまっても良いのではないかと思います。

仕事は楽かもしれませんが、ドッグイヤーのIT業界において、スキルアップが望めない、ルーチンワークの仕事は、そこに居ればいるほど年を取るだけで、市場価値を下げる事にしかなりません

長くエンジニアを続けたいと考えるのであれば、早々に部署移動をするか、マネジメントよりに移るか、開発を出来る仕事に転職したほうが良いと思います。

paizaでも運用保守に長くいた人は転職時に苦労されている例も数多くあるため、開発側に戻りたいのであればのんびりせず、開発スキル落ちない早いうちに転職・異動をした方が良いと思います。paizaではスキルテストで測定したスキルランクを元に応募できる求人が変わるため、掲載求人も開発が中心となり、技術スキルの向上が望める求人が数多く掲載されています。(「自社サービス」というくくりで求人を探すことも可能です。)

■どのようなチーム構成にしていくべきなのか

f:id:paiza:20161213121452j:plain
Photo by Jim Bauer

より良いサービスを作り、またエンジニアの成長につながるチーム構成は、それぞれの役割を考えてていくと「開発チーム」と「運用・保守チーム」ではなく「開発・保守チーム(開発チーム)」と「運用チーム(インフラチーム)」と分けたほうが自然でしょう。

◆開発と保守

「保守」はアプリケーション保守(バグ修正、追加開発)の事を指しますが、従来はビジネスの変化のスピードが緩やかだったという事も有り、システム納品後はそれほどアプリケーションの保守、追加開発をする必要も有りませんでした。そのため開発時ほど人員を割り当てる必要もなかったため開発チームとは分けて、スキルの低いエンジニアがOJT的に仕事を覚える場として利用されていた面が有ります。

しかし現在ではビジネスの変化のスピードは早くなり、システム面での差別化が競合優位性につながる事も多々有り、常にプロダクトを市場のニーズの変化にフィットさせるための継続的で永続的な開発が必須になってきています。「ローンチしたら後何かやる事有るんだっけ?」というのは過去の話です。店舗構えたら勝手に人がやってくる訳ではないのと同様に、商売・サービスとしてシステムを利用する場合は常に競合より優れたものを提供し続ける必要があり、その為の追加開発発生し続けなければならないのです

大きな追加開発であれば開発と大きな違いはなく、また小改修やバグ修正についても開発者が行った方が効率も良く、作業内容や開発者の視点から考えると開発と分ける必然性がほとんどあまりありません。むしろ開発と保守を一体化し、開発者が自分でバグ修正をやらなければいけない環境にした方が、無責任なコードをコミットする事もなくなるため、全体としての品質、効率も上がるはずなのです。

◆運用の役割の変化

運用を「IT基盤、インフラの運用」というように分けて考えた場合、現在ではAWSなどのIaaSや、HerokuなどのPaaS等が使える現場であれば、「運用」は基本的にアウトソースされる領域がとても大きくなる事が解ります

また最近ではDevOpsの流れもあり、ビルドやテストを自動化/半自動化するJenkins、Travis CI、Circle CI といったCIツールや、環境構築を自動化する、Chef や Puppet、Ansible 等のサーバプロビジョニングツールなどが登場し、これまで運用チームが人手で行っていた手続き型の作業の多くが自動化され始めています。

これらの結果として運用チームは、従来のような「申請書の手順に従った機械的な作業を人手が行う」という役割から「CIツールやプロビジョニングツール導入など、継続的インテグレーション実現為の運用基盤構築、保守」という役割へと変わりつつあります。

そのため、従来のような守りの運用チームではなく、開発出身者がローテーションで担当し、より開発と運用が近い関係になり、対立せずに素早いリリースが出来るような体制を作る必要が有るでしょう。


■まとめ

ここまで見てきたように、開発と運用保守の分離は、より良いサービスを生み出すための仕組みではなく、SIビジネスの都合上出てきた「必要悪」としての仕組みと言えます。そのためITエンジニアの成長およびキャリアにとってはマイナス面が多分にあります。

Webサービス、自社サービスを行っている企業では、DevOpsの流れもあり、開発と保守を統合し、運用だけチームを分けたり、規模によっては開発チームの中で運用を行う事も数多くあります。こちらの体制の方が、より良いサービスを生み出す体制としては優れており、ITエンジニアとしても本質的な価値を高めるためにも良い環境だと言えるでしょう。

プロダクトの質を検証する事すらできず、学びのプロセスを捨ててしまっている、作りっぱなしの体制では、より良いプロダクトを作る事がかなわないのは、火を見るよりも明らかなのです




paizaは、技術を追い続けることが仕事につながり、スキルのある人がきちんと評価される場を作ることで、日本のITエンジニアの地位向上を目指したいと考えています。

「paiza転職」は、自分のプログラミング力が他社で通用するか(こっそり)腕試しができる、IT/Webエンジニアのための転職サービスです。プログラミングスキルチェック(コーディングのテスト)を受けて、スコアが一定基準を超えれば、書類選考なしで複数の会社へ応募ができます。
paiza.jp
まずはスキルチェックだけ、という使い方もできます。すぐには転職を考えていない方でも、自分のプログラミングスキルを客観的に知ることができますので、興味がある方はぜひ一度ご覧ください。
paiza.jp

ITプログラマ・エンジニア向け転職・就活・学習サービスのpaiza