文字化け〜データベースは大丈夫か？

「画面上で『〜』という文字が文字化けを起こして『??』と表示されているバグが報告されてきた。管理者のD氏は、文字化けは表示だけの問題と思い、優先順位を『低』にして対応することにした。ところがその後データベースに格納されているデータの『〜』が文字化けを起こしていることが判明した」

日本語のシステムを開発していると必ず文字化けの問題に遭遇する。文字化けを起こす文字の中でも、特に「〜（wave dash）」はその代表格である。

システムのどこかで文字化けの事象を発見したら、その箇所だけでなくシステム全体の問題と考えるべきだ。類似の処理をしている箇所はないか、また文字化けのデータをデータベースに格納していないかを確認することが必要である。

バグ票〜バグを再現できない

「システムカットオーバー間近の某プロジェクト。納品間近のテスト工程で予想以上にバグが多発し、現場は混乱していた。開発担当のE氏がバグを修正しようとバグ票の中身を確認したところ、『画面Aがおかしい』『マウスが変な動きをする』『金額が合わない』などと書いてあった。修正内容がわからず、バグ票を書いたメンバーを捜すのに途方に暮れてしまうE氏であった」

意味不明なバグ票というのはテスターの数が多ければ多いほど遭遇しやすくなる。テスターや開発の未経験者がいると、修正時にどんな情報が必要であるかという勘所がないため、奇怪なバグ票を提出することが多い。かく言う筆者も、新人の頃は意味不明なバグ票を書いて、現場を混乱させてしまった経験がある。

ユーザの視点〜実は重要だったもの

「とあるアプリケーションのリプレイス案件にて。ある画面上で、Tabボタンを押すと入力欄をカーソルが移動する仕様になっており、その遷移順が異なるというバグがあった。カーソルの遷移順は、データ更新には影響せず、また影響範囲もその画面だけの内容だったので、優先順位を『低』に設定していた。ところがその画面を使うユーザは、リプレイスする前のアプリケーションで相当に訓練されており、入力の手順は『手で覚えている』人がほとんどであった。それらのユーザから、カーソルの移動順が異なると、自分たちの業務処理のスピードに多大な影響を与えるという申告があり、そのバグの優先順位を『高』にすることにした」

これはアプリケーションエンジニアの視点で「業務」を考えていないと、つい陥ってしまう事例である。「画面系＝優先度『低』」と考えていると判断を誤ってしまうので注意が必要だ。ユーザ登録画面や賞品の申込み画面、あるいは伝票の入力画面などは、ユーザインターフェースの優先順位が他の画面に比べて高くなる。

今回紹介した例は、実際にソフトウェア開発で起こりやすいものであるので十分注意していただきたい。最後に、効率的なバグ管理を行うポイントについてまとめていこう。 次のページ