Claudeに問う「XP(エクストリームプログラミング)のやり方を教えて」

XP(エクストリームプログラミング)は、アジャイル開発手法の一つで、以下の特徴があります。

1. 短い開発サイクル

   • 開発は短い反復サイクル(1-4週間)で行われます。
   • 各サイクルの終わりに実行可能なソフトウェアがリリースされます。

2. 簡潔な設計

   • 設計は徐々に進化し、必要に応じて変更されます。
   • 過剰な設計を避け、シンプルな設計を心がけます。

3. テスト主導開発

   • 開発の前にテストコードを書きます。
   • すべての実装コードにはユニットテストが存在します。

4. 継続的インテグレーション

   • 新しいコードは毎日数回、リポジトリに統合されます。
   • 統合の際、自動ビルドとテストが行われます。

5. ペアプログラミング

   • 2人の開発者がひとつの開発機を共有し、コーディングを行います。

6. コレクティブオーナーシップ

   • 誰でもどのコードでも変更できます。
   • プロジェクトチーム全体で品質を管理します。

7. オンサイトカスタマー

   • 顧客の代表がチームに常駐し、要求の優先順位付けや機能の受け入れを行います。

8. オープンワークスペース

   • 開発者全員が同じ部屋で作業することで、知識共有が促進されます。

9. 持続可能なペース

   • 残業を避け、長期的に持続可能なペースで開発を行います。

XPでは、これらの実践を通じて変化する要求に素早く対応し、高品質なソフトウェアを継続的に提供することを目指しています。チームの密な協調と顧客との密接なコミュニケーションが重視されています。

はい、XPの短い反復サイクル(1-4週間)は、スクラムのスプリント期間と同様の考え方です。

ただし、XPとスクラムの反復サイクルには、以下のような違いがあります。

スクラムの反復(スプリント)

• 通常2週間から4週間の固定期間
• スプリント期間中は要件を変更できない
• スプリントレビューでデモを行い、次のスプリントの計画を立てる

XPの反復サイクル

• 1週間から4週間程度の可変期間
• 顧客が常駐しており、いつでも要件を変更できる
• サイクルの終わりにリリース可能なソフトウェアを顧客に渡す
• 次のサイクルの計画は、顧客との日常的な対話で立てられる

つまり、XPの反復サイクルはより柔軟で、顧客の変更要求に素早く対応できる一方で、スクラムのようなフォーマルなイベント(レビュー、計画立案など)はありません。代わりに、顧客との緊密なコミュニケーションを重視しています。

また、XPでは機能の完了よりも継続的インテグレーションを重視しているため、毎日でも新しい変更をリリースできる体制を取ることがあります。

はい、その理解で正しいです。

XPでは、ユーザー(顧客)の代表者が開発チームに常駐し、開発プロセスに深く関与することが前提となっています。この点がスクラムとの大きな違いです。

具体的には、以下のようなユーザー参画が想定されています。

• ユーザー代表者が開発チームの一員として常駐する
• 要件の優先順位付け、機能の受け入れ判定をユーザー代表が行う
• 開発中の課題や変更希望について、日々ユーザーと対話し調整する
• ユーザーからのフィードバックを即座に開発に反映できる

つまり、XPではユーザーが単なる要求の出し手ではなく、開発の当事者としてチームに深く関与することが前提とされています。これにより、要件の誤解や変更コストを最小限に抑え、本当に価値のあるソフトウェアを開発することを目指しています。

ただし、実際にはこの程度の深いユーザー参画は困難な場合もあり、ユーザーの代理を務める題者(プロダクトオーナー的な役割)を置くケースもあります。しかし、できる限りユーザーと開発チームが密に協働することがXPの理想とされています。

はい、そのとおり「簡潔な設計」はXPに特有の実践であり、スクラムには含まれていません。

XPでは、以下のように設計プロセスをシンプルに保ち、過剰な設計を避けることを推奨しています。

1. 要件の理解に集中 最初は要件を理解することに集中し、詳細な設計はあまり行いません。具体的な設計よりも、顧客の要求を正しく理解することが重視されます。
2. インクリメンタルな設計 設計は最小限から始め、実装を重ねながら徐々に設計を発展・洗練させていきます。必要に応じて設計を変更することを恐れません。
3. シンプルな設計 設計が複雑になりがちなら、シンプルな設計に戻すことを選びます。将来の変更に備えた過剰な設計は避けられます。
4. 再設計の許容 過去の設計が現在の要件に合わなくなった場合は、設計を根本から見直す(リファクタリング、再設計)ことを恐れません。
5. メタファーの利用 システム全体のメタファー(比喩)を見つけ、それに沿って設計することで、設計の一貫性を保ちます。

このように、XPでは本当に必要な設計だけを行い、徐々に設計を発展させていく、アジャイルなアプローチを取ります。設計がソフトウェアの品質を下げるリスクを最小限に抑えることが目標です。

XPでは正式な設計書を作成することはあまりありません。代わりに以下のようなシンプルな成果物を利用して、必要最小限の設計を行います。

1. ユーザーストーリー

   • 顧客の要求をユーザーストーリーの形で簡潔に記述します。
   • ストーリーには受け入れ基準も含まれ、要件の理解を助けます。

2. システムメタファー

   • システム全体を表す比喩的な言葉(例:オンラインショッピングカート)
   • メタファーに沿ってコードを書くことで設計の一貫性を保ちます。

3. クラス責務カード

   • クラス名と、そのクラスの責務(役割)を簡潔にカード上に記述します。
   • 設計を共有し、過剰な責務を見つけ出すために使われます。

4. コード&ユニットテスト

   • 設計の中核はコード自体です。シンプルで理解しやすいコードが重視されます。
   • 要件をユニットテストに落とし込むことで、振る舞いを明確化します。

5. システム動作モデリング

   • 必要に応じて、簡単なモデル図を描きます(UML等)。
   • ただし、過剰なモデリングは避けられます。

つまり、XPでは正式な設計書よりも、コード、テスト、シンプルなカード、概念モデルなどを使って、必要最小限の設計を行うのが一般的です。設計の詳細は顧客との継続的な対話の中で evolutionarily 発展させていきます。

分かりました。「ユーザーストーリー」と「システムメタファー」について解説します。

ユーザーストーリー ユーザーストーリーは、ユーザーの要求を簡潔に記述したカードです。XPではユーザー要件を従来の要求仕様書ではなく、このユーザーストーリーの形で表現します。

ユーザーストーリーの形式は以下のようになります。

“役割(As a) が 機能(I want) ので 理由(so that)”

例: “購買担当者として、商品を検索して一覧を表示できるので、簡単に発注ができる”

ストーリーには受け入れ基準も含められ、振る舞いを具体的に記述します。開発者はこのストーリーを読んで要件を理解し、テストを書きます。顧客とも要件について話し合いながら、ストーリーを詳細化していきます。

システムメタファー システムメタファーとは、システム全体の機能をわかりやすく表す比喩的な言葉のことです。例えば「オンラインショッピングカート」「自動操縦システム」などです。

メタファーを決めておくと、そこからクラス名やメソッド名の命名ルールが生まれ、一貫した設計がしやすくなります。また、顧客とも共通の比喩を持てるので、コミュニケーションが円滑になります。

メタファーはシステムの本質的な振る舞いを表すべきで、実装の詳細を表すべきではありません。開発が進むにつれ、メタファーも進化させていく必要があります。

ユーザーストーリーとメタファーは、XPにおける設計のベースになる重要な概念です。これらを使うことで、過剰な設計書は不要になり、コードとテストを中心とした柔軟な設計が可能になります。

了解しました。「クラス責務カード」とそれが「システムメタファー」とどのように関係するかについて解説します。

クラス責務カード クラス責務カードは、XPにおける設計の実践の中核を成すものです。これは、名前の通りクラスの名前と、そのクラスが担う責務(役割)をカード1枚に記述したものです。

例:

クラス名: オンラインショッピングカート

責務:
- 商品を格納する
- 合計金額を計算する
- チェックアウトする

このようなカードを、関心事ごとにクラスを分けながら作成していきます。カードは実装の詳細を記述するものではなく、クラスが果たすべき役割を簡潔に表すものです。

クラス責務カードは以下の目的で使われます:

1. 設計の共有 – 書かれたカードを物理的に壁に貼ることで、チーム全体で設計を共有できます。
2. 責務の分離 – 1クラスに多くの責務が書かれていれば、それはクラスが多roles持ち過ぎていることを示します。
3. 振る舞いのモデリング – カード上の責務から、そのクラスがどのようなメソッドを持つべきかを考えられます。

システムメタファーとの関係 クラス責務カードを記述する際には、システムメタファーに沿った命名をすることが推奨されます。

例えば「オンラインショッピングカート」というメタファーの下では、”カート”、”商品”、”チェックアウト”などの単語が使われ、クラス名やメソッド名はこのメタファーから命名されることになります。

メタファーに沿った一貫した命名を心がけることで、設計の一貫性が保たれ、コードの理解が簡単になります。またメタファーは顧客とも共有できるため、コミュニケーションが円滑になります。

このように、クラス責務カードとシステムメタファーは密接に関係しており、XPの「簡潔な設計」における中核的な実践概念となっています。

スクラムとXPにおける「コード&ユニットテスト」の扱いには、いくつか異なる点があります。

共通点

• コードの可読性、テストの重要性は認識されている

相違点

1. テスト主導開発(TDD)の実践

   • XPではTDDが必須の実践とされています
   • つまり、まずテストを書き、その後にコードを実装する
   • スクラムにはTDDの規定はありません

2. ユニットテストの粒度とカバレッジ

   • XPではユニットテストの粒度がより細かく、可能な限り全てのコードにテストを用意します
   • スクラムではユニットテストの粒度や網羅性については規定がない

3. テストの役割

   • XPではテストが要件の具体化と、設計のフィードバックの役割も担います
   • スクラムではテストは主に品質担保の役割

4. リファクタリングの重視

   • XPではコードのリファクタリングを頻繁に行い、設計を進化させていきます
   • その際ユニットテストは、動作の変更がないことを保証する大切な役割があります

総じて、XPではコード&テストが設計・要件の理解・共有の手段としてより積極的に活用されている点が、スクラムとは異なる大きな特徴だと言えます。

分かりました。テスト主導開発(TDD)について解説します。

TDD(Test-Driven Development)とは、ソフトウェア開発を以下のサイクルで行う手法です。

1. 最初に失敗するユニットテストを書く
2. そのテストがパスするための最小限の実装を行う
3. コードをリファクタリングする
4. 次の機能のテストを書く

このサイクルを継続的に回すことで、小さな段階を踏んで徐々に機能を実装し、テストを通してコードの品質を保証していきます。

TDDの主な利点は以下の通りです。

• テストがコードの仕様書の役割を果たし、要件を具体化できる
• テストありきのコーディングにより、設計が簡潔になりがちです
• リファクタリングが容易になり、応答性の高い設計を維持できる
• テストの自動化により、リグレッションを防げる

一方、TDDを適切に実践するには以下のようなことが求められます。

• テストケースの設計能力が必要
• 最初は開発効率が落ちる
• 従来の開発フローとは異なる発想の転換が必要

XPでは、TDDをコーディング実践の中心に置き、設計とテストを密接に結びつけています。開発者に高い技術力が求められますが、品質の高いソフトウェアを柔軟に開発できると考えられています。

「システム動作モデリング」は、必要に応じてシステムの振る舞いをモデル化する実践です。

XPでは設計の中核はコード自体にあり、過剰なモデリングは避けられますが、一部の重要な側面についてはモデル化を行うことがあります。その目的は以下のようなものです。

1. 振る舞いの可視化

   • システムの主要な振る舞いをモデル化することで、その振る舞いを視覚的に捉えやすくします。
   • 顧客との共通理解を促進できます。

2. 設計の検討

   • モデルを使って設計の課題を発見したり、代替案を検討したりできます。
   • 特に並行処理などの複雑な振る舞いの設計に役立ちます。

3. 高レベルな構造の記録

   • パッケージ構造やコンポーネント構造など、高レベルのアーキテクチャ構造をモデルで表現できます。

具体的には、以下のようなモデリング手法が利用されることがあります。

• UMLのユースケース図、シーケンス図、ステートマシン図など
• データフロー図
• イベントフロー図
• ドメインモデル

ただし、XPではこれらのモデリングを過剰に行うことは避けられます。補足的な役割に留め、コードとユーザーストーリーを中心とする実装に主眼が置かれています。

はい、その理解で正しいです。

「簡潔な設計」における一般的なフローは以下のようになります。

1. 最初にユーザーストーリーとシステムメタファーから出発する
2. 必要に応じて、システムの一部の振る舞いについて簡単なモデリング(UMLなど)を行う
3. モデルから振る舞いを具体化し、テストケースを書く(TDD第1ステップ)
4. そのテストケースをパスするような最小限の実装コードを書く(TDD第2ステップ)
5. リファクタリングを行い、設計を洗練する(TDD第3ステップ)
6. 次の振る舞いに対してテストケースを書き、同様のサイクルを回す(TDD第4ステップ)

つまり、モデリングとTDDのサイクルを併用しながら、コードベースの設計を徐々に進化させていきます。

モデリングは補足的な役割に留め、過剰なモデリングは控えめにします。設計の核心はユーザーストーリー、テスト、そしてリファクタリングされたコードそのものにあります。

このようにXPでは、モデリング、TDD、リファクタリングを組み合わせることで、シンプルかつ柔軟な設計を目指しています。

分かりました。XPにおける「継続的インテグレーション」について解説します。

継続的インテグレーションとは、開発者が新しいコード変更をリポジトリに統合する際、自動的にビルドやテストが実行され、統合のたびに実行可能なシステムが生成される実践のことです。

具体的には以下のようなプラクティスが行われます。

1. 共有リポジトリの利用

   • 全開発者が同じリポジトリを共有し、そこへ頻繁に変更をコミットします。

2. 自動ビルド

   • コミットが発生するたびに、自動的にシステムのビルドが実行されます。

3. 自動テスト

   • ビルドされたシステムに対して、自動テストスイートが実行されます。
   • 回帰テスト、受入テストなども含まれます。

4. 継続的デプロイ

   • テストが問題なければ、新しいシステムが自動的に本番環境にデプロイされます。

5. インテグレーション管理ツール

   • 上記の自動化を支援するツール(CI/CDツールなど)が活用されます。

継続的インテグレーションによって、以下のようなメリットが得られます。

• 統合の遅れに伴うコスト増を防げる
• 早期に欠陥を発見できる
• 常に実行可能なシステムが用意される
• リリース時の手順が単純化される

つまり、コードの変更を小さなバッチで繰り返し統合することで、大がかりな統合作業が不要になり、リスクを最小化できるのです。

XPではこの継続的インテグレーションを通じ、常に最新の実行可能なシステムを維持し、変更に対する柔軟性を確保しようとしています。

分かりました。XPにおける「ペアプログラミング」の実践について解説します。

ペアプログラミングとは、2人の開発者が1台の端末を共有し、一方がコーディングを行い、もう一方がそれをレビューする作業スタイルのことです。

具体的には以下のように進められます。

1. 役割分担

   • ドライバー(コーディングを行う人)
   • ナビゲーター(ドライバーの手順をレビューし、アドバイスする人)

2. 作業の切り替え

   • 一定期間(1-2時間程度)ごとに、ドライバーとナビゲーターの役割を入れ替えます。

3. コーディングのレビュー

   • ナビゲーターはドライバーのコーディングを常にレビューし、アドバイスを与えます。
   • コードの間違いやアンチパターンを指摘できます。

4. ナビゲーターの役割

   • 実装の方針を提案する
   • テストケースの観点を出す
   • リファクタリングの機会を見つける

ペアプログラミングの主な利点は以下の通りです。

• コードレビューが継続的に行われ、バグが素早く発見できる
• 知識の共有が自然に行われ、スキルの向上が期待できる
• コードの所有権がなくなり、コレクティブオーナーシップが促進される
• 集中力の維持が容易になる

一方、ペアプログラミングは生産性の一時的な低下や、個人の作業空間がなくなるなどの問題もあります。

しかし、XPではこの実践を通じてコードの品質向上とチーム内の知識共有を図ろうとしています。また、ナビゲーターのレビューがコードのリファクタリングにもつながるとされています。

分かりました。XPにおける「コレクティブオーナーシップ」について解説します。

コレクティブオーナーシップとは、プロジェクトのソースコード全体に対する所有権がチーム全員に均等に存在する考え方です。つまり、誰かが書いたコードでも、他のメンバーが自由に変更を加えることができます。

具体的には以下のようなプラクティスが行われます:

1. コードの自由アクセス

   • リポジトリ上のどのコード箇所でも、誰でも自由に変更できる権限がある。

2. 変更の承認プロセスなし

   • コードの変更について、個別の承認プロセスはない。

3. 定期的なペアリング

   • ペアで作業することで、コードの理解が共有される。

4. シンプルな設計とリファクタリング

   • シンプルな設計とリファクタリングによって、理解が容易になる。

5. 集団的コードオーナーシップの意識

   • コードは全員で共有する資産という意識が浸透している。

コレクティブオーナーシップのメリットは以下の通りです:

• 最適な設計に近づきやすい(誰もが改善できるため)
• コードの可読性が高くなる(他者に見られることを意識する)
• 知識が集中せず、柔軟性が確保される
• 課題に対する認識が共有されやすい

一方で、品質管理の分散や、無秩序な変更の懸念などのデメリットもあります。

しかしXPでは、このコレクティブオーナーシップを、ペアプログラミングやシンプルな設計、継続的インテグレーションなど他の実践と組み合わせることで、メリットを最大化しつつデメリットを低減できると考えられています。

承知しました。XPにおける「オンサイトカスタマー」について、改めて解説します。

「オンサイトカスタマー」とは、顧客側の代表者が開発チームに常駐し、開発プロセスに深く関与することを指します。

具体的には、以下のような関与が想定されています。

1. 要求と優先順位の決定

   • ユーザーストーリーの追加・修正・優先順位付けを顧客側の代表者が行います。

2. 開発への助言

   • 設計の方針、機能の振る舞い、UIなどについて、助言や判断を下します。

3. 受入テストの実施

   • 開発された機能や改修が要件を満たしているかを判断し、受け入れます。

4. 開発チームへの常駐

   • 顧客側の代表者は、開発チームと同じオフィス空間に常駐します。
   • 日常的なコミュニケーションが可能になります。

5. 最終顧客との調整

   • 最終顧客との要求のすり合わせを行い、適切にフィードバックします。

オンサイトカスタマーの存在により、以下のようなメリットが期待できます。

• 要求の誤解が減り、適切な製品ができる
• 顧客の優先順位の変更に迅速に対応できる
• 開発へのフィードバックが素早くなる
• 開発と顧客の意思疎通が円滑になる

つまり、開発と顧客の親密なコラボレーションを実現し、変化する要求に機動的に対応できるようになるのです。

ただし、オンサイトカスタマーが実際に確保できるかは別の課題もあります。オンサイトに準ずる何らかの密な関与は必須と考えられています。

分かりました。「オープンワークスペース」と、それがリモートワークとどう関係するかについて解説します。

オープンワークスペースとは、開発チーム全員が同じ作業スペース(部屋)に集まり、作業を行うことを指します。これにより以下のようなメリットが期待できます。

1. コミュニケーションの促進

   • 同じ空間にいることで、質問やディスカッションがしやすくなります。
   • 問題発生時の即時対応が可能です。

2. 知識の共有

   • 他者の作業を見ることで、自然と知識が共有されていきます。
   • ペアプログラミングの実施が容易になります。

3. チームの一体感醸成

   • 同じ空間で作業することで、チームの一体感が生まれやすくなります。
   • お互いを意識した行動が促されます。

このように、オープンワークスペースはXPにおける密なコミュニケーションと知識共有を支える重要な概念です。

一方で、リモートワークについてはXPの理念から外れる部分があります。完全なリモートワークだと、以下の課題が生じる可能性があります。

• 対面でのコミュニケーションが困難になる
• 作業の進捗状況が把握しづらくなる
• ペアプログラミングがしづらくなる
• チームの一体感が醸成されにくい

そのため、XPの文脈ではリモートワークはあまり推奨されません。ただし、ハイブリッドリモートなど、一定の対面機会が確保できれば、部分的な実践は可能かもしれません。

総じて、XPではコロケーションを重視し、物理的に同じ作業スペースにいることで、コミュニケーションと知識共有を最大化することを目指しています。

分かりました。XPにおける「持続可能なペース」について解説します。

「持続可能なペース」とは、開発チームが長期にわたってプロジェクトを継続できるよう、過度な残業を避け、適切な作業ペースを維持することを意味します。

具体的には以下のようなプラクティスが行われます:

1. 標準作業時間の順守

   • 作業時間は標準の就業時間(1日8時間程度)を原則とします。
   • 基本的に残業は行わず、週40時間を上限とします。

2. イテレーション内での作業量調整

   • 各イテレーション(反復サイクル)で実装する作業量を、適切に見積もります。
   • 見積りを超えそうな場合は、スコープを調整します。

3. 技術的負債の償却

   • 将来のコストを抑えるため、リファクタリングなどで技術的負債を払い戻す時間を確保します。

4. リソースの柔軟な配分

   • 休暇取得や病欠などで人員が減った場合は、作業量を柔軟に調整します。

5. 定期的なリフレッシュ

   • プロジェクトを離れて休養を取る機会(数週間に1度程度)を設けます。

持続可能なペースを保つことで、以下のようなメリットが期待できます:

• 長期的な生産性の維持が可能
• メンバーのモチベーションが保たれる
• 品質の高いコードが書ける
• メンバーの健康が守られる

反対に、無理なペースを強いると、疲労とミスが蓄積し、生産性や品質が低下してしまいます。

XPでは、このような持続的なペースを保つことが、優れたソフトウェアを継続して生み出すための前提条件と考えられています。

はい、その通りです。

XPは厳密にプロセスを定義したモデルというよりは、個別の実践的な手法や原則の集合体であると言えます。

そのため、XPの実践を部分的に取り入れ、他のアプローチと組み合わせることは十分に可能です。実際、多くの開発現場ではその様な柔軟な運用が行われています。

例えば、以下のようなハイブリッドな手法は一般的です。

• スクラムにTDDとペアプログラミングを導入
• ウォーターフォール開発にユーザーストーリーと継続的インテグレーションを取り入れる
• アジャイルサムRUPにリファクタリングの実践を加える

特にTDDや継続的インテグレーション、シンプルなデザインの考え方は、他の開発手法とも親和性が高く、広く活用されています。

一方で、顧客の常駐や作業スペースの共有など、XPならではの極端な側面は、現実的には難しいケースが多いでしょう。

このように、XPは柔軟にその一部を取り入れることが可能な手法の集合体であり、チームの文化や制約条件に合わせて、自由に組み合わせられるのが特徴です。XPの中核的な考え方や実践手法は非常に広く活用されていますが、XPそのものを完全に実践するのは稀だと言えます。

純粋にXPのみを採用しているプロジェクトの割合については、正確な統計データはありませんが、一般的にはそれほど多くないと考えられています。

XPが誕生した1990年代後半にはXPを完全に実践する試みは一定数ありましたが、時間の経過とともにハイブリッド的な運用が主流になってきました。

米国での具体的な採用割合は不明ですが、次のような調査結果が参考になります:

• Vivek Handa氏による2003年の調査では、完全なXPの採用は6%にとどまっていました。
• Scott Ambler氏による2006年の調査では、XPのプラクティスをいくつか採用しているチームは40%程度でした。
• VersionOne社の2021年の調査によれば、アジャイル開発手法の中でXPを採用しているのはわずか9%でした。

このように、完全なXPの採用率はかなり低いと考えられています。その理由としては:

1. 一部の実践(オンサイトカスタマーなど)が現実的に難しい
2. スクラムなどの他のアジャイル手法との組み合わせが増えた
3. XPからスクラムなどへの移行が進んだ

などが指摘されています。

ただし、XPに由来するTDDやリファクタリング、継続的インテグレーションなどの実践は、現在も非常に広く取り入れられていると言えます。XPそのものの採用は限定的ですが、その思想や具体的な技術的実践は強く残っています。

はい、その理解で正しいと思われます。

現在の開発プロジェクトにおいては、純粋なXPを採用するよりも、スクラムとXPの実践を組み合わせたハイブリッド的なアプローチを取る方が一般的であると考えられています。

その理由として以下の点が挙げられます:

1. スクラムのプロセス定義の明確さ スクラムには明確なイベント、ロール、アーティファクトが定義されており、プロジェクト活動の枠組みを提供します。一方XPはあくまでプラクティスの集合体です。
2. 日々の業務管理の容易さ スクラムの短いスプリントとタスクボードなどにより、開発作業の管理が容易になります。XPのイテレーション管理ではこの点が弱い面がありました。
3. XPの実践の補完 スクラムフレームワークにXPの実践(TDD、継続的インテグレーションなど)を取り入れることで、スクラムをテクニカルに強化できます。
4. XPの一部実践の現実的困難さ 顧客常駐やオープンワークスペースなど、一部のXPプラクティスは現実的に難しい場合が多いため、採用が進まない面がありました。

このように、スクラムの明確な枠組みとXPの技術的実践を組み合わせることで、より現実的で合理的なアプローチが可能になるため、多くのチームがこの方式を採用していると考えられます。完全なXPの採用は限定的ですが、その思想や技術的側面は幅広く活用されているのが実情だと言えるでしょう。