「アジャイル開発」に先行して「アジャイル分析設計」を

　ソフトウエア開発の世界でアジャイル手法が注目されている。「アジャイル」というのは「俊敏な、素早い」という意味の英単語(agile)で、「アジャイル開発」とは、

ユーザーからの要望にもとづいて素早く『動くソフトウエア』を組み立て、それを用いて要望をより具体化しつつソフトウエアに反映させる

といった開発スタイルを意味する。

　筆者自身もアジャイル開発には共感を覚える。ユーザーが事前に表明できるシステム要件は非常に限られたもので、それに頼って仕様を固めることには無理がある。どうしても、ユーザー要件を漸進的に具体化するための「動くソフトウエア」のような仕掛けが要る。

　とはいうものの、その適用に関しては疑問もある。アジャイル開発では、小さなモジュール毎の「設計・構築・テスト・評価」の繰り返し（イテレーション）で作業が進むが、そもそもその「小さなモジュール」を切り出す根拠がよくわからない。この問題はシステムの規模が大きいほど顕著で、基本構造が決まっていないうちからモジュールを切り出せと言われても困ってしまう。だから、アジャイル開発は基本的に規模が小さめの案件でしか利用できないんじゃないかと思う。

　しかし、アジャイル開発にはＸＰをはじめとした有用な知見が多く盛り込まれていて、相手が大型システムだからといって活用しないのはもったいない。なんとかしたいところだ。

　というわけで、「アジャイル開発」に先行すべき「アジャイル分析設計」の可能性を吟味したい。じっさい、分析設計作業は「ユーザーとの打合せで書いたメモを持ち帰って机上で図面をまとめる」という牧歌的なノリで進められることが多い。そこに「アジャイルさ」は微塵もない。アジャイルさを適用できる広大なフロンティアとして分析設計工程にもっと注目していい。

　では、「アジャイル分析設計」において「動くソフトウエア」に替わるものは何だろう。とにかく、システムのあり方をわかりやすく示し、かつ、ユーザーの要望をより具体化してくれるネタであれば何でもよい。筆者にはそれは「ユーザーが理解できるモデル」以外には思い当たらない。そうであれば「アジャイル分析設計」は、

ユーザーからの要望にもとづいて素早く『ユーザーが理解できるモデル』を描き広げ、それを用いて要望をより具体化しつつモデルに反映させる

といったプロセスになる。

　これが可能なのであれば、基幹システムのような大型案件でも「アジャイル開発」を実践できる。なぜなら、「アジャイル分析設計」によって、「アジャイル開発」におけるイテレーションの単位となる「小さなモジュール」を的確に切り出せるからだ。二段構えアジャイル、アジャイル波状攻撃である。

　しかし、そもそも「ユーザーが理解できるモデルを用いたアジャイル分析設計」なんて本当に可能なのだろうか。可能だ。筆者が言う「業務システムの３要素」――要するに、データベース構造とユーザインタフェースと業務マニュアル――を「ユーザーが理解できる絵（モデル）」としてユーザーの目に前に描き出せばいい。

　それらを同時に描き広げて、彼らからの「イチャモン」に応えてその場で改善してフィードバックする（ペアモデリングと言っていい）。それを繰り返す過程で、システム要件はユーザーに了解可能な形で素早くまとまってゆく。それは「アジャイル開発」と同じくらいにアジリティと知的刺激に満ちた世界だ。一度これを知れば、たとえアカデミックな緻密さがあっても非効率な従来手法には戻れなくなってしまうだろう。