目次

｢おはようから、おやすみまで｣を想定する

5つの対象と4つのライフイベント

監視設計／モニタリング設計

変更対応

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

今回は（2）の「ライフサイクルマネジメント」についてです。（クリックで拡大）

1. ｢おはようから、おやすみまで｣を想定する

システムも業務も生き物です。環境の変化、法制度の変化、組織の変化、さまざまな変化に応じて変えていかなければなりません。最初は想定していなかったイレギュラーな業務パターンや例外ケースが発生することもあるでしょう。また、老朽化により新しいシステムにリプレースしたり、業務そのものを終了したりする必要も出てくるでしょう。しかし、そのシステムや業務が変化を想定しない作りになっているとどうなるか？

｢変更できない！｣
｢やめられない！｣

その結果、

｢運用でカバーしろ！｣

このような悲しい結末になり、運用現場と利用者の貴重なリソースを奪い続けます。

業務やシステムを作るとき、私たちはできる限り未来の変化を見据え、対応できるようにデザインする必要があります。
いわば、業務やシステムの｢おはようから、おやすみまで｣を想定する。その一連の取り組みを、ライフサイクルマネジメントと言います。

2. 5つの対象と4つのライフイベント

（クリックで拡大）

変化が発生する対象は、大きく5つを想定すると良いでしょう。

①業務
②システム
③データ（例：トランザクションデータ、マスタデータ、ユーザ情報データ、ログデータ）
④資材（例：端末、サーバー、OS、DB、各種ライセンス、ネットワーク機器、各種ドキュメント類）
⑤組織（例：業務運営組織、システム運用組織、会社組織そのもの）

この5つの対象に対して、どんな変化が発生しうるか？　4つのライフイベントの視点で想定します。

(1)新規
(2)変更
(3)停止
(4)廃止

(1)新規

新たに業務が発生する。新たに会員データを取得する。新規取引先データをシステムに登録する。当該システムをメンテナンスできる運用担当者にアドミン権限を付与する。

(2)変更

既存の業務を変更する。トランザクションの増加にあわせて、ストレージやディスクを追加する。ソフトウェアライセンスを買い足す。会員情報を変更する（例：姓変更、居住地変更）。取引先情報を変更する。アドミン権限を変更する。

(3)停止

年末年始に業務を止める。システムのオンラインサービスをメンテナンスで停止する。会員情報を一時停止する。運用担当者の休職にともない、アドミン権限を一時停止する。

(4)廃止

その業務自体をなくす。サーバーやネットワーク機器を撤去して廃棄する。ソフトウェアライセンスの契約をやめる。会員情報を破棄する（物理削除）。アドミン権限を削除する。

この4つの視点で、どんなシーンが発生しうるか？それをどれだけ網羅できるかが、後々運用しやすい業務／システムを創るための肝です。

3. 監視設計／モニタリング設計

（再び）システムも業務も生き物です。よって変化を察知（監視／モニタリング）して、適切に変更しなければなりません。

変化の例）
・法制度が変わるらしい
⇒業務のやり方とシステムの機能を変更する必要がある
・取引先の吸収合併があるらしい
⇒当該取引先情報を変更しなければならない
・トランザクションが増えて、システムのパフォーマンスが低下しつつある
⇒ハードウェア、ネットワークを増強したほうが良いかもしれない。データをガベージしたほうが良いかもしれない。

変化やトラブルの予兆はないか？それを察知するためには、日々の業務／システムを測定して、報告（共有）する必要があります。そもそも、日頃何にアンテナを立てておいたらいいのか？すなわち、監視／測定項目を定義するところから始まります。いわゆるサービス測定／報告です。

(1)監視／測定項目定義
(2)監視／測定方法定義
(3)報告方法定義
(4)緊急対応ルール
(5)振り返りの実施

ただなんとく業務を回しているだけでは、変化に気づくことはできません。業務設計／サービス設計時に、きちんとアンテナを立て、仕組みをもって変化の予兆を察知できるようデザインしたいものです。

4. 変更対応

変化を予測あるいは察知していても、いざ業務やシステムを適切に変更できなければ、結局｢運用でカバー｣に陥ってしまいます。変更を確実かつ効率良く実施する。そのためには、変更対応のための活動を定義して実行できるよう整える必要があります。

変更対応は、日頃から取り組んでおきたい定常活動と、変更発生時にのみ行う非定常活動に分かれます。以下、定常活動と非定常活動の例です。

＜定常活動＞

(1)構成管理

(2)情報収集（変更の予兆把握）
業務やシステムの変更につながりそうなイベント情報（例：組織の統廃合、年度末決算処理）などを収集する

(3)キャパシティマネジメント／デマンドマネジメント
業務やトランザクション量の増加／減少を把握し、適切にリソース（運用人員、ハードウェア、ソフトウェア、ライセンス、ネットワークなど）を配備する

＜非定常活動＞

(1)変更管理
変更のリスクを判定する
変更実施可否を判断する

(2)リリース管理
変更に必要なリソースを判断する
変更に必要な資材を判断し調達する

(3)テスト計画と実施（正常系／異常系）

(4)アンチパターンの想定

(5)移行設計
データの移行、スキルの移行方法を検討して実装する
移行のリハーサルを計画して実施する

手始めに、あなたが今扱っている業務／システム／データ／資材／組織について、どんな変化が発生しそうか？それを想像してみてはいかがでしょうか？その習慣こそが、｢後で慌てない｣｢『運用でカバー』に依存しない｣、強い業務、強いシステムを生む第一歩です。

次回は、(3)コミュニケーション設計を解説します。

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

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