こんにちはBTI部のマスダです。
今回は情報システム部の大切な仕事「運用・保守」について書かせていただきます。

システム導入・構築と運用・保守

情報システム部の業務として、大雑把に大別すると
・システムを導入（構築）すること
・導入したシステムの面倒を見ること
に分けられます。

どちらの方がシステム屋っぽく映るかと聞けば、一般的にはシステム導入の方でしょう。
導入したシステムの面倒を見る、いわゆる「運用・保守」については地味なイメージを持たれる方も多いのではないでしょうか。

一般的に運用と保守は別の業務として定義されます。
運用はシステムが安定稼働するように予防的措置を講じることを含めたメンテナンス業務で、保守はハード・ソフトの不具合が生じた際の対応を行う業務です。

構築を外部委託する（パッケージのシステムを導入することを含む）場合、ユーザー企業が運用、ベンダーが保守という役割分担で契約を結ぶことが多いでしょう。

ただ、最近は様々なノーコードツールを用いて、ユーザーインターフェースにあたる部分をユーザー企業側で作ったりすることもあり、フロントよりのソフトウェア保守はユーザー企業、ミドルウェアやプラットフォーム部分の保守はベンダーの役割となっていることもあります。

このように運用と保守の役割分担というよりも委託範囲で切り分けて意識することの方が普通な感じがするので、以下「運用・保守」をユーザー企業サイドの役割の中では区別しないで書いていきます。

構築から運用・保守を一元的に見ることの良さ

ユーザー企業側の役割の範囲が広くなってくると、負担も当然多くなるということになりますが、ユーザーニーズに則したサービスを提供しやすくなるというメリットも生じます。

例えば、ベンダーに構築依頼する案件で、リリース後にそのまま要求仕様のとりまとめの段階から主担当となっているSEがそのまま初期の保守窓口になることは珍しくありません。

「何を考えて作ったのか」を理解していることが、ユーザー企業・ベンダー企業の意思疎通が図りやすいこと、またベンダー社内で構築部隊に調査を投げる段階でも正確な情報伝達を行えることがユーザー企業にとってのサービス品質の重要な評価指標だからだと考えています。

同様に、ユーザー企業の情報システム部が導入した製品の仕様理解が深ければ深いほど、システム利用者からの問い合わせに対して、あるいは不具合に対して効率良く適切な対応ができる可能性が高くなります。

運用監視が必要なミッションクリティカルな業務（他社との連携等）以外では、運用・保守担当者の対応の多くは利用者からの問い合わせがトリガーになります。

問い合わせ対応には操作に関する質問、何らかの誤操作によるトラブルの対応依頼等がありますが、それらはシステム利用者側からするとシステムのユーザビリティ評価につながる重要な体験になるため、運用・保守の担当者はいかに早く、正しくトラブルの解決に導くかを意識することになります。

そのため運用・保守の担当者は必然的にシステム利用者との直接的なやりとりが多く発生し、副次効果としてフィードバックを直接受けることも多く、要求構築の下地になるアイデアが蓄積されやすくなります。

役割分担がきっちりしているかどうかについて、会社の規模、組織のレジリエンスという観点では一長一短あると思いますが、少なくとも上記のように現場に近い要望を構築に反映できるという点では、システムカットで構築、運用、保守を一元して行う担当を決めた方がシステム利用者にとって満足感の高いサービスが提供できるのではないかと思っています。

運用・保守担当者も情報システム部の主役

冒頭で、構築の仕事の方が「システム屋っぽい」イメージがあるのではないかということを書きましたが、では運用・保守の仕事が地味でつまらないかといえば決してそんなことはないと思います。

弊情報システム部では「運用・保守職人」という明確な役割がないのでアレですが、一般論としても初期構築期間に比べて運用期間の方が圧倒的に長く、また、日常的にコミュニケーションをとる回数が桁違いなので、システム利用者の中でプレゼンスが高くなるのはむしろ構築選任の担当者より運用・保守の担当者なのではないかと思います。

おわりに

情報システムも企業システムの一部分である限りは、構築・導入したシステムがいかに現場の実業務をサポートしているかというのは重要な観点です。
その意味では、利用者自身によるシステム構築というのが理想的です。

しかし、往々にして利用者自身が作ったシステムは良くも悪くも尖りすぎてしまい、個人用のツールでは問題ないものの、複数人が利用するツールの場合、他所展開の難しい一子相伝のなにかになりがちです。

とはいえ、切って捨てるには惜しい業務の勘所が詰まったものも多いです。
そのエッセンスは抽出したいと思うわけですが、出来上がったものを機能的に分析するだけでは見えてこないものがあります。

それは、オリジナルツールなり業務ロジックの作成者の背景にある業務状況や考え方といったもので、日常的に会話をしていないとなかなか掴み切れないある種の不合理性です。

合理を突き詰め過ぎたシステムは、「使えん」「わからん」と言われてしまう話は世の中にあちこち転がっていますが、その理由のひとつは利用者の理由ある不合理性を織り込んでいないからだと思っています。

上記のようなアンマッチを防ぐことが出来るのは、日常的には利用者部門と、構築時には情報システム部内のコミュニケーションがとりやすい業務システムの運用・保守担当者なのではないでしょうか。

それではまた次回！