日本的共創マネジメント041：「PMとシステム思考」～システムズマネジメント～

「PMとシステム思考」～システムズマネジメント～

3. システムズマネジメント
システム思考にはシステミック（Systemic：全体的）とシステマティック（Systematic：系統的）という概念がある。システミックとはシステム全体という意味であり、システマティックとはシステムを構成要素に分解して系統的に理解するという考え方である。システムズエンジニアリングの基本はシステマティックである。一方、システムズマネジメントには、システミックとシステマティックの両方の意味合いがある。マネジメント（管理）を「全体的に」「系統立てて」おこなうという意味である。

3.1. システムズマネジメントとは
システムズマネジメントとは、対象への接近方法であるシステムズアプローチと、システム実現のための工学手法であるシステムズエンジニアリングにおける知識、手法、スキル、ツール等を活用し、全体最適化を実現するための管理手法である。システムズアプローチが選択し、システムズエンジニアリングが設計製作したものを実用化するまでの管理運用事項いっさいを取り扱う統合活動と定義される。

3.1.1. プロジェクトとシステム
プロジェクトマネジメントの管理機能とは、個々の作業を合理的、能率的に遂行させるとともに、これらを全体的に関連づけ、調和を保って行われるように、あらかじめその活動の方向性を決定し、その方向に従って統率していく機能をさす。この管理機能は、通常、計画(Plan)、実施(Do)、評価(See)、のサイクルを経て循環的に遂行される。

（プロジェクトとシステム）

一方、システムは「関係づけられた諸要素の集まり」である。天然自然にシステムが存在するのではなく、主体者が何らかの視点に基づいて、いくつかの要素間に関係性を見出す、あるいは関係を与える結果としてシステムが姿を現すと考えるべきである。
プロジェクト業務遂行過程では、対象となる諸要素をシステムとしてとらえるアプローチが役立つと思われる。プロジェクトの成果物が提供するサービスや、プロジェクトで作られる製品、さらにはプロジェクトそのものをシステムとしてとらえることにより、課題や問題が明確になり、解決の可能性を的確に探ることができるようになる。従って、システムズマネジメントとは、調査研究フェーズ（プログラム計画）のおけるシステムズアプローチの活用と、実行段階（計画・開発・生産）におけるプロジェクトマネジメントの実施にある。

3.1.2. システム構造の管理
システムズアプローチでは検討内容がダイナミックに変わっていくので、「システム構造の管理」がプロジェクトに必須となってくる。
プロジェクトに関る諸要素をとらえ、関係付けて、全体システムとして矛盾のない構造に保つ活動として、システムマネジメントがある。そこでは、システムを構成する要素や要素間の関係を記述し、保管と参照、更新の繰り返しが基本となる。具体的な活動は以下のとおりである。
(1) 構成管理
システムを構成する要素間の関係を把握し、システム全体の構成を把握することが第1の役割である。さらに、その情報に基づいて構成要素の重複や関係の切れ目を見つけ出すことができる。問題があれば、プロジェクトマネジャーに報告し、プロジェクト活動の軌道修正を要請する。
(2) 進捗把握
あらかじめ明確にしておいたシステムを構成する要素や要素間の関係について、それぞれの「状態」を記入しておくことで、プロジェクトの進捗状況を知ることができる。
(3) 変更管理
プロジェクトの進行過程で、環境変化やステークホルダーの要請、あるいは技術的な理由などにより、システムの仕様を変更しなければならない事態がしばしば発生する。その時、変更がどのシステム要素と関わり、どの部分には影響しないかを調べる必要がある。
場合によっては、変更要求がシステム全体に悪影響を及ぼすので、受けつけるべきでない場合もある。変更にどう対処すべきかを考え、対応策を考案するためのデータを提供することが変更管理の第1 の任務である。
変更が頻繁に行われ、しばしば、プロジェクト業務の現場では、どの変更指示に基づいて行動すればよいかわからなくなることがある。その時、変更の発生順序をとらえ、システム仕様の「版管理」を行うことが第2 の任務である。
(4) システム間調整
プロジェクトが複数のシステムを取り扱うなど、複数のプロジェクト間に何らかの関係がある場合がある。その場合、プロジェクトそのものをシステムとしてとらえ、関係を把握することもシステムズマネジメント機能の一部分として重要になる。たとえば、プロジェクトチームの利用する資源が重複するとか、プロジェクトの成果物の導入設置先が同じ場合は、複数のプロジェクト活動のスケジュールを修正する必要がある。
(5) プログラムマネジメントへの提言
システムズエンジニアリングの初期のフェーズにおいて、対象世界を調査し、問題解決の可能性を探る時、単一のプロジェクト内に複数のシステムが存在したり、プロジェクトの内部では解決できない課題が存在したりする場合がある。それらにどう取り組むかをプロジェクト内部で決めることは妥当ではない。ステークホルダーの利害を調整し、プロジェクト間の重複と矛盾を取り除くために、プログラムマネジメントに課題や問題を報告し、総合的な解決を図るべきである（エスカレーション）。

3.1.3. システム環境の管理
システムは環境からの制約や外乱で影響を受ける。従って、プロジェクト活動を円滑に行うには、環境の整備が重要である。必要な資源や機材をタイムリーに供給し、働きやすい作業環境を整備することが有効である。作業環境が不良であれば、プロジェクト活動に着手できない、または着手しないほうがよい場合も少なくない。
適切なプロジェクト活動を行うためには、さまざまな情報を検討し、計画・実施する必要がある。そこで、プロジェクトを構築するための資材やソフトウェア、情報などをあらかじめ用意しておけば、プロジェクト活動を円滑かつ効果的に行うことができる。
さらに踏み込んで、プロジェクト活動支援システムやプロジェクト情報システム（PMIS）を構築できれば、より効率的である。
異なるプロジェクトの製品に共通部品や共通資源が使用される場合、プロジェクト間に関連をもたせて、プロジェクト活動を共同で行うことによって、時間と労力を節約できる可能性がある。プロジェクト情報システムはこのような場合、特に効果的である。ただし注意を要する。既存のプロジェクト活動支援システムやプロジェクト情報システムにプロジェクトを当てはめようとして、プロジェクトの課題や目標成果物をゆがめる恐れがある。「顧客機能」に対する「サービス」提供の実現がプロジェクトの最重要課題であって、既存のシステムの組み込みが目的ではないことを忘れてはならない。
以上の活動に対して、支援する道具がいくつかある。たとえば、製品の設計・開発を支援するPDM（Product Data Management）や、製品の生産準備と製造過程の管理に使用されるBOM(Bill Of Material) 、ソフトウェアの構成を管理するDataDictionary(Repository)などである。

3.1.4. 学際のマネジメント
システムズマネジメントの概念の特徴としては、戦略（プログラム）策定段階におけるシステムズアプローチの活用と、プログラムの実施（プロジェクト）段階におけるプロジェクトマネジメントの実施である。
プロジェクトを実行する上で必要となる事柄（知識、手法、スキル、ツール等）を貯え、マネジメントを実行(運営、実施、実践、思考、判断など）をする上で、 適切なタイミングで、適切に選択し、適切に活用しながらマネジメントをすることが重要である。
定義しづらい暗黙知に遭遇したら、システムズアプローチやSSM を活用し、洞察力を持って形式知化し、それをシステムズエンジニアリングにて創意工夫しながら実現していく。そういう流れにおいて、分析したり、戦略を立てたり、戦術を用いたりして、自由自在に組み合わせながら管理、制御、 問題解決などをやるのがシステムズマネジメントである。
システムズアプローチの基礎に経済学が、システムズエンジニアリングの基礎に工学が、システムズマネジメントの基礎に経営学があると言われるが、実際にはこの3 つのアプローチは、インターディシプリナリー（学際的）を特徴としており、問題の性質に応じて横断的に各領域の専門知識を駆使し、問題解決を図る融通無碍な応用力が問われている。

3.2. システムとしてとらえられない事柄の取り扱い
システムとしてとらえられる事柄については、蓄積した技術や用意した道具が役に立つことが多い。そのような場合、システムズマネジメントは強力である。一方、人間の情念やビジネス判断など暗黙知に関ることや、カオスや複雑系などのように物事をシステムとしてとらえられない場合も生じる。

3.2.1. 暗黙知とプロジェクトマネジメント
実世界にはシステムとしてとらえられない事柄が多い。しかし、そのような場合であっても、可能なかぎりシステムズアプローチを適用し、暗黙知を形式知に変換して、プロジェクトの対象世界の構造を把握する必要がある。構造を解明できない不確実で不透明な部分が少なくなり、プロジェクトの使命を達成できる可能性が高まるからである。さらに、不確実で不透明な事柄についてもできるかぎり記述し、プロジェクトにとってシステム化できる事柄と、できない事柄を明確に区別できるようにしておくことが望ましい。
プロジェクトマネジャーはシステム化すべき事柄と、すべきではない事柄をわきまえる必要がある。システム化すべきでない事柄については、システムの運用段階で顧客や運用者といった「ヒト」に任せるほうがよい。本来システムではなく、顧客や運用者が実施せざる得ない部分や工夫を凝らす余地のある部分については、顧客に任せることによって、システム化された部分と併せて頑強なシステムとすることができる。

3.2.2. カオス・複雑系とプロジェクトマネジメント
システム化がむずかしい例としては、カオスにみられるように、個々の要素の挙動を定式化できても、初期値などの前提のわずかな違いのために、システムの最終的な挙動がまったく予想していなかったものとなる場合がある。特にコンピュータシミュレーションの世界において、個々の要素の働きは明確で規則性があるにもかかわらず、結果がまったく予測しなかったものになる問題があることが認識されている。たとえば、天候を予測するための非線形方程式において、初期値をほんの少し変えると思いがけない結果が出る。さらに驚くことに、計算結果をすべて画面にプロットすると、値はランダムでも全体として規則性のある形状が現れる。このような性質をもつ課題を「カオス＊」問題と呼ぶ。株価変動もカオス問題の一つとして研究されている。プロジェクトの問題の中には予測や制御が非常にむずかしい、カオスに類した要素が存在することに注意する必要がある。
このカオスとシステムの中間に課題が存在している。「カオスの縁」と呼ばれる状態のものは「自己組織性」をもつ。たとえば、水と氷の中間の状態で美しい結晶ができあがる。
自己組織性をもつ要素が多数集まると、全体としては思いがけない挙動を果たす。このような要素あるいは要素の集まりを「複雑系」と呼ぶ。生物は複雑系である。たとえば、人間の免疫系はマクロファージを始めとするさまざまな細胞の働きにより成り立っているが、特定の器官をもっていない。それぞれの要素は独自に挙動、その総合的な働きによって免疫として機能している。
「カオスの縁」として自己組織性をもった生物からなる自然界や人間社会は、「システム」として記述できない面が多々ある。そのような部分をあえてシステム化すれば、予想もしない副作用を引き起こすことがある。企業や社会においても、このような現象はごくありふれた状況として観察される。企業や社会は自律的に働く個人の集まりであり、その連携によってビジネスが遂行され、社会活動が進行する。もちろん、「複雑系」を直接プロジェクトマネジメントに役立てるケースはあまり研究されていない。しかし、社会的な問題や企業ネットワークを扱う場合は、分析の切り口として利用することができる。

3.3. 様々な問題解決技法
システム概念に基づく問題解決技法としては、先に掲げたSSM 以外にブレーンストーミング、ＫＪ法、ワークデザインなど多数あり、さまざまなかたちで利用されている。それぞれの方法には特徴と向き不向きがあるので、課題の性質や問題の状況に応じて方法を適切に選択することが望まれる。たとえば、発散技法と呼ばれる技法を用いて、可能なかぎりアイデアを抽出し、収束技法を用いて、収集した事実やアイデアをまとめる。また、統合技法は発散技法と収束技法の両者の特徴を兼ね備えていることから、アイデアの抽出
からまとめまで実施することもできる。

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