「運用改善」を考える ?「自動化」を考える前に
?
130 likes?16,777 views
本資料は2015年6月23日時点のものです。今後、内容が大幅に変動する可能性があります。 本資料の内容は、運用設計ラボ合同会社の活動に基づくもので、全ての文責は運用設計ラボ合同会社に帰すべきものです。
「運用改善」を考える ?「自動化」を考える前に
- 1. Operation Lab 運用設計ラボ 「運用改善」を考える 運用設計ラボ合同会社 シニアアーキテクト 波田野 裕一 2015-06-23 ～「自動化」を考える前に
- 2. Operation Lab 運用設計ラボ 本資料について ? 本資料は2015年6月23日時点のものです。 ? 今後、内容が大幅に変動する可能性があります。 ? 本資料の内容は、運用設計ラボ合同会社の活動に基づくもので、 全ての文責は運用設計ラボ合同会社に帰すべきものです。
- 4. Operation Lab 運用設計ラボ 「運用」とは「サービスデリバリ」である リクエスト に対する デリバリ の繰り返し 出典: 経営情報学会 2010年春季全国研究発表大会 「運用業務プロセスのモデル化」 顧客?外部サービス outboundinbound outboundinbound 外部支援組織 inbound inbound 運用メンバー outboundinbound 内部協調/支援組織 inbound outbound リクエストデリバリ デリバリ デリバリ デリバリ リクエスト リクエストリクエスト 運用現場 窓口 フロントエンド バックエンド outbound outbound
- 5. Operation Lab 運用設計ラボ 「運用」を「サービスデリバリ」と捉える Quality Cost Delivery 品質という価値観 時間という物性 金額という物性 ? 「サービス」視点で物事を考えるようになる ? 「デリバリ」視点で定量評価が可能になる ? 専門性(サービスとデリバリ)が明確になる ユーザ サービス デリバリ
- 7. Operation Lab 運用設計ラボ サービスとは何か? 全ての業務は「サービス」と捉えることができる 利用者の「課題」を解決すること サービス価値 (経営、実務) 目的 ? エンドユーザの課題を解決すること ? 社内ユーザの課題を解決すること ? 誰かの課題を解決することを(間接的に)支援すること
- 8. Operation Lab 運用設計ラボ サービスとは何か? (利用者視点) ? 丸投げ: 代わりにやってもらう ? 半投げ: 手伝ってもらいながら自分でやる ? 丸被り: 自分でやる (自己責任) (利用者視点) サービス価値 (経営、実務) 目的 利用者の「課題」を解決すること
- 9. Operation Lab 運用設計ラボ サービスとは何か? (クラウド時代) ? SaaS: 代わりにやってもらう ? PaaS: 手伝ってもらいながら自分でやる ? IaaS: 自分でやる (自己責任) 費用型 資産型 ? オンプレミス: 自分でやる (自己責任) (利用者視点) (利用者視点) 丸投げ 半投げ 丸被り 丸被り サービス価値 (経営、実務) 目的 利用者の「課題」を解決すること
- 10. Operation Lab 運用設計ラボ プロダクト指向運用からサービス指向運用へ ? SaaS: 代わりにやってあげる ? PaaS: 専門性や基盤で支援してあげる 今後: サービス(課題解決)指向運用へ (提供者視点) 従来: プロダクト指向運用 手段 の提供(コストセンター扱い) 道具のお守り サービス価値 (経営、実務) 目的 利用者の「課題」を解決すること
- 11. Operation Lab 運用設計ラボ プロダクト指向運用からサービス指向運用へ 今後: サービス(課題解決)指向運用へ ? SaaS: 代わりにやってあげる ? PaaS: 専門性や基盤で支援してあげる (提供者視点) 考 作展 ユーザ 稼サービスの根幹は 稼ぐ人 考える人 それを支える 作る人 展げる人 Ops Dev Deploy QA 営業 事業戦略、運用設計 サービス運用現場 サービス開発(支援) リリースマネジメント+営業 サービス価値 (経営、実務) 目的
- 12. Operation Lab 運用設計ラボ デリバリとは何か? サービスを安定的合理的に提供すること ? 高度な反復性、再現性が求められる業務活動。 ? 独自性よりも安定性、合理性が価値を持つ業務活動。 ? 定量評価による合理性検証を前提とした業務活動。 全ての定常業務は「デリバリ」と捉えることができる エンジニアリング価値 (生産工学) 手段
- 16. 「運用改善」は「成功」するのか? Operation Lab 運用設計ラボ 経験的に「だいたい失敗する」 実施直後は「改善効果」を実感できる、、、、が 数ヶ月～1年経過すると、次の「運用改善」が必要な状態に ? 場当たり的な「改善」の実施 ? 客観的な「到達点」の不存在 ? 「効果測定」の曖昧さ
- 19. 典型的な局所最適化のワナ 実は何も改善されていない とある伝説の改善事例 Operation Lab 運用設計ラボ 正社員 正社員 正社員 表彰 (2回目) 表彰 (1回目) 工数の押し付けあい アウトソースチーム
- 24. Operation Lab 運用設計ラボ 「運用改善」の成功要因1. 全体最適化 ? 受注から納品までの期間が短縮した。 ? 納品遅れによる失注がゼロになった。 ? 関係部署との連携が向上し、工数が激減した。 事業全体での「最適化」がカギ 自部署以外に改善効果が波及する事が重要 効果が波及しないものは優先順位が低い (例)
- 25. Operation Lab 運用設計ラボ 「運用改善」の成功要因2. 客観化 ? アラートメールが減った (数百万通->数万通/年) ? 成果に必要な工数(時間)が減った (2時間->10秒) ? 部署間調整に必要な時間が減った (40人日->8人日) 「客観化」がカギ 「誰がどう見ても同じ数字や事実」で Before/Afterを示すことが重要 (経験的に) (例)
- 26. ? 場当たり的な「改善」の実施 ? 客観的な「到達点」の不存在 ? 「効果測定」の曖昧さ 「運用改善」は「成功」するのか? Operation Lab 運用設計ラボ 事業全体を客観的に改善しないと意味がない 客観化 ? 局所最適化のワナ 事業全体での 最適化 必須 必須 自己満足におわってしまう
- 27. 「運用改善」の成功要因3. 変化に耐える Operation Lab 運用設計ラボ 実施直後は「改善効果」を実感できる、、、、が 数ヶ月～1年経過すると、次の「運用改善」が必要な状態に 常にチューニングできる余地を残しておく必要がある 「運用改善」には、あらかじめ「変化への対応」 を織り込んでおく必要がある。 環境の変化 実務との乖離 想定外の事象 事業全体を客観的に改善しても、硬直的だと…
- 28. ? 場当たり的な「改善」の実施 ? 客観的な「到達点」の不存在 ? 「効果測定」の曖昧さ 整理:「運用改善」を「成功」させるためには Operation Lab 運用設計ラボ Before/Afterを明確に AsIs(現状)を明確に ToBe(理想)を明確に 「全体最適化」と「客観化」が成功の要因 ? 局所最適化のワナ ? 事業全体での最適化 ? 客観化 ? 「改善効果」が短命 ? 「変化」を意識 「変化」を前提とすることが改善効果の維持につながる 成功の要因「だいたい失敗する」
- 29. まとめ:「運用改善」成功の要因 Operation Lab 運用設計ラボ Before/Afterを明確に AsIs(現状)を明確に ToBe(理想)を明確に ? 事業全体での最適化 ? 客観化 ? 「変化」を意識 「根本的にやり方を考えなおす」ことが 恒常的な「運用改善」につながる
- 30. Operation Lab 運用設計ラボ 2. ビジネスと「運用改善」 ～ 运用の「サービス」価値を考える
- 31. Operation Lab 運用設計ラボ 「運用改善」とは 「運用の価値」を 現状よりも高めるための改善活動 ToBe (理想) AsIs (現状) 運用改善「誰がどう見ても同じ数字や事実」 でBefore/Afterを示す 事業全体での最適化 客観化 変化を意識 環境の変化 想定外の事象 改善効果が自部署以外に波及する事が重要
- 33. Operation Lab 運用設計ラボ See Do 運用改善はPDSサイクルで (日本の現場) 現場主体の 自主サイクル ToBe (理想)とAsIs(現状)のギャップ解消のためのサイクル ギャップ の確認 ギャップ の評価 Plan ギャップ の縮小
- 34. Operation Lab 運用設計ラボ See Do Plan 「客観化」から着手して、AsIsを知るのが最初の作業 データに基づく 客観的、論理的 な改善サイクル 客観化 構造化 データの蓄積 AsIs ToBe AsIsとToBeの ギャップを埋める 「誰がどう見ても同じ数字や事実」 でBefore/Afterを示す 理想と現実の差分を明確にする 現実を理想に近づけるためのロジック を明確にする 運用改善におけるPDSサイクル
- 35. Operation Lab 運用設計ラボ 「運用改善」が必要な状況とは ? サービス価値の低下 ? 処理能力の低下 ? アジリティ(経営戦略への追随能力)の低下 運用の「価値」が低下している(可能性がある)状況 サービス価値 (経営、実務) エンジニアリング価値 (生産工学) もしくは 運用の「価値」を向上させることができる(可能性がある)状況
- 36. Operation Lab 運用設計ラボ ユーザ 価値の提供 サービス価値 (経営、実務) エンジニアリング価値 (生産工学) 経営者 事業戦略 「サービス価値の低下」はなぜ発生するか サービスへの期待と実際の価値に乖離がある ToBe (理想) AsIs (現状) AsIs (現状) ToBe (理想) 経営環境の変化も大きく影響 需要との乖離 事業戦略との乖離 「外部との乖離」
- 37. Operation Lab 運用設計ラボ 他部署 局所最適化のワナ 処理待ち… 内部作業 依頼作業 内部情報は豊富 「外部との乖離」の発生要因1. 情報の不均衡 外部からの情報と運用現場内部の情報の不均衡が原因 内部情報に基づいて優先順位付け 優先順位の不整合の例 外部情報は欠乏気味 外部からの情報 (事業戦略、ユーザニーズ) < 内部情報 (組織内の力関係を含む)
- 38. Operation Lab 運用設計ラボ 他部署 局所最適化の習性 処理待ち… 内部の最適化を求める 「外部との乖離」の発生要因2. 組織の本能 一般的に組織は「自己目的化」「自己最適化」する 内部の効率、快適性、人間関係 事業への貢献は後回し 外部への適応 < 内部の最適化 内部の効率UP 快適な職場、人間関係
- 39. Operation Lab 運用設計ラボ 自分の仕事しか考えない 自分の仕事しか考えない ユーザ 価値の提供 経営者 事業戦略 需要との乖離 事業戦略との乖離 自分の仕事しか考えない 自分の仕事しか考えない 局所最適化 まとめ: 「外部との乖離」の発生要因 外部への適応 < 内部の最適化 外部からの情報 (事業戦略、ユーザニーズ) < 内部情報 (組織内の力関係を含む)
- 41. Operation Lab 運用設計ラボ ユーザ 価値の提供 経営者 事業戦略 全体最適化指向 「外部との乖離」を回避するためには 組織が主体 発生要因2. 組織の本能 発生要因1. 情報の不均衡 社内情報の平衡化 + 事業への最適化を求める 事業への最適化を求める 事業が主体
- 42. Operation Lab 運用設計ラボ 「外部との乖離」を回避するためには 発生要因1. 情報の不均衡 発生要因2. 組織の本能 組織内外での情報の均衡を図る。 「組織が主体」から「事業が主体」への転換。 経営環境の変化にあわせて組織構成は変わる。 社内情報の平衡化 全社共通マスターの整備 「全体最適化」指向の情報管理 情報管理も、組織単位ではなく、事業単位。 事業への最適化を求める 事業への最適化を求める
- 45. Operation Lab 運用設計ラボ 「事業」とは何か 対価を得て、社会的意義のある価値を提供すること。 社会的意義のある価値を提供すること。 対価を得ること。 主目的 副次的な目的 事業を維持するために必要 「逆になると顧客は逃げる」とよく言われます ○ 価値を提供して、お金を貰った (給料増えます) お金が欲しいので、何かをする (給料増えません) 個人の場合 事業への最適化
- 48. Operation Lab 運用設計ラボ ユーザ 経営者 市場の変化 (経営者 vs. ユーザ) 考える人 使って払う人 市場変化 戦略が変わり続ける時代 需要が変わり続ける時代 需要と供給の乖離が 簡単に発生するようになった 長期契約がリスクとなる時代 長期戦略が意味を持たない時代 失敗を覚悟した短期戦略へ サービスの離脱率向上へ ユーザはきまぐれ 供給側の都合には付き合ってくれない 事業への最適化
- 49. Operation Lab 運用設計ラボ 経営者 経営との乖離 (経営者 vs. 社員) 考える人 実践する人 社員 事業戦略と遂行 戦略が変わり続ける時代 オペレーションのアジリティが 企業の命運を決める 事業戦略とオペレーションの乖離が 企業の致命傷になる時代になった 失敗を覚悟した短期戦略へ 長期戦略が意味を持たない時代 経営の視点 が求められる時代 敏捷性と柔軟性が価値 市場の変化に対応できない会社は潰れる 事業への最適化
- 50. Operation Lab 運用設計ラボ ユーザ ユーザとの乖離 (ユーザ vs. 社員) 実践する人 使って払う人 社員 評価と対価 需要が変わり続ける時代 自分の給料分を稼ぐことができる人が 限定される時代になった サービスの離脱率向上へ 長期契約がリスクとなる時代 ユーザの視点 が求められる時代 敏捷性と柔軟性が価値 給料の原資をはらってくれるのはユーザだけ 事業への最適化 企業人は給料の4倍以上ユーザから 稼がないと存在意義がない
- 56. Operation Lab 運用設計ラボ 「運用」問題 解決の構造 Phase2. 任務(mission)の客観化 Phase3. 実績(output)の客観化 Phase1. 期待(input)の客観化 経営論 運用方法論 費用対効果の見える化 高負荷の解消 属人性の解消 運用の「価値」の拡大 現場だけでやれることには限界がある 運用と経営は一体である 「運用」とはサービスデリバリである。 運用組織は分散協調である。 運用業務は工程である。 まとめ
- 59. Operation Lab 運用設計ラボ 参考: 「運用改善」の構造 Phase2. 任務(mission)の客観化 Phase3. 実績(output)の客観化 Phase1. 期待(input)の客観化 経営論 運用方法論 費用対効果の見える化 高負荷の解消 属人性の解消 ToBe (理想) AsIs (現状) 接 近 運用の「価値」の拡大 「誰がどう見ても同じ数字や事実」 でBefore/Afterを示す 「誰がどう見ても同じ数字や事実」 でBefore/Afterを示す 事業全体での最適化 運用現場と「外部」との乖離の縮小、解消 運用現場「内部」の矛盾の縮小、解消 影響大 影響小(相対的) 客観化 客観化 サービス価値 (経営、実務) エンジニアリング価値 (生産工学) 経営環境の変化を意識 想定外事象の発生を意識 まとめ 「運用」とはサービスデリバリである。 運用組織は分散協調である。 運用業務は工程である。