ノーマン・カーノベール新しいシステムや大きなアップグレードは、歓迎されるとは限りません。この歓迎きれないということが、プロジェクトにとって大きな脅威になることがあります。最初の段階では、ユーザーが、新しいシステムの実装に賛成しないことはよくあります。いうことがあるのは当然予想しなければなりませんし、理由も記録しておくべきでしょう。最初の段階での反発は、長く拒否反応が残ることと比べれば大きな問題ではありません。アーキテクトは、ユーザーの拒否感情が脅威になることを意識し、その強さがどの程度かを見積もって、脅威を緩和する方向に働きかけることが大切です。そのためには、拒否感情を認識しその理由を考えなければなりません。見られる理由は、次のようなものです。新しいシステムが必要で、古いシステムを引退させなければならないことはわかっているが、そのために従来の機能がなくなることや、仕事が変わって自分の影響力がなくなることを恐れている。新しい、海のものとも山のものともつかないテクノロジーに恐れを感じている。コスト/予算の問題が気になっている。単純に変化を好まない。これらの理由には、それぞれ異なる解決方法が必要です。アーキテクトの力でどうにかできるものとそうでないものがあります。理由の違いを見分けて、対処できるものについては、早速動かなければなりません。早い段階で、エンドユーザーと新システムとその利点、欠点について、どう感じているか、実際にはどうなのかということについて議論を重ねるのです。長期的にもっとも効果的なのは、システム自体の設計を使ってユーザーの懸念事項に対処することです。システムのデモ(プロジェクトの初期段階で)、新システムによってユーザーが得るものについての知識の共有などです。「プロジェクトのサボーター」がいれば、ユーザーの拒否感情の問題をやわらげるカになります。ユーザーグループや利害関係者を代表するような人物に「サポーター」になってもらえば理想的です。場合によっては、まず、この人物にシステムのメリットを確信してもらわなければならなければなりません。適切な人物がいなくても、最初の時点から誰か1人を立てた方がよいでしょう。「プロジェクトのサポーター」を決めたら、あなたができるあらゆる形で彼を助けていくことです。ソフトウェアアーキテクトが知るべき97のこと当サイトはオライリー・ジャパンによる公式なサイトではありません。個々のエッセイは「CC-by-3.0-US」によってライセンスされています。2プロジェクト・マネジャーが知るべき97のこと。