IT導入（システム開発）に於いて、機能そのものに拘り過ぎてはいけない

現代社会においてIT導入は必須事項となりましたが、ITの専門家がいないユーザー企業にとって、開発事業者やツールの選定は慎重に行いたいものです。しかし、失敗に終わるケースも多々あるようで、知り合いのSlerなどからも同じような事案を何度も耳にする次第です。そこで我々がこれまで見てきた中で、危険なパターンをいくつか紹介していこうと思います。

今回のパターンは「担当者がそこそこITの知識を持っているが故に、機能の実装に凝りだしてしまう」場合です。

上長から〇〇を導入するから△△さん仕切ってくれ、と言われて張り切って要求定義を進めていくのは良いのですが・・・一番の落とし穴は、“目的を実現するためのシステム（ツール）導入”とならないパターンです。どこに分岐点があるのでしょうか？

要求定義をする場合、まずは目的を明確にしておくことです。ほとんどの場合、これまでの業務フローをITに置き換えるわけですが、その業務自体をきちんと説明できなければいけません。そして、人が行う業務において課題となるようなフローを、ITで効率化させることが目的のはずです。

ところが、多少の知識や興味本位からか、打合わせを重ねるに連れて機能の充実に話を持って行きがち。しかも、そのほとんどが全体から見れば小さな拘りだったり、導入当初から必要無いと思われるものだったりします。

更に危険なことに、話を聞かされるSEは何とかそれを実現しようと頑張るのです。SEという人種は要求に対して実現方法を探そうとする性質なので、それが無駄かどうかなど正しい判別も出来ず、当然お客様を説得しようとするわけでもないのです。

そうして設計されたシステムが（しかも予算オーバーする場合もある）、果たして効果的に業務で使われるのか？文句を言われながらでも使い続けられれば良い方で、半年も使われずに放置されていくパターンも多々あります。酷い事例になると、またゼロから作り直し、買い直しというパターンも。

これは作ることが目的、導入することが目的になってしまっているからです。そもそも要求定義が間違ってしまうと、開発事業者や販売事業者は正しい目的を伝えられずに提案をすることになります。正しく要求定義したにも拘わらず、違ったものが導入されたというパターンは、私が知る限りではほとんどありません。日本では“お客様は神様 ” という意識が強いためか、要求元は自らの非を認めず、発注先にばかり責任を押し付けがちです。正しく要求定義するにはどうすれば良いのか？まずはスタートから見直してみましょう。