はじめに
はじめまして、公共サービス事業部の星と申します。2023年10月に新卒入社、翌年1月から約1年間、前所属の事業部でシステムの保守運用業務を担当しました。
この記事は、私の業務経験をもとにしており、まだ保守運用の経験がない方や始めたばかりの方向けです。
システムの保守運用とは
一般的に「保守」と「運用」は別物で、それぞれ具体的に何をするのか簡潔に説明すると以下でしょうか。
- 保守：機能の改修を含む活動
- 運用：安定稼働させるための活動（定型、非定型）
より具体的には、私の場合ですと監視やデータパッチ等の定常作業を実施しつつ、エラーが発生した時の原因調査および復旧や、想定外の挙動を発見した時の改修なども実施していました。
私は特定の顧客向けのシステムを担当していたので、上記に加えて顧客の要望に応じた機能追加やデータ調査等も行っていました。
キャッチアップにおける工夫
私のように保守運用フェーズの途中から配属された場合、当然ですが配属当初からシステムは完成しており既に稼働していることになります。今まで触れたことや聞いたことすらない技術が数多く使われていました。さらに、技術面に加えて顧客の業務背景なども勉強する必要があります。
学ばないといけないことが多いですが、なるべく早くキャッチアップするために意識していたこと、実践していたことを書きたいと思います。
一般の知識か内部の知識か
今学ぼうとしていることは「インターネットで検索したら多数の記事がヒットする」ような広く知れ渡っているものなのか、それとも「プロジェクト内のドキュメントにしか記載がない」ような内部の人しか知らないものなのか。この違いを常に意識していました。
前者であれば、時間をかけてでも納得いくまで調べることが多くありました。様々な記事を読んだり、ひたすらAIに質問したりしていました。特にAIへの質問は、どんなに初歩的な内容でも気軽にできるのでおすすめです。AIからの回答が正しそうか調査し、新たに生まれた疑問をまたAIに聞いてみる、というサイクルが効果的でした。
一方で後者の場合は、自分で調べるだけでは限界がありますし、AIに聞くわけにもいきません。ある程度調べても解決しないものは躊躇せず先輩方に質問していました。そのためにも、やはり素早くプロジェクトに溶け込んで周囲と良い関係を構築するのは重要なことです。以下の記事で紹介されている工夫が興味深かったです。
保守運用業務に限る話ではないですが、両者の違いを意識すると効率的なキャッチアップができるのではないかと思います。
データを見る
保守運用担当者に対してどこまでデータベースにアクセスする権限が与えられているかはプロジェクトにもよると思いますが、許されている範囲で実際のデータを積極的に見ると良いと思います。
データを見ている中で「このテーブルのこのカラムにはそういう意味があるのか」「このカラムにはこういったイレギュラーなデータが入ることもあるのか」というような発見が多くあり、顧客業務の理解にも繋がっていました。
障害発生時の対応
私が配属された時点ではシステム全体が安定稼働していましたが、それでも稀にメインシステムがエラーで落ちてしまうことがありました。
顧客業務に大きな影響があることは理解していたので、発見次第すぐに周囲に伝えることを徹底していました。先輩方の動きを見て対応を少しずつ学んでいきましたが、自分では原因の特定が困難だったと感じる場面もあり、やはり障害を発見した際はまず共有することが大事だと感じました。
システム障害対応の心構えと対応 にもあるように、障害発生時は初動が重要だということを身をもって実感しました。
注意すべき点
特に特定の顧客向けに作られたシステムの場合、顧客業務の事情がソースコードに反映されていることがあるという点は気を付けるべきだと感じました。
例えば、ある機能の改修を担当することになり該当するソースコードを読んでいると、以下のような疑問を抱く場面があるかもしれません。
- なぜこのような “不自然な” 処理順序になっているのか？
- この処理はもっと簡潔に記述できるのでは？
そうした場合に改善の余地ありとすぐに断定するのは危険です。不自然あるいは冗長に見える実装がされているのは、顧客の業務上発生しうるイレギュラーなケースに耐えるためかもしれません。もちろん実際に改善できる場合もあると思いますが、まずは周囲に確認することが大切です。
おわりに
私の業務経験をもとに、保守運用について共有したいと感じたポイントを書きました。
技術的な話はできませんでしたが、少しでも保守運用業務のイメージがわいたり、参考になる部分があれば幸いです。