常々、ソフトウェアは二種類あると考えています。
一つめは、正しい要件（仕様）があって、ベストな設計、実装が存在するソフトウェア。ミッションクリティカルなシステム、例えば証券取引所の株式売買のシステムや銀行の勘定系、通信ネットワークのバックボーンで動く交換機のソフトウェアなど。ロケットに積まれるようなものや、身近なところでは自動車のエンジンを制御するソフトウェアなども同じ類でしょう。
これらのソフトウェアは、（障害によって）止まることが許されないという特徴の他に共通していえることは、変化が激しくないということです。あるいは予想できない変化はないといえるかも知れません。例えば株式売買のシステムは機能面での変化はまず考えられず、処理量の変化もおおよそは予想できるでしょう。
つまり、システムが止まらないよう、考えうるすべての事象と変化を考慮した設計をすることが求められます。当然ながら事前の検証や評価などを行うことも必要ですが、机上で完全といえる設計をし、それに基づき実装しテストするソフトウェア開発、そう、ウォーターフォールモデルそのものです。
対してもう一方は、正しいといえる要件がなく、その時点でよりベターと思われる実装がなされるソフトウェアです。なんとなくこんな事をしたい、あるいはこんな事に困っているから解決したいという曖昧な要望があり、おそらくそれを満たすにはこういう機能や画面があればいいんじゃないかと想定してみます。すなわち仕様としてまとめます。
残念ながら、これに基づいて実装されたソフトウェアは、仕様は満たしても要望を満たせないことが多いと言わざるを得ません。例えば、ある人の要望は満たしていても別の人が想い描いていたものとは違ったり、当初はそれでよかったものがソフトウェアを開発している長い時間の間に状況が変わってしまったり。使いやすいだろうと思った（想定した）機能が実際に動かしてみると煩雑であったり、足りなかったり。そもそも解決したいと思っていた問題が別のところにあることに気づく、なんてこともあるでしょう。
マイクロソフトのソフトウェアアーキテクトである萩原さんは、直接利用する人が多いシステム程、変化が激しいと仰っています。そもそも画面デザインなどのユーザインタフェースは人の好みによるところが多く、ましてや昨今のコンシューマ向けのWebアプリケーションはおじいちゃんや子供から我々のような一日中コンピュータに向かっているような人までITリテラシーが大きく異なる利用者がターゲットになりえます。加えて、利用環境も一般的なPCだけでなく、携帯電話やWiiなどのビデオゲーム機までヒューマンインタフェースすら全く異なるデバイスへと広がっています。
このような多様化と変化をあらかじめ予想する事は不可能ですし、実際に使ってみないとわからないことが多い訳ですから、しっかりとした仕様と設計をまとめて開発するウォーターフォールモデルでは対応できません。数日から一ヶ月程度のショートイテレーションで動くソフトウェアを作り、フィードバックを得つつ、変化に対応していくアジャイルプロセスが有効な開発モデルであると考えています。
アジャイルプロセスは、一部で不要なドキュメントを作らないで短期間に安くソフトウェアを開発できる、あるいはプログラマに取って幸せな開発プロセスだといった印象を与えているようです。決して誤ってはいないのですが、それが本質ではなく、変化を重視し、より価値のあるソフトウェアを開発することを目的にしています。
それも上に上げたようなソフトウェアにおいてのみその価値を生み出すことができるのです。つまり万能ではありません。そのソフトウェア（システム）の価値とは何かを見極め、開発プロセスをも含めた広義のアーキテクチャを構築することがますます重要になっています。
hogehoge
hugahuga
11月 132008