先日私はコーチングセミナーに出席したのですが、オランダ代表女子フィールドホッケーチームの監督Marc Lammers氏が、そのセミナーで基調演説をしました。オランダ女子チームはワールドカップ史上最高の成績を誇り(リンク)、これまでに6度優勝しています。監督のスピーチを聞く間に、なぜオランダチームがこれほどの素晴らしい成績を収めたかを理解し始めました。チームの成功は監督のコーチング法に負うところが大きいのです。Lammers氏は、チーム全体としての力と、チームメンバーとしての個々の力を、思いがけない方法で解き放つための非常に重要な要素を見つけたのです。実に感動しました。この論文では、氏が発見した原則を要約し、その原則をいかにしてソフトウェア開発に応用するかを説明します。
私自身スクラムマスターであり、Lammers氏が発見した原則が私のスクラムチームにも応用できるのではないかと思いました。その理由は、自動車の組み立てや、ホッケーチーム、ソフトウェア開発など、その種類に関係なく、この原則が本質的にあらゆる種類のチームに適用できるからです。この論文では、セミナー中に明かされたLammers氏のコーチングの秘密と経験、そしてそれを日々のスクラムやプロジェクトの実践に解釈し直す方法を分かち合いたいと思います。この知識があってもワールドカップで優勝はできないでしょうが、気をつけていないと、あなたご自身や顧客のとんでもない期待をはるかに越えて、あなたの開発チームが仕事を成し遂げるようになるかもしれません。
原則1:
効果的なコミュニケーションの力を利用する
Marc Lammers氏:
指導者として駆け出しの当初は、自分の言っていることを理解してもらうことにかなりのエネルギーを費やしました。ですから、私の素晴らしいコーチング戦略を長ったらしいスピーチで自チームの選手達に説明しました。選手に私の言いたいことを確実に理解させるために、「皆さん、分かりましたか？」と尋ねたものでした。皆がうなずいたので、私は満足でした。しかし、選手のプレーを見て、理解していなかったことが分かりました。
私の言ったことを聞いていないようでした。ですから、もっと大きな声で、より攻撃的に、そして対峙するような感じで話すようになりました。残念ながら、効果はありませんでした。私は自分の指導者にこう言いました --「才能がなくて耳の遠い選手が集まっても、大きな成果は上げられません」。するとこの指導者は、何もかも私の責任だと言いました。コミュニケーション調査の結果を見せてくれたのですが、この調査によって次のことが判明しました。人間が思い出せるのは、
私はハッとしました。それからは自由な意見を求める問いかけを行うようになり、選手に戦略を言い換えさせ、会話したり、相互に影響し合ったりするための余裕を持つようにしました。選手達が私の概念を良く理解するようになっただけでなく、私も選手の関心事を把握するようになり、そこからたくさんのことを学びました。それ以来、ゲーム前に話したことと、最終的なプレー内容がスムーズに一致するようになりました」
- 耳にしたことの10%
- 目にしたことの35%
- 耳にして、かつ目にしたことの55%
- 言葉を言い換えたことの70%
- 言葉を言い換えて、実行したことの90%
スクラムに関しては、知識や情報の交換が行われるあらゆる分野で、このレッスンを利用できます。設計セッションを思い浮かべると、開発者や営業担当者へ必要条件を伝えること、営業担当者や新しいチームメンバーに開発プロセスを説明すること、何もかもが当てはまります。こうした分野のすべてにおいて、自由な意見を求める問いかけや、対話形式のコミュニケーション、言葉の言い換えなどを使うと、相互理解を劇的に改善できます。なぜなら、全関係者が本当に理解していること、考えるていることが明らかにならざるを得ないからです。その見返りとして、信頼と尊敬に満ちた関係の基礎が築かれ、私から見れば、この関係こそが生産性を上げる最も重要な促進剤なのです。
日々のスクラム実践ですでに分かっていた法則もあります。それでも、効果的なコミュニケーションがどれほどの利益をもたらせるかについて気づかせてくれる、とても貴重なレッスンです。
原則2:
異なるやり方のみが異なる結果を生み出す
上記のコミュニケーションに関する話には、重要な原則がもう1つ含まれています。Lammers氏の経験では、当初のコミュニケーション方法がうまくいかなくとも、自分の行動を深く考えることはせず、まず同じ方法をもっと一生懸命行いました。氏の行いは人間的と思います。自分が予想した結果が得られないときはいつでも、単に一生懸命さが足りなかったと先入観をもって考えてしまいます。その結果、仕事の時間が長くなり、もっとエネルギーを費やし、一生懸命話をして、週末も働く、などといった行動に出てしまいます。Lammers氏の経験から分かるように、たいていの場合はそれでは成功しません。氏が問題に対してまったく異なる姿勢をとった時、初めて欲していた成果を上げたのです。
この原則が当てはまるケースが多数あります。スクラムで見積もりを容易にする方法を考えましょう。特定チームがもたらすことができる生産能力と無関係のファンクションポイントを用いて作業する代わりに、スクラムでは経験に基づいたチームの速度と複雑性のポイントに依存しますが、実際に驚くほど正確であることが分かりました。ですから、ファンクションポイントの分析に磨きをかけて完ぺきにするのではなく、スクラムでは単純さと正確性で抜きんでた、まったく異なるアプローチをとります。
この原則がたびたび酷使されるもう1つの例として、現状の取り組み方では守れないことがはっきりと分かっている締切が近づいてきたときに、時間外勤務を要請する傾向が挙げられます。時間外勤務は二次的に必要になるかもしれませんが、構造的に見ればこのアプローチは対症療法に過ぎないことが分かっており、長い目で見れば有用ではありません。チームスピリットやチームメンバーの健康にひどい影響を与えるばかりか、ソフトウェアの品質にも害を及ぼします。バグ率が上昇し、それに伴って、発生したバグを直すための作業負荷も増加します。結果として、時間外勤務を用いてこの問題に取り組むことにより、物事が悪化するかなりのリスクがあるのです。
スクラムには、緊急手順という形式でこの問題に対処するという、より期待のできる方法があり、この方法は本質的に、原則２を具体的に適用することです。締切に間に合わないことが分かったら、スクラムの緊急手順では以下の行動を考慮するよう提案します。最初に、レトロスペクティブ・ミーティングを開き、生産性を引き上げるために取り除くことができる主な障害を考えます。次に、手順１を実行後も顕著な生産性向上が見られない場合は、専門家にアウトソース可能な具体的なタスクを考えます。こうした専門家はチームの一員ではなく、チームメンバーにはない専門的知識を使って隔離されたタスクを単に解決するだけです。第三に、そうしたタスクが見あたらない場合は、再度スコープし直しみてください。最後に、クライアントが再スコープに同意しない場合は、スプリントを中止しなければなりません。
まとめると、唯一の構造的な解決策は、現行の方法を徹底的に再考し、変更する勇気を持つことです。実際にそうするのは大変ですが、チームにデスマーチをさせるよりも、期待された目標を成し遂げられる可能性はずっと高くなります。
原則3:
革新はより良い結果を生み出すための強力な手段であって、目標そのものではない
加えて、副作用に注意すること
Marc Lammers氏:
「私はいつも革新を模索しています。オリンピックのとき、コーナーからのプレーについてアドバイスしたくても、フィールドの外からゲームを見ていたら、重要部分が十分よく見えないと感じました。ゲーム後にビデオの断片を見て分析したものですが、私にとってはそれでは遅すぎでした。リアルタイムに分析したかったのです。
ラップトップを長いケーブルでテレビカメラに接続し、何度か試しましたが失敗し、その後ビデオグラス（ビデオメガネ）を思い付きました。小さいスクリーン付きのメガネのことで、このスクリーン上にすべてのテレビカメラからの映像が表示されるのです。エンジニアと連絡を取り、そして数ヵ月後には、最初のプロトタイプをテストすることができました。それ以来、選手達にはずっと詳しいアドバイスをしています。
革新を利用するときに言っておかなければならない重要事項が3つあり、皆さんと分かち合いたいと思います。
- 革新は常に目的に役立たなくてはなりません。これまで何度も、革新のために革新するような誘惑にかられましたが、それでは改良にはつながりません。革新を用いて解決しなければならない、はっきりとした課題がなくてはならないのです。
- 革新にはそれぞれ、発展の痛みが伴います。最初からうまくいくとは思わないでください。あなたの望む競争上の優位性を手に入れるまで、微調整やチューニングが必要です。
- 革新は抵抗をもたらします。人間は新しいものを何でも怖がるのです。この事実には2つの意味があります。まず、抵抗に遭うことは、恐らく、真の革新を見出したということであり、自分自身を誇りに思ってください。次に、抵抗に対応する方法を見つけましょう。他の人たちがあなたの斬新さを受け入れてくれるとは期待しないでください。斬新さに順応し、慣れるための時間を他の人たちに与えてください」
ソフトウェア開発でこうした単純な知恵をまじめに受けとめたなら、ずっと多くのプロジェクトが成功すると確信しています。この話から以下を教わりました。
- 目的に関して：私個人の経験から、ツールの使用法を観察していると、目的の欠如が最も歴然と分かります。結果指向ではなく、ツールが中心となったプロジェクトを多数見てきました。主な関心事は優れたソフトウェアをデリバーすることではなく、できるだけ効率的にツールを使う方法になっているのです。「高度なツールを1つも使わず開始する」方法が実践でとてもうまく行く理由は、恐らくここにあると思われます。ホワイトボードと付せんを使った方が、高度なツールを次々に利用するよりずっと効果的なことが多々あります。なぜなら、チームは相互作用して、目前の課題に焦点を合わさざるを得なくなるからです。
- 発展に伴う苦痛に関して：プロジェクト環境内に変更があると、ほとんどの場合、発展に伴う苦痛が発生します。チームへの新メンバーの加入や、新技術の選択、新プロセスの使用、など、変更の内容にかかわらず、期待が楽天的過ぎる傾向にあります。変化があれば、発展に伴う苦痛は当然の成り行き、という考えが頭にあれば、楽天的ではなく現実的な展望を抱くことができ、その展望を通じて、それ相応に予想することができるものです。
- 抵抗に関して：たとえば、組織にスクラムのようなアジャイル開発の実践を導入するとき、抵抗は一般的な反応です。Lammers氏の話から、抵抗を非難して立ち向かうのではなく、抵抗という反応を予期し、対処する方法を見つけだすことを教わりました。新しいものを導入する場合は、抵抗者に迫るように説得したり、変更を強要したりするよりは、辛抱すること、そして抵抗者が何を心配しているのかに耳を傾けることの方がずっと効果的です。
原則4:
自分の仕事の仕方を常に疑う
Marc Lammers氏:
「チームのトレーニングプログラムには、30メートルダッシュを何度も入れていました。30メートルダッシュの練習は長いこと、習慣になっていたものですから、チームは過度にこの練習をしなければならなかったのです。当時私は、ゲーム中のランニングパターンを分析しようと思い付きました。分析ができるように、トレーニング時、各選手にGPSを装着させました。データを分析したところ、選手がダッシュする平均距離は30メートルではなく、15メートルということが分かりました。そのため、真のニーズにより合致するよう、トレーニング計画を練ることができました。また1つ、小さな改良が誕生したのです」
この話から、次の2点を学びました。
- なぜそれを行うのか、自分に問い続けてください。「私たちは常に」そうしてきたから、という理由で特定の活動を行っていませんか。その活動は本当に全体に価値を加えているのでしょうか。具体的にどういった価値を加えていますか。その活動は、行う必要のある仕事と調和が取れていますか。
- 上記の質問に満足いく回答が考えつかなかったら、測定を始めましょう。測定とは知ることです。測定することにより、対策や調整の有効性を評価し、改良を達成できたかを確かめられます。測定とは、「単に特定の活動をやめてみて、何が起こるかを見る」というように、単純なことの場合もあります。
経験に照らしてみると、仕事の仕方を単に当然のことと考え、問題視しないために、日々多くの時間を浪費しています。同じタスクを長期間繰り返していれば、たとえそのタスクがまったく何の価値を加えていないとしても、正当化されたかのように思えてしまいます。生産性の改善を模索しているときは、確立された方法を疑問視し、その次に変化を測定すれば、非常に効果的です。
原則5:
人の短所ではなく長所に関心を集中する
Marc Lammers氏:
バックハンドが悲惨で、得点を期待できない選手がいました。彼女のバックハンドを訓練しようと、あらゆることを行いましたが、うまくいきませんでした。はなはだ骨を折ったにもかかわらず、この選手はほとんど進歩しませんでした。彼女のバックハンドに意識を集中していたので、彼女が実際処理できなかったバックハンド目がけて、他の選手がボールをパスしていたのも当然だったのです。
絶望しかけたとき、どうやってボールをプレーしたいかを彼女に尋ねると、「本当のところは、こちら、フォアハンドで」というのが、答えでした。彼女はまったく見込みがないと確信した私たちは、フォアハンドの練習を始めました。自分の目を疑いました。彼女は渡されたすべてのパスをスムーズかつ素速く処理したのです。集中的にフォアハンドを練習すると、彼女の得点も自意識も3倍になりました。
私が取った最初のアプローチは、味気ない画一性がいかにして作り上げられるかを示しています。10点満点で考えた場合、彼女のバックハンド技術を当時の4点から6点に引き上げたかったのですが、彼女のフォアハンドは元々8点だったにもかかわらず、練習しなかったために同じく6点に落ちていたのです。フォアハンドの練習後、8点から9点へ進歩した彼女は、傑出した選手となったのです。彼女の長所ではなく短所に焦点を当て、改善しようとした試みは、とてつもない無駄でした」
チームメンバーが果たすべき役割を果たさないとき（例：訓練されていない、経験がない、混乱している、非友好的、など）はいつでも、当然のことのように、その人物の否定的な側面に焦点が当てられます。Lammers氏の話から、欠点よりも、スキルを意識して探すことにより、その人間とチームの両方にずっと良い結果がもたらされることを学びました。その人の否定的な側面を甘んじて受け入れて、良い面を伸ばす方法を見いだすことです。
原則6:
チームには制御可能な課題を与える
Marc Lammers氏:
「ゲームが始まる前には、『本当に勝たなければならない。さもなければ脱落する』というような言葉を使って、チームに刺激を与えるのが良いと思っていました。効果はどちらかと言うと正反対で、選手が力を発揮する助けとはなりませんでした。最初、その理由が分かりませんでした。今では分かっています。選手個人ではゲームの結果を左右できない、ということが問題だったのです。選手個人がベストを尽くしても、個人ではコントロールできないあまりに多くの要因が他にあり、そうした要因によって結果が決まることがあるのです。自分ではコントロールできないことのために緊張して神経質になり、最高の働きができなくなったのです。
勝ち負けは、単にプレーの仕方の結果であると悟りました。朗報は、個々の選手は自分のプレーに影響を与えられるということです。ですから、ゲームの前に勝敗について話をする代わりに、自分たちの戦略と、各選手が注意を払わなければならない個人的な留意点を注意深く繰り返します。こちらの方が具体的ですし、ずっと制御が可能です。このアプローチを使うと、選手はずっとリラックスし、自分のベストを発揮できる状態になるのです。結果がそれを証明しています」
スクラムマスターの私から見ると、「これから1年以内に一定量の機能をデリバーしなければならない」とチームに伝えることはほとんど価値がないことを、Lammers氏の話は示しています。そのようなことは、チームメンバーがコントロールできないことですから、モチベーションにはなりません。単一のスプリントにおいてさえ、約束した機能をもたらす責任についてチームに再認識させることは、単にプレッシャーを増すだけですから、ほとんど意味がありません。プレッシャーの欠如が問題となっているなら効果的かもしれませんが、ほとんどのケースでは、プレッシャーの欠如は本当の問題ではありません。
Lammers氏の話から、チームあるいはチームメンバーが成し遂げられる、次の小さな生産性改良に焦点を合わせることを学びました。デリバリを阻止している障害はありませんか。チームが知らない技術のために、専門家を雇えますか。お手上げ状態になっても助けを求めない人たちには、ペアプログラミングを選択した方がよいでしょうか。価値のない書類の処理に時間を奪われていませんか。こうした具体的な問題は制御可能であり、解決すれば自動的にさらなる生産性がもたらされるので、プロジェクトのスケジュールが守られる可能性が高くなるのです。
原則7:
「自分の世界」の中だけを見回せば限界しか見えないが、他人の世界を見れば、可能性が見える
Marc Lammers氏:
「ホッケーではコーナーをプレーする方法が38通りあります。試合中、チームにプレー方法を指示します。そのために、私は凝ったサインを作り上げ、全選手がそのサインを覚えなければなりませんでした。問題は、敵チームがこのサインを録画、分析して、ついに解読してしまったことです。従って、私がしようとしていたことが敵チームに分かってしまい、私の競争上の優位性にピンチが訪れました。
その頃、偶然にも、ツール・ド・フランスのオランダ自転車チームへの加入を求められました。折良く、サイクリスト同士の連絡に無線を使っていることを知りました。「すごいぞ。もし無線が使えたなら、すぐにでも競争上の優位を取り戻すことができるだろう」と思いました。家に帰って密かに規則を勉強し、規則では無線通信にまったく触れていないことが分かりました。ですから、当然、無線通信は許可されるはず、と私は適切に推測しました。サイクリストが使う無線セットはかさばるので、耳栓サイズの無線セットを製造する会社と連絡を取りました。多少の調整を済ませると、最初のプロトタイプは使用可能でした。
何が素晴らしかったかというと、このハイテク化を極秘にしておいて、敵チームを混乱させるためにサインを使い続けたことです。１年半の間、見つかることなく、敵チームに発見されるまで、だまし続けることができました」
アジャイルとスクラムは、別の規範のベストプラクティス、すなわちトヨタのリーン生産方式を部分的にソフトウェア産業に適合させた結果です。どうやら、ほかの誰かが先だってこの考えを持っていたようです…
上の話をスクラムに置き換えると、スクラムを関連した方法論の実践と組み合わせれば、かなり強力で、もっとふさわしいものになることが分かりました。例を申し上げると、私は個人的にUP（Unified Process）のアーキテクチャが中心になった、リスクおよびユースケース主導のアプローチや、XPの持続可能な速度哲学、加えてテスト駆動型開発、（カスタマイズ化した）ペアプログラミングにかなりの経験があります。他の方法論の要素を組み合わせ、いじってみると、あなたのニーズにふさわしいスイートができあがります。
Lammers氏の話から、ソフトウェア開発に無関係の分野を違った目で見て、そこから得られるものはないか考えることを教わりました。他を見渡せばいいものがたくさんありますから、それを見つけ出して自身の世界に組み入れるのが手腕の見せ所です。
原則8:
目標が重要と受け取られれば、モチベーションは高くなる
Marc Lammers氏:
「金銭的に見ると、ホッケー選手になるのは狂気の沙汰です。奨学金は支払われますが、それではほとんど生き残れません。悲惨な金銭的現実にもかかわらず、応募者は列をなして参加を待ちわびます。奨学金を勝ちとり、勝利チームの一員になれば、全世界に報道されると考えて、それは金より何より、ずっと魅力的なのです」
論理的な見地からすると、開発者がどの目的でクラスを書くかで違いがもたらされるべきではありません。実際は違いが生じるのです。まったく同じクラスを、内部のユーティリティプロジェクトの技術ライブラリ向けに書くのか、あるいは、次の火星探査をリアルタイムで追跡するNASAの新しいWebサイト向けに書くのかには、計り知れない相違があります。
Lammers氏の話から、チームを動機づける最も良い方法は、チームが行っていることは重要であり、違いをもたらしているとチームに感じさせることである、と気づきました。プロジェクトによっては、こうした認識作用を元々備えているものもあります。そうしたプロジェクトでは、完了して引き渡せば、マスコミに報道されたり、広告キャンペーンで紹介されたり、あるいは社会に影響を与えることもあるでしょう。このような場合は、ほとんど何も行う必要がありません。
しかし、大多数のプロジェクトはとてもやりがいがあっても、知名度ははるかに低いのです。比較的小さな動機づけの努力で、プロジェクトの知名度と重要性を向上させることにより、喜びを増幅できます。以下に例を挙げます。
- 成功したリリースを祝いましょう。「重要」人物を招待し、感謝とプロジェクトの重要性を表明するスピーチをこうした人たちにしてもらいましょう。;
- 新しいリリースやプロジェクトの進行状況をユーザーに伝えたり（チームの写真をつけることを忘れずに）、会社のニュースレターに寄稿したりすることにより、何を行っているかを組織に伝えましょう。
- 部門責任者やCEOにプロジェクトを訪問してもらい、チームに紹介しましょう。
モチベーションの重要性をはっきり理解することは、生産性を急上昇させる上で非常に重要な要因になり得ます。
結論
この論文で説明した原則の大部分は、常識のように聞こえます。しかし、この原則を適用したことにより、オランダの女子ホッケーが世界一なったことを忘れないでください。あらゆる理論と原則がそうであるように、理論や原則を実際に使用し、適用することが技(わざ)なのです。Mark Lammers氏の話を聞いたとき、氏が行っている方法に気づきました。氏は喜びに満ちた熱意、度重なる内省、熱い精神をもって、物事を行う新しい方法を見つけ出し、実験しているのです。
この点から、私は最後の原則を導き出しました。
競争精神に楽しみを組み合わせ、そしてたくさんの内省を加えてください。そうすればこれまでの原則は、自ずとついてきます。
これほど単純なことなのです。
後注
Mark Lammers氏は、自身の指導者としての成果について、本を書いています（オランダ語）www.marclammers.nl。
著者について
Urs Peter氏はXebia(リンク)で上級コンサルタントを務め、アジャイルソフトウェア開発を専門にしています。Peter氏はこれまでに、スクラムやAgile RUPなどの異なるAgile方法論を適用して数種の大規模プロダクトを開発してきました。現在は高い実績を上げている分散型のスクラムチームで仕事しており、オランダ鉄道向けに次世代の情報ソフトウェアを提供しています。氏の現在のプロジェクトについては、「Case study: Distributed Scrum Project for Dutch Railways」（ケーススタディ：Dutch Railways 向けの分散型スクラムプロジェクト）(参考資料)をご覧ください。
原文はこちらです：http://www.infoq.com/articles/sport-coaching-and-agile
（このArticleは2008年8月20日に原文が掲載されました）