目次

システムを導入すればおしまい！…ではない

業務運用項目を定義しよう

スキル要件定義

開発と運用の壁。これがさまざまな問題を生む。開発担当者は運用を考えずにシステムをリリースし、足りない部分は｢運用でカバー｣の一言で運用担当者にナントカさせようとする。そして、たいてい火を吹く。なぜなら、リリース間際に対処しようとしても付け焼き刃の属人的な対応しかできないからだ。この状況、運用も開発も、何よりシステムを使う顧客やユーザも幸せにしない。運用をデザインしよう。この連載では、運用を主体的にデザインし、価値あるITサービスを提供できる人材になるための視点や行動を考えます。

今回は（1）の「業務運用／システム運用定義」についてです。（クリックで拡大）

1.システムを導入すればおしまい！…ではない

システムを導入すれば、ハイはいおしまい！

残念ながら、そう思っている人や組織はいまだに少なくありません。

｢クラウドを使えばすべてがラクになる｣｢AIで何でもかなう｣｢RPAさえ入れれば、現行の業務をチャチャっと自動化できる｣

組織長クラスでも、このようなIT万能説を信じている人がいます。その結果、導入検討段階で、あるいは最悪、システムの利用開始直前になって火を噴く。

｢えっ、業務側（＝ITシステムを使う人、ITサービスの管理主管部門など）でやる作業があるの？｣
｢変更対応？システムが自動でやってくれるんじゃないの？｣
｢バージョンアップってなんですか？｣

このような考慮漏れにより、予算をとっていない、運用体制を確保していない。その結果、サービスレベルの低い仕組みができあがったり、どこかでタダ働きによるカバー（いわゆる｢運用でカバー｣が発生したり、ユーザに無駄な作業を発生させたりと、悲惨な状況を生みます。これではITシステムそのものの評価を下げてしまいます。ユーザもベンダも幸せにしません。

｢ユーザのITリテラシーが低いのが悪い｣

そう言ってしまえばそれまでですが、私たちITサービス提供者側もきちんと予防策を講じていく必要があるでしょう。
業務側がすべきこと、システムがすべきこと。この2つがあることを事前に理解してもらい、システム導入後の世界地図を描くナビゲートをしたいものです。

とりわけ、業務側が行う作業。すなわち、業務運用は意識からスッポリと抜け落ちてしまいがち。
いままでITシステムの導入や運用経験の少ないユーザであればなおのこと、ピンと来ない。ITに精通した人であっても、上流工程（企画や開発）にしか関わってこなかった人はイメージしにくい。よって、運用経験豊富な私たちが水先案内人になりましょう。

2.業務運用項目を定義しよう

以下は業務運用項目の例です。全部で12項目挙げました。

■業務運用項目の例
（1）運用スケジュール管理
（2）データ／マスタメンテナンス
（3）ユーザ情報管理／権限管理
（4）構成管理／文書管理
（5）インシデント対応／問題対応
（6）ジョブメンテナンス
（7）リリース対応
（8）調達業務／課金請求
（9）イベント対応
（10）訓練／トレーニング
（11）コミュニケーション管理
（12）サービス報告

（1）運用スケジュール管理

日次、週次、月次、四半期単位、決算時期など業務スケジュールに応じてシステムに対しておこなうべき作業を一覧化し、スケジュールに落とす。やり漏れがないよう管理する。

（2）データ／マスタメンテナンス

システムが管理するデータ（例：売り上げデータ、顧客セグメント別の収益）を抽出したり加工したりする。各種コードやマスタ（部署コード、取引先マスタなど）を整備してシステムに提供する。

（3）ユーザ情報管理／権限管理

システムを利用するユーザIDを発行／変更／無効化する。必要な権限を付与する／剝奪する。

（4）構成管理／文書管理

エンドユーザの端末の機器情報、OSやブラウザのバージョン情報、IPアドレス、ソフトウェアライセンスのバージョンや期限情報の管理などを行う。
必要に応じて更新をエンドユーザに促す。

（5）インシデント対応／問題対応

ITIL®でおなじみ、インシデント管理。問題管理。日々発生するインシデントに対応する。インシデントが再発しない／未然に防ぐ対策を検討して実施する。

（6）ジョブメンテナンス

システムで行う日次の夜間バッチ処理、オンラインのバッチ処理など、必要に応じて変更の判断をする。
（例：決算時期は処理対象のデータ量が増えるため、バッチ処理の開始時間をはやめる）

（7）リリース対応

システムの変更や機能追加を行う際の業務影響を判断する。エンドユーザへの周知や教育（新機能の操作説明や問い合わせ対応など）などを計画して実施する。

（8）調達業務／課金請求

必要な機器やライセンスを発注する。エンドユーザにシステム利用料を請求する。

（9）イベント対応

組織変更（統廃合）、年度末、決算期、オフィスレイアウト変更など業務イベントを事前に察知して、必要な運用作業項目を定義し実施する。

（10）訓練／トレーニング

災害やセキュリティインシデントを想定した、復旧訓練／切り替え訓練などの計画と実施。

（11）コミュニケーション管理

エンドユーザへの日々のコミュニケーション（システム利用手続きの周知、よくあるお問い合わせの整備、システムの便利な使い方を知らせるなど）を計画して実施する。

（12）サービス報告

システムの利用状況、運用作業の実施状況、インシデントの発生状況／対応状況、ヘルプデスクの対応状況など、測定項目を定義して⇒測定して⇒報告する／社内共有する。そこから改善検討につなげる。

これらの項目は、オンプレミス型のシステムでなくても、クラウドでも発生しますし、RPAなどを導入する上でも多かれ少なかれ求められます。
システム導入検討時、あるいは利用開始前に抜け漏れなく検討されているか？実施担当者が決まっているか？ほかに業務側としてすべき作業がないか？
あらかじめ確認しましょう。

また、｢自動化できるものはないか？｣｢どうやったら効率化できるか？｣
このような疑いの目を持って効率化も検討したいものです。

3.スキル要件定義

業務側ですべきこと＝業務運用項目が定義できれば、おのずと｢どんなスキルを持った人をアサインすればよいか？｣あるいは｢業務側の組織にどんなスキルが足りないか｣が見えてきます。
例えば、「(11)コミュニケーション管理」が必要だとあらかじめ分かっていれば、Webデザインが得意な人やエンドユーザとのコミュニケーションが得意な人（ヘルプデスク経験者など）をチームにアサインすることができるでしょう。計画的に人をアサインし、計画的に人材育成を行うことができます。

ただ単にいまいる人を頭数だけそろえて、いきあたりばったりで対応していては限界があります。｢運用でカバー｣で、都度対応を繰り返していては生産性も上がりません。

ところで、業務もシステムも生き物です。常に変化します。変化、すなわちライフサイクルに応じた対応をしないといけません。
次回は、(2)ライフサイクルマネジメントを解説します。

運用をデザインできる人材は、これからの時代、間違いなく価値ある人材として活躍の場が広がります。

目指せ、運用デザイナー！