![見出し画像](https://assets.st-note.com/production/uploads/images/46985426/rectangle_large_type_2_f7e7ac062103916cfb9b2ccebc432249.png?width=1200)
[ITIL入門⑨]「なぜ?」を掘り下げる
#以前書いた記事をアップデートしました
ITIL入門シリーズ第9回は「なぜ?」を掘り下げるです。
ITILを読んでいて、「なぜ?」と考えてしまう場面がいくつもあるのですが、明示的にその疑問に対する解答が書籍に書かれていないケースも多々あります。
そんな時、自分自身の経験や分析から仮説を立てるわけですが、その中で得られる気づきは実務においては非常に有益だと感じています。
例えば、ITILv3のプロセスとITIL4のプラクティスを比較した場合、以下のような疑問が浮かんできます。(プラクティスとプロセスの違いはこちらを参照ください)
・「キャパシティ管理(ITILv3)」は、なぜ「キャパシティとパフォーマンスの管理(ITIL4)」に名称が変更されたのだろう?
・「リリース管理および展開管理(ITILv3)」は、「リリース管理(ITIL4)」と「展開管理(ITIL4)」になぜ分かれたのだろう?
・「組織の変更管理(ITIL4)」が追加されたのはなぜだろう?
・「サービス資産管理および構成管理(ITILv3)」は、なぜ「IT資産管理(ITIL4)」と「サービス構成管理(ITIL4)」に分割されたのだろう?
・・・などなど。
皆さん理由がいくつか思いつきますでしょうか?
実は答えは単純で、「これまで何かしらの課題があり、それを解決するために更新された」です。
例えば、「サービス資産管理および構成管理(ITILv3)」が、「IT資産管理(ITIL4)」と「サービス構成管理(ITIL4)」に分割された理由は、目的が異なるからだと考えています。
資産管理は財務的な側面が強いのに対して、構成管理はサービスの可視化、品質向上やセキュリティ対応に活用する等が目的になります。
目的に応じて、要件や利害関係者が全くことなるため、目的が曖昧なまま要件定義を初めてしまうと収拾がつかなくなり、結果プロジェクトが頓挫することも・・・。費用対効果もわかりづらいプロセスなので、より一層慎重に進める必要があります。もしそういったリスクが高いのであれば、プロセスは分けた方が良い・・・と判断されても不思議ではないでしょう。
このように、その理由を知ることができれば、自組織がその課題を同じように抱えていた場合、解決のアプローチを容易に得ることができるということです。そういった目線でITILを改めて読んでみると、いろんな発見があるかもしれません。(ちなみに上記はあくまで私の見解です。笑)
本日は以上です。ありがとうございました。
この記事が気に入ったらサポートをしてみませんか?