2015-03-27 ザ・運用 ～ 運用とは何か、運用とはどのようであるべきか
•
28 likes•6,795 views
日本MSP協会主催 オペレーションカンファレンス 2015 Spring (https://msevents.microsoft.com/CUI/EventDetail.aspx?culture=en-US&Even)で発表した「ザ・運用 ～ 運用とは何か、運用とはどのようであるべきか」の公開資料です。
Recommended
More Related Content
What's hot
What's hot (19)
Viewers also liked
Similar to 2015-03-27 ザ・運用 ～ 運用とは何か、運用とはどのようであるべきか
Similar to 2015-03-27 ザ・運用 ～ 運用とは何か、運用とはどのようであるべきか (20)
2015-03-27 ザ・運用 ～ 運用とは何か、運用とはどのようであるべきか
- 1. Operation Lab 運用設計ラボ ザ・運用 運用設計ラボ合同会社 シニアアーキテクト 波田野 裕一 2015-03-27 オペレーションカンファレンス 2015 Spring ∼ 運用とは何か、運用とはどのようであるべきか
- 3. Operation Lab 運用設計ラボ 「運用」とは何か 実は、人によって概念が異なる。(現状) 運用 構成変更 って運用? 部署間調整 って運用? 調査研究 って運用? 障害原因の 追及って運用?
- 4. Operation Lab 運用設計ラボ 人によって概念が異なるので… • 実は、運用現場は自分達を知らない • 何に苦しんでいるのか • 何が成果になっているのか (どうすれば評価されるのか) • 「そこは運用で」と言われるとやらされざるを得ない • 本当の「運用」に工数と予算が行き届いていない可能性 • 日々の改善や将来に向けた布石ができずジリ貧に… 「運用」のたてつけがおかしい そのもののもつ機能を生かして用いること。活用。 (大辞泉)
- 5. Operation Lab 運用設計ラボ 運用研究から見えてきた「共通の悩み」 連載：現場視点からの運用方法論 第1回 見えない「運用」 - 疲弊する運用現場 http://thinkit.co.jp/story/2010/12/02/1903
- 7. Operation Lab 運用設計ラボ 「現場共通の問題点」を整理 1.高負荷 2.属人的 3.見えぬ費用対効果 やっていること(mission)が見えていない 成果(output)が見えていない 期待(input)が見えていない • 実は、運用現場は自分達を知らない • 何に苦しんでいるのか • 何が成果になっているのか (どうすれば評価されるのか)
- 9. Operation Lab 運用設計ラボ 「運用設計」は理想と現実の橋渡し 1. 高負荷 2. 属人的 3. 見えぬ費用対効果 運用現場の現実 ブラックボックス化 低付加価値化 業務が複雑化 1. 業務の複雑化を許さない仕組み作り 2. 業務のブラックボックス化を許さない仕組み作り 3. 業務価値の陳腐化を許さない仕組み作り 運用設計の目的運用現場の理想 ‣ サービスの安定 社会基盤に相応しい安定運用。 ‣ 業務負荷の平準化 うまく業務が回る運用現場。 ‣ 運用に対する評価の適正化 適正な利潤を生む現場と、適切に評価される要員。 常にシンプル 常に見える 常に価値を生む 出典: Think IT 「現場視点からの運用方法論 第2回 自分たちの「運用」を知る - 運用設計の本質」(2010-12) やっていること(mission)の見える化 成果(output)の見える化 期待(input)の見える化 適切な「運用設計」で解決するはず
- 10. Operation Lab 運用設計ラボ 「運用設計」は理想と現実の橋渡し (再) 1. 高負荷 2. 属人的 3. 見えぬ費用対効果 運用現場の現実 ブラックボックス化 低付加価値化 業務が複雑化 1. 業務の複雑化を許さない仕組み作り 2. 業務のブラックボックス化を許さない仕組み作り 3. 業務価値の陳腐化を許さない仕組み作り 運用設計の目的運用現場の理想 ‣ サービスの安定 社会基盤に相応しい安定運用。 ‣ 業務負荷の平準化 うまく業務が回る運用現場。 ‣ 運用に対する評価の適正化 適正な利潤を生む現場と、適切に評価される要員。 常にシンプル 常に見える 常に価値を生む やっていること(mission)の見える化 成果(output)の見える化 期待(input)の見える化 実は「費用対効果」が最大の難問 適切な成果基準が必要 経営学視点
- 12. Operation Lab 運用設計ラボ 「運用」要件1. 費用対効果の説明可能化へ 「運用」の費用対効果が説明できない 費用に見合った効果のある「運用」 集約 提供 サービス リソース サービス 運用 売上原価 運用にかかるコストを直接配賦し 「売上原価」として貢献 成果(output)の見える化
- 13. Operation Lab 運用設計ラボ 「運用」要件2. 共通の「運用」という概念へ 「運用」のたてつけがおかしい 誰が見ても同じ「運用」へ • 客観的に情報に基づく議論 • 科学的手法による分析 • 論理的手法による分析 やっていること(mission)の見える化 期待(input)の見える化
- 15. Operation Lab 運用設計ラボ 仮説:「運用」とは「サービスデリバリ」である リクエスト に対する デリバリ の繰り返し 顧客・外部サービス outboundinbound outboundinbound 外部支援組織 inbound inbound 運用メンバー outboundinbound 内部協調/支援組織 inbound outbound リクエストデリバリ デリバリ デリバリ デリバリ リクエスト リクエストリクエスト 運用現場 窓口 フロントエンド バックエンド outbound outbound 出典: 経営情報学会 2010年春季全国研究発表大会 「運用業務プロセスのモデル化」
- 17. Operation Lab 運用設計ラボ 誰が見ても同じ「運用」へ 仮説:「運用」とは「サービスデリバリ」である inbound outbound Quality Cost Delivery 時間という物性 金額という物性 品質という価値観 デリバリリクエスト • 客観的に情報に基づく議論 • 科学的手法による分析 • 論理的手法による分析運用方法論 やっていること(mission)の見える化 期待(input)の見える化
- 18. Operation Lab 運用設計ラボ • 客観的に俯瞰することが可能 • 科学的手法による測定が可能 • 論理的手法による分析が可能 誰が見ても同じ「運用」へ 結論:「運用」とは「サービスデリバリ」である inbound outbound Quality Cost Delivery 品質という価値観 デリバリリクエスト やっていること(mission)の見える化 成果(output)の見える化 期待(input)の見える化 時間という物性 金額という物性 売上原価 費用に見合った効果のある「運用」 かかるコストを直接配賦し 「売上原価」として貢献 運用方法論経営論
- 19. Operation Lab 運用設計ラボ • 社内のインフラ運用 • 依頼元部署へのサービスのデリバリと考える。 • 「道具のお守り」からの脱却 • アラート対応 • システムから「復旧リクエスト」が来たと考える。 • 「復旧というサービス」のデリバリという視点で考える。 参考:「運用」とは「サービスデリバリ」である
- 20. Operation Lab 運用設計ラボ デリバリの変化で 運用業務の変化を 認識可能 Platform as a Service Service as a Service Infrastructure as a Service SaaS PaaS IaaS 上位に対してサービスをデリバリ 「運用」を「サービスデリバリ」と表現 上位に対してサービスをデリバリ 上位に対してサービスをデリバリ ユーザ 運用業務全体に ライフサイクル の概念 運用最小単位に ライフサイクル の概念
- 22. Operation Lab 運用設計ラボ • 客観的に俯瞰することが可能 • 科学的手法による測定が可能 • 論理的手法による分析が可能 誰が見ても同じ「運用」へ 費用に見合った効果のある「運用」 かかるコストを直接配賦し 「売上原価」として貢献 運用方法論 経営論「サービス」の専門集団 「デリバリ」の専門集団 エンジニアリング (生産工学) サービス価値の向上 (経営、実務) 前提:「運用」とは「サービスデリバリ」である 運用現場には、専門集団として2つの側面がある 目的 手段
- 29. Operation Lab 運用設計ラボ SaaS PaaS IaaS 「デリバリ」の価値を考える ユーザ サービス価値 デリバリ価値 エンジニアリング (生産工学) 標準化、スケーラビリティ が求められる領域 運用方法論 Howの比重が高い「手段」の世界 規模の経済が働きやすい Azure / AWS / GAE Azure / AWS .. 下位レイヤーになるほど、スケーラビリティが必須 手段 今回は割愛
- 30. Operation Lab 運用設計ラボ 参考: 「デリバリ」を「工程」として捉える 工場型モデル • 手戻りに対する違和感 • QCDへの意識付け • 作業員保護機構の重要性 (セキュリティ強化)
- 33. Operation Lab 運用設計ラボ サービスとは何か? • 丸投げ: 代わりにやってもらう • 半投げ: 手伝ってもらいながら自分でやる • 丸被り: 自分でやる (自己責任) (利用者視点) 利用者の「課題」を解決すること
- 34. Operation Lab 運用設計ラボ サービスとは何か? (クラウド時代) 利用者の「課題」を解決すること • SaaS: 代わりにやってもらう • PaaS: 手伝ってもらいながら自分でやる • IaaS: 自分でやる (自己責任) 費用型 資産型 • オンプレミス: 自分でやる (自己責任) (利用者視点) (利用者視点)
- 35. Operation Lab 運用設計ラボ クラウド時代に求められるサービス 利用者の「課題」を解決すること • SaaS: 代わりにやってあげる • PaaS: 専門性や基盤で支援してあげる 費用型 (提供者視点)
- 36. Operation Lab 運用設計ラボ プロダクト指向運用からサービス指向運用へ 従来: プロダクト指向運用 今後: サービス指向運用へ • SaaS: 代わりにやってあげる • PaaS: 専門性や基盤で支援してあげる 費用型 (提供者視点) 手段 の提供(販管費扱い) 道具のお守り
- 37. Operation Lab 運用設計ラボ 「運用」とは「価値の提供」である リクエスト に対する 価値の提供 顧客・外部サービス outboundinbound outboundinbound 外部支援組織 inbound inbound 運用メンバー outboundinbound 内部協調/支援組織 inbound outbound リクエストデリバリ デリバリ デリバリ デリバリ リクエスト リクエストリクエスト 運用現場 窓口 フロントエンド バックエンド outbound outbound
- 42. Operation Lab 運用設計ラボ まとめ • 「運用」とは「サービスデリバリ」である。 • 「サービス」という経営的な専門性 (売上) • 「デリバリ」という技術的な専門性 (売上原価) • 「運用」の本質は「価値の提供」である。 • 決して「コストセンター」ではない • 自前時代の終焉 • 価値の最大化のためにコアコンピタンスの明確化を • マネージドサービスの利用を前提とした時代へ