品質管理

品質管理

品質管理はシステム開発で重要な管理項目の一つです。

品質に問題があると作業に手戻りが発生し、
・スケジュール
・予算
に大きな影響を与えます。

ここで説明する品質管理は、各工程で一定以上の品質を確保する事を目的にする管理になります。

 

設計開発工程

設計開発工程の品質管理は、以下の工程で行う品質管理です。
・外部設計（基本設計）
・内部設計（詳細設計）

 

設計工程の品質管理

設計工程の品質管理は、設計書のレビューを実施する事で実現します。

設計書のレビューはどの会社でも行っている事ですが、レビューの品質をいかにして高めるかがポイントになります。

レビューの品質を高めるための管理ポイントは
・レビュー者
・レビュー時間
・レビュー指摘数
・レビュー指摘内容
となります。

それでは、個別に管理方法を説明していきましょう。

 

レビュー者

レビュー者の評価は、誰がレビューを行ったかと言う評価を行います。
例えば、外部設計書のレビューは、基本的に要件定義を行った人が行います。
若しくは、システムの利用者やシステム全体の設計者が行います。

システム全体やプロジェクトの要件を理解していない人がレビュー者では、外部設計の内容がシステムの意図に沿っているか判断できません。
内部設計では、利用者が細かいロジックを把握しているケースは少ないため、外部設計者が適切なレビュー者と言えます。

ポイント

「適切なレビュー者がレビューを行っているか」

が評価のポイントになります。

 

レビュー時間

レビュー時間の管理は、各設計書にどれだけ時間をかけてレビューしたかを評価します。
レビュー時間の評価方法は、設計書1ページあたりにどれくらいの時間をかけたかを評価します。
レビュー時間は長くても短くても駄目です。

レビュー時間が短い場合は細かい部分まで確認できていない可能性が高いと思います。
レビュー時間が長い場合、品質が上がる可能性は高くなりますが、生産性を考えると適切ではありません。
（A4の設計書1枚のレビューを、10分で行うのと、1時間以上かけて行うのでは、品質はほとんど変わりません）

適切な時間は、設計書の記載レベルにもよりますが、10枚の設計書だと30分～60分を目安に考えます。

システム開発でレビュー時間の実績を残していくことで、適切な時間が割り出せるようになるので、プロジェクトごとに「レビュー時間と不良の発生件数」の割合を残していくようにしましょう。

ポイント

「レビュー時間は適切な時間が確保できているか」

が評価ポイントになります。

 

レビュー指摘数

レビュー指摘件数は、レビュー実施時にどれくらい指摘が発生したかを評価する項目です。

レビュー者やレビュー時間がレビューのレベルを評価しているのに対して、レビュー指摘数は設計書の品質を評価する数値になります。

適切なレビューアが適切な時間をかけてレビューを実施した場合、指摘件数が平均値よりも多い場合、設計書の品質が低いと言う判断ができます。

レビュー指摘数が多い場合、
・同じ人が作った設計書の指摘数はどうなのか？
・同じ機能の設計書の指摘数はどうなのか？
と言う観点でチェックします。

特定の人が作った設計書の指摘が多い場合は、その人が作った設計書を再レビューしたり、指摘の多い機能を再レビューする事で、全体の品質を上げる事ができます。

ポイント

「レビュー指摘数は、品質が低くなりやすい箇所を事前に把握する」

と言う評価ポイントになります。

 

レビュー指摘内容

レビュー指摘内容の評価は、指摘内容を分類分けして評価します。

指摘分類は、大まかに以下のように分類します。
・誤字脱字
・記載漏れ
・仕様の勘違い（仕様を間違えて理解していた）
・記載ミス（仕様は理解していたが、間違って記載していた）
・曖昧な記述
・指摘ミス

仕様の勘違いが多い場合、上位の設計書の記載が曖昧な可能性があるので、上位の設計書も再チェックした方が良いですし、誤字脱字や記載漏れ、ミス、曖昧な記述が多い場合は、設計者のスキルが低いと判断できます。

ポイント

「レビュー指摘内容で、設計書の品質低下の原因を分析する」

と言う評価ポイントになります。

 

テスト工程

テスト工程の品質評価は、設計書とは異なる評価になります。

テスト工程の評価は、
・適切なテストケースでテストを実施したか。
・テストの結果、想定通りの品質が確保できているか

を評価します。

 

テストケース数の評価

テストを実施する場合、テストケース数は重要な指標になります。

システムの規模が大きくなるほどテストケース数は増えていきますが、テストケースが足りていないとテスト内容が妥当でない可能性が高くなります。

テストケースは、有識者（設計者や利用者）がレビューを実施しますが、テストケース数を見ることで、概ね妥当か否かの判断が可能です。

テストケースは、システム内の分岐の数だけ増えていきます。
（単体テストではプログラム内の分岐の数、結合テストでは外部設計書の分岐の数）

1,000ステップあたりの分岐の数は一定の範囲に収まる事が多いので、1,000ステップ当たりのケース数を把握する事で、ケース数が妥当か否かの判断が可能です。
（1,000ステップあたりのケース数は、過去のプロジェクトで設定したケース数の平均値を参考に評価します）

1,000ステップ当たりのケース数が少ない場合は、なぜ少ないのか？（多い時もなぜ多いのか？）を調査し、ケース数の妥当性を評価します。

傾向としては、画面系のプログラムは1,000ステップ当たりのケース数が多くなる傾向にあり、ファイルや帳票の編集は1,000ステップあたりのケース数が少なくなる傾向があります。

ポイント

「1,000ステップ当たりのケース数をチェックする事で、ケース密度の妥当性を評価する」

と言う評価ポイントになります。

 

テスト結果の評価

テスト結果の評価は、
・発生した不良の数
・不良の内容

を分析します。

まずは不良の数の分析です。

不良の数はシステムの規模が大きくなるほど増える傾向にありますが、あまりに多い場合はシステムの品質が低い可能性があります。

システムの規模以外にもシステムの難易度にも影響されるので、一概に何件が適正とは言えませんが、過去のプロジェクトの規模と不良の発生件数を平均化し、その平均値より多い場合は品質を疑った方が良いでしょう。

また、不良が少ない場合、テストが適切に実施されていない可能性があるので、テストケース数が足りているか確認し、「テストケース数も不良も少ない」場合、不良が少ない理由を分析します。

不良の内容についても分析を行います。

分析方法は、レビュー指摘内容と同様に、
・設計書ミス（仕様ミス）
・コーディングミス
・データミス
・手順ミス
・環境不備
などに分類します。

いづれかの分類に不良が集中するようなら、その分類に特化し、品質向上活動を行います。

また、前工程で発見すべき不良が多い場合（システムテストでコーディングミスの不良が頻発するなど）、前工程のテストが適切でない可能性が高いので、前工程のテストを再実施するなどの対策を行います。

ポイント

「テスト結果の評価は、システムの品質を確認する最終チェックとなる」

システムテスト工程では、システムの不良を発見する最終工程となります。

システムテストで不良を発見できない場合、実業務で不良が発生する事になります。

システムテストで発生した不良は、丁寧に分析し、「発生した不良は氷山の一角」と言う気持ちで類似調査を行います。

 

まとめ

いかがだったでしょうか。

システム開発を行っている人から見ると、当たり前の内容ばかりですが、この当たり前の事が出来ていないのが現状だと思います。

当たり前の事を当たり前に実施すればシステムの品質は格段に向上します。

今回は、品質管理の概要の説明になりましたが、今後も品質管理の詳細の解説や、予算や時間に限りがある時の品質管理も解説していきたいと思います。