開発組織における社員の役割としては、一般的には開発工程の下流から少しずつ業務に慣れ、経験を積んでいくことで、徐々に上流工程を担当するようになり、製品の仕様や問題点などを理解するようになるのかと思います。
この間、開発に関するツールやスキルに習熟するにつれ、担当する自社の製品や関連製品、また他社の類似製品についても理解を深めるようになりますが、では果たして実際にユーザがその製品を使っている現場を見る機会はどれだけあるでしょうか？
私も以前は、メーカーでソフトウェア開発を経験していましたが、主には自社内での開発において先輩社員が作成した仕様を元に、指示通りに作り込みを行うだけで、何故そのような仕様にしているのか、その機能を実装することでユーザは何が満たされるのかなど、あまり深いことは考えずに開発を行っていたように思います。
自社の開発部署のような組織では、外部の方々（例えば、同業他社の開発者やお客様）にお会いする機会はほとんど無く、たまに開発ツールや自社の新製品の展示会などへ出掛けた時に、営業担当の方々と立ち話をする程度で、自分たちが開発した製品をユーザがどのように使うのかなど、想像する機会もそれほど無かったように思います。
お客様の製品に対する意見や不満などは、製品リリース後にクレームとして報告されてきますが、その内容や操作手順などは、製品開発時に考えていたものとは違っていました。
製品に精通した熟練者による開発や評価の工程を経ても、お客様が使う段になると問題が見つかるという状況が何故起こるのか、このような想定していない／できない問題を見つけ出すにはどうしたら良いでしょうか？
ユーザが製品をどのように使うのか、ユーザ環境での使用状況を実際に観ていない場合には、想像すること自体が難しいのではないかと思いますが、例えば問題が発生しやすい状況を意図的に作ることで問題点を見つけやすくすることができるのではないかと考えます。
人間でも、体調が悪い時に無理して体を動かしたりすると、弱っているところに負荷が掛かり、熱が出たり、風邪を引いたりして、さらに調子が悪くなるように、機械やソフトウェアでも大きな負荷が掛かった状態でさらに無理を強いると、案外問題が発生しやすくなることがあります。
また、ユーザやユーザが行う操作を想定したシナリオを作成するようなシナリオテストなどもユーザ視点で問題を見つけ出すのには適しているので、興味のある方は導入を検討してみるということも必要かと思います。
例えばユーザクレームの内容から、なぜユーザがそのような操作を行い、問題が発生するに至ったのかを深彫りして考えていくことで、どのようなユーザが、何を意図してそうしたのかを探るヒントが見つかります。あとは、これら一連の手順をシナリオにまとめ、さらに派生シナリオを作成することで、ユーザ操作らしいシナリオを手に入れることができます。
日々の開発や評価の業務においては、「自分がユーザだったらどうするか？」を常に考え続けることで、お客様の使用状況に近い設計ができるようになり、さらにユーザが求める品質に近づくことができるのではないかと考えます。
またもし可能であるなら、実際のユーザ環境を観て、さらにはお客様の話を聴いてみることも、これからの開発や評価の設計に役立つので、積極的に活動することをお勧めします。