システム開発の現場では、構築したシステムが正しく動作するかをテスト（検証）します。この工程を関係者で一丸となって楽しく乗り切りませんか。障害管理表を活用し、グラフを使ってゴールと達成状況を見える化することをお勧めします*1。
ちょうど1年前にそういうエントリを書きました。今読むと言葉が足りないように感じるので別エントリを作成しました。
障害管理に関するグラフ
障害と書きましたが、進捗と障害の両方を可視化します。テスト消化線で、予定した通りにテストが進められているかをみます。
不良摘出線で、予想した通りに不良（バグ、障害）が摘出できるかをみます。
さらに、摘出した不良（バグ、障害）が解決できているかもみます。
これら3つをみていくと、テストを始める前に期待した通りにシステムが動作するようになっている（品質が作り込めている）ことが実感できます。
これらができているのに実際のシステムの完成度が不十分だと感じる場合は、テスト計画に欠陥があるかもしれません。必要なテストの種類やテスト項目に不足がないかの確認をお勧めします。
テスト工程を楽しく乗り切るための工夫
昨年のエントリでお伝えしたかったのは、グラフ化して共有するだけで楽しく取り組むことができる、ということです。ゴールと達成状況が関係者の間で見えるようになり、モチベーションの向上が期待できます。
テスト実施者は1つでも多くのテスト項目を消化しようと、問題解決者は1つでも多くの不良を解決しようと働きかける。
テスト消化が思うように進まない場合は、テスト項目の記載なのかテスト対象のプログラムが不十分なのか原因を特定します。
解決が思うように進まない場合も、不良を解析するためのテスト結果の書き方が悪いのか、プログラム自体が不十分なのかなど原因を特定します。
原因が特定できたら何を補強すればベストなのかを関係者で提案し合い、共有し対策として実施します。
グラフも、チーム別や担当者別に出力することでさらに責任範囲を明確にし、やる気を上げることもできます。
終わりに
システム開発の中でも特にこのテスト工程は分業化して進めてきたチームが一丸となることが重要だと考えています。だからこそこのグラフを効果的に使って、共通のゴールに向かってみてはいかがでしょうか。
ゲーミフィケーション研究家usaboより
*1:どんな現場でもやっていることなのは理解しています。それをいかに前向きに捉えて盛り上げるかが重要だと考えています
