システムリリース後、バグの発生をはじめ様々な不具合で、修正や改修の対応に追われることは珍しくありません。ですから、バグや不具合が起きても冷静に対処し、ユーザーの不満の声にもきちんと耳を傾けて、システムをより良いものに進化させていくことが肝要です。本記事では、システム改修と再公開の具体的なプロセスを解説します。
改修はユーザーのフィードバックから始まる
システム公開後の改修は、ユーザーのフィードバックが発端となることがほとんどです。社内システムのアップデートや入れ替えの場合は該当部署の社員から直接「ここがうまく動かない」と電話やメールで連絡が入るでしょうし、一般ユーザー向けサービスの新リリースや新機能追加の場合でも、最近はインターネットを通じてユーザーから反応が直接上がってくるようになっています。
みなさんも経験があるかもしれませんが、「自分は何もしていないのにシステムが勝手におかしくなった」というフィードバックもあります。これには2パターンあって、本当にシステムにバグが起きているケースがひとつ。もうひとつは想定されていない使い方をユーザーがしたケースで、ほとんどは後者です。
「Webブラウザの『戻る』ボタンは押さないでください」という注意書きを見ることがあると思います。それぞれのシステムには、“正しい”扱い方があるのです。説明書やマニュアルを読まずに誤った操作をしてエラーが発生するのは、仕方がありません。
とはいえ、同様のフィードバックが大量に届く場合や、発生するエラーが重大な場合などは、「言われた通りにしなかった本人が悪い」と片付けるのではなく、「Webブラウザの『戻る』ボタンを押してもエラーが起きないようにするには」というように、ユーザーの操作性を優先してシステムの改修を検討すべきケースもあるでしょう。
「改修がないのがいいシステム」と思われるかもしれませんが、不確実性の極めて高いシステム開発において、100点満点を目指すのは非現実的です。ユーザーの声に向き合っている会社ほど、改修サイクルが早い傾向もあります。「改修＝悪いこと」では必ずしもないという意識を持ちましょう。実際に、ユーザーの声に応えて素早い改修を繰り返している企業はそれ自体がブランドとなっており信頼を獲得しているようなケースも存在するほどです。
