アジャイルの「自己組織化チーム」のパラダイムでは、チームのメンバに新しいスキルが要求されます。その中には、以前はプロジェクトマネージャに頼っていたかもしれない、人と接するためのスキルが含まれています。自己組織化へと移行しつつあるチームでは、彼らがコミュニケーションをとったり協力したりするための新しいやり方を学ぶのを支援する上で、管理する側が重要な役割を担うことがあるでしょう。しかし、どこから始めればよいのでしょうか？この記事では、発展しつつあるチームの自己組織化を壊さずに、新たなスキルを伝えるためのいくつかの戦略を提案します。そして、新しいスキルを身につけるのに役立つ資料のありかを提示しています。
「ソフトウェアを書くのが人間であることは、はっきりしています。... そして、そのことは無視されています。」 -- 「Agile Software Development」（邦訳：アジャイルソフトウェア開発(リンク)）の中でAlistair Cockburn氏が引用したGerald M. Weinberg氏の言葉
アジャイルがレベルを引き上げる
Alistair Cockburn氏は、プログラマはコミュニケーションをとろうとしない人たちだ、という誤った固定観念に異議を唱え(リンク)、次のように言っています。「プログラマは、自分たちが話したいと思うことについて、大抵の場合は彼らが関係しているプログラムについて、コミュニケーションをとるのが好きなだけなのです。... 彼らは、関係の無さそうな噂話に加わるのが好きではないだけなのです。」アジャイルとは異なるのは、部門間で協力し合うチームや顔を合わせてのコミュニケーションを重視していることです。これは開発者の有効性に「関連した」スコープを大きく広げます。
最近では、開発者達はプログラミングの優秀さに加えて、顧客のビジネス用語を話し、部屋の同じチームの仲間のボディ・ランゲージを読み解き、建設的なフィードバックを行うことを学び、そして性格の異なる人とのペアプログラミングのやり方を把握しなければなりません。アジャイルの作業の強度は、スループットの改善にあると考えられることが多く、チームの内外での複雑な関係に対処している間も生産的なままでいて欲しいという要求の増大によっても、もたらされるかもしれません。
一度小部屋の壁が取り払われると、比喩的に、あるいは（より正確には）文字通り、もはや隠れることは出来ません。マネージャやビジネス・アナリスト、あるいはテクニカル・ライターが「人と接するための才能」を見出すのを待っているのです。生産性を高めるためには、チームが自己組織化することは必要不可欠なことです。これは対人関係の、あるいは「ソフトな」スキルと言われるものが、次第にチームの日々の作業に入っていかなければならないことを意味しています。
誰を教育するべきか？
そのようなトレーニングは、チームの中のより成熟した、ビジネス寄りの役割のメンバに行うべきだと考えたくなります。そうではないのです！アジャイルは立場を平等にします。全てのメンバはチームの製品に等しく貢献するのです。チームはどのメンバの振る舞いからも影響を受けたり制約を受けたりするでしょう。スクラムの実践者でありコーチであるSimon Baker氏は、プログラミングの作業でさえ「社会的な契約、会話」であり、人と接するスキルの改善から恩恵を受けるということに気づかせてくれます(リンク)。
成功したペアプログラミングは、技術的なスキルと同じくらい効果的なソフト・スキルを必要としています。ペアを組んだ人はそれぞれ、相手に対して気を遣い、効果的に話を聞き、ボディランゲージを読み取る必要があります。そして考えを伝えたり、建設的な意見の相違を話し合い、決めつけたり相手を見下したりせずに代替案を提示する必要があります。手伝いを申し出たり、逆にお願いするタイミングを感じる能力が必要です。多くのプログラマがこうしたソフトスキルに苦労しているのは残念なことです。
では、どのようにチームを改善していくか？
マネージャは、チームやチームのメンバを「改善」する役割を担わなければ成らないのでしょうか？誰も彼もが全てのことをうまくできなければならないのでしょうか？私達は、全ての役割について、全ての人をクロス・トレーニングしなければならないのでしょうか？自己組織化チームにとって、こうした介入は新たなパラダイム導入のためにはマイナスになるでしょう。本当に効果をあげるためには、コーチングするという姿勢のほうが適しています。チームが、どのように作業を分担し、誰をクロス・トレーニングするかを自分たちで決めるのを手助けするのです。目標はスキルセットの統一ではなく、有効性や、与えられた状況で効果が得られるものなのです。クロス・トレーニングの話題について、あるプログラマは次のように書いています(リンク)。
「ゼネラリスト化したスペシャリスト」(リンク)という造語を作った(リンク)Scott Ambler氏は、これに同意しています。私は、弱点の改善という前提には同意しません。才能を伸ばし弱点を知る、という前提を好みます。「汝自身を知れ」というのは、全てのことを学びスイス・アーミーナイフのように万能になることを指しているのではありません。
ゼネラリスト化したスペシャリストは、単なるゼネラリストにとどまりません。ゼネラリストが多芸は無芸であるのに対し、ゼネラリスト化したスペシャリストは多芸でありながら、いくつかの分野でも優れています。これは大きな違いです。
伝統的に、パフォーマンスの目標には、メンバ一人一人の知識向上のための計画も含まれていましたが、これらは非常にまれであり、そして１年後にどんなスキルがチームに必要になっているかを推測するのは難しいことです。実際の、現在の状況を対象としたトレーニングは、より効果的なものになるでしょう。しかし、マネージャはどのようにしたらチームに必要な助けやリソースをすぐに見つけ出すことができるのでしょうか。1つの出発点は、チームがそれらを探し出すのに任せることです。
チームが緊急の課題の解決策を探すのを支援する
チームが必要なスキルを学ぶのを助ける1つの方法は、彼らの進歩を妨げているものを見つけるように働きかけ、答え探しをサポートすることです。改善されたコミュニケーションの探求は、1つの試みとみなされるべきです。試し、良く考え、学び、再び試すという、チームが適用しているプロセスの改善なのです。雑誌や本、記事、論文、ポッドキャストといった、学習を促進する材料を提供して下さい。しかし、時間を資源として考えることを忘れないで下さい。コーチングや会議、Webサーフィンをしたり他のチームを訪れて解決策を見出すための時間を提供するか、次の反復に「学び」のタスクを追加します。何が自分達の価値を生み出す能力を邪魔しているのかについて、チームが自分たち自身の答えを見つけ出すと、学ぶことの恩恵を受け、続いてすぐに応用されます。トレーニングを印象付ける素晴らしいやり方です。
もし効果的であれば、チーム自身の継続的な改善への努力はニーズを掘り起こし、戦略を提案することもありえます。Esther Derby氏とDiana Larsen氏の著書「Agile Retrospectives: Making Good Teams Great（参考記事・英語）」（邦訳：アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き）は、チームが価値のあるプラクティスを開発する助けになるでしょう。
しかし覚えておいて欲しいのですが、この受身的なアプローチは、チームがトラブルを発見し、腹を割って話し、どこに助けを求めるかを推測する能力に頼っています。経験の浅いチームは、重要な「人と接することについての問題」に苦労するかもしれませんが、そのことが警告しているものを見逃して、これを頭痛のたねに過ぎないと考えます。そして、ストレスを抱えた状態で、トラブルが発生した際には、対策を探し始めるには最高の状態ではなく、習慣となっているパターンに戻るかもしれません。一部のチームにとっては、さらなる戦略が有用でしょう。
問題への新しい取り組み方を作る
小部屋から出てきたばかりのチームでは、建設的で協力的なミーティングに必要なスキルは、大きく欠けているかもしれません。外部からファシリテータを招くか、あるいはチームの中からファシリテータの才能のある人を見つけ出して、スクラムマスタまたはファシリテータとしてトレーニングして下さい。指名されたファシリテータは、チームが失敗を乗り越えて解決策を見つけるために力を貸すことが出来ます。ファシリテータは公平を保ち、議論からは外れます。－彼または彼女は、チーム自体が成長していく一般的な過程の一部として、チームが人と接することについての問題をもっと客観的に理解するように働きかけることが出来ます。
ファシリテーションは難しい会話からとげを取り去り、互いに影響しあい、問題を解決していくための新しい方法を作ります。例えば、新しいファシリテータ達が、彼らがほっと落ち着ける場所に集中しすぎると、チームの内部では、ステークホルダやチーム外の人に期待するのを忘れるでしょう。例えば外部のファシリテータは、初心者がミーティングやプロジェクトのスポンサーと打ち合わせを行い(リンク)、合意に達し、成功に向かって（参考記事・英語）チームを組織して、関係者全員が現実の最終目標に集中すること確実にする、といったことを学ぶのを手伝うことができます。
チームのメンバはおそらく、ファシリテーションを見ることを通して学ぶでしょう。－トレーニングを求めることさえあるかもしれません。チームの安定性やおかれた環境により、ファシリテーションは短期的な役割になるかもしれませんし、ファシリテータと一緒に、チームがますます自らファシリテートしていくようになると、その他の責務も引き受けられるかもしれません。HPやSiemensといった大企業で行われたように、内部の部門に仕えるために新しい「ファシリテータ」の役割が時々出てきて、ファシリテータのトレーニングに参加したり、問題や隔たりがある場合にはふりかえりを指導したりするでしょう。アジャイル・ソフトウェア・コミュニティのメンバには、Ainsley Nies氏(リンク)やDiana Larsen氏(リンク)、Esther Derby氏(リンク)が顔を連ねています。彼らは経験豊富で、こうしたことをこれまでに実践してきましたし、他の人たちが行うのを手伝うことができます。
なぜ問題が起きるまで待つのか？
多くの成功したチームを研究した後で、Alistair Cockburn氏は次のことを確認しました。－人々の弱点に関わらず－必ず当てにすることが出来るものが3つ(リンク)あります。
問題が発生する前でも、個人間のコミュニケーションスキルはプログラミングのスキルと同じくらい価値の高いものであることを、チームのメンバが理解するのに任せてください。そして、チームの部屋の中で何が起きるのかを静かに見守り、ふりかえりから何が明らかにされるか耳を傾けてください。－覚えておいて欲しいのですが、一部のチームでは、あいまいな問題と向き合うのに時間がかかります。そのため、彼らには働きかけるだけではなく、継続的なサポートすることが必要なのです。
集団力学や政治的な問題に敏感なチームのメンバに気をつけてください。「周りを見ている」だけで何が必要なのかを感じ取り、あえて人と接することについての論争を引き起こす危険を冒して、チームの善良なメンバとして反応する人がいるかもしれません－そしてあなたはおそらく、それが誰なのかを知って驚くでしょう。
例えばチームのメンバが、チームの部屋を関係者全員のためになるようにする方法が心配だと言うかもしれません。彼女自身でこの問題の解決に必要な情報を探してどうにかするよりもむしろ、マネージャが、チームの変化に貢献するために自分自身が利用可能な情報源をチームのメンバに提供するために、この機会を利用することもできるでしょう。この場合について、Cockburn氏の著書Agile Software Developmentで(リンク)は、チームの部屋を機能させる方法(リンク)－そして避けなければいけないこと－を示しています。メンタリングというアプローチがあります。２冊の本を用意して、何回かチームのメンバと会い、その資料が彼の状況にあてはまるかについて話すのです。
質問やメンタリング、提案、情報資源という形をとった指導を通して、マネージャは、チームが自主管理について高めつつある自信を侵害することなく、チームの力になることができるでしょう。
こうしたリソースはどこにあるのか？
「コンピュータの専門家のためのソフト・スキル」について、Webで探すのは難しいでしょう。何百万もの無関係な話題のブログに使われていないキーワードはどれでしょうか？そしてアジャイルの方法にはどの解決策があっているのでしょうか？アジャイルコミュニティから、マネージメントやコミュニケーション、ファシリテーションに関する本が出始めています。InfoQ.comのAgileコミュニティ（参考記事）やAgile Journal(リンク)等のニュースや、ScrumDevelopment(source)、ExtremeProgramming(リンク)、LeanDevelopment(リンク)、Agile Management(リンク)、LeanAgileScrum(source)等のアジャイルのメーリングリストを注意してみて下さい。こうしたリストには経験豊かな実践者達が集まっているので、初心者が適切な資料のありかを聞くのにも適しています。
Accelerating Your Effectiveness(リンク)（AYE）の年次大会がありますが、ここでは特にソフトウェアの専門家やマネージャがもっと対人スキルを学ぶのを支援することを目標にしています。AYEはGerald “Jerry” Weinberg氏を含む小さなコンサルタントグループによって2000年に発足しました。Weinberg氏は25年にわたってマネージャやソフトウェア開発者向けに有益な情報資源を提供しつづけています。（Weinberg氏はたくさんの本を書いており、1971年出版の「The Psychology of Computer Programming」（邦訳：プログラミングの心理学）はおそらく、プログラミングを個人とチームの努力として扱った最初のメジャーな本でしょう。 1997年に出版した「Quality Software Management, Volume 4: Anticipating Change」（邦訳：ワインバーグのシステム変革法 ソフトウェア文化を創る第４巻）では、ソフトウェアがアーティストを変えることを目的としています。）
AYEのカンファレンスは、ソフトウェアの今後の方向性を示す一握りの指導者達(リンク)が主催しています。AYEは経験豊富な実践者達の協力によるもので、彼らは価値のある様々な4日間のソフトスキルのカンファレンスを作りました。これを、彼らの専門家としての最も大きな出来事であると考える人たちもいます。こうしたスキルは、お互いに影響しあって学ぶのが最も効果的です。しかし、誰かを派遣することが出来ない場合は、カンファレンスのWebサイトから調べ始めるとよいでしょう。カンファレンスのコンテンツの大部分は 発表者の自己組織化チームやグループでの経験から生まれたものです。彼らの論文や発表資料は、過去のものから(リンク)カンファレンスのサイトに置かれています。その中には、2007年のものでは以下のものがあります。
- Dale Emery氏の「Rewriting the Story of Resistance」（抵抗のあらすじを書き直す）
- Esther Derby氏の「Peer-to-Peer Feedback」（ピア・ツー・ピアのフィードバック）
- Johanna Rothman氏の「Convincing Management that Context Switching is a Bad Idea」（コンテキストの変更は悪い考えであることを経営者に納得させる）
さらに、アジャイルアライアンスが毎年行っているAgile200xカンファレンス(リンク)では、コミュニケーションやファシリテーションのスキルに関するたくさんの実践的なセッションがあります。プロシーディングは有償ですが、セッションのプロポーザルやアブストラクトは無償で利用できますし、あなたのチームが興味を持っているトピックのことを考えている人達にたどり着く助けとなるでしょう。これは、調査の始まりに過ぎません。こうした人たちがブログを書いたり論文を発表している場所を見つけることによって、もっと参考になる著者やコーチがきっと見つかるでしょう。
アジャイルアライアンスの論文ライブラリ(リンク)も、情報を探すのに適したところです。コミュニケーションやファシリテーションのスキルに関する論文が、自己組織化(リンク)やコミュニケーション(リンク)、人(リンク)といったカテゴリに散在しているはずです。
そして、おそらくもっと時間があるときは...
私達には、十分な時間があるということは決してありません。しかし、私達がもっと多くのことをするために活用できる資源は、時間だけではありません！ Schwartz氏とMcCarthy氏(リンク)は、彼らが「個人の活力」と呼んでいるものが回復可能な資源であることを教えてくれています。
従業員達が定期的に活力を再度満たす助けとなるような、簡単そうに見える日常的な習慣を促進することで、組織は、働く人たちが肉体的、情緒的、そして精神的に回復する力をつけます。このような習慣には、特定の間隔で短い休みを取ったり、他の人たちに感謝の気持ちを表したり、中断を減らしたり、人々が一番好きで最も楽しむ活動にもっと時間を使うこと等が含まれています。従業員達が彼らの活力を取り戻すのを体系的に助けましょう。そうすれば、成果はすぐに損益に現れます。
彼らはワコビア銀行の例を引用しています。この銀行では「活力の回復」プログラムに参加した人たちは、融資による収益の前年比で、対照群を13％上回りました。そして預金による収益では、対照群の利益を20％上回りました。
Scott Ambler氏は、Agile Single Sourcing(リンク)（アジャイルにおける情報源の一元化）について話し、「アジャイルソフトウェア開発では、できるだけ軽く進めたいと思っていますし、そうする最も簡単な方法は、情報を記録するのに最適な成果物を選択すること」であることに気づかせてくれました。
チームが、成果物の小さな部分を扱う仕事の仕方だけを知っている専門家で構成されている場合、あなたはおそらく同じ情報をいくつかの場所で得ることになるでしょう。...人々が１つまたはそれ以上の専門分野を持っていて、ソフトウェアのライフサイクル全体に関する一般的な理解を持つゼネラリスト化したスペシャリストの場合、成果物を幅広く扱う仕事をし、同じ情報を複数の場所で得る必要性を減らすことができます。
実際、これは成果物の枠に収まりません。あなたのチームが現在作成しているドキュメントのどれくらいが、タイムリーで効果的な議論によって、あるいは適切な人に相談することによって、除外されるでしょうか。人と接することについての問題に恐れを抱いていないチームでは、共同作業がよりよく進み、決定は早く、「無駄になる」ドキュメントやコミュニケーションは減るようです。
さて、もしあなたがするべきことがたくさんあったら…人の活力やあなたのチームのメンバのコミュニケーションの効果を高めるようにしない余裕がありますか？もしあなたが本当に「時間が無い」場合は、管理をしているのはデスマーチ(リンク)プロジェクトで再調整が必要ではないかを自問してください。（代わりに、 Jerry Weinberg氏は、絶望的な要因の守護聖人である、聖人ユダに祈りを捧げる戦略を勧めていました。(リンク)。）
あせらない
こうした戦略や情報資源で武装しても、チームや個人が必要に応じて情報資源を「引き出す」ことができるようにしておき、自信を持つことは、管理する側がそれを押し付けるよりもむしろ重要です。そしてこの記事で最後の言葉は、コーチであり比喩に精通しているDale Emery氏のものです。
…「馬を水場に連れて行くことはできても、水を飲ませることはできない」というのは、「スマートな変革者である私達は、素晴らしいアイデアを人々に教えることはできますが、そのアイデアを採用させることは出来ない」ということです。
そして残念なことに、素晴らしい変革者である私たちには私たちの素晴らしいアイデアを人々に採用させることはできないのはもどかしいことです。
アイデアがあります。のどの渇いた馬を水場に連れて行ってみて、どうなるのか観察するのです。もし馬が疲れていたら、日陰の、横になって休めるような地面の柔らかい場所に連れていくのです。もし馬がおなかをすかせていたら、干し草や燕麦を与えてやります。もし馬がなにも欲しがっていなければ、放っておきましょう。
著者について
Deborah Hartmann(リンク)は二ヶ国語を話せるアジャイルの実践者であり、トロントを拠点に国際的に活躍しているトレーナでありコーチです。Deborah氏は仕事を、ビジネスにとって価値があり、かつチームにとって楽しいものにすることに熱心に取り組んでいます。彼女は大小の企業でアジャイル採用のコーチをしてきました。2006年4月からはInfoQのアジャイルコミュニティで執筆者のリーダを務めています。そしてカナダやアメリカで、XPやBarCampコミュニティのために様々なOpenSpaceカンファレンスをファシリテートしています。Naresh Jain氏と彼女はAgileCoachCamp(リンク)の共同創立者です。
InfoQの関連コンテンツ
「コミュニケーションの失敗のスパイラルをコントロールせよ(リンク)」でJoe Rainsberger氏は、AYEで学んだことを人と人とのコミュニケーションへの挑戦に適用しています。そして、２つの追加の資料を提供しています。
InfoQのアジャイルコミュニティ(参考記事)にある、チームワーク(参考記事)や対人コミュニケーション(参考記事)、自己組織化チーム(参考記事)、リーダーシップ(参考記事)に関する記事を是非お読み下さい。
写真著作権：「Matthew」（無実の人を守るため仮名）の写真は「Developer Abuse(参考記事・英語)」と呼ばれているアジャイルの広告コンテストで去年優勝したスチール写真です。
原文はこちらです：http://www.infoq.com/articles/agile-people-facilitation-skills
（このArticleは2008年3月24日に原文が掲載されました）