ユーザーズ・マニュアル指向開発

世の中アジャイルだXPだと言っているが、個人的にはどうにも納得がいかない。というより、いままでの開発プロジェクト経験から言ってアジャイルの方法論がどう役に立つのか理解できない。むしろ、企業というシステムに合ってない気がする。特に大企業のシステムや巨大プロジェクトの時はそうだ。いくらお金がかかるかわからないし、どんなシステムになるかわからないが、いいものを作ります……などという企画が通るはずはない。まず、目的。そして費用対効果である。そこには変化を擁護する余地などない。

いや、純粋に開発という観点で言えばアジャイルの考え方やXPの考え方はひたすら正しい。問題なのは、開発というのは発注した企業から見たら業務改善プロジェクトのほんの一部に過ぎないということだ。開発なんて重要ではないのだ。重要ではない以上、お客にXPやりましょうといっても受け入れられるわけはない。もしかすると受け入れてくれるお客もいるかもしれないが、たぶんそのお客は業務知識に乏しい情報システムのオタクかプロジェクトに興味がないかだ（そしてプロジェクトは失敗する）。

実際に変化は起こるのだから、変化を起こることを前提にしよう。だから、変化を擁護しよう。いや、ごもっともだ……少なくとも前半は。変化はおこる。しかし、変化が起こることを前提にプロジェクトを進めてはいけない。なぜなら、お客は仕様を決めてくれないし、SEも仕様が決まらないことを放置するからだ。

実際のプロジェクトを見ると、仕様が決まってはじめて問題が見えてくる。だから、重要なのは変化を前倒しすることであって、後ろ倒しにしてはいけない。しかし、実際にはそれでも変化はおこるではないか。そういう反論もあるだろう。しかし、そのような変化に対応する手法は昔からある。リスク管理である。

要件定義と設計／開発は違う。設計／開発はXPで構わない。実際、プログラミングは書いてみて始めて気づくことが多い。しかし、その概念を要件定義まで拡張するのは間違いだ。

と、ここまで書いて気づいたがタイトルまで行き着かない。困った。

閑話休題。最近、業務という視点から開発プロセスの再構成ができないかと考えている。ちょっと、はぶ先生の影響を受けすぎているのかもしれないけど。そのアイデアのひとつが「ユーザーズ・マニュアル指向開発」。まだ、タイトルだけしかないけど。

DFDだ、ERDだと言ったって技術文書は難しい。お客が理解できないのは仕方ないとしても、SEやプログラマの8割もクズなのだから（←失礼）彼らが正しく理解できるということを前提にしてはいけない。しかし、ユーザーズ・マニュアルならどうだろう。マニュアルというのは利用者なら誰でも理解できることを前提に作られるものだ（まぁ、最低限日本語が読めるという前提は置かなければならないが）。お客もSEもプログラマも運用もマニュアルならば理解することができる（はずだ）。

最初から最後まで「ユーザーズ・マニュアル」を軸に進むそんな開発プロセスを現在夢想中である。

いやはや、まとまりがないな(w