こんにちは、Hです。
梅雨も明けて急に暑さが増してきましたね。
水分補給をこまめに行って熱中症に気を付けるとともに
プロジェクトの作業にも集中力を切らさずに行きたいですね。
プロジェクトも後半戦に入ってくると、テスト実施とその時点での
品質が見えてきます。またテストで発生した不具合などを
分析して顧客に報告する必要もあると思います。
今日はその品質を報告するというお話です。
品質報告って？
品質報告ってそもそも何でしょうか？
それは現在開発しているシステムがどの程度の品質を担保できているのかを
定量的・定性的に分析して状況を伝えることです。
決して品質が良くできているように見せるものではないですよね。
もし品質が想定したレベルに到達していないのであれば、その原因をあぶり出し
対策を実施していく必要があります。
そしてこの品質状況を把握するという作業、これは開発メンバーの仕事ではなく
プロジェクトマネージャの重要な仕事です。
日々頑張っているメンバーが最終的な果実を得るためにも、
ここは数字をベースとして冷静な態度で品質を評価していく必要があります。
ここで発生しているトラブルのシグナルをしっかりとチェックすることで
未然に障害を防ぐことができるからです。
なんだかんだいってリリースが問題なく終わることがチームにとっては一番の成功です。
どんなことを報告する？
私たちのプロジェクトでは品質を報告するためのテンプレートを用意して
報告書を作成しています。
どんなことを記載しているのでしょうか。下記に記載していきます。
■基礎数値
まずは品質評価のもととなる数値を洗い出します。
1.改修規模
基本的にはステップ数を算出して、改修規模を表します。
2.品質目標指標
ステップ数から割り出されるテストケース目標や不具合検出目標数を表します。
■テスト内容
つづいて実際のテスト結果をまとめます。
3.テストケース数、不具合検出数
実際に実施したテストケース・不具合件数の数値をシステムや機能単位で
集計します。
4.テスト消化状況、不具合発生・解決状況
テスト期間中の実績を表やグラフとして表していきます。
いわゆるテスト消化曲線とバグ曲線です。
5.不具合の事象、原因
このあたりは不具合管理システムを利用して管理しているので
その値をそのまま集計して算出しています。
事象や原因には下記のようなものがあります。
○事象
・データ更新内容の不正
・画面表示データの不正
・画面文言の不正
・画面遷移不正
・異常終了
○原因
・仕様不備
・設計不備
・コーディング不備
・テスト手順・データミス
■品質分析
先ほどまとめた内容をもとに品質を分析します。
全体としては不良の発生状況やどんな事象や原因が発生しているか？
そしてその不良が発生した背景は何か、類似確認を終えているかなど
確認していきます。
また特定の機能に不良が偏っていないかなど機能単位の品質もチェックしていきます。
テスト内容についてもテストの網羅性やケース数が十分か、
またテストの観点に抜けがないかなど振りかえって分析します。
必要に応じて品質が低い機能の分析のしなおしや追加のテストを実施したり、
施策も合わせて考えます。
■品質報告
上記のような分析を終えたら、最終的に今の工程での品質判断をしていきます。
指摘をしっかり受け止める
こうして作成した品質報告書。
最後はユーザや担当者の方に内容を報告します。
品質報告については基本的には悪い部分に指摘が集まります。
当然ですね、品質を上げるためには必要なことです。
報告する立場としては時に非難・中傷に近い指摘を受けることもありますが
ここはしっかりと受け止めることが大切です。
むしろ報告する中で新しい不良を発見してもらうぐらいの気持ちで臨むと
いろいろな指摘・意見をもらって本当に不良が発見できたりします。
最後に
今やシステム開発は品質が良いことは当たり前。
差別化の要素としてもアピールしづらいものがあります。
ですがやはり品質が良い開発チームは現場では信頼感を得るのも事実です。
この品質報告という作業、顧客を納得させるための作業ではなく
プロジェクトマネージャが実施する成果物品質への向上作業ととらえて
取り組むことでより品質の高い報告書ができると思います。
世の中のプロマネさん、胸張っていい報告していきましょう！
