自分たちの良いところを認識することからはじめるXP

(出典：”Appreciating Your Way to XP”)

Kent Beck, Three Rivers Institute
訳: 平鍋健児

概要

「問題を認識してそれを解決する」という考え方は工学では常識的だが、別の手法として「現在うまくいっ ていることの価値を認識(appreciate)することからはじめる」というアプローチには、変化を生み出す大きな 力がある。この記事では、AI=アプリシアティブ・インクワイアリ(Appreciative Inquiry)が、どのようにXPの導 入に応用できるかを考える。

はじめに
1. 最悪の問題を選ぶ。
2. XP を使ってそれを解決する。
3. その問題が「最悪」でなくなったら、これを繰り返す。
—Extreme Programming Explained, 第一版

このやり方はXP本の第一版から引用したものだが、変化を起こすための工学的アプローチだ。すなわち、 問題を見つけ、それを解決する。残念ながら、このアプローチは変化を継続させるのに必要な条件の多く を無視している。

「変化」は複雑なプロセスであり、知的、感情的、そして人間関係的な活動を必要とする。変化の複 雑さは、それが必要とする人間の下地に関係する。変化しつつある人は、現状を認識する必要がある。 自分の変化を邪魔する、感情的な過去の重荷を捨てる必要がある。「こんな状況になったのは、自分が ダメだったからだ」という感情や考えが変化の妨げとなる。もしかしたらそれは正しいかもしれない。しかし、そ れを嘆くことは、変化の助けにならない。

変化には、エネルギーとアイディアが必要だ。この２つの要素を集めることは簡単ではない。「最悪の問題を 選ぶ」戦略では、まず現状認識をして変化の前提を築くが、その前提だけではうまく行かない。すべての問 題に耳を傾け、整理し、現状の全体像を得ようとするのだが、この前提はどうしても現状否定というバイア スがかかるし、逆に現在うまくいっていることを無視することになる。最悪の問題を特定するには、多くの問 題点を洗い出すことになり、そのあまりにも長大な問題点リストに意気消沈してしまう。さらに、最悪の問 題を解決したとしても、結局他の問題はそのまま残る。変化を起こそうという情熱的なエネルギーは、こうい った活動からは出てこない。さらに、残りの問題点は検討しただけで解決法についても議論していない。つ まり、無視してしまう問題を明らかにしたに過ぎない。

「問題⇒解決」という工学メタファ（世界を解決すべき問題の集合とみている）では、人間の変化を支援 できないのだ。タスクの見積がいつも合わないプログラマが持っている「問題」は、見積係数や見積のレビュ ーという単純な調整で解決できるものではない。一般的に、いつも見積が甘いという症状の根本原因は 深く、それを改善するには知的な、そして感情的な個人の成長を必要とする。誠実に前回の見積もりと 実績を見つめる知性の成熟と、その結果に対してたとえ怖くても誠実でいられる、という感情的な成熟だ。 問題が解決されるのではない。個人の成長が問題を超えたのだ。

「世界は解決すべき問題の集合」と見るアプローチとは違うもう１つのアプローチは、最初にうまくいってい ることや過去にうまくいったことに焦点を当てる方法、「世界のよいところを再認識する見方(to see the world appreciatively)」だ。何かがうまくいっていることが変化の前提となる。最近あるワークショップで試 した例を紹介しよう。「先週のミーティングは完全に時間の無駄だった。数時間議論をし、最終的に到達 した結論はそのミーティングにいない人がくつがえしてしまった」という人に、「そのミーティングの良い点はなか った？」と聞くと、「まったくない。誰もそのミーティングでうそを言わなかったくらいかな。」ちょっとまって、会議で みんな誠実、というのは改善のパワフルな滑り出しじゃないか。これは、問題に焦点をあてるあまり、よい点 に目が向かなくなってしまった例だ。

「アプリシアティブ・インクワイアリ」(Appreciative Inquiry)では、まず現状うまくいっていることに着目し て、そこから変化を促す。最初に、現在もしくは過去のポジティブなことに焦点を当て、そこで見つけたエネ ルギーとアイディアを現在起きていることに適用する。こんな具合だ。

このステップは、レシピとして決められているわけではなく、１つの進め方の例だ。たとえばリリースプロセスに ついて私はチームと話をしていた。最近のリリースがいかにひどかったか、文句を言い始めた。AI を思い出し、 こうやってみた。

「リリースはいつもこんなひどいのかい？」
「いやいや、二年前は問題はなかったんだ。」
「ほんと? 違いは何？」
「１つはもっと頻繁にリリースしていた。現在ではつらくなり、リリース間隔が長くなってしまった」
「他には？」
「チームがもっと小さかったな。全員が１つの部屋に入りきった。現在では、テスターは別の建物に移って 彼らとのコミュニケーションはほとんど取れていない。彼らの質問にちょっとしたデモを見せてやるだけでよかっ たんだ」
「もっとリリースをスムーズにするために、あなたならどうする？」
「まずリリース間隔を短くする。辛いからといって延ばすのは、さらに辛くなるだけだ。開発者とテスターは同 じ場所にいるべきだ。大きな部屋が見つけられなくても、双方のチームを半分に分割して混成チームを２つ 作る。」

ここで起こった対話は、AI のスピリットに沿っている。

AI を使うことで、変化への前提を作っていく。

ブラジルの劇作家アウグスト・ボアール（Augusto Boal) はこう言った。「カタリシスは、現状を維持する ために何千年も用いられてきた技法だ。虐げられた農奴の映画を見れば、農民たちは感情を開放するこ とができるだろう。しかしこの感情は、農民の変化への力にならない。逆に今の境遇に無関心になってしま う。これが、典型的な魔女狩りセッション（リリースがうまくいかない例など）が間違っている点だ。全員が状 況に憤慨しているのに、変化する前に感情がなえてしまう。

AI は、ポジティブな言葉で会話をガイドし、ネガティブな感情を行動に変化させる方法だ。思い出すポ ジティブな経験は、現在の状況とは一見関係していなくてもよい。チームが一緒に活動することに問題があ る場合、全員が過去に経験した最高のチームを思い出し、なぜそのチームはそんなに良かったのかについ て話すことは、変化へのよいスタートとなる。それぞれが思い出すチームは、スポーツチームでもボランティア の組織でもよいのだ。ちょっと深く掘ってみないとよいアイディアにはたどり着かないかもしれない。「OK、その チームではお互いを尊敬しあっていたんだね、でもどうやってそうなったんだい？」「うん、ゲームの後は必ずビ ールを飲みにいって、そのゲームについて話し合ったさ」「ぼくらは今は仕事が終わった後でも忙しいけど、金 曜のランチは一緒にできるかもね」

ポジティブな経験から得た教訓を、直接適用することもできる。たとえば、プログラマとテスターを一緒にチ ームにするなど。また、ポジティブな経験が、一見無関係なアイディアを発生させることもある。私は以前、 チームが全員同席しているチームの話を語っていたときに、フルーツバスケットを遠隔地のメンバーに贈ること を思いついた。AI のゴールは、過去をそのまま繰り返すことではなく、現在の変化に必要なアイディアとエネ ルギーを集めることだ。

AI をペア（二人一組）ではじめるとうまく行く。これまでに私がやってみて何回もうまくいった方法だ。最初 の３０分一人が話し（話し手）、もう一人（書き手）は聞きながらマインドマップを書いていく。書き手は「積 極的に」聴く。考えながら聴き、不明点は質問をしたり、興味をもったポイントをまとめたりする。３０分後に 役割を交代し、こんどは書き手をやっていた方が話し、話していた方書き手にまわってマインドマップを作る。 その後、ペアでストーリーを話し合ったり、結果をグループ全体へ発表したりする。

ペアを組むことで、書き手はリスニング・スキルを実践する経験になる。話し手をうまくリードして、お話全 体がうまく形になるように助けたり、話し手に進行を促したりする。注意点として、書き手は、自分自身の 経験を話したいという誘惑に対抗しなくてはならない。自分の番は次なのだ。うまい書き手は、話し手に対 して「私は十分自分の話を話し、すべて聞いてもらって理解してもらった」という気持ちを与える。 AI を、より大きなグループで適用することもできる。書き手に今聞いたストーリーの「まとめ」をグループ全 体にしてもらう（この方が、一度聞いた話を全体へ再度話すよりうまくいく）。あるいは、一人の書き手が部 屋をまわってお話を集めてまわる方法もある。

グループAI は、グループに共通の基盤がないような場面でもうまくいく。私が最初に聞いたAI の例は、 ポートランド港の労働問題を解決するものだ。経営と労働者がお互いの言い分をすべて聞きあったあとに は、部屋にいる一人ひとりが、敵対関係ではなくゴールを共通しながら別々の意見をもった個人として、全 員を認識している、とう状態が作られた。

AI は、XP でもうまくいく。プラクティスや原則を１つ選んで、パートナーにそれに近い技術的な協力例を ポジティブな話として語ってもらう。たとえば、ペアプログラミングを選んで、パートナーとそれについて語る。誰 でも、うまく協力的にできたコラボレーション例を経験として持っている。抽出した教訓は、教科書的なペア プログラミングと似ているかもしれないし、違うかもしれないが、改善を促すことができることがおおい。私は以 前このエクササイズを大きなグループで行ったとき、とても多くの改善のアイディアがでた。顧客とのウィークリ ーのミーティング、ホワイトボードでのデザインセッション、たまに一緒に行うコーディング。

XP をこのように適用するするのは、「人間は自分自身が関わったプロセスにことについては責任がもて る」、そして、「人間は自分自身のペースで変わる」という事実を尊重している。あなたがXPのコーチであれ ば、このプロセスにおけるあなたの役割は、ペアプログラミングのやり方を正確に教え、強制することではない。 また、受動的に聞き手に回り過去にうまく行ったやり方をそのまま推奨するだけでもない。会話の一部とな るのだ。自分の物語を語り、それを創造的に適用することで、「変化」のアクティブな役割を担うのだ。他の 人が自分の物語を語り、そこで発見された教訓を適用することを促し、ポジティブな成長と責任感を与え るのだ。

私は、あなたがAI を試してみることを勧める。正式なプロセスとしてやってもいいし、自分の心の持ち方 (attitude)を変えてみるだけでもいい。あなたが何かについて文句を言いたくなったとき、よい聞き手を見つ けてその人にお話を聞いてもらう。文句ではなく、うまく行っていたときの話、あるいは一部だけでも今よりは 状況が良かったときの話を。自分の経験から教訓を引き出し、それを適用してみよう。 あなたが現状を認識し、成長する、ことを願う。「世界は解決すべき問題の集合」ではない。それは世 界の１つの見方であり、別の見方だって他にもある。 （おしまい。）