こんにちは、MSPの田所です。

みなさんは「オペレーショナルエクセレンス」とは何かご存知でしょうか？
日本語で言うと「運用上の優秀性」らしいです。
なんだか日本語でもイメージが湧きませんね？

今回は オペレーショナルエクセレンス が MSP として刺さる内容だらけだったのでご紹介です。

1. オペレーショナルエクセレンス と私

オペレーショナルエクセレンス とは何でしょう？

一般的には、

企業が事業活動の効率を高めることで、競争上の優位性を保つ状態

のことを言います。

これだけだとイメージが湧きにくいですが、個人的にはトヨタ生産方式のイメージです。
自動車を製造するメーカーは数あれど、原料調達、生産、物流網などの管理、運用、バックアップ体制が優れている企業は、そうでない企業と比べて競争力がある、というのはイメージしやすいのではないでしょうか。

この オペレーショナルエクセレンス ですが、企業勤めを始めてから常に耳にする言葉でした。
私は IT業界に入るまでは、メーカーにてサプライチェーンを担当していました。

商品の生産管理では、
「品切れさせない、けれど在庫は持ちすぎない、さらに運用コストも抑えたい」
という文脈で オペレーショナルエクセレンス の重要さが強調されていました。

また物流管理では、
「お客様に早く届けたい、けれど破損や運用ミスは減らしたい、そしてプロセスや資材は簡素化したい」
とこれまた オペレーショナルエクセレンス という用語で語られていました。

そして、IT業界に転職してからもこのワードに出会うとは思いもしませんでした。

オペレーショナルエクセレンス とは一生の付き合いになるのかもしれません。

2. AWS の オペレーショナルエクセレンス

そして AWS における オペレーショナルエクセレンス の話です。
AWS は、クラウド上でワークロードを設計、実行するためのベストプラクティスを集めた Well-Architected フレームワーク を定めています。
このフレームワークには6つの柱と言われる大項目があるのですが、そのうちの1本目の柱が オペレーショナルエクセレンス です（重要！）
AWS 公式ドキュメントによると、オペレーショナルエクセレンス は以下のように定義されています。

運用上の優秀性の柱には、開発をサポートし、ワークロードを効率的に実行し、運用に関するインサイトを得て、ビジネス価値をもたらすためのサポートプロセスと手順を継続的に改善する能力が含まれます。

3. AWS Well-Architected Mini Bootcamp for iret で学ぶ

これまで私は、社内の Mini Bootcamp イベントで以下の柱を学習してきました。

そして今回、オペレーショナルエクセレンス の柱をテーマに社内向けのイベント開催がありました。
6つの柱の中で一番気になっていたということもあり、迷わず参加です。

今回参加した AWS Well-Architected Mini Bootcamp for iret では、以下の設定でディスカッションを行なっていきました。

  • 架空企業のいまいちな現状がお題として与えられる
  • オペレーショナルエクセレンス の観点で、どこをどう改善したらいいのかを考える
  • 現状と理想を整理して発表する
  • みんなであれこれ議論する
    • 具体的な実装をどうするか
    • どんな優先順位で行うか
    • どんなハードルが考えられ、それをどう乗り越えるか
    • 現場あるある
    • 最近の技術トレンド
    • などなど

例えば、複数のチームが同じアカウント環境を無秩序に使っているとします。

というベストプラクティスに沿うと、

  • アカウントを分けて AWS Organizations で管理する
  • AWS Config でリソースのタグ付けルールを強制する

といった対策が考えられます。

そうすれば、

「このインスタンス誰が立てた？消してもいいやつ？」
「このリソースのコストをうちのチームで負担するのはおかしくない、、？」

のような事態を防ぐことができます。

オペレーショナルエクセレンス を構成する項目やベストプラクティスについては、

に全容が載っていますが、2024年11月時点では 11 の項目と、それらに紐付く 68 のベストプラクティスがあります。
これだけチェックできれば万全な運用体制を目指せそうですね。

他にも主にこんな項目で構成されています。

  • 組織の設計
  • ワークロードのリスク低減や改善
  • 運用の管理や分析
  • 運用の日々の進化

運用の具体的な手法やサービスだけでなく、

  • 組織や複数のチームを意識した共通プロセスの設計を行う
  • 新しいテクノロジーを取り入れながら運用自体を進化させる

といったポイントが明記されていたことが印象的でした。

4. MSP として感じたこと

インフラ運用部隊である MSP として、学びになる点がたくさんありました。
聞くほどに耳が痛い項目もちらほら、、

気になった3つをご紹介します。

OPS02-BP03 オペレーションアクティビティに、そのパフォーマンスに責任を持つ所有者が紐付いている

運用のプロセスやパフォーマンスに誰が責任を持つのか文書化するというものです。
AWS の 責任共有モデル さながら、例え社内でもその責任の所在を明確にしておくと、いつの間にかボールが落ちていたり、古くて実質意味をなさない情報が放置されることも減らせます。

これは MSP が社内で構築や二次運用担当と取り決めをする際にも大事な要素であると思いました。

OPS07-BP03 ランブックを使用して手順を実行する

ランブックはプロセスを完了するための一連のステップをまとめたもので、MSP のアラート対応時の手順書がまさにランブックにあたります。
そして組織が成熟するほどランブックの自動化を進める必要があるという内容です。

MSP として手順の自動化は確実に進んでいますが、有人対応でこそ出せる価値をどこに見出すか、その境界が急速に変わってきているのを感じます。

OPS11-BP05 改善の推進要因を定義する

ビジネス成果に結びつく改善を分解し、優先順位付けして取り組むというものです。
またテクノロジーの進歩による新機能の活用や、自動化の実装も改善の手段になるという内容も含まれています。

MSP でも最新の監視や自動化のテクノロジーを取り入れて日々改善に取り組んでいるため、ホットで身近なトピックでした。

またディスカッションの時間には、障害対応に Amazon Bedrock を活用して原因予測や対策の提案を行う SaaS も登場していると話題に上がりました。
今後、アラートの一次対応においても生成 AI の利活用は必須になると感じました。

5. まとめ

オペレーショナルエクセレンス に関する個人的な接点と、AWS における オペレーショナルエクセレンス、MSP として感じたことをお伝えしてきました。
今回は ITサービスや組織に関する話でしたが、オペレーショナルエクセレンス は家事やサークル活動などプライベートにも十分活用できる便利な概念であると思いました。

それにしても「オペレーショナルエクセレンス」がゲシュタルト崩壊しましたね。

おしまい