教育系パッケージソフトの導入 -ユーザテスト編-

ユーザテスト

教育系パッケージソフトの導入はユーザテストに入りました。

 

このフェイズではユーザに実際にシステムを操作をしてもらい、業務要件を満たしているかを確認してもらいます。ベンダーによって多少呼び方が異なり、総合テストがこのフェイズの位置づけになっていることもありますし、ビジネステストと言うような場合もあります。

 

この段階では、システム的な不具合はほぼ解消されており、プログラムの品質が担保できていることが大前提です。ユーザにはあくまでも「業務要件を満たしているか」といった観点から、確認をお願いします。
ただし、あまりにも炎上しているプロジェクトだと、この時点で品質が全く追いついていないこともあり、お話にならない程バグが発覚することもあります。問題外の話ですが、意外と多くの現場でこのような状況になっているのが、日本のシステム開発の現場です。

意外なトラブル

今回の場合はパッケージ適用だったため、致命的な問題はほとんど発覚しませんでした。
軽微なバグが2点、仕様の誤認による設計不良が1点であり、いずれも既定の期間内で修正することができました。

 

しかし、問題はデータの方で発生しました。
今回は多くの外部連携を行っていたのですが、実際に連系されたデータを詳しく見ると、以下のような問題が発生しました。

 

  1. 想定していたデータフォーマットで送られてこない
  2. 区分などの項目に想定外のものが入っている
  3. 重複したデータが存在する
  4. 値の持ち方が想定外でありパッケージ側でエラーが起こる

 

いずれも、システム屋を長くやっていれば定番のネタなのですが、あまりに大量の問題が同タイミングで発覚したため、現場(私)は火の車となりました。
今回のプロジェクトでは、サンプルデータをある程度事前に受領しており、そちらを見たところでは特に問題がなかったのですが、大量データを入手してみると、その中に上記のような問題を引き起こすものが含まれていました。

 

データ確認作業は本来もっと早い段階で実施しておくべきだったのですが、初心者だったこともありユーザテストの前後で行ったため、最終局面になって慌てることとなったのです。
データパターンの確認、変換プログラムの修正、クレンジング対応などの対応を必死で行いました。何とか納期には間に合ったものの、レビューやダブルチェックが手薄になり、システムのカットオーバ―後に移行漏れが発覚することがありました。

 

ちなみに、データの問題が発生した場合、パッケージ側かバッチ側のいずれかのプログラムを修正して対応させることが考えられます。
パッケージソフトの場合、テーブル定義などや内部処理を変更しようとすると、オプションとして纏まった費用を取られることが一般的ですので、大体の場合はバッチ側で対応します。

 

今回は、余分な費用を甘く見ていたプロジェクトでしたが、意外なところで失敗をし、深く反省すると共に、大変多くの事を学ぶことができました。

 

パッケージ適用のポイント、それは

移行データの早い段階での精査

これに尽きます。

転職サイト・エージェントの選び方を徹底検証!

転職サイト ランキング

管理人が実際の転職を通じて学んだ転職サイトの選び方とおすすめのエージェントを紹介しています。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です