Some of slide contents are a bit old idea due to recent agile movement. It should be updated according to ITIL4.
English Translation and Revised Version is there
https://www2.slideshare.net/YukoSoma/use-cases-for-iso200001-based-on-itil-in-english
17. アウトソーシングとインソーシング
ケーススタディ MALC 8の要約：
① 全てのシステムを自社開発し、運用してきたが、変更要求の増加、ハードウェア、ソフトウェアの種類の多さと進
歩の早さから、対応の遅れもでてきて、コストも増加している。
② 情報システム刷新プロジェクトは、これらを改善し、アウトソーシングを視野入れることを考えだした。
③ これを機に、情報子会社を設立して、社長になろうと思う。情報子会社が設立できなくても、コスト削減の成果が
認められればが、CIOになれるかもしれない。
要望：
アウトソーシングとインソーシングのメリット、デメリットを明らかにして、バランスよく取り入れて、周囲を納得させる
方法をITILを例に教えてほしい。
解決へのステップ:
ステップ1 サービス提供戦略を考える。
Yuko Soma – Case 8 - 1 ここが、プレゼンの始まりです。
ソーシング構造 メリット デメリット
インソーシング ① 直接的なコントロール
② 選択の自由
③ 熟知した方針、または、プロセス
④ 企業固有のナレッジ
① 規模の制限
② 外部から容易に入手可能なサービスに対
するコスト
アウトソーシング ① 規模の経済
② 専門知識の購入
③ 一時的なニーズに対する支援
① 比較的直接的でないコントロール
② サプライヤの破綻リスク
③ ガバナンスと妥当性確認の増大
マルチソーシング ① 市場投入までの期間
② 専門知識の活用
① プロジェクトの複雑化
② 知的財産権、および著作権の保護の課題
③ 企業間カルチャの衝突の可能性
（＊この図は、ITILコア書籍をもとに、カスタマイズしたものです。）
17
18. アウトソーシングとインソーシング
ステップ2 ソーシング戦略を考える
スッテプ3 変更管理の課題、リスクに対するソーシング・ソリューションを考える
結論：
① サービス提供戦略と、ソーシング戦略を組み合わせて、計画をたてる。
② 計画は、ビジネス・ケースを作成して、具体的なROIを出して、定量化する。
③ 最終的には、企業のカルチャ、サービス・ポートフォリオの複雑さ、能力、スキルセット、力量などを考慮して、決
定する。
Yuko Soma – Case 8 - 2
ここが、プレゼンの終わりです。
ソーシング構造 例
ローカル・ソーシング ベンダー契約をし、オフィスに常駐してもらう
マルチショア・ソーシング APAC, EMEA, North Americaに、サービスデスクを配置
ニアショア・ソーシング 大連市にカスタマー・センターをつくる
オフショア・ソーシング デンマークに開発センターと製造工場をつくる
課題 ソーシング・ソリューション
① RFCが増加している インソーシングのままのほうが、変更管理がしやすい。
② ハード・ソフトの種類が多すぎる ローカル・アウトソーシングで、アセット管理してもらう
③ ハード・ソフトの進歩が早すぎる オフショア開発アウトソーシングで専門知識の購入
（＊この図は、筆者が考案したものです。）
（＊この図は、筆者が考案したものです。）
18
20. 議論をしたにもかかわらず、ビジネスが失敗した原因
② 緊急出版を行なう前に、RACIマトリクス通りに、変更許可が実施されていたのか？
結論：
① 投資リスクの高い案件については、取締役会の承認が必須である。
② 緊急出版の是非について、取締役会役員に、RFCの提出→相談→報告されていなかった可能性が高い。
Yuko Soma – Case 9 - 2
ここが、プレゼンの終わりです。
プロセスの役割 顧客 変更の
要求元
変更の
実行者
変更マ
ネー
ジャ
CAB ECAB 担当
役員
取締
役会
リスクレベルを決定する n/a C AR
リスクレベル5 – 標準的な変更
現場の許可
n/a C RI A
リスクレベル4 – 低リスクの変更
変更マネージャの許可
n/a C RI A
リスクレベル3 – 現場またはサービ
スのグループにのみ影響がある
n/a C AR CI
リスクレベル2 - 複数のサービスま
たは事業部に影響がある
n/a C AR C CI
リスクレベル1 – 高コスト、高リスク
の変更（アセスメントのため、RFC を
取締役会へ）
n/a C AR CI
（＊この図は、筆者がITILコア書籍の図を、カスタマイズしたものです。）
20
21. 技術的な問題か、人為的な問題かの切り分け
ケーススタディ MALC 10の要約：
① 取り扱う生鮮食品の廃棄率が高くなっている。
② 流通経路で、気がついた時点で、部門や委託先が、廃棄することになっており、良品の中に紛れるリスクと運用
コストが余計にかかるリスクを低減している。
③ 生鮮食品の包装を変更して、廃棄率が減少するはずであったのに、なぜか増えており、流通経路で足りなくなり、
とうとう、納品できないという事故が起きた。
要望：
技術的な問題だったのか、人為的に不正が行なわれていたのか、ITILを用いて、切り分けて、解決策を提示してほしい。
解決へのステップ:
ステップ1 矛盾が生じているのはなぜか、以下の用法で、技術的ミス（廃棄率測定ミス）を疑ってみる。
Yuko Soma – Case 10 - 1 ここが、プレゼンの始まりです。
① このデータをどのように収集したか？ 50人のリモート在庫担当スタッフが入力 ○
② 誰がデータを収集したのか？ 在庫管理担当の短期派遣スタッフ、John △
③ データを収集するために、使用したツールは？ Salesforce.com ○
④ 誰がデータを処理したのか？ 在庫管理マネージャの新人、Sara △
⑤ どのようにデータを処理したのか？ ただ、所定のボタンをクリックしただけ。 △
⑥ 正しくない情報につながった要因は何? 要分析 △
（＊この図は、筆者が考案したものです。）
21
23. 戦略的計画立案
ケーススタディ MALC 12の要約：
① 中韓の同業他社の追い上げが激しく、主力製品の低価格競争に巻き込まれている。
② 新製品の開発スピードが他社と比較して遅くなっているようだが、何が問題なのか、定量化できていない。
③ アイディアはあるが、改善コストがかかるのと、数多くのファクターが絡むため、改善の決断もできていない。
要望：
自社開発、自社生産、自社販売網でビジネスを行なってきたが、これからもこれでいいのか、ITILに基づいて、解決
策を提示してほしい。
解決へのステップ：
ステップ1 SWOT分析を行い、自社製造主義を変えないメリット、デメリットを知る。
Yuko Soma – Case 11 - 1
ここが、プレゼンの終わりです。
強み：
① 独自の生産、販売ルートがある。
② 新製品を開発する力がある。
③ 10もの事業ユニットのノウハウが利用で
きる可能性がある。
脅威：
① 中国、韓国の競合他社の追い上げが激しく
なって来た。
② 中韓の低価格競争に巻き込まれている。
機会：
① 中国、韓国などの海外市場が大きい。
② 円安で、中韓への輸出がしやすい。
弱み：
① 新製品の開発スピードが十分とは言えなくなっ
て来た。
② 投資が数値化されていない。
③ 10の事業ユニットのノウハウが利用しきれて
いない。
（＊この図は、筆者が考案したものです。）
23
24. ステップ2 自社製造から、アウトソース製造に切り替えた場合のビジネス・ケースを作成し、投資利益率(ROI)を
見る。
結論：
SWOT分析の後、製造をタイにアウトソースした場合のビジネス・ケースと、日本国内で自社製造のままの場合
のビジネス・ケースを作成し、比較検討し、意思決定をする。
Yuko Soma – Case 11 - 2
ここが、プレゼンの終わりです。
戦略的計画立案
戦略的カテゴリ 低コストで製造された、競争力のある製品の導入
A. 序章 （事業目標の提示） 自社製造主義から、タイでのアウトソース製造に切り替えて、より競争力のある製品を提供する。
B. 方法と想定事項（ビジネ
ス・ケースの境界定義）
対象： 補聴器製造部門
実施時期： 2015年6月〜
組織的背景： 価格競争が激しくなっている今、コストがかかるのに、今後も引き続き、自社開発、
自社製造、自社販売網でビジネスをしていいのかが問われている。手始めに、製造だけでも、アウ
トソースできないかというアイディアが役員会で持ち上がった。
C. 事業へのインパクト(財
務的、および財務以外の結
果)
① アウトソース先とのナレッジ共有のための導入コスト 1000万円
② アウトソース先への教育コスト 2000万円
③ アウトソースにより、100人分の人件費を削減 2000万円
④ アウトソースにより、製造コストの削減 1000万円
結果：
・ 財政面 - ROIは、3000万円/3000万円=1.0
・ 非財政面 - より効果的なマーケティングに従事する能力。調達と保管のコスト削減につながる、
より優れた在庫レベルの予想。アウトソース製造による顧客ロイヤルティの低下。
D. リスクと緊急事態
（別の結果が発生する確
率）
① カルチャの違いによる失敗リスク 発生確率10%
② 自然災害による製造遅延リスク 発生確率20%
③ 突然の退職、欠勤、デモのリスク 発生確率5%
E. 推奨事項（具体的措置） 自社製造のままでいった場合のビジネスケース作成で、比較検討する。
（＊この図は、筆者が考案したものです。）
24
40. アクセス権の変更のトリガと、アクセス管理者の責任
問2: アクセス管理者の責任を明確にする方法
① 事業関係管理が、法務部からの要望により、アクセス・コントロールについてのビジネス・ケースを作成
する。
② サービス・ポートフォリオ管理が、アクセス・コントロールについての、サービス・モデルを作成して、SDサ
イクルに渡す。
③ デザイン・コーディネーションが、サービスの妥当性確認およびテストに、サービスデザインパッケージを
渡す。
④ アクセス管理者の責任が記載された文書をSOマネージャに渡し、サインさせる。
まとめ：
① アクセス管理は、どのITサービスに誰がアクセスするかに対して、決定権は持っておらず、全て、情報セ
キュリティ管理プロセスの方針に基づいて、代行しているにすぎない。
② 今のままでは、コンプライアンス違反なので、まずは、アクセス管理についての、サービス要求モデルを
作成し、グループを作成し、サービスディレクトリに反映し、アクセスをモニタリングし、定期的に、アクセス管
理について、測定すべきである。
③ コンプライアンスの徹底が、事業目標なので、できるだけ、自動化すべきであり、セキュリティ・インシデ
ントに備えて、アクセス管理は、インシデント管理との連携が必須である。
Yuko Soma – Case 9 - 2
ここが、プレゼンの終わりです。
ビジネス・ケース
サービス・モデル サービス・デザイン・
パッケージ
アクセス管理者の責任
が記載されたドキュメント
一式
（＊この図は、筆者が考案したものです。）
40
41. イベント管理とインシデント管理の関係
ケーススタディ OSA 10 の要約：
イベントの種類について、イベントとインシデントとの関係を、お弁当作りを例にして、説明してほしい。
ITILの基礎： イベントとは・・・
① イベントには、下図の3種類があり、右にいくほど、対処が必要な、重要なイベントである。
② 通常、バッチのスケジューリング、テープ・バックアップ、ストレージ容量チェック、可用性レベルなど、イン
フラストラクチャ全体のイベントをモニタリングする必要があるため、サービスデスクだけでなく、IT運用管理に
も関係が深い。
Yuko Soma – Case 10 - 1 ここが、プレゼンの始まりです。
情報イベント
例外イベント警告イベント
a) スケジューリングされた作業負荷
が完了した。
b) ユーザがアプリケーションを使用
するためにログインした。
c) 電子メールが対象とされた受取人
に届いた。
a) サーバのメモリ使用率が、許容
可能なパフォーマンス・レベルの上限
5%以内にまで達している。
b) トランザクションの完了に、通常
より、10%長い時間がかかっている。
a) ユーザが不正なパスワードで、
アプリケーションにログオンしようとした。
b) ビジネス・プロセスで、事業による
更なる調査を必要とする、例外を示す異常
な状況が発生した。
c) 装置のCPUが、許容できる使用率を
超えている。
d) トランザクション処理が終わらない。
ご飯 メインの海老フライどうでもよいパセリ
低 重要度 高
（＊この図は、筆者が考案したものです。）
41
42. イベント管理とインシデント管理の関係：
① 海老フライは、必須の”例外イベント”として、インシデント管理にエスカレーションされる。 ② ご飯である”警告
イベント”がインシデントなる可能性は、めったにないが、あれば欲しい。 ③ どうてもよいパセリの”情報イベント”は
無視してよい。
まとめ：
① ITSMツールの設計で、適切なフィルタリングのレベルを設けると、人の介入が減り、コストを最小化できる。
② すべてのコンポーネント(CI)を、イベント管理に組み込むように、ITSMを設計する必要がある。
③ イベント管理の自動化は、サービスデスクだけでなく、IT運用管理の仕事にも必須である。
④ イベントは、種類によっていつまでの保存が必要か、コンプライアンスなどの利害関係者と話し合う。
Yuko Soma – Case 10 - 2
ここが、プレゼンの終わりです。
イベント管理とインシデント管理の関係
例外イベント
フィルタリング
情報イベント
インシデント管理
イベント管理
フィルタリングの
設定次第では・・・・
無視
最低限、メインの海老フラ
イがないと・・・ 可能であ
れば、ご飯も！
参考程度
ITSMツール：インシデン
ト・チケットが自動起票さ
れ、SDキューにアサイン
される。→要「人の介入」
ITSMツール： インシデント・
チケットは自動起票され、
自動的にクローズされる。
イベント イベント イベント
警告イベント
（＊この図は、筆者が考案したものです。）
42
44. サービスデスクの形態と欠点について
ステップ1 問題の把握と解決案の策定
問題： オフショアでのサービスデスクを考えているが、その欠点があれば、回避したい。
解決策： 4種類の組み合わせとなる。
ステップ2 以下のようなサービスデスク組織を作る。
「サービス品質とカルチャにおける一貫性と画一性を確保するために、実現手段が必要になる」という欠点をカ
バーするには ・・・
① 日本語話者の人口が多く、人件費の安価な地域に、ニアショア先を見つける。
② 日本カルチャとサービス品質のトレーニングを計画する。
③ 一貫性をもたせるため、全ての詳細なドキュメントを用意する。
④ ITサービスマネジメントツールを導入して、日本へのエスカレーションの仕組みをつくる。
ステップ3 欠点がカバーできているかレビューし、改善する。
結論：
① どの形態のサービスデスクにも欠点はあるので、利点のほうが上回ればそれでよい。
② 特にニアショア化には、トレーニングとツールの導入と適切な運用に重点をおかなければ、かえってユーザ
の満足度が下がる。
Yuko Soma – Case 13 - 2
ここが、プレゼンの終わりです。
44
45. BCPの策定
ケーススタディ OSA 15 の要約： 以下を、ITILで解決してほしい。
① 企業合併の秘密が漏洩してしまった。
② 緊急役員会議で使う、今回の情報漏洩事故に対処する、短期的な対策と、長期的な対策を作成してほしい。
解決へのステップ：
ステップ1 問題の把握と、解決案の策定
問題： 情報漏洩事故が起きたときの対応策がなかった。
解決案： 今回は、事業顧客を巻き込んで、対処する必要がある。
ステップ2 短期的な対応、中期的な対応、長期的な対応をとる。
短期的な対策：
直ちに、機密情報をネットワーク接続から退避させ、その部屋への、外部からの物理的な侵入を禁止する。
中期的な対策：
① 機密情報が入っていたマシンへのアクセス履歴を調べる。
② 外に漏洩しているデータが他にもないか、技術管理プロセスのメンバーに調べてもらう。
③ ビジネス・インパクト分析、リスク分析を行ない、事業への影響と損害を算出する。
Yuko Soma – Case 15 -1 ここが、プレゼンの始まりです。
45
46. BCPの策定
Yuko Soma – Case 15 - 2
ここが、プレゼンの終わりです。
長期的な対策：
① BCPを策定する。
② ITSCMを導入する。
③ 情報セキュリティ管理を導入し、セキュリティ方針を作成する。
④ アクセス管理を導入し、効率的に、ユーザID認証、アクセス許可、ユーザIDステータス追跡を行なう。
ステップ4 プロセスをレビューし、必要に応じて、改善する。
結論：
① BCMが無かったことが、今回の事業存続の危機となったことを、CEOは、十分反省する。
② 全ての用意ができたら、インシデント管理、アクセス管理は、それに従って、連携して、サービス・オペレー
ション業務を行なう。
d) アクセス付与
の自動化
a) モニタリング・
ツールの導入
c) ディレクトリ・
サービス技術の導入
b) 役割カタログ
の導入
e) 人事部
との連携
（＊この図は、筆者が考案したものです。）
46
54. 比較： PDAのどこに重点を置くかで下図の違いがでる。
重要なポイント:
① Pに重点を置いた場合は、改善すべき点が最小化される。
② 反対に、Aに重点を置いた場合は、改善すべき点が多く、コスト高になり、時間もかかってしまう。
③ これでは、事業顧客の合意も得られないし、満足度も得られない。 よって、コストを正当化できない。
まとめ:
リリース後のトラブルを防止するためにも、いくつもで、改善点を出すのではなく、リリースに着手する前に、P
の計画段階で、リリース中、リリース後のトラブルを防止しなければ、大きな事故を防ぐことが難しい。
Yuko Soma – Case 4 - 2
リリース管理と展開管理のプランの重要性について
ここが、プレゼンの終わりです。
Pに重点を置いた場合
Aに重点を置いた場合
計画立案
計画立案
実 施 測定・レビュー 改 善
実 施 測定・レビュー 改 善
改善すべき点
P
P
D
A
C
C
A
効率的で、改善コストを最小化！
手戻りが多くなり、改善コストも膨大に・・
改善すべき点
（＊この図は、筆者が考案したものです。）
54
D
改善すべき点
改善すべき点
55. サービスの妥当性確認およびテストによる、DBの遅延
原因の特定と、変更評価による、評価方法
ケーススタディ RCV 5 の要約：
① 多品種、多数の原産地などの複雑な情報をDBに一元化したが、この事業のVBFとなるDBのユーザ
サービスに遅延が発生してしまっており、事業の存続にかかわる問題となっている。
② その原因となる要素を特定し、その要素の評価基準を、ITILに基づいて設定してほしい。
解決策:
ITILの妥当性確認およびテスト・プロセスを導入し、変更がある場合は、リリース管理および展開管理とは
中立の立場で検証することにより、インシデントの原因となる要素を特定し、変更評価プロセスにより、4つ
の評価レポートを提出して、評価すべきである。
ITILの基礎: 妥当性確認およびテスト・プロセスとは・・・・・
① サービスの品質保証を行ない、有用性を提供することの妥当性を確認する。
② テスト・プロセスの実施により、エラー、リスクを識別する。
解決へのステップ:
ステップ1 問題の把握と利害関係者の特定
現状：
① VBFとなるDBのユーザサービスに遅延が発生。
② 協力企業のユーザと、消費者が被害を受けており、事業顧客の存続が危ぶまれている状態。
Yuko Soma – Case 5 - 1 ここが、プレゼンの始まりです。
55
