http://www.atmarkit.co.jp/farc/rensai2/proto01/proto01a.html
上流工程っていうのは
- 要件定義
- 基本設計
なんかを指すのが普通。まあ一般的には。
その上流工程の前段階には、
- なんのためにシステムを入れるか
ということに関する議論は必須。
これをちゃんと議論しないでシステムを作っちゃう、
というのはありがちな悲劇の元。
要はユーザの気持ちを理解しなきゃ駄目よ、と。
その議論のためには、システムを導入したいユーザの商売、
つまり
- どういう業務を
- 誰が
- どんなふうにやっていて、
- お金をどう使って
- お金をどう回収してるか
というようなことを、予備知識として、
きちんと理解しとく必要がある。
業務知識がある SE が欲しい、と言うのは、
この辺の知識がある、ということよね。
ただ業務知識というものは、実際に業務に携わらないと、
ちゃんとは身につかないもので、
システムだけ作ってて身につくものじゃないのよ。
なのでシステムを作る方で業務知識がある人を
揃えられるか、というとなかなか難しい。
でもユーザ側は、システムを作る側に、
業務知識は当然ある、ということを要求しがち。
お金だけ出せばシステムができてハッピーになるぞ、
と思ってるわけだ。
その辺もありがちな悲劇の元。
アジャイル的なアプローチが絶対っていうわけじゃないとは思うけど、
少なくともアジャイル的なアプローチでは、
- 顧客がやりたいことを、顧客と開発者で明確化し共有できる
というメリットはあるのは確か。
アジャイルの考え方や理念は、従来型の開発にも応用ができるので、
上流工程の人こそアジャイルの勉強をして欲しいなあ、と思うね。