要求開発、BABOK、　失敗学・・・・ Dora_PaPa_san's

要求開発、BABOK、　失敗学・・・・

<< 作成日時： 2009/08/27 20:53 >>

　先週末から、　ビジネスアナリシスの研究会に参加させていただいている。　SIベンダーのスタッフだったり、個人でコンサルタントをされていたり、　ITベンダーで相当の経験をされていたり、皆さん、論客であり、本当に何でもよくご存知の方ばかりだ。　ビジネスアナリシスという、古くて新しい視点が、BABOKで明確に出ているので、それに対する期待もあるのだろう。自分の無知や少ない経験が恥ずかしいばかりである。

　Requirement Definition を「要求開発」と読んだり、「要件定義」と読んだりしている。　多くの方は、ユーザーの「要求」を、システム側が定義して「要件」とする読み方が多い。　そういう気持ちはよく分かるし、そういうことにしましょうというのなら、それはそれでよいのだが、もともと「要件」にも、言葉自体に、そんな限定された意味づけはなかったはずだ。　ただ、ベンダー側が使う「要件定義」が、ユーザーのビジネス要求まで遡りきっていないもどかしさから、「要求」という言葉を使いたくなるのだろう。　しかし、要件と要求を区別したからといって、それでビジネス要求まで遡れる訳ではない。　やはり会社の異なるベンダーには、なかなか立ち入れない領域があるということも大きい。　ユーザーがやらなければならない。

　昨日、８/２６は、ISACAの月例研究会で、失敗学会という存在を知った。　回転ドア事件、福知山線事件、ミートホープ事件などを題材にして、事故・事件調査の在り方や、失敗学の意義など興味深かい。　各事件の見解については、その場だけの参考資料で、引用・転載することもできないが、根本原因を探り、対策を練るということは、一様ではないことを改めて理解した。　そういわれればそうだが、警察は、根本原因を探ることが目的ではないし、ましてや根本対策を立てることなど考えてはいないのは、確かにそうだ。　犯罪を立証して検挙することが目的だからだ。　事故調査委員会の対策と失敗学会の対策とがかなり異なるというのも興味深い。　ことほど左様に、目に見える機械ですら、問題の原因を究明し解決案をたてるのがむずかしいのなら、目に見えないシステムの問題解決など、ことごとく、おかしなものなのではないだろうか。　