アジャイル開発手法の重要ポイント

ITでのアジャイル開発手法についてなんどか書いてきましたが、最近複数のためになる記事があったので紹介します。

Think IT：今こそ再考するアジャイル開発
第1回 アジャイル開発を問い直す
第2回 アジャイル開発のメリット 〜 ユーザのメリット
第3回 アジャイル開発のメリット 〜 ユーザとベンダー共通のメリット

ITPro Enterprise：ITエンジニアのスキル向上ゼミナール
【中級】反復開発 現場のノウハウ 第1回
【中級】反復開発 現場のノウハウ 第2回
【中級】反復開発 現場のノウハウ 最終回

アジャイル開発手法の本質は、反復（イテレーション）でも、テスト･ファーストでも、ペア･プログラミングでもなく、"要求と仕様の変化にソフトウェア･エンジニアリングとして対応する"ということだと思っています。「変化を抱擁する（受け入れる）」というアジャイル開発手法の標語こそ、最重要なポイントだと思います。反復も、テスト･ファーストも、ペア･プログラミングも、それを実現するためのベスト･プラクティスの1つに過ぎません（と私は思っています）。

要求と仕様がソフトウェア開発プロセスに影響を与えるほど変化するようになった背景は、一般的に言われるようにビジネス世界の変化が激しくなったということもありますが、ITが、定型的な入力業務を中心とした帳簿管理の自動化といういわば裏方の役割のみならず、情報をいかにビジネスにいかしていくかという知的作業の領域へと重点が移ってきているということも大きいのではないでしょうか？知的作業においては、新たに創造されたアイディアを迅速に実現することがビジネス上のメリットとなるため、そのツールとなるべきITにおいても迅速な対応が求められます。

そうなると、今まで作ってきたものとは似て非なるものを作ることになりますので、開発手法も同じというわけにはいかなくなってくるでしょう。

ユーザも、ビジネス上のアイディアは出しますが、それがどういうITとしての要求となるのか、仕様となるのかについてはわかっていないことも出てきます。

開発者は、そういう状況の中、ソフトウェア（アプリケーション）を開発していかないといけないのです。

その場合、まず考えられるのは、仕様が決まるまで開発しないというフェージングでは遅すぎるということです。

でも、仕様が決まらないのにどうやって開発するのか。
その難題に答えるのが、反復開発です。

仕様が決まらないのであれば、決まっている範囲の内容でとにかく作ってしまうという発想です。そして、早い段階でできあがったものをユーザに確認してもらって、ユーザのもつイメージと違うところを次の反復で直していくというやり方になります。
実際、できあがるのが海のものとも山のものともわからない段階ですべて仕様を決めろというのがかなり無理のある話です。どういうITシステムになるのかユーザと開発者に明確なイメージがあるような場合にだけこういうことは可能です。

その際重要なのは、ユーザに参加（常駐）してもらって、きちんとレビューを受けれる体制にすることです。そのためには、作る対象をユーザの目線で定義して合意し（ユースケースやストーリーが重要となります）、またその1反復の間で開発するものを明確にするために要求リストを作ってそのうちの優先順位の高いどれを開発するのかをユーザと合意します。その1反復の間は、それ以外の作業や変更要求は一切受け付けません。新たに出てきた要求などは、次の反復で受け入れていくという形になります。

こうすることで、ユーザは早い段階で実際に動くものを見れる上、そのできあがったもののフィードバックとして新しい要求を出していくことができます。開発者は、一時点では確定された仕様の実現に集中することができます。

アジャイル開発手法の反復で重要なのは、1つの反復で開発されるものはけっして"プロトタイプ"ではなくて、きちんとした動くものだということです。
したがって、イメージとしては、1回目の反復で一気に動くものを開発して、後の反復ではユーザによる検収を受けながら品質改良していくということになります。ある意味、運用保守フェーズの品質改良というイメージでしょうか。

実際にプログラムを開発したことのある人なら感覚としてもっていると思いますが、最初に作ろうと考えた機能はけっこう早い段階でできてしまいます。ただし、そこからユーザごとにカスタマイズした動きになるようにしたり、エラーハンドリングしたりと品質を高めていくのに非常に労力と時間がかかります。
アジャイル開発手法では、ある意味、中心機能は最初に一気に作ってしまって、その後は実際のユーザのフィードバックを受けながら品質を高めていこう、という手法とも言えるかもしれません。

また、仕様変更による機能の追加をいかに実現していくかを考えるとき、反復と並んで、その反復期間中にいかに効率的かつ品質高く開発／テストをするかということが非常に重要です。そこで、アジャイル開発手法では、テスト･ファーストと呼ばれる手法やテストツールを重視します。

アジャイル開発手法では、各反復で完成品の開発を目指しますので、原則開発したものに対してその日のうちにテストすることが求められます。それを実現するために、各種テストツールを使用したり、開発するより前に自動テスト用のプログラムを開発したりします。
しかも、テストは統合テストまで求められることがあります。その日に加えた機能については、元のビルドに組み込んで全体としてきちんと動くようにすることになります。
これはそうとうきつい要求のように思えますが、逆に、統合テストまで済ませられる範囲でしか1日のうちに開発しないということでしょう。

また、その日のうちに統合テストまで済ませることで、インタフェースが変わって他のモジュールに影響が出るような場合でも、その日のうちに改修してしまい後々に問題となることはありません。
ウォーターフォール型開発手法では、インタフェース定義は手戻りを防ぐために非常に重要ですが、開発の最初の段階で決まったインタフェースのまま変更できないというはたしかに非常に窮屈な作り方です。
毎日ビルドしていくことで、インタフェースの仕様変更にも耐えていくという開発手法となります（もちろん、大きなくくりでのシステム間インタフェースはこの限りではないですが）。

最後に、短いタイムスパンで迅速に開発していくために、チーム内でのコミュニケーションが非常に重要です。

アジャイル開発手法では、スタンドアップ･ミーティング等ほぼ毎日チーム内で短時間のミーティングをすることを求めることが多いです。その場で、その日のうちに取り組むべきタスクや課題をみんなで確認していきます。
また、ドキュメントによる情報の引継ぎを信用せず、直接コミュニケーションによる情報共有を重視します。とくに、"ゴシップの共有"と言われるように、プロジェクト内外の情報をなんでもチーム内で共有することが重要だとされます。
コミュニケーション・ギャップが、プロジェクトの失敗の大きな要因となることは多々あるので、こういう指摘をノウハウとするだけでなく開発手法の中に含めてしまうのはよいことですね。

というわけで、アジャイル手法は、私なりにまとめると、

* 要求と仕様の変化にソフトウェア・エンジニアリングとして対応する

という目標を実現するために、

1. 反復開発する
2. ユーザに参加してもらい反復内でのタスクを明確にする
3. 反復内での品質を高めるためテストを重視する
4. 開発効率向上のためチーム内コミュニケーションを重視する

ということを心がけることになります。