NTTグループのソリューションガイド

ICTソリューション総合誌 月刊ビジネスコミュニケーション

ビジネスコミュニケーション
第131回 保証ケース導入上の課題国立大学法人 名古屋大学 情報連携統括本部 情報戦略室 教授 山本修一郎

国立大学法人 名古屋大学 情報連携統括本部 情報戦略室 教授
(前NTTデータ フェロー システム科学研究所長)山本 修一郎

先日、保証ケースの導入を考えている品質保証部門の方々と意見交換した。そこで、保証ケースの適用分野、効果事例、普及促進の考え方という3つの質問をいただいた。この背景には、「上流工程での合意形成がうまくいかないことへの対策として、保証ケースを適用できるのではないか」という問題意識がある。

本稿では、これらの質問に基づいて、保証ケースをプロジェクトに導入する上での課題について考察することにしよう。

保証ケースの連載記事

これまで、本連載で扱った保証ケース関連記事を表1にまとめる。本稿も含めると記事数は20である。131回のうちの20回なので、本連載の15.3%が保証ケース関連の記事になったことになる。

この表から分かるように、プロジェクト管理と保証ケースについては、これまで言及してこなかった。連載94回では、保証ケースの落とし穴について説明して、表記法の課題についての考え方を紹介した。しかし、プロジェクトへの適用上の課題については、まとめていなかった。以下では、保証ケースをプロジェクトに導入する上での問題に対する考え方を説明しよう。

表1 保証ケース関連記事一覧(クリックで拡大)

表1 保証ケース関連記事一覧

導入に前向きな組織とは

保証ケースの導入に前向きでない組織は、プロジェクトが失敗しないと思っていることが多い。これに対して、保証ケースの導入に前向きな組織の場合、プロジェクトが失敗するリスクがあることを前提にして、リスクを識別するとともに、リスク対策が適切であることを確認しようとしている。プロジェクトが失敗しない根拠を明らかにする手段が保証ケースである。

プロジェクトが失敗する3大要因は、コミュニケーション不足、要求爆発、不十分なプロジェクト管理である。保証ケースを活用することで、コミュニケーションの主題、ゴール要求、プロジェクト管理ゴールであるQCDについて合意形成を支援できることから、プロジェクト失敗要因への対策として保証ケースが有効であることが分かる。

次の問題は、プロジェクトへどのようにして保証ケースを適用すればいいかという具体的な施策を明らかにすることである。たとえば、プロジェクトへ保証ケースを導入する場合の留意点として、以下がある。

すなわち、開発プロセスとかい離した状態で保証ケースが適用される場合、プロジェクトの状況に合わせて保証ケースを適用できるように、開発手法のカスタマイズが必要である。しかし、保証ケースの専門家でないと、開発プロセスのカスタマイズが困難である。この問題を解決するためには、保証ケース手法のカスタマイズのためのガイダンスが必要である。また、プロジェクトの状況に応じた専門的な保証ケースの訓練が必要である。

保証ケースの適用分野とは

保証ケースがうまく適用できる分野とそうでない分野の差異として、どんなことが考えられるのだろうか?この問いに対する回答は、開発対象分野の差よりも、プロジェクトのあり方によってうまく適用できるプロジェクトとそうでないプロジェクトが決まるということである。

保証ケースを作成するためには、①主張、②成果物の構成、品質特性、品質基準などの前提、③証拠をそろえる必要がある。主張では、成果物の構成要素やその関係について必要な原則・品質基準を満たすことを明記する。証拠は、主張が達成できることを示す客観的な事実についての文書である。

これらがそろっていなければ保証ケースを作成することはできない。驚くべきことに、これまで筆者が聞いた範囲では、上流成果物に対して品質原則や品質基準を明確に定義している品質保証部門は、大手も含めてどこもない。品質原則やシステム成果物の構造が明確になっていないと、保証ケースを作成できないことは明らかだ。したがって、まず、システムの構成(アーキテクチャ)や品質原則を明確に定義する必要がある。また、安全性などは原則化しやすく、操作性は原則化しにくいのではないか、したがって、関心のある品質特性分野によって保証ケースの得意分野が変化するのではないということも幻想である。安全性原則を明確に定義している企業は少ない。同様に操作性原則を定義している企業も少ない。また、現行システムのアーキテクチャや品質原則・設計原則が暗黙知化していて手が付けられない、という話をよく聞く。

いずれにしろ、このようにアーキテクチャや原則が明確に定義できないのであれば、日本国内のプロジェクトに保証ケースを適用することはできない。保証ケースが支援するのは論理的な説明方法であって、アーキテクチャや品質原則を定義することではない。

保証ケースの得意分野と不得意分野について上述したことを表2にまとめる。

保証ケースの手間はどうか

定量的に保証ケースの作成工数を評価した研究は少ない。名古屋大学で実施した評価実験では、保証ケースの適用工数について、以下の結果を得ている[1、2]

[事例1]仕様書の適切性の保証工数[1]

システム仕様が与えられた場合、①仕様を理解、②データフロー図(DFD)を作成してリスク分析を実施、③保証ケースを用いてリスク対策を確認という手順で、仕様の適切性を保証した。この事例の場合、図1に示すような工数の内訳となった。仕様理解が11%、DFDに基づくリスク分析と保証ケース作成が同じく43%、保証ケース研修が3%であった。

[事例2]テスト十分性の保証工数[2]

システム要求に対して、①要求定義カードを作成、②要求の逸脱分析を実施、③例外試験項目を作成、④保証ケースを作成、⑤保証ケースを用いてテスト十分性について合意という手順で、例外テストの十分性を保証した。この手法は、本連載第108回「要求に基づくテストの十分性」で紹介した内容である。

この事例の場合、図2に示すような工数の内訳となった。要求定義が42.7%、逸脱分析が27.2%、例外試験定義が1.4%、保証ケース作成が10.8%、合意形成が17.9%であった。事例2では、保証ケース知識を持つ担当者が実施したため、研修工数は計測していない。

表2 保証ケースの得意分野と不得意分野(クリックで拡大)

表2 保証ケースの得意分野と不得意分野


続きは本誌でご覧頂けます。→本誌を購入する
ご購入のお申込みは電話(03-3507-0560)でも承っております。

第59回以前は要求工学目次をご覧下さい。


会社概要 NTT ソリューション 広告募集 ページ先頭へ
Copyright:(C) 2000-2017 BUSINESS COMMUNICATION All Rights Reserved. ※本サイトの掲載記事、コンテンツ等の無断転載を禁じます。

【PR】

ピンポイントプライベートセミナー 企画、集客のご案内