＃4：要求定義工程やテスト工程において、エンドユーザー自身に積極的な役割を担ってもらう
エンドユーザーとのミーティングを開催したあとすぐ、IT部門が独自にプロジェクト要求ドキュメントを作成するというケースをあまりにもよく見かける。協力関係を維持し、両者の期待に隔たりが生じないようにするうえでの最適な戦略は、プロジェクトの要求定義作業を率いるという役割（少なくとも業務的側面に関する役割）をエンドユーザーに担ってもらうというものだ。エンドユーザーはプロジェクト全体を通じて、すなわち初期のプロトタイプテストからプロジェクトの本番稼働前に実施する最終的な受け入れテストまで、関与し続けるべきだ。疎外感を抱いているエンドユーザーがいるのであれば、プロジェクト内で充実感を得られる役割を担ってもらうことで、状況を変えていくための大きな1歩を踏み出せるはずだ。
＃5：ユーザーフレンドリーなIT担当者をユーザー窓口にする
昔からIT部門は人間を中心に据えるのではなく作業を中心に据えて仕事を進めてきている。しかし、IT担当者には社交性に長けた人材もおり、彼らは人から、そして作業から最善の結果を導き出す方法を体得している。怒っている、あるいは不満を抱いているエンドユーザーがいるのであれば、社交性に長けるとともに、仕事にも打ち込めるIT担当者をユーザー窓口にしてほしい。
＃6：エンドユーザーが感じている業務上の痛点に共感を覚える
関係の修復に向けた手始めとして、エンドユーザーの立場に立つというのは良い考えだろう。Javaのコードをそのまま引用したようなエラーメッセージを表示させるのは造作もなく、プログラマーであればそういったメッセージから容易に意味をくみ取れるかもしれない。しかし、ちゃんとした文章を表示させてほしいと思っているエンドユーザーや、エラーによって仕事が止まってしまうエンドユーザーにとっては大きな問題なのだ。同様に、あなたがIT部門に所属しており、システムの問題を解決しようとしているのであれば、ユーザーに何も知らせず、不安感をただ煽るのではなく、進捗を定期的に報告するよう心がけてほしい。信頼関係にひびが入った元々の原因が貧弱なコミュニケーションにあったというのであれば、問題への取り組み状況をエンドユーザーに報告するというちょっとしたことだけで、関係修復に向かって大きく踏み出せるはずだ。
＃7：プロジェクトの状況について正直かつ率直になる
悪いニュースを好む人はいない。とは言うものの、プロジェクトが遅延している際には、エンドユーザーを避けたり、プロジェクトの状況に関して都合の良い内容だけを報告するのではなく、プロジェクトが実際にどうなっているのかを率直に打ち明けるようにしてほしい。筆者はIT部門の中間管理職としてのキャリアを積み始めた頃に、こういった過ちをおかした担当者を見てきている。彼はプロジェクトを制御不能にし、その過程において自らとその上司のクビを飛ばしたのだ。そしてチーム全員がエンドユーザーの激しい怒りの犠牲になったのだった。怒りの原因はプロジェクトがうまく進捗しなかったためではなく、プロジェクトの本当の状況をユーザーに報告し、緊急時の対応を取れるようにしなかったためだ。現在携わっているプロジェクトに問題がある場合、常に状況を報告してユーザーの驚きを避けるようにすれば、このような事態を避けられるはずだ。
