ビジネスケイパビリティ中心
2016年6月8日
ビジネスケイパビリティ中心のチームとは、業務が特定のビジネス領域に長期的に連携しているチームです。このチームは、当該ビジネスケイパビリティがビジネスに関連している限り存続します。これは、プロジェクトのスコープを達成するまでしか存続しないプロジェクトチームとは対照的です。
たとえば、eコマースビジネスには、購買と商品化、カタログ、マーケティング、注文管理、フルフィルメント、カスタマーサービスなどのケイパビリティがあります。保険ビジネスには、保険契約管理、請求管理、新規事業などのケイパビリティがあります。通信事業には、ネットワーク管理、サービス提供と保証、請求、収益管理などのケイパビリティがあります。これらは、管理可能な規模のチームが所有できるように、さらに細かく分類される場合があります。
ビジネスケイパビリティ中心のチームは、「考え、構築し、運用する」チームです。彼らは、テスト、デプロイ、または構築したもののサポートを他のチームに引き継ぎません。彼らは、自分たちの領域の問題にエンドツーエンドで責任を持ちます。また、主にビジネスケイパビリティをサポートするITシステム（アプリケーション、API、データ）も所有します。基盤となるテクノロジープラットフォーム（例：Java、.NET）およびアプリケーションプラットフォーム（例：Salesforce、SAP、Peoplesoft）は、チーム間で共有される場合があります。
スリラムの著書では、ビジネスケイパビリティ中心のIT組織を構築する方法と理由について詳しく説明しています。
各ケイパビリティのチーム規模は、IT戦略からのガイダンスに基づいて、毎年など定期的に決定されます。これは、従来のポートフォリオ管理では、資金という形で予算が比較的短命のプロジェクト/プログラムのポートフォリオに割り当てられるのに対し、チームのキャパシティという形で予算が長期にわたるビジネスケイパビリティのポートフォリオに割り当てられる異なる種類のポートフォリオ管理です。ビジネスケイパビリティ中心のチームは、その可能性を最大限に発揮するために、成果志向である必要があります。ビジネス成果に向けて取り組む権限が与えられない限り、スコープデリバリー指向に陥る可能性があります。
最新のシステムとレガシーシステムが混在し、自作のアプリケーションと市販の既製（COTS）アプリケーション、SaaSアプリケーション、いくつかの新しいマイクロサービスによって提供される異種APIレイヤー、いくつかのメガサービス、そしてすべてがアドホックな統合、エンタープライズサービスバス、その他の特別なミドルウェアの組み合わせで結び付けられている典型的なアプリケーションランドスケープの例を考えてみましょう。各ビジネスケイパビリティ中心のチームは、主にそのビジネス領域に関連する上記のまとまりのあるサブセットを所有します。ただし、一部のアプリケーションは本質的にクロスケイパビリティです。たとえば、eコマースアプリケーションのエンドツーエンドのルックアップからチェックアウトまでのカスタマージャーニーなどです。彼らは独自のチーム（または2つのチーム、モバイル用とラップトップ用）が必要になる場合があります。アプリケーションランドスケープ内に境界線を引いてチームに分割するのは、簡単な作業ではありません。成果志向は、優れた指針となります。各区分がビジネス成果またはサブ成果（ビジネス指標として表される）に責任を負うことができるかどうかを検討してください。
単一のチームがビジネスケイパビリティ内の複数のシステムを管理すると、コンウェイの法則に反するのではないかと懸念する人もいます。しかし、コンウェイの法則は、単一のチームが複数の関連コンポーネントを担当することに反対しているわけではありません。コンポーネントの所有権の高い凝集性とチーム間の低い結合を可能にし、より良い応答性を実現します。
人員への影響
ビジネスケイパビリティ中心の構成では、プロジェクト中心の実行モデルよりもわずかに多くの人員が必要になる場合があります。これは、プロジェクトの任務は通常、「構築、サポート/運用への引き渡し、解散」のみであるのに対し、ビジネスケイパビリティ中心のチームの任務は、ビジネスケイパビリティが関連している限り「考え、構築し、運用する」ことであるためです。そのため、各ビジネスケイパビリティに少なくとも最小限のチームを常に維持する必要があります。結局のところ、これは多くの理由から望ましいことです。プロジェクト中心のモデルは、各プロジェクトチームが約束された日付までにスコープを達成することのみを重視しているため、アプリケーションランドスケープのアーキテクチャの整合性を損なうことがよくあります。その過程で、次のような近道をする可能性があります。
- 依存するシステムとのアドホックな統合
- 廃止予定のシステムとの統合または機能追加。これは、交換システムで行うよりも多くの労力が必要になるためです。
- 以前のチームの作業の上に場当たり的なコードを追加し、その過程でメンテナンスの悪夢を作り出す。
これらのいくつかは、エンタープライズアーキテクチャからの適切な監督によって回避される場合がありますが、プロジェクト中心のモデルでは、新しいリリースごとに異なるチームが編成されることが多く、新しいチームはビジネスルールと周囲のアプリケーションランドスケープの注意事項をすべて最初から学習する必要があるため、依然として課題となっています。アウトソーシングはこれをさらに複雑にします。
一方、プロジェクト中心のモデルは、資金が豊富で、既存のコードベースとアプリケーションランドスケープの許容量を無視してプロジェクトが軽率に開始された場合、膨大な人員を抱えることは珍しくありません。プロジェクトポートフォリオレベルでの仕掛かり作業の制限がないため、多くのプロジェクトが開始され、完了したり、望ましい結果をもたらしたりするプロジェクトはほとんどありません。
戦略ケイパビリティとユーティリティケイパビリティ
ビジネスケイパビリティは、特定の期間にわたって戦略的またはユーティリティとして分類される場合があります。場合によっては、ケイパビリティ内のいくつかのサブケイパビリティに戦略的なラベルを付ける方が useful です。一方、給与、会計、法務、人事、職場コラボレーションなどの企業ITケイパビリティは、通常、ユーティリティとして分類されます。ビジネスケイパビリティ中心のチームとして編成されていますが、ユーティリティケイパビリティは、多くの場合、パッケージソフトウェア（ビルドではなく購入）で提供されます。そのため、彼らは「考え、購入し、カスタマイズ/設定/統合し、運用する」チームであり、「考え、構築し、運用する」チームではありません。ユーティリティケイパビリティは、マネージドサービスプロバイダーが提供する外部のビジネスケイパビリティ中心のチームにアウトソーシングされることもよくあります。社内で提供される場合でも、これらのチームには、一流の開発スキルではなく、維持管理スキルを持つスタッフを配置するのが実用的です。同様に、成果志向はユーティリティケイパビリティにとって重要ですが、それらは下級のプロダクトオーナーが率いることができます。