Photo by Photo4jenifer
今回のpaiza開発日誌は片山がお送りします。
近年Webビジネスにおける開発業務は、システムが売上や収益と直結しているため、素早い開発が求められるようになり、開発と運用が協力する継続的インテグレーションやDevOpsという概念が重要になってきています。
逆にSIerでは開発と運用・保守の分離がされたままで、特にITエンジニアの成長阻害要因になっていると考えられます。この「開発と運用保守の分離」は、SI業界で働くITエンジニアにとっては、「人月商売」「多重下請け構造」と並ぶ三つ目の問題になっているのではないかと思います。
そこで今回はITエンジニアがキャリアを形成していく上で、開発と運用保守の分離がもたらす弊害について考察してみたいと思います。
■運用・保守とは何か？
SIerではシステム開発の場において、大きくは「開発チーム」と「運用・保守チーム」という仕事に分離してチームを分けることが一般的です。「運用・保守チーム」のほうは「運用」と「保守」という二つの概念が一つにまとめられています。
Webサービスの開発で一般的になってきているDevOpsという概念は、Dev（開発）とOps（運用）が密接に連携しようということです。「保守」については触れられていませんが、開発、運用、保守とはそれぞれ何を指すのでしょうか。
◆運用 = 主にIT基盤、インフラの運用
◆保守 = アプリケーション保守(バグ修正、追加開発)
開発は言わずもがなとして、運用と保守について、人によってさす部分が違う場合もあると思われるので、今回は運用と保守を上記の定義でとらえて考察を進めていきたいと思います。
■「開発」と「運用・保守」分離の弊害
開発と運用・保守分離の何が問題かというと、「運用」と「保守」はまったく性格の異なる仕事であり、「保守」はむしろ「開発」とほぼ同じ内容なのに「開発」と「運用、保守」と分けてしまっていることが大きな問題です。
この「運用・保守」というおかしな抱き合わせによって、そこで働くITエンジニアは次のような弊害が発生します。
- 運用・保守にいると技術力が身につかない
- 開発側が保守性を考えなくなる、無責任になる
- サービスを作るのではなく物を作るだけになってしまう
これらの弊害について順番に見ていきましょう。
◆弊害1.運用・保守側にいると技術力が身につかない
SIerの「運用・保守チーム」に良いイメージを持つ人は少ないでしょう。SIerでは基本的に「開発チーム」が花形で、「運用・保守チーム」はスキルの低い人が回されがち、という意識が多く見受けられます。
そのイメージ通り、SIerの「運用・保守」は、本番環境へのデプロイを手順書に従って行い、問題が起きた場合には、申請書に書かれた手順に従った対応をしたり、上手くいかなかったらアップ前の元の状態に戻し、連絡して仕事終了というような、手順書に従った部分的な仕事が多く見受けられます。
保守の面でも、月の運用保守費用が決まっており、その費用内（業時間内）でバグ対応などの最低限の事を行う、というレベルにとどまることが多くなります。またある程度の規模の追加開発は月の運用保守費用で収まらないため、開発チームが担当することになり、運用保守チームは技術的なスキルアップはあまり望めない、作業的な仕事がほとんどになっていまいます。
◆弊害2.開発側が保守性を考えなくなる、無責任になる
Webサービスであればサービスローンチはスタート地点にすぎず、その後どれだけ市場ニーズにフィットできるようプロダクトを改善できるかが勝負どころになりますが、SIerだと開発チームは「納品したらそこで仕事は終了」です。
「納品したら仕事が終わる」という立場だったら、多少保守性が悪かったり、スパゲッティコードになっていても、納品することが第一義という力学が働くため、コード品質はどうしても悪くならざるを得ません。
悪くいってしまえば「多少バグのあるコードでも納品時に発覚しなければ、あとは知ったことではない」という人が現れてもおかしくないのです。性善説に任せるしかない仕組みとなっています。
◆弊害3.サービスを作るのではなく物を作るだけになってしまう
開発チームはローンチしたら仕事は終了であり、また運用保守チームは何故このシステムが作られたかもよくわからず、月額運用保守費用の中でだけ仕事をしているようになると、サービスをより良い物にしようという力学はまったく働きません。
開発チームは「物」を作ることが目的になり、運用保守チームは「物」が動く状態を保つだけが目的となってしまいます。物を作ることもそれはそれで一つ大きな価値ではありますが、より良いサービスを作れるということのほうが、ただ物を作るより価値が高いのは明らかです。
このように「開発」と「運用保守」の分離した体制では、特に運用保守チームでは技術力の向上は望めず、開発チームもITエンジニアの本質的な価値である「より良いサービスを生み出す能力」を高めることが出来ない構造となっています。
■なぜそうなるのか？
SIerで開発と運用保守の分離が進んだかというと、一つの要因としては2002年のSOX法に端を発する内部統制の強化というのがあげられるでしょう。
開発と運用の権限を1人のエンジニアが持っていると、プログラムを自分の都合のいいように書き換えてしまったり、本番のDBの情報を勝手に書き換えてしまったりといったことが起こりうるため、SOX法をきっかけとして開発と運用の分離がより明確になったと言えます。
しかしSOX法の話のみで考えると、開発と運用が分かれている必要はありますが、保守と運用が一緒である必然性がほとんどありません。
◆費用の取り方による分離
保守と運用が一緒になった経緯としてはSIerの運用保守費用の取り方によるものが大きいと考えられます。
Photo by Joe Goldberg
一般的にSIerでシステムを受注した際には、納品後も運用保守費として開発費の○○%という形で毎月一定の費用をとり、バグの修正や、開発時には予見しきれなかった追加仕様の開発、UIの改善等を運用保守の中で行うというものがあります。
またユーザー企業側からみても、都度見積りだと軽微な修正に対しても毎回見積もりが発生し煩雑ということで、毎月の運用保守費用の中である程度対応してもらったほうが楽、ということで運用と保守がセットになる場合があります。
こういった流れから、運用と保守が月額固定費用の中で賄われるようになり、その費用の取り方の都合上、運用と保守は同じチームで対応するようになってしまうわけです。つまりサービスとしてより良い物を作るための体制として運用と保守は同じチームで対応しているわけではなく、費用の取り方の都合上一緒にしているのです。
SIerはビジネスモデルの特性上、構築したプロダクトが生み出すエンドユーザーへのサービスの質を保証するビジネスではなく、「物を作る」という意味でのシステム開発サービス提供が主たるビジネスとなっているため仕方ないのかもしれません。
SIerは官公庁や銀行、保険など巨大なシステム（物）を作るのに特に最適化されたビジネスモデルです。巨大なシステムを作るニーズは一定数存在しているため、多重下請け構造でどんなに叩かれても必要悪としてSIerが存在しているように、「開発」と「運用保守」分離も必要悪として存在します。
それはそれで社会のニーズ答えた一つの形ではありますが、その形態が働き手にとっても最適とは限りません。多重下請け構造でエンジニアから中間搾取が行なわれているように、「開発」と「運用保守」分離もエンジニアの成長にとっては害悪になり得るため、成長したいエンジニアはあえてそういった構造の中に身を置く必要性はないと言えます。
◆ビジネス都合によるエンジニア成長機会の阻害
ただそれでも開発チームにいれば、要求されたプロダクトを納期までに動くものを作り上げるという力は身に付きますが、運用保守チームにいるだけだと半端な仕事ばかりとなってしまうため成長は少ないでしょう。
もしこれを読んでいる方が運用保守チームにいるのだとしたら、今後も運用保守チームに留まる事のプラス面はほとんどないと言ってしまっても良いのではないかと思います。
仕事は楽かもしれませんが、ドッグイヤーのIT業界において、スキルアップが望めない、ルーチンワークの仕事は、そこにいればいるほど、時間経過とともに市場価値を下げることにしかなりません。
長くエンジニアを続けたいと考えるのであれば、早々に部署移動をするか、マネジメント寄りに移るか、開発ができる仕事に転職したほうが良いと思います。
paizaでも運用保守に長くいた人は転職時に苦労されている例も数多くあるため、開発側に戻りたいのであればのんびりせず、開発スキルが落ちない早いうちに転職・異動をしたほうがいいと思います。paizaではスキルテストで測定したスキルランクを元に応募できる求人が変わるため、掲載求人も開発が中心となり、技術スキルの向上が望める求人が数多く掲載されています。（「自社サービス」というくくりで求人を探すことも可能です。）
■どのようなチーム構成にしていくべきなのか
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転職をご利用いただいている企業の人事担当や、paiza転職を使って転職を成功した方々へのインタビューもございます。こちらもぜひチェックしてみてください。
詳しくはこちら
