システム立ち上げ直前期のユーザテスト期間が短く、リリース後に現場が混乱

私は産業ロボットメーカーに勤務しており、手配システム（営業が受注した製品を、社内の生産管理部へ手配するためのシステム）刷新のプロジェクトマネージャーを担当しています。
今回はシステム立ち上げ前のユーザテスト期間が短く、リリース後に現場が混乱したプロジェクトをお話ししていきます。
このプロジェクトは、営業メンバー10名、生産管理メンバー５名で活動していました。また、新システムは全国の営業・アシスタントメンバー計40名ほどが使用するものでした。

切り替え前の手配システムは20年以上使われてきたシステムでした。そのレガシーシステムを刷新するプロジェクトでしたので、立ち上げ初期はユーザにとって少なからず困惑が生じるのはある程度承知をしていました。

プロジェクトの一般的な流れにそって「要件定義→基本設計→詳細設計→開発→結合テスト→システムリリース」の流れで進めていました。
ユーザに画面や操作感をつかんでもらうために、結合テストフェーズよりも前の基本設計～詳細設計のフェーズで、事務局からユーザへシステムの動作説明会を開催しました。
また、モックアップの環境をユーザに展開し、自由に触ってもらう期間も1.5か月ほど設けました。

事務局および情報システム部としては、基本設計～詳細設計フェーズで、ユーザに十分に触ってもらう期間を設けたつもりでいました。
その後は開発も順調に進み、事務局が準備したテストシナリオにそってプロジェクト主要メンバーに結合テストの協力をお願いしました。無事に結合テストも完了し、あとはシステム切り替えをするのみです。
前述のとおり、モックアップを触る期間1.5か月と、システム結合テストをしっかり実施していましたので、システム切り替え直前期については、ユーザに新システム（テスト環境）を触ってもらう期間（＝ユーザテスト期間）は１～２週間しか設けませんでした。それで、十分と事務局は判断したからです。

その結果システム切り替え後に、現場が混乱してしまいました。「今までと手配のやり方が異なる」「テスト期間はもっと長くしてほしかった」など、多くの不満が事務局に届きました。最終的には、ユーザも新システムに徐々に慣れていき、クレームは無くなっていきました。

「切り替え直前期にも、十分なユーザテスト期間を設けるべきだった」と今では反省しています。また、「ユーザは日々の業務で忙しくて、なかなかテスト環境を触ってもらえない」ということも頭に入れて、プロジェクト全体の工程を設計すべきでした。