Rashina Hoda 氏は、アジャイルの研究者で、 New Zealand、 WellingtonのVictoria University で博士を目指しており、米国 Louisiana State Universityから学士を取得している。
氏は、 New Zealand と Indiaで３年余り、企業ベースの博士号の研究の一部として、アジャイルのチームを調査してきた。彼女の研究成果は、世界中で出版されたり、発表されており、彼女は、Agile2008, Agile2009, そして XP2009 で発表した。
最近、５月に南アフリカの Cape Townで開催されるInternational Conference on Software Engineering (ICSE2010) に彼女の論文が受理された。世界中から３８０の応募があり，５２本が受理されたが、彼女の自己組織型アジャイルチームに関する論文は，その中の１つである。
彼女のICSE 論文の要旨は、自己組織型アジャイルチームに、実際起きていることである－チームが効果的な自己組織型になるには、どのような考え方、役割、態度がチームに必要なのか。
最近、氏は、自分の研究についてのいくつかの質問に答えた:
あなたの研究の背景、なぜこのような研究をやることになったのですか？
ここ Victoriaの博士号の研究の一部として，２００６年にアジャイルプロジェクトのマネージメントを調査し始めました。企業におけるアジャイル手法の使われ方を調査し、アジャイルの実践者がぶつかるいくつもの決定的な問題を深く理解しようと考えました。
あなたの研究では、「自己組織する」チームの重要性について述べてますね－何がチームを自己組織型にするのか、なぜそのようなチームは、指示されるチームよりいいのか、自己組織型が生まれるためには、何が必要なのか、述べてますね。
はい，その通りです。アジャイルチームは、本来、「自己組織型」になるはずなのですが、不幸にして、アジャイルチームが実際に、どのようにして、自分たちを自己組織化しているのかについて充分な情報がありません。
自己組織しているチームには、各イテレーションで自分たちのチームのゴールを選択する自由が与えられています[4]。彼らには、タスクを自分たちで割り当てる自由も与えられていて、マネージャがタスクを割り当てる、マネージャ主導ないし指示型のチームと比べてタスクとプロジェクト全体への責任感と所有者意識が高いです。自己組織型のチームは、職能上の枠を超えて仕事をし、専門知識の職務領域を超える柔軟性をもっていて、確実にリソースを最大限に活用し、協調を通して更に学習します。一方、指示待ちチームは、協調や知識の共有にとって有害な専門化にフォーカスします。最後に、 自己組織型のチームは、また自己反省と継続的な学習を大事にしますし、効果的にイテレーションのゴールを達成するので、成長するばかりでなく、仕事のより良いやり方や革新的な方法を見出せるようになります。一方、指示待ち型チームは、マネージャに決められた締め切りを守ることに集中し、自分たちの仕事のやり方を改善しようという動機がほとんどありません。
自己組織型のチームは、孤立していては機能しませんし、環境的要因に影響されます[1,4]。研究でわかった、最も重要な２つの環境要因は、上級管理層のサポートと顧客の関与です。チームの組織における上級管理層は、チームが自分たちを自己組織化できるように、チームに自由を与えられなければなりません。顧客は，チームをサポートし、開発プロセスに積極的に関わり、定期的に要件と説明そして必要に応じてフィードバックを提供しなければなりません。これら２つが，自己組織型が生まれるのに必要な、最も重要な環境要因です。
文書化されたアジャイルプラクティスは、すでにアジャイルプロジェクトに必要な様々な役割を定義しています。あなたの研究は、既存の役割（スクラム・マスター、アジャイルコーチ、開発者、テスター、顧客、SME, ビジネス・アナリスト、UIデザイナなど）を否定するのですか？
いいえ。我々が発見した役割は、自己組織化での役割です。－非公式で、自発的で、時間的に一時的です。－チームが直面した問題に対処するために生まれる役割です。これらは、確立された組織的な役割とは違います。－公式に、あらかじめ決められており、大抵の場合、永久的です。－これらは，コーディング、テスト，設計などのようにソフトウェア開発の確立された役割に基づいており、アジャイルでないチームにもあるものです。我々の研究でわかった、自己組織化での役割は、特に自己組織を容易にするために生まれますし、違った組織的な役割によって、果たされます。例えば、比較的新しいアジャイルチームでは、アジャイルコーチがメンターの役割をしますが、もっと成熟したチームでは、ベテランの開発者がその役割を果たします。つまり、この２つのケースに矛盾はないのです。そうではなく、確立された組織的な役割と非公式の自己組織型の役割の間には、対応があります。
あなたの論文では、チームに必要な６つの役割を定義してますね。それらを説明してくれますか。そして、これらの役割がこれまでに定義されたものと違う点を説明してください。
チームが自己組織するのを助けるために、我々が確認した、チームメンバが導入すべき６つの非公式な役割は [1]:
1. メンター は、アジャイル手法についての最初のガイダンス、理解，自信を与え、アジャイルのプラクティスにずっと従うことを励まします。この役割は、これまでのアジャイルコーチの役割に一番近いですが、私が言ったように、もっと成熟しているアジャイルチームでは、上級の開発者もその役をやります。
2. 調整役 は、顧客からのコミュニケーションと変更要求を調整します。顧客が開発チームと物理的に離れている場合で、顧客からの変更要求やコミュニケーションを調整することが難しい状況では、調整役は、存在しました。調整役は、開発者かビジネスアナリストがやります。
3. 翻訳者 は、コミュニケーションの改善のために、顧客のビジネス言語をチームによって使われる技術用語に翻訳したり、その逆の翻訳をします。この役は、ビジネス顧客と技術開発チームの間に存在する言語上の溝を埋めるために生まれました。ビジネスと技術の用語をよく理解し、翻訳できる人で、コミュニケーション能力が優れていれば誰でも翻訳者の役ができます。
4. チャンピオン は、パイロットチームを作り、組織中にもっと自己組織できるチームを広めるために、上級管理層から支持を獲得する人です。チャンピオンは、アジャイルコーチか（上級の）開発者がやります。
5. プロモーター は、アジャイルチームが効率的に働けるように、顧客の協力と関与を引き受けます。アジャイルコーチがその役をします。
6. ターミネータ は、アジャイルの開発方法に馴染めないために，チームの生産性を阻害するメンバーを外します。アジャイルコーチがやります。
組織は、アジャイルチームを作る時に人を募集して、これらの役割を確立すべきですか？
これらの自己組織型の役割は、チームが直面した特有の問題に対処するために自発的に生まれるもので、組織によってあらかじめ、公式に確立されるものではありません。これらの自己組織型の役割を知っておいて、必要なときに、これらのひとつあるいはいくつかの役割を担うことのできる人たちでチームを作ることを確実にすることは、役に立ちます。
あなたの研究は、将来の研究のどの領域を開拓するのですか？
自己組織型のチームについてより深く理解したことを発表する他に、我々の研究は、アジャイル手法を実践する際のいくつもの課題を明らかにしました。この中には、契約における交渉 [2]、顧客関与の欠如[3]、そして上級管理層のサポートに関する問題などがあります。我々の研究は、将来の研究領域では、これまで調査した以外の、異なった国々や文化における自己組織型のアジャイルチームまで広げていきます。
InfoQのインタビュに時間を割いていただきありがとうございました。
あなたは、これらの定義に同意しますか？あなたのアジャイルチームにはこのような役がありましたか？
リファレンス:
[1] Organizing Self-Organizing Teams. Rashina Hoda, James Noble, and Stuart Marshall. To appear in the proceedings of the International Conference on Software Engineering (ICSE), South Africa, 2010.
[2] Negotiating Contracts for Agile Projects: A Practical Perspective. Rashina Hoda, James Noble, and Stuart Marshall. XP2009, Italy, 2009
[3] Agile Undercover: When Customers Don't Collaborate. Rashina Hoda, James Noble, and Stuart Marshall. To appear in the proceedings of XP2010, Norway, 2010.
[4] Balancing Acts: Walking the Agile Tightrope. Rashina Hoda, James Noble, and Stuart Marshall. To appear in the proceedings of CHASE workshop at ICSE2010, South Africa, 2010.
コミュニティコメント