日本的共創マネジメント037：「PMとシステム思考」～システムズアプローチ(No.4)～
「PMとシステム思考」～システムズアプローチ（No.4）～：
1.5. システムズアプローチとプロジェクトモデル
システムズアプローチは経営管理にも応用できる。たとえば、アーベルは「事業領域」を定義する方法として、製品やサービスを利用する「顧客層」、製品やサービスが使用される「顧客機能」、製品やサービスを提供するために使用する「固有技術」を規定することを提案している。これに「モノ」や「ヒト」などの「資源」を追加すれば、プロジェクト活動の範囲や、プロジェクトの成果物である製品やサービスの範囲を規定できると考えられる。さらに、この図式を用いて「システムの内部構造」についても、それぞれの構成要素の働きを同じように投入、プロセス、産出、並びに制約、外乱によって詳細に表現し、投入と産出の流れに沿って順序づけると、機能構造を明示的に表現することができる。
このような考え方を基に、プロジェクトの課題をとらえ解決すべき問題を明らかにしようとする時、全体が3 つの層から成り立つと見て、それぞれをシステムとしてとらえ、モデルとして記述する方法がある。第1 層をサービスシステム層、第2 層を製品システム層、第3 層をプロジェクトシステム層として分類するものである。
第1 層については、プロジェクトの使命や課題、プロジェクトの成果物に関する要求仕様を規定するために、プロジェクトまたはプロジェクトの成果物が「顧客」に提供する「サービス」を「システム」ととらえ、サービスモデルとして記述する。
第2 層については、サービスモデルの中で求められる製品の働きや内部の仕組みを「システム」としてとらえ、製品システムモデルとして記述する。
第3 層については、サービスモデルとそこから抽出されたシステムモデルを全体構造として最適化し、それを実現していくプロジェクトまたはプログラムをシステムとしてとらえモデル化するものであり、これはスキームモデルに相当する。
1.5.1. システムの層（レイヤー）と対象のとらえ方
対象を３つの層からなるシステムととらえ、それぞれの層をモデル化する場合の視点の説明を行う。
(1) サービス提供の視点（第1 層）
第1 層の視点は、どのような顧客の、どのような働きに貢献するのか、「顧客機能に対するサービスの提供」を意識して製品機能を規定すべきであり、いきなり「どのような製品を作るか」という観点から製品仕様の記述をするのは危険なことがある。顧客機能については、顧客が求める機能を一つの製品では満たせない場合もある。たとえば、顧客機能が製品だけでは足りず、別のサービスを提供しなければ、顧客満足を得られない場合がある。
一方、製品が顧客の期待していない機能、すなわち「副作用」をもつことがある。この場合は、副作用を抑えるか、問題発生を回避するためのサービスを併せて用意しなければならない。なお、サービス提供そのものがプロジェクトの使命である場合もある。
(2) プロジェクトの成果物の視点（第2 層）
第2 層の視点は、プロジェクトの成果物（製品）自体をシステムとして規定するものである。プロジェクトの成果物がもつ機能と副作用、成果物の使用にあたって消費する資源、与えるべき情報などの関係をまず記述する。また、成果物を構成する要素と、それらの間の関係も明示する。製品機能をとらえるうえで、システムズアプローチは有効な手段となる。
プロジェクト活動のできるだけ初期にプロジェクトの成果物をシステムとしてとらえ、記述することが理想である。しかし、プロジェクトは非反復的で未知の要素が多い課題に取り組むために編成されるので、目標成果物をすぐには規定できない場合がある。そこで、初期には大まかなモデルを描き、それを吟味しながらしだいに詳細化するアプローチがとられることが多い。成果物としてのシステムの構造はプロジェクト活動の進行に従って詳細化され、また、手直しされる。
(3) プロジェクトの仕組みの視点（第3 層）
第3 層の視点は、「顧客サービス」を目指して何らかの成果物を生み出すプロジェクト活動をシステムとしてとらえるものである。
成果物を生成するために（またはサービスを提供するために）プロジェクトはさまざまな活動を行う。必要な資源を調達し、加工、輸送、検査、教育などの変換を施し、目指す成果物を生み出さなければならない。一つの活動で直接的に目標成果物を生み出せない場合、中間製品を作り、いくつかの活動を組み合わせて手順を追って成果物を作ることになる。この時、最終の目標成果物は顧客に納品されるが、中間製品の中には納品されないで、破棄されるものも少なくない。不要な中間製品を大量に作ってしまう恐れさえもある。また、プロジェクトの使命や目標成果物は未知で不確実性があっても、その実現に使用する資材や道具、人材は実際に存在し、入手できるものを使用するしかない場合が多い。そして、これらの資源に関する固有な技術をもつ人材が参画して既存の要素を組み合わせ、変形・加工して目標成果物を生み出す方法を考案することになる。
このようなことから、プロジェクトそのものをシステムとしてとらえ、最終的な成果物である顧客サービスを実現するために、どのような要素があるか、それぞれの要素間の関係はどうあるべきか、要素に欠落や無駄がないかを管理することが重要である。
1.5.2. 製品機能に対するシステムズアプローチ
製品は何らかの作用を果たし、顧客機能に貢献する。まず、製品が「使命として受けとめるべきインプット要素」を明らかにする必要がある。すなわち、製品が働きかける対象やその状態をまず明らかにする。働きかける対象が存在しないなら、製品の存在意義はないと考えてもよい。そのような要素が存在するはずである。
次に、製品が作用の目標として「産出すべきアウトプット要素」を明らかにする必要がある。すなわち、製品が正常に作用した結果として生み出すべき機能とか、上位の投入の状態変化を記述することにより、製品の作用が規定される。さらに製品が作用するために必要な資源や、製品が生み出す副産物も記述する必要がある。これらを「システム環境図式」や「コンテキストダイアグラム」と呼ばれる図式で表現するとよい。
製品の内部構造や仕組みもシステムとしてとらえることができる。しかし、「機能」のみに着目して内部構造をとらえることは妥当ではない。さまざまな視点で対象を「モデル化」し、その特性を洗い出すことが望ましい。製品の内部構造に関していうと、機能の実現に関わる部品や材料などの構成要素は、一般に複数の働きをもつことが多い。さらに、他の機能を阻害する副作用ももつことがあり、それを防ぐための仕組みが必要になる。このように機能と構成要素の関係は複雑に絡み合っているため、内部構造を階層構造としてとらえることはむずかしい場合が多い。
(2006年「P2M研究報告書」寄稿）
（次号に続く⇒）