■「アジャイル型開発」の代表的手法
アジャイル型開発については、いくつかの手法が知られています。ちょっと概念的すぎる手法も含まれていますが、そのいくつかを紹介してみたいと思います。
アジャイル型開発の代表的な手法としては、
（１）スクラム
（２）エクストリーム・プログラミング（XP：Extreme Programming）
（３）ユーザー機能駆動型開発（FDD：Feature Driven Development）
などがあります。
今回は、（１）のスクラムと、（２）のエクストリーム・プログラミング（XP）について紹介してみましょう。
■（１）スクラム
「スクラム」というと、誰もがラグビーの「スクラム」を想像すると思います。その通りで、スクラムの語源はラグビー。少人数のチームが、がっちりとスクラムを組んで、開発を進めていくことをいいます。
スクラムのメンバーには、次のようなものがあります。
・プロダクトオーナー …プロダクトの責任者。ユーザーからの要望を理解し、メンバーに伝えます。
・スクラムマスター …スクラムの進行役です。デイリースタンドアップミーティングを行い、スプリントの計画やレビュー、振り返りを行います。
・スクラムチーム…スクラムの作業（スプリント）に参加するすべてのメンバーです。
スクラムの進行は、アジャイル型の一変形であって、よく似ています。
スクラムは、1過程2週間程度の「スプリント」と呼ばれる1スパンで作業を行います。
まず、バックログと呼ばれる課題群から、スクラムマスターがやるべき仕事を決定します。
それから、計画セッションと呼ばれる打ち合わせを行います。その時に、バックログの項目の中で重要なものを選び出し優先順位をつけます。
計画セッションが終われば、スプリントの開始です。開発に集中し、2週間で一つの成果を出します。
スプリント中は、毎日チームで朝一番に15分間のミーティングを行い、進行状況を説明し合って共有します。また、難しい問題などが起きれば、優先順位をそのつど調整していきます。デイリースタンドアップミーティングと呼ばれます。
スクラムスプリントの2週間が終われば、チームで集まってレビューを行います。2週間のスプリントで完了した仕事を報告し合い、完成度に問題がないかチェックを受け、確認します。
1スプリントが終わったら、振り返りの会議を行い、反省点を話し合い、次の改善点を提案します。
スクラムでは、常に改善し続けることが重要で、新しい開発手法にチャレンジし、効果がなければ戦略は修正されていきます。
こうして出来上がった製品（ソフトウェア）は、スプリントの終わりに納品されていきます。これを「製品インクリメント」と呼びます。製品インクリメントの中には、新製品だけでなく、機能追加やバグ修正なども含まれます。製品インクリメントが完了しているかどうかは、レビューで判断されます。
スクラムメンバーには、それぞれのタスクの責任を分担して持ち、責任を共有することで積極的に計画に参画することができます。
スクラム開発では、最初の完成品は完璧ではありませんが、反復的な開発によって、徐々に完成度を上げていくことができます。
■（２）エクストリーム・プログラミング（XP：Extreme Programming）
エクストリーム・プログラミングも、アジャイル型開発の手法の一つですが、最初に開発するものをシンプルにし、それからの生育に重きを置いたものといえます。
XPの考え方では、「5つの価値」と「19のプラクティス」が重視されます。
★5つの価値
まず「5つの価値」とは、コミュニケーション、シンプル、フィードバック、勇気、尊重です。
・コミュニケーション
XPでは、非常にコミュニケーションを重視します。チーム内だけでなく、お客様とも頻繁にコミュニケーションを取り、成果物が意図通りかを確認していきます。
・シンプル
XPの最初の設計は、基本機能だけを盛り込んだ非常にシンプルなものにします。他の機能が必要になった時には、その時点でのイテレーションで対応するようにします。
・フィードバック
不要な機能は、開発においては無駄になるので、極力排します。お客様とのコミュニケーションで、緻密なフィードバックを行い、必要な機能だけをピックアップするようにします。
・勇気
XPでは、途中での大きな設計変更にも、勇気をもってチャレンジすることにします。
・尊重
XPでは、チームメートの意思を尊重し、協力しながら仕事を進めていきます。
★19のプラクティス
また、XPでは、いくつかのプラクティスを実践していきます。主なプラクティスは以下のようなものです。
●共同プラクティス
XPに関わる全てのメンバーを対象とします。
・反復…2週間単位のイテレーションを何度も繰り返して、開発を進めます。
・開けた作業空間…作業環境を密室化せず、開発チームとお客様の間でコミュニケーションがとりやすい空間を作ります。
・共通の用語…言葉の定義に間違いがないよう、用語集を作ってメンバー間で共有します。
・回顧…ミスの再発を防ぐために、以前の作業からのフィードバックを生かしていきます。
●開発プラクティス
開発プラクティスは、開発チームが対象ですが、革新的な手法が多く紹介されています。
・ペアプログラミング…2人1組で行うプログラミングです。1人がコードを書き、もう1人がコードを確認します。
・テスト駆動開発…まず最初にテストコードを書き、それに通るようなプログラムを書くという方法です。逆転の発想ですが、これによりシンプルなコードが実現します。
・リファクタリング…完成したコードを分かりやすく書き直すことです。外部の動作を変えず、内部だけ修正します。他の人にとってもメンテナンスしやすくなります。
・ソースコードの共同所有…開発したコードを共同所有することで、書き方が平準化され、また共同所有により、開発のスピードアップが期待できます。
・YAGNI…「You Aren't Going to Need It」の略で、直訳すると「それは必要ありません」。逆に言うと、必要なコードだけ書きましょう、という意味です。無駄な記述は極力排します。
・継続的インテグレーション…開発したコードを1日数回という頻度でマスターに統合するということです。1回の変更量を減らして頻繁にマージすれば、問題が早く発見でき、対処が楽になります。で構成されています。
●管理者プラクティス
プロジェクトを管理するメンバーが対象となるプラクティスです。
・責任の受け入れ…最終的な開発の責任が責任者にあることを自覚します。
・援護…不足や問題のある部分があれば、開発の援護を行います。
・ミラー…現在の状況を把握し、チーム全体に共有し、プロジェクトの中で迷子になることを防ぎます。
・四半期毎の見直し…四半期ごとに状況を見直し、進行を的確に行います。
・最適なペースの仕事…仕事が過度にならないよう、進行を調整します。
●顧客プラクティス
XPでは、お客様もチームの一員とします。作業の優先順位をつけるのは、お客様の役割です。顧客プラクティスは、お客様が行うべき作業です。
・ストーリーの作成…必要とする機能を、ストーリーカードに短く書きだします。チームは、そのカードを元にミーティングを行い、開発の手順を決めます。
・リリース計画…各イテレーションで、ストーリーカードに書いたどの機能をリリースするかを提案し、チームと相談します。
・受け入れテスト…イテレーションごとに受け入れテストを行い、決定した内容が実装されているかを確認します。
・短期リリース…完動するプログラムを最短で2週間、長くても2ヶ月ほどでリリースします。
このような手法です。アジャイル型開発の各手法は、どれも基本的な点では似通っていますが、細部で異なることが分かるでしょう。
こうして手法を紹介するだけでも、いくつか部分的にでも試してみたいやり方が見つかったのではないでしょうか。次回も引き続き、手法について解説していきたいと思います。