保守案件って実際どうなの？現役ベテランSEが説明します

IT業界において数多くの案件がありますが、ざっくり大きく分けると以下２つの案件があります。

新規開発案件とはその名の通り、新しいシステム、サービスをゼロの状態から構築する案件になります。

保守案件は既にリリースは完了していて、実際にユーザーが使用可能な状態になっているシステムやサービスをメンテナンスする案件になります。

この記事の内容は、保守案件についてです。

僕の印象では、数ある案件の中で新規開発案件は少数で、多くは保守案件なのではないかと考えています。実際、僕が携わってきた案件もほとんどは保守案件です。

実際、保守案件はどうなのか？のリアルなお話したいと思います。

忙しさにはバラつきがある

忙しいのか忙しくないのかですが、これは案件によってかなりバラつきがあります。

安定稼働していて、余裕を持ったスケジュールで新機能の追加やメンテナンスを行っている場合は、残業もほぼなく落ち着いて仕事ができます。

逆に障害が多発していたり、かなりタイトなスケジュールでメンテナンスを行っているような案件もあります。このような案件は例外なく炎上しており、かなり忙しいです。チームの雰囲気が良くないことがほとんどです。

僕の経験では、自社のサービスで、障害が少なくシステムの稼働が安定している場合は、余裕を持って仕事ができるケースが多いです。ほぼ定時上がりが可能です。

どんなに落ち着いた案件でも、障害が発生した場合は忙しくなります。

障害の程度にもよりますが、ユーザーへの影響があって早急に修正して本番反映しなければならないものになると、急ぎでの対応になるので忙しくなります。

平和だった職場が途端に戦場と化すような場合もあります。

最悪、徹夜での対応を迫られるケースもあります。

たまに金融機関でのATM障害や航空会社での搭乗手続き関連のシステム障害が発生してニュースになることがあります。あのような数万人単位の人への影響がある障害が発生した場合、その対応に追われるエンジニアは大変な思いをしているはずです。敬意を持って応援したいところです。

障害をゼロにするのは困難なので、このような事態になる可能性があることは覚悟しておくことをおすすめします。

保守案件は既に完成しているシステムに対してメンテナンスを行う仕事なので、そこまでハイレベルなスキルは求められないイメージがあります。

しかし、これは完全な誤解です。私も最初は少し考えが甘かったです。やっている仕事は結構高い能力を求められます。

一番ハードルが高いと感じるのは、システム全体の仕様を把握しなければならないことです。

新規開発の場合は、自分が担当する領域とその周辺の仕様だけ把握しておけば、乗り切れてしまうことがあります。

しかし、保守案件の場合はそういうわけにはいきません。どこで障害が発生するか分からないからです。

全体の仕様を把握していないと、障害が発生した場合に、原因がどこにあるのか、どのように修正するのか、そこを修正することによってどこに影響があるのかの調査に時間がかかってしまいます。迅速対応が求められる障害対応においてこれは致命的です。

全体の仕様把握はシステム規模が大きくなるほど大変な作業になります。障害が発生してすぐに「あの辺りが原因だな」と当たりをつけられるようになるのが理想ですが、そのレベルに達するまでには、かなりハイレベルの仕様理解能力が求められます。

実は求められる能力は高いのです。

上記で、保守案件では仕様全体を把握する必要があると書きました。

仕様を把握するために、ドキュメントやソースコードを読み込むことになります。

この時、他の人が書いたコードを読むことになるのですが、これが結構勉強になります。自分が使用経験がある言語においても「こんなやり方があるのか」と新たな発見があることは珍しくないです。

参考書には載っていない応用的、且つ現場で使える技術をそこから学ぶことができます。

逆に、真似してはいけない反面教師にすべきコードもありますが。それはそれで勉強になります。

新規開発案件の場合は、結構スケジュールに追われて大変なのですが、その代わり手を動かす機会が多いのでスキルは早く身に付けられる可能性は高いです。

保守案件は障害が多発しているような不安定な案件だと大変ですが、そうでなければ残業もなく落ち着いて仕事ができる可能性が高まります。

新規開発、保守案件どちらにも言えますが、どんな案件かの見極めは本当に大事です。

どちらを選ぶかは人それぞれですが、もしも残業が少なく、落ち着いた環境で仕事をしたいというのが優先順位として高いのであれば、保守案件に参画するというのを選択肢の１つとして検討することをおすすめします。