現在私は、数ヶ月前にカットオーバーしたシステムの品質保証というやっかいな仕事に取り組んでいます。。。

まぁよくある話なのですが、納期最優先で気合いと根性によりなんとかカットオーバーして、クリティカルな障害は出ていないものの、ポツポツとしょぼい障害が発生するという状況が続いており、顧客から品質について見直せというクレームが出ているわけです。

ちなみに、アーキテクチャ視点から見たこのシステムは、Java製で、WebフレームワークはStrutsを使用しており、ORマッパーやDI・AOPなどの比較的新しい技術は利用していないため、ゴリゴリの実装になっていました。PLに聞いたところ、新技術を利用することによる技術的問題を抱える余裕がないため、枯れた技術で構成したとのことです。まぁ個人的には、枯れた技術を利用してももっとやりようがあったとは思いますが、後の祭りですね。

とりあえず、MavenやHudsonを導入して、JUnitで単体テストクラスを作って（今はありません）などというタスクになるといいうことで、引き受けたわけですが、提案資料を作っている最中に大きな障害が発生し、ソースレビューだとか機能テストのやり直しだとか、もうちょっと根本的なところから手を付けることになりそうです。

よくよく考えてみると、上記に挙げた単体テストの自動化＆レポート作成などの仕組みは、開発フェーズにおけるプロセス改善として、品質を作り込むための事前予防的なアプローチです。対して、今回の私のミッションは、すでにカットオーバーしているシステムの品質をチェックして、問題があれば直すということで、最初から後手のアプローチになっているわけですね。

とはいえ、顧客に対して、「品質が上がってよかった」もしくは「品質に問題がないことがわかってよかった」のいずれかの納得感を持ってもらわねばなりません。これらを定量的に実感してもらうためには、何らかの品質指標を使うという手もあるのですが、これを可視化するとこちらとしても困るとか、今後もその指標に縛られるから嫌だとか、PM・PLからいちゃもんをつけられたため、工学的な手法も微妙だったりします。

そんなこんなで、内部的な事情も考慮しつつ、障害分析の深掘りから見えてくる傾向と対策により品質チェックをするという方向で提案しようとしています。これで顧客からどんな反応が返ってくるかドキドキですが。。。

■参考リンク

Wikipedia：ISO 9126

■参考にした文献