※チームメイトのDenis Guyadeenが書かれたこちらの英文ブログを元にしています
はじめに
組織の規模が拡大し、進化するにつれて、多くの企業がイノベーション、アジリティ、効率性を高めるために分散型の開発と運用を備えたチームモデルを採用されています。よく耳にするDevOpsやSREはそれに当たります。このアプローチは多くの大手企業で成功を収めている一方で、開発や運用で使っているばらばらのツールとそれらの統合や管理、組織全体として整合性を確保するなど上で課題も生じています。この記事では、これらの様々な課題を掘り下げ、また課題解決の為に、ITOM BUが24Q3に正式リリースしました、組織全体で標準化ソリューションであるServiceNowサービス信頼性管理（英語名：Service Reliability Management、あるいはSRMとも呼びます）を交えてご紹介します。
分散チームの台頭： 組織が分散チームを採用する理由
分散チームは、俊敏性、柔軟性、迅速なイノベーションの必要性によって、現代の組織構造の要となっています。AmazonやSpotifyのようなハイテク大手によって普及した分散チームモデルは、小規模で自律的なユニットが独立して活動することを可能にし、イノベーションとスピードを促進しています。
分散チームの主な構成要素
- 自主性： チームには迅速に意思決定する自由があり、ボトルネックを減らし、対応力を高めます
- クロスファンクション： チームは多くの場合、異なる分野のメンバーで構成され、多様な視点や専門知識をもたらします。
- 集権排除： 意思決定がチームレベルで行われることで、より迅速で状況に即した意思決定が可能になります。
- 目標指向の構造： チームは通常、特定の製品、機能、サービスを中心に組織され、明確な目標と説明責任を持ちます。
成功の実例
- アマゾン２ピザチーム： アマゾンの２ピザ・チーム・コンセプトは、チームを小規模かつ機敏に保ち、過度な調整を必要とせずに独立して活動できるように設計されています。このモデルでは、各チームが特定のサービスやコンポーネントを所有するため、スピードとイノベーションが促進されます。
- Spotifyスクワッド： Spotifyのスクワッドモデルは、サービスの特定の機能または側面を中心にチームを編成する。分隊は自律的かつ部門横断的であるため、独立して活動し、迅速に結果を出すことができます。この構造により、Spotifyは規模が拡大しても高いレベルのイノベーションと俊敏性を維持することができます。
- INGのアジャイル変革： 金融セクターの伝統的企業であるINGは、組織全体にアジャイルプラクティスを導入することで、分散チームモデルの採用に成功しました。INGは、Spotifyのモデルと同様に、従業員を小規模で自律的なチームに再編成しました。この変革により、INGはイノベーションのスピードと顧客ニーズへの対応力を高めることができ、分散チームを効果的に採用した伝統的な企業の代表例となりました。
- Capital Oneのアジャイルへの旅：金融サービス業界のもう1つの大手企業であるCapital Oneは、デジタルトランスフォーメーション取り組みの一環として分散チームを採用しました。アジャイル手法を採用し、チームを機能横断的な小規模ユニットに編成することで、Capital Oneは新しい金融商品やサービスを迅速に開発・展開できるようになりました。この転換によって、同社の革新能力を向上させただけでなく、急速に変化する市場における競争力を強化しました。
分散チームのメリット
分散チームの採用には、一般的に以下のようなメリットがあります：
- 敏捷性と柔軟性： 小規模で自律的なチームは、大組織にありがちな官僚的な遅れを生じることなく、変化に迅速に対応し、イノベーションを起こし、顧客のニーズに応えることができます。
- コラボレーションの強化： クロスファンクションのチーム編成により、コラボレーションが促進され、業務に対するオーナーシップと説明責任が高まります。
- グローバルな人材へのアクセス： 分散チームは地理的に異なる場所で活動できるため、組織はグローバルな人材プールを活用し、問題解決に多様な視点をもたらすことができます。
- 生産性の向上： 明確な目標と自主性を持ったチームは、強いオーナーシップと目的意識をもちますので、より高いモチベーションと生産性を発揮できます。
分散チームを採用する企業が直面する課題
分散チームモデルは大きなメリットをもたらしますが、従来の集中型運用に馴染んでこられた企業は、このアプローチを採用しようとしたら、様々な課題に直面することが多いです。その中、とりわけ多様なツールやプロセスを管理するという点になります。
ツールとプロセスの断片化： 分散チームはそれぞれのニーズに合わせて独自にツールを選択することが多いです。このような自主性は、チームレベルでの効率化を促進する一方で、組織全体の分断を招きます。異なるツールはサイロを作り出し、システムの統合やデータの共有を困難にし、最終的にコラボレーションを妨げます。信頼性管理(SRM)は、以下のスクリーンショットに示すように、サービスオペレーションワークスペース(SOW)にシームレスな統合により、ツールやプロセスの分断を解消します。これにより、管理者はチームまたは製品のリーダーを割り当て、そのリーダーが独立して自身のチームを管理し、チームだけのサービス定義し、オンコール通知の設定、サービスレベル目標(SLO)、サービスレベル指標(SLI)、エラーバジェット（Error Budgets）などのサービス管理のタスクを行うことができます。
サービスオペレーション管理コンソールでSRMを有効にします
インスタンス管理者は、製品やサービスのチームリーダーを指定し、SRMアドミンの役割を割り当てます
SRMアドミンをもつチームリーダーがチームのメンバーとサービスをインポートできるようになりました
可視性と透明性の欠如： チームが独立して運営されているため、リーダーシップは、各々のチームが使用しているツールやその効果を見失う可能性がある。このような可視性の欠如は、どのチームのパフォーマンスが高く、どのチームが苦戦しているかを評価することを困難にしています。信頼性管理(SRM)は、包括的なダッシュボードとレポート機能を提供し、チームのパフォーマンスと全体的な生産性に関するリアルタイムの洞察をリーダーシップに提供します。
非効率と冗長性： 複数のツールを同じような目的で使用すると、非効率とコスト増を招きます。チームは様々なツールの管理や習得に時間を費やすことに陥り、本来のコア業務に集中できなくなります。信頼性管理(SRM)は、複数のポイントソリューションの必要性を減らすことでオペレーションを合理化し、チームが統一されたプラットフォームでより効率的に作業できるようにします。
セキュリティとコンプライアンスのリスク： 異なるチーム間でさまざまなツールを使用することで、セキュリティの脆弱性やコンプライアンス上の問題が発生するリスクが高まります。すべてのツールがセキュリティ基準や規制に適合していることを確認することは、一元的な管理をしなければなりません。サービス信頼性管理(SRM)はNow Platform上に構築されているため、既存のセキュリティおよびコンプライアンスフレームワークを活用し、一貫したセキュリティプロトコルを実施し、業界標準を遵守することを実現できます。この一元化されたアプローチはリスクを軽減し、すべてのツールが必要なセキュリティとコンプライアンス対策を満たすことを保証します。
統合の課題： チーム間で異なるツールを統合することは、技術的に勿論複雑でありながら、人的と物的なリソースや労力を必要とします。シームレスな統合を行わなければ、データの不整合が発生し、効果的なコラボレーションの妨げになります。サービス信頼性管理(SRM)は強力な統合機能を備え、すべてのチーム間でのスムーズなデータフローとコラボレーションを実現します。
拡張性の問題： 個々のチームが選択したツールは、組織全体で効果的に拡張できない可能性があり、組織の成長と新たなチャレンジへの適応能力を制限します。サービス信頼性管理(SRM)は、NOWプラットフォームの堅牢で実績のある機能を活用することで、このようなスケーラビリティのハードルを克服するために特別に設計されています。
SRMは、大規模でテストされ実証された既存のITSMおよびITOMソリューションの機能を再利用します。この設計アプローチの元につくられたものであるため、需要が増大しても信頼性とシームレスなパフォーマンスが保証されます。これらの確立されたコンポーネントの上に構築することで、サービス信頼性管理(SRM)は、大規模なオペレーションを効果的に処理できる一貫性と堅牢性のある環境を提供します。さらに、既存のコンポーネントを再利用することで、サービス信頼性管理(SRM)は新機能やアップデートをより迅速に提供することができます。この迅速なリリース能力により、企業や組織は最新の機能やイノベーションの恩恵を遅滞なく受けることができます。
サポートとメンテナンスの負担： 多種多様なツールの管理とサポートは、ITリソースに負担をかけます。すべてのツールを最新の状態に保ち、機能させるためには継続的な努力が必要であります。しかし、それによってより戦略的な取り組みから重要なリソースをそらすこととなってしまいます。サービス信頼性管理(SRM)はNOWプラットフォーム上に構築されているため、企業はサポートとメンテナンスの取り組みを一元化することができます。この統合により、サービス信頼性管理(SRM)と他のServiceNowソリューションとの管理が簡素化され、ばらばらのシステムを維持することに伴う複雑さとコストが削減されます。
さらに、サービス信頼性管理(SRM)はストアリリースであるため、ファミリリリース待たずにより短いサイクルのリリースのメリットを享受できます。最新の機能、アップデート、セキュリティ強化が、手作業による大規模な介入を必要とせずにシームレスに提供されます。その結果、チームは本来のコア作業、より戦略的な目標に向かって集中することができ、複数の異なるツールを管理する運用上のオーバーヘッドを減らすことができます。
生産性測定の難しさ： 標準化されたツールがなければ、異なるチームの生産性を測定し比較することは困難です。リーダーシップは、パフォーマンスの高いチームとサポートが必要なチームを特定できなくなり、リソースの不均衡な割り当てにつながる可能性があります。下図のように、サービス信頼性管理(SRM)は標準化されたメトリクスとアナリティクスを提供するため、企業全体でチームの生産性を総合的に測定し、比較することが容易になります。
サービスリストのダッシュボードは、各チームの状況を一目瞭然に示しています。
文化とコミュニケーションの壁： 異なるツールは、チーム間のコミュニケーションの断絶や文化的な隔たりを生む可能性があります。結束力のあるコラボレーション文化の醸成が難しくなり、チームの士気やパフォーマンスに影響を与えます。サービス信頼性管理(SRM)は統一されたコミュニケーションフレームワークを促進し、コラボレーションを強化し、チーム間の壁を取り除きます。
オンボーディングとトレーニングの複雑さ： 新入社員はさまざまなツールを使いこなすという課題に直面します。この複雑さがオンボーディングプロセスを遅らせ、チーム全体の生産性に影響を与えます。サービス信頼性管理(SRM)は、習得と使用が容易なひとつ統一したプラットフォームを提供することで、オンボーディングとトレーニングを迅速化と簡素化します。
ServiceNowの優位性
ServiceNowの信頼性管理(SRM)は、ポイントソリューションと違って、サービス信頼性においてのあらゆる側面に対応する包括的な統合プラットフォームを提供しています。特定の機能に特化したポイントソリューションとは異なり、信頼性管理(SRM)はサービスライフサイクル全体をエンドツーエンドで可視化し、コントロールします。この全体的なアプローチにより、より良い調整、冗長性の削減、運用効率の向上が実現します。
結論
ServiceNowの信頼性管理(SRM)を用いて、分散型チームに権限を委譲しながら、コラボレーションを強化します。そして、組織全体の生産性とパフォーマンスを推進するために必要な可視性をリーダーシップに提供します。シングルプラットフォームにツールとプロセスを統合することで、組織はツールの断片化、非効率性、可視性の欠如という課題を克服できます。サービス信頼性管理(SRM)は、組織の長期的な成功を保証する、さらに結束力のある効率的でスケーラブルな作業環境を育成すると、バランスの取れたアプローチを提供します。
その他参考リソース
- Introducing Service Reliability Management for ServiceNow
- Maximizing IT Service Reliability with ServiceNow's SRM and Strategic Portfolio Management
- Navigating Service Reliability: Insights into SLOs, SLIs, and Error Budgets
- Implementing Service Level Objectives (SLOs) within ServiceNow: A Customer Perspective
- Free the SRE: Hybrid Reliability Teams Framework
- Powering Innovation and Speed with Amazon’s Two-Pizza Teams
- Spotify engineering culture
- ING’s agile transformation
- Capital One – Benefits of SAFe for Financial Services
