スクラム～チーム一丸となって開発を進める～
スクラムは1993年にジェフ・サザーランドらにより考案された手法で、ラグビーのスクラムに因んでいます。スクラムはマネージメント主体に内容を定義しており、本手法もXPと同様6～7名といった少人数での開発に向いていると言われています。
スクラムでは、開発チームの中にチーム代表のスクラムマスターを定義し、スクラムマスターがチーム全体をコントロールします。従来のプロジェクトマネージャの役割と考えてかまいません。さらに、チームのほかに製品やプロジェクトに責任を持つプロダクトオーナーを定義し、製品やプロジェクトの方向性をチェックします。
以下に代表的なプラクティス（※注）を示します。
スクラムではプラクティスという概念はありませんが、本稿ではXPとの対比のために実践的な手法の意味でプラクティスと表記します。
バックログ作成
要件の定義と、機能ごとの詳細仕様を定義すること。以下に分類される。
- 製品バックログ
- リリースバックログ、スプリントバックログ
求める機能のコンセプトを定義する。製品の外部仕様や顧客の要件に近い。
製品バックログを詳細化し、ある反復で実装する機能／項目を定義する。
開発推進
- スプリント
- スクラム会議
- スプリントレビュー
開発期間を1～4週間の短い期間（スプリント）に区切り、期間ごとに部分的な設計／実装／テスト／レビュー（後述）を繰り返す。
毎日開催（通常朝一番を想定）するチーム内の意識合わせの会。15分以内で完了させることが望まれる。スクラムマスターがチーム全員に、「昨日何を行なったか」「問題はあるか」「本日は何を行なう予定か」を質問し、回答を確認する。この会議で上がった問題を解決する会を、必要に応じて別途実施する。
スプリントで完了した機能の確認と、次のスプリントで実装すべき機能の確認をプロダクトオーナーやチームメンバーを含めた関係者全員で実施する。
これらのプラクティスに従った開発の全体像を図2に示します。
XPによる開発の進め方にかなり似ていますが、スクラムはマネージメント主体という趣旨のとおり、毎日のチーム内ミーティング（スクラム会議）の実施やその進め方、および各スプリントの終了時に実装した機能と今後実装する機能について関係者全員で確認するミーティングの実施（スプリントレビュー）がプラクティスとして明確に定義されています。
XPやスクラムのミーティングは、よく「スタンドアップミーティング」が良いと言われています。“スタンドアップ”という名のとおり、ミーティング中は立ったままで議論を進めます。
立ったままで議論を進めることで、次の効果が期待できます。
- 皆が議論に集中する
- 短い時間で効率的に進める癖がつく
ただし、長時間立ったままで議論すると、疲れてしまうので逆効果です。やはり方法論だけに頼るのは禁物ですね。
アジャイル手法／プラクティスの取捨選択
XPやスクラムを定義するプラクティス（実践的な手法）については少しずつイメージを掴めてきたかもしれませんが、これらのプラクティスをいま直面しているソフトウェア開発の現場にどのように導入していくのでしょうか。
ここでは、さまざまなプラクティス導入の際に持つ疑問や不安について、考えていきます。
XPやスクラムを全面的に導入しないといけないの？
XPやスクラムの解説は世の中にたくさんありますが、どれもXPやスクラムのすべてのプラクティスを開発工程に導入すること（全面的導入）を前提にしているように思われます。いま皆さんが導入している開発手法や業務フローを全面的に変更することは極めて難しいことでしょう。また、何らかの良い成果を確認できてから全面的に導入したいと思うでしょう。
例えば、アクセラテクノロジではいくつかのプロダクト開発プロジェクトでアジャイル開発を実施していますが、XPやスクラムの全面的導入には至っていません。やはり、会社や組織の持つ特性と合わなかったり、プロダクト開発の理念と合わせづらい部分があるからです。そのため、XPのあるプラクティスと、スクラムのあるプラクティスを選択して使用するという“良いとこ取り”を実践しています。
つまり、XPやスクラムを全面的に導入するのではなく、プラクティス単位での部分導入でも十分な効果をもたらすことができると考えているのです。
どのようにプラクティスを選択して導入するの？
現在の開発において、何に困っているかを明確にすることがポイントとなります。よく耳にする代表的なお困りケースと、それに対応したプラクティスを見ていきましょう。
- 外部仕様が徹底されず、完成したものが仕様を満たしていない
- 仕様の変更が多く、ゴールが見えない。士気が落ちている
- 課題がチームで共有されず解決が人任せ。特定の開発者に負荷が集中する
- 品質が悪い。後からテスト項目の抜けに気がつく
- 将来の機能拡張を考慮したら、開発工数が爆発した
- 開発者が異動／入院／退職したため、その開発者の書いたコードを誰もメンテナンスできない
- 開発スケジュールが遅延しがち。リリース日を守れない
XPのストーリー作成／受け入れテスト、スクラムの製品バックログ作成／スプリントレビューにより、製品やプロジェクトとしての目標や顧客の要望の整理が有効ではないでしょうか。定期的なゴールの確認は重要です。
短い単位での開発を繰り返すXPの反復（イテレーション）／リリース計画やスクラムのスプリント／スクラム会議は、短期的な分かりやすいゴールの設定により、開発者の集中力を維持できます。また、プロジェクトの方向性を細かく修正することが可能で、最終的な手戻りを防ぐ効果があります。
スクラムのスクラム会議のような定期的な短時間ミーティングを実施することで、課題の整理と抽出が確実にできます。また、チームメンバー全員が個々の進捗／課題を理解し、いっしょに考えるきっかけとなります。
XPのテスト駆動型開発や継続した結合の導入により、常時テスト＆結合を繰り返すことが可能となり、製品やプロジェクト全体レベルでの品質を維持できます。ただし、設計時にテストすべてを見極めきれなかったり、GUIのようなテストの自動化が困難なケースもあり、適用範囲が限られることがあります。また、XPのペアプログラミングを用いることで、思い込みによる障害の作り込みを減らすことが期待できます。
XPのYAGNIや、YAGNIを推進する効果のあるリファクタリングを用いることで、「まずは最低限の機能を実装」といった開発工数の最小化や開発機能の最小化が見込めるのではないでしょうか。ただし、製品やプロジェクトの基幹／基盤機能は、今必要な機能の実装だけで良いかの判断には注意が必要です。
XPのソースコードの共同所有や、共同所有を推進するペアプログラミングが効果を発揮します。ただし、ソースコードの責任者が不明確なため、無責任な修正が発生したり、開発スキルの弱いメンバーによるペアプログラミングはさらなる悲劇を招くかもしれません
実はXPやスクラムには、開発遅延を防ぐための直接的なプラクティスは存在しません。反復（イテレーション）やスプリントにより細かな進捗の見える化はできますが、製品やプロジェクト全体を通しての進捗を吟味することが、とても難しいのです。
プラクティスの選択的導入によって、悩み解決のイメージは湧いてきたことでしょう。もちろん、プラクティスを導入すれば万事うまくいくというわけではありません。プラクティスを導入し、その効果をしっかりと測定し、より現場にあった運用に変えていく。これが重要です。
ちなみに、アクセラテクノロジでは上記すべてのお困りケースに直面し、それぞれのプラクティスを導入していきました。導入当初は「本当にこれで順次解決に向かうの!?」と疑う毎日でしたが、3ヶ月を過ぎたあたりから、少しずつ効果が見えてくると共に、開発メンバーの意識にも変化が現われ始めました。導入から1年以上経ったいまでは、各プラクティスを少しずつアレンジすることで、より現場に根付いてきています。
ベテラン開発者は、問題の整理や課題解決など自分1人でできるし、何よりペアでソースコードを書くなど効率が悪くて仕方がないと考えるかもしれません。一方、新入社員をはじめとした開発初心者には、問題を整理／解決したり、品質の高いソースコードを書くことはなかなか難しいでしょう。通常、開発初心者にはさまざまな教育を行なったり、いきなりつらい実地訓練を行なうことで、これらのスキル向上を狙うことが多いのではないでしょうか。
アクセラテクノロジでは、毎年プログラミング経験のない新入社員を採用していますが、スクラム会議やペアプログラミング、ソースコードの共同所有を通して、驚くほど成長しています。特に1人で悩み問題を抱え込む前に、多くのチームメンバーとコミュニケーションを図ることが良いようです。
アジャイル開発は、開発初心者ほど効き目があるのかもしれません。
