Transcript

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