企業のシステム開発でアジャイル開発を採用するケースが目立つようになった。背景にあるのはIT部門の危機感だ。従来のウォーターフォール型開発では顧客や業務部門の要求に対応できない。開発手法を刷新する必要があるというわけだ。
しかし、システム開発の現場に浸透するにつれ、アジャイル開発に対する否定的な意見を聞く機会も増えた。「アジャイル開発を実践したのに成果を上げられなかった」「やはり、エンタープライズ分野の開発手法としては相応しくないのではないか」といったものだ。
一度や二度の失敗をもって、アジャイル開発の価値を判断するのは拙速だろう。なにしろ、ウォーターフォール開発だって、全体の3割しか成功していないという調査があるくらいだ。何しろ新しいことにチャレンジするのである。もう少し鷹揚に構えたいところだ。
一方で、筆者は現在のアジャイル開発を取り巻く状況に少なからず危惧も覚えている。というのも、アジャイル開発の手法が乱立した結果、アジャイルプラクティス（＝手法、取り組み）が一人歩きし始めているように感じるからだ。
開発手法の特徴や違いにばかり焦点が当てられ、そもそもアジャイル開発が何を目的としたものかが見落とされている。結果として、アジャイルプラクティスを実践することがアジャイル開発であるという考えを持つ開発者も珍しくない。
アジャイルプラクティスには魅力的なものが多いのも理由の1つだろう。例えば、プランニングポーカーやフィボナッチ数列を使った見積りなど、名前を聞いただけでも先進的なイメージを与える。しかも、実際にやってみると何とも楽しいのである。手段が魅力的であるがゆえに、結果として目的や価値を冷静に評価することを怠ってしまうケースは多い。
しかし、あくまでプラクティスはアジャイル開発を実践するための手段でしかない。アジャイルプラクティスはそれぞれコンテキストを持っている。目的があり、適用すべき場面がある。いくらプラクティスを忠実に再現しても、目的やシチュエーションが異なると十分な効果を得られない。裏目に出ることもある。こうした情報はガイドを読んでも書かれていないことが多く、初心者が失敗するのは避けられない状況にあるのだ。
実は、ほとんどのアジャイルプラクティスはウォーターフォールにも適用できる。実際に、プラクティスだけを取り入れた“アジャイル風ウォーターフォール”も散見される。
もちろん、アジャイル開発とでは得られる効果が自ずと異なる。冒頭に述べたような問題意識からアジャイル開発を望むのであれば、アジャイル風に陥穽に陥ることは避けたい。
アジャイル開発を成功させるために必要なのは、開発手法についての正しい理解である。具体的にはアジャイル開発の目的を把握した上で、それを支える重要な概念である「自己組織化」「タイムボックス」「要件定義の扱い」「振り返り（レトロスペクション）」を学ぶ。これらを理解すれば、プロジェクトを成功させるための必要最小限の知識を得たことになる。今回は、アジャイル開発の本質について改めておさらいしよう。
アジャイル開発の本質とは
アジャイル開発の本質は、「超短期リリースを繰り返す」ことである。超短期リリースとは文字通り、数週間程度で動作するソフトウェアをリリースすることを指す。目的は、ビジネス変化に素早く対応することである。具体的には以下のような効果を狙っている。
- 顧客に見せてフィードバックを得る
- 仕様変更を取り入れる
- 開発した機能を早く利用する
これらは全く特別なことではない。むしろ、ソフトウェアに限らず受注生産全般における課題である。モノが完成してしまってから、顧客の希望に沿っていないと発覚するような事態は断じて避けたい。
