こんにちは。てとです。
みなさん、IT業界にはどんなイメージを持っていますか？
エンジニアと聞くと、どんな仕事をしているイメージがありますか？
IT業界とは言っても、本当に色々な事業、職種があります。
同様に、エンジニアの仕事も色々あり、お客さんと打ち合わせばっかりやっている人もいれば、パソコンに向かってひたすらコードを書いている人もいます。
そんな広いIT業界について、四季報や業界紙などで企業研究を始めて見たものの、いまいち仕事のイメージがつかめない・・・という人も多いんじゃないでしょうか。
そこで、今回は現役エンジニアであり、転職して複数のIT企業を見てきた私の視点で細かく解説していきます！
一般的に言われている定義と少し違う部分もあるかもしれませんが、まずはイメージができるようわかりやすさ優先で書いていますことをご了承ください。
今回は、「保守」について解説します！
目次
運用と保守について
就活のために業界研究をしていると、「要件定義・設計・開発・試験」と、「運用・保守」のように大きく二分化されており、運用と保守がひとつにまとめて書かれていることが多いかと思います。
なぜこのようにまとめられるのかと言えば、一言で言えば、後者はシステムを作り終わった後にしか発生しない工程だからです。
しかし、保守と運用では、目的は全然違うのですが、実態としてはごっちゃになってしまっていたりして、かなりややこしかったりします。
これについては実際に仕事をしてみないとわかりにくいのですが、実際に両方の仕事をした私の経験から、それぞれ説明します。
「保守」とは
保守とは、一言で言えば、「完成したシステムを、より使いやすくするために改善したり、使いにくい部分を改善したりする」ことと言えます。
まずシステム開発会社の視点から見て、大雑把にですが「保守」の概要を説明します。
システム開発会社は、お客さんが欲しいと思うシステムを作ります。
作り終わったら、お客さんにそのシステムを「納品」します。
ただ、作って納品して終わりかと言うと、必ずしもそうとは限りません。
システムの内部的なことはお客様よりも、作ったシステム開発会社のほうが詳しいです。
納品した後も、お客さんから「ここ使いにくいから、もうちょっと使いやすくして」とか、「こういう風にしたいときはどう操作すればいいの？」といった問い合わせが来たりします。
このような問い合わせ対応そのものも「保守」ですし、システムをより使いやすく改善することも「保守」です。
そして、この保守は、システム開発会社とお客様の間で「保守契約」というものを結んだ上で、やる作業です。
保守契約は、だいたい月額いくらの有料サポートみたいなものです。
つまり、お客様が「作って納品してくれたらそれでいい、そのあとのことは何もしなくていいから保守契約料を払いたくない」というのであれば、上記のような保守はしなくていいのです。
「保守」についてもうちょっとわかりやすく
・・・と色々書きましたが、具体例も書いた方がわかりやすいかと思うので、「勤怠管理システム」を例に、保守作業の具体例を2つほど説明します。
「勤怠管理システム」とは、誰が何時に出社したか、何時に退社したか、またいつ休んだかを管理できる、タイムカードみたいなシステムのことだと思ってください。
下記の通りのシステム要件と運用ルールを前提に、とある会社で勤怠管理システムを作ってみたとします。
【システム要件】
１）勤怠管理システムは、「出社ボタン」「退社ボタン」のふたつのボタンで構成されている。
２）社員は、朝、出社したときに、会社に設置されたパソコン上で「勤怠管理システム」を起動する。起動した後に、「出社ボタン」を押すことで、押した時間が出社時間として記録される。
３）社員は、夕方、退社する前に、会社に設置されたパソコン上で「勤怠管理システム」を起動する。起動した後に、「退社ボタン」を押すことで、押した時間が退社時間として記録される。
４）9時より遅く「出社」ボタンが押された場合は「遅刻」、18時より早く「退社」ボタンが押された場合は、「早退」として記録する。
【運用ルール】
・出社時や退社時にボタンを押し忘れてしまった場合など、勤怠を変更したいときは人事部署に電話かメールで修正をお願いする。
保守の例１：利用者のフィードバックを元に改善要望に対する修正
上記のシステムが完成して、実際にこの勤怠管理システムを使って社員の勤怠状況を管理するようになりました。
しかし、実際に社員の人たちに使ってもらうと、色々と意見が出てきます。
・「出社ボタン」と「退社ボタン」の色は、別の色のほうがわかりやすくない？間違えて反対のボタンを押してしまうことがある。
・朝から打ち合わせでお客さんのところに行く日は、直接お客さんの会社に行くので、「出社ボタン」が押せるのは打ち合わせが終わって自社に戻る12時頃になってしまう。打ち合わせのたびに、人事部署に電話やメールするのは面倒だから、なんとかならない？
などなど・・・。
システムは、作った時で終わり、ではありません。
もちろんシステムを作る時には、「要件定義」という工程で、どんな機能が必要かということをきちんと決めます。
必要であれば、実際に勤怠管理システムを使う社員の人たちにヒアリングしたりします。
それでも、実際に完成して使い始めてみると、「これ必要だと思ったけど、あんまり使わないな。」とか、「いらないと思って作らないことにしたけど、やっぱり欲しい。」とか、色々な意見が出てくるものです。
システム開発って、そういうものです。
そういった、日々出てくる改善要望に対して、勤怠管理システムを修正したり、機能を追加していく作業のことを「保守」と捉えていただければイメージしやすいかと思います。
保守の例２：時間の経過とともに新しい機能が必要になったことによる修正
もちろん、時間が経てば要件が変わることもあります。
例えば、勤怠管理システムを導入してから2年が経つ頃、下記のようなルールが会社に導入されたらどうでしょうか？
・これまでは勤務時間は9時〜18時だったが、これからは一部の職種の人（仮にエンジニアのみとします）には、「フレックス制」を適用する。「フレックス制」の適用者は、12時までに出社し、15時以降に退社すれば、「遅刻」「早退」にはならない。
これまでのシステム要件だと、9時より遅く「出社」ボタンが押された場合は「遅刻」、18時より早く「退社」ボタンが押された場合は、「早退」として記録されてしまいます。
そうなると、この勤怠管理システムは、フレックス制度の適用者のために、下記のように修正しなければいけません。
【修正前】
４）9時より遅く「出社」ボタンが押された場合は「遅刻」、18時より早く「退社」ボタンが押された場合は、「早退」として記録する。
【修正後】
４）9時より遅く「出社」ボタンが押された場合は「遅刻」、18時より早く「退社」ボタンが押された場合は、「早退」として記録する。ただし、フレックス適用者の場合は、12時より遅く「出社」ボタンが押された場合は「遅刻」、15時より早く「退社」ボタンが押された場合は、「早退」として記録する。
こういう風にシステムを修正することで、フレックス適用者の人が10時に出社した場合は、遅刻にならなくなります。
こういった改善も、保守のひとつだったりします。
まとめ
システムが作り終わった後も、システムを使う人の意見や、社内ルールの変化、法律の改正などによって、システムはちょっとずつ改善していく必要があります。
そういったシステムを改善していく作業を「保守」として捉えていただければ、まずは理解しやすいんじゃないかな、と思います。
もしあまり分からなかった・・・ということであれば、ぜひコメントで教えてください。
それでは！
コメント