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にまとめておく。
- 1:要求工学の概要
- 2:第12回要求工学国際会議 RE2004
- 3:要求仕様
- 4:要求工学プロセス
- 5:要求抽出
- 6:要求分析
- 7:要求確認
- 8:要求管理
- 9:要求追跡
- 10:要求工学の課題
- 11:ジャクソンの問題フレーム
- 12:シナリオ分析
- 13:要求工学国際会議RE2005
- 14:ゴール分析
- 15:iスター・フレームワーク
- 16:要求インタビュー
- 17:ゴール分析 応用編
- 18:ゴール分析 応用編つづき
- 19:ゴール分析の視点
- 20:ソフトシステム方法論 再考(その1)
- 21:ソフトシステム方法論 再考(その2)
- 22:ソフトシステム方法論 再考(その3)
- 23:非機能要求
- 24:信頼性要求
- 25:コミュニケーションの構造
- 26:組織とコミュニケーション
- 27:論理思考プロセスと現状分析ツリー
- 28:対立解消図と未来実現ツリー
- 29:前提条件ツリーと移行ツリー
- 30:特性要因図とゴール思考分析
- 31:i*フレームワークの書き方
- 32:i*フレームワークの危険な曲がり角
- 33:目的思考
- 34:要求工学の研究動向
- 35:アジャイル開発の要求工学
- 36:アジャイル開発の要求工学
- 37:要求レビュ
- 38:要求の曖昧さ
- 39:アクタ関係分析
- 40:要求工学の現状と課題
- 41:セキュリティ要求工学
- 42:ソフトウェア品質要求工学
- 43:イノベーションと要求工学
- 44:Wikiと要求工学
- 45:要求工学プロセスの改善
- 46:アクタ関係から見るユースケースと要求獲得
- 47:要求エンジニア
- 48:要求モデリングと誤り
- 49:要求を軸としたこれからのソフトウェア社会
- 50:ゴール指向とアスペクト指向要求工学
- 51:サービス指向要求工学
- 52:要求質問
- 53:試験工程での要求発見
- 54:要求とテスト
- 55:すりあわせの技術と価値星座
- 56:学生からの質問
- 57:SysMLの要求図
- 58:アシュアランスケースとGSN
- 59:組込み要求工学
- 60:要求とアーキテクチャ
- 61:要求と保守・運用
- 62:オープンソースソフトウェアと要求
- 63:要求工学のオープンな演習の試み
- 64:Web2.0と要求管理
- 65:ソフト製品開発の要求コミュニケーション
- 猿でもわかる“クラウドケータイ”
【猿でもわかるICT】 - 10G-EPONの概要 その4-10G-EPONの課題と今後の動向-
【新ネットワーク】 - やっぱりおかしいよね?メモリの使い方
【通信ソフトウェア開発】 - 猿でもわかる”フレッツテレビ”その2
【猿でもわかるICT】 - 10G-EPONの概要 その3-10G-EPONの特徴2-
【新ネットワーク】 - 10G-EPONの概要 その2-10G-EPONの特徴1-
【新ネットワーク】 - 開発支援ツール
【通信ソフトウェア開発】



