NTTデータ
技術開発本部
副本部長
山本修一郎
概要
前回はゴールドラットによる制約理論[1]と論理思考プロセス[2]の概要を紹介した。また現状分析ツリーについて述べ、事例を紹介した。今回は何を何にどのように変えるのかという「何に」の部分について解説する。まず対立解消図を紹介し、立場の違いからどんな対立が発生しているかを調べる。次いで、現状分析ツリーの問題点を用いて好ましい結果を探す未来実現ツリーを説明する。未来実現ツリーでは、新たな行動から派生する悪影響を探し出して対処するために、ネガティブ・ブランチを作成する。最後にネガティブ・ブランチとその対処策としてのインジェクションを未来実現ツリーに追加することにより、「何に変えるのか」の定義が完成する。問題分析ツリーで発見した課題に対して、それを解決する方法を発見するのが対立解消図だとすると、選択した新たな行動に対して想定される悪影響も考慮して、何をなすべきかを具体化するための手法が未来実現ツリーなのである。
ゴールドラットの論理思考プロセスの概要
論理思考プロセスを復習しておくと次のようになる。
問1 何を変革するのか?
現状分析ツリーを用いて、現状の問題点とその根本原因との因果関係を論理的に分析する。
問2 何に変革するのか?
まず、対立解消図を用いてゴールやゴール達成の要件と要件の前提の相互関係を分析することにより、前提間の対立を解消するインジェクションを発見する。次に、インジェクションと因果関係に基づいて、想定される好ましい結果とネガティブ・ブランチの可能性を明らかにする。さらに、ネガティブ・ブランチを用いて最悪の事態を予測し、それに対するインジェクションを考案する。最後にネガティブ・ブランチを未来実現ツリーに追加する。
問3 どのように変革するのか?
前提条件ツリーを用いて、最終目標と障害や中間目標としての行動の時間的な依存関係を具体化する。また移行ツリーを用いて、どのように変革を完成するかを示す行動の時間的な順序関係を具体化する。
今回は第2の問いに答えるための手法を説明する。
対立解消図
対立解消図の構成要素には①目的、②要求、③前提、④インジェクションがある。異なる立場の要求に対して共通する目的があるはずである。一方、立場によって要求の前提条件が対立することがある。この対立を解消するためのアイデアを発見することが、対立解消図の目的である。対立解消図は「雲」とも呼ばれる。現状のシステムが持つ雲(前提間の対立)を晴らすために、対立解消図を作成するのである。
また、構成要素間の関係には因果関係、インジェクション関係と対立関係の3つがある。
表1に対立解消図の構成要素をまとめておく。
◆因果関係
因果関係では、目的、要求、前提の論理的な関係を定義する。また同じ前提から対立していた前提の要求が、インジェクションにより論理的に導かれることも因果関係で表す。
◆インジェクション関係
要求と前提の因果関係を修正するために、必要となる前提に隠された仮定を否定するアイデアをインジェクションという。インジェクションと要求と前提の因果関係との関係をインジェクション関係という。
◆対立関係
異なる立場によって、2つの前提が互いに対立することを対立関係で表す。
対立解消図の作成プロセス
対立解消図では、次の2つの問に答える必要がある。
- 問1
- 前提条件の対立がどんな望ましくない影響をもたらすか?
- 問2
- 望ましくない影響を防ぐためにどのような方法があるのか?
対立解消図の作成プロセスを表2に示す。
まず手順1から手順3までで、対立する前提条件から望ましい要求と対立しない共通の目的を探索する。次いで手順4から手順6で、対立を解消するためのインジェクションを発見するのである。このように対立を生じさせている要求の目的を探すことで、変更可能な仮定や暗黙の条件を明らかにするための手がかりを見つけることができる。
【手順1】対立を明確に表現する
対立する立場に着目することにより、対立する前提を表現する。
【手順2】要件を決める
対立する前提から生じる要望を記述する。
【手順3】目的を見つける
対立する前提から導かれる異なる要求に共通する対立しないひとつの目的を明らかにする。
【手順4】雲を洗練する
次の条件を確認することにより、要求や前提を見直す。
- 条件1
- 「目的」のために2つの「要求」がそれぞれ必要であること
- 条件2
- 「要求」のために「前提」が必要であること
【手順5】仮定を明確化させ否定可能な仮定を見つける
要求のために前提が必要であることを主張するための根拠となる仮説を明確にすることで、必ずしも成立させる必要のない仮説を抽出する。この仮説を否定することにより、対立を解消できる可能性がある。
【手順6】インジェクションにより前提を置き換える
対立していた前提を変更するアイデアとしてのインジェクションを要求と前提の関係に追加することで、現状のシステムを変える解決策を提示する。
■望ましくない影響を防ぐためにどのような方法があるのか?
作成手順 | 留意点 | |
---|---|---|
1 |
対立を明確に表現する | 対立する立場に着目することにより,対立する前提を表現する |
2 |
要件を決める | 対立する前提から生じる要望を記述する |
3 |
目的を見つける | 対立する前提から導かれる異なる要求に共通する対立しない ひとつの目的を明らかにする |
4 |
雲を洗練する | 次の条件を確認することにより,要求や前提を見直す 「目的」のために2つの「要求」がそれぞれ必要であること 「要求」のために「前提」が必要であること |
5 |
仮定を明確化させ否定可能な仮定を見つける | 要求のために前提が必要であることを主張するための根拠となる仮説を明確にすることで,必ずしも成立させる必要のない仮説を抽出する.この仮説を否定することにより,対立を解消できる可能性がある |
6 |
インジェクションにより前提を置き換える | 現状のシステムを変える解決策のアイデアとしてのインジェクションを要求と前提の関係に追加することで,対立していた前提を変更する |
上勝町の対立解消事例
前回と同じ徳島県上勝町(かみかつちょう)の町おこしの事例[3]について、対立解消図を作成してみよう。上勝町はミカン以外に産業のない山間の過疎と高齢化に悩む町だったが、「葉っぱ」をビジネスにすることで、活性化に成功したことで有名になった。
何が上勝町の対立する雲だったのか?高齢者しかいない山間の町では、資源は自然しかなく、また、商品を生産するための技能がないということと高齢者が生きがいを持つためには、働くことが必要だということが対立していたと考られる。徳島県上勝町の雲を図1に示す。
図1 徳島県上勝町の雲
目的は「地場産業を創出して地域を活性化したい」ことにある。
第1の要求は「町の予算執行を健全化する」ことで、その前提には「町の支出を削減する」ことがあげられる。
第2の要求は「町民の生きがいを増進する」ことで、その前提には「高齢者が従事できる事業を創出する」ことがある。
ここでの対立は「高齢者が従事できる事業を創出する」ためには事業予算が必要だと考えられるのに、「町の支出を削減する」必要があることだ。
ところが山ならどこにでもある「葉っぱ」を、料亭などで添えられる「つまもの」として商品化することで、すべてが好転する。商品を、技能や特別な資源や投資がないと生産できないと思い込んでいたことに対立の原因があったのだ。前提間の対立を解消するインジェクションは「葉っぱを事業資源にする」ことだ。上勝町の対立解消図の例を図2に示した。
図2 徳島県上勝町の雲とインジェクション
- 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:保証ケース作成支援ツールの概要