「運用改善」を考える〜「自動化」を考える前に

Operation Lab運用設計ラボ

「運用改善」を考える運用設計ラボ合同会社シニアアーキテクト波田野裕一

2015-06-23

～「自動化」を考える前に


本資料について

• 本資料は2015年6月23日時点のものです。

• 今後、内容が大幅に変動する可能性があります。

• 本資料の内容は、運用設計ラボ合同会社の活動に基づくもので、全ての文責は運用設計ラボ合同会社に帰すべきものです。


序. 「運用」とは

まとめ


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

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

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

顧客・外部サービスoutboundinbound

outboundinbound

外部支援組織inbound

inbound

運用メンバーoutboundinbound

内部協調/支援組織inbound

outbound

リクエストデリバリ

デリバリ

デリバリ

デリバリ

リクエスト

リクエストリクエスト

運用現場

窓口フロントエンド

バックエンド

outbound

outbound


「運用」を「サービスデリバリ」と捉える

Quality

Cost

Delivery

品質という価値観

時間という物性

金額という物性

• 「サービス」視点で物事を考えるようになる

• 「デリバリ」視点で定量評価が可能になる

• 専門性(サービスとデリバリ)が明確になる

ユーザサービスデリバリ


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

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

運用方法論

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

「デリバリ」の専門集団

「サービスデリバリ」に求められる2つの専門性

運用現場には、専門集団として2つの側面がある

目的

手段

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

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


サービスとは何か?

全ての業務は「サービス」と捉えることができる

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


目的

• エンドユーザの課題を解決すること

• 社内ユーザの課題を解決すること

• 誰かの課題を解決することを(間接的に)支援すること


サービスとは何か? (利用者視点)

• 丸投げ: 代わりにやってもらう

• 半投げ: 手伝ってもらいながら自分でやる

• 丸被り: 自分でやる (自己責任)

(利用者視点)


目的



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

• SaaS: 代わりにやってもらう

• PaaS: 手伝ってもらいながら自分でやる

• IaaS: 自分でやる (自己責任)

費用型

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

(利用者視点)

(利用者視点)

丸投げ

半投げ

丸被り

丸被り


目的



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

• SaaS: 代わりにやってあげる

• PaaS: 専門性や基盤で支援してあげる

今後: サービス(課題解決)指向運用へ(提供者視点)

従来: プロダクト指向運用手段の提供(コストセンター扱い)

道具のお守り


目的



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

今後: サービス(課題解決)指向運用へ

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

(提供者視点)

考

作展

ユーザ

稼サービスの根幹は

稼ぐ人考える人

それを支える作る人展げる人

Ops

Dev

Deploy QA

営業

事業戦略、運用設計

サービス運用現場

サービス開発(支援)

リリースマネジメント+営業


目的


デリバリとは何か?

サービスを安定的合理的に提供すること

• 高度な反復性、再現性が求められる業務活動。

• 独自性よりも安定性、合理性が価値を持つ業務活動。

• 定量評価による合理性検証を前提とした業務活動。

全ての定常業務は「デリバリ」と捉えることができる


手段


まとめ: 「運用」とは

目的サービス価値 (経営、実務)

エンジニアリング価値 (生産工学)ユーザ


経営論誰が見ても

同じ「運用」へ

運用方法論

手段サービス価値を支える価値の提供

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

「運用」の本質は「価値の提供」価値を提供できれば「手段」は何でも良い


これからの「運用」




経営論誰が見ても

同じ「運用」へ

運用方法論


どちらの価値も重要だが……

サービス価値が無いと「運用」の存在意義がない利用者の「課題」を解決できない

X

独自色標準化、スケーラビリティ


1. 「運用改善」は成功するか?

「運用改善」は「成功」するのか?


経験的に「だいたい失敗する」

実施直後は「改善効果」を実感できる、、、、が数ヶ月～1年経過すると、次の「運用改善」が必要な状態に

• 場当たり的な「改善」の実施

• 客観的な「到達点」の不存在

• 「効果測定」の曖昧さ

とある伝説の改善事例

正社員の仕事をアウトソースチームに移転させて、正社員の工数削減


正社員

アウトソースチーム正社員

正社員

正社員の工数削減効果により表彰

1期目負荷が高い…



正社員

正社員

正社員 2期目

アウトソースチームの工数削減効果により表彰

アウトソースチームに移転させた仕事の負荷が高いので、正社員が実施するように戻してアウトソースチームの工数削減

負荷が高い…

アウトソースチーム

典型的な局所最適化のワナ実は何も改善されていない



正社員

正社員

正社員

表彰 (2回目)

表彰 (1回目)工数の押し付けあい

アウトソースチーム



意外と笑えない

部署毎の別々改善

局所最適化のワナ事業自体は改善されない

部署間インタフェースの不整合

内部工数削減

内部の工数減、依頼側の工数増

各部署毎に別々に改善した結果


他部署

依頼方法変更依頼が大変…




他部署

局所最適化のワナ

処理待ち…

優先順位の不整合

内部工数削減内部作業

依頼作業ボトルネック

事業に重要ではないところにリソース傾注

事業自体は改善されない




意外と笑えない

部署毎の別々改善工数の押し付けあい

部署間インタフェースの不整合優先順位の不整合


「運用改善」の成功要因1. 全体最適化

• 受注から納品までの期間が短縮した。 • 納品遅れによる失注がゼロになった。 • 関係部署との連携が向上し、工数が激減した。

事業全体での「最適化」がカギ

自部署以外に改善効果が波及する事が重要効果が波及しないものは優先順位が低い

(例)


「運用改善」の成功要因2. 客観化

• アラートメールが減った (数百万通->数万通/年) • 成果に必要な工数(時間)が減った (2時間->10秒) • 部署間調整に必要な時間が減った (40人日->8人日)

「客観化」がカギ

「誰がどう見ても同じ数字や事実」で Before/Afterを示すことが重要

(経験的に)

(例)

• 場当たり的な「改善」の実施 • 客観的な「到達点」の不存在 • 「効果測定」の曖昧さ

「運用改善」は「成功」するのか?


事業全体を客観的に改善しないと意味がない

客観化

• 局所最適化のワナ事業全体での最適化

必須

必須自己満足におわってしまう

「運用改善」の成功要因3. 変化に耐える


実施直後は「改善効果」を実感できる、、、、が数ヶ月～1年経過すると、次の「運用改善」が必要な状態に

常にチューニングできる余地を残しておく必要がある

「運用改善」には、あらかじめ「変化への対応」を織り込んでおく必要がある。

環境の変化実務との乖離想定外の事象

事業全体を客観的に改善しても、硬直的だと…

• 場当たり的な「改善」の実施 • 客観的な「到達点」の不存在 • 「効果測定」の曖昧さ

整理:「運用改善」を「成功」させるためには


Before/Afterを明確に

AsIs(現状)を明確に

ToBe(理想)を明確に

「全体最適化」と「客観化」が成功の要因

• 局所最適化のワナ • 事業全体での最適化

• 客観化

• 「改善効果」が短命 • 「変化」を意識

「変化」を前提とすることが改善効果の維持につながる

成功の要因「だいたい失敗する」

まとめ:「運用改善」成功の要因


Before/Afterを明確に

AsIs(現状)を明確に

ToBe(理想)を明確に

• 事業全体での最適化

• 客観化

• 「変化」を意識

「根本的にやり方を考えなおす」ことが恒常的な「運用改善」につながる


2. ビジネスと「運用改善」～運用の「サービス」価値を考える


「運用改善」とは

「運用の価値」を現状よりも高めるための改善活動

ToBe (理想)

AsIs (現状)運用改善「誰がどう見ても同じ数字や事実」

でBefore/Afterを示す

事業全体での最適化

客観化変化を意識環境の変化想定外の事象

改善効果が自部署以外に波及する事が重要


「運用改善」に「銀の弾丸」は存在しない

合理的・客観的に着実に進める必要がある。

業務を根本的に見直す必要がある。一足飛びに実現することは難しい。

一足飛びに実現が不可能、ということは実現できた場合、圧倒的な強みになる。

「運用の価値」を現状よりも高めるための改善活動


See

Do

運用改善はPDSサイクルで (日本の現場)

現場主体の自主サイクル

ToBe (理想)とAsIs(現状)のギャップ解消のためのサイクル

ギャップの確認

ギャップの評価Plan

ギャップの縮小


See

Do

Plan

「客観化」から着手して、AsIsを知るのが最初の作業

データに基づく客観的、論理的な改善サイクル

客観化構造化

データの蓄積

AsIs ToBe

AsIsとToBeのギャップを埋める

「誰がどう見ても同じ数字や事実」でBefore/Afterを示す

理想と現実の差分を明確にする

現実を理想に近づけるためのロジックを明確にする

運用改善におけるPDSサイクル


「運用改善」が必要な状況とは

• サービス価値の低下

• 処理能力の低下

• アジリティ(経営戦略への追随能力)の低下

運用の「価値」が低下している(可能性がある)状況



もしくは運用の「価値」を向上させることができる(可能性がある)状況


ユーザ価値の提供サービス価値

(経営、実務)


経営者

事業戦略

「サービス価値の低下」はなぜ発生するか

サービスへの期待と実際の価値に乖離があるToBe (理想) AsIs (現状)

AsIs (現状)

ToBe (理想)

経営環境の変化も大きく影響

需要との乖離

事業戦略との乖離

「外部との乖離」


他部署

局所最適化のワナ

処理待ち… 内部作業

依頼作業

内部情報は豊富

「外部との乖離」の発生要因1. 情報の不均衡外部からの情報と運用現場内部の情報の不均衡が原因

内部情報に基づいて優先順位付け

優先順位の不整合の例外部情報は欠乏気味

外部からの情報 (事業戦略、ユーザニーズ) < 内部情報 (組織内の力関係を含む)


他部署

局所最適化の習性

処理待ち…

内部の最適化を求める

「外部との乖離」の発生要因2. 組織の本能一般的に組織は「自己目的化」「自己最適化」する

内部の効率、快適性、人間関係

事業への貢献は後回し

外部への適応 < 内部の最適化

内部の効率UP

快適な職場、人間関係


自分の仕事しか考えない

自分の仕事しか考えないユーザ

価値の提供

経営者

事業戦略

需要との乖離




局所最適化

まとめ: 「外部との乖離」の発生要因

外部への適応 < 内部の最適化外部からの情報 (事業戦略、ユーザニーズ) < 内部情報 (組織内の力関係を含む)



自分の仕事しか考えないユーザ

価値の提供

経営者

事業戦略

需要との乖離


「外部との乖離」はなにをもたらすか

組織硬直化

顧客の離脱

経営の危機



他に移ろう

給料払えない… 局所最適化


ユーザ価値の提供

経営者

事業戦略

全体最適化指向

「外部との乖離」を回避するためには

組織が主体発生要因2. 組織の本能

発生要因1. 情報の不均衡

社内情報の平衡化+

事業への最適化を求める


事業が主体


「外部との乖離」を回避するためには

発生要因1. 情報の不均衡

発生要因2. 組織の本能

組織内外での情報の均衡を図る。

「組織が主体」から「事業が主体」への転換。経営環境の変化にあわせて組織構成は変わる。

社内情報の平衡化

全社共通マスターの整備「全体最適化」指向の情報管理

情報管理も、組織単位ではなく、事業単位。




ユーザ価値の提供

経営者

事業戦略

まとめ: 「外部との乖離」を回避するには

事業への最適化

「事業(全体)への最適化」を常に実現する必要がある


3. 運用改善による「事業への最適化」


「事業」とは何か

対価を得て、社会的意義のある価値を提供すること。

社会的意義のある価値を提供すること。

対価を得ること。

主目的

副次的な目的事業を維持するために必要

「逆になると顧客は逃げる」とよく言われます○ 価値を提供して、お金を貰った (給料増えます)× お金が欲しいので、何かをする (給料増えません)個人の場合



価値の提供

事業戦略

「事業」を取り巻く環境

社員

実践する人経営者

考える人

ユーザ

使って払う人

事業の遂行

価値の創成



ユーザ

経営者


考える人

実践する人

使って払う人

社員市場変化

事業戦略と遂行

評価と対価



ユーザ

経営者

市場の変化 (経営者 vs. ユーザ)

考える人

使って払う人

市場変化

戦略が変わり続ける時代

需要が変わり続ける時代

需要と供給の乖離が簡単に発生するようになった

長期契約がリスクとなる時代

長期戦略が意味を持たない時代失敗を覚悟した短期戦略へ

サービスの離脱率向上へ

ユーザはきまぐれ供給側の都合には付き合ってくれない



経営者

経営との乖離 (経営者 vs. 社員)

考える人

実践する人

社員

事業戦略と遂行戦略が変わり続ける時代

オペレーションのアジリティが企業の命運を決める

事業戦略とオペレーションの乖離が企業の致命傷になる時代になった

失敗を覚悟した短期戦略へ長期戦略が意味を持たない時代

経営の視点が求められる時代

敏捷性と柔軟性が価値

市場の変化に対応できない会社は潰れる



ユーザ

ユーザとの乖離 (ユーザ vs. 社員)

実践する人

使って払う人

社員評価と対価需要が変わり続ける時代

自分の給料分を稼ぐことができる人が限定される時代になった

サービスの離脱率向上へ長期契約がリスクとなる時代

ユーザの視点が求められる時代敏捷性と柔軟性が価値

給料の原資をはらってくれるのはユーザだけ


企業人は給料の4倍以上ユーザから稼がないと存在意義がない


ユーザ

経営者

「事業」を取り巻く環境 (全体像)

考える人

実践する人

使って払う人

社員





サービスの離脱率向上へ

失敗を覚悟した短期戦略へ

敏捷性と柔軟性が価値






ユーザ

経営者


社員








組織硬直化

顧客の離脱

経営の危機

局所最適化の結果

事業全体を客観的に改善しないと意味がない運用改善

経営との乖離

ユーザとの乖離



価値の提供

事業戦略

事業の構造 (ユーザや経営との乖離防止)

経営者

考える人

ユーザ

使って払う人

事業の遂行

価値の創成


社員実践する人

ビジネスドメイン (事業領域)

ビジネスメニュー (売上の対象単位)

オペレーションサービスカタログ

事業領域の宣言

ビジネスマーケット (市場)

遂行事業と売上要素の明確化

ビジネスサービスカタログ

ユーザとの接点の明確化

組織間の接点の明確化

現在の提供価値一覧未来の価値源泉一覧

全体最適化の実現

サービスチェーン


オペレーションサービスカタログ

サービスチェーン

現状の見える化が最優先See

外部との関係の客観化

AsIs(改善のBefore)を客観化する

客観化

中途メンバーが2営業日で事業の全体像を理解できるように客観化する

ビジネスドメイン (事業領域)カタログ

ビジネスメニュー (売上対象)カタログ

ビジネスサービスカタログ

事業領域の理解遂行事業と売上要素の理解

ユーザとの接点の理解

組織間の接点の理解

組織の提供価値の理解

事業の提供価値の理解


事業構造の見える化

ビジネスマーケット (市場)


まとめ


「運用」問題解決の構造

Phase2. 任務(mission)の客観化

Phase3. 実績(output)の客観化 Phase1. 期待(input)の客観化

経営論

運用方法論

費用対効果の見える化高負荷の解消

属人性の解消

運用の「価値」の拡大現場だけでやれることには限界がある

運用と経営は一体である

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

運用組織は分散協調である。運用業務は工程である。

まとめ


「運用」とはまとめ




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

運用方法論


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

「運用」の本質は「価値の提供」価値を提供できれば「手段」は何でも良い


「運用改善」とはどのような活動であるべきか

運用の「価値」の拡大

運用現場と「外部」との乖離の縮小、解消

影響大

運用現場「内部」での矛盾の縮小、解消


影響小 (相対的)




まとめ

事業全体での最適化

客観化

客観化

経営環境の変化を意識

想定外事象の発生を意識


参考: 「運用改善」の構造

Phase2. 任務(mission)の客観化

Phase3. 実績(output)の客観化 Phase1. 期待(input)の客観化

経営論

運用方法論

費用対効果の見える化高負荷の解消

属人性の解消

ToBe (理想)

AsIs (現状)

接近運用の「価値」の拡大「誰がどう見ても同じ数字や事実」でBefore/Afterを示す


事業全体での最適化運用現場と「外部」との乖離の縮小、解消

運用現場「内部」の矛盾の縮小、解消

影響大

影響小(相対的)

客観化客観化



経営環境の変化を意識

想定外事象の発生を意識

まとめ

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

運用組織は分散協調である。運用業務は工程である。


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

OperationLab運用設計

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

「運用改善」を考える 〜「自動化」を考える前に

Services

「運用改善」を考える〜「自動化」を考える前に