NTTデータ
技術開発本部
副本部長
山本修一郎
概要
前回はチェックランドのソフトシステム方法論(SSM)[1]の基礎となる人間活動システムの基本定義や概念モデルについて説明した[2]。今回はSSMによるシステム分析プロセスの内容とその留意点を紹介しよう。
SSMの分析プロセス
【ステージ1、2】発見
SSMの最初のステージが問題の発見である。ステージ1で分析の対象となる問題状況を抽出し、ステージ2で問題状況を具体的に表現する。たとえば、どんな視点Wから見ると、その状況が問題となるのかを利害関係者に質問して記録する。(ここで、Wは「世界観」の略であるが、システムが何であるかという見方なので、世界観よりもやさしい言葉として「視点」を用いることにする。)この場合、基本定義や概念モデルを用いて問題状況を表現することもできる。ただし重要なことは構造化されていない問題状況を把握することであるので、基本定義や概念モデルの作成では、分析者の考え方や視点を過度に反映したモデルにならないように留意する必要がある。
また問題状況の中で変化しない静的な構造は何か、変化しやすい動的なプロセスは何か、そして両者の関係はどうなっているのかを考察することも重要である。チェックランドは構造とプロセスのこの相互関係を「状況の風潮」と呼んでいる。何が動いて、何が動かないのか、それを発見するのがこのステージだともいえよう。
【ステージ3】選択
選択ステージでは、望ましいシステムが「何であるか」を基本定義により記述する。システムへの入力を出力に変換する可能な「入出力変換」の候補を列挙し、その背景にある視点Wを考察することにより、基本定義を作成する。たとえば、バランス・スコアカードでは、財務、顧客、業務プロセス、学習と成長という4つの視点から、ビジネス活動のゴールを明確化する。この4つの視点はSSMのWであるといってよいだろう。ビジネス情報システムの要求定義では、顧客の視点は見落としやすいものである。
ステージ3で作成される基本定義は問題状況を改善するための仮説の集合であるといえる。この基本定義の分析法にはタスクに基づく方法と論点に基づく方法の2つがある。
◆タスク分析型基本定義
タスク型分析では、組織ごとに人間活動としてのタスクを分析するので、組織の境界と基本定義によるシステム境界が一致する。タスク型基本定義は、組織の使命や目標を表す。ただしタスク型分析では、組織活動を一般化しすぎてはいけない。具体的な組織の特徴が失われるので、深い分析のための意味のある情報が失われるからである。組織の現在の固有の状況を多様な視点Wから適切に捉えた基本定義を作成する必要がある。
◆論点分析型基本定義
論点型分析では、論点ごとに必要な人間活動を分析するので、組織の境界と、基本定義によるシステム境界が必ずしも一致しない。たとえば、「販売店の役割を明確化する」というような論点に対しては、このこと自体を目的にした組織が必ずしも存在するとは限らない。また組織横断的な取り組みも既存の組織活動には当てはまらない例である。
主要なシステムの候補が抽出できたら、CATWOE分析により基本定義に何が記述されているかを確認する。もしCATWOE分析によりある要素の抜けが検出できて、それを基本定義に補足することが必要だと判断されれば、基本定義を修正する。
【ステージ4】構築
構築ステージでは、基本定義ごとに概念モデルを作成する。システムが基本定義で記述されたものであるために、必要最小限の活動を動詞により記述し、活動間の論理的な関係を明らかにする。
概念モデルは階層的に詳細化することができる。すなわち上位の概念モデルに含まれるある活動の内容を具体化するために、複数の活動からなる概念モデルを用いて記述することができる。概念モデルの作成では、状況を認識するための活動、変換内容を実行する活動、活動を監視するために必要となる活動、各活動を制御するための活動の4つに分けて考えるといいだろう。ただし、概念モデルをこの4つの一般的な名前でそのまま作成してはいけない。
たとえば、次の基本定義に対する概念モデルの例を図2に示す。
図2 概念モデルの例
【基本定義】
A社が所有するシステム。従業員、株主および消費者の利益に注意を払うとともに、製品の原価率を最小化することによって、利益を確保し会社を持続させようとする。
図2では、分かりやすさのために、これら4活動を点線の矩形で明示したが、実際の概念モデルではこのような矩形は記述しないので注意が必要である。
基本定義に基づいて具体的な活動を概念モデルとして記述してみて、これらの活動に相当する活動が概念モデルの中に存在することを確認することで、抜けのない概念モデルを構築できるようになる。実際にはこれらの4種の活動のうち変換活動と制御活動の一部として他の活動が含まれる場合もあるかもしれない。
概念モデルを構成する要素としての活動の粒度については、基本定義に対する最初の概念モデルでは12個以上の活動を含めてはいけないという指針がある。この理由は、人間の知能は5~9個までしか一度に認識できないからというものだ。11個までになっているのは、活動の連続性を考慮して、多少は増えてもいいとしているためである。
【ステージ5】比較
比較ステージでは、基本定義と概念モデルを用いて表現されたシステムの有効性を、発見ステージで表現された問題状況に対して評価する。つまり、論理的なシステム思考の結果を現実の問題状況に対して有効であることを確認するのである。具体的には次に示すような手法を用いて、問題状況に対する基本定義と概念モデルの有効性を評価することにより、これらを反復的に修正していく。
◆組織の役割についての戦略的な議論
概念モデルの内容と想定される組織の役割について戦略的に議論する。
◆系統的な質問
概念モデルを構成する活動ごとに次のような系統的な質問をすることにより、活動の妥当性を確認していく。たとえば質問項目として、活動の存在性、現状の対処、活動の評価指標、変革案、活動の事実、変革案の有効性、他の活動との関係などが考えられる。これらの項目は問題状況とその対処を分析するためのFBCMの現場観察カードの項目と類似している[3]。現場観察カードでは、事実、問題、対処策、改善の機会、成功要因、KPI、関連組織を記入した。もし、問題状況を現場観察カードのような形でまとめておけば、概念モデルとの比較も容易になるだろう。
◆概念モデルにより一連のできごとを再現
問題が発生した過去のできごとを概念モデルを用いて再現してみることで概念モデルの妥当性を確認することができる。もし問題状況を改善できなければ、新たな活動が必要になる。ただし過去のできごとに係わった関係者を批判する手段だとみなされかねないので、この方法を用いるときにはそうならないように注意する必要がある。
◆asisモデルとtobeモデルの差異分析
実際の問題状況を忠実に反映したasis概念モデルをtobe概念モデルとの差異を分析することにより、この2つのモデルの違いを明確化する。
各手法の内容を見れば分かるように、どれか一つを選択して比較するというよりも、複数の手法を組合せて、問題状況と概念モデルを比較する方が現実的である。
【ステージ6、7】変革と行動
変革ステージではWに基づき実行可能な変革案を選択する。変革案の選択では、次の2点を考慮する必要がある。
- ・望ましさ:
- 変革案が適切であること
- ・実行可能性:
- 変革案を実行できること
次いで変革案に基づき問題状況を改善する活動を決定して実施する。
変革活動の対象には、次の3種がある。
- ・構造変革:
- 組織構造を変革する。
- ・プロセス変革:
- 業務プロセスを変革する。
- ・行動変革:
- 組織構成員の行動を変革する。意識改革が必要であり最も難易度の高い変革である。
以上述べたようにSSMは一連のステージから構成されているが、これらのステージを順番に実施する必要があるわけではない。また反復的な繰り返しプロセスになっている点と、現実世界と論理的なモデルとを明確に分けて考えている点が重要である。SSMによるシステム分析の概要をステージごとに表1にまとめておく。
- 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:保証ケース作成支援ツールの概要