NTTデータ
技術開発本部
副本部長
山本修一郎
移行ツリーの構成要素
移行ツリーの構成要素は、現実、ニーズ、期待される結果と具体的なアクションである。
移行ツリーの関係は結果を親節点としニーズ、現実、アクションをその子節点とする基本関係だけである。
移行ツリーの基本関係により、ニーズと現実に対してアクションを実行することで期待する結果を導けることを表すのである。
移行ツリーの作成プロセス
移行ツリーの作成では、次の2つの問に答える必要がある。
- 問1 最終目標(中間目標)は何か?
問2 ニーズ、現実から目標(期待する結果)を導くためにどのような方法(アクション)があるのか?
まず第1の問に答えるために前提条件ツリーの最終目標や中間目標を利用することができる。次に段階的に手順2と手順3を適用することですべての現実、ニーズアクションを抽出する。最後にこれらの構成要素を相互に関係付けることにより移行ツリーを完成させる。
【手順1】最終目標と最初のアクションを決める
前提条件ツリーの最終目標と中間目標を移行ツリーの結果として配置する。
【手順2】最下位の中間目標について必要となるニーズ、現実、アクションを抽出する
下位の中間目標を生成するために必要なニーズ、現実、行動を記述する。
【手順3】最初の中間目標に先行するすべての現実、ニーズ、アクションを抽出する
最下位のアクションの実行可能性を確認することで先行関係の妥当性を評価する。
【手順4】移行ツリーを完成する
最下位の結果から中間目標に向けて論理関係を作成することにより、最終目標までの移行ツリーを構築する。
作成手順 | 留意点 | |
---|---|---|
1 |
最終目標と最初のアクションを決める | 前提条件ツリーの最終目標と中間目標を移行ツリーの結果として配置する |
2 |
最下位の中間目標について必要となるニーズ、現実、アクションを抽出する� | 下位の中間目標を生成するために必要なニーズ、現実、行動を記述する |
3 |
最初の中間目標に先行するすべての現実、ニーズ、アクションを抽出する | 最下位のアクションの実行可能性を確認することで先行関係の妥当性を評価する |
4 |
移行ツリーを完成する | 最下位のニーズと現実、結果から中間目標に向けて基本関係を反復的に作成していくことにより、最終目標までの移行ツリーを構築する |
上勝町の移行ツリーの例
徳島県上勝町の前提条件ツリーに基づいて作成した移行ツリーの例を図2に示した。
移行ツリーの目的は段階的な実行計画を明らかにすることである。移行ツリーのアクションは実行すべき行動である。これに対して未来実現ツリーのインジェクションは達成すべき課題である。
ゴール指向と論理思考プロセス
Lamsweerdeによれば、システム開発の目標としてのゴールを構造的に明確化することに基づいてシステム要求を定義することがゴール指向の基本的な考え方である[4]。たとえば、ゴールは上位レベルの戦略的な関心事から下位レベルの技術的な関心事へ段階的に構成される。つまりゴールを目標から手段へ階層的に展開することにより、システム要求を論理的に理解しやすい形で構造化するのである。このように階層的に詳細化されたゴールグラフの最下位のゴールがシステム要求になる。
またゴールは機能要求だけでなく、サービス品質やソフトウェア属性としての安全性、セキュリティ、正確性、性能などの非機能要求も表現できる。
上位レベルのゴールでは、人間やデバイス、環境等の振る舞いを伴うアクタとシステムとの協調動作を扱う必要がある。したがって、このような上位のゴールを達成するには異なるアクタが互いに協調することが必要となる。
これまで見てきたように、ゴールドラットの論理思考プロセスでは現状の問題は何か?ゴールとは何か?ゴールを達成する実行手段はどのようになるのか?について具体的な手順を明らかにしている。したがって論理思考プロセスをゴール指向手法であると見ることもできる。たとえば、未来実現ツリーではゴールグラフと同じようにAND関係やOR関係を用いてゴール間の論理的な関係を明確にすることができる。
また、ゴール指向ではゴール間の対立を貢献度によって表現しておき、優先順位付けることでゴール間の対立を解消する。これと同じように、論理システム思考では対立解消図を用いてゴールの前提間の対立を表現することで、対立を解消する方法を考えることができる。
なおゴール指向手法のゴールグラフでは、現状分析ツリーの悪循環ループや未来実現ツリーの好循環ループなどを表現しないことを注意しておく。
論理システム思考ではアクタを明確に表現する図式表現は用意されていない。したがってアクタ間の依存関係についても表現できないので、組織構造やビジネスプロセスを検討する場合には、iスターフレームワーク[5]のようなゴール指向手法と組み合わせる必要があると思われる。たとえば、アクタ間で相手に何を期待しどんな義務があるのかなどを、アクタ間の依存関係として表現できない。あえて記述するとすれば、「アクタに対して何を期待する」というような文章でゴールを表現することになる。
一方、ゴール指向手法では現状の問題構造をゴールグラフで表現することはなく、あるべきゴールの構造を表現するので、現状分析ツリーや望ましくない影響を記述するネガティブ・ブランチなどは論理システム思考が優れている点であると考えられる。
論理システム思考は、基本的に人間活動をどのように変革するかという手法であり、システム要求を対象にしているわけではないので、論理システム思考が扱うゴールはすべて人間活動に対するソフトゴールである。もし論理システム思考をシステム要求の定義に使うとすれば、人間活動の分析と新たなビジネス活動の定義になるだろう。そのビジネス活動の中でITを活用する人間活動をどう具体化するかについては、ゴール指向要求工学の手法を利用することができる。
まとめ
これまで3回にわたって、論理思考プロセスを説明してきた。今回はゴールドラットによる論理思考プロセスの前提条件ツリーと移行ツリーについて述べ、事例を紹介した。生産管理論で周知の論理思考プロセスが、要求工学におけるゴール指向手法と非常に近い関係にあることがご理解いただけたのではないかと思う。両者を組み合わせることで生産活動と調和したITのあり方も容易に具体化できる可能性があると考えられる。
ところで、ソフトウェアシンポジウム2007[6]では、私と立命館大学の大西淳教授がオーガナイザになって「要求工学ワークショップ」(WS3)を企画している。ワークショップの司会は九州工業大学の橋本正明教授だ。実は、制約理論とゴール指向手法の類似性を私に指摘してくださったのは橋本教授だ。この指摘がなかったら論理思考プロセスを紹介することもなかったかもしれない。
さて、このワークショップでは、併設チュートリアル「非機能要求とアーキテクチャ」を企画していて、羽生田栄一さんに発表をお願いしている。このチュートリアルでは私も参加しているソフトウェアエンジニアリングセンターでの「非機能要求とアーキテクチャ」の活動内容を紹介してもらうことになっている。
ワークショップの目的は、システム要求の作成に携わる実務者と要求工学の研究者による相互交流の場を提供することにより、システム要求を作成する上での経験や知見の共有を図ることだ。したがってワークショップの実施にあたっては、参加者によるポジションペーパの発表と討論を通じて、要求工学の課題を具体化するとともに今後のあるべき方向を探りたいと考えている。
ぜひ、この連載をご覧になっている皆さんと私も議論したいので、ふるってポジションペーパの投稿をお願いしたい。申し込みの締め切りは3月31日だ。
■参考文献- [1]エリヤフ ゴールドラット著、三本木 亮 訳、ザ・ゴール ― 企業の究極の目的とは何か、ダイヤモンド社 、2001
- [2]H.ウイリアム デトマー著、内山 春幸、 中井 洋子訳、ゴールドラット博士の論理思考プロセス―TOCで最強の会社を創り出せ! 同友館、2006
- [3]朝日新聞、葉っぱで年商2.5億円、地域に生きて、新商売、2006、11月27日朝刊
- [4]Axel van Lamsweerde, Goal-Oriented Requirements Engineering: A Guided Tour,Proceedings RE’01、5th IEEE International Symposium on Require- ments Engin- eering,pp.249-263,2001.
- [5]i* homepage, http://www.cs.toronto.edu/km/istar/.
- [6]ソフトウェアシンポジウム2007, http://www.rewg-jp.mydns.jp/
- 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:保証ケース作成支援ツールの概要