日経SYSTEMSの2014年1月号特集2「現場の困ったシーンで役立つロジカル説得術」は、開発者側とユーザー側のギャップの具体例と、そのギャップを埋めてフィットさせるための事例が示されていて、興味深く読んだ。記事中に挙げられていた「あの画面はこう変えたい」「すべての問題を早急に解決せよ」といったシーンは、多くの開発者が体験することだろう。

　特集ではロジカル説得術のポイントも提示していた。（1）相手にとっての問題、（2）判断基準、（3）提案がもたらす相手にとってのメリット、（4）提案に潜むリスクへの対策―の四つである。これらはコミュニケーションや交渉の基本である。これらが問題解決に大いに役立つのは間違いない。これに加え、開発側とユーザー側のギャップが発生するメカニズムを把握していれば、説得術に磨きがかかるはずだ。

　開発の各フェーズで「現場の困ったシーン」は発生するが、中でも多いのはユーザーがシステムを直接目にするようになる下流フェーズからだろう。しかし、問題の多くは要件定義などの上流フェーズで種がまかれている。一般的には、開発者は要件定義の段階でシステムのおおよそのイメージをつかんでいるものの、業務に関しては理解度が低い。似たような業務システムのプロジェクト経験が他であっても、案件が変われば手探り部分は多くある。

　逆に、ユーザーは業務のことがよく分かっているものの、システムに関しては具体的な完成イメージが持てない。システムの専門家でも要件定義書などの文書だけでは具体的にイメージしにくいのだから、ユーザーができないのは当たり前といえる。

　このように、開発者とユーザーとで業務とシステムの理解度が“逆さま”である期間が長いほど、その後のギャップが大きくなる。要件定義から設計、開発と進んでいくにつれ、開発者は次第に業務の理解を深めていく。この設計・開発の時期はそのフェーズの作業で忙しく、ユーザーと業務に関してじっくり話し合う余裕はない。