変化のための道筋を描く

新しいソフトウェアは仕事のやり方を変えます。これは組織にとってよいことかもしれませんが、そこで仕事をしている人は必ずしも変化を受け入れる準備ができているわけではありません。この現実を認めましょう。新しいソフトウェアを使うよう説得できなかったり、なだめられなかったり、指示できなければ、それは時間とお金の大きなムダになります。

仕事のやり方を変えさせるときには、ムチ（罰）よりもアメ（報酬）の方がはるかに有効です。たとえ新しいソフトウェアを導入せざるを得なくなったとしても、ユーザーが理解して習得するに値する大きな利益が見い出せなければ、彼らはあらゆる手段を駆使して使わずに済ませようとするでしょう。（1）この変化が関係者にどんな影響を及ぼすのかを理解し、（2）彼らが変化を受け入れられるような変更管理計画を整備するためには、適切なケアが必要になります。

変化がどんな影響を及ぼすのかを理解するために重要なのは、みんなが現在どのように仕事をしているのか、新しいソフトウェアはそのプロセスをどのように変えるのかを理解することです。そうすれば新しいソフトウェアがユーザーのニーズに合致することを保証でき、ユーザーが新しいシステムを導入する可能性が高まり、最終商品の設計も改善されます。

変更管理の重要性を過小評価してはいけません。これはプロジェクトの初期にプロジェクト・マネジャーが注力すべきところです。変化がユーザーにどんな影響を及ぼすのか判断するために、まずはソフトウェアプロジェクトにまつわる現在のあらゆる（そのままの）プロセスをドキュメント化しましょう。毎日のタスクを列挙したプロセスフローダイアグラムとデータの入出力を図示しましょう。

次に、新しいソフトウェアを展開することによって、これらのプロセスがどのように変化するのかをドキュメント化しましょう。新しいソフトウェアのターゲットユーザーと率直に話し、その変化がどのような影響を及ぼすのか議論しましょう。彼らの声に注意深く耳を傾けて、フィーチャー変更の影響とそのコストを評価して、ソフトウェア設計を徐々に整えていきましょう。変化がターゲットユーザーと彼らのマネジメントに受け入れられているか確認してください。ターゲットユーザーのマネジャーを、早期に頻繁に巻き込みましょう。彼らは変化に対する重要な支持者となります。エンドユーザーに切り替えを勧めたり指示したりすることにより、彼らは新しいシステムへの移行を実施もしくは中断できます。彼らは新しいソフトウェア展開に伴う障害を取り除き、不測の問題を解決するための貴重なパートナーなのです。

変化のための計画を作りましょう。プロジェクト立ち上げ前にやっておく必要のあるトレーニングやチーム作りのためのリストを決めて、ユーザーのスケジュールに組み込んでおきましょう。変更管理計画を作るときには、マネジメントからの支援を仰ぎましょう。少なくとも彼らが、そのコンセプト、実行およびトレーニング方法、スケジュールについて心から賛同していなければなりません。彼らからのアプローチに対する反対意見や警告には、注意深く耳を傾けましょう。

結局のところ、ユーザーとそのマネジメントはビジネス目標を果たすことに正面から注力し続けることに関心があります。新しいプロセス、ツール、システムへの移行は、彼らの目標達成にとって潜在的脅威になり得ます。きっちり事前に計画しておきましょう。そうすれば、新しいシステムへスムーズに移行でき、賛同と受け入れのための道を開き、長期的な利用の機会を高めることができるでしょう。