・ユーザーが要件を定義してくれない
・ユーザーのいう事はコロコロ変わる、何で今になって仕様変更なんていうんだ
・ユーザー内の意見集約が進んでいない
・ユーザーが自分の仕事も分かってない
・ユーザーが前もってこの情報を伝えてこなかったから、スコープに入っていない
このような発言を、今も昔もよく聞きます。
たいてい決まって、システム開発プロジェクトに進捗遅れが出た場合に聞きます。
私は、ITエンジニアの言い訳にしか聞こえない。
それなのに、一見、一理ありそうな理論を展開します。
・システムの人間は業務を知らないんだから、ユーザーがどんなシステムを作りたいかハッキリしてくれないと作れない
・ユーザーの為のシステムなんだから、ユーザーがどのような業務改善をしたいのか、具体的に考えるべきだ
私からみると、『何を今さら』です。
システム開発案件に着手した時点で、ユーザーが作成した資料なり、説明内容なりは聞いているはず。
あるいは、自ら（あるいは同僚、上司が）何かをユーザーや経営層に提案し、要件定義書や基本設計書の作成に関与したはず。
本当にユーザー部門とシステム部門で役割分担の「当たり前」を持ち合わせているなら、開発案件の開始時点で合意形成を行うべきです。
コトの始まりでは無責任にもユーザー部門や発注側に期待を持たせ、いざ躓くと責任転嫁をする。
こういうタイプは、若手よりもむしろ、技術・知識の空洞化世代ともいうべき40代、50代のエンジニア・管理職に多いように思います。
本人の前では言えず、陰でしかいえないタイプも少なくありません。
別の教育記事「教育 残念ながら、SE向けの教育体制は成熟する土壌がなさそう」で記載した、メッキ人材の帰結です。
このようなエンジニアが担当したケースでは、例えば私なんかが横から指摘をしても聞く耳を持たず、自らが正しいと頑なに信じています。
（例外的に、第三者が特効薬の処方箋を出すと聞いてくれます。）
こうして、業務改悪システムが出来ることすらあります。
・導入前より仕事が大変になった
・導入して効果があるというが、実感はない
・導入に何千万、何億円もかかってるらしく、使うしかないらしい（失敗は責任問題になってしまう）
⇒ユーザー部門・実担当者の不満は上に届かず、システム推進者は表面的に成功扱いにすることが常です。（ユーザー部門の中でも、システムを使う人はやや立場が弱い傾向。意思決定者はシステムを使わない。）
ではどうすべきか、と言うと、答えはいくつかあります。
その一つは、このブログの主旨である、SEが自ら業務知識を備え、自ら考え、ユーザーを引っ張ることです。これは私の考えるベストです。
ユーザー部門から出される「やりたいこと」は、基本的には「自分・自部署にとってベター」の視点です。
加えて、工場ではQC活動やカイゼン活動といったことが行われているので、コストは一旦置いておいて、「ないよりあった方が良い」事案をブレインストーミングのように出してみる、という土壌があります。
従って、ユーザーの多くの発言から社益に資する内容と、コスト負けする内容を判断し、ふるいにかける。取り下げるべき内容は、その妥当性をユーザーと疎通していく。このようなバランス調整を繰り返す。
それを行う『誰か』が必要になります。
『誰か』は、業務とITの両面に詳しい必要があります。
ユーザー部門とIT部門でタッグ/スクラムを組んで『誰か』を構成するのもアリですが、１人でやるより難しい側面があります。経歴、感覚、常識が違うので、疎通・合意にオーバーヘッドが多いこと、お互いがお互いをリスペクトした間柄でもなければ機能しないこと、などが懸念されます。
１人で『誰か』をやるとしたら、ユーザー部門がITを学ぶか、IT部門が業務を学ぶかは、様々な考え方があろうかとは思います。
私の考えでは、ユーザー部門にハイブリッド人材を作るほうが難しいとの意見です。ユーザー部門は別に本業を抱えているのに対し、IT部門は業務仕様・システム実装に触れる毎日です。開発に求められる感覚は、実務を通じてしか身につきません。
少し自分の自慢のような話で大変恐縮ですが、私はその『誰か』を実践しているつもりです。（勿論、100点ではありません。毎回、反省と改善の繰返しです。）
これを掘り下げると長くなるので、別に全社最適カテゴリの記事を書くときに記載したいと思っています。
『誰か』がいなくて、表面上順調に進んでいくプロジェクトを見てきました。
お互いがお互いに、暗黙の期待を持っていて、最初は仲良く進めているのに、いつのまにか険悪ムードに変わっていました。
システム完成後、そのまま犬猿の仲になったり、関係修復して「（業務改悪システムを作ってしまったのに）あの時は、あの情報では、誰がやってもこの結果がベストだったな」と両者の貢献で、まるで成功したかのような振る舞いをしたりと、色んな人がいました。
システムは同じモノを２つ作る訳ではないので、比較しようがなく、何かしらのＫＰＩなど成功指標があっても、少なからず主観が入るので、成功プロジェクトとは「言ったもん勝ち」なんですよね。（失敗したことを）知らぬが仏ともいえますが。
処理仕様をユーザーが見ても、正しく理解できるケースは稀。提案する側、即ちITエンジニア側がユーザーの言葉で合意を目指すことが、遠いようで最も現実的だと思います。