おわりに
今回は、アジャイル開発のXPとスクラムの概要を説明しました。また、皆さんが直面している開発上の課題を解決するために、XPとスクラムのプラクティスを選択的に導入する方法とその効果をお話しました。
表に、XPとスクラムの各プラクティスとその導入効果／留意事項についてまとめます。実際に導入した経験から得た“お奨め度”もあります。ぜひ、実際の開発現場で活用してみてください。
| プラクティス | 定義元手法 | お奨め度 | 導入効果／留意事項 |
| イテレーション／スプリント （リリース計画策定と、受け入れテスト／スプリントレビューを含む） |
XP、スクラム | ◎ | 短期的な分かりやすいゴールの設定により、開発者の集中力を維持。また、プロジェクトの方向性を細かく修正することが可能で、最終的な手戻りを防ぐ効果あり |
| テスト駆動型開発 | XP | ○ | 常時テストを繰り返すことによって、品質を維持できる。ただし、設計時にすべてのテストを見極めきれないケースもあり、適用範囲が限られる |
| ペアプログラミング | XP | ○ | 思い込みによる障害の作り込みを減らすことができる。ただし、チームメンバーの開発スキルのばらつきにより、向き不向きあり |
| リファクタリング | XP | ○ | 「まずは最低限の機能を実装」といった開発工数の最小化が見込める。ただし、本当に必要な部分だけをリファクタリング対象にするバランス感覚が必要 |
| ソースコードの共同所有 | XP | △ | 保守性の観点から重要だが、無責任な修正が起きうるなど、運用に注意が必要 |
| 継続した結合 | XP | △ | 常時テストを繰り返すことが可能となり、製品やプロジェクト全体レベルでの品質を維持できる。ただし、テストの自動化が困難なケースがあることを考えると、適用範囲の絞り込みが必要 |
| YAGNI | XP | △ | 開発機能の最小化が見込める。ただし、製品やプロジェクトの基幹／基盤機能は、今必要な機能の実装だけで本当に良いのか注意が必要 |
| ストーリー／機能コンセプトの作成 | XP、スクラム | ◎ | 企画者、設計者、開発者全員が製品の機能を正しく理解できる |
| スクラム会議 | スクラム | ◎ | 課題の整理と抽出が確実にできる。また、チームメンバー全員が個々の進捗／課題を理解し、いっしょに考えるきっかけとなる |
次回は、ウォーターフォール開発とアジャイル開発の組み合わせ（良いとこ取り）について説明します。お楽しみに。
今月の復習問題
以下の問題文を読んで、正しいものに○、間違っているものに×を付けてください。
- 問題1：XPとスクラムはアジャイル開発に分類されるものの、具体的な実践手法（プラクティス）はまったく別物だ。
- 問題2：XPやスクラムは、それぞれで定義される全プラクティスを導入しなくても、プラクティス単位で採用するといった選択的な導入が可能だ。
- 問題3：XPやスクラムさえ導入すれば、開発上の問題は一挙に解決する。
復習問題の答え
- 問題1：×
- 問題2：○
- 問題3：×
XPは開発主体、スクラムはマネージメント主体という違いはあるが、開発を反復により推進したり、課題の共有や解決のための具体的手法を提案するなど、多くの共通点が存在する。
開発現場のお困りケースに合わせた選択的導入が可能。
XPやスクラムのプラクティスはあくまでも手法の提案であり、実際の開発現場にどのくらい適合するかは、導入してみないと分からない。導入してからの継続的な改善が重要である。
スロージン20ml、アプリコットブランデー20ml、レモンジュース20mlをシェイクし、氷を入れたグラスに注いで出来上がり。色鮮やかな華やいだ中にもそこはかとない大人の苦みを感じるしゃれた一品です。
アジャイル開発を初めて行なう際には、XPやスクラムなどのプラクティスの中で、どれをやる、どれはやらないという方針を最初に決めることが大切です。そして、やると決めたものは、自社に合った（合いそうな）やり方を具体的に定めて実践してみましょう。本連載で紹介したプラクティス一覧表に○×を付けたりして、「よし、これでやろう！」と自信を持って一歩踏み出してみてください。カンパーイ！（梅）
