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

2022年3月4日

プロジェクトの落とし穴 ユーザテスト期間

何かしらのプロダクトを開発するプロジェクトでは、最終的にそのプロダクトを使うユーザがテストをするユーザテストの期間が設けられます。このユーザテストを開発側が行うテストと同じように捉えていると、思わぬ落とし穴にはまってしまうかもしれません。
今回はユーザテスト期間が短かったが故に大きなトラブルに発展した事例を紹介し、その教訓を考えていきましょう。

失敗談

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

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

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

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

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

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

ユーザテストの注意点

今回はユーザテストの期間が十分に用意されず、トラブルに発展した事例を紹介しました。
開発中のプロダクトについて十分な知識のある開発メンバーとはことなり、ユーザは専門的な知識がないため、操作になれていなかったり、他の業務のためにテストの時間が十分にとれなかったりします。

そのため、ユーザテストの期間は長めに用意し、実際に触れてもらう時間が作れるように関係者と調整する必要があります。プロダクトが完成したら、専門知識のないユーザにもわかるマニュアルを用意し、講習会を開くのもよいでしょう。