こんにちは。
FLINTERSでプロジェクトマネジメント職を担当しております桜井です。
FLINTERSブログ祭りの記事として今回はシステム保守運用業務を遂行するにあたり意識していることを書こうと思います。 テーマは #保守 です。
私は現在参加しているプロジェクトチームでシステムの保守運用部分のPMを担当しています。 その中での気づきや実施してみたこと、意識するようになったことを紹介したいと思います。
システム保守とは
ChatGPTさんに尋ねると下記のように答えてくれました。
システム保守（しすてむほしゅ、System Maintenance）とは、情報システムやソフトウェア、ハードウェアなどのITリソースを適切に運用し、その安定性と信頼性を維持・向上させるための活動全般を指します。システム保守には主に以下のような活動が含まれます。
予防保守:
- 定期的な点検や診断を行い、障害が発生する前に対策を講じる。
- ソフトウェアやファームウェアのアップデート、セキュリティパッチの適用など。
是正保守:
- システム障害が発生した際に、その原因を特定し、迅速に修正する。
- バグ修正、障害対応、データリカバリなど。
適応保守:
- システムの機能や性能を改善し、新たな要求や環境変化に適応させる。
- ユーザーの要望に基づく機能追加や改良、パフォーマンスチューニングなど。
運用保守:
- 日常的な運用業務や監視を行い、システムが正常に動作していることを確認する。
- バックアップの取得、システム監視、ログ管理など。
システム保守は、システムのライフサイクル全体を通じて重要な役割を果たします。これにより、運用コストを低減し、システムのダウンタイムを最小限に抑えることが可能になります。また、セキュリティリスクを軽減し、ユーザー体験の向上に寄与します。
実務を通して分かったこと
上記は保守業務を遂行する側からすると十分な説明に思います。
しかし実際に担当してみて分かったのは上記の保守業務の必要性をステークホルダーに理解してもらう活動も必要ということでした。
上記４つの活動はどれも新しい機能を提供するものではなく、製品の見た目上は変化がありません。
そのため顧客からはやってることが見えづらい状況に陥りやすくなります。
保守だからといって内部的な活動やユーザーやステークホルダーから問い合わせが来たときのみ反応する受動的な対応に閉じてしまうと、顧客からは新しい機能を開発してもらっているわけではないが実態の見えない維持費だけ支払っているという印象を持たれてしまう可能性があります。
また要求や相談事項の対応にかかる工数感についてもある程度の理解を頂く必要があります。
例えばステークホルダーの感覚からすると１日で終わると思っている調査でも実際は影響範囲の考慮等で２，３日かかった場合、実態をきちんと説明をしないと先方からは不信感の素を作ってしまいます。
また障害対応時の対処内容やスピード感によってはマイナスな評価を頂いてしまうこともあるかもしれません。
その結果保守費用の減額を打診されたり、リソースを超えた依頼相談事項を受けて業務が回らなくなるなどの事態を招きかねません。
施策
そこで必要な活動として下記を実施することを考えました。
・保守業務の透明性を上げて顧客から何をしているのか把握しやすくする
スプリント毎に着手したタスクを一覧化して顧客にレポートとして報告します。保守で行っている活動の実態を理解してもらい、この報告を継続することで１スプリントで処理できるタスクのボリューム感を掴んでもらいやすくなることが期待できます。
・品質が向上した部分を可能な限り定量化し報告する
新しい機能追加でなくても、例えばクエリのチューニングで処理速度が向上した。自動テストを組み込んだことでバグ発生が減少した、等は見た目上は変化に気づきにくいですが明らかに品質が向上しています。そのため実施前後の処理速度やバグ発生数等を可能な範囲でトラックしレポートとして報告することで保守活動によりプロジェクトの価値を向上したことを顧客に示せると考えます。
・障害はどんなシステムでも起きることを説明し復旧対応後に原因や再発防止策について報告する
まず前提としてどんなにテストを重ねたシステムでも予期しない外部要因によって障害は発生することを理解頂き、そのうえで発生した障害に対しては原因と対策の報告を行うことで信頼感を向上させます。
終わりに
これらを実施することで顧客は安心して保守に対して予算を投下できるようになると考えています。 保守はこちらから発信をしないと、問題が起こった時のみ評価が下がる減点法になりがちに思います。 そのため障害や対応事項が少ない時でも計測や報告を継続して行うことが資産になる業務であると今のプロジェクトを通じて感じています。
