危機から悟る「ITサービスマネジメント」

ITサービス運営の現場で実践され評価されてきた手法やツールでIT活用プロセスを改善しましょう

どのようなプロダクト／プロジェクトでお困りですか？

ITを活用するプロダクト（プロジェクト）の性格を二分類することがよく行われます. ひとつは企業基幹システムのように重要データを堅牢でセキュアに運用することが求められるSoR（System of Record）です.　もうひとつはテクノロジーやデータを活用した新たな価値を提供することを目的とし、顧客やエンドユーザーが直接利用できるサービスを提供するSoE（System of Engagement）です。

ここで語りたいITサービスマネジメント（以下ITSMと略すことがあります）は元々SoR的なシステムを対象にして普及してきた技術ですが昨今その適用先はSoEへと拡大しています.　ホームページに書かれていた問題事象はどちらの類型のプロダクト（プロジェクト）でも発生するのでありITSMの本質的な考え方はSoR・SoE共通ですが、説明をシンプルにするために今お困りのシステムはSoE的でありDevOpsと通称される開発・運用の方法論を活用した比較的少人数のチームによって実現維持されるものであるとして話を進めようと思います。

何がおきていますか？

IIT活用のプロセスのなかで直面する問題事象を１０種類に整理してみます.　10種類の問題事象は主に業務部門（Biz）が主導する仕事の領域、開発部門（Dev）が主導する仕事の領域、運用部門が主導する仕事の領域（Ops）、全部門共通の仕事の領域にマッピングされています.　右の図を見て皆様の抱える問題がどこかに該当するようであれば以下の説明はお役にたつ可能性があります. ホームページに書かれていた問題事象をこの図に照らし合わせてみると以下のように分類できそうです.

問題事象事例の分類

・ITコストが計画と比べて大幅に増えてているのはなぜ？	7
・稼働後の不具合やヒューマンエラーが減らない. ・今頃になって手順書、マニュアルが存在しない、メンテされていないことが露見した.	3,4,6
・利用者からの機能強化要望に機動的に対応できていない.	1,2,3,8,6
・運用メンバーが定着しないのはなぜ？.	5,6
・導入した ITのパフォーマンスを利害関係者に対してうまく説明できず投資効果を疑問視されている.	9

右の問題事象の分類図は以前当社代表が参画した民間の協議団体活動のなかでITの利用、開発、運用に詳しい識者たちによって提唱された「IT活用価値モデル」を裏返して価値が欠損している状態に読み替えてみたものです.

今の自分を知ること

今起きている問題事象に対処しIT活用価値を獲得していく道筋をITサービスマネジメントは示してくれます.　目指す歩みのはじめは当事者のチームメンバーとの対話を通じて問題事象の真因を追求することです.　その結果は例えば「人」「もの」「金」といった視点で整理してみることで誰が（どのチームや組織が）どのようなアクションをとればよいのかを可視化していくことが重要です.

ゴールはどこですか？

IT活用を企図したときにイメージしたはずの「X年後には私は（私の組織は）〇△□のようになっていたい」というビジョン、そしてそのビジョンにたどり着くために設定した定量的な指針としてのゴールを実現していくことが進むべき道のはずです.　それを見据えて課題解決の達成レベルと目標期限を記録することとします.　表のように３カ年計画で価値の獲得を目指すとした場合、毎期の始まりか終わりにこの記録をアップデートしIT活用に関わるメンバーが気持ちをひとつにして共有するのです. 　この価値獲得表はいわばIT活用の実態を表す自己像といえるものです。

目指す価値を獲得してくためには技術アセットを蓄積していくことに加えそれを健全に活用できるプロセス、チームメンバーが担う役割を最適化していくことが必要です。

役割定義は非常に重要なステップです.　最初に役割定義を明確化しておけばそのあとの様々な作業の漏れ抜けリスクを軽減できるでしょう.　チームが担う役割のカバレージ例をダウンロードできるようにしていますのでご一読ください。

垣根を超えた協働が必須

先の「自己像」をまとめるために直面する問題事象をときほぐしていくと事象に関わる関係者が意外に多いことに気がつくのではないでしょうか.　右の図で企業体のなかのIT活用に関わる組織を一例として模式化してみました.　価値獲得表の列に現れる課題の一項目ごとにさまざまな部門が陰に陽に関わり合っているのが普通の姿でしょう. 　課題を遂行可能なものとして設定するためには自部門・他部門含めたプレーヤーが組織の壁をとりはらって協働しながら正しい課題化を行っていくことが必須であるといえます. 下図はこれを絵に描いてみたものです.　協働におけるよく知られたカイゼンツールとしてバリューストリームマップの概要を説明する資料をダウンロードできるようにしていますのでご参照ください。

ベストプラクティスとは？

長い年月の間に世界中のIT活用実践者が経験し蓄積してきた課題解決のためのツールや方法論は「ベストプラクティス」という用語で形式知化されています.　例えばITIL（Information Technology Infrastructure Library）はITSMにおけるよく知られたベストプラクティスであり有用なプラクティス（実践的なツールや方法論）を体系的に整理しています.　ただし右図のITIL 4のカバレージに示されるようにかなり長大な構成になっています.　ビジネススピードを重視するITシステムに対してこれら全てを適用する必要はありませんし逆に導入ありきで取り組もうとすれば副作用もありそうです.　問題事象解決に直接役立つところから適用を考えることが現実的でしょう.ITILの詳細については例えばitSMFJapanの公開情報が参考になります.
一方DevOpsはIT開発とIT運用のサイクルを高速に回すことを狙いとしたベストプラクティスでありこれも様々な体系が考案され利用されています. 下図では一例として「３．価値を生む作業ができていない」という問題の解決に有用なプラクティスを例示しました.　冒頭で分類した問題事象を見ると右図問題項目にあてはまりそうな感触を持ちます.

ITサービスマネジメントのプラクティス

上述したIT系プラクティスとITSM系プラクティスを組み合わせて複雑な問題群に対処していくことが改善実行フェーズでの中心的な作業となります.　ホームページで例示しました問題事象はまさにその事例ですがIT運用フェーズで発生する問題も原因をたどると運用前の上流（企画、要求・設計、開発）にさかのぼることがあります.　プロセス上流で行うべきデザインタスクを確実に実行することが下流でのシリアスな問題、大きな解決コストの発生を抑止することに有効である、とはよく言われることなのです.　以下では安心・安全なIT導入を支える3種類のプラクティス、「SLA/OLA」、「SAC」、「リリース判定」を紹介します.　これらのプラクティスはITサービスの健全性を維持するためのベーシックな道具であると同時に冒頭分類しました問題事象のいくつかに対する重要な対策となりうるものです.　

SLA/OLA

ITSMにおいて特に重要な管理対象はITサービスの健全性を担保するためのベース情報であるサービスレベルオブジェクト（SLO）とオペレーショナルレベルオブジェクト（OLO）です.　それぞれが定める情報項目を関係者間で明文化し合意するサービスレベルアグリーメント（SLA）、オペレーションナルレベルアグリーメント（OLA）の維持はIT活用を健全に保つための主要プラクティスといえます.　

右図はSLAシートの記載例です.　文末からダウンロードできますのでご参考としてください.　SLAシート同様OLAについても関係者により合意された文書として管理してください.

SAC

SLA,OLAで定めた内容が正しく実現されているのか運用開始前に確認する行為は、運用チームから言えば「運用受け入れ」であり、開発チームから言えば「システム引き渡し」ですがこのインプットになるチェックシートがサービス受け入れ基準（Service Acceptance Criteria）です.　SLA/OLAを定め、SACを確認して運用に入る流れをしっかり遂行することが運用開始後の問題発生抑止につながります.　右図はSACシートの記載例です.　文末からダウンロードできますのでご参考としてください.

リリース判定

SLA/OLA,SACが合意されITシステムの開発が進み首尾よくリリースする段階になれば安心・安全の運用をスタートする最終ゲートとなるのがリリース判定です.　特に初回リリース作業は、システム規模が大きく、複雑になったとしても適切な負荷の範囲でリリース判定を行えるよう上流各工程でのエビデンス類の記録・可視化の仕組みを効率化させることが重要です.　右は初回リリースの場面を想定したリリース判定シートのサンプルです.　文末からダウンロードできますのでご参考としてください.

改善スパイラルこそ命

プロセス改善の流れはPDCAサイクル、あるいはジョン・ボイド（元米国空軍大佐）が提唱した意思決定と行動に関する理論であるOODAループに沿って理解すると把握しやすいように思います.　OODAループは次の構成要素がフィードフォワードあるいはフィードバックで接続されるループとして定義されます.

　・観察（Observe）
　・情勢への適応（Orient）
　・意思決定（Decide）
　・行動（Act）

これをIT活用プロセスの改善に適用してみるならば、

　・問題事象の観察
　・観察結果を意思決定可能な情報として整理・統合
　・問題事象の重み、対処に要するリソース等を考慮し実行すべき課題を決定
　・課題を実行→（再び観察へ）

このループを反復しながらめざすべき自己像を実現していくわけです.　ITサービスマネジメントの手法は特に「Orientation」のフェーズを遂行するのに有用な考え方やプラクティスを体系的に提供しているところに価値があると当社は評価しています.

以上説明しましたITサービスマネジメントのポイント踏まえ活動していくことで確実に問題事象の発生を抑止しのぞむビジネスゴールへ到達することができると当社は考えています.　

Let’s start ITSM!

お役立ち資料ダウンロード

ITSMを推進する際にお役に立つ資料類のダウンロードリンクを用意しました.　資料類をプロセス改善の参考にしていただければ幸いです.　これらの資料は当社代表が関わったさまざまなITサービス開発、運用の現場での経験、また業界団体での活動成果をもとにしています.

「DevOpsの価値とプラクティス」は10のIT活用価値カテゴリ、価値阻害要因、課題、そして課題解決に役立つプラクティス群の関係を説明します.　最初に読んでほしい資料です.	DevOpsの価値とプラクティス	ダウンロードリンク
「価値獲得表」は自チームの現在のIT活用レベルと将来の目標レベルを可視化します.	価値獲得表	ダウンロードリンク
「役割カバレージ表」はITを運営する典型的なチームの役割構成を例示します.	役割カバレージ表	ダウンロードリンク
サービスレベルアグリーメント（SLA）、オペレーショナルレベルアグリーメント（OLA）、サービス受け入れ基準（SAC）の記載事例です.	SLA/SACシートサンプル	ダウンロードリンク
リリース判定シートの記載事例です.	リリース判定シートサンプル	ダウンロードリンク

此処から先へ

ここまでのご説明とダウンロード資料をきっかけに皆様が自律的にIT活用プロセスの改善に取り組まれていくことを当社は願います.　しかしながら諸事情により当社の支援が必要とお考えの際にはお気軽にご相談ください.　以下のリストは当社にて支援可能な作業の例です. これらをまとめたITSMアドバイザリサービスをご活用ください.　お打ち合わせにはメール、Web会議、貴社ご指定場所訪問などご要望にあわせ対応します.

関係者へのヒアリングによる現状把握

改善課題の策定

改善遂行状況のモニタリングとフィードバック

ITSMプロセスドキュメント作成

ロール定義、スコープオブワーク、プロジェクト計画、変更管理、リリース管理、インシデント管理、問題管理、情報セキュリティ管理、等

問い合わせフォームへ行く