エクストリームプログラミング (XP): 成果を出すアジャイル手法の特徴

エクストリームプログラミングという言葉から、エクストリームゲームやアクションスポーツを連想する方もいるかもしれませんが、それはあながち間違ってはいません。エクストリームプログラミング (XP) は、実は、かなりエクストリーム (過激) なプログラミングのやり方なのです。他のアジャイルソフトウェア開発手法と同様に、XP はソフトウェアエンジニアリングにおいて、適応性のあるテスト駆動開発を行います。しかし、他の手法とは異なり、エクストリームプログラミングには、作業の進め方を規定する厳格なルールと指針となる価値観があります。

エクストリームプログラミング (XP) とは

エクストリームプログラミング (XP) は、短い開発サイクルと最小限のドキュメンテーションで、スピードとシンプルさを追求するアジャイルプロジェクトマネジメントの手法です。そのプロセス構造は、5 つの指針となる価値観、5 つのルール、そして 12 の XP プラクティスによって成り立っています。この記事ではさらにその内容を詳しく解説していきます。

XP は、他のアジャイル手法と同様に、作業スプリントに分割されるソフトウェア開発手法です。アジャイルフレームワークは、スプリントごとにフレームワークを完成させて見直し、効率を最大化するために改良し、変化する要件に対応するという反復プロセス (イテレーション) で行われます。他のアジャイル手法と同様に、XP のデザインは、開発者が顧客のストーリーに応え、適応し、リアルタイムで変化することを可能にします。しかし、XP はより厳密で、頻繁にコードレビューとユニットテストを行い、すばやく変更を加えます。また、この手法は、クリエイティブでコラボレーションに重点を置き、すべての開発段階でチームワークを重視します。

エクストリームプログラミングとスクラムの違い

スクラムは一般的なアジャイル手法の一種で、スクラムマスターによって管理されます。XP と同様に、スクラムは、新しい製品やソフトウェアの機能を開発するために、ユーザーストーリーからスプリントを実行します。一方、XP はスクラムよりも厳密で、厳しいルールとガイドラインがあり、開発者と顧客との間の継続的な接触を促します。また、XP はプログラミングにしか使えないのに対し、スクラムは反復と顧客からのインプットを必要とするあらゆるプロセスに使えます。

エクストリームプログラミングの生みの親

XP の起源は、1990年代後半、Kent Beck 氏がクライスラー社の給与計算ソフト「C3 プロジェクト」の開発を管理するために考案したことに始まります。XP の目標は、開発プロジェクトの中でコードを変更することへの抵抗を取り除くことであり、現在もその目標は変わっていません。従来のソフトウェア開発手法では、一度書いたコードをデバッグする以外は放置しておくことが多いものです。しかし、XP では、開発者が 1 回のイテレーションでコードを完全に書き直すことを決めることもあるほど、コードを慎重に精査するのです。

エクストリームプログラミングを使うべき場面

エクストリームプログラミングはソフトウェア開発に特化しているため、エンジニアリングチームやソフトウェアチームが、特定の条件下でのみ使用します。エクストリームプログラミングの価値を最大限に引き出すには、次のような場面で使うのが効果的です。

• 少人数のチームを管理する場合: XP は非常に協調的な性質を持っているため、10 人以下の小規模なチームで最大限に効果を発揮します。

• 顧客と常に連絡を取り合っている場合: XP は開発プロセスを通じて顧客の要件を取り入れ、テストと承認の段階でも顧客の意見を参考にします。

• 難なく変化を受け入れられる適応力のあるチームである場合: エクストリームプログラミングでは、その性質上、チーム全員が苦労して作ったものを放り出さなければならないことが度々あります。本人以外のチームメンバーがいつでも変更を加えられるというルールもありますが、チームメンバーがそれを不快に思う可能性がある場合は、このルールはうまく機能しません。

• コーディングの技術的な要素に精通している場合: XP は初心者向けではありません。すばやく作業し、変更を加える知識と実力が求められます。

XP のライフサイクル

XP のライフサイクルでは、チームメンバーがほぼ常時、1 時間ごと、1 日ごとといった頻度でインテグレーションを行う、継続的インテグレーションを推奨しています。XP のライフサイクルは、次のように構成されています。

• ユーザーストーリーからやり残した仕事 (バックログ) を引き出す

• 重要なアイテムを優先する

• 反復計画を開始する

• 現実的な計画を取り入れる

• 関係者全員と常にコミュニケーションをとり、チームの自信と力を引き出す

• 開発したものをリリースする

• フィードバックを受ける

• 反復計画の段階に戻り、必要に応じて繰り返す

エクストリームプログラミングの 5 つの価値観

エクストリームプログラミングは価値主導型です。XP は、外的な動機付けや複雑な設計を用いる代わりに、シンプルさとコラボレーションを重視し、次に紹介する 5 つの価値に基づいてチームが働くことを可能にします。

1. シンプルさ

エクストリームプログラミングを始める前に、まず、最もシンプルで、かつ効果的なものは何かを確認してください。この「効果的な」部分が重要な違いです。最もシンプルなものが常に実用的で効果的とは限りません。XP では、最も重要な仕事を最初に終わらせることに焦点を当てます。つまり、自分が達成できるとわかっているシンプルなプロジェクトを探すのです。

2. コミュニケーション

XP は、すばやい反応と効果的なコミュニケーションを前提としています。成功するためには、チームがお互いにオープンで正直でなければなりません。問題が発生したら、はっきりと意見を言いましょう。なぜなら、他のメンバーがすでに解決策を知っていることが多いからです。また、そうでない場合でも、一人で考えるよりグループで考えた方が早く解決策を思いつくでしょう。

3. フィードバック

他のアジャイル手法と同様に、XP はユーザーストーリーとフィードバックをプロセスに直接組み込んでいます。XP の焦点は、すばやく、シンプルに製品を作り、それを共有し、ほぼ即座にフィードバックを受けることです。そのため、開発者はプロセスを通じて、顧客と常に連絡を取り合うことになります。XP では、頻繁にリリースを行い、早期にそして頻繁にインサイトを把握します。フィードバックを受けると、そのフィードバックを取り入れるために、プロジェクトではなくプロセスを適応させます。たとえば、不要なタイムラグを解消したほうがいいというフィードバックがあれば、プロジェクト全体を調整するのではなく、一組の開発者がタイムラグを改善するようにプロセスを調整するのです。

4. 勇気

XP を行うには、それなりの勇気が必要です。常に自分の進捗を正直に報告しなければならないので、かなりダメージを受ける可能性があります。XP で締め切りを守れなかった場合、チームリーダーはその理由について話し合おうとはしないでしょう。そうする代わりに、あなたは締め切りを逃したことを伝え、責任を負い、作業に戻ることになります。

チームリーダーの XP プロセス開始時の責任は、成功への期待値を設定し、「完了」を定義することです。成功することに集中するあまり、失敗を想定した計画がほとんどないチームが多いのです。しかし、必ずしも計画通りに物事が進むとは限らないので、無計画にプロセスを進めると危険な可能性があります。XP のプロセス中に物事が変化した場合、チームはそれに合わせて適応し、変化することが期待されています。

5. 尊重

XP がコミュニケーションと誠実さを非常に重要視していることを考えれば、尊重することが重要であることは納得がいきます。チームが効果的にコミュニケーションやコラボレーションを行うためには、異なる意見を持てる環境が必要です。しかし、それを友好的に行えないのであれば、逆効果になってしまいます。正直に意見をぶつけ合うチームでも、お互いを尊重することが優しさと信頼の大切な基盤になります。エクストリームプログラミングで求められることは次のとおりです。

• 顧客と開発チームの間で互いに尊重し合う関係を維持できること。

• チームメンバー間で互いに尊重し合う関係を維持できること。

• チームの一人ひとりがプロジェクトに価値をもたらす存在であることを認識すること。

エクストリームプログラミング手法の 5 つのルール

エクストリームプログラミングの価値は、どちらかというと哲学寄りの要素です。一方、ルールは、仕事をどのように行うかという実用的な手段です。効果的な XP チームを運営するためには、この両方が必要です。

1. 計画

XP の計画段階では、そのプロジェクトが実行可能かどうか、XP に最適かどうかを判断します。これを行うには、以下を確認します。

• ユーザーストーリーが XP の価値観の 1 つ「シンプルさ」と一致するかどうかを確認し、顧客がそのプロセスに対してタイムリーに意見を言えることを確認します。ユーザーストーリーが複雑だったり、匿名の顧客が作ったものだったりすると、XP では高確率でうまくいきません。

• 「最も重要な仕事を最初に終わらせる」ことができるかを確認するために、ビジネス価値とプロジェクトの優先度を確認します。

• 開発のどの段階に位置するのか。XP は初期段階の開発に最も適しており、それ以降のイテレーションにはあまり効果がありません。

プロジェクトが XP で実行可能であることを確認したら、リリーススケジュールを作成します。ただし、フィードバックを得るために、早い段階で頻繁にリリースする必要があることを意識しましょう。そのためにできることは次のとおりです。

• プロジェクトを複数のイテレーションに分割し、それぞれの計画を作成する。

• 現実的な期日と持続可能なペースを設定する。

• アップデートを随時共有することで、チームが誠実で透明性のある行動をとれるようにする。

• リアルタイムの最新情報を共有することで、チームがいち早く状況を把握し、適応し、変更を加えられるようサポートする。

• プロジェクト管理ツールを使って、かんばんボードやタイムラインを作成し、リアルタイムで進捗を確認する。

2. 管理

XP の伝統的な考え方では、チームメンバー全員が 1 つの部屋に集まって仕事ができるオープンワークスペースを使用することを推奨しています。XP は共同作業の多い手法であるため、物理的に集まれる空間があることはとても重要なことです。しかし、これは現代においては必ずしも現実的なことではありません。もしリモートチームで仕事をしているのであれば、リモートコラボレーション用に非同期作業をサポートするプラットフォームの利用を検討してみてください。そうすれば、物理的に一緒にいなくても、メンバー全員が一緒にプロジェクトに取り組むことができます。

他のアジャイル手法と同様に、毎日のスタンドアップミーティングでチェックインを行い、常にオープンなコミュニケーションを促します。週次サイクルと四半期サイクルの両方を使用することをおすすめします。四半期サイクルでは、チームと一緒に、作業の指針となるストーリーをレビューしましょう。また、XP のプロセスを確認し、ギャップや変更を加える機会を探ります。次に、週次サイクルで作業します。週次サイクルは、それぞれ顧客とのミーティングから始まります。顧客は、その週にプログラマに取り組んでほしいユーザーストーリーを選びます。

マネージャーやチームリーダーは、作業の進捗を管理し、ペースを計り、バグや問題が発生したらチームメンバーの作業内容を調節し、XP プロセスを現在のプロジェクトやイテレーションに合うように変更することに重点を置きます。XP のゴールは、柔軟な対応と行動をとることです。そのために、チームメンバーが現在行っている作業に焦点を当て、あらゆる変更に対応することになります。

3. 設計

エクストリームプログラミングの初心者であれば、できるだけシンプルな設計から始め、後のイテレーションでより複雑になることを想定しておきましょう。この段階では初期の機能を追加せず、できるだけシンプルに保つようにします。

XP 手法のチームは、設計の各オブジェクトがどのように相互作用するかを示すために、しばしば CRC (クラス - 責務 - 協調) カードを使用します。カードの各フィールドを埋めることで、すべての機能が関連し、相互作用する様子を視覚的に把握できます。CRC カードには以下が含まれます。

• クラス (同じようなオブジェクトの集合)

• 責務 (クラスに関連する事柄)

• 協調クラス (上記のクラスと相互作用するクラス)

CRC は、プロセスをシミュレートし、起こりうる問題を特定するのに役立ちます。どのように設計するにしても、できるだけボトルネックになりそうな部分を少なくするようなシステムを使いたいものです。そのためには、積極的にリスクを探すことが大切です。潜在的な脅威を発見したら、すぐに 1 〜 2 名のチームメンバーを配置し、それが起こった場合に備えて解決策を見出すようにしましょう。

4. コーディング

XP の特徴として、コーディングプロセスを通じて、顧客と常に連絡を取り合いながら作業を進めることが挙げられます。このようなパートナーシップを築くことで、スプリントの終わりまで待つのではなく、各イテレーションの中でテストを行い、フィードバックを取り入れることができるのです。しかし、XP では、かなり厳しいコーディングルールが定められています。そのルールの一部をご紹介します。

• すべてのコードはコーディング規約に従ったものでなければならない。

• ユニットテストを使って要件を確実に満たすことにより、プロジェクトのすべての要素を開発する。

• ペアプログラミング - 2 人の開発者が 1 台のコンピューターで同時に作業を行う。これにより、同じ時間で、集中力を高めて、最高品質の結果を出せるようになる。

• 継続的インテグレーションを使って、新しいコードを追加してすぐにテストする。

• エラーを減らすために、常に 1 組だけがコードを更新できるようにする。

• コードの集団所有権 - チームのどのメンバーでも、いつでも他の人の書いたコードを変更できる。

5. テスト

エクストリームプログラミングでは、プロセス全体を通してテストを行う必要があります。コードはすべて、リリースされる前にユニットテストに合格する必要があります。もしこれらのテスト中にバグが見つかったら、それを修正するために新しい追加のテストを作成します。その後、これまで取り組んできたユーザーストーリーを受け入れテストに設定します。このテストでは、顧客が結果をレビューし、ユーザーストーリーをいかにうまく製品に反映させたかを確認します。

エクストリームプログラミングの 12 のプラクティスとは

さらにプロセスを改善するために、XP ではプロセス全体を通して 12 のプラクティスを取り入れています。アジャイルソフトウェア開発宣言がベースになっていますが、次のように、XP のニーズに合うようにアレンジされています。

1. 計画ゲーム: XP の計画は、作業の指針として使われます。計画の結果には、いつまでに何を達成するのか、次に何をするのか、などが含まれる必要があります。

2. 顧客テスト: 新しい機能が完成したら、顧客の立場から受け入れテストを行い、それが元のユーザーストーリーにどれだけ近いかを判断します。

3. 小規模リリース: XP では、プロセス全体を通してインサイトを得るために、定期的に小規模リリースを行います。多くの場合、リリースは顧客に直接送られますが、社内で行われることもあります。

4. シンプルな設計: XP のシステムはシンプルに設計されています。つまり、必要なものだけを作り、それ以外は作らないということです。

5. ペアプログラミング: エクストリームプログラミングでは、開発者が 2 人 1 組になって、プログラミングを行います。この手法では、1 人で作業することはありません。

6. テスト駆動開発 (TDD): XP では、フィードバックに重点を置くため、大量のテストが必要となります。短いサイクルの中で、プログラマは自動化されたテストを作成し、テスト結果にすぐに対応します。

7. リファクタリング: これは、コードベースの細部にまで気を配り、重複を排除し、コードがわかりやすいものかを確認するプラクティスです。その結果、良質でシンプルな設計が可能になります。

8. 集団所有権: ペアは、自分が開発したかどうかにかかわらず、いつでもコードを変更できます。XP では、チームとしてコードを作成するので、全員が共通の高い基準をもって仕事に取り組めます。

9. 継続的インテグレーション: XP チームは、イテレーションの完成を待たずに、継続的にインテグレーションを実行します。多くの場合、XP チームは 1 日に何度もインテグレーションを行います。

10. 持続可能なペース: XP での作業はハードであるため、持続可能なペースを設定することが大切です。チームはこのやり方で一日、一週間にどれだけの成果を出せるかを決め、それを元に仕事の締め切りを設定します。

11. メタファー: メタファーとは、「隠喩」を意味する言葉です。XP では、チーム全員が「こう動くべきだ」というビジョンを共有し、そのためにチームで言葉を選んで表現します。一例として、集団で蟻塚を作り上げる蟻が挙げられます。

12. コーディング規約: XP チームは一つの規約に従います。複数のライターがブランドボイスに則っていつも同じ人が書いているように聞こえる文章を書くように、XP チームも一人の開発者が書いたコードのようにするために、同じ統一された方法でコーディングします。

ハードかつ効果的な手法

そろそろ、エクストリームプログラミングが、その名の通りエクストリームであることがわかってきたと思います。そのプロセスは厳密で高度に構造化されていますが、それだけに価値のある結果が得られる可能性があります。XP のユニークな開発プロセスには、顧客からのフィードバックや、ハードでコラボレーションに満ちたプログラミングが盛り込まれており、その結果、高品質のソフトウェアを生み出せます。

仕事の変化に合わせてリアルタイムでアップデートして調整できるワークマネジメントツールで、XP の計画と管理を合理化しましょう。