![見出し画像](https://assets.st-note.com/production/uploads/images/36932653/rectangle_large_type_2_3369b20059f9ae1969451e77b37787c9.jpg?width=1200)
日本的共創マネジメント036:「PMとシステム思考」~システムズアプローチ(No.3)~
「PMとシステム思考」~システムズアプローチ(No.3)~:
1.4. 意思決定支援のモデリング
ソフトシステムズアプローチも含めて、一般的にシステムズアプローチにより意思決定を支援するモデリングは次のように考えられる。
1.4.1. 問題の定義と概念化
モデリングの前提として、分析者の頭の中に「概念(concept)」が入っていなければならない。組織や社会の問題を取り扱う時、システムに関与する人々のもつ概念がある程度まで共通でなければ、意思疎通さえも困難である。また、何らかの変革・変更を伴うプロジェクトでは、その必要性に関して関係者の「意識がある程度そろっていること(問題形成)」が望ましい。ソフトシステムズアプローチは、主に概念形成、問題形成に注力する。
1.4.2. モデリングとシミュレーション
多数の要素が複雑に絡み合っているような対象を解析したい場合や、時間とともに変化する状況を予測したい場合など、現実に生じる問題を取り扱う時、対象世界を「モデル(原型、模型)」として表現し、さまざまな角度から吟味することが広く行われている。これはモデリングと呼ばれ、的確に問題点や原因を突きとめることができる技法である。モデルとして表現することにより、解決策を具体的なシステムとして吟味し、妥当性や欠点を発見することができる。モデルの分類としては、概念モデル、分析型モデル(論理・数式モデル)、アイコン型モデル(模型)などがあり、それぞれのモデルに応じて、コンピュータシミュレーションやテストマーケティング、プロトタイピングなどのシミュレーション(模擬実験)が可能になり、現象の解明やケーススタディによる最適案選択の意思決定を支援する。
1.4.3. モデリングの視点
システム化の対象となる実世界は一見、「もの」や「ひと」が脈絡なく雑然と存在し、出来事がランダムに発生しているように見える。このような状況の中で規則性や関係性を見出し、システムとして構造をとらえるさまざまなモデリング技法が提案されている。モデリング技法は、まだ世界標準として認知されたものはないが、たとえば、オブジェクト指向技術標準化コンソーシアム(OMG)が設定中のUML(Unified Modeling Language)や米国国防省(DOD)が定めているIDEF(Integrated DEFnition)など、いくつかの候補がある。
技法によって表記法は異なるが、共通する主要なモデリングの視点は次のとおりである。
(1) 実体・関連
対象世界を構成する複数の「実体(モノ=entity)」とそれらの間の「関係(関連=relationship)」をとらえる。要素の時間的な変化過程を含まない場合は「静的モデル」と呼ばれる。静的モデルが正確に記述されていると、システムの構成要素や働きを文章表現することや、機能モデルに書き換えることは容易である。
(2) 実体・事象と状態遷移
実体の性質をとらえるために、実体の状態を変化させる「出来事(事象=event)」の連鎖、あるいは順序規則を記述する。これは実体の動的性質をとらえるアプローチである。対象世界の現象が時間的に変化する状況を記述したモデルは「動的モデル」と呼ばれる。
一方、順序関係に着目して状態遷移を分析する方法があるが、これは出来事を捨象して、実体の状態変化のみをモデル化するものである。このようなモデルは「状態遷移モデル」と呼ばれる。
(3) 機能と変換
「システム環境図式」として既に述べたとおり「機能と変換」の技法は、要素の働きを表現する方法として投入、プロセス、産出、制約および外乱を用いるものである。このようなモデルは、「入出力モデル」または「I-P-O モデル」と呼ばれる。一つの活動や出来事によって複数の実体の状態が変化する様子を表現できる。この方法はシステムの働き、作用を表現するために役立つ。
(4) 相互作用
実体がある状態に達した時、またはある出来事が発生した時、他の活動を起動させたい場合がある。そのような場合は、実体間の相互作用の様子を記述する方法がある。ただし、相互作用の記述方法は現在のところ貧弱であり、推奨できるものは少ない。
(5) 手続き
ある目的を達成するために行う一連の活動の順序や活動順序の選択規則を記述するものである。ワークフロー-やビジネスプロセスは手続きの一種である。システムに関与する要素が多種・多数あると、手続きを部分的に変えなければならない場合の記述は極めて複雑になる。しばしば、設定した手続きに漏れや論理的ミスが組み込まれることがあるので注意する必要がある。実際のプロジェクトでは複雑すぎて、手続きとしては記述し切れない課題が少なくない。このような問題を回避、軽減するために、いくつかの順序を伴う活動をまとめてサブシステムを構成することによって、システム全体の構成をブロックの結合として表現する。
以上のような視点をすべて使わなければならないというものではない。課題の性質に応じてモデリング技法を選択することが望ましい。また、一つの表記法にこだわると、課題の重要な性質を見落とすことがあるので注意が必要である。なお、米国国防省のIDEF(Integrated DEFinition)手法では、システムのモデリング記述に、投入、プロセス、および産出に加えて、プロセスを制約する条件(法規制、規格、契約条件、等)や所与の条件(プロジェクトの上位組織の規定やポリシーなど)を制約条件(constraints)とし、プロセスの実施を可能にする方法論、資源、ツールをメソッド(methods)と総称して、それぞれプロセスに上下から入る矢印の関係で記述する。
IDEFは、システム構築のみではなく、プロジェクト遂行プロセスやモデルの記述にも使用されている(例:米国PMI®のPMBOK®Guide、米国CII のPre-Project Planning Guide、エンジニアリング振興協会プロジェクトマネジメント部会分科会報告書「PMS とCAE の統合に関する研究〈1993〉」など)。
(2006年「P2M研究報告書」寄稿)
(次号に続く⇒)
この記事が気に入ったらサポートをしてみませんか?