NTTデータ
技術開発本部
副本部長
山本修一郎
現状分析ツリーの作成プロセス
現状の問題点とその根本原因との因果関係を論理的に分析する手順1と手順2ではエンティティを抽出することにより現状分析ツリーの作成を準備する段階だ。手順3でエンティティ間の因果関係を分析してツリーを作成する。手順4では、作成した現状分析ツリーに抜けがないことを確認する。手順5では現状分析ツリーの中で何が根本原因なのかを明らかにする。
作成手順 | 説明 |
---|---|
ゴールを抽出する |
■システム境界とゴールを抽出する |
■システムの問題を宣言する | |
好ましくない結果を見つける |
■原因,マイナス面,理由を列挙する |
■分析ツリーの構成要素(エンティティ)に変換する | |
■好ましくない結果(UDE)を決める | |
問題間の関係を分析する |
■エンティティをグループ化してクラスターを構成する |
■クラスタ内を関連付ける | |
■クラスタ間を関連付ける | |
■因果関係を検証してツリー化する | |
別の問題がないことを確認する |
■別の原因を探す |
■下向きにツリーを展開する | |
■好ましくない結果を見直す | |
問題の根本原因を見つける |
■悪循環ループを探す |
■すべての根本原因と核心問題を見つける | |
■本質的でないエンティティを削除する | |
■取り組む根本原因を選ぶ.選ばれた根本原因が制約条件である |
【手順1】ゴールを抽出する
・システム境界とゴールを抽出する。
たとえば、「ある地方都市を活性化するシステム」はシステム境界の例である。
ゴールは「住民が生きがいを持つ町づくりシステム」。システムには情報システムだけでなく人間活動も含めることができる。
・システムの問題を列挙する。
たとえば、「このシステムのどこが良くないのか?」を考えることでシステムの問題点を抽出していく。
【手順2】好ましくない結果を見つける
まず抽出した問題点に対して、その原因、マイナス面、理由を列挙する。
次に、このようにして抽出した原因、マイナス面、理由を分析ツリーの構成要素(エンティティ)とする。
さらに、これらのエンティティの中から、好ましくない結果(UDE)を決める。ここで理由に基づいて作成されたエンティティを好ましくない結果の候補とする。原因よりもその理由の方がより好ましくないことを説明している上位の概念となるからである。
【手順3】問題間の関係を分析する
エンティティ間の因果関係を次の4ステップで作成する。
まず、関連するエンティティをグループ化してクラスターを構成する。
次に、クラスター内のエンティティ間を因果関係により関連付ける。
さらに、クラスター間を関連付けるために、クラスターの境界にあるエンティティ間の因果関係を確認する。
最後に因果関係に基づいてエンティティを関係づけることで現状分析ツリーを構成する。
この手順はあくまでも大まかな分析の流れを示したものである。実際にはこの手順のように直線的に因果関係が分析できるわけではなく、反復的に因果関係の付け直しや、新たな原因や、結果を追加、削除することが必要になるだろう。したがって、原因や結果を分割してクラスターを見直すこともあるはずだ。
【手順4】原因の抜けがないことを確認する
まず別の原因を探す。ここで、注目している結果が生じるのに現在の現状分析ツリーに現れている原因以外の原因を「別の原因」という。もし「別の原因」があれば、現状分析ツリーに追加して因果関係を見直す。
次に下向きにツリーを展開することにより、因果関係に抜けがないことを改めて確認する。
最後に、好ましくない結果を見直す。この理由は、現状分析ツリーが完成に近づくとともに最初に考えていた好ましくないと考えていた結果が重要でないことに気づく場合があるからだ。
【手順5】問題の根本原因を見つける
まず悪循環ループを探す。ここで、原因に基づく否定的な結果がその原因の新たな成立につながるとき、悪循環ループを構成するという。悪循環はその原因が解決されれば、逆に好循環に転換する可能性を持つので、改革の機会を発見する上で重要な意味がある。
次にすべての根本原因と核心問題を見つける。ここで、人が関与することによって解決できる原因を根本原因という。根本原因は改革によって変更できる原因である。人が関与できない原因を根本原因とは言わない。また好ましくない結果の大部分を引き起こすような根本原因を核心問題という。
また、根本原因の観点から見て本質的でないエンティティを削除する。
最後に、改革に取り組むために対象とする根本原因を選択する。選ばれた根本原因が制約条件である。
地域社会の問題分析事例
徳島県上勝町(かみかつちょう)の町おこしの事例[3]について、現状分析ツリーを作成してみよう。上勝町はミカン以外の産業のない山間の過疎と高齢化に悩む町だったが、葉っぱをビジネスにすることで、活性化に成功したことで有名になった。
何が上勝町の問題だったのか?何を変えることで上勝町は成功したのか?どのように改革することができたのか?
ここでは、論理思考プロセスの最初の問を考えよう。徳島県上勝町の現状分析ツリーを図1に示す。
図1 徳島県上勝町の現状分析ツリー
システム境界は、上勝町の地域社会だ。
ゴールは上勝町を活性化することだ。
地域社会(上勝町)を活性化できないことが好ましくない結果だ。
悪循環ループは事業を創出できないので、働き手が都会に流出し、住民が減少し、税収が減少するので、事業に従事する働き手もいなければ、事業投資する資金もない。したがってさらに事業を創出する機会が減少することになる。
根本原因は、上勝町には事業資源がないと思っていたことだ。山ならどこにでもある「葉っぱ」を料亭などで添えられる「つまもの」として商品化することで、すべてが好転したことから、理解できるだろう。イノベーションは技術開発だけではない。すでに存在するが顕在化していない価値を発見することでも創造することができるという例だ。
まとめ
今回はゴールドラットによる制約理論と論理思考プロセスの概要を紹介した。また現状分析ツリーついて述べ、事例を紹介した。
論理思考プロセスの6つの図式をシステムのasisとtobeという面と、whatとhowという面の2つの側面からまとめると、図2のような関係になるだろう。
図2 ゴールドラットの論理思考プロセス図式の関係
ゴールドラットによれば、現状を認識するだけではシステムを改革することはできない。論理的な因果関係を明らかにすることで、なぜ好ましくない結果が生じるのかを理解する必要がある。その上で好ましくない結果を導く根本原因を見つける必要がある。
現状のシステムの問題を改革するには、新たなイノベーションによって現状のシステムに関するできごとの因果関係を把握し、その根本原因を取り除くことができるようにシステムを再構築していく必要がある。
次回はゴールドラットの第2の問に対する手法を紹介しよう。現状分析ツリーに対して、問題を解決するための対立解消図や未来実現ツリーなどを紹介する。
■参考文献- [1] エリヤフ ゴールドラット著, 三本木 亮 訳、ザ・ゴール ― 企業の究極の目的とは何か、ダイヤモンド社 、2001
- [2] H.ウイリアム デトマー著, 内山 春幸, 中井 洋子訳、ゴールドラット博士の論理思考プロセス―TOCで最強の会社を創り出せ! 同友館、2006
- [3]朝日新聞、葉っぱで年商2.5億円、地域に生きて、新商売、2006,11月27日朝刊
- 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:保証ケース作成支援ツールの概要