2015-03-27 ザ・運用～運用とは何か、運用とはどのようであるべきか

Operation Lab運用設計ラボ

ザ・運用運用設計ラボ合同会社シニアアーキテクト波田野裕一

2015-03-27オペレーションカンファレンス 2015 Spring

～運用とは何か、運用とはどのようであるべきか


「運用」とは何か


「運用」とは何か

実は、人によって概念が異なる。(現状)

運用

構成変更って運用?

部署間調整って運用?

調査研究って運用?

障害原因の追及って運用?


人によって概念が異なるので…

• 実は、運用現場は自分達を知らない • 何に苦しんでいるのか • 何が成果になっているのか (どうすれば評価されるのか)

• 「そこは運用で」と言われるとやらされざるを得ない • 本当の「運用」に工数と予算が行き届いていない可能性

• 日々の改善や将来に向けた布石ができずジリ貧に…

「運用」のたてつけがおかしい

そのもののもつ機能を生かして用いること。活用。(大辞泉)


運用研究から見えてきた「共通の悩み」

連載：現場視点からの運用方法論第1回見えない「運用」 - 疲弊する運用現場http://thinkit.co.jp/story/2010/12/02/1903


運用研究から見えてきた「現場共通の問題点」

1.高負荷

2.属人的

3.見えぬ費用対効果ブラックボックス化

低付加価値化

業務が複雑化

「費用」は一定で「効果」は経年劣化する「費用対効果」は勝手に低減していく

現場では制御不能状態


「現場共通の問題点」を整理

1.高負荷

2.属人的

3.見えぬ費用対効果やっていること(mission)が見えていない

成果(output)が見えていない

期待(input)が見えていない

• 実は、運用現場は自分達を知らない • 何に苦しんでいるのか • 何が成果になっているのか (どうすれば評価されるのか)


運用現場共通の問題点解決への道

やっていること(mission)の見える化

成果(output)の見える化

期待(input)の見える化高負荷の解消

属人的の解消

費用対効果の見える化


「運用設計」は理想と現実の橋渡し

1. 高負荷

2. 属人的

3. 見えぬ費用対効果

運用現場の現実

ブラックボックス化

低付加価値化

業務が複雑化

1. 業務の複雑化を許さない仕組み作り

2. 業務のブラックボックス化を許さない仕組み作り

3. 業務価値の陳腐化を許さない仕組み作り

運用設計の目的運用現場の理想

‣ サービスの安定社会基盤に相応しい安定運用。

‣ 業務負荷の平準化うまく業務が回る運用現場。

‣ 運用に対する評価の適正化適正な利潤を生む現場と、適切に評価される要員。

常にシンプル

常に見える

常に価値を生む

出典: Think IT 「現場視点からの運用方法論第2回自分たちの「運用」を知る - 運用設計の本質」(2010-12)



期待(input)の見える化

適切な「運用設計」で解決するはず


「運用設計」は理想と現実の橋渡し (再)

1. 高負荷

2. 属人的

3. 見えぬ費用対効果

運用現場の現実

ブラックボックス化

低付加価値化

業務が複雑化

1. 業務の複雑化を許さない仕組み作り

2. 業務のブラックボックス化を許さない仕組み作り

3. 業務価値の陳腐化を許さない仕組み作り

運用設計の目的運用現場の理想

‣ サービスの安定社会基盤に相応しい安定運用。

‣ 業務負荷の平準化うまく業務が回る運用現場。

‣ 運用に対する評価の適正化適正な利潤を生む現場と、適切に評価される要員。

常にシンプル

常に見える

常に価値を生む




実は「費用対効果」が最大の難問

適切な成果基準が必要

経営学視点


運用現場共通の問題点解決への道




適切な成果基準が必要

高負荷の解消

属人的の解消

費用対効果の見える化

運用設計

経営論

ここに着目して「運用」を再定義する必要がある


「運用」要件1. 費用対効果の説明可能化へ

「運用」の費用対効果が説明できない

費用に見合った効果のある「運用」

集約提供サービスリソース

サービス運用売上原価

運用にかかるコストを直接配賦し「売上原価」として貢献



「運用」要件2. 共通の「運用」という概念へ

「運用」のたてつけがおかしい

誰が見ても同じ「運用」へ

• 客観的に情報に基づく議論 • 科学的手法による分析 • 論理的手法による分析

やっていること(mission)の見える化期待(input)の見える化


では「運用」とは何か


仮説:「運用」とは「サービスデリバリ」である

リクエストに対するデリバリの繰り返し

顧客・外部サービスoutboundinbound

outboundinbound

外部支援組織inbound

inbound

運用メンバーoutboundinbound

内部協調/支援組織inbound

outbound

リクエストデリバリ

デリバリ

デリバリ

デリバリ

リクエスト

リクエストリクエスト

運用現場窓口フロントエンド

バックエンド

outbound

outbound

出典: 経営情報学会 2010年春季全国研究発表大会「運用業務プロセスのモデル化」



inbound outboundデリバリリクエスト売上原価

かかるコストを直接配賦し「売上原価」として貢献


経営論成果(output)の見える化




inbound outbound Quality

Cost

Delivery 時間という物性

金額という物性

品質という価値観

デリバリリクエスト

• 客観的に情報に基づく議論 • 科学的手法による分析 • 論理的手法による分析運用方法論

やっていること(mission)の見える化期待(input)の見える化


• 客観的に俯瞰することが可能 • 科学的手法による測定が可能 • 論理的手法による分析が可能


結論:「運用」とは「サービスデリバリ」である

inbound outbound Quality

Cost

Delivery 品質という価値観

デリバリリクエスト




時間という物性

金額という物性売上原価


かかるコストを直接配賦し「売上原価」として貢献

運用方法論経営論


• 社内のインフラ運用 • 依頼元部署へのサービスのデリバリと考える。 • 「道具のお守り」からの脱却

• アラート対応 • システムから「復旧リクエスト」が来たと考える。 • 「復旧というサービス」のデリバリという視点で考える。

参考:「運用」とは「サービスデリバリ」である


デリバリの変化で運用業務の変化を

認識可能

Platform as a Service

Service as a Service

Infrastructure as a Service

SaaS

PaaS

IaaS

上位に対してサービスをデリバリ

「運用」を「サービスデリバリ」と表現



ユーザ

運用業務全体にライフサイクル

の概念

運用最小単位にライフサイクル

の概念


「運用」とはどのようであるべきか


• 客観的に俯瞰することが可能 • 科学的手法による測定が可能 • 論理的手法による分析が可能


費用に見合った効果のある「運用」かかるコストを直接配賦し「売上原価」として貢献

運用方法論

経営論「サービス」の専門集団

「デリバリ」の専門集団エンジニアリング

(生産工学)

サービス価値の向上 (経営、実務)

前提:「運用」とは「サービスデリバリ」である運用現場には、専門集団として2つの側面がある

目的

手段


SaaS

PaaS

IaaS

「サービス」と「デリバリ」の2つが運用の価値

ユーザ

サービス価値

デリバリ価値

デリバリ価値

サービス価値X

= 運用現場の価値


エンジニアリング (生産工学)

目的

手段


SaaS

PaaS

IaaS

「サービス」と「デリバリ」のコスト構造

ユーザ

サービス価値

デリバリ価値



目的

手段

売上原価

売上


「サービス」と「デリバリ」のコスト構造

サービス価値

デリバリ価値



目的

手段売上原価

売上

良い「運用(サービスデリバリ)」を実現するにはバランスが重要

サービス価値の無い運用はコストセンター

デリバリ価値の無い運用は、要求の変化に対応する体力がない


SaaS

PaaS

IaaS

「サービス」の独自化と「デリバリ」の標準化

ユーザ

サービス価値

デリバリ価値



独自色が求められる領域

標準化、スケーラビリティが求められる領域

独自性と標準化の領域が明確に分かれていくただし、両方とも必要!

目的手段


SaaS

PaaS

IaaS

これからの「運用」 (ザ・運用)

ユーザ

サービス価値

デリバリ価値




標準化、スケーラビリティが求められる領域どの領域を

主戦場とするか?

目的手段


「デリバリー」の価値


SaaS

PaaS

IaaS

「デリバリ」の価値を考える

ユーザ

サービス価値

デリバリ価値


標準化、スケーラビリティが求められる領域

運用方法論

Howの比重が高い「手段」の世界規模の経済が働きやすい

Azure / AWS / GAE

Azure / AWS ..

下位レイヤーになるほど、スケーラビリティが必須

手段今回は割愛


参考: 「デリバリ」を「工程」として捉える

工場型モデル

• 手戻りに対する違和感 • QCDへの意識付け • 作業員保護機構の重要性 (セキュリティ強化)


「サービス」の価値


SaaS

PaaS

IaaS

「サービス」の価値を考える

ユーザ

サービス価値

デリバリ価値



経営論

Whyの比重が高い「目的」の世界規模の経済が働きにくいロングテール、スティッキー

目的


サービスとは何か?

• 丸投げ: 代わりにやってもらう • 半投げ: 手伝ってもらいながら自分でやる • 丸被り: 自分でやる (自己責任)

(利用者視点)

利用者の「課題」を解決すること


サービスとは何か? (クラウド時代)


• SaaS: 代わりにやってもらう • PaaS: 手伝ってもらいながら自分でやる • IaaS: 自分でやる (自己責任)

費用型

資産型• オンプレミス: 自分でやる (自己責任)

(利用者視点)

(利用者視点)


クラウド時代に求められるサービス


• SaaS: 代わりにやってあげる • PaaS: 専門性や基盤で支援してあげる

費用型 (提供者視点)


プロダクト指向運用からサービス指向運用へ

従来: プロダクト指向運用

今後: サービス指向運用へ

• SaaS: 代わりにやってあげる • PaaS: 専門性や基盤で支援してあげる

費用型 (提供者視点)

手段の提供(販管費扱い) 道具のお守り


「運用」とは「価値の提供」である

リクエストに対する価値の提供

顧客・外部サービスoutboundinbound

outboundinbound

外部支援組織inbound

inbound

運用メンバーoutboundinbound

内部協調/支援組織inbound

outbound

リクエストデリバリ

デリバリ

デリバリ

デリバリ

リクエスト

リクエストリクエスト

運用現場窓口フロントエンド

バックエンド

outbound

outbound


自前主義の終焉2つの側面で自前主義の時代は終焉

工場型モデル

全てのプロセスでセキュリティを守ることは不可能に

サービスプロセス

サービス基盤自前での価値は

産みにくくなった

自前で価値を産みだせる

全てのレイヤを自前で用意することが割に合わなくなってきた


工場型モデル

独自性(コアコンピタンス)とは関係ない工程をマネージドサービスに処理させる

自前でスケールできない基盤をマネージドサービスに任せる

運用のコアコンピタンスとマネージドサービス自前主義から、マネージドサービスの時代へ

サービスプロセス

サービス基盤自前での価値は

産みにくくなった

自前で価値を産みだせる


「運用」イコール「サービス」の時代へ「サービス」と「デリバリ」の両者を設計



コアコンピタンス

サブコンピタンス

マネージドサービス利活用

運用

3者のいずれも激しく変化しつづけるはず


まとめ


まとめ

• 「運用」とは「サービスデリバリ」である。 • 「サービス」という経営的な専門性 (売上) • 「デリバリ」という技術的な専門性 (売上原価)

• 「運用」の本質は「価値の提供」である。 • 決して「コストセンター」ではない

• 自前時代の終焉 • 価値の最大化のためにコアコンピタンスの明確化を • マネージドサービスの利用を前提とした時代へ


http://www.operation-lab.co.jp/

OperationLab運用設計

Engineering

2015-03-27 ザ・運用 ～ 運用とは何か、運用とはどのようであるべきか

2015-03-27 ザ・運用～運用とは何か、運用とはどのようであるべきか