“使えないシステム”という表現は少々過激ですが”導入で躓くシステム”というのは少なからずあります。

仕様書に記載されている機能、性能を満たしているにも関わらず、導入段階になって躓いてしまうシステム（＝使えないシステム）が出来てしまうのはどうしてなのでしょうか？

“仕様を満たしても業務に使えない”ということは”業務に使えない仕様”だったと考えるのが自然でしょう。
業務を遂行するために必要な仕様が仕様書に反映されていればこのような矛盾は起こり得ないのですから。

“使える仕様” を練り上げるにあたって以下の課題があります。

1. システム開発事業者は業務を遂行するためにシステムがどうあるべきか？を知らない。
2. クライアントはシステム仕様書がどう書かれるべきか？をご存じない。

双方共にお互いの領域についての知見が足りないため、お互いの足りない部分を補い合う姿勢が不可欠です。

同じ日本語を使って打ち合わせを行っても話し手の意図と聞き手の解釈に違いが生じている可能性があります。

例）綺麗に掃除して欲しい。

• 話し手の意図：掃除機を使って手早く、ざっと掃除してくれれば良い。目立つゴミや埃が無ければ良い。重要なのはスピード。
• 聞き手の解釈：塵ひとつあってはならない。掃除機は勿論、雑巾がけも必要、年末の大掃除のように完璧に仕上げることこそ重要。

双方共積み重ねてきた経験が異なる以上、同じ言葉から受け取る情報は違ったものとなってしまう可能性があります。

これは、話し手の言葉が足りないのでしょうか？それとも聞き手の理解力が足りないのでしょうか？

これまでのシステム開発経験から、このような思い込み、勘違い、行き違いを減少させるのに効果があったのは以下の方法です。

1. 聞き手は話し手から聞いて”解釈した内容”を図、表、文章を用いて書類化し、話し手に書類（解釈した内容）を確認して貰う。

   大事なことは聞いた言葉をそのまま書き写さないこと、聞いた言葉をそのまま書き写すと解釈の違いを発見することが出来ません。

   ★自分が「話した」内容よりも相手に「伝わった」内容の方が大事です。

2. 同じ事柄について条件を変えて何度も問い直す。

   一つの事柄を一方向からの説明だけでなく、違う角度（異なる条件）で何度も問い直すことで理解が深まります。

   ★同じことを何度も尋ねるのは理解を深めようとしているためです。

上記２つはシステム開発事業者側のアプローチです。

普段、クライアントには次のように伝えています。
「書類あるいは仕様書を確認する際に”きっとこうだろう”と好意的に解釈するのではなく、”もしかすると勘違いしているかもしれない”という姿勢でお願いします。

思い込みや勘違いを減らすという意識を持ち続けることで使えないシステムになってしまう可能性を減らすことが出来ます。