お久しぶりです。最近プライベートが忙しく、かつAC IVも発売され遠ざかっておりました。いいですよね、AC。もう、時間が溶けるし何より単に楽しい。
さて、今回はITILというより、ITSMにとって重要だと思うマネジメントすることとはどういうことかを語りたいと思います。
そもそもITSMとは、ITサービス管理と呼ばれるものの略称です。では、ITSMとは何をすることがITSMなのか？
この問いをITサービス管理を主務とする方々に投げかけたとすると、おそらくさまざまな答えが返ってくると思います。ただ、その中で誰しもが思い浮かべるものとして、「ITサービス管理ツール(ITSMツール)を導入する」ことが上がってくると思います。
それ(ITサービス管理ツール導入)そのものは確かに大切ですし、コアな業務であると私も思います。しかし、ITSMツールの導入が大切なのは、管理(マネジメント)のために制御(コントロール)するための道具の導入だからなのです。
管理したいものを可視化するために、確実に制御する。そのためのツール導入であって、ツール導入そのものが管理ではない、ということを明言しておきたいと思います。それはあくまで制御です。
ITサービス管理ツールという言葉に引っ張られて、例えば、Jira /SNOW/Remedyなどのツールを導入することが管理であるというのは、大きな勘違いです。ITサービス管理ツールの導入は、あくまで「管理のために制御する」ことを目的としているのであって、管理のために導入していません。
したがって、何よりもかによりもまずは、自分たちが何を管理したいのか？を明確にする必要があります。
Vモデルで考えてみましょう。
自分たちが何を管理したいのか。つまり、、、自分たちが提供しなければならない(IT)サービスとは何か？それを定量的に表す指標は何なのか？端的にいえば、要求定義と要件定義です。
具体的にいえば、どのような(What's kind of...)チケットが必要なのか。これは超具体的な話(例えば、パスワードリセットや構成変更など)をしていません。ここでいう「どのような」とは、どのような種類が、、、、という意味です。端的にいえば、「(投資家保護法の理由から/会社法上の理由から/左記ひっくるめて統制上の理由から/地政学的な理由から/組織上の利益確保の理由から)変更管理」を必要とするチケットって何種類必要ですか？とか。そういうことです。あくまで一例ですが、チケットの種類が何種類必要か、そのチケット枚数は週間/月間/年間何枚ぐらいを見積られているのか、それに対して必要になる体制(人月、スキルセット、ヘッドカウントetcetcこれら定量化できる「単位」)は何が必要で、「単位毎」に定量化できる「数量」は幾らかのか？これらを予測や一定のルールベースに基づいて定義する。これが可視化のための第一歩。別の言い方をすれば、管理(マネジメント)する際の指標です。
では、それら、マネジメントする際の指標がどう積み上がっていけばサービス提供の現場が可視化されるのか、それを制御するのがコントロールな訳です。Vモデルでいうところの詳細設計なわけです。
例えば、積極的に管理したい種類のチケットがあったとしても、それが正しく正確に起票されたり、入力されたりしなければ、管理(マネジメント)できません。可視化された数字が正しいものでなければ、正常な状態なのかそうでないのかの判断ができないからです。
正しく起票されるようにするため、問い合わせやアラートが発報されたら、自動でチケットが起票されるようにする。正しく入力するために、自動で入力されるようにしたり、誤った入力がなされた場合にそれ以上チケットのステータスが変わらないようにする、ガバナンスに違反しないように承認されなければ次のステップに行けないようにする。そういう制御(コントロール)を入れることが必要になってきます。ね？設計でしょ？
マネジメントにより、要求と要件が定義される。
コントロールにより、定義に基づいて設計がなされる。
これを具体的に示すと、あくまで一例ですが、下記になります。
管理(マネジメント)によって、どんな種類のチケットが必要で、それらをそれをどう処理（プロセス）するかを決める。(もちろん定義するのはチケット種別だけではありません。あくまで一例です)
制御(コントロール)がそれぞれの種類のチケットがどの流れ（フロー）を通ってクローズまで制御されるのかを設計する。
これらが終わって、初めて、ITSMツールの「製造(コーディング)」が可能となります。
ITSMツールの導入に絞って話をしましたが、管理(マネジメント)と制御(コントロール)の違いについてご理解いただけましたでしょうか？
「ITサービス管理の導入」と言っても、自分の今しようとしていることは、「管理(マネジメント)」なのか「制御(コントロール)」なのか。これを常に意識しておきましょう。
考えてみてください。「ITSMの導入」というSIプロジェクトにおいて、要件定義フェーズでフロー(詳細設計)を設計をしても話が発散します。逆に、詳細設計フェーズでチケット種類(要件定義)を決めようとしても手戻りしていて進捗が遅れます。
自戒の意味も込めて。
