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

Transcript

• 1. Operation Lab 運用設計ラボ 「運用改善」を考える 運用設計ラボ合同会社 シニアアーキテクト 波田野 裕一 2015-06-23 ∼「自動化」を考える前に
• 2. Operation Lab 運用設計ラボ 本資料について • 本資料は2015年6月23日時点のものです。 • 今後、内容が大幅に変動する可能性があります。 • 本資料の内容は、運用設計ラボ合同会社の活動に基づくもので、 全ての文責は運用設計ラボ合同会社に帰すべきものです。
• 3. Operation Lab 運用設計ラボ 序. 「運用」とは まとめ
• 4. Operation Lab 運用設計ラボ 「運用」とは「サービスデリバリ」である リクエスト に対する デリバリ の繰り返し 出典: 経営情報学会 2010年春季全国研究発表大会 「運用業務プロセスのモデル化」 顧客・外部サービス outboundinbound outboundinbound 外部支援組織 inbound inbound 運用メンバー outboundinbound 内部協調/支援組織 inbound outbound リクエストデリバリ デリバリ デリバリ デリバリ リクエスト リクエストリクエスト 運用現場 窓口 フロントエンド バックエンド outbound outbound
• 5. Operation Lab 運用設計ラボ 「運用」を「サービスデリバリ」と捉える Quality Cost Delivery 品質という価値観 時間という物性 金額という物性 • 「サービス」視点で物事を考えるようになる • 「デリバリ」視点で定量評価が可能になる • 専門性(サービスとデリバリ)が明確になる ユーザ サービス デリバリ
• 6. Operation Lab 運用設計ラボ 誰が見ても同じ「運用」へ 費用に見合った効果のある「運用」 運用方法論 経営論 「サービス」の専門集団 「デリバリ」の専門集団 「サービスデリバリ」に求められる2つの専門性 運用現場には、専門集団として2つの側面がある 目的 手段 サービス価値 (経営、実務) エンジニアリング価値 (生産工学)
• 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 運用設計ラボ デリバリとは何か? サービスを安定的合理的に提供すること • 高度な反復性、再現性が求められる業務活動。 • 独自性よりも安定性、合理性が価値を持つ業務活動。 • 定量評価による合理性検証を前提とした業務活動。 全ての定常業務は「デリバリ」と捉えることができる エンジニアリング価値 (生産工学) 手段
• 13. Operation Lab 運用設計ラボ まとめ: 「運用」とは 目的 サービス価値 (経営、実務) エンジニアリング価値 (生産工学) ユーザ 費用に見合った 効果のある「運用」 経営論 誰が見ても 同じ「運用」へ 運用方法論 手段 サービス価値 を支える価値の提供 「運用」とは「サービスデリバリ」である。 「運用」の本質は「価値の提供」 価値を提供できれば「手段」は何でも良い
• 14. Operation Lab 運用設計ラボ これからの「運用」 目的 サービス価値 (経営、実務) エンジニアリング価値 (生産工学) ユーザ 費用に見合った 効果のある「運用」 経営論 誰が見ても 同じ「運用」へ 運用方法論 手段 サービス価値 を支える価値の提供 どちらの価値も重要だが…… サービス価値が無いと「運用」の存在意義がない 利用者の「課題」を解決できない X 独自色 標準化、スケーラビリティ
• 15. Operation Lab 運用設計ラボ 1. 「運用改善」は成功するか?
• 16. 「運用改善」は「成功」するのか? Operation Lab 運用設計ラボ 経験的に「だいたい失敗する」 実施直後は「改善効果」を実感できる、、、、が 数ヶ月∼1年経過すると、次の「運用改善」が必要な状態に • 場当たり的な「改善」の実施 • 客観的な「到達点」の不存在 • 「効果測定」の曖昧さ
• 17. とある伝説の改善事例 正社員の仕事をアウトソースチームに移転させて、正社員の工数削減 Operation Lab 運用設計ラボ 正社員 アウトソースチーム 正社員 正社員 正社員の工数削減効果により表彰 1期目負荷が高い…
• 18. とある伝説の改善事例 Operation Lab 運用設計ラボ 正社員 正社員 正社員 2期目 アウトソースチームの工数削減効果により表彰 アウトソースチームに移転させた仕事の負荷が高いので、 正社員が実施するように戻してアウトソースチームの工数削減 負荷が高い… アウトソースチーム
• 19. 典型的な局所最適化のワナ 実は何も改善されていない とある伝説の改善事例 Operation Lab 運用設計ラボ 正社員 24時間チーム 正社員 正社員 表彰 (2回目) 表彰 (1回目) 工数の押し付けあい
• 20. とある伝説の改善事例 Operation Lab 運用設計ラボ 意外と笑えない 部署毎の別々改善 局所最適化のワナ 事業自体は改善されない
• 21. 部署間インタフェースの不整合 内部工数削減 内部の工数減、依頼側の工数増 各部署毎に別々に改善した結果 Operation Lab 運用設計ラボ 他部署 依頼方法変更 依頼が大変… 局所最適化のワナ 事業自体は改善されない
• 22. 各部署毎に別々に改善した結果 Operation Lab 運用設計ラボ 他部署 局所最適化のワナ 処理待ち… 優先順位の不整合 内部工数削減 内部作業 依頼作業 ボトルネック 事業に重要ではないところにリソース傾注 事業自体は改善されない
• 23. 各部署毎に別々に改善した結果 Operation Lab 運用設計ラボ 局所最適化のワナ 事業自体は改善されない 意外と笑えない 部署毎の別々改善 工数の押し付けあい 部署間インタフェースの不整合 優先順位の不整合
• 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を示す 事業全体での最適化 客観化 変化を意識 環境の変化 想定外の事象 改善効果が自部署以外に波及する事が重要
• 32. Operation Lab 運用設計ラボ 「運用改善」に「銀の弾丸」は存在しない 合理的・客観的に着実に進める必要がある。 業務を根本的に見直す必要がある。 一足飛びに実現することは難しい。 一足飛びに実現が不可能、ということは 実現できた場合、圧倒的な強みになる。 「運用の価値」を 現状よりも高めるための改善活動
• 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 運用設計ラボ 自分の仕事しか考えない 自分の仕事しか考えない ユーザ 価値の提供 経営者 事業戦略 需要との乖離 事業戦略との乖離 自分の仕事しか考えない 自分の仕事しか考えない 局所最適化 まとめ: 「外部との乖離」の発生要因 外部への適応 < 内部の最適化 外部からの情報 (事業戦略、ユーザニーズ) < 内部情報 (組織内の力関係を含む)
• 40. Operation Lab 運用設計ラボ 自分の仕事しか考えない 自分の仕事しか考えない ユーザ 価値の提供 経営者 事業戦略 需要との乖離 事業戦略との乖離 「外部との乖離」はなにをもたらすか 組織硬直化 顧客の離脱 経営の危機 自分の仕事しか考えない 自分の仕事しか考えない 他に移ろう 給料払えない… 局所最適化
• 41. Operation Lab 運用設計ラボ ユーザ 価値の提供 経営者 事業戦略 全体最適化指向 「外部との乖離」を回避するためには 組織が主体 発生要因2. 組織の本能 発生要因1. 情報の不均衡 社内情報の平衡化 + 事業への最適化を求める 事業への最適化を求める 事業が主体
• 42. Operation Lab 運用設計ラボ 「外部との乖離」を回避するためには 発生要因1. 情報の不均衡 発生要因2. 組織の本能 組織内外での情報の均衡を図る。 「組織が主体」から「事業が主体」への転換。 経営環境の変化にあわせて組織構成は変わる。 社内情報の平衡化 全社共通マスターの整備 「全体最適化」指向の情報管理 情報管理も、組織単位ではなく、事業単位。 事業への最適化を求める 事業への最適化を求める
• 43. Operation Lab 運用設計ラボ ユーザ 価値の提供 経営者 事業戦略 まとめ: 「外部との乖離」を回避するには 事業への最適化 「事業(全体)への最適化」を常に実現する必要がある
• 44. Operation Lab 運用設計ラボ 3. 運用改善による「事業への最適化」
• 45. Operation Lab 運用設計ラボ 「事業」とは何か 対価を得て、社会的意義のある価値を提供すること。 社会的意義のある価値を提供すること。 対価を得ること。 主目的 副次的な目的 事業を維持するために必要 「逆になると顧客は逃げる」とよく言われます ○ 価値を提供して、お金を貰った (給料増えます) お金が欲しいので、何かをする (給料増えません) 個人の場合 事業への最適化
• 46. Operation Lab 運用設計ラボ 価値の提供 事業戦略 「事業」を取り巻く環境 社員 実践する人 経営者 考える人 ユーザ 使って払う人 事業の遂行 価値の創成 事業への最適化
• 47. Operation Lab 運用設計ラボ ユーザ 経営者 「事業」を取り巻く環境 考える人 実践する人 使って払う人 社員 市場変化 事業戦略と遂行 評価と対価 事業への最適化
• 48. Operation Lab 運用設計ラボ ユーザ 経営者 市場の変化 (経営者 vs. ユーザ) 考える人 使って払う人 市場変化 戦略が変わり続ける時代 需要が変わり続ける時代 需要と供給の乖離が 簡単に発生するようになった 長期契約がリスクとなる時代 長期戦略が意味を持たない時代 失敗を覚悟した短期戦略へ サービスの離脱率向上へ ユーザはきまぐれ 供給側の都合には付き合ってくれない 事業への最適化
• 49. Operation Lab 運用設計ラボ 経営者 経営との乖離 (経営者 vs. 社員) 考える人 実践する人 社員 事業戦略と遂行 戦略が変わり続ける時代 オペレーションのアジリティが 企業の命運を決める 事業戦略とオペレーションの乖離が 企業の致命傷になる時代になった 失敗を覚悟した短期戦略へ 長期戦略が意味を持たない時代 経営の視点 が求められる時代 敏捷性と柔軟性が価値 市場の変化に対応できない会社は潰れる 事業への最適化
• 50. Operation Lab 運用設計ラボ ユーザ ユーザとの乖離 (ユーザ vs. 社員) 実践する人 使って払う人 社員 評価と対価 需要が変わり続ける時代 自分の給料分を稼ぐことができる人が 限定される時代になった サービスの離脱率向上へ 長期契約がリスクとなる時代 ユーザの視点 が求められる時代 敏捷性と柔軟性が価値 給料の原資をはらってくれるのはユーザだけ 事業への最適化 企業人は給料の4倍以上ユーザから 稼がないと存在意義がない
• 51. Operation Lab 運用設計ラボ ユーザ 経営者 「事業」を取り巻く環境 (全体像) 考える人 実践する人 使って払う人 社員 戦略が変わり続ける時代 オペレーションのアジリティが 企業の命運を決める 企業人は給料の4倍以上ユーザから 稼がないと存在意義がない 需要が変わり続ける時代 サービスの離脱率向上へ 失敗を覚悟した短期戦略へ 敏捷性と柔軟性が価値 ユーザはきまぐれ 供給側の都合には付き合ってくれない 給料の原資をはらってくれるのはユーザだけ 市場の変化に対応できない会社は潰れる 事業への最適化
• 52. Operation Lab 運用設計ラボ ユーザ 経営者 「事業」を取り巻く環境 社員 戦略が変わり続ける時代 オペレーションのアジリティが 企業の命運を決める 需要が変わり続ける時代 ユーザはきまぐれ 供給側の都合には付き合ってくれない 給料の原資をはらってくれるのはユーザだけ 市場の変化に対応できない会社は潰れる 事業への最適化 組織硬直化 顧客の離脱 経営の危機 局所最適化の結果 事業全体を客観的に改善しないと意味がない 運用改善 経営との乖離 ユーザとの乖離 企業人は給料の4倍以上ユーザから 稼がないと存在意義がない
• 53. Operation Lab 運用設計ラボ 価値の提供 事業戦略 事業の構造 (ユーザや経営との乖離防止) 経営者 考える人 ユーザ 使って払う人 事業の遂行 価値の創成 事業への最適化 社員 実践する人 ビジネスドメイン (事業領域) ビジネスメニュー (売上の対象単位) オペレーション サービスカタログ 事業領域の宣言 ビジネスマーケット (市場) 遂行事業と売上要素 の明確化 ビジネス サービスカタログ ユーザとの接点 の明確化 組織間の接点 の明確化 現在の提供価値一覧 未来の価値源泉一覧 全体最適化の実現 サービスチェーン
• 54. Operation Lab 運用設計ラボ オペレーション サービスカタログ サービスチェーン 現状の見える化が最優先 See 外部との関係の客観化 AsIs(改善のBefore)を客観化する 客観化 中途メンバーが2営業日で事業の全体像を理解できるように客観化する ビジネスドメイン (事業領域)カタログ ビジネスメニュー (売上対象)カタログ ビジネス サービスカタログ 事業領域の理解 遂行事業と売上要素 の理解 ユーザとの接点 の理解 組織間の接点 の理解 組織の提供価値 の理解 事業の提供価値 の理解 事業への最適化 事業構造の見える化 ビジネスマーケット (市場)
• 55. Operation Lab 運用設計ラボ まとめ
• 56. Operation Lab 運用設計ラボ 「運用」問題 解決の構造 Phase2. 任務(mission)の客観化 Phase3. 実績(output)の客観化 Phase1. 期待(input)の客観化 経営論 運用方法論 費用対効果の見える化 高負荷の解消 属人性の解消 運用の「価値」の拡大 現場だけでやれることには限界がある 運用と経営は一体である 「運用」とはサービスデリバリである。 運用組織は分散協調である。 運用業務は工程である。 まとめ
• 57. Operation Lab 運用設計ラボ 「運用」とは まとめ 目的 サービス価値 (経営、実務) エンジニアリング価値 (生産工学) ユーザ 費用に見合った 効果のある「運用」 経営論 誰が見ても 同じ「運用」へ 運用方法論 手段 サービス価値 を支える価値の提供 「運用」とは「サービスデリバリ」である。 「運用」の本質は「価値の提供」 価値を提供できれば「手段」は何でも良い
• 58. Operation Lab 運用設計ラボ 「運用改善」とはどのような活動であるべきか 運用の「価値」の拡大 運用現場と「外部」との乖離の縮小、解消 影響大 運用現場「内部」での矛盾の縮小、解消 サービス価値 (経営、実務) 影響小 (相対的) エンジニアリング価値 (生産工学) 「誰がどう見ても同じ数字や事実」 でBefore/Afterを示す 「誰がどう見ても同じ数字や事実」 でBefore/Afterを示す まとめ 事業全体での最適化 客観化 客観化 経営環境の変化を意識 想定外事象の発生を意識
• 59. Operation Lab 運用設計ラボ 参考: 「運用改善」の構造 Phase2. 任務(mission)の客観化 Phase3. 実績(output)の客観化 Phase1. 期待(input)の客観化 経営論 運用方法論 費用対効果の見える化 高負荷の解消 属人性の解消 ToBe (理想) AsIs (現状) 接 近 運用の「価値」の拡大 「誰がどう見ても同じ数字や事実」 でBefore/Afterを示す 「誰がどう見ても同じ数字や事実」 でBefore/Afterを示す 事業全体での最適化 運用現場と「外部」との乖離の縮小、解消 運用現場「内部」の矛盾の縮小、解消 影響大 影響小(相対的) 客観化 客観化 サービス価値 (経営、実務) エンジニアリング価値 (生産工学) 経営環境の変化を意識 想定外事象の発生を意識 まとめ 「運用」とはサービスデリバリである。 運用組織は分散協調である。 運用業務は工程である。
• 60. Operation Lab 運用設計ラボ http://www.operation-lab.co.jp/ OperationLab運用設計