要件定義とはITの上流工程に位置するもので、ユーザの要件を汲み取りこれをシステム仕様に落とし込む工程です。
業界の人ならば誰でも知っており、この工程がシステムの品質を大きく左右する重要なものです。
要件定義ではユーザのヒアリングや作業状況を観察するだけでなく、代替案の提示、解決策のディスカッションなど、様々な手段を用いて顧客要件をまとめてゆきます。
が、IT企業から離れてみて分かったことは、単なるインタビューを要件定義と勘違いしている人が多いといこと。特に、ITに疎いコンサルさん。
「ITベンダーと協力し、互いの強みを活かし、補完しあいながら．．．」という論理も間違ってはいませんが、何が不足している部分で、どこを補完しあうのかはっきりしないといけません。
要件定義で難しいのは技術（IT）ではなく、業務内容やビジネスモデル、経営戦略等のあるべき姿と、それを実現する方式をマッチングさせる点にあります。
単に「要望に一番近い技術」を探すのではなく、実現性や費用対コストの観点からビジネスモデルを見直したり、当初の要望とは異なった技術に解を求めることもあります。
つまり、技術と事業のバランスを取りながら最適解を探ることがキモになるわけです。
しかし、「インタビューが得意な人」と、「モノ（システム）づくりが得意な人」の組み合わせでは、キモの部分を担当する人がいないというわけです。
もし、複数のプレーヤーでチームを構成せざるを得ないなら、「業務もITの飛びぬけて詳しくないけど、別業態・別業務等で両者を融合させた経験のある人」が必要不可欠です。
これに、、「インタビューが得意な人」と、「モノ（システム）づくりが得意な人」を組み合わせられるなら、それぞれで補完するということは可能だと思います。
ただ、現実的にはそこまでの体制になっていないのが現実のようです。
「ユーザの要求に問題がある」という話も聞きますが、こういう現場を見ると、「そもそも要件定義をしていない」って感じることが多いですね。
コメント