日本的共創マネジメント040：「PMとシステム思考」～システムズエンジニアリング(No.3)～

「PMとシステム思考」～システムズエンジニアリング～（No.3)

2.4. システムズエンジニアリングのプロセス
システムズエンジニアリングのプロセスは、「６つのフェーズ」の中で繰返されるサブシステムとしての「６つのプロセス」として認識することができる。６つのプロセスとは、問題の設定、目的の選定、システム合成、システム解析、最良システムの選択、行動計画の作成、の要素を含むプロセスである。

2.4.1. 問題解決のモデル
一般的な問題解決のモデルは次のように記述できる。
まず、問題をもつ当事者は、自分自身が、ある不確実な状況にあることを知る。そこで、彼は自分の環境との間に交流をもちはじめ、調査を開始する。ついで、問題の定義をこころみ、それが終わると、その問題が解けるようなアイデアを見つけ出す。最後に、そのアイデアを評価し、それが問題を解く上でどれほど適当であるかをはっきりさせる。この３つの要素間にはインタラクション（相互作用）が存在する。たとえば。当事者があるアイデアを見つけ出すと、それに応じて問題を再び設定し直すこともあるということである。

（問題解決のモデル）

これを更にシステムズエンジニアリングのプロセスとしてモデル化すると、
問題の定義、目的の定義、システム合成、システム解析、最適案の選択、行動計画の作成、という６つの要素間のプロセスとして記述できる。これらの問題解決プロセスがシステムズエンジニアリングの各フェーズで、サブシステムとして繰返されると考えるべきである。
特に、高度技術化が進みビジネスのスピードもアップした現在では、調査研究フェーズ（プログラム計画）と探求計画フェーズ（プロジェクト計画Ⅰ）での問題解決プロセスの重要性が増している。これからのプロジェクトマネジャーは、このフェーズにおける問題解決プロセスついて十分に理解しておく必要がある。

（システムズエンジニアリングのプロセス）

2.4.2. 6 つのプロセス
(1) 問題の設定(problem definition)
問題を問題として認知し解決の必要性を、ステークホルダーや組織、課題によっては社会が認めることが重要である。だれかが問題に気づき、関係者が解決の必要性を認める「問題認識と問題形成」のプロセスを経なければ、プロジェクトを立ち上げることはできない。
ここでいう「問題」には幅広い意味がある。「アイデア」や「需要」のほかに、関係者の感情的な不安や不満の類の中にもシステムに関わる「問題」が含まれている。
問題設定のためには、政治的、経済的、社会的「環境」を明らかにし、関連しそうな規則や標準の存在を調べておく必要がある。特に問題を素朴に把握し、記述し、その意味を確認することを通して、プロジェクトマネジャーやシステムズエンジニアリング担当者は、ステークホルダーから信頼される存在になることが重要である。
(2) 問題の定義(goal definition)と価値システムの設計
調査し、記述した「問題」に基づいて、システムの目的を考え、プロジェクトが達成すべき目的を選定する。
「問題」の背後にはさまざまな「目的」が存在する。プロジェクトマネジャーやシステムズエンジニアリング担当者はそれを推測し、問題提起したステークホルダーに確認し、その人が真に求めていることを把握する。目的は多数あり、それらが関係し、全体として「価値システム（value system）」を形成している。いくつかの目的は矛盾しているが、その上位目的が一致している場合がある。また、下位目的は一致しているが、上位目的が複数あり、しかも対立や矛盾を含んでいる場合も少なくない。要するに価値システムを明らかにし、対立や矛盾を調停する新しい上位目的を導入することが望ましい。この価値システムの中から、システムが達成すべき一群の目的を抽出し、関連づけてプロジェクトの目的を選定するとよい。
(3) システム合成(system synthesis)
システム合成とは入手可能な資源を組み立てて、システムの内部構造を描くことである。一般に「設計」というと、「実現方法」は意識しなくてもよいと思いこんでいる人がいる。しかし、実現できなければ設計したシステム案が無意味になってしまう。実現可能性を保証するために、合成から始めることは重要である。
システム合成を全体から部分に向かう（トップダウン設計）か、部分から全体に展開する（ボトムアップ設計）か、あるいはその組み合わせで行うか、アプローチは問題の性質に応じて選ぶことが望まれる。
トップダウンでは、内部に矛盾が組み込まれることが多い。また、実装するに必要な資源にたどり着かない恐れがある。ボトムアップでは実現可能性
は保証されるが、しばしば全体の目的に合致しないシステムが提案される恐れがある。
システム合成作業にあたって「価値システム」を意識し、構成要素（サブシステムや部品など）が、どの価値に貢献するかを明らかにすることが望まれる。これはシステム解析の準備である。また、システム合成の結果はモデルとして記述すべきである。
「価値システム」には矛盾や対立が含まれるので、システム案やその部分案は複数になる場合が多い。複数の案を提示し、意思決定者が多数の案の中から最適と思うものを選択できるようにすべきである。
システムの構成要素について、入手可能な資源を利用すれば実現可能であると分った場合、それ以上の詳細案を作ることは好ましくない。そこから後は開発部門の手に委ねるべきである。また実現可能性を保証できない構成要素については、可能性がはっきりするまで詳細案を作る必要がある。この重点的詳細化を意識することにより、問題設定プロジェクトは時間と労力を大幅に節約できる。
(4) システム解析(system analysis)
システム解析とは、仮説として出された一連のシステムとその構成要素の特性を調べ、意図する結果が得られるかどうか、また意図しない結果（副作用）としてどのようなものがあるか吟味することである。
最近の傾向として、システムズエンジニアリング担当者がシステム合成やシステム解析を併せて担当することが多いので、2 つのプロセスを明確に分離できなくなり、しかもシステム解析を省略することが多い。しかし、それでは開発末期のシステムテストや移行段階で欠陥が見つかり、プロジェクトは失敗する危険性が高い。たとえ、担当者は同一人であっても、システム合成とシステム解析を明確に分離し、システム案の特性を把握すべきである。
OR(Operations Research)や構造解析、シミュレーションシステムなどシステム解析の方法については、ツールが多数販売されている。これらを適切に使い分けてシステムの特性を把握することが重要である。ただ、特定の方法やツールに依存し過ぎることは好ましくない。それらはシステムの特定の側面を扱うものにすぎないことに留意すべきである。特に社会的な課題については、因果関係や利害関係などを考慮し、定性的な特性も把握する必要がある。そのような場合には「What-if 思考」（こうすればこうなると類推する思考方法）や過去の経験が役立つ。
システムの特性を把握するに際して、測定方法と尺度を適切に定めることが望まれる。すべての物事は定量的に測れるものではない。単に見分けがつく「名称尺度（物など）」、違いがわかる「順序尺度（成績など）」、差がわかる「間隔尺度（温度や経常利益など）」、倍率がわかる「比例尺度（距離や重量、売上高など）」など、対象の性質に合った尺度を組み合わせ、システムやその構成要素の特性を導き出すことに留意すべきである。
(5) 最良システムの選択(optimal selection)
システムやその構成要素に代替案がある時、それらの中から最も好ましいものを選び、推奨案を定め、その根拠を明らかにする必要がある。すべての代替案を詳細に設計することは時間的にみても、労力面からも困難な場合が多いので、システム設計の途中で推奨案を定めながら、詳細にシステム案を設計するほうがよい。しかし、最終の意思決定のために、採用しなかった代替案とその選択理由は記録すべきである。
意思決定はできるだけ客観的なデータに基づいて行うことが望ましく、かつ、あらかじめどの尺度がどの価値に関わっていて、どの程度貢献するか、明らかにしておく必要がある。しばしば推奨案を定めた後で、その案の弱点を補う方策を追加すべきである、という意見が出る場合がある。その場合は、追加部分について「システム合成」に戻り、補足するとよい。また、システム案がステークホルダーの期待を大幅に上回る効果をあげることができるとか、期待にはるかに及ばない効果しか得られないと判明する場合がある。その場合は、「プログラム計画」に立ちもどって、全体の問題解決計画を軌道修正するほうがよい。
システムが実際に期待どおりに効果をあげるかどうかは、実行の時期や順序に影響される。システム案を選択する時、サブシステムの適切な構築順序と構築方法、実行期間を明らかにし、実行計画の素案を立てておくことが望ましい。これは実現可能性保証の一環である。

(6) 行動計画の作成(action planning)
以上の問題解決プロセスで得た成果を基に、情報を整理し、行動計画としてまとめ次のフェーズに引き継ぐ必要がある。これらのプロセスが各フェーズで要求される成果物の詳細さに応じて繰返され、最終成果物へと受け継がれていくことになる。

　　　　　　　　　　　　　　　　　　(2006年「P2M研究報告書」寄稿）

（次号に続く⇒）