成功するディシプリンド・アジャイル・デリバリー・チームを編成するための 5 つのヒント

「ディシプリンド・アジャイル・デリバリー (DAD: Disciplined Agile Delivery)」とは、大規模なソフトウェア開発チームが小規模なソフトウェア開発チームと同様にアジャイル開発で成功を収められるよう支援するために IBM が提唱している一連のプラクティスです。DAD は単なるアジャイル手法の 1 つではありません。DAD は、既存のさまざまな実証済みアジャイル・プラクティスから最も優れたガイダンスを選び出して組み合わせたハイブリッド・フレームワークを提供します。DAD はさらに、一般的なアジャイル手法を企業向けのガイダンスで補完します。そのため、20 名を超える規模のプロジェクト・チームを抱える組織がアジャイル開発手法から最大限の成果を得るために利用できます。DAD チームを編成する際には、考慮すべき事項が数多くあります。そのうちの最も重要な 5 つが、この記事のテーマです。

Mark Lines, Co-founder, Unified Process Mentors

author photoUPmentors.com の創設者である Mark Lines は、20 年以上ソフトウェア開発に携わっています。彼は IBM Rational コースで講師を務めるとともに、クライアントが RUP を軌道に乗せ、カスタム・プロセスを実装するのを支援する RUP メンタリング・サービスを行っています。また、IBM developerWorks の RUP Forum のファシリテーターである彼は、IBM Methods Client Advisory Group のメンバーでもあります。



2013年 4月 18日

はじめに

アジャイル手法の中核となる精神は、2001年に発表されたアジャイル・マニフェストによって定義されましたが、最近になって IBM が「ディシプリンド・アジャイル・デリバリー (DAD: Disciplined Agile Delivery)」という名前の一連のプラクティスを提唱しています。これらのプラクティスは、小規模なソフトウェア開発チームが過去 10 年間にわたってアジャイル手法によって収めてきた成功を、大規模なソフトウェア開発チームでも実現できるように支援するためのものです。DAD は、既存の一般的なアジャイル手法が無秩序であるという理由で提唱されているわけではありません。実際、ほとんどのアジャイル手法には、従来の手法や場当たり的な手法よりも厳しい統制と厳密さが必要です。けれども、複雑なエンタープライズ環境での大規模なアジャイル・プロジェクトとなると、その現実に対処するためのガイダンスが常に存在するとは限りません。

DAD は、Scrum、XP、Crystal、FDD、DSDM などの既存のさまざまな実証済みアジャイル手法から最も優れたガイダンスを選び出して組み合わせたハイブリッド・フレームワークを提供します。これらの既存のアジャイル手法の 1 つひとつに価値があるとは言え、各手法はいろいろな意味で完全ではありません。アジャイル手法の実践者たちは通常、複数の異なる手法を継ぎ合わせることにより、比較的まとまりのある結果を得ているのが現状です。IBM Chief Methodologist for Agile/Lean IT である Scott Ambler (敬称略) は、さまざまな手法から最も優れたガイダンスを集めて、DAD フレームワークを完成させました。Scott に協力できたこと、そして DAD のプラクティスを自分自身のプロジェクトで使用できることは、私にとって非常に幸運なことだと思っています。

DAD はまた、一般的なアジャイル手法を企業向けのガイダンスで補完します。例えば DAD では、チームがバックログなどの主流の概念を次のレベルに引き上げて、大規模なエンタープライズ環境に適応させる方法を示します。こうすることにより、自分が直接所属する開発チームの枠を超えて、エンタープライズ・アーキテクトやデータベース管理者などの全社的な責任者と協力できるようになります。一部の開発者は、アジャイル手法の導入後は、自分のチーム以外の開発者や分野に関与する必要はなくなると思っていますが、それは誤解です。ほとんどのアジャイル・チームは、他のプロジェクトや組織内の他の責任者と協力する場合はなおさらのこと、チーム外部にも目を向ける必要があります。

多種多様なアジャイル・プロジェクトに開発者およびチーム・リーダーとして関与してきた私個人の経験を基に、アジャイル開発の原則に従ったプロジェクトで大規模なチームを管理する上での課題を検討するのに役立つアドバイスを提供します。ここで取り上げるのは、20 名を超える開発者からなるアジャイル・プロジェクト・チームを編成する際に考慮すべき事項のほんの一部ですが、これらのヒントに従うことで、大規模なアジャイル開発チームを上手く管理できるはずです。


ヒント 1: 万能のスペシャリストを採用すること

従来の手法では、専門分野に極めて特化したメンバーからなるチームが、最終的に顧客にとってより良い成果を生み出すものであると考える傾向がありました。けれども私たちは、実際にはその正反対であると判断しています。多くの場合、プロジェクトの関係者が専門分野に特化していればいるほど、完全な文書、完全なコード、完全なモデルにしようとしがちです。さらに、専門分野以外のスキルを持ち合わせていないスペシャリストに依存するチームは、非効率になる可能性もあります。例えば、データベースを理解しているメンバーがチームに 1 人しかいなければ、チームの作業に遅れが出る可能性があるだけでなく、実際に動作するソリューションを利害関係者の手に渡すプロセス全体が遅れる恐れもあります。

DAD では、「万能のスペシャリスト」でチームを編成することを奨励しています。万能のスペシャリストとは、専門分野を持っている一方で、ソフトウェア開発のライフサイクルにおける複数の分野に関する一般知識もある人物のことです。例えば、アナリストが要件のスペシャリストであるだけでなく、テストに関する一般知識も持っていれば、チームのテスト作業が遅れている場合、そのアナリストがテストに協力することができます。

私が現在取り組んでいるプロジェクトでは、開発者たちはこれまで専門としていたコーディング作業とは別に、デプロイメントおよび継続的インテグレーションのためのスクリプト作成を支援するために時間を費やしています。これにより、どの開発者もインフラストラクチャーや構成の管理に関する一般知識を深めています。別の例として、テスターが焦点とするのは、通常、ユーザー・インターフェースや、ブラックボックス的な観点でのソフトウェアの動作ですが、アジャイルの世界では、テスターはよりテクニカルになる必要が増してきているとともに、開発者の意図を汲んで考える必要も増してきています。テスターがユーザー・インターフェースから機能をテストするだけでなく、自ら実行するテストのコードを作成できれば、チームによってより有用な存在になります。


ヒント 2: 知力よりも共同作業の能力を重視すること

優秀なメンバーからなるチームでも、時には期待される結果を出せないことがあります。賢い個人を集めたからといって必ずしも優れたチームになるとは限りません。メンバーが共通のゴールを目指して協力することで、初めて成功することができます。これまで、非常に優秀な人材が共同で作業するのを嫌がり、単独で作業するのを望んでいるのを目にしたことがあります。皆さんが属する組織の中にはそのような人物にふさわしい役割があるかもしれませんが、アジャイル手法で開発およびデリバリーを行うチームにはないはずです。

さらに、すべてのプロジェクト・チームにスーパースターを配属できるわけではないという現実もあります。私たちに必要なのは、スーパー・プログラマーだけで構成されるのではない、平均的でありきたりの能力を持つメンバーによるチームで生産的かつ効率的に作業する方法を学ぶことです。したがって、私がチームのメンバーを集めるときには、能力と信用があると同時に共同作業に適した人物を探します。つまり、自分だけではすべてを理解することはできず、互いに学ぶべきことがあるということを現実的に理解しており、エゴを捨ててチームに参加する人物です。


ヒント 3: 当面のプロジェクトに適した規模のチームを作ること

DAD ではチームを、典型的な小規模チーム、中規模チーム、大規模チームという 3 つのレベルで表します。もちろん、DAD が対象としているのは中規模から大規模のチームです。例えば、複数の大規模チームが、コンポーネントを共有して複数のサブプロジェクトを同時に進めている場合、各グループおよびそれぞれのチーム・リーダーが共同で作業する方法を検討することが重要になります。ここでポイントとなるのは、従来のアジャイル理論では、チームだけで完全なソリューションを実現できることを前提に小規模な自給自足型チームを提案していますが、規模が大きくなれば、チームの枠を超えて、専門のスキルを持つ外部の人間も関与させなければならなくなるということです。

一例として、私が現在取り組んでいるプロジェクトでは、非常に大規模なシステムを実現するために 12 種類のテクノロジーを扱っています。「万能のスペシャリスト」の原則は当然適用しますが、チームの全メンバーがこの 12 種類のテクノロジーすべてについて完全に理解できると考えるのは、まったく現実的ではありません。そこで、チームの足りない部分を補うために、インフラストラクチャー関連の関係者 (Linux エキスパート、数名のデータベース専門家、セキュリティーとファイアウォールのスペシャリストなど) の協力を得ています。

このような大規模プロジェクトでは、本番環境へ移行する際に、例えば DevOps チームや企業の環境の最新化に取り組むチームの協力が必要になってきます。つまり、システムはそれ単独では存在していないということです。現在私が取り組んでいるプロジェクトは既存のシステムに統合することになっており、本番環境へ移行されるすべてのものは、厳しい変更管理プロセスによって厳重に管理されています。そのため、プロジェクトを順調に進めるために、チーム外部の関係者と定期的に情報を交換しています。

DAD には、プロジェクト発足の一環としての初期計画に関するガイダンスも含まれています。このガイダンスは、複数の異なるチームが共同作業する際に大いに役立つはずです。特殊なプロジェクトの場合、解決しなければならないビジネス問題や必要となるソリューションについて初期の構想を立てておかなければなりません。この構想に、ビジネス・ケースの大まかな概要、技術アーキテクチャー案、リスクの要約、そして実際に妥当なプロジェクトであることを利害関係者に同意してもらうために必要なその他諸々の情報を含めることができます。


ヒント 4: アジャイル・リーダーシップの原則とチームの編成を理解し、当面のプロジェクトに柔軟に対応すること

小規模チームのアジャイル手法 (Scrum など) では、ソフトウェア開発において、マネージャーが作業分解図を作成し、チームにタスクを割り当て、各タスクに必要な時間を指示するというリーダーシップの指揮管理体制が問題であるという事実に対処します。アジャイル手法の実践者たちは、そのような決定を行うのに最も適任なのは、実際に作業を行っている者であることを認識しています。開発者たちは自分たちが行うタスクを特定し、見積もりを行い、タスクに進んで取り組み、自分たちの間で作業を分担します。プロジェクト管理者という役割を明示的に定義しなくても、彼らは本質的に、自己組織化されたチームとして上手く機能します。プロジェクト管理者の代わりに、チームではプロセス全体が円滑に進行するように導くチーム・リーダーとして特定のメンバーを指名します。

DAD で使用しているプロダクト・オーナーの概念は、Scrum から直接採り入れたものです。実際、DAD ではこの役割をまったく変更していません。プロダクト・オーナーは、作業範囲、優先順位を決定し、完了させる必要がある作業の要件を明確にし、ソリューションのプロダクト・ビジョンを持ちます。その一方で、DAD の実践者たちは、大規模で複雑なプロジェクトには、プロダクト・オーナーを支援するドメイン・エキスパートをチームに加える必要があるかもしれないことを認識しています。

DAD にはプロダクト・オーナーと似た、アーキテクチャー・オーナーという別の役割もあります。チームに有能な開発者がいるのに越したことはありませんが、ソリューションを実現するためのアーキテクチャーに関するビジョンを持ち、技術上の重要な決定について説明できる人物がいることも重要です。アーキテクチャー・オーナーがチーム外部の重要な責任者 (エンタープライズ DBA やエンタープライズ・アーキテクトなど) と協力して、開発チームが行う決定が企業全体の標準およびガイドラインに矛盾しないようにする場合もあります。つまり、アーキテクチャー・オーナーはプロジェクトの技術エキスパートとして、これらの利害関係者と定期的に打合せを行うということです。

チーム・リーダーとしての私は、アーキテクチャー・オーナーに大いに頼っています。現在、私のオフィスには 25 名のメンバーがいます。これは従来のアジャイル・プロジェクトで編成するようなチームよりも大きな規模ですが、プロジェクトを DAD プロジェクトとして拡大する好例です。私の左隣の席にはアーキテクチャー・オーナーがいるので、以下のような質問をいつでも尋ねることができます。

  • 適切な人材がそれぞれに適切なタスクを担当しているかどうか?
  • 技術リスクを軽減しているかどうか?
  • どのチーム・メンバーが支援を必要としているか?支援を必要とするチーム・メンバーを誰かと組ませることで、作業の支援が得られるようにしたほうが良いか?
  • 企業内に、私たちが利用できる可能性のある既存の技術資産や技術パターンが存在するか?

このような大規模なチームではなおさらのこと、チーム・リーダーが開発者それぞれの作業状況を詳細に認識することは困難です。そこで私は、チームが有効に機能するように支援するのをパートナーであるアーキテクチャー・オーナーに頼っています。

アーキテクチャー・オーナーは別の意味でも重要です。プロジェクトには、プロジェクトの枠を超えた依存性 (例えば本番環境、ビジネス・ニーズ、レガシー・データ、古いシステムなどへの依存性) があることを考えると、アーキテクチャーがプロジェクトにリスクをもたらす可能性は大いにあります。アーキテクチャー・オーナーは、これらのリスクをできるだけ早く軽減するために、反復開発の早い段階で実装するとよい作業項目を決定します。この DAD プラクティスは、「リスクと価値によるライフサイクル」と呼ばれています。これが、作業の優先順位をビジネスの価値のみで決める他のアジャイル手法と DAD が異なるところです。アーキテクチャー・オーナーは、プロジェクトの後のほうで修正すると非常に困難で費用がかかる極めて重要な技術リスクをチームが理解し、さらにこれらのリスクを軽減するにはどのような要件を取り込んで満たさなければならないかまでをチームが理解できるように支援します。


ヒント 5: チームに経験がない場合は特に、自己組織化されたチームに注意を払うこと

自己組織化されたチームとは、アジャイルの素晴らしい概念です。チーム・メンバーは自分たちのプロセスをどのようにカスタマイズすれば最も効率的であるかを一番良く知っています。チーム・メンバーは共同で作業する方法を学んでいるため、協力することができます。例えば、ハルというチーム・メンバーは、ジュリーに e-メールを送信すれば良いのか、あるいは直接会って話し合うほうが生産的であるのかを知っています。もちろん理想的なのは、要求されているソフトウェアを作成するという任務を果たす上で不可欠なスキルがチームにあることです。実際のところ、技術的に長け、ソフトウェア開発におけるベスト・プラクティスを十分に理解し、アジャイル手法の知識がある開発者にとって、自己組織化されたチームは非常に効果があります。

新しく結成したばかりのチームや経験の浅いチームの場合、このような開発者が存在しない可能性があります。また、そのようなチームは、アーキテクチャーや要件に対するソリューションをモデル化する方法を理解していないかもしれません。もっと根本的なこととして、チームにとってアジャイル手法は初めてで、今までとは異なるプラクティスを理解していない恐れもあります。

したがって、チームを自己組織化させるときには、スキルと経験も考慮しなければなりません。スキルと経験が欠けていると、混乱を招き、統制のとれていないチーム環境になる可能性があります。さらに、個々のメンバーも考慮の対象となります。チーム・メンバーのなかには、どのタスクを実行するべきか、あるいはどの順番で実行するべきかを決定する作業に慣れていないメンバーもいます。なかには、従来のように指示される側になることを選ぶメンバーがいるかもしれません。チーム・リーダーは、そのようなメンバーの態度と習慣を敏感に察知して、日常業務に関して催促したり、指示を与えたりしなければならないタイミングを理解する必要があります。

このヒントで理解する必要がある本質的な点は、自己組織化されたチームは有効に機能しますが、チーム・リーダーがどの程度チームに自己管理を任せるかは、チームの成熟度と能力によって決まるということです。優れたチーム・リーダーは、チームに全権を任せてチームの好き勝手にさせることはしません。チームが行っていることを把握し、チームの作業が順調に進むように常に監視を怠らないのが、優れたチーム・リーダーです。


おわりに

主流のアジャイル理論は、高いビジネス価値を持つソフトウェアを顧客に配信する確かな基盤を提供しますが、やや理想論的になりがちです。アジャイル理論で描かれている開発エクスペリエンスは必ずしも、Scott Ambler と私が大規模なプロジェクトで日々目にしている類いのものではありません。アジャイル手法は適切に実践すれば効果があるため、私たちの目標は、既存のアジャイル手法を白紙に戻して新たに考案することではありません。しかし、既存のアジャイル手法とアジャイル理論との間には、私たちが埋めようとしているギャップが存在します。

私たちは DAD で規範を示そうとしてはいません。例えば、私たちはユーザーのシナリオでの作業項目リストに要件を示していますが、代わりにユース・ケースのシナリオを適用したい場合には、その判断はお任せします。DAD はフレームワークです。DAD に意図されているのは、それぞれのアジャイル・プロジェクトのニーズに最適な手法をそこから選択することです。


まとめ

DAD は、大規模なソフトウェア開発チームがアジャイル開発プロジェクトで成功を収める上で役立ちます。DAD は既存のさまざまな実証済みアジャイル手法から最も優れたガイダンスを抜粋して組み合わせたフレームワークであるだけでなく、一般的なアジャイル手法を企業向けガイダンスで補完します。そのため、20 名を超える規模のプロジェクト・チームを抱える組織がアジャイル開発手法から最大限の成果を得るために利用できます。DAD チームを編成するときには、ここで紹介したヒントに留意してください。具体的には、万能のスペシャリストを採用すること、共同作業の能力を重視すること、プロジェクトに適した規模のチームにすること、アジャイル・チームの原則とチームの編成を理解する一方で柔軟に対応すること、そして自己組織化されたチームに注意を払うことです。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Rational, DevOps
ArticleID=870566
ArticleTitle=成功するディシプリンド・アジャイル・デリバリー・チームを編成するための 5 つのヒント
publish-date=04182013