XPのテーマのバリエーション

なぜ方法論を購入するのか？

これらの質問に答えるために、少し戻って自問自答する必要があると思います。方法論とは何のためにあるのでしょうか？なぜ誰もが方法論を使いたいと思うのでしょうか？これに対する答えは、方法論の顧客は、ソフトウェアを適切に開発する方法を懸念しており、方法論に従うことで、成功の可能性を高める実績のあるパスをたどることができると期待しているからだと私は考えています。

また、方法論に従うことで、「私はできる限りのことをしました。尊敬される方法論に従いました」と言って、失敗の結果から身を守っていると言うこともできます。後者の理由を非難することはよくあることですが、多くの分野では、タスクを実行するために特定のプロセスに従うことが期待されており、結果に従わない場合、将来の問題に対してより責任を負う可能性があるというのは事実です。

いずれの場合も、人々は成功の可能性を高めるために従うべき手順をいくつか求めています。これは合理的です。結局のところ、私たちは数十年間ソフトウェアを開発してきました。他人の経験から学ぶことができるはずです。

方法論の可変性

率直に言えば、ほとんどの方法論は、方法論者がかつて行ったことに基づいて行う声明です。つまり、彼が幸運であればの話です。私は、それらのほとんどは彼らがやりたかったことに基づいているのではないかと思います。せいぜい数人がアイデアを組み合わせているかもしれません。しかし、実際に結果として得られた一連のことを誰かがやったかどうかは別問題です。

ソフトウェアはまた、信じられないほど可変的です。まず、ソフトウェアの重要な変数の1つは人です。異なるメソッドは、異なる人々に対して異なる効果を発揮します。企業文化も大きな影響を与えます。ソフトウェアのスタイルもあります。電話用に設計されたプロセスが情報システムに適しており、ゲームに適しているとは思いません。

公平を期すために、方法論者の多くはこれを認識しています。彼らは、人々が従うべき簡単な手順のシーケンスを提供して、完璧な結果を得ることができないことを知っています。常に何らかの適応、何らかの調整が必要です。しかし、どのように調整をガイドするのでしょうか？方法論の顧客は、何が合理的な調整であり、何が方法論を壊すのかをどのように知るのでしょうか？

これは特に、アジャイル方法論に従う人々にとっての質問です。これらの方法論の重要な機能の1つは、私が_自己適応型_と呼ぶものです。つまり、時間の経過とともに方法論を使用するにつれて変更することが期待されています。この状態では、許容できるバリエーションの境界はさらに流動的です。あるプロジェクトの方法論の使用法が異なるだけでなく、単一のプロジェクトでも時間の経過とともにバリエーションがあります。

これは方法論者のジレンマです。方法論内のバリエーションをどのように記述すれば、あなたのアドバイスに従おうとする人々があなたが期待する利益を得られると確信しながら、彼らが特定の状況に合わせてあなたのアドバイスを適応させることができるようにできるでしょうか？

可変性と方法論

方法論の柔軟性についての問題を見るとき、そこにはさまざまなスタイルの方法論があることを覚えておく価値があります。これらのそれぞれは、バリエーションの問題に異なる一連の問題をもたらします。そこで、考えるべき方法論の分類を以下に示します。ここで使用する用語は、この記事のために私が作ったものであり、それらの間の境界線は非常に曖昧であることに注意してください。

まず、具体的なプロセスです。**具体的なプロセス**は、従うべき固定された一連のプラクティスを提供します。具体的なプロセスでは、ほとんどまたはまったくバリエーションが許容されません。具体的なプロセスの強みは、何をすべきかを非常に明確にすることです。具体的なプロセスの明らかな制限は、変更できないことです。まあ、実際には変更できます。常に人々は具体的なプロセスを取り、ローカルな変更でそれを採用します。問題は、方法論がその方法についてガイダンスを提供していないことです。さらに、変更を開始するとすぐに、厳密にはプロセスから外れますが、プロセスのファンがプロセス内にあると言うほど十分に近い可能性があります。特に成功した場合です。

具体的なプロセスは非常に固定されているため、多くのプロセスには、それを変更する方法の明示的なガイドラインが付属しています。そのようなプロセスを**調整可能なプロセス**と呼びます。調整可能なプロセスには通常、どのようなバリエーションが許容されるか、いつそれらのバリエーションを使用するのが適切かについて説明する、プロセス記述の重要な部分があります。そのため、バリエーションに関するアドバイスを提供するため、具体的なプロセスよりも優れています。しかし、これを正しく行う方法を理解するのが非常に難しいことが多いため、完璧ではありません。何をすべきかを決定する前に、基本プロセスとすべてのバリエーションの両方を理解する必要があります。

この時点で、プロセスのサイズについて考える価値があります。プロセスでサイズが何を意味するのかを理解するのは簡単ではありませんが、1つの方法は、プロセスを理解するためにどれだけのものを読んだかを考えることです。一般的なパターンは、大規模な調整可能なプロセスを持つことです。このアイデアは、あなたがすべきことをすべて伝え、次に何を省略できるかを伝えることです。しかし、これを行うには、小さいものを理解する前に、大きなプロセスを理解する必要があります。より小さなプロセスが必要な場合、これはあなたがやりたいと思うよりもはるかに多くの作業になる可能性があります。

このように調整可能なプロセスはたくさんありますが、おそらく現在最もよく知られているのは、Rational Unified Processです。これはほとんどのものよりも調整可能であるため、**プロセスフレームワーク**と呼ばれています。これは、RUPを使用する人は誰でもRUPのインスタンスである特定のプロセスを使用し、RUPの完全な柔軟性を使用または理解する必要がないと説明されています。そのため、具体的なプロセスとRUP（調整可能なプロセス）を同時に使用することは durchaus 可能 です. 私の見解では、あなたがそうし、RUPを実際に見ない場合、それはあなたが使用している具体的なプロセスです。しかし、RUPは、具体的なプロセスに欠けているバリエーションに関するアドバイスを提供するだけでなく、他の具体的なRUPインスタンスを使用する人々とコミュニケーションをとるのに役立ちます。

一部のプロセスでは、具体的な手順をまったく示していません。むしろ、プロセスの基礎となるソフトウェア開発の哲学を教えることに集中しています。このような**哲学的プロセス**は、哲学に合ったプロジェクトを実行する方法が多数あるため、本質的に柔軟性があります。手順とバリエーションの詳細には触れないため、調整可能なプロセスやプロセスフレームワークほど大きくなくてもこれを行うことができます。ただし、具体的な手順が不足しているため、従うのが難しいことが多く、月曜日に何をすべきかを明確に示していません。ジム・ハイシュミスのASDは、哲学的プロセスの優れた例です。

人々はしばしばそれらをプロセスとは呼びませんが、関連する知識グループはベストプラクティスのコレクションです。**ベストプラクティスコレクション**の良い例は、マコーネルの優れた著書Rapid Development（ラピッドデベロップメント）に掲載されているベストプラクティスのコレクションです。そのようなコレクションは、かなり独立した良いことのグループであり、ほとんどどの順序でも適用できます。哲学的プロセスとは異なり、具体的な部分ですが、プロジェクトにどのベストプラクティスを適用するかを決めるのはあなた次第です。

ベストプラクティスの良い点は、それらを活用するために複雑な手順のWebを理解する必要がないことです。代わりに、最も価値があると考えるプラクティスを選択できます。私は方法論を常に信用していなかったため、このアプローチが好きでした。しかし、XPが私に明らかにしたことの1つは、プラクティスが独立した部分ではないという事実です。XPの力は、個々のプラクティスからではなく、ケントが選択したプラクティス間の相互作用から生まれます。XPのプラクティスを個々のプラクティスとして見ると、XPのポイントの多くを見逃してしまいます。このことから、プラクティス間の相互作用はプラクティス自体と同じくらい重要であり、具体的なプロセスまたは調整可能なプロセスがうまく捉えているのはその相互作用であることを学びました。

そのため、これらすべてのアプローチは、何らかの形で不完全です。具体的なプロセスは、理論的にはまったく可変的ではなく、実際には、それを変更する方法に関するガイダンスを提供していません。調整可能なプロセスは理論的にはうまく機能しますが、調整するには非常に多くの資料を理解する必要があります。哲学的プロセスは優れた基盤を提供しますが、実際に行うべきことについて具体的なアドバイスは与えません。ベストプラクティスコレクションは、個々の行うべきことを教えてくれますが、プラクティス間の相互作用については触れていません。

XPとは何か？

XPと可変性を見るには、まずXPがどのカテゴリに当てはまるかを認識する必要があります。多くの人にとって、XPは具体的なプロセスであることは明らかです。従うべき12のプラクティスがあり、XPディスカッショングループで多くの時間を過ごすと、XPの支持者が12のプラクティスすべてを実行させるために多くの努力をしていることがすぐにわかります。そのため、多くの人が自分の見解を主張する際に、過度の熱狂で評判を得ています。

しかし、XPの魅力の多くは、具体的なプラクティスよりも、XPの根底にある哲学に惹かれた人々から生まれています。XPの適応性、人間中心主義、軽量さ、そして創発的な振る舞いへの注目は、魅力的な組み合わせです。XPを使いたいけれど、具体的なプロセスの範囲外にいる人はたくさんいます。

私が特に気に入っているXPの特異な点の一つは、XPが非常に明確な境界線を設けていることです。最大12人程度の開発者からなる、同じ場所に集まったチームを想定しています。これらの境界線は非常に明確ですが、XPには、これらの境界線に当てはまらないプロジェクトにも魅力的なところがたくさんあります。30人の開発者がいるプロジェクトや、多くの人がテレワークをしているプロジェクトの場合はどうなるのでしょうか？適応性と人間中心主義の原則は依然として有効です。可能な限りXPに近づけてはいかがでしょうか？

そのため、XPを狭義に捉えるべきだとする人々と、広義に捉えるべきだとする人々の間で議論が起こります。XPが多くのブランド認知を獲得したことで、この議論は激化しています。人々は、自分たちがXPを使用していると喜んで言います。なぜなら、そう言うことで、自分たちの仕事の根底にある価値観や原則、つまり、大規模なチームや分散したチームであっても重要な価値観を伝えることができるからです。

XPには、何がXPで何がXPでないかを公式に宣言する運営委員会はありません。それは、非公式な取り決めしかないコミュニティのようなものであり、このコミュニティはこの問題についてまだ結論を出していません。ケントは、XPを具体的なプロセス、つまり「明確な立場」として捉えることを好むと述べています。彼がXPコミュニティで認められたリーダーであるため、その好みは大きな影響力を持っています。そのため、XPは具体的なプロセスを意味するという見方が支配的です。

XPと自己適応性

そこで、私たちはXPを明確に定義されたプロセス、つまり明確な立場として捉えます。これを自己適応性のニーズとどのように両立させるのでしょうか？

その答えの手がかりは、ケント・ベックがXPの成熟度レベルの設定について質問された際に発言した言葉にあります。ほとんどの人は、XPにCMMのような成熟度レベルの概念があることに恐怖を感じて反応しました。ケントは、いつものように、人々を驚かせるような思慮深い真剣さで答えました。彼は、XPには3つの成熟度レベルがあると述べました。

• レベル1は、すべてのプラクティスをマニュアル通りに正確に行っている段階です。
• レベル2は、XPを自分の状況に合わせて適用している段階です。
• レベル3は、XPをやっているかどうかを気にしない段階です。

ここで自己適応性が出てきます。XPであり続けるためには、XPを適応させなければなりません。私が言うように、イテレーション6でイテレーション1と同じようにXPをやっているなら、それはXPではありません。

しかし、ここでの成熟度の段階に注目してください。これらのレベルは、適応する前に、人々がマニュアル通りにXPを行っていることを前提としています。重要なのは、XPを実際にやってみなければ、どのように機能するのかを理解するのは難しいということです。XPを構成するプラクティスの組み合わせは、実際に一緒にやってみて、それらがどのように相互作用し、連携するのかを確認しない限り、その効果を理解するのが非常に難しい方法で機能します。読書や推測は、実際に体験することの代わりにはなりません。私は、自分が考えていたXPの働き方と、C3で作業したときに見たものとの間には大きな違いがあることを確かに証明できます。

XPの支持者の多くが、XPをどのように改善できるかについて推測する前に、マニュアル通りにXPを行うことをそれほど重視するのはこのためです。多くの場合、これはある程度理由があって、閉鎖的な狂信のように見えます。しかし、多くの場合、それはXPの支持者が、自分自身の初期の懐疑心と、物事を異なって行いたいという気持ち

具体的なXPの変更

これは、プロセスを可変にする方法について、具体的なプロセスを基礎とする異なる考え方をすることを意味します。複雑でありながら調整可能なプロセスをどのように使用するかを最初に考えるのではなく、ニーズに最適ではないことが明らかであっても、具体的なプロセスから始めます。この最適ではないが具体的なプロセスを実行します。そうすることで、そうでなければ見逃してしまうであろう、プロセスに関する重要なことを学ぶことができます。それが終わったら、変更を始めます。他のプロセスからのヒントを参考にしましょう。

これが、XPにおけるバリエーションの仕組みの核心です。方法論の仕組みを本当に理解していなければ、方法論をどのように調整すればよいかを本当に理解することはできません。複雑で重い方法論の場合、これには多くの作業が必要です。少数のプラクティスと、サイクルの中で段階的に開発し、学習することに重点を置いたアジャイルな方法論は、これをはるかに容易にします。基本的に、小さなものを少しづつ追加して変更する方が、大きなものを少しづつ削除して変更するよりも簡単です。

しかし、XPがどのように機能するかを理解する上で難しいのは、XPを実際にやってみなければ、XPがどのように機能するかを本当に理解するのが非常に難しいということです。そのため、XPの仕組みを理解できるようになるまで、XPを調整することには非常に注意する必要があります。

最善の解決策は、マニュアル通りにXPを実行し、数回のイテレーションで落ち着かせてから、調整することによってプロジェクトを開始することです。しかし、ほとんどの場合、人々はそうすることができません。代わりに、発生するさまざまな問題を解決するために、プラクティスを少しずつ適用する必要があります。後者のアプローチは、実行しやすい一方で、プラクティスの相互作用を見逃してしまう可能性があるため、リスクも大きくなると思います。そこで、後者のアプローチでは、XPがうまく機能するのを見たことがある人がそばにいて、知識に基づいて指導してくれることが、より重要になると考えます。

このように、XPでは、依然として始めるためのプラクティスと経験のセットが得られます。しかし、それはまだ始まりに過ぎません。XPを自分の状況に合わせて適用する必要がありますが、XPがどれほどうまく機能するかを理解した上で適用することが重要です。私の考えでは、これは、変更によって効果が上がると思わない場合でも、しばらくの間はできるだけマニュアルに近い形でXPを試してみるべきであることを意味します。その段階を学習段階と考えてください。数回のイテレーションの後、適応を開始します。その時の適応が、最初に考えた最初の適応と同じであれば、私は驚きます。

XPと境界

では、XPの将来と、その境界線の向こう側はどうなるのでしょうか？Thoughtworksでは、約60人のプロジェクト（その半数は開発者）の基盤としてXPを使用しています。これは明らかにXPとしては大きすぎます。それでも私たちはそれをXPと呼んでいます。なぜなら、XPが私たちの仕事の背後にある指導理念だからです。そこには、私が否定できない矛盾があります。おそらく、それをXPと呼ばない方が良いでしょう。確かに、私たちはそれを機能させるためにプラクティスをかなり変更しなければなりませんでしたし、規模が大きいため、チーム全体が「マニュアル通りの」XPプロセスを経験したことはありませんでした。

それにもかかわらず、私はXPが明確に定義された境界線の背後にある明確な立場のままであることを望みます。私たちが行っていることはXPの影響を受けているかもしれませんが、それは異なるプロセスです。私たちはそれに名前を付けないかもしれません。結局のところ、それは今では特定のプロジェクトに高度に適応しており、そのように適応し続けるので、それがXPであるかどうかはほとんど気にしません。他のプロセスもそのように現れるべきであり、XPの影響を受けたプロセスの開花が見られるでしょう。おそらく、XPを考える最良の方法は、それが木ではなく種であるということです。

そこで、私たちがXPを「購入する」（結局のところ購入費用はかかりません）ことを選択すると、私たちが得るのは種です。私たちは、小さく、具体的で、調整が必要なものよりも理解しやすいプロセスで、XPコミュニティの経験を活用して始めることができます。数回のイテレーションでは、そのアドバイスに従います。しかし、すぐに私たちはそれを基に、私たちの状況に合わせて適応しなければなりません。そのため、私たちは依然として経験に基づいて構築していますが、XPを「責任逃れ」の防御として使用することはできません。XPや他のアジャイルな方法論は、そのためには適していないと思います。そして、私はこれを問題とは考えていません。アジャイルな方法は、最終的にプロセスの制御を übernehmen 真に権限を与えられたチームがいない限り、機能しません。種はどんな木にとっても重要な部分ですが、どんな庭師も言うように、ただ地面に投げ込むだけでは成功の保証はありません。