ITmedia エンタープライズ：コミュニケーションに方法論を持ち込もう
たとえば、あるエンジニアは、「正しくないシステムを正しく作ってしまった」という経験が何度もあるという。つまり、バグはない、データの連携もスムーズ、パフォーマンスも正常だ、でも、本来のビジネスプロセスには馴染まず、結果としてまったく利用されなかった。というのも、彼が顧客企業との対話で固めたはずの要件定義がまるで的外れだったのである。「そのときの悲しさは言葉では表現できない」と彼は苦笑いする。
SEだけじゃなくて、機械設計でも同じです。 図面ですら読み取って理解することが出来ない顧客が多いですが、ソフトウェアの場合はなおさらなんでしょうね。
自分が欲しいものが何かを、キッチリ把握している顧客なんていないからね。 絵空事を簡単に言ってくれる顧客も多いし。
経験があれば、ある程度は”クサイ”部分をちゃんと確認するんだけど、設備設計だとワンオフというのも多い。 「顧客の言うとおり設計しました」なんて言う若手は、必ず痛い目に遭うことになる。 つまづいてみないと分からないこともあるので、そのままやらせてみるんだけどね。
しかし、どんなにがんばって聞き出したところで、「これで完璧に聞き切った、聞き漏らしたことはもう何もない」というようなことにはならない。もし仮に完璧に聞き切ったとしても、それは1人のユーザーの理解や要望で生まれた属人的なものであったりする。
所詮、聞くという単純なコミュニケーションだけで正しく開発すべきシステムの全貌を把握するには無理がある、システム要求というのは、もっと科学的でロジカルなプロセスで導き出されるべきなのだ。（中略）
Openthologyは「情報システムに対する要求は、あらかじめ存在しているものではなく、ビジネス価値にもとづいて『開発』されるべきものである」というスタンスに立って開発された。
「要求を開発する」という考え方は面白いね。 でも、入り口でモタモタしている時間があったら、図面描いちゃえと思うのが悪いクセ。 ちょっと勉強してみようかなぁ？