ITIL シラパス2011の基本とは
ITILとは？
Information Technology Infrastructure Library(ITIL)は、ITIサービスマネジメントのベストプラクティス（成功事例）を体系的に整理した手引書を指す。
ITILの前回バージョンv2と今回の大きな違いは、プロセス個々に着目して解説されていたのに比べ、サービスのライフサイクルに着目して解説している点となる。
サービス・ライフサイクル(Service life cycle)
サービス・ライフサイクルは、その名の通り、サービスが市場に生まれて、廃棄されるまでの流れを表すものであり、ITILでは以下と定義されている。
- サービスストラレジ(戦略）
- サービスデザイン（設計）
- サービストランジション（移行）
- サービスオペレーション（運用）
- 継続的サービス改善（改善）
ITサービスを供給している組織「サービスプロバイダ」が、顧客が期待する価値を提供する能力を「サービスマネジメント」と呼ぶ。
サービスストラテジ(Service Strategy)
事業の目標に準じた、ITの要件と役割を定義する。ビジネスの観点で、プロバイダの方針やサービスの位置づけを明確にするステージである。
サービスは一般的に「人」「物」「情報」が「顧客にとって価値ある活動」をしているものを指すため、ITだけで成り立っている訳ではない。
サービスがどのような顧客に、いくらで、どのような価値を提供するのか。そのために必要なものはなにか、必要なものを提供するのに、いくら掛かるのか。また、どのくらいの時間が掛かるのか、など。
ITを通じてビジネスに必要な戦略的な手引きを提供することを指すものである。
サービスデザイン（Service Design）
サービスストラテジで定義した方針に従って、サービスの仕様や導入計画を作成するステージである。
サービス設計で必要なことは、あらゆる観点からサービスを捉えて、そのすべてを考慮することだ。
例えば、本をECサイトの場合。商品となる本はどこから仕入れるのか。仕入れた本はどうサイトにアップするのか、そのサイトで購入したものはどう顧客へ配送されるのか、などぱっと考えるだけでも多くのオペレーションが思い浮かぶ。
そのオペレーションをどこからどこまで人の手で行うのか、ITで行うのか、ITの場合、どう維持するのか、維持するのに必要なものは何か、など明確に設計することを指すものである。
サービストランジション（Service Transition）
サービスデザインで定義された内容に従い、移行（サービスの新規導入や変更）を実施するステージである。
サービスデザインで設計された、すべて（商品、IT、プロセス、人など）を用意し、
それが期待通りに機能することを検証し、課題があれば修正するものである。
サービスオペレーション（Service Operation）
サービストランジションで移行されたサービスを供給し、顧客へ価値を提供するステージである。
継続的に顧客の期待以上のサービスを効率よく提供することだけではなく、期待に添えない状況が発生した場合にできるだけ早く期待以上の水準に復旧させることも含む、
ITサービスを提供するために日常的になされるすべての活動を指すものである。
継続的サービス改善（Continual Service Improvement）
供給されたITサービスに対して、PDCAサイクルを継続的に回し、改善していくステージである。
ITサービスを日々供給していく中で発見された改善点に対して、目標を計画し、その計画に対して対策を実施し、実施された結果を分析し、より良い結果を得る為に必要な処置を行う一連の活動を継続的に行うことを指すものである。
ITIL v2の基本とは
以下の内容はITIL v2の内容です。最新の情報ではありません。（2016/4月現在）
直近の自分の関わるプロジェクトで必要となってきたので、今回はITILについてまとめてみる。
ITILとは？
ITIL（IT Infrastructure Library）は、１９８０年代にイギリス政府によってIT運用のノウハウを調査、それを体系化しガイドラインにまとめたのがITILの始まりとなる。
ITはシステムを構築し終えたところがスタートではなく、その後運用という構築したシステムを効果的に維持する、大切な作業がある。
組織の業務部門が提供するIT運用を「サービス」としてとらえ、その「サービス」が投資に見合った管理がされ、適切に提供されているかを重要としている。
ITILは場当たり的なIT運用を改めて、システム化し、運用業務の自動化と相互間の連携を進めることによって効率化を図ること、「サービス」の提供という観点からIT運用を可視化し、顧客満足度を向上すること、そして一つ一つの運用業務に裏付けを与え、適切なIT運用コストを算出するための根拠を手に入れること、このようにIT運用に関する業務を全般的に体系化し、再構成するための指針として利用するのがITILである。
ITILの中心となっているのが、日常的な運用管理業務をテーマとした、「サービスサポート」、そして中長期的な運用管理計画の策定を扱った「サービスデリバリ」だ。
- サービスサポート
サービスサポートは、IT運用における障害や、ユーザーからの問い合わせを１つ１つ管理し、その根本原因を見いだし、場合によってはサービスの変更や増強を含む措置を施し、ユーザーへフィードバックする一連の作業を確実に、組織的に、効率的に遂行するための手順や手法を表す。
そのプロセスを「インシデント管理」「問題管理」「変更管理」「リリース管理」「構成管理」に分け、これらを連携させた、一連の活動としている。
- サービスデリバリ
サービスデリバリは、「サービス」が予め定義された「サービスレベル」を維持すべく、どう運用されていることが必要か、その運用はどの期間で、幾らぐらいのコストで行われるべきかを明文化するものである。
サービスデリバリでは、「サービスレベル管理」が定義され、各組織の求めるサービスレベルを達成するために、「可用性管理」「キャパシティ管理」「IT財務管理」「ITサービス継続性管理」が説明されている。
上で説明した「サービスサポート」、「サービスデリバリ」の構成を図にしたのが下図となる。
終わりに
今回はITILの概要についてまとめた。
今後は今回の内容を詳細化していき、ITILに対する更なる理解を深めていきたい。
プロジェクトのリスク管理方法
今回は、プロジェクトマネジメントにおける、リスク管理方法についてまとめてみる。
リスク管理とは？
リスクとは、現在発生している問題ではなく、将来プロジェクトに起こりうる脅威、危険を予測し、予め対策を行うことを言う。
問題との違いは、端的に言えば、現在発生しているか、していないか、という違いとなる。
リスクを定義する方法
では、どのようなものをリスクと定義すればよいのだろうか？
端的に言えば下記となる。
- 現在発生していない
- 将来的に発生する可能性がある
- プロジェクトに影響を与える
例えば、「プロジェクトを構成するメンバーの一人がプロジェクトを辞めてしまいそう」というのがリスクとなる。
次に定義しなければいけないのは、影響度だ。
リスクを分析する方法
「プロジェクトを構成するメンバーの一人がプロジェクトを辞めてしまいそう」というリスクの場合、その辞めようとしているメンバーがどのような役割を担っているか、によって影響度が変わってくる。また、発生確率も人によって違う。メンバーにとても重要な役割を担っているメンバーがいる、当然そのメンバーが辞めた場合の影響度は大きいものだが、その方が辞める気持ちがなく、前向きにプロジェクトに邁進している場合、辞める可能性が低く、リスクとして、挙げる必要がない場合がある。
上記のようにリスクとなる要因に対して、以下を分析することでリスクとなり得るかどうかを分析する。
- 影響範囲
- 発生確率
上記の分析は、「低い、普通、高い、非常に高い」など定性的に分析することが大事だ。
リスクを対策する方法
リスクを特定出来た後は、そのリスクに対して対策を行うことになる。
リスク対策には、大きく分けて４つの方法がある。
- リスク回避
- リスク低減
- リスク移転
- リスク保有
リスク回避
リスク回避とは、リスクを抱えた状態、状況を避ける。ということとなる。
「プロジェクトを構成するメンバーの一人がプロジェクトを辞めてしまいそう」の場合、そもそものメンバーを辞めさせないようにするか、もしくはそのメンバーをプロジェクトから外す、といった対策がリスク回避となる。
リスク低減
リスク低減とは、リスクの発生確率を下げる、もしくはリスク発生時の影響を低くする、またはそれらの両方の対策をとることをいう。
「プロジェクトを構成するメンバーの一人がプロジェクトを辞めてしまいそう」の場合、そのメンバーが辞めてしまう時期を延期させる。または、そのメンバーが担う範囲を小さくする。ことがリスク低減となる。
リスク移転
リスク移転とはそのリスクとなる要因を他へ移動させてしまうことをいう。
「プロジェクトを構成するメンバーの一人がプロジェクトを辞めてしまいそう」の場合、その辞めてしまうメンバーを他の人間に変える。またはそのメンバーが担う範囲を他者へ移動（委託も含まれる）を行うことが、リスク移転となる。
リスク保有
リスク保有とは、リスクを回避も低減も移転もしない、つまり「何もしない、発生した損失は甘受する」ということをいう。
「プロジェクトを構成するメンバーの一人がプロジェクトを辞めてしまいそう」の場合、そのまま対策せず。辞めさせてしまう。
しかし、この方法は認められる影響範囲が小さいリスクに対して行うことが一般的だ。
終わりに
今回はプロジェクトマネジメントのうち、最も技量の問われるリスク管理をまとめてみた。
リスク管理を常に行えるマネージャーは「仕事を先んじている」ことができる人間であり、やはりどれだけ先を見通して、対策を考えられているか、がよいマネージャーの資質と言えると思う。
自分も携わったプロジェクトに関わる情報を常に整理、分析し、先んじてリスク管理できるよう、習慣化していきたい。
問題を分析し、構造化する方法
前回（問題を定義する方法）では、どう問題を正しく把握するか、をまとめた。
今回は正しく定義された問題をどう分析し、構造化することで、解決方法を導くのか、を述べたい。
問題を枠組み（フレームワーク）で分析し、詳細構造を明らかにする
問題は多くの状況が重なりあい、複雑になっていることが多い。まずは、問題を分野などから適した枠組み（フレームワーク）に当てはめ、詳細構造を明確にする必要がある。
問題に対して必要なフレームの組み合わせの例は、以下のようなものとなる。
問題）プロジェクト期限が近づいているが、品質が悪い
- 品質管理基礎（QCD）
→分析例：期限の設定に対して、C（人員）が少ない。その為Q（品質）の確認ができていない。
上記のように問題に合わせてフレームワークを当てはめ、分析することで問題の構造が詳細化されていく。詳細化された構造は問題が発生した原因が何か、を示している。
問題の原因を仮設的に設定する
問題の原因が明らかになると、次に行うことは、解決方法について仮説を設定する。
仮説の設定方法は、次のような点に留意する必要がある。
- 新規性、独自性がある
上記は、新しいビジネスを起こす際に、誰も気付いていない市場を見つける、という説明が多いが、その限りではない。
問題となっている＝誰も解決方法に気付いていない。であり、そのことにスポットを当てて考えることは必要なのだ。
- 具体的な行動（アクション）に繋がる
たとえば、品質が悪いから、管理をしよう、などと抽象的なことは具体的ではない。
例えば、品質が悪い＝誰もチェックをしていないのであれば、確認する。確認方法はインスペクション（定められた手順、チェックリストで第三者確認を行う）とより具体的な手順、プロセスを定義する必要がある。
- 実際に活用できる
これは、実現可能な仮説であることを指す。
例えば、期限に対して100人日工数が足りず、人がいない、という問題の場合、では、100人を調達して解決する。ということは実現可能ではない。
100人日工数が必要分に対して、今ある人数で実現可能なもの以外は対象から外す、もしくは期限を顧客への影響が最小限となる範囲まで伸ばす、というのが現実性があるだろう。
設定した仮説の妥当性を証明（または否定）するデータを収集する
設定した仮説が正しいか証明するには、事実を示すデータが必要となる。
それは、ピラミッド原則に従うと、仮説が主題（テーマ）となり、事実を示すデータが主題を支えるひとつレベルが下の階層のメッセージと言える。
例えば、以下のような例となる。
仮説）機能ABCのうち、BCを対象外として、Aを期限内に納品することが可能
- 機能Bは既存のシステムがあり、そちらで業務遂行が可能
- 機能Cは期限の1年先の法改正を見据えた機能であり、必達ではない
- 機能Aのみを対象にすれば、現状の工数、人数で達成可能
今回は仕事を行う上で、基本であり、必要な問題解決について、分析と構造化、解決についてまとめた。
今回挙げた内容を常に意識しながら日々の業務に向かい、習慣化していきたい。
問題を定義する方法
問題を正しく定義できる、ということは、問題解決するための最初の一歩であり、これがブレてしまうと後々が全てブレてしまうため、意図しない解決方法に対して時間と労力を割いてしまう危険がある。
つまり、問題を定義することは、入り口でありながら大変重要なステップであると言える。今回はどう問題を定義すればよいか、について述べてみたいと思う。
問題とは何か
問題は何かと簡単に言えば、今現在の結果と、本来望んでいた結果の間にあるギャップのことを言う。
例えば今現在の結果が「売上が低くなっている」、本来望んでいた結果「売上が上がる」が欲しい、そのギャップのことを指す。
これだけを聞くと簡単に見えるが、本来仕事上で発生する問題は、特定の環境下で様々な影響を受けながら拡大してきたものであり、その環境は単純な場合もあれば、原因と結果が入り交じった、大変複雑な場合もある。
問題を定義する、とは何か
問題は今現在の結果と、本来望んでいた結果の間にあるギャップだということは、上記でも述べた通りである。
では具体的に、どう問題を定義するのか、
- 今現在の結果 ＝ 今、どこにいるのか
- 本来望んでいた結果 ＝ どうなりたいのか
自分を見失った、という言葉がある。これは人間が状況を正しく把握できていないことを端的に示す言葉であり、どんなに注意していても人間は正しく現状を把握できていないことが多々ある。
私自身もそのような経験をしてきた。例えば自分がいくら残業し、率先してチームを引っ張っていった、と自負していても、メンバーは、なんであの人は自分のことを分かってくれてないのだろう、と感じたとしたら、そのリーダーは正しく状況を把握していないことになる。
また、プロジェクトがうまくいく為には、この仕事を今やることが最善だ、と自分が思ったとしても、他に優先すべきことがあれば、これも正しく把握していないことになる。
上記は、自分が把握しているギャップが正しく定義出来なかった、例となる。
それでは、どう正しく問題を定義すればよいのだろうか？
問題の正しい定義のやり方
正しく問題を定義するには、その根拠を具体的に表すことができるほど、情報が十分にあること。また、その問題を論理的に構造化できていることが必要である。
- 状況が具体的（定制、定量的）に把握できる
- 問題の分析元となる情報源が正しい
- 今現在の結果と本来望んでいた結果の差（ギャップ）がなぜ発生したのか、が見出だせている
上記はどれも、自身や他者の思い込みや誤った情報源からは、正しく把握できない。具体的にどう正しく問題を定義するか、は事実（ファクト）を正しく集めることが正しいやり方といえる。すなわち、知っている人に聞く。または出典が明らかな情報（政府や省庁の発表など出処がはっきりしているもの）を収集する、などがある。
終わりに
正しく状況、問題を把握する。には何が正しいのか、自分の今までの経験を振り返ると、私の場合、失敗するときは、自身の思い込みや他者の誘導に引っ張られ、正しく定義できていないことが多い。
状況を何度も確認し、事実を集め、問題を正しく定義できるよう、今回学んだことを常に意識して日々取り組んでいきたい。
グループ内の考えを要約する方法
グループ内の考えを要約する。とは、ピラミッド型にメッセージを整理する際の基本であり、ピラミッド構造の「どのレベルのメッセージもその下にあるメッセージのグループを要約したものである。」というルールをどう守るのか、ということにある。
今回はその混乱した考えの中から、本質的な考えを抜き出すこと、すなわち帰納法的な要約を見つける方法をまとめてみる。
考えの類似性を発見する
考えを整理するときに、まず必要なのはその類似性を見つけることだ。類似性を見つけることができれば、それ自体がグループ化となり、グループで分けた説明にもなる。
では考えの類似性をどう発見すればよいか、それは次のような方法がある。
- 各考えがすべて同じテーマについて述べている
- 各考えがすべて同じアクションを必要としている
- 各考えがすべて同じ対象に対するアクションについて述べている
- 各考えがすべて同じ洞察結果を意味している
以下にそれぞれの詳細を記述してみる。
各考えがすべて同じテーマについて述べている
同じテーマとは、現在の状況から成し遂げたい、いわゆる問題の解決方法を指す。すなわち「何が、どうなる」の「何が」の部分、メッセージの主部を指す。
たとえば「ラーメンがうまい」「うどんがうまい」「そばがうまい」は、すべて「麺類」がテーマであり、それでグループ化する。
各考えがすべて同じアクションを必要としている
同じアクションとは、異なる対象についての行動が同じことを指す。すなわち「何が、どうなる」の「どうなる」の部分、メッセージの述部を指す。
たとえば「ボールを蹴る」「缶を蹴る」「石を蹴る」は、「蹴る」でグループ化する。
各考えがすべて同じ対象に対するアクションについて述べている
同じ対象に対するアクション群の実行から得られる結果について述べる。
たとえば「本を書く」「本を読む」「本を捨てる」は、「本」でグループ化する。
各考えがすべて同じ洞察結果を意味している
洞察とは、物事を観察して、その本質や、奥底にあるものを見抜くこと。見通すこと。を指す。この場合本質や奥底にあるものの類似点を挙げ、グループ化することを指す。
たとえば「Java」「C#」「Ruby」「PHP」はすべて「オブジェクト志向言語」が本質であり、それでグループ化する。
グループ内の要約を簡単にまとめてみた。今回のことも、通常人は無意識に行っているがそれに気付かない点が多いと感じる。論理性を持った説明が常にできるよう、意識的に行っていきたい。
自分の考えを論理的な順序に配置する方法
考えをグループ化する場合、ただ類似点を当てはめてグループ化すればよいというものではない。グループ内の順序についても、決める必要があります。
なぜなら正しい順序なのかどうか判断し、説明できることが論理的に配置されていることとも言えるからです。今回はその順序の付け方についてまとめてみる。
論理的順序の種類
論理的順序の種類は、大きく以下の３つだとと言われている。
この３つの順序付けは１つだけ適用してもよいし、組み合わせて適用してもよい。しかしグループ化した中にどれかひとつは必ずあるべきものだ。
- 時間の順序
- 構造の順序
- 重要度の順序
以下にそれぞれの順序付けを詳細にしてみる。
時間の順序
時間順はもっともシンプルで一般的なものだ。ある結果を達成するために必要なプロセスを書いてみると、一度に１つずつしか実行できない。これを順序よく正しく書くのが時間の順序となる。
正しく順序を書くときに、よく間違えるのが、原因と結果を同じグループとしてしまうことだという。
例えばECサイトの一般的な運用フローを考えた場合、
- 顧客がサイトに訪問する
- 商品を検索する
- 欲しい商品が検索される
- 商品をカートに入れる
- カートで購入手続きを行う
- 商品が購入される
上記の場合、「3.欲しい商品が検索される」「6.商品が購入される」はプロセスではなく結果になります。正しく時間の順序とするならばこの2つは省き、
- 顧客がサイトに訪問する
- 商品を検索する
- 商品をカートに入れる
- カートで購入手続きを行う
と上記のようにすべきだ。
構造の順序
構造の順序とはMECEと言われる。個々に見てダブリがなく、全体的に見てモレがない。構造とは、組織構成や機械の部品など論理的にも物理的にも構造を言葉にしたものとされます。
例えば、あるプロジェクトの構造を示すと
プロジェクトオーナーの下にPMがいて、その下に開発部隊、運用部隊、営業部隊が居ます。それぞれの部隊にはリーダーがいて、その下にメンバーがいる構成になっています。
このような構造の順序を表すのが構造の順序であり、例えばその構造に誰を、どんな理由で配置したのか、を説明付けることが実際に必要になってきます。
重要度の順序
度合いの順序とも言われるが、単純に言うと何かをグループ化した時に、成し遂げたい結果を得る為に必要なものを、重要さで順序付けることだ。
例えば、あるシステムを開発中、以下の問題が複数発生した。しかし全てを解決する余力はチームにない場合、どうすればよいか。
- A機能で、次処理に行けない不具合が発生
- B機能で、不適切なデータを作成してしまう不具合が発生
- C機能が、作成できていない
上記の問題だけでは、何が重要かを判別できない。そのため重要かを判別するための情報を整理することが大事となる。
全体のフローで見た場合、A機能、B機能はC機能で作成されるデータがあってはじめて実行可能な機能となる。そこでC機能を優先して作成し、次に次処理へ行けない、という問題の大きいA機能を着手し、最後にB機能に着手する。
上記のような整理が重要度の順序である。問題の根本的な重要度は何か、を適切に整理することで論理的に整理することだと思う。
自分の考えを正確に配置することについて復習できたと思う。これらの順序付けは、通常無意識に行っていることが多いと感じる。論理性を持った説明が常にできるよう、意識的に行っていきたい。
