DADチームにおける役割

ディシプリンド・アジャイル・デリバリー(DAD)のフレームワークは、アジャイル・ソリューション・デリバリーのために、役割の強固なセットを推奨する。これらの役割の全体像を下図に示す。ご覧のように役割には2つのカテゴリーがある。

  • 主な役割
    これらの役割は、DADチームで一般に見られる(チームが直面するスケールの程度にかかわらず)。
  • 補助的役割
    これらの役割は、しばしば一時的に果たされる(スケーリングにおける課題に対処するために)。

3-roles

 

主な役割

主な役割は、スケーリングの程度にかかわらず一般に見られる。主な役割には次の5つがある。

  1. 利害関係者
    利害関係者(未翻訳)” とは、ソリューションの結果によって実質的に大きな影響を受ける人のことである。この点では、利害関係者は明らかにエンドユーザー以上の存在である。利害関係者は例えば次のような人である – 直接的なユーザー、間接的なユーザー、ユーザーのマネージャー、シニアマネージャー、運用スタッフ、プロジェクトに資金を供給する”gold owner”、サポート(ヘルプデスク)スタッフ、監査役、プログラム/ポートフォリオ・マネージャー、開発中のシステムと統合・連携する他のシステムに取り組む開発者、開発やデプロイに潜在的に影響されるメンテナンスのプロフェッショナル。DADチームは利害関係者と一緒にプロジェクトを通して日々仕事をするのが理想的だろう。
  2. チームメンバー
    チームメンバーの役割は、利害関係者のために実際のソリューションの創出に集中することだ。チームメンバーは、テスト、分析、アーキテクチャー、設計、プログラミング、計画、評価、見積り、その他多数の活動を、プロジェクトを通して適切に行う。注意してほしいのは、すべてのチームメンバーがこれらのスキルを全部持っているわけではないことだ(少なくともいまのところは)。しかし、彼らはこれらのスキルのサブセットを持っており、時間とともにより多くのスキルを手に入れるよう努めるだろう。チームメンバーは、コアアジャイル手法では”開発者”または単にプログラマーと描写されることがある。とはいえ、DADではすべてのチームメンバーが必ずしもコードを書くとは限らないことを認めている。チームメンバーは、タスクを確認し、タスクを見積り、タスクに”サインアップ”し、タスクを実行し、そして完了するまでタスクのステータスを記録する。
  3. チームリード
    アジャイルプロジェクトでは、従来のプロジェクトマネージャーの役割は大きく変わっている。それどころか、プロジェクトマネージャーという用語は、いまでは残念なことに眉をひそめられてしまうこともある。アジャイルコミュニティでは、チーム管理よりもプロジェクトやチームのリーダーシップにフォーカスしてきた – 「最良の”マネージャー”は計画や見積りのような技術的管理の課題よりもリーダーシップを優先する」と述べることで。自己組織的なチームの重要な側面は、チームリードがチームの技術的管理の活動を促進したり先導したりすることである(自分自身でその責務を果たすのではなく)。チームリードはチームにとってのサーバントリーダーであり、チームを成功させる状況を作ったり整えたりする。チームリードはまたアジャイルコーチであり、チームが次のことに集中できるよう援助する – ワークアイテムを実施すること、イテレーションのゴールやプロダクトオーナーに確約したことを果たすこと。そして彼/彼女は真のリーダーとして振る舞い、コミュニケーションを促進し、チームのプロセスを自己最適化できるようにし、チームに必要なリソースを確保し、チームの障害をタイムリーに取り除く。チームが自己組織化するとき、有効なリーダーシップは成功するために極めて重要である。
  4. プロダクトオーナー
    何百何千もの要求があるシステムについて、要求に関する疑問の答えを得ることはしばしば難しい。プロダクトオーナーはチームの一員として”顧客の声”を伝える。彼/彼女は利害関係者達のニーズや要望をアジャイル・デリバリー・チームに説明する。そうして、彼/彼女はソリューションに関する詳細を明らかにしながら、優先順位付けしたワークアイテムリストを管理する責務も果たす。それによって、チームはこのワークアイテムリストを実現し、ソリューションのデリバリーを実施するだろう。すべての疑問に答えられないことはあっても、タイムリーに答えを突き止めることがプロダクトオーナーの責務である。これによってチームが自分達の仕事に集中できるようになる。プロダクトオーナーがチームと密に協力し、実行することになっているワークアイテムについての疑問に答えることで、要求・テスト・設計のドキュメントの必要性を大幅に減少させる。もちろん、運用マニュアルやサポートマニュアルやユーザーガイド等のドキュメントは提供する必要がある。各DADチームまたはサブチーム(チームの中にチームが編成される大きなプログラムの場合)には、1人のプロダクトオーナーがいる。プロダクトオーナーの第2のゴールは、アジャイルチームの作業を利害関係者達に説明することである。これは、重要な利害関係者に向けて、ソリューションのデモを手配したりプロジェクトの状況を伝えたりすることを含んでいる。
  5. アーキテクチャーオーナー
    アーキテクチャーはプロジェクトのリスクの重要な源泉であり、チームがこのリスクを低減するのを確実なものにする責務を誰かが果たす必要がある。結果として、DADフレームワークはアジャイルモデリングにおける”アーキテクチャーオーナー(未翻訳)” の役割を明確に位置づけている。アーキテクチャーオーナーは、チームのためにアーキテクチャーを決定する責任を持ち、そしてソリューション設計全体の創造と進化をファシリテートする。小規模なチームでは、チームリードの役割をする人が、しばしばアーキテクチャーオーナーの役割を兼ねるだろう。いつもそうとは限らないが(特に規模が大きいと)、より小規模なアジャイルチームではよくあることだ。アーキテクチャーオーナーは一般にはチームの上級開発者であり、そしてときにはテクニカルアーキテクトやソフトウェアアーキテクトやソリューションアーキテクトであるのだが、他のチームメンバーが報告書を提出するような階層的な地位ではないことに注意すべきだ。彼/彼女は他のチームメンバーと全く同様であり、タスクをサインアップしたり引き渡したりすることが期待される。アーキテクチャーオーナーは、技術的なバックグラウンドとビジネス領域の十分な知識を持っているべきだ。

補助的役割

補助的役割は、しばしば一時的に、スケーリングにおける課題に対処するために導入される。補助的役割には次の5つがある。

  1. スペシャリスト
    大抵のアジャイルチームのメンバーはゼネラルスペシャリストであるけれども、ときには(特に規模が大きいと)、スペシャリストが必要になる。例えば、大規模なチームや複雑な領域では、1人以上のアジャイルビジネスアナリストが加わって、作ろうとするものに対する要求の調査を援助することがある。また、非常に大規模なチームでは、プログラムマネージャーに様々なサブチームのチームリードとの調整が求められることがある。DADチームでもスペシャリストが見られるだろうが、それはゼネラルスペシャリストを確保できない場合や、組織が初めてアジャイルを導入することになって、最初に配置されたスペシャリストがまだゼネラルスペシャリストに移行していない場合だ。
  2. ドメインエキスパート
    プロダクトオーナーは、エンドユーザーだけではなく幅広い利害関係者を代表している。微細にわたる専門知識を持つことを彼らに期待するのは妥当ではない(複雑な領域では特にそうである)。プロダクトオーナーは、ときにはチームと一緒に働くための専門家を連れてくるだろう。例えば、要求の詳細を説明するための税に関する専門家や、プロジェクトにとってのビジョンを説明するためのエグゼクティブスポンサーなどだ。
  3. テクニカルエキスパート
    時としてチームはテクニカルエキスパートの援助が必要になることがある。例えば、ビルドスクリプトをセットアップするビルドマスター、データベースの設計とテストを援助するアジャイルデータベースアドミニストレーター、使いやすいインタフェースの設計を援助するユーザーエクスペリエンス(UX)エキスパート、またはセキュアなシステムの書き込み処理を中心に助言するセキュリティエキスパートなど。テクニカルエキスパートは、必要に応じて迎え入れられ、臨時でチームが困難な問題を克服するのを援助したりチームの1人以上の開発者にスキルトランスファーしたりする。テクニカルエキスパートは、しばしば他のチーム(エンタープライズレベルの技術的な重要事項に責任がある)で働いたり、単に他のデリバリーチームから出向であなたのチームに来るスペシャリストだったりする。
  4. 独立テスター
    テストの大部分はDADチーム自身によって行われるけれども、並行作業する独立テストチームがDADチームを支援してライフサイクルを通して検証することもある。典型的には、この独立テストチームは大規模な状況でのアジリティのために必要である(複雑な領域、複雑な技術の使用、または規定遵守の課題への対処といった範囲内で)。
  5. インテグレーター
    複数のサブチームから編成された大規模なDADチームでは、サブチームは1つ以上のサブシステムまたは機能に対する責任がある。作ろうとしているシステムがより大きくより複雑になるほど、チーム全体がより大きくなる。このような状況では、チーム全体で1人以上のインテグレーター、すなわち様々なサブシステムからなるシステム全体の構築の責務を果たす役割が必要になる。より小規模なチームやより単純な状況では、アーキテクチャーオーナーが統合を確実に行う責務、すなわちより複雑な環境のためにインテグレーターが果たすような責務を担うことになる。インテグレーターは、しばしば独立テストチーム(もしあるなら)と密に協力し、システム統合テストを定期的にプロジェクトを通して行う。このインテグレーターの役割は、大規模での複雑な技術のソリューションのためにのみ必要となる。

なぜ多くの役割があるのか?

これは、スクラムに精通する人から私達が受ける共通の質問だ。スクラムには3つの役割(スクラムマスター、プロダクトオーナー、チームメンバー)がある。では、なぜDADには10も必要なのか? 主要な論点はスコープだ。スクラムは、主に構築フェーズ期間のリーダーシップと変更管理の側面にフォーカスするので、これを反映した役割がある。DADは一方で、完全なデリバリーライフサイクル と、ソリューション・デリバリーのあらゆる面に、スクラムが除外する技術面も含めてはっきりとフォーカスする。それで、より大きなスコープに対してより多くの役割がある。例えば、DADはアジャイルアーキテクチャーの事柄を網羅するので、アーキテクチャーオーナーの役割を加えている。スクラムはアーキテクチャーを扱わないので、そのような役割はない。

役割についての重要な考察

DADプロジェクトでは、各人には1つ以上の役割があって、個人は時間が経てば自分の役割を変えることができ、そしてある役割は誰もやらないか、または1人以上がその時々でやるだろう。例えば、Peterは、今はチームメンバーとアーキテクチャーオーナーの役割になっているとしても、現在チームリーダーのCarolが休暇を取る来月には、チームリーダーの役割になる。

役割は地位ではなく、また、そうあるべきでもない。例えば、Janeはプロジェクトの利害関係者の役割になっているとしても、組織では最高財務責任者(CFO)の地位にある。それどころか、プロジェクトに何百人の利害関係者がいようとも、誰も”利害関係者”という地位にはないだろう。

アジャイルは特定の役割を重視することなく、すべてのチームメンバーを対等とみなす – 誰もが動くソリューションを提供するために、職務内容にかかわらず協力する。この意味は、利害関係者を除いて誰もが効果的にチームメンバーの役割をするということだ。

従来の役割(ビジネスアナリストやプロジェクトマネージャーのような)は、DADには登場しない。従来の役割の人々が達成しようとするゴールは、例えばソリューションのために利害関係者のニーズ/意図を理解して伝えるビジネスアナリストの場合、DADでは異なる役割による異なる方法で取り組まれる。従来の役割とDADの役割が完全に1対1で合致することはない。しかし、ディシプリンド・アジャイル・デリバリーの書籍には理にかなった移行戦略がある。従来の考えを持つ人が理解すべき重大なことは、根底にあるパラダイムと戦略が変わったので、彼ら自身もDADのアプローチに取り組めるように変わらなければならないということだ。

このページの素材は、ディシプリンド・アジャイル・デリバリー:エンタープライズ・アジャイル実践ガイド(IBM Press, 2012)の第4章から改変されたものである。

オリジナル:Roles on DAD Teams
http://www.disciplinedagiledelivery.com/roles-on-dad-teams/
 (翻訳 大隈登)

LINEで送る
Pocket