InfoQ

InfoQ

News

マイブックマーク

ブックマークするためにログイン または 会員登録 する

ブックマークされました!

ブックマークがエラーになりました。もう一度お願いします。

アジャイルコーチの秘訣、トップ10

作者 Mark Levison , 翻訳者 笹井 崇司 投稿日 2009年9月13日

セクション
プロセス/プラクティス
トピック
Agile
タグ
コーチング&メンタリング

原文(投稿日:2009/09/03)へのリンク

CoachingAgile Coachingの著者、Rachel Davies氏とLiz Sedley氏により、“Top Ten Tips for Agile Coaches”(「アジャイルコーチの秘訣、トップ10」)という、おもしろいセッションが開かれた。このセッションは「多くのアジャイルコーチができてないこと、トップ10」と呼んでもよかっただろう。

自己紹介をしよう – コーチが初めて(既存の、もしくは新しい)チームにやって来たときというのは、忘れられない出来事だ。コーチが何者なのか、なぜそこにいるのか、そもそもその仕事をする資格があるのかさえ、チームにはよくわからない。こういうときには、年長者(マネージャやチームリーダー、あるいはとても尊敬されている人)から自己紹介をすると、不安をやわらげる効果がある。コーチはその背景や目標についても説明しておくべきである。

アジャイルは宗教じゃない – チームのメンバはアジャイルなんかどうでもよくて、とにかく仕事が完了すること、給料が上がること、そしておそらく昇進することで頭がいっぱいだ。だから、現在取り組んでいる問題を解決するのに役立つことにしか関心がない。私たちはコーチとして、時間をかけて、状況を理解し、話を聞く必要がある。最も重要なのは、チームの懸念を聞いてくれたと感じてもらうことだろう。

敬意を払おう – チームの抱えている問題をすべて解決しようとしてはいけない。どうやって今の状況に至ったのかを理解しよう。言葉には注意しよう。例えば、チームメンバは人であり、単なるリソースや開発者、テスタ、マネジメントというものではないのだ。

一歩離れて見よう – 私たちコーチは、全体像を見ずに、チームが提起した問題に目がいってしまうことが多すぎる。人をどうにか元通りにしようとしてはいけない。 – たいていの場合、彼らは組織のプレッシャーに反応しているだけなのだ。代わりに一歩離れて、システム思考を活用して、そのプレッシャーを見つけよう。そして、そのプレッシャーを解消することに注力しよう。

時間をかけて考えよう – 私たちはついカッとなって問題に反応してしまうことが多い。ムッとして即座に反応するのではなく、立ち止まって、時間をかけて考えよう。他のコーチとも議論しよう。ことによると、一晩考えてみてもよいだろう。

質問しよう、アイデアを語ろう– チームがどのように動いているのか/仕事をしているのかを理解しようとするときには、「どうやって」と「何を」という質問をしよう。Liz氏によると「なぜ」という質問は避けた方がよいらしい。「なぜ」という質問をすると、たいていの人は守りに入ってしまうためだ。「なぜ」という質問は根本原因分析のためにとっておこう。 – 慎重に使おう。シェアすべきおもしろいアイデアがあれば、チームに語ろう。ここで質問をしてはいけない。あなたのやっていることを見透して、不快に感じてしまうだろう。

みんなが避けている重要な問題を切り出そう – 大きな問題は無視されてしまうことが多い。みんなどうせ解決できないと思っているためだ。これを見逃してはいけない。ふりかえりの場を利用して、「みんな避けているけど…」と切り出そう。その問題に少しずつでもチームが取り組んでいけるよう手助けしよう。結果がどうあれ、まだチームの準備ができていないなら、無理に行動させてはいけない。

変化を1つの実験だと考えよう – 人は変化に怯えてしまうものだが、変化を1つの実験だと考えることで、その不安を貴重な経験にすることができる。チームメンバを変化に巻き込むことで、彼らはそれを自分のものにし、小さな変化をすることに慣れていく。ふりかえりは、こうした実験を取り入れるのによいタイミングだ。

チームの実力に合わせよう – いつもチームが直面している最大の問題を解決しようとするのではなく、チームには何を解決する力があるのかを見いだそう。まずは小さな問題を解決することで、自信と喜びを得ることができる。経験を積むにつれ、向上心と実力が養われるだろう。

信念に従って行動しよう – 定期的に、あなたの信頼は傷つき、疑念をもたれることだろう。勇気をもって自分を信じよう。しかし何より、我慢しよう。私たちはチームに非常に大きな変化をもたらそうとしているのだ。私たちはこうした変化をすでに会得しているのだが、チームはまだこれからなのだ。

聴衆からも、いろいろな秘訣が紹介された。

  • 静かにしているか、黙っていよう – 最善の介入とは、ときには全く介入しないことである。 (Tobias Mayer氏)
  • 離れてみよう – コーチがいないときには、チームは自ら問題を解決することを学ばざるを得なくなる。
  • クライアントの言葉を学ぼう – クライアントの問題領域を理解することは、懸念を解消するのに役立つ。
  • 意のままに推し進めてはいけない: 提案をしよう、それも簡潔に。そうしたら立ち去って、しばらく待ってから、また戻ろう。
  • 大きな目標へ向かう中間地点として、積極的に小さな成功を得ることに注力しよう。
  • チームメンバを人前で批判してはいけない。問題にはこっそりと対処しよう。
  • コーチングに関するバックログを作って、チームに優先順位付けをしてもらおう。そうすれば、チームにもっと主導権を与えることになるだろう。 (William Rowden氏)

以前の記事:InfoQの「初心 ― 聴くことへの入り口」、ブログのCoaching Workshop

特集コンテンツ一覧

GAE開発の落とし穴

Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します

イベントレポート:「Coqチュートリアル#1」

去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。

Javaの未来についてのNeal Gafter氏とのディスカッション

Choosing Options

Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。

Google Dartのエッセンス:アプリケーションの構築、スナップショット、Isolate

GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式

CSPベースのモデル検査ツール「Process Analysis Toolkit」

本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。

Jenkinsによる継続的インテグレーションのススメ(4) ~CloudBeesでJenkinsをサービスとして使う~

前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。

書籍『抽象によるソフトウェア設計-Alloyではじめる形式手法-』の紹介

Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。

Windows デバイスで開発するタッチユーザーインターフェイス

スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。