第3回 第2部　アジャイル開発とは

ページ  1／2

第二部：アジャイル開発とは

アジャイル型開発技法

　アジャイルとは「俊敏な」という意味で、ウォーターフォール型開発手法の問題点を解消する視点に立って提唱されている開発手法の一つです。アジャイル型開発手法にもいろいろなバリエーションがありますが例えば次のような進め方で開発をします。

1. ユーザーと開発者（設計者＋実装者）が少数精鋭の共同開発チームを作ります。（構築するシステムの規模によっては同時に複数のチームを立ち上げることもあります。）
2. 共同開発チームは情報システム構築範囲全体をいくつもの短い範囲、おおむね２週間程度でできると思われる範囲、に区分します。そしてどの範囲から着手するかを決定します。
3. 共同開発チームは２週間という期間内に　その範囲のシステム要件の決定、実装、テスト、修正、リリースを行います。
4. リリースできた機能や残っている範囲を検討し、次に着手する区分を決めます。

上記の２から４のサイクルを繰り返してシステム構築を進め、全体の完成度を高めていきます。
このような手法では次のようなメリットが得られます。

• 業務プロセスが確定された部分からでも着手できる。
• ユーザーが実際に動く画面、機能を試すことができるので仕様の間違いや要求の漏れに早い段階で気づくことができる。
• 仕様の誤りがなぜ発生したかを分析することでユーザーと設計者、設計者間の情報の伝え方、確認のやり方が向上していく。
• 構築の途中で業務プロセスが変更になった場合、未着手の場合は変更された内容で構築できる。すでに構築済みの場合でも改訂の影響範囲は限定される。

イテレーション（反復）開発とも呼ばれるこのような開発プロセスで、ユーザーの要件をすばやく反映しながら情報システムを構築することを「アジャイル型開発技法」と呼びます。たくさんの詳細な仕様書を作るよりも実際に動く、ユーザーが使えるプログラムを作ることを重視し、変化にできるだけ柔軟に対応し、チームの協調と個人の活躍を動機付けることに特徴があります。

【ウォーターフォール開発とアジャイル開発の比較図】

アジャイル型開発手法の代表的な開発手法として、XP：エクストリームプログラミング手法をご紹介しましょう。
XP は 12のプラクティスを示しています。ここでのプラクティス(practice)とは、経験に基づいて効果が認められた開発のスタイルです。XPでは情報システム開発をこれらのプラクティスに基づいて進めます。

1. 計画ゲーム
   ユーザーとシステム開発者がビジネス優先度と技術的見積により優先順位を考え最初の、あるいは次の開発範囲を決めます。規模としては２～３週間程度で出来上がる範囲とします。
2. 短期リリース
   計画ゲームで決めた範囲を短期間で作り上げます。結果を確認しすばやく修正を加えたりビジネスの変化を細かく取り込んだりできます。計画ゲームと短期リリースを繰り返します。
3. 比喩（メタファ）
   システム全体や機能のイメージを何かに例え、ユーザーと開発者とがイメージを共有します。
4. シンプル設計
   システムのメンテナンスや機能追加が容易になるようにシステムの設計を出来る限りシンプルにします。
5. テスト駆動開発（テスティング）
   コーディング（プログラミング）以上にテストを重視する。プログラムを書く前にテストコードを先につくります。プログラムができたときにはもちろん、機能変更や追加をしたときにもすぐにテストを実行します。
6. 設計改善（リファクタリング）
   一度書いたプログラムコードを逐次見直し洗練させます。コードを改善したならば前述のテストを実行し動作を確認します。
7. ペアプログラミング
   ２人のプログラマが１台のマシンに向って共同でプログラミングを進めます。２人でコードを見ることでミスを減らします。新人の実践教育にもなります。
8. コード共有所有
   開発者は誰でも自分以外の人が記述したコードを含めて手を入れることができます。システムの全体像をみなが把握できるのでオリジナルコードを書いたプログラマ以外でも問題発生時に対応がしやすくなります。
9. 常時結合
   プログラムコードが完成するたびに、すでに出来上がっている他のコードと結合しテストします。各コードを常に結合できる状態に保つことで全体の構築を容易にします。
10. 最適ペース
    過剰なペースで仕事をしてはいけません。 過労は集中力、想像力を失わせ開発効率が落ちていきます。
11. 全員同席
    ユーザーを開発チームに加えます。その外の開発メンバーも含めて全員ができるだけ同席して開発を進めることで誤解を減らし時間を節約します。
12. コーディング標準
    プログラマによってコードの表記にばらつきがでないように、コーディング標準に従って全てのコードを書きます。

少し補足します。

• これらのプラクティスは厳密に規格として定義されているわけではなく逐次改訂されています。XPの説明文によっては２項目を追加して１４項目としたり、誰向けのプラクティスかでカテゴライズし１９項目としたりしている場合もあります。
• XPではこのプラクティスすべてを実際のシステム開発プロジェクトですべて実施することを求めてはいません。プロジェクトの特性に合わせて取捨選択します。
• XPでは出来上がった部分からリリース（システムとして稼動させる）するとしていますが、既存のシステムからの置き換えの場合は部分的なリリースを繰り返すことは「既存システムとの接続部分が必要になる」「データの移行作業が複雑になる」など必ずしも現実的ではありません。そこで途中のリリースはテスト環境への公開にとどめ、既存システムとの置き換え、全体リリースは最後に一括して行うことが現実的です。

さてこのXPに代表されるアジャイル型開発を実行するにはどのような工夫が望まれるでしょうか？　アジャイル型開発の大きな特徴である「短期間でユーザーが実行できる機能を作る」には従来の開発ツール、実装方式では問題がありました。ユーザーからヒアリングした内容を実装して実際の動作画面としてユーザーに見せるにはある程度の時間が必要だからです。
ユーザーに見せて誤りに気が付いたしても、修正してビューするにはまた時間が必要です。また画面の見栄えや動作は検証できても、いくつかの画面を結合して業務プロセスとして正しいかをチェックできるようにするにはさらに時間が必要でした。ユーザーと開発者が一体となって開発を進める、とするには従来の開発方法では実はまだ敷居が残っていたのです。

関連ソリューション

• 業務アプリケーション開発基盤　Orteus（オルテウス）

ページの先頭へ戻る