「地域経済研究」第１７号、２００６

製品開発マネジメントの分析ツールとしての設計構造マトリックスに関する考察

広島大学大学院社会科学研究科附属地域経済システム研究センター助手

目

代

武

史*

要

旨
本稿の目的は、複雑な製品開発を分析するためのツールである設計構造マトリックス（DSM: Design
Structure Matrix）について、その基本概念と最近の研究動向を整理するとともに、DSM の分析ツールとしての利点と限界点を明らかにすることである。DSM は、開発製品や開発組織などをシステムの観点から捉え、システムを構成する要素間の依存関係を簡潔に示す行列である。分析対象に応じて、コンポー
ネント DSM、チーム DSM、タスク DSM、パラメータ DSM などがある。
近年の研究動向を見ると、（１）開発製品や開発組織の構造を最適化する流れと（２）開発プロセスを最適化する流れがある。構造の最適化には主にクラスタリング、プロセスの最適化にはパーティショニン
グといった分析手法が用いられる。
他の製品開発手法と比較した DSM の利点は、記述する情報の簡潔性、網羅性、一覧性、操作性の良さにある。ただし、DSM は分析手法の一つに過ぎず、製品開発のすべてを分析できるわけではない。
DSM には、要素間の未知の依存関係に対する脆弱性、スタティックな分析アプローチ、組織の知識蓄積に関する分析の弱さといった限界点があることに留意する必要がある。
キーワード：設計構造マトリックス、製品開発、製品アーキテクチャ

１．はじめに本稿の目的は、複雑な製品開発を分析するためのツールとして近年注目されている設計構造マトリックス（Design Structure Matrix、以下 DSM）の基本概念と最近の研究動向を整理するとともに、
DSM の分析ツールとしての利点と限界点を明らかにすることである。
DSM は、１９７０年代に Donald V. Steward が考案
し、９０年代に入ってからマサチューセッツ工科大学（MIT）の Steven D. Eppinger や A. Yassine 等
によって拡張され、製品開発研究へ応用が進んでいった。とりわけ Baldwin and Clark（２０００）において、製品アーキテクチャを記述するツールとして紹介されて以来、DSM が広く知られるように* 連絡先：〒７３０_００５３ 広島市中区東千田町１_１_８９
TEL（０８２）５４２_６９９２ FAX（０８２）２４９_４９９１
Email: mokudai@hiroshima-u.ac.jpなった。
本研究の背景には、実践面および研究面における次のような課題がある。
まず、実践面では、製品開発マネジメントの鍵の一つは、複雑性への対処にある。製品に求められる機能や品質レベルの上昇に伴い、製品設計の複雑性はますます高まっている。また、製品が必要とする科学・技術知識は高度化や複合化が進展し、一つの製品開発プロジェクトにさまざまな個
人や組織が携わるようになり、組織の複雑性も増している。さらに、市場投入のリードタイムを短縮するため、設計開発工程のオーバーラップや問題解決のフロントローディングが求められており、開発プロセスにおいても短期間で多くの問題解決をこなさなければならず、開発プロセスの複雑性も高まっている。
このような複雑性に対処するために、われわれは通常、全体システムをより単純な下位システム― 25 ―

や要素へと分割していく。システムの複雑性は、
くは、綿密な調査に基づいているものの、製品構成要素の数が増えるほど、また要素間の繋がり
アーキテクチャ特性の記述は、研究者の主観的なが増えるほど、増大していく。製品開発において観察やアンケート調査などに依拠しており、記述は、個々の要素の開発に加え、要素を統合して一の客観性や再現可能性、比較可能性などに方法論
つの製品にまとめ上げる必要がある。そのプロセ
上の限界があった。
スは、しばしば試行錯誤的であり、作業の繰り返
DSM による製品設計特性の記述は、そうした従しを伴う。このことが、製品開発マネジメントの来の製品アーキテクチャ研究の方法論上の弱点を複雑性の大きな源泉となっている。
補うものである。２節以降で詳しく述べるように、
ところが、製品開発マネジメントのツールとし
DSM は要素間やプロセス間の作用・被作用の関係て知られるガントチャートや PERT などでは、こを網羅的、体系的に記述することができる。また、
うした要素間の込み入った相互依存性から生じる
DSM は情報の要約性や一覧性に優れるため、研究
開発マネジメントの複雑性を十分に捉えることが者と実務家との間のコミュニケーションを容易にできない。ガントチャートや PERT は、開発期間
し、より正確な製品アーキテクチャ特性の記述おや所要資源を規定する重要なポイントやボトル
よび分析に貢献すると考えられるのである。
ネック、すなわちクリティカルパスを明らかにす
本稿の構成は以下の通りである。２節において、る上では有効なツールである。しかし、そうした
DSM の基本的な概念や分析手法について説明する。
クリティカルパスにおいて開発作業の遅れや開発
３節では１９９０年代以降の主な研究をとりあげ、工数の増大といった問題がいかに生じるのかは十DSM を用いた最近の研究動向を整理する。そして分に説明できない。なぜなら、ガントチャートや４節では、製品開発研究における DSM の限界点
ないし留意点について考察する。最後に５節におPERT では各工程の所要時間や所要工数は、少な
くとも短期的には与件として扱われるからである
いて、本稿の結論を述べる。
（藤本、２００１）。
２．設計構造マトリックスの概要
DSM は、要素間やタスク間の相互依存性を直接分析の対象とすることで、従来の分析ツールが捉（１） 基本概念
え切れなかった複雑性の問題をより効果的に分析できる。これが DSM を研究する実践上の背景でDSM は、開発製品や開発組織などをシステムの観点から捉え、システムを構成する要素間の依存ある。ただし、DSM は他の分析ツールに対して全関係を網羅的に示す行列である。要素間の依存関面的に優れているというわけではなく、他の分析係には、物理的な関係、情報の受け渡し関係、エ
ツールと相互補完的に用いられるべきである。本
ネルギーの交換関係、空間的な干渉関係などがあ
稿では、DSM の制約条件や限界点についても若干る。
の考察を行う。
次に、本稿の学術研究面の背景として、製品
DSM では、システムの複雑性を要素間の依存関係に還元して記述する。要素間の関係は、作用のアーキテクチャ研究の進展がある。製品アーキテク
方向性を持った有向グラフ（directed graph; diaチャ研究は、製品開発における複雑性の問題を要素間の関係性の観点から分析する研究アプローチ
graph）で示すことができる。図１は、要素間のもっとも基本的な依存関係のパターンを示していである。製品アーキテクチャとは、製品をいかにる。
要素に分解し、そして分解した要素をいかに統合
並行型は、要素 A と要素 B が依存関係を持たなするかに関する基本的な設計構想である（Ulrich,いパターンである。依存関係を持たないとは、例
１９９５; 藤本・武石・青島編、２００１）。製品アーキテ
クチャ研究では、様々な製品や産業を対象として、 えば要素 A を設計するために、要素 B からの何らかのインプットを必要としないということである。
製品アーキテクチャの特性自体の分析、製品アー
そのため、並行型では、要素 A と要素 B を互いにキテクチャが組織構造や組織関係に与える影響の独立に設計することができる。
分析、産業構造やイノベーションに与える影響の逐次型は、要素 A が要素 B に影響を与えるが、分析などが行われてきた。それらの先行研究の多― 26 ―

「地域経済研究」第１７号、２００６
図１

要素間の依存関係（グラフ表示）（出所）Yassine（２００４）
図２

要素間の依存関係（DSM 表示）（出所）Yassine（２００４）

その逆の影響はないパターンである。すなわち、
要素 B を設計するためには、あらかじめ要素 A からのインプットが必要となる。
相互依存型は、要素 A と要素 B がそれぞれ影響を与え合うパターンである。すなわち要素 B を設計するためには、要素 A からのインプットが必要
であり、さらに要素 B の設計の結果が要素 A の設計に影響を与える。この場合、要素間で循環的に影響の連鎖が生じるので、何らかの収斂のメカニ
ズムが働かないと、いつまでも設計が完了しない恐れがある。
こうした要素間の依存関係のパターンを２×２の DSM で表示したのが図２である。
DSM は、次のように読むことができる。
１．行および列は、システムを構成する要素を表し、行列とも同順序に配列している。
２．リストは上から下へと読んでいき、要素 A
が要素 B に影響する（入力になる）場合、A 列と B 行の交点をマーク（X）する。
３．列方向に読むと、その要素がどの要素へ影響しているかが分かる。
４．行方向に読むと、その要素がどの要素から影響を受けているかが分かる。
図２に戻ると、（a）並行型では、要素 A と要素
B との間で依存関係がないため、A 列 B 行も B 列（b）逐次型では、A 列
A 行も空欄となっている。
B 行に印 X が入っており、要素 A が要素 B に影響を与える関係となっている。（c）相互依存型では、A 列 B 行にも B 列 A 行にも印 X がついており、要素 B は要素 A から影響を受け、同時に要素
A は要素 B から影響を受けるケースを示す。
（２） 依存関係の記述方式
要素間の依存関係を記述するもっとも単純な方
法は、依存関係の有無を２値的（binary）に捉えることである。すなわち、要素 A と要素 B との間に依存関係があれば、DSM の所定の欄に印（X）を記入する方式である。依存関係の有り無しで記述した DSM を２値 DSM（binary DSM）という。
もう一つの代表的な記述方式は、依存関係の強
弱や必要性などを数値でウェート付けして記述する方法である。依存関係の数値表現には次のような尺度がある。
１．強 ０.３、中 ０.２、弱 ０.１、無 ０（Sharman,
et al. ２００２; Yassine, et al. ２００３など）
２．必要 ＋２、望ましい ＋１、中立 ０、望ましくない −１、有害 −２ （Pimmler andEppinger, １９９４; Sosa, et al. ２００３）
３．タスクの繰り返し確率（P）：０＜ P ＜１
（Cronemyr, et al. ２００１; Smith andEppinger, １９９７; Yassine, ２００１）
第一に、依存関係の強弱を記述する場合、依存関係がない場合（０点）を起点として、依存関係が強まるほど点数が一方向的に高まっていく。要― 27 ―

表１

DSM の基本タイプ

目的

DSM タイプ

表示対象

適用対象

分析手法

（a ）
コンポーネント DSM
製品アーキテクチャにお システム基本構造設計、もしくはアーキテクチャ
クラスタリング
ける部品とその関係性
エンジニアリング、等
DSM
構造最適化
（b）
チーム DSM
もしくは組織 DSM

組 織における個 人、グ
組織設計、インタフェー
ループ、チームとその関クラスタリング
ス管理、組織間統合係性（c ）タスク DSM もしくはスケジュール DSM

プロセスにおける諸活動 プロジェクトのスケジュー パーティショニング、ティとそのインプット及びアウト リング、活動の順列化、 アリング、シミュレーショ
プット関係
サイクルタイム短縮ン、固有値分析（d）パラメータ DSM

パーティショニング、ティ
設計におけるパラメータと 末端レベルの活動の順列
アリング、シミュレーショ
その関係性
化、プロセスの構築
ン、固有値分析プロセス
最適化（出所）Browning（２００１），Yassine（２００４）から引用。一部変更、加筆。

素間の依存関係を客観的もしくは記述的に捉える
他方、数値的な記述方式は、依存関係の程度を場合に用いられる尺度である。例えば、開発組織
より詳しく記述する。実際の分析では、２値的方の DSM（チーム DSM、後述）の場合、開発チー
式と数値的方式は補完的に用いられる。すなわち、ム間のコミュニケーション頻度が毎日（強い依存DSM 作成の第一段階では、２値的記述により要素関係）、週に数度（中）、月に数度（弱）などの形間の依存関係の有無をまず記述し、必要であれば、で依存関係を記述する。
第二段階でさらに調査を行い、２値的な依存関係
第二に、依存関係を望ましさの観点から規範的を数値に置き換えるなどの方法が多くの先行研究に記述する尺度もある。例えば、部品間で物理的でとられている（Sharman, et al. ２００２; Yassine, et
な依存関係が機能実現のために不可欠であればal. ２００３）。
「必要 （＋２）」、依存関係があれば有用だがなくても機能は損なわなければ「望ましい （＋１）」、（３） DSM のタイプと分析手法
依存関係と機能性が中立もしくは無関係な場合
記述対象の違いによって、DSM にはいくつかのは「中立（０）」、依存関係は無い方がよいのだがタイプがある（Browning, ２００１）。表１は、DSMあっても機能を損なわない場合は「望ましくないの基本タイプを示している。DSM はタイプによっ（−１）」、依存関係があると機能を損なう場合はて、分析目的や分析対象、分析手法などが異なる。
「有害（−２）」などと記述する。
ここでは、DSM タイプ別に分析対象や手法につい第三に、依存関係を確率的に記述する尺度もあて概説し、分析目的については３節であらためてる。この尺度は、開発作業間の依存関係を分析す検討する。
る場合（タスク DSM）などにしばしば用いられる。
ある作業 B の結果によって、別の作業 A が影響を
（a）コンポーネント DSM受ける（例えば、作業のやり直しが発生する）よ
コ ン ポ ー ネ ン ト DSM（Component-based
うな場合、その影響を受ける確率（P）を ０＜P＜１
DSM）は、製品システムを部品もしくはサブシスの範囲で記述するのである。
テムに分解し、部品（もしくはサブシステム）間
２値的な記述方式の利点は簡便性にある。DSMの依存関係を記述するものである。行列に表示さの主要な目的の一つは、分析対象となるシステム
れる要素は、分析対象となる製品を構成する部品の特性を、その複雑性の源泉となる構成要素間のである。部品の間でどのような依存関係（空間、依存関係に着目し、その他の情報は捨象して記述
エネルギー、情報、物質など）がどのような形することである。２値 DSM は、この目的をもっ（並行、逐次、循環）でどの程度（強、中、弱）存とも簡潔な形で実現するものである。
在するのかを記述する。
― 28 ―

「地域経済研究」第１７号、２００６
図３

自動車用空調システムのコンポーネント DSM（注）

空間 Ｓ Ｅ エネルギー
情報 Ｉ Ｍ 物質
空欄は、依存関係が存在しないこと（空間、情報、エネルギー、物質ともに０）を示す。

（出所）Pimmler and Eppinger（１９９４）
図４

自動車用空調システムのコンポーネント DSM（クラスタリング後）（注）

空間 Ｓ Ｅ エネルギー
情報 Ｉ Ｍ 物質
空欄は、依存関係が存在しないこと（空間、情報、エネルギー、物質ともに０）を示す。

（出所）Pimmler and Eppinger（１９９４）― 29 ―

図３は、自動車用空調システムのコンポーネン
ト DSM の事例である。事例の空調システムは、
ラジエータやエンジン、ヒーターコアなど１６の物
理的な要素、すなわち部品から構成されている。
部品間の依存関係は、空間的干渉、エネルギー交
換、情報交換、物質交換の観点から、それぞれ数
値尺度（必要 ＋２、望ましい ＋１、中立 ０、望ましくない −１、有害 −２）で記述されている。例
えば、E 列（コンデンサ）をみると、A 行（ラジエータ）とは空間上必要な依存関係があり、エネ
ルギー面では有害な依存関係があることが分かる。
また、B 列（エンジンファン）に対しては、空間面および物質面で必要な依存関係がある。なお、対角線上の点は、ある部品の自分に対する依存関係を意味するため、空欄となっている。図３をみると、DSM 全体に依存関係が散らばっていることがわかる。
行列を並び替え、依存関係にある要素を対角線の近傍にグループ化する分析手法をクラスタリン
グ（clustering）という。一般に、クラスタリングにおいては、各クラスターの内部では部品間の依存関係が密集し、クラスター間の依存関係は最小限に抑えるように要素の並べ替えを行う。依存関
係の強い部品を一つの塊、すなわちモジュールにまとめることにより、設計過程において部品間の重要な依存関係を見逃すのを防いだり、依存関係の強い部品同士を統合するなどして、問題解決を容易にするのがクラスタリングの狙いである。
図３の空調システムを、物理的な依存関係の観点からクラスタリングしたのが図４である。図４
では、フロントエンド・エア（部品 A、B、E）、
冷却（部品 E、F、I、H）、内装エア（部品 H、C、P、O、G、N）の３つのクラスターに加え、制御・接続クラスター（部品 K、J、L、D、M）が抽出されている。図４のケースでは、クラスター
外部の依存関係は、制御・接続クラスターに集約されている。
このようにコンポーネント DSM が記述するのは、製品のアーキテクチャ特性である。クラス
ターをモジュールと読み替えれば、クラスタリン
グは、製品アーキテクチャのモジュール化の手法といえる１）。小さな DSM では、クラスタリングを
１）モジュール化とは、下位システムができるだけ完結

手動で行うことも可能であるが、大きな DSM では手動でクラスタリングすることは現実的でない。
クラスタリングの方法については、コンピュータ
で自動的に計算するためのアルゴリズムがいくつか開発されており、一般に公開されている２）。
（b）チーム DSM
チーム DSM（Team-based DSM）もしくは組織
DSM（Organizational DSM）は、開発組織を構成する作業チームやグループ間の依存関係を記述す
る DSM である。行列に表示される要素は、分析対象となる組織を構成するチームや個人である。
作業チーム間でどのような依存関係がどのような形でどの程度存在するのかを記述する。
図５は、自動車エンジン開発の組織 DSM の事例である。事例の開発組織は、エンジンブロック
担当、シリンダーヘッド担当、カムシャフト／バ
ルブトレイン担当など２２のチームから構成される。
各チームは、CAD 設計者や生産技術者、購買担当者など数人の構成員からなっている。
チーム間の依存関係は、チーム間の情報交換の頻度により捉えられる。情報交換の頻度がほぼ毎
日あれば高い依存性（大きな丸印）、週に一回程度
であれば中程度の依存性（中位の丸印）、情報交換が必要ではあるがその頻度は高くない場合は低程度の依存性（小さな丸印）と判断する。図７をみると、丸印が DSM 全体に広がっており、あるチームが仕事を遂行するためには、広範なチームと情報交換が必要なことがわかる。
チーム DSM の分析に用いられるのは主にクラスタリングである。行列を並び替えて、依存関係の強いチーム同士は同じクラスターにまとめ、クラスター間では依存関係を抑制する。クラスタリ
ングのアルゴリズムは、コンポーネント DSM と同じである。
図６は、図５の開発組織のクラスタリングを行った結果である。５つのチーム・クラスターがした機能をもつように全体システムを切り分けると共に、下位システム間のインターフェースを標準化するようにアーキテクチャを変換することである。これと対をなす概念にインテグラル化がある。インテグラル
化とは、全体システムを構成する下位システム同士が機能的、構造的に互いに結び付きを持つようにアーキ
テクチャを変化させることである。
２）http://www.dsmweb.org/DSM_tools.htm― 30 ―

「地域経済研究」第１７号、２００６
図５

自動車エンジン開発のチーム DSM（注）開発チーム間の情報交換の頻度：●毎日、 ● 毎週、・毎月（出所）McCord and Eppinger（１９９３）
図６

自動車エンジン開発のチーム DSM（クラスタリング後）（注）開発チーム間の情報交換の頻度：●毎日、 ● 毎週、・毎月（出所）McCord and Eppinger（１９９３）

抽出されている。クラスター１から４は、部品の関連性が高く頻繁なコミュニケーションが必要なチームの集合を示している。クラスター内ではチーム間で密なコミュニケーションがあるが、クラスター間の情報交換は最小限となっている。いくつかの開発チーム（例えば、ピストン担当、潤滑担当、エンジンブロック担当）は隣り合うクラスター（クラスター１および２）の両方に所属することで、クラスター間の情報交換チャネルが確保されている。クラスター５は、ほとんどすべてのチームと情報交換チャネルを持っており、エンジン開発の全体を統合する役割を持っている。

― 31 ―

図７

電気自動車開発プロセスのタスク DSM（注）対角線上のまるで囲まれた数字は、当該タスクの所要時間を表す。
（出所）Smith and Eppinger（１９９７b）
図８電気自動車開発プロセスのタスク DSM（パーティショニング後）（注）対角線上のまるで囲まれた数字は、当該タスクの所要時間を表す。
（出所）Smith and Eppinger（１９９７b）

チーム DSM におけるクラスタリングの狙いは、 タスクから構成される３）。タスク間の依存関係とは、頻繁な情報交換の必要なチーム同士を一つにまとあるタスクが別のタスクの入力関係にある場合をめたり、物理的に近くに配置することにより、コ意味する。例えば、車両重量設計（４列）は、
ミュニケーションを円滑化することにある。例え
モータ仕様・重量設計（３行）、加速・馬力比設計
ば、職務の関連し合うチームの大部屋への配置は（９行）、車体構造・サスペンション設計（１２行）
その一例である。チーム DSM の分析では、コンに影響を与える。
ポーネント DSM と同様に、要素のまとまりが重タスク DSM では、タスクの順序に重要な意味要であり、要素の順序はとくに問題ではない。
が あ る。対 角 線 よ り 下 に あ る 印 は、フ ィ ー ドフォーワード、すなわちタスクが前工程から後工（c）タスク DSM
程へと逐次的に進むことを意味する。一方、対角
タスク DSM（Task-based DSM）は、製品開発
線より上にある印は、フィードバック、すなわちプロセス等における各種の活動（タスク）の間の後工程から前工程へとタスクが逆流することを意
依存関係を記述する DSM である。行列に表示さ味する。例えば、後工程における設計変更が前工れるのは、分析対象となるプロセスを構成するタ程の設計の見直しをもたらすようなケースである。
スクである。タスク間でどのような依存関係がど
図７では、モータ仕様・重量設計から車両サイのような形でどの程度存在するのかを記述する。
ズ・空力設計への影響（３列１行）、車両重量設計
図７は、電気自動車開発プロセスの仮想事例で３）事例のオリジナル版は Steward（１９８１）で、１６のタある（Steward, １９８１; Smith and Eppinger, １９９７b）。
スクで構成される。同じ事例を引用した Smith and事例の開発プロセスは、車両サイズ・空力設計、
Eppinger （１９９７b）ではその一部を用いて分析を行っモータ仕様・重量設計、車両重量設計など８つのている。
― 32 ―

「地域経済研究」第１７号、２００６

対角線に近づけることである。対角線の近くにからモータ仕様・重量設計への影響（４列３行）
フィードバック・ループがあるということは、開などがフィードバックを示している。
発プロセス上近くにあるタスクの間で繰り返しがタスク間にフィードバック・ループが存在する
行われるということであり、タスク間の連携がや場合、最初のタスクは、後工程のタスクからのりやすい。また、繰り返しのサイクルも短期間でフィードバックを推測して遂行される。例えば、回すことができる。対角線よりも離れた場所に印
図７によれば、車両サイズ・空力設計は、モータ仕様・重量設計に先立って遂行されるが、車両サX が存在する場合、仕事がかなり下流のタスクまで流れてから、上流のタスクに仕事が戻ってくる
イズ・空力設計を完成させるには、モータ仕様・ことを意味し、繰り返しのサイクルが非常に長く
重量設計、車両重量設計などの下流工程からのなってしまうからである。
フィードバックを必要とする。すなわち、車両サ
繰り返しが必要なタスクを識別し、それらを予イズ・空力設計を最初に行う時点では、実際のめ連携作業として開発プロセスに組み込むことをモータ仕様・重量設計や車両重量設計がこうなる「計画した反復プロセス」という（Eppinger, ２００１）。
だろうという予測や仮定に基づいて行われるのでコンカレント・エンジニアリングは、計画した反ある。したがって、この仮定の精度を上げること
復プロセスの典型である。
が繰り返しの可能性や程度を削減する重要な鍵と問題となるのは、対角線から離れた場所に予想なる。
外の印 X が存在する場合である。それらは「計画
このような試行錯誤的なタスクの繰り返しは、外の反復」であり、タスク間の予想外の依存関係
革新的な製品を生み出すためには、ある程度必然によって、開発プロセスが大幅に遅延したり、問となるプロセスであるが、行き過ぎると開発リー
題の解決に膨大な工数を浪費させる危険性がある。
ドタイムの延長、開発資源の浪費などの弊害をもこのような場合、デザインレビューなどにより開たらす（Eppinger, ２００１）。タスクの繰り返しによ
発の節目の管理を徹底すること、致命的な欠陥でる弊害を低減し、製品開発の所定の目標を達成す
るため、開発プロセスの最適化を図る必要がある。 なければ、そのまま開発製品を市場投入し、次世代の開発プロジェクトのための教訓として扱うこパーティショニング（partitioning）もしくは順と、欠陥が致命的な場合プロジェクトを放棄して列化（sequencing）は、開発プロセスの最適化をしまうこと、などの対策が考えられる（Eppinger,
図るための分析手法である。パーティショニング
２００１; Yassine, et al., ２０００）。
とは、DSM の行列を並び替えることによって、タスク間の依存関係を示す印 X を対角線より下に移（d）パラメータ DSM
動させる手法である。パーティショニングも小規
パラメータ DSM（Parameter-based DSM）と模な DSM では手動で行うことが可能であるが、は、製品設計を構成するパラメータ間の依存関係
コンピュータで自動的に行うプログラムも一般にを記述する DSM である。パラメータ DSM は、利用可能である４）。
図８は、パーティショニングによってタスクの製品開発におけるもっとも末端のレベルの意思決順列化を図った DSM である。図５の DSM と比定に関わっている。設計パラメータ間でどのよう較して、対角線より上の印が減少し、フィード
な依存関係がどのような形でどの程度存在するの
バック・ループが削減されていることが分かる。
かを記述する。
しかし、パーティショニングを行っても、実際
図９は、自動車用ブレーキシステムの事例であの DSM で対角線より上の印 X をすべて取り除くる（Smith and Eppinger, １９９７a; Yassine, ２００４）。
ことはほとんど不可能である。その場合、フィー
事例のブレーキシステムは、顧客ニーズ、車輪ト
ドバック・ループを効率的に管理可能なレベルにルクなど１３のパラメータで構成される５）。パラ
メータ間の依存関係とは、あるパラメータが別の制御することを考えなければならない。そのためのポイントは、対角線より上の印 X をできるだけ
４）http://www.dsmweb.org/DSM_tools.htm５）Smith and Eppinger（１９９７a）のオリジナル DSM は
１０５の要素から構成されるが、簡単化のため、主要な依存関係を含む１３の要素を抽出。

― 33 ―

図９

自動車用ブレーキシステムのパラメータ DSM（出所）Yassine（２００４）
図１０ 自動車用ブレーキシステムのパラメータ DSM（パーティション後）（出所）Yassine（２００４）

パラメータの入力関係にある場合を意味する。例
えば、ローター直径（５列）の決定は、ペダル機
構アドバンテージ（３行）、フロントライニング摩擦係数（７行）、リアライニング摩擦係数（１１行）、ブースター反発比率（１３行）のパラメータ設定に影響を与える。
パラメータ DSM では、タスク DSM と同様、対角線より上にある依存関係が重要な意味を持つ。
すなわち、対角線より下にある印 X は、パラメー
タ間のフィードフォーワードを意味する一方、対角線より上にある印 X は、パラメータ間のフィードバックを表す。フィードバックが存在する場合、先に決定したパラメータがその後に決定するパラ
メータの結果により、再度見直す必要がある。いわゆる設計変更による設計の手戻りが発生するのである。
このような設計の手戻りを最小化するために、パラメータ DSM ではパーティショニングが行われる。タスク DSM と同じ要領で、行列を並び替
え、印 X を対角線より下に移動させるのである。
図１０は、図９をパーティションにより順列化した結果である。パーティション後に残ったフィード
バックは、できるだけ対角線に近づけるとともに、コンカレント・エンジニアリングなどにより、計画的にパラメータ設計の繰り返しを管理する必要がある。

― 34 ―

「地域経済研究」第１７号、２００６

３．DSM 研究の動向
DSM を用いた研究は、１９９０年代以降、MIT の研究者等を中心にして、分析手法の開発が進み、応用分野も広げられていった。表２は、近年のDSM 研究を整理したものである。DSM の研究動
向を振り返ると、大きく分けて（１）構造を最適化する流れと（２）プロセスを最適化する流れがある。

ノベーションと呼んでいる。また、Baldwin and
Clark （２０００） は、DSM による製品アーキテク
チャの分析によって、製品アーキテクチャのモ
ジュラー化の推進要因やプロセスを詳細に分析している。
構造の最適化は、開発組織についても様々な研究がある。例えば、McCord and Eppinger（１９９３）
は、自動車用エンジンの開発組織を対象として、各部品の開発担当チームのコミュニケーション頻度を分析し、コミュニケーション頻度の高い開発担当チームのグループ化を行っている。これによりグループ内におけるコミュニケーション効率を改善する一方、グループ間での不必要な依存関係を削減し、組織全体の開発効率を高める組織構造を提示している。
また、組織構造の最適化問題は、しばしば製品
アーキテクチャとセットで分析される。例えば、
Sosa, et al.（２００４）は、航空機エンジンの詳細設計フェーズについて、コンポーネント DSM とチー
ム DSM を記述し、両者の適合関係を分析している。分析の結果、コンポーネント間に依存関係があるにもかかわらず、それに組織が対応できていないケースが数多く見られた。そうした見逃されたコンポーネント間の依存関係は、しばしば開発
担当チームの境界線上に存在するため、開発チーム同士で適切なコミュニケーションがとられていないことが原因となっていることが明らかにされた。こうした製品設計と組織との適合関係の分析
は、Baldwin and Clark（２０００）でも行っており、製品アーキテクチャと組織のアーキテクチャは同型化することを指摘している。

（１） 構造の最適化
構造の最適化とは、分析対象となるシステムを構成する要素間の依存関係を整理することによって、要素間の相互作用から発生する複雑性を管理可能なレベルにコントロールしようとする研究の方向性である。コンポーネント DSM を用いた製品
アーキテクチャの分析やチーム DSM を用いた組織構造の分析がこれに当る（McCord, K. R. and S. D.
Eppinger,１９９３; Pimmler, T. U. and S. D. Eppinger,
１９９４; Sharman, D. M. and A. A. Yassine, ２００４; Yu,
et al. ２００３）。
製品アーキテクチャの構造最適化の研究は、モジュラー化の研究とほとんど同義である。構造最適化の研究では、コンポーネント DSM によってまず構成要素の間の依存関係を記述し、次にクラスタリングによって要素間の依存関係を整理するのが一般的な分析パターンである。すなわち、構成要素がクラスターの内部では緊密な依存関係を持つが、クラスターの外部との依存関係は最小化するように行列を並び替える。それにより、要素間の依存関係から生じるシステム複雑性をクラス
ター内に閉じ込めるのである。このクラスターを
モ ジ ュ ー ル と 読 み 換 え れ ば、コ ン ポ ー ネ ン ト（２） プロセスの最適化
DSM におけるクラスタリングは、統合型アーキテ
クチャを持つ製品をモジュラー型に転換するため
もう一つの DSM 研究の流れは、開発プロセスの方法論を意味することが分かる。
の最適化である。典型的なのは、DSM 分析によって開発プロセスを構成するタスクの流れの改善を
DSM による製品アーキテクチャのモジュラー化は、ボトムアップ的である。すなわち、新規の試みる研究である（Browning, ２００２; Clarkson
技術や部品の導入によってモジュール化を図るの
and Hamilton, ２０００; Kusiak, ２００２; Smith andはなく、現状の部品構成とそれらの依存関係を出
Eppinger, １９９７a; Smith and Eppinger, １９９７b;
発点として、それをクラスタリングすることで、
Yassine and Braha, ２００３; Yassine, et al. ２０００;
モジュールの形成を図るアプローチとなっている。 Yassine, et al. ２００１）。
開発プロセス最適化の研究の一つのアプローチ
Henderson and Clark（１９９０）は、このように既存の部品間のつなぎ方の見直しによってイノベー
は、開発タスクのパーティショニングの改善を図
ションを実現することをアーキテクチュアル・イ
ることである。タスク DSM により、まず現状の― 35 ―

表２

DSM を用いた製品開発研究

文献名

記述方式

DSMタイプ

分析手法

分析対象

研究概要

Becker, et al.
（２０００）

パラメータ、コン ２値
ポーネント、
タスク

クラスタリング、パー 仮想事例
ティショニング

Browning, T. R
（２００１）

コンポーネント、
チーム、
タスク、
パラメータ

２値

クラスタリング、パー 自動車用空調システム、 複雑な PD の分析手法としての DSM のレビュー。製
ティショニング、テア 自動車エンジン開発組織、品- 組織―プロセスのアーキテクチャの相互関係を整リング
自動車設計、ロボットアー 理。実用面での障害を明確化。
ム/ ハウジング

Browning, T. R
（２００２）

タスク
（活動）

２値

パーティショニング 仮想例（作 業 順 序 の 順 列化；手戻りの削減）

Clarkson and
Hamilton（２０００）

タスク

２値

繰り返し作業の記述

Cronemyr, et al.
（２００１）

タスク

数値（タスク所要時間、繰り返し 所要時間シミュレー ガスタービン用ブレードの確率［０＜P＜１］）ション
開発、航空機開発におけるサプライヤーとの協業
関係

複雑なシステム設計における構成要素間のインターフェースを削減するための手法の開発。独自アルゴリ
ズムにより、インタフェース最小化。

製品開発の複雑なプロセスを記述するツールとしてプロセスの最適化（同期化、統合化）をDSMを提示。
図る方法論を提示。

ヘリコプターのローター設 複雑なPDにおける最適な設計開発作業の道筋づくり
計のため、DSMによるタスクの依存関係の記述を提言。
PD プロセスの改善がリードタイムに与える影響をシ
ミュレーション分析。! 繰り返しの削減、" タスクの遂
行時間の短縮がリードタイム短縮にもたらすインパクトを定量的に計測。

Eppinger, S. D. and タスク、チーム、
V. Salminen（２００１） コンポーネント−

クラスタリング、
パーティショニング

空調システム、エンジンコ 複雑な PDを製品―プロセス―組織の３つの視点かンパートメント、新型自動 ら記述するアプローチの提示。
車エンジン、ジェットエン
ジン、電子部品

Kusiak（２００２）

コンポーネント
タスク
（活動）

２値

クラスタリング
パーティショニング

仮想例

モジュラリティを実現するための方法論の提示。製品モデル―（開発）プロセスモデル―資源モデルの相互依存性に着目。

McCord, K. R. and
S. D. Eppinger（１９９３）

チーム

数値（情報交換：高、中、低）クラスタリング

自動車用 V8 エンジン
（GM）、
ラップトップ PC

複雑なPDプロセスにおいて、プロジェクトの底辺にある技術的な構造を踏まえた上で、タスクの統合や調整を適切に行う方法を提示。

Pimmler, T. U. and
S. D. Eppinger（１９９４）

コンポーネント

数値（必要＋２、望ましい＋１、中立 クラスタリング
０、望ましくない−１、有害−２）

自動車用空調システム（Ford）

複雑な PDプロセスにおいて適切に要素分解し統合するための分析手法の開発。適切な製品アーキテク
チャと開発組織構造の創出と選択の方法論を提示。

クラスタリング

産業用ガスタービン

複雑な製品アーキテクチャを記述し、その特性を掴むための方法論の確率。クラスタリングにおける恣意性の軽減、分析精度の向上。

産業用ガスタービン

クラスタリング・アルゴリズムの改善。モジュールの境界、経路依存性、ディメンショナリティを考慮に入れる
ことで自動クラスタリングアルゴリズムの弱点を補完。

（３１ 数値（４段階：０,１,２,３）
Sharman, D. M. and コンポーネントのサブシステムでA. A. Yassine（２００４）
構成）
Sharman, et al.
（２００２）

コンポーネント

２値→数値（高３、中２、低１、無０） クラスタリング

Smith, R. P. and
S. D. Eppinger（１９９７a）

タスク

数値（タスク遂行所要時間、タス 並び替え（順列化） 自動車ブレーキシステム
クやり直し確率：０５. , ０２. ５, ００. ５） 所要時間シミュレーション

Smith, R. P. and
S. D. Eppinger（１９９７b）

タスク

数値（タスク遂行所要時間、タス 並び替え（順列化） 仮 想 事 例（Steward 複雑なPDにおける逐次的な作業の繰り返しを記述し、
クやり直し確率）
所要時間シミュレー [１９８１] の電 気 自 動 車 開 作業順序の見直しなどにより、リードタイムの短縮を図
ション
発の仮想プロジェクト）
るアルゴリズムを開発。

Sosa, et al.（２００３）

コンポーネント、チーム

・数値（必要＋２、望ましい＋１、中 クラスタリング、
航空機エンジンおよびそ 開発製品のモジュラーな部分と統合的な部分を峻別
立０、望ましくない−１、害がある−２） パーティショニング の開発組織
したうえ、適切な開発チームの組織化とチーム間のインターフェースを管理。
・２値：開発チーム間の調整の重 （順列化）
要性及び頻度

Sosa, et al.（２００４）

コンポーネント、チーム

デザイン：数値（−２、−１、０、＋１、 −
＋２）関係の性質（空間、構造、物質、
エネルギ、情報）
組織：数値（６点）→２値へ変換

Yassine, A. and
D. Braha（２００３）

タスク、チーム

２値

パーティショニング 通信産業のデータサービ DSMにより、PDにおけるタスクの繰り返し、オーバー（順列化）、クラスタリ ス開発、自動車シリンダー ラップ、分解と統合、問題解決の収斂について分析。
ング
ブロック開発、自動車エン 適切なタスク、チームのグループ化や順列化のポイン
ジン開発、自動車外観設 トを提示。
計

Yassine, et al.
（２０００）

タスク

数値

パーティショニング 自動車（フード［ボンネッ 複雑な PDにおける繰り返しタスクの削減。繰り返しを（順 列 化）、シ ミュ ト］設 計、シートベルト設 含むタスクブロックに、簡単な検証タスクを挿入するこレーション、DRFT
計）とにより、DSM の単純なパーティショニングよりも大幅に繰り返しを削減。

Yassine, et al.
（２００１）

タスク

数値（やり直し確率：１〜９）

パーティショニング 自動車（フード［ボンネッ 複雑な PDにおけるタスクの繰り返し確率の分析（順 列 化）、シ ミュ ト］設計）
レーション

Yassine, et al.
（２００３a）

チーム

数値（部品間の依存性：強・中・ 所要工数シミュレー 自動車（内外装）外観デ 複雑な PDにおける問題発生の記述と分析。問題解
弱・無→０.３, ０.２, ０.１, ０）
ション
ザイン
決の収束性を分析。

Yassine, et al.
（２００３b）

タスク、
コンポーネ ２値→数値
ント、パラメータ、
顧客ニーズ要素Yu, et al.（２００３）

コンポーネント

２値 / 数値

複雑なPDにおける同時並行的な作業の繰り返しを記述し、作業順序の見直しなどにより、リードタイムの短縮を図るアルゴリズムを開発。

航空機エンジンの詳細設 製品アーキテクチャと開発組織の構造の適合性の分計フェーズ
析。設計上・組織上の境界（boundary）が不適合（misalignment）の発生に有意に影響。

--

自動車用安全ベルト、自 PDプロセスにおける要素間（タスク、パラメータ、コン
動車シャシー
ポーネントなど）の依存性を多面的に記述する手法（CM：connectivity matrix）の開発。

クラスタリング

産業用ガスタービン（出所）筆者作成― 36 ―

複雑な製品システムをより高い精度で最適なクラスタ
リングするアルゴリズムの開発

「地域経済研究」第１７号、２００６

開発プロセスを記述し、次にパーティショニング
によってタスクの順列化を行うのが一般的な分析手順である。タスク DSM の対角線より上にある
印 X を対角線より下に移動させることにより、タ
スクのやり直しを低減するのである。
プロセス最適化の研究は、研究者の研究関心や専門分野などの違いによって研究アプローチにい
くつかのバラエティがある。
まず、パーティショニングのアルゴリズム開発に重点を置く研究がある（Becker, et al. ２０００;
Smith and Eppinger, １９９７a; Yu, et al. ２００３）。例えば、Smith and Eppinger（１９９７b）は、複雑な製品開発における逐次的なタスクの反復をタスク DSM
により記述し、作業順序の見直しなどにより開発
リードタイムを短縮するアルゴリズムを開発している。仮想的開発プロジェクトの分析を通じて、あるタスクの実行は強い依存性のある別のタスクの後に回すこと、所要時間の長いタスクはできる
だけ後にもっていくなどすることで、タスクの繰り返し確率の低減や繰り返しが生じた場合の所要時間の最小化が図れることを示した。
次に、タスクの繰り返し問題に対してより組織的な解決策を探る研究がある（Browning, ２００２;
Yassine, et al. ２０００; Yassine and Braha, ２００３）。現
実の製品開発プロセスにおいては、パーティショ
ニングによってすべての印 X を対角線より下に移動させることは不可能である。タスクの試行錯誤
的な繰り返しは不可避的に生じる現象であり、タスクの繰り返しを生産的に処理する組織的な対応が 必 要 で あ る（Eppinger, ２００１; Yassine andBraha, ２００３）。
そうした組織的な解決策の一つに、ティアリン
グ（tearing）という手法がある。タスク DSM では、対角線より上にある印 X がフィードバック・
ループを表す。対角線よりも上に印 X が密集しているような場合、そこには多重的なフィードバッ
ク・ループが存在する。ティアリングは、大きなフィードバック・ループが存在するプロセスにおいて、そのフィードバックの核となっている依存関係を抽出し、その依存関係を除去することにより、フィードバック・ループを解消、もしくは経済的に管理可能なレベルに抑制する手法である（Yassine, ２００４）。
どの依存関係をいかにティアリングするかは、

DSM 分析だけからは導き出すことはできない。組
織的な解決策とセットで考える必要がある。２つのタスクの間にフィードバック・ループが存在す
る場合、前工程のタスクは、後工程のタスクからのフィードバック内容を推測して、実行される。
この推測の精度が高ければ、タスクのやり直しの確率や度合いが低減される。コンカレント・エン
ジニアリングやデザインレビューなどは、上流と下流のタスクの間で情報共有するための組織的な方法といえる。Yassine and Braha （２００３）は、
DSM 分析を応用して、開発プロセスにおける効果的なコンカレント・エンジニアリングの方法を提示している。また、Yassine, et al.（２０００）は、開発プロセスの中に小さな検証タスクを挿入することにより、間違った仮定に基づいてタスクが進行する確率を低減させることで、タスクの繰り返しを抑制する方法を分析している。
最後に、プロセス最適化の成果をシミュレー
ションにより定量的に計測する研究アプローチがある（Cronemyr, et al. ２００１; Smith and Eppinger,
１９９７a; Smith and Eppinger, １９９７b; Yassine, et al.
２０００; Yassine, et al. ２００１; Yassine, et al. ２００３）。各
タスクの平均所要時間と依存関係にあるタスクのやり直し確率（０＜ P ＜１）を計測し、このデー
タをもとにモンテカルロ法などのシミュレーショ
ン手法を活用して、開発リードタイムや所要工数などを確率的に導き出すのである。前述のアルゴ
リズム研究や組織分析の多くは、シミュレーショ
ン分析を併用して、タスク DSM の改善効果の定
量的な検証を行っている。

４．DSM の限界点
DSM は、製品開発において生じる複雑性を記述し分析する強力な分析ツールである。DSM は要素間の複雑な依存関係を解きほぐし、行列形式で記述することができる。記述する情報の簡潔性、一
覧性、操作性に DSM の利点がある。
しかし、DSM は万能な分析手法ではない。
DSM の簡潔性や操作性は、製品開発に関するある種の情報を捨象することによって得られる利点であり、そのことは同時にこの分析手法の限界にもなる。以下では、DSM 分析の限界点や留意点について若干の考察を行う。

― 37 ―

（１） 依存関係の予見可能性について
DSM 分析は、要素間の依存関係がある程度、特定可能あるいは予見可能であることを前提としている。基本的に、DSM の作成は既存の開発製品や開発プロジェクトをベースとして、構成要素を定義したり要素間の依存関係を特定したりする。したがって、技術的に安定し、定期的にモデルチェ
ンジを繰り返す自動車のような製品の開発においては、部品間あるいはタスク間の依存関係は相対的に安定しており、新規開発製品の DSM を作成することは比較的容易である。
しかし、製品開発の新規性が高まるほど、部品間にどのような依存関係があるのか、あるいはタスク間でどのような繰り返しが生じるのかを特定することは難しくなる。製品開発の新規性は、新規導入の要素の多さおよび製品アーキテクチャの変化幅の大きさによって規定される。
新規に導入される技術や部品が多くなるほど、要素間に存在する依存関係を特定していくのが難しくなっていく。個々の要素は、しばしば２つ以上の依存関係を持つために、新規の要素の導入は、より多くの未知の依存関係を生み出すからである。
この時、新規の要素がもたらす未知の依存関係の影響は、製品アーキテクチャの特性によって異なると考えられる。開発製品の製品アーキテク
チャがインテグラル型の場合、新規要素の導入に伴う未知の依存関係は、他の多くの要素に波及的に影響を与える可能性がある。一方、モジュラー型の場合、新規要素が特定のモジュールの中で採用された場合、未知の依存性があったとしてもその影響はモジュール内に止められる。しかし、新規要素がインターフェースに関わるものである場
合、未知の依存関係の存在は製品システム全体に影響を与えることになる。
また、開発製品の大部分が既知の要素により構成される場合でも、要素間の関係性に多大な不確実性が生じる可能性がある。製品アーキテクチャが大幅に変更された場合である。大幅に変更された製品アーキテクチャのもとで初めて DSM を作成するような場合には、要素の間に多くの未知の依存関係が隠されることになろう。
こうした DSM の特徴から、DSM の活用においては、次の２点に注意する必要がある。
第一に、新規性が高く要素間の依存関係を十分に特定できないような場合においては、DSM の活用は限定的な用途に限る必要がある。新規の製品開発においても、全く新規に導入される技術や部品は限られており、その他の大部分の要素は既存のものが使われるのが一般的である。したがって、
DSM の作成を通じて、既存の分かっている部分と新規の分かっていない部分とを峻別することにより、未知の依存関係が生じるかもしれない管理ポ
イントを割り出す目安とすることはできる。新規性の高い製品開発においても、このように DSMをある種の参照情報と活用することは有効である。
しかし第二に、新規性の高い製品開発の場合、作成される DSM はあくまでも仮説的なものである。どの部分にどのような依存関係があるかという仮説自体は、その組織やエンジニアの経験や理論的推論、予見力などによって導き出される。仮説的な依存関係や未知の依存関係があまりにも多くなると、クラスタリングやパーティショニングなどによって依存関係の最適化を行っても、現実の使用に耐える分析とはならない可能性が高い。
DSM は、存在が明らかになった依存関係が製品設計や開発プロセスにどのような影響をもたらすかを分析することはできるが、依存関係自体を特定化することはできないのである。
（２） スタティックな分析アプローチ
基本的に、DSM はスタティックな分析アプ
ローチである。現状のシステム構成の記述をベースとして、クラスタリングやパーティショニングといった手法により、構造やプロセスの改善を図るのが一般的な分析パターンである。
例えば、コンポーネント DSM を用いた製品モジュール化の分析では、現状の部品構成とそれらの依存関係を出発点として、それをクラスタリン
グすることで、モジュールの形成を図る。実現すべきパフォーマンスが一定である場合には、モジュール内での要素間の依存関係は密にし、モ
ジュール間の依存関係は最小化することで、開発製品のコスト、品質、利便性などの改善、開発生
産性の向上などの成果を漸進的に実現することが可能となる（図１１の（a）の部分）。
しかし、実現可能なパフォーマンスのレベル自体を高めたい場合、既存のシステム構成の最適化
だけでは十分でない（図１１の（b）の部分）。新規― 38 ―

「地域経済研究」第１７号、２００６
図１１ DSM による改善とパフォーマンスとの関係（出所）筆者作成（３） 情報フローと知識蓄積について性の高い部品やサブシステムの導入、あるいは新しい観点からのモジュールの切り分け（クラスタDSM 研究における主要な命題の一つに、製品アーキテクチャと組織構造の同型化がある。すなリング）が必要になってくる。このような場合、
わち、製品開発の生産性を高めるためには、組織
既存のシステム構成に基づいた DSM の分析から構造の DSM は、コンポーネント DSM でとらえは、新たなパフォーマンス・レベルに対応した製られる部品やサブシステム間の依存関係と対応し品アーキテクチャを導出することはできない。
てなければならないということである。この命題
DSM とは別のロジックによる分析が必要である。
は、開発チーム間のコミュニケーションの効率化
要素の積み上げや改善だけでは、システム全体のやタスク間の情報フローの改善の面では、効果の最適化を必ずしも実現できないからである（柴田高い方策である。
他、２００２）。
しかし、知識の蓄積面を考えると、製品アーキ
DSM は、現状のシステムを記述し、問題のあるテクチャと同型化した組織編制が常に効果的とは箇所を特定するには適した手法である。クラスタ
限らない。コンポーネント DSM が表示するのは、リングやパーティショニングなどにより、現状のあくまでも要素間の依存関係であり、要素自体のシステム構成の下で改善を積み重ねることはできる。そして、その改善が一定の閾値まで達した時、 複雑性や重要性に関する情報は捨象されている７）。
要素間の依存関係を最適化する観点からは、例え
新たな製品アーキテクチャへと移行する契機とな
ば、開発プロジェクトごとに担当チーム間のコる可能性はある。しかし、DSM 自体には新たなミュニケーションを最適化するように、組織をそアーキテクチャを創出するロジックは含まれておの都度組み直すことは有効かもしれない。しかし、らず、むしろ漸進的なアーキテクチャの変化を強ある部品やサブシステムの開発に非常に深い専門化する。基本的に DSM は、既存の要素の並び替性や経験蓄積を必要とするような場合には、プロえを中心にして構造やプロセスの最適化を図る手
ジェクト・ベースのコミュニケーション効率をあ法であるからである。DSM によって捉えられた既る程度犠牲にしても専門性や経験蓄積を重視した
存のアーキテクチャの課題や限界を乗り越えるには、DSM とは別のロジックからのアプローチが必要である６）。
６）例えば、柴田他（２００２）は、「分断による学習」という概念を提起し、新たな製品アーキテクチャの創出には、実際に製品システムを要素へと分割していく設
計行為の繰り返しを通じてシステムレベルの知識を組織的に積み上げていく必要があることを指摘している。
７）タスク DSM では、タスク実行の所要時間や工数の形で、個々の要素の特性が記述されることがあるが、コンポーネント DSM ではコンポーネント自体の特性について記述を与えている既存研究は、本稿でレビューした範囲では見つけられなかった。

― 39 ―

強みを発揮する。従来の研究では、製品アーキテ
組織編制が効果的になる可能性がある。技術の成クチャのモジュラー度やインテグラル度の判断は、熟性や信頼性が求められる自動車メーカーの多く
研究者自身の定性的な判断に依存する部分が大きが機能別組織をベースとした組織構造を採用してかった。DSM を活用することにより、より客観的いるのは、組織の知識蓄積を重視するという背景
で反証可能な分析を行うことが可能になり、製品があるからかもしれない。
アーキテクチャ分析の精度の向上に大きく貢献で既存の DSM 研究は、やや技術決定論的な傾向があり、組織の論理は必ずしも重視されていない。 きると考えられる。
組織の論理、例えば組織学習やモチベーションの
謝 辞
観点から考えると、むしろ製品アーキテクチャの方を組織構造に適した形に変換していくことも一
論文の執筆に当っては、二人の匿名のレフェ
つの方法である。このことは DSM 自体の方法論
リーから本稿に対し有益なコメントを頂いた。記上の問題というよりは、DSM の活用上の問題といして感謝申し上げたい。
える。いずれにしても、今後の DSM 研究におい
なお、本研究は平成１７年度科学研究費補助金ては、技術論と組織論との間でよりバランスのと（若手研究（B））［課題番号：１７７３０２３５］の研究成れた分析フレームワークの設計が重要である。
果の一部である。

５．むすび
製品開発を複雑にする要因はさまざまである。
例えば、顧客ニーズの複雑性や多義性、部品やサブシステム自体の技術的複雑性、個々の開発タス
クの複雑性などの要因があげられる。現代の製品開発をとりわけ複雑にしているのは、これらの要因が相互に作用し合っていることである。部品と部品、タスクとタスクとの間で相互的な依存関係があり、ある一つの部品やタスクにおける変更が他の部分へと波状的に影響を与えるのである。
DSM は、こうした要素間の依存関係を網羅的かつ簡潔に記述する分析ツールである。分析対象に応じて、コンポーネント DSM、チーム DSM、タスク DSM、パラメータ DSM などがあり、構造の最適化には主にクラスタリング、プロセスの最適化にはパーティショニングといった分析手法が用いられる。製品開発の他の手法と比較した DSMの利点は、記述する情報の網羅性、簡潔性、一覧性、操作性の良さにある。
ただし、DSM は分析手法の一つに過ぎず、製品開発のすべてを分析できるわけではない。DSM には、要素間の未知の依存関係に対する脆弱性、ス
タティックな分析アプローチ、組織の知識蓄積に関する分析の弱さといった限界点がある。
しかし、こうした制約にもかかわらず、DSM は非常に強力な分析ツールであることに変わりはない。とりわけ、製品アーキテクチャ分析において

参考文献［１］Baldwin, C. Y. and K. B. Clark (2000). Design
Rules: The Power of Modularity, The MIT Press.
［２］Becker, O., J. Ben-Asher, and I. Ackerman (2000).
“A model for system interface reduction using N2
charts,” Systems Engineering, 3, 27–37.
［３］Browning, T. R. (1998). “Integrative mochanisms
for multiteam integration: Findings from five casestudies,” Systems Engineering, 1, 95–112.
［４］Browning, T. R. (2001). “Applying the design structure matrix to system decomposition and integration problems: A review and new direction,” IEEE
Transactions on Engineering Management, 48 (3),292–306.
［５］Browning, T. R. (2002). “Process integration using
the design structure matrix,” Systems Engineering,
5 (3), 180–193.
［６］Clarkson, P. J. and J. R. Hamilton (2000). “Signposting’, A parameter-driven task-based model ofthe design process,” Research in Engineerign
Design, 12, 18–38.
［７］Cronemyr, P., A. O. Ronnback and S. D. Eppinger(2001). “A decision support tool for predicting theimpact of development process improvements,”
Journal of Engineering Design, 12 (3), 177–199.
［８］Eppinger, S. D. (2001). “Innovation at the speed of
information,” Harvard Business Review, 79 (1), 149–
158.
［９］Eppinger, S. D. and V. Salminen (2001). “Patterns
of product development interactions,” Proceedingsof International Conference on Engineering
Design, Glasgow, Aug. 21–23, 2001.

― 40 ―

「地域経済研究」第１７号、２００６［１０］Henderson, R. M. and K. B. Clark (1990). “Architectural innovation: The reconfiguration of existingproduct technologies and the failure of establishedfirms,” Administrative Science Quarterly, 35, 9–30.
［１１］Kusiak, A. (2002). “Integrated product and process
design: A modularity perspective,” Journal of Engineering design, 13 (3), 223–231.
［１２］McCord, K. R. and S. D. Eppinger (1993). “Managing the integration problem in concurrent engineering,” MIT, Sloan School of Management Working
Paper #3594［１３］Pimmler, T. U. and S. D. Eppinger (1994). “Integration analysis of product decompositions,” ASME
Design Theory and Methodology Conference, Minneapolis, MN, September 1994.
［１４］Sharman, D. M. and A. A. Yassine (2004). “Characterizing complex product architectures,” Systems
Engineering, 7 (1), 35–60.
［１５］Sharman, D. M., A. A. Yassine, and P. Carlile(2002). “Characterizing modular architectures, Proceedings of DETC ’02: ASME 2002 International
Design Engineering Technical Conferences andDesign Theory & Methodology Conference, Montreal, Canada, Sep. 29–Oct. 2, 2002.
［１６］Smith, R. P. and S. D. Eppinger (1997a). “Identifying controlling features of engineering design iteration,” Management Science, 43 (3), 276–293.
［１７］Smith, R. P. and S. D. Eppinger (1997b). “A predictive model of sequential iteration in engineering
design,” Management Science, 43 (8), 1104–1120.
［１８］Sosa, M. E., S. D. Eppinger and C. M. Rowles(2003). “Identifying modular and integrative systems and their impact on design team interactions,” Journal of Mechanical Design, 125, 240–252.
［１９］Sosa, M. E., S. D. Eppinger and C. M. Rowles(2004). “The misalignment of product architecture
and organizational structure in complex productdevelopment,” Management Science, 50 (12), 1674–
1689.
［２０］Steward, D. V. (1981). Systems Analysis and Management: Structure, Strategy and Design, Petrocelli
Books, Inc.
［２１］Ulrich, K. (1995). “The role of product architecture in the manufacturing firm,” Research Policy,
24, 419–440.
［２２］Ulrich, K. and S. D. Eppinger (2000). Product
Design and Development (2nd Ed.), The McGrawHill.
［２３］Von Hippel, E. (1990). “Task partitioning: An innovation process variable,” Research Policy, 19, 407–
418.
［２４］Yassine, A. A. (2004). “An introduction to model-

ing and analyzing complex product development
processes using the design structre matrix (DSM)
method,” Quaderni Di Management (Italian Management Review), 9. (English translation ver.)［２５］Yassine, A. and D. Braha (2003). “Complex concurrent engineering and the design structure matrix
method.” Concurrent Engineering, 11 (3).
［２６］Yassine, A., D.E. Whitney, J. Lavine, and T. Zambito(2000). “Do-it-Right-First-Time (DRFT) approachto design structure matrix (DSM) restructuring,”
Proceedings of DETC ’00: ASME 2000 International Design Engineering Technical Conferences
and Computers and Information in Engineering
Conference, Baltimore, Maryland, Sep. 10–13,
2000.
［２７］Yassine, A., D.E. Whitney, J. Lavine, and T. Zambito(2001). “Assessment of rework probabilities for
simulating product development processes using
the design structrue matrix (DSM),” Proceedingsof DETC ’01: ASME 2001 International Design
Engineering Technical Conferences and Computers and Information in Engineering Conference,
Pittsburgh, Pennsylvania, Sep. 9–12, 2001.
［２８］Yassine, A., D. Whitney, S. Daleiden and J. Lavine(2003). “Connectivity maps: Modeling and analysing relationships in product development processes,” Journal of Engineering design, 14 (3), 377–
394.
［２９］Yassine, A., N. Joglekar, D. Braha, S. Eppinger,
and D. Whitney (2003). “Information hiding in
product development: The design churn effect,”Research in Engineerign Design, 14, 145–161.
［３０］Yu, T., A. A. Yassine, and D. E. Goldberg (2003).
“A genetic algorithm for developing modular product architectures,” Proceedings of DETC ’03:
ASME 2003 International Design Engineering
Technical Conferences and Computers and Information in Engineering Conference, Chicago, Illinois USA, Sep. 2–6, 2003.
［３１］足立 泰（２００４）「開発プロセスの改革手法『DSM』
第１回、第２回」『日経デジタルエンジニアリング』
２００４年２月号、３月号［３２］柴田友厚・玄場公規・児玉文雄（２００２）『製品アー
キテクチャの進化論』白桃書房［３３］藤本隆宏（２００１）『生産マネジメント入門（Ⅱ）』日本経済新聞社［３４］藤本隆宏・武石 彰・青島矢一編（２００１）『ビジネ
ス・アーキテクチャ』有斐閣［３５］目代武史（２００５）「広島地域における自動車部品モジュール化の動向と地場部品メーカーの対応」『地域経済研究』１６号― 41 ―

A Review on the Design Structure Matrix as an Analytical
Tool for Product Development Management
MOKUDAI Takefumi*
Research Assistant, Center for Research on Regional Economic Systems,
Graduate School of Social Sciences, Hiroshima University

Abstract
This article reviews fundamental concepts and analytical techniques of design structure matrix (DSM) as
well as recent development of DSM studies. The DSM is a matrix representation of relationships between
components of a complex system, such as products, development organizations and processes. Depending on targets of analysis, there are four basic types of DSM: Component-based DSM, Team-based DSM,
Task-based DSM, and Parameter-based DSM.
There are two streams of recent DSM studies: 1) optimization of product design and organizational structure and 2) optimization of development process. The former employs clustering, whereas the latter does
partitioning.
The advantages of the DSMs, compared with other analysis tools, are its conciseness, completeness, andoperationality. However, DSMs are not a panacea. The article also discusses some constraints of theDSMs, such as its vulnerability to unknown dependency between components, a static nature of the analytical approach, and relatively weak implications for organizational learning.
Key words: design structure matrix, product development, product architecture* Corresponding author: mokudai@hiroshima-u.ac.jp― 42 ―