アジャイルの未来（『はじめよう Ruby on Rails』を読んで）

『はじめよう Ruby on Rails』という本を読む。Webアプリケーションのフレームワークは実際に使ったことがない。慣れるまでがたいへんそう。しかし、CGIなどでWebアプリを書いて無駄や面倒を実感しているひとほどすぐに慣れそうだ。
この本はRailsを用いたアジャイル開発（エクストリームプログラミング）を追体験するかたちで書かれています。プロジェクトの進め方やメンバー同士のやりとりを見れておもしろい。きっちりした解説書を補う役割、あるいはその入り口に最適な本だと思います。

はじめよう Ruby on Rails

ソースコード、正誤表など→Rails' Wiki - hajimeyo_rails

アジャイル開発の目的はソフトウェアづくりか

二人のメンバーがスケジュール管理のアプリケーションを開発します。ペアプログラミング、テスト駆動開発、ストーリーカード（機能のまとめ）、タスクカード（実装のまとめ）などに基づいて。
Railsを使ってデータベースの構造を定義すればスケジュールの表示や追加などができる簡単なWebアプリができます。これを拡張していくかたちでデザインを改良し機能を追加していきます。これだとつくっているひとが進歩が実感できて楽しいですね。しかし要求分析がある程度できていることが前提なのかな、と気になりました。
スケジュール管理アプリというのは典型的なソフトウェアで、ないよりあったほうが便利なのは想像できます。じゃあ、単純じゃないアプリをつくるためにアジャイル開発は役に立つのか。べつに複雑なアプリをつくるとは限らない。問題があるのはわかるけれど、対策の方針が立たないとき。問題を解決するために、どんなシステムが有効かわからないとき。つまり、アジャイル開発は問題の分析にも有効なのか、それとも分析の成功を前提にしているのか。

アジャイル開発はビジネス価値を生み出すか

だから、
問題の分析に注視するのがシステム開発のあり方である。アジャイル開発は問題解決のめどが立っているとき、あるいは典型的なアプリケーションをつくるときに有効である。アジャイル開発はときにシステム開発の一部の工程として、またはある種のアプリケーション開発で活躍する手法である。
などと考えてみた。
そういうぼんやりとした違和感がまさにアジャイル開発と反復開発の落とし穴 − ＠IT自分戦略研究所で議論されていました。反復開発とアジャイル開発を対比するかたちで、両方の欠点を克服するビジョンを示しています。ビジネスモデルを安易にシステム開発の工程に取り入れることの問題に、はっとさせられました。また、アジャイル開発における分析・設計の重要性を主張している点には強く納得できます。
ウォーターフォール開発の裏プロセス（「現状のソフトウェア開発は間違っていないか？」（プロセス編） − ＠IT自分戦略研究所）とか、ビジネスアジャイル（ソフトウェア開発の革命 − ＠IT自分戦略研究所）など、すごく興味深い連載です。
ウォータフォールだから、とか、アジャイルだから、とかじゃなくて、業務とシステムの両方について、開発プロセスのあるべき姿を考え抜くことが重要なのだと気づきました。