中堅システムエンジニアの備忘ログ

20代後半SEによる、備忘を兼ねた技術的な記事メインのブログです。

品質分析について(ドキュメント編 その①)

こんばんは。ねるおです。


先日、品質分析についてレクチャーを受けました。実践の機会はまだ無さそうですが、忘れないうちにまとめておこうと思います。


レビュー等で摘出したエラーはすべて起票する。

当たり前なようで意外と出来ていない。「担当者間のクロスチェックは対象外」とかいつの間にか自分ルールを作って起票を怠るケースあり。

起票に抜け漏れがあると、その後の指標値との比較が無意味になってしまうので、エラーは必ずすべて起票する。

ただし、起票したエラーが無かったことになるケースもあるある。

 

問題記述票の記載レベルについてメンバの目線を合わせる。

エラー原因等の選び方を統一しておかないと、その後の分析でエラー原因の偏りから弱点を見つけることが出来なくなる。

レビュー期間に突入する前に記載レベルについてメンバ全員の意識を統一する必要がある。が、それでも個人ごとにバラツキがでるはず。

理想は毎日チームリーダーが問題記述票をチェックし、摘出したエラーの傾向を見守りつつ、記述レベルについても「当初決めたルールから逸脱しているものはないか」チェックすることも有効である。(「最後にまとめて・・・」とか絶対無理!!)

いつの間にかエラー原因が書き変わっていても見なかったことにしよう。

 

レビュー時間を記録する

レビューが不適切な場合、十分にエラーを摘出できない。従って、まずレビューが適切であったか?評価するために時間を記録しておくことが大切。

分析フェーズでは「レビュー時間が指標値内に収まっているか」「突出して時間が長かった(短かった)はドキュメントは無いか」を分析し、適切なレビューであったか評価していく。

レビューの形式がオンラインであったか、対面であったかで時間も変わってくるはずなのでレビュー形式についても記録する。

「あれ?あのときのレビューってこんなに時間かかってたっけ?」と思っても口にしてはいけない。

 

まとめ

問題記述票やレビュー時間など日々の記録が正確でないと分析が無価値になります。チームのルールに従って愚直に記録していくことが品質分析の第一歩なんですね。

その後、記録をゴニョゴニョされても泣かない

 


ねるお。

 

 

 

 

 

追伸 ショウスーシーあがられました。


f:id:kojikoji1990:20170622234343j:image