目次

システム運用者の業務を可視化してみる

(Who) 誰が?

(When) 何をトリガーにして?

(What) 何をする?

(Why) 何のため?

(Where & How) どんな条件の時、どうやって?

まとめ：業務の棚卸と構造化

システム運用者の業務を可視化してみる

「今からシステム運用者の業務を可視化しよう」と思った時、どのような順序で何を考えるべきか、解説してみたいと思います。いきなり業務フローは書きません。次のような外堀を埋めてから詳細を可視化してゆきましょう。

(Who) 誰が?

まず、運用しているのは誰か? 何を担当しているか? を洗い出しましょう。これは少人数でやっている場合はシンプルで、書き出すほどのことでもないかもしれませんが、運用担当者が多い場合は意外と厄介です。業務領域やアプリケーションの単位で縦割りの分担をしている場合、フロントエンド、バックエンド、ミドルウェア、OS、DB、ネットワーク等の横串で分担をしている場合、それらの掛け合わせで分担している場合などがあるからです。書き出そうとしてみたら互いの認識が異なることや、相手がその場にいないので断言できないようなグレーゾーンが出てくることがよくあります。そしてそれが問題の源泉でもあることも多いと思います。このようなことに気付けることも可視化の効果の一つです。

(When) 何をトリガーにして?

次にそれぞれの運用の仕事は何をトリガーにして開始されるか? を考えます。大別すると突然発生するもの(都度イベント系)と、定期的に行うもの(定期イベント系)に分けられます。都度イベントとは、「利用者からの問い合わせ」とか、「監視システムから発信されるアラート」などが該当します。このような突然発生するイベントをどんな手段で検知・認識しているかを書き出してみて下さい。「電話」「メール」「問い合わせシステム」「監視システムのダッシュボード」といった粒度で良いでしょう。ここでは、その手段がバラバラであったり、その時々で異なるという状態が問題の源泉です。 定期イベントとは、「定期ジョブの処理結果チェック」「週次報告」「月次の締め処理」などが該当します。こちらは、一般的にはスケジュールが定義されているはずですので、そこから洗い出します。「日次」「週次」「月次」「四半期毎」「年度毎」などにカテゴリ分けして一覧化すると良いと思います。属人化した (その人しか認識しておらずスケジュール表に載っていない) 定期業務がないか? 実施するかどうかが曖昧な定期業務はないか? という事が洗い出す時の注意点です。

(What) 何をする?

前のステップで洗い出された都度イベントや定期イベントについて、ひとことで言うと何をしているのかを大まかに書き出してゆきます。「利用者からの問い合わせ」が来た場合には、「受付」→「切り分け」→「調査」→「エスカレーション」→「回答」→「再発防止」といった具合です。どんな問い合わせが来た場合でも、抽象的に考えれば当てはまるような用語を選んで下さい。これらが後のステップで定義する業務フローのタイトルになります。「エスカレーション」がない場合や「受付」時に即答してしまう場合等、実際には様々なケースがあるでしょうが、それは詳細フローレベルに表現しますので、ここでは様々なケースを包含できるような大枠を仮決めします。詳細フローを描いた結果、枠の数や名前を修正するという試行錯誤はどうしても発生しますので割り切って仮置きして下さい。 都度イベント系の業務については下図のような縦横の表 (以後、業務マトリクスと呼びます) として棚卸結果を表現することができます。業務マトリクスの縦軸、横軸をうまく定義し、できるだけ多く業務がこの枠内に含まれるようにすることが、業務を網羅的に可視化し、後に標準化を進めてゆくためのコツです。

図1. 業務マトリクスの例 (都度イベント系)

一方、定期イベント系の業務については互いの類似性が少ないためマトリクスにはしにくいと思いますので、マップまたはツリー図としてまとめるのが良いでしょう。

図2. 業務マップの例 (定期イベント系)

図1, 2のいずれにおいても、緑色の矢羽に対して1枚の業務フローを定義してゆきます。

(Why) 何のため?

現状業務を網羅的に可視化しようとする際は、それぞれの業務が何のためか? を考える必要性はそれほどありません。やっているのは事実ですから。しかし、Whyはそれぞれの業務の改善を考える際に非常に重要です。短期的な顧客満足に直結する仕事、中長期の信用につながる仕事など、お客様のどんな期待に応えるか? でそれぞれの業務をカテゴライズするのも良いかと思います。

(Where & How) どんな条件の時、どうやって?

いよいよ業務フローの出番となります。業務マトリクスと業務マップで洗い出した枠組み (緑色の矢羽) に対して、そこで行う業務の手順を記述してゆきます。フローの作成前に、それぞれのフローは何に始まり、何で終わるのか、始点と終点を明確にしておくと良いでしょう。「電話による問い合わせ対応の受付」であれば、電話を受けてから、その内容をインシデント管理システムに記録して、次のアクションが決定されるまで、という具合です。この業務のアウトプットは、受領した電話のお問い合わせ内容と対応方針の記録です。この例ではシンプル過ぎて、業務フローを描くまでもないと思われるかもしれませんが、その後のアクションはどんなパターンがあり得るかが整理されるという点で重要な作業です。業務フローは次のようなイメージとなります。

図3. 業務フローの例 (電話による問い合わせ対応の受付業務)

業務フロー内のグレーの六角形が入電後の場合分けを表しています。このように「どんな条件の時 (Where)、どんな手順で進めるか (How) 」が定義され、誰でもこれに沿って業務を進めることができるようになることが業務フローを描く意義だと言えるでしょう。

場合分けを書き出す時に細かな例外を言い出すとキリがありませんが、場合分けはその後のアクションのパターン毎に括れば良いと考えて下さい。Aの場合、Bの場合・・・といろいろあり得るけれど、結局はパターン1に進むのであれば一つに括っておきます。但し、その業務の初心者は例えば「どんな場合に上長承認が必要となるのか」が判断できない可能性もあります。このような判断基準については別途、補足資料 (デシジョンツリー等) を作成し、この業務ステップにリンクしておくと良いでしょう。業務フローの描き方に関するTipsは次回のコラムで、もう少し詳述したいと思います。

まとめ：業務の棚卸と構造化

さて、システム運用者の業務を可視化するシーンを想定して、進め方を解説して来ましたが、この手順はビジネスサイドの業務の可視化についても全く同様に適用できます。システム運用も業務の一つですから、業務部門と情報システム部門で業務可視化の方法を区別する必要はありません。全社で共通の記述法と進め方を決め、統一することをお勧めします。

全社的に業務を可視化してゆくとすると、前述の業務マトリクスや業務マップのさらに上位に一枚のマップを定義する必要が出てきます。例えば下図のようなイメージになります。システム運用業務は「情報システム」という箱の下位に位置付けられます。

図4. 全社業務マップの例

これにより、業務可視化の全体像としては3階層の構造となります。各レベルの定義をまとめておきましょう。

図5. 業務可視化の構造

以上、業務可視化の進め方を解説させて頂きました。可視化のレベル(粒度)を適切に定義し、業務の5W1Hを明らかにしてゆくことがポイントとなります。図5のような最終的な構造を参考に、皆様もシステム運用業務の棚卸を進めてみて下さい。

次回は業務フローの描き方にもう一歩踏み込んで、推奨事項やTipsをご紹介したいと思います。

補足
本稿の図版1〜4は株式会社ユニリタが提供する業務可視化ツール Ranabase (ラーナベース) で作成しています。本ツール内でこれらのサンプルが提供されており、コピーして皆様の業務に合わせて書き換えてゆくことで効率的に自社の業務可視化を進めることができます。無償トライアルも可能ですので、ご興味があれば是非お試し頂ければ幸いです。
お申し込みサイト： https://lp.ranabase.com/