概要
品質管理などでは、特性要因図がよく用いられる。特性とその特性に対して影響を与える要因との関係を階層的に整理するための図式が特性要因図である。今回は、特性要因図とゴールグラフとの関係について考えてみよう。
特性要因図
特性要因図では、まず特性を大骨で示す。次に特性に対する要因を中骨、中骨に対する要因を小骨という風に段階的に詳細化していく。このため特性要因図を魚の骨図(フィッシュボーンチャート)ともいう。特性要因図の構成要素を表1に示す。
特性要因図の例
ISO9126ソフトウェア品質特性に対する特性要因図の記述例を図1に示した。
ソフトウェアの品質の特性は、以下のように分類される(JIS X 0129)。
(1)信頼性:
指定された達成水準を維持する特性。副特性には成熟性、障害許容性、回復性がある。
(2)保守性:
修正のしやすさに関する特性。副特性には分析容易性、変更容易性、安定性、試験容易性がある。
(3)移植性:
ある環境から他の環境に移すための特性。副特性には成熟性、障害許容性、回復性がある。
(4)効率性:
使用する資源の量に対比して適切な性能を提供する特性。副特性には時間効率性と資源効率性がある。
(5)機能性:
明示的及び暗示的必要性に合致する機能を提供する特性。副特性には合目的性、正確性、相互運用性、セキュリティがある。
(6)使用性:
理解、習得、利用でき、利用者にとって魅力的である特性。副特性には理解性、修得性、運用性、魅力性がある。
特性要因図では、このように主特性と副特性の関係を表現することができる。また特性要因図では、大骨として問題や課題を対応させることで中骨や小骨で大骨に対する原因や対策を段階的に分析することもできる。たとえば、ソフトウェアの設計ミスに対する特性要因図の例が文献[1]にある。
ここでは、図2のようなマツダのロードスターのデザインで用いられた「人馬一体」を大骨とする特性要因図の例を示そう。この例は、イノベータの条件を豊富な事例に基づいて整理している「イノベーションの作法-リーダーに学ぶ革新の人間学」[2]のロードスターの事例から作成した。この本の冒頭に出てくるマツダのロードスターの事例は、「人馬一体」を実現するという強い信念で1人の技術者が、孤立無援の状態から徐々に支援者を得て会社を救う物語だ。図2は筆者がこの事例を参考にして描いたものであり、当然実際に用いられたロードスターの特性要因図[3]とは異なることを注意しておく。
図2 マツダ・ロードスターの特性要因図の例
さて、この図から次のようなことが分かる。ロードスターが目標とする「人馬一体」を実現するためには、緊張感、走り感、ダイレクト感、爽快感が重要だ。緊張感を実現するためには、全体レイアウト、デザイン処理、パワープラントおよびシャーシでどうすればいいかを検討する必要がある。このため全体レイアウトのデザインでは、スポーツカーとしての乗降性、あえて狭い居住性、運転席からの視界などが検討されたのである。
この図で分かるように、特性要因図では、最終目標としての「人馬一体」感を達成するために検討すべき課題を段階的に具体化できるのである。
ゴールグラフと特性要因図
特性要因図では、主特性を副特性に段階的に展開できると述べた。ということは、ゴールをサブゴールに段階的に展開するゴールグラフと同じ構造を特性要因図が持つということである。実際に、大骨をゴール、中骨をそのサブゴール、小骨をサブゴールのサブゴールというように対応付ければ、特性要因図からゴールグラフを作成できる。
たとえば、ロードスターの例に対して、このように対応付けられたゴールグラフを図3に示す。
図3 ロードスターの特性要因図に対するゴール木の例
ところで、このゴールグラフを良く見ると、「緊張感」などの乗車時のドライバーの心理状態の性質に関するゴールと「デザイン処理」などの車を実現する上でのプロセスや、「あえて狭い居住性」というようなデザイン上の意志決定が混在していることが分かる。
そこで、次に、NFRフレームワーク[4][5]を用いて、この点についてどうすればいいか考えてみよう。まず、NFRフレームワークを紹介しよう。
- 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:保証ケース作成支援ツールの概要