アクティビティ指向

2016年6月1日

悪い点

チーム組織

重要なソフトウェア開発の取り組みには、分析、ユーザーエクスペリエンスデザイン、開発、テストなど、いくつかの異なるアクティビティが必要です。アクティビティ指向のチームは、これらのアクティビティを中心に組織されるため、ユーザーエクスペリエンスデザイン、開発、テストなどの専任チームが存在します。アクティビティ指向は多くの利点を約束しますが、ソフトウェア開発は通常、成果指向のチームで行う方が優れています。

従来、大規模なIT部門を持つ大企業（エンタープライズIT）は、マトリックスIT組織（機能組織）から選ばれたアクティビティ指向のチームの集団でIT開発プロジェクトを実行する傾向がありました。マトリックスの太線（開発、テストなどのVPが率いる）は通常アクティビティの境界に沿っており、点線のプロジェクトまたはプログラム組織に「リソース」を貸し出します。そうする一般的な正当化には、以下が含まれます。

  • すべての開発者が単一の組織（マトリックスの腕）に報告する場合、開発における規約と手法の標準化に役立ちます。テストなども同様です。
  • すべての開発者が長期的な開発/エンジニアリングマネージャーを持っている場合、メンターシップ、トレーニング、および能力全般の育成に役立ちます。テストなども同様です。
  • プロジェクトに、交換可能とされる開発者、テスターなどのプールから人員を配置することで、人材の活用を最大化（ひいてはコスト効率を向上）するのに役立ちます。

ただし、アクティビティ指向のチームは、有用なソフトウェアの提供という大きな全体像ではなく、自分たちのアクティビティを最適化しがちです。これは、彼らが責任を負わされていることと、どのように評価されているかの結果です。開発者のみのチームがベロシティのみで評価されることはよくあります。彼らがスコープの提供のみを課せられている場合、それが解決するはずの問題を解決するかどうかについて考えることはありません。たとえそうしたとしても、製品管理チーム（仕様の決定のみを担当する別のアクティビティ指向チーム）によって妨げられる可能性があります。

アクティビティによる組織化は、チーム間で引き渡される作業のバッチサイズを小さくすることを妨げます。テスターの別チームは、開発者チームから一度に1つのストーリーを受け入れません。彼らは、リリースに値するストーリー、または少なくとも一度に機能内のすべてのストーリーをテストすることを好みます。これにより、フィードバックループが長くなり、エンドツーエンドのサイクルタイムが長くなり、全体的な応答性が損なわれます。

高速ITは、やる気のあるチームを必要とします。自律性は、チームにとって重要なモチベーターです。ただし、アクティビティ指向の組織は、自律性を自分たちのアクティビティの領域を最適化するために使用する傾向があるため、それほど多くを与えることはできません。

アクティビティ指向の組織のバリエーションは、次の結果をもたらす可能性のある、超特化したチームです。

  • ツールまたはスキル中心のチーム：例：WebSphere Portal ServerチームまたはBizTalkチーム
  • アーキテクチャレイヤーチーム：例：プレゼンテーションレイヤーチーム、ミドルウェアチーム、データレイヤーチーム。

これらは、焦点が狭く、全体像よりもチームのパフォーマンスを最適化する傾向があるため、問題があります。確かに、一部のツールには専門家が必要になる場合がありますが、それを別のチームに隔離する理由にはなりません。専門化が問題なのではなく、専門化のラインに沿って組織化することが問題なのです。

よりうまく機能するもの

ソフトウェア開発は反復的な設計プロセスです。真の反復を実現し、迅速なフィードバックの価値を認識するためには、そのアクティビティを可能な限り単一のチーム（共通の報告ラインを持つ）で実行する必要があります。多くのインターネットビジネスおよび独立系ソフトウェアベンダー（ISV）は、すでにこの方法で運営しています。

Sriramの本では、アジャイルアプローチを使用して効果的なIT組織を構築する方法について詳しく説明しています。

アクティビティ指向の組織は、利用率を最大化するという観点からは魅力的かもしれませんが、価値付加とエンドツーエンドの応答性を最大化することを妨げます。今日のビジネス環境では、市場の応答性（時間効率）は、特にソフトウェア開発などの資本支出項目に関しては、コスト効率よりも重要です。さらに、太線のレポートは、応答性と価値付加という最も重要な目標に合わせる必要があります。

整合された報告構造がない状態でコンピテンシーを効果的に育成するためには、メンターシップ能力とコミュニティイベントを組織し、書籍を購入し、トレーニングを手配する予算を持つ専門コミュニティリードとともに、実践コミュニティを立ち上げます。これらのコミュニティは、標準化をやりすぎることなく、規約と手法の標準化にも役立ちます。安定した報告マネージャーを持つことに関しては、それはプロジェクト中心のITでのみ問題になります。ビジネスケイパビリティ中心のセットアップにより、安定した報告マネージャーが可能になります。

謝辞

コメントをくれたBill Codding、David Wang (Wang Wei)、James Lewis、Kief Morris、Patrick Kua、Patrick Sarnacke、Steven Lowe、Venkatesh Ponniahに感謝します。コンテンツのガイダンス、出版の支援、そして素敵なイラストを提供してくれたMartin Fowlerに特に感謝します。