DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

早いもので、夜の街並みのあちこちでクリスマスツリーの明かりが目につくようになりました。2015年は箱根山の火山活動、鬼怒川の決壊など、自然災害が多い年でした。防災マップやハザードマップを公開することで、地元住民に対して、いざという時に備えるよう訴えかけている自治体も多いと思います。（※１）

システム開発の現場でも「品質マップ」などを用いて、品質状況の「見える化」を図り、品質管理活動の効率化を目指す必要があります。

【　「品質マップ」とは？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
プロジェクトも終盤を迎えたシステムテストやユーザテストで障害が多発している場合など、システムの品質があまり良くない状況では、なんとか本番稼働までに品質向上を図る必要があります。しかし、既に本番稼働までの期間やリソースも限られている中で、やみくもに品質向上策を打っても、逆に混乱に拍車をかけることになりかねません。確実に効果のあがる品質向上策を実施するためには、ポイントを絞る必要があります。

単体テスト、結合テストと定量的な品質評価を行っていた場合でも、システムテストともなれば、それまでとは摘出される障害の質が異なることも多いので、最新の品質状況をしっかりと分析する必要があります。いわゆるＶ字モデルの考え方に基づけば、システムテストやユーザテストでは、外部設計や要件定義などの上流工程に対応した検証を行うことが目的となるはずです。したがって、単体や結合テストでの取りこぼしが少なければ、単体・結合テストにおける障害発生傾向とシステムテスト・ユーザテストの障害発生傾向が異なるのは当然のことです。（※２）

そのようなときに品質状況を「見える化」するための有効なツールが「品質マップ」です。あまり耳慣れない言葉かもしれませんが、そんなに難しいものではありません。システム全体の中でどの辺に品質の弱点があるのかを、たとえば図１に示すように、障害が摘出された機能とその障害事象がどの品質特性に関するものかをマトリクス表で表したものです。（※３）

図1では、11/9から11/13の１週間に摘出された障害の件数を機能と品質特性のマトリクス表にマッピングしています。あまり障害が摘出されていない（０～１件）箇所をグリーン表示、そこそこ摘出されている（２～４件）箇所をイエロー表示、かなり摘出されている（5件以上）箇所をレッド表示として、どの辺が品質に問題があるかを浮き彫りにしようとしています。

この例では、Ｃ機能に障害の摘出が集中していること、合目的性、使用性に関する障害が多く摘出されていることを読み取れます。品質向上のポイントとしては、Ｃ機能を徹底的に見直しするのはもちろんのこと、要件定義や外部設計において、しっかりとユーザ要件が反映されているかを見直しする必要があることが明確になります。

この「品質マップ」を週次など定期的に更新していくことで、システム全体の中で品質の弱点がどの辺にあるかを時系列に追跡することができます。もちろん、システムテストやユーザテストは、テストシナリオにもとづくテストを実施することが多いので、シナリオの内容によっては、実際に動作する機能の時期にばらつきが出ることにより、「品質マップ」の更新サイクルが短い場合には、「品質マップ」が実際の品質状況と少しずれてしまうということもありえます。（※４）

しかし、システム開発の仕上げともいえるシステムテストやユーザテストのシナリオにあげられる機能は、本番稼働後も重要な機能である可能性が高いので、本番稼働までの限られた期間やリソースを優先的に投入するためにも、このような「品質マップ」による品質弱点分析は有効だと考えられます。（※５）

【　分析の軸を変えた「品質マップ」　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
「品質マップ」は、その名前からして、システム全体の「どの辺に」品質の弱点があるか、冒頭で触れた防災マップやハザードマップと同様、弱点の場所を示すのが目的です。防災マップやハザードマップは、経度と緯度という二次元で示される地図上に、災害の発生しやすい場所を色や記号でマーキングすることで、危険地域を「見える化」します。図１で示す「品質マップ」は、機能と品質特性という二次元の表で品質の弱点を「見える化」しましたが、二次元の表の縦横の軸を変えることで、いろいろな角度で品質状況を分析することが可能になります。

図２は、障害種別と障害が作り込まれた工程のマトリクス表に、障害摘出件数をマッピングしたものです。工程別に見ると、外部設計起因の障害数が突出していますが、内部設計起因、コーディング起因の障害件数もそれなりに多く、作り込み工程別の障害発生件数だけでは、どの工程に焦点を当てて品質向上を実施すべきかぼやけてしまいます。

ここに障害種別の軸を追加して二次元の表にすると、エラー処理はどの工程を通じても考慮が不足していますが、それ以外は外部設計のインターフェース不良が突出していることを除き、品質状況はそれほど大崩れしていないことが見えてきます。

本番稼働までの期間やリソースも限られていていることを考えると、最優先は外部設計のインターフェース見直しに重点を置き、エラー処理については、システムダウンやエンドユーザ影響につながるようなシビアな障害発生防止に絞るなど、ポイントを絞った品質向上策を実施することが可能になるはずです。

前回のブログ　【第６３回】１０倍返しだ！品質保証部門の逆襲　でご紹介した品質保証部門が、製品検査で摘出した障害を「品質マップ」化することで、開発部門に対して客観的に品質の弱点を示すという使い方も効果的です。

ここで、「品質マップ」を用いた品質状況の「見える化」のポイントを整理します。

＜　「品質マップ」による品質状況「見える化」のポイント　＞

１．単体、結合テストがひと段落し、システム全体の品質を評価できるようになった時点を起点として作成します。

２．機能×品質特性など、品質を分析する二つの切り口を二次元の表にして、一定期間内に発生した障害件数をマッピングします。

３．「品質マップ」を一定期間ごとに更新し、障害発生件数の変化を時系列に追跡することで、品質の弱点が浮き彫りになります。

４．単体、結合、システムテストを通じたバグ密度などによる定量的品質評価と「品質マップ」による評価を重ねることで、より立体感を持たせることができます！
（どちらの分析結果も同じ傾向を示していれば、分析結果の正しさが証明できます）

「品質マップを活用したシステム全体の品質状況見える化で、品質向上の効率化を図ろう！」

【　システムテスト前に作る「システム疎通状況マップ」　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
「品質マップ」はシステム全体の品質状況を「見える化」するツールですが、システムテストの前にサブシステム間のインターフェースの疎通状況を「見える化」した「システム疎通状況マップ」を作ることもあります。

システムテストでは、本番業務を意識したテストシナリオに基づき、システム全体を対象にした検証を行うため、構築した全てのサブシステムがつながった状態である必要があります。その状態をシステムテスト開始前に実現するため、全てのサブシステム間のインターフェース疎通確認を完了させておく必要があるのです。しかし、大規模システム開発の場合、サブシステムごとに開発ベンダーが異なっていたり、新規開発したサブシステムと接続する予定の現行システムの有識者がアサインできない場合など、思うように疎通が進まないケースもあります。

そのため、システムテスト開始の必須条件となるサブシステム間のインターフェース開通状況をハイウエイ渋滞情報マップのように「見える化」することで、関係者間で共有し、必要に応じて課題対策の迅速化を図るために活用するのです。

図３は、システム全体図に対して、サブシステム間のインターフェース開通が完了した箇所にグリーンで「ＯＫマーク」、障害などで開通していない箇所にレッドで「NGマーク」、まだ疎通テストを開始していない箇所に「未実施マーク」を記載することで、システム全体の疎通状況の「見える化」を図っています。

システム間インターフェース一覧などの表形式で疎通状況を管理するというやり方ももちろんありますが、プロジェクトが終盤を迎えた段階で、プロジェクトメンバーのモチベーションを高め、ベクトルを統一するための演出として、「システム疎通状況マップ」を作成し、プロジェクトルームに張り出すことも効果的だと思います。（※６）

それでは次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～

※１　「ハザードマップ」『フリー百科事典　ウィキペディア日本語版』
2013年7月28日 (日) 08:45 utc https://ja.wikipedia.org/wiki/ハザードマップ

※２　Ｖ字モデルについては、当ブログの以下の回も参考にしてください。
・【第５３回】仕様変更と設計不良のグレーゾーンのさばき方

※３　いわゆる「JISの品質特性」については、以下参照。
・「ISO 9126」『フリー百科事典　ウィキペディア日本語版』
2014年7月16日 (水) 13:57 utc https://ja.wikipedia.org/wiki/ISO_9126

※４　テストシナリオやユーザテストは本番業務の年間運用サイクルなどを考慮して組み立てることが多いと思います。そのため、たとえば日次処理はテスト期間中毎日実行されるが、年次処理はテスト期間を通じて数回しか実行されないなど、実行回数にばらつきが生じることになります。

※５　システム開発の限られた期間やリソースの有効活用（優先順位づけ）に関しては、当ブログの以下の回も参考にしてください。
・【第３９回】トリアージでデスマーチを脱却せよ！
・【第４０回】膨張するプロジェクトとトリアージ依存症

※６　プロジェクトメンバーをその気にさせる演出については、当ブログの以下の回も参考にしてください。
・【第５７回】プロジェクトの成功を演出せよ！
・【第５８回】ピグマリオン効果と席替え大臣