(前NTTデータ フェロー システム科学研究所長)山本 修一郎
先日、保証ケースの導入を考えている品質保証部門の方々と意見交換した。そこで、保証ケースの適用分野、効果事例、普及促進の考え方という3つの質問をいただいた。この背景には、「上流工程での合意形成がうまくいかないことへの対策として、保証ケースを適用できるのではないか」という問題意識がある。
本稿では、これらの質問に基づいて、保証ケースをプロジェクトに導入する上での課題について考察することにしよう。
保証ケースの連載記事
これまで、本連載で扱った保証ケース関連記事を表1にまとめる。本稿も含めると記事数は20である。131回のうちの20回なので、本連載の15.3%が保証ケース関連の記事になったことになる。
この表から分かるように、プロジェクト管理と保証ケースについては、これまで言及してこなかった。連載94回では、保証ケースの落とし穴について説明して、表記法の課題についての考え方を紹介した。しかし、プロジェクトへの適用上の課題については、まとめていなかった。以下では、保証ケースをプロジェクトに導入する上での問題に対する考え方を説明しよう。
表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 保証ケースの得意分野と不得意分野(クリックで拡大)
続きは本誌でご覧頂けます。→本誌を購入する
ご購入のお申込みは電話(03-3507-0560)でも承っております。
- 60:要求とアーキテクチャ
- 61:要求と保守・運用
- 62:オープンソースソフトウェアと要求
- 63:要求工学のオープンな演習の試み
- 64:Web2.0と要求管理
- 65:ソフト製品開発の要求コミュニケーション
- 66:フィードバック型V字モデル
- 67:日本の要求定義の現状と要求工学への期待
- 68:活動理論と要求
- 69:ビジネスゴールと要求
- 緊急:今、なぜ第三者検証が必要か
- 71:BABOK2.0の知識構成
- 72:比較要求モデル論
- 73:第18回要求工学国際会議
- 74:クラウド時代の要求
- 75:運用要求定義
- 76:非機能要求とアーキテクチャ
- 77:バランス・スコアカードの本質
- 78:ゴール指向で考える競争戦略ストーリー
- 79:要求変化
- 80:物語指向要求記述
- 81:要求テンプレート
- 82:移行要求
- 83:要求抽出コミュニケーション
- 84:要求の構造化
- 85:アーキテクチャ設計のための要求定義
- 86:BABOKとREBOK
- 87:要求文の曖昧さの摘出法
- 88:システムとソフトウェアの保証ケースの動向
- 89:保証ケースのためのリスク分析手法
- 90:サービス保証ケース手法
- 91:保証ケースのレビュ手法
- 92:要求工学手法の再利用
- 93:SysML要求図をGSNと比較する
- 94:保証ケース作成上の落とし穴
- 95:ISO 26262に基づく安全性ケースの適用事例
- 96:大規模複雑なITシステムの要求
- 97:要求の創造
- 98:アーキテクチャと要求
- 99:保証ケース議論分解パターン
- 100:保証ケースの議論分解パターン[応用編]
- 101:要求発展型開発プロセスの事例
- 102:参照モデルに対する保証ケース
- 103:参SEMATの概要
- 104:参SEMATの活用
- 105:SEMATと保証ケース
- 106:Assure 2013の概要
- 107:要求の完全性
- 108:要求に基づくテストの十分性
- 109:システムの安全検証知識体系
- 110:機能要求の分類
- 111:IREB
- 112:IREB要求の抽出・確認・管理
- 113:IREB要求の文書化
- 114:安全要求の分析
- 115:Archimate 2.0のゴール指向要求
- 116:ゴール指向要求モデルの保証手法
- 117:要求テンプレートに基づく要求の作成手法
- 118:ビジネスゴールのテンプレート
- 119:持続可能性要求
- 120:操作性要求
- 121:安全性証跡の追跡性
- 122:要求仕様の保証性
- 123:システミグラムとドメインクラス図
- 124:機能的操作特性
- 125:セキュリティ要求管理
- 126:ソフトウェアプロダクトライン要求
- 127:システミグラムと安全分析
- 128:ITモダナイゼーションとITイノベーションにおける要求合意
- 129:ビジネスモデルに基づく要求
- 130:ビジネスゴール構造化記法
- 131:保証ケース導入上の課題
- 132:要求のまとめ方
- 133:要求整理学
- 134:要求分析手法の適切性
- 135:CROS法の適用例
- 136:保証ケース作成支援ツールの概要