スケーリングファクター

SDCF(Software Development Context Framework)は、ソフトウェア開発において、状況に合わせて適切な戦略を選択しテーラリングする方法を定義する。 SDCFは、ソフトウェアベースのソリューションをデリバリーするチームを対象に、その人材、プロセス、ツールを編成するためのコンテキストを提供するために使用される。 下の図1は、複数のセレクションファクターが、チーム構成(人員)、デリバリープロセス、およびツール構成の選択とテーラリングに影響を与えているかを示している。 もちろん、最初の選択は始めの一歩に過ぎない。あなたが直面している状況(これがスケーリングファクターだ)を反映して、これらの選択肢をテーラリングする必要がある。 このページのフォーカスは、セレクションファクターではなく、スケーリングファクターに合わせられる。

図1 戦略の選択とテーラリング

sdcf-selection-and-scaling

ピープル、プロセスそしてツールに関する戦略をスケールする。

図2は、6つのスケーリングファクターをまとめたもので、各ファクターの範囲を示している。 左側は極端に単純なケース、右側はもっとも難しいケースを表す。 長年にわたるさまざまなIT調査(もっとも最近のものは、2012Agility at Scale 調査)では、組織がこれらすべてのレベルでアジャイルを適用しているという証拠が見られた。

図2 スケーリングファクター

Context Factors

各スケーリングファクターを見ていこう:

  1. チームサイズ。 チームの規模は、2人から20人、さらに200人以上に及ぶことがある。 大規模なチームは、より複雑な問題に対処するために形成されるのが一般的であり、その結果、以下で説明するように、ドメインの複雑さや技術的な複雑性の増大という課題に取り組んでいる。 チームサイズは、チームの編成方法やチーム内での調整方法に直接影響する傾向がある。 たとえば、200名のチームがサブチームに編成され、それらを調整するためにリーダーシップチームが必要となる。 50人のチームもサブチームに編成されるが、その場合チーム間の調整は、各サブチームの代表者の日々の調整会議(スクラム・オブ・スクラムと呼ばれる技法)によって、より簡単な形で処理されるだろう。 10人のチームの活動を調整するのはかなり簡単だ。 詳細については、Large Agile Teamsを参照いただきたい。
  2.  地理的分散  アジャイルチームは、チームメンバーと主要な利害関係者とが同じ部屋にいることがあるかもしれない。ひとつのビルの同じフロアにいることもあれば、複数のフロアに散っていることもあるし、異なる建物で働く場合もあれば、自宅で働く場合もある。さらには異なる国で働くことさえある。よくある誤解は、アジャイルチームが同じ場所に存在する必要がある、ということだ。何年にもわたっていくつかの調査で見られたこの誤解は、誤っている。確かに、人々をできるだけ密接に働かせることは非常に良い考えだが、私たちが望むほど頻繁には起こらない。大規模なチームと同様に、プロジェクト全体でのチームメンバーの調整はより困難になり、その結果、より洗練された調整が必要になる。方向付けフェーズの間に初期のモデリングとプランニングにもっと投資することでーそれほど多くは必要ないがー、人が分散していることに起因するコミュニケーションリスクを低減することができる。プロジェクトの成功の機会を増やすには、プロジェクトの重要なポイントで人を飛行機で送り込む必要がある。旅行費用を測定するのは簡単だが、対面でのコラボレーションのメリットを数値化することが難しいため、多くの組織はそれを嫌がる。詳細については、地理的に分散したアジャイルチームを参照いただきたい。
  3. 組織の分散。 これは、複数の組織から人々がプロジェクトに関与するという概念を指す。 最も簡単な状況は、単一の組織内の同じグループ/部門からチームメンバー全員が来ているという状況だ。 複数のグループの人々が関わっていると少し難しくなる。 請負業者を雇うと複雑さは増す。 仕事の一部を外部サービスプロバイダーにアウトソーシングすることは、さらに困難になる。 いくつかのベンダーへのアウトソーシングは困難さを増し、自分の文化とはまったく異なる文化を持つ1つないしはそれ以上のサービスプロバイダーへのアウトソーシングはもっと困難になる。 組織が分散したプロジェクトは、大規模なチームと地理的に分散したチームに関連する課題を抱える傾向がある。 アウトソーシングが関与している場合、彼らは調達に関連するリスクを引き受け、次にアウトソーシングされた労力へのガバナンスを司る。
  4. コンプライアンス。  コンプライアンスには2つの形式がある。 一般に、より単純な形のコンプライアンスは、自分達で課しているものであり、おそらく、あなたの組織はCMMIまたはISOに準拠することを選択している。 第2の、そしてより困難なコンプライアンスの形式は、法令遵守です。 チームは、財務規制、プライバシー規制、またはライフクリティカルな規制に準拠する必要がある。すべての法令・規制は各々異なる要求をするものだが、プロセスの観点からすると、通常は追加の文書(しかし出来るだけ軽量に)や、レビュー(合理的にやろう)、文書化されたプロセス(筆者達がDADの提案をするように)を必要とする。
  5. ドメインの複雑さ  チームが取り組んでいるドメインや問題空間の複雑さ は、実に様々なものがあり大きく異なる。 このサイトのような、情報ウェブサイトはかなり簡単な部類だ。 電子商取引サイトはもっと難しい。 航空交通管制システムはさらに難易度が高い。 ドメインの複雑さが増すほど、先行モデリングと計画に投資したいと考える。 それほど多くは必要ないが、ー忘れないでいて欲しいのだがーそれでも今よりは必要だ。 同様に、ドメインの複雑さが増すと、アジャイルテストの戦略がより洗練されるようになる。 ドメインの複雑さが増すにつれて、プロダクトオーナーに大きな負担がかかり、より洗練されたアジャイルモデリングスキルとアジャイルビジネスアナリストのサポートが必要になる。
  6.  技術的な複雑さ。 DAチームは、さまざまなレベルの技術的複雑さに直面する。 その振り幅の終端、もっとも簡単なほうには、新しいテクノロジーで構築されたまったく新しいスタンドアロンアプリケーションの開発がある。 既存のサービスやデータソースを活用する必要がある場合は、より困難になる。 いくつかのテクノロジープラットフォームをサポートする必要がある場合は、さらに難しくなる。 複数の言語を使用して実装する必要があるともっと難しくなり、 既存のインフラストラクチャ(従来のデータソースを含む)をリファクタリングする必要がある場合は、さらに難しくなる。 ドメインの複雑さと同様に、技術的な複雑さが増すほど、ライフサイクル全体を通じて先行モデリングとより洗練されたテストが必要になる。 技術的な複雑さが増すと、アーキテクトオーナーに負担がかかり、アジャイル・アーキテクチャアジャイル設計の高度なスキルが求められる。

オリジナル Scaling Factors
http://www.disciplinedagiledelivery.com/agility-at-scale/scaling-factors/

翻訳:藤井 智弘

Pocket