MMRCDISCUSSION PAPER SERIES
No. 267

製品開発における分業構造とプロセスの相互関係-製品開発プロセスにおける重層的問題解決の構造東京大学大学院経済学研究科企業・市場専攻
博士課程 東 秀忠
2009 年 7 月

東京大学ものづくり経営研究センター
Manufacturing Management Research Center (MMRC)
ディスカッション･ペーパー･シリーズは未定稿を議論を目的として公開しているものである。引用・複写の際には著者の了解を得られたい。
http://merc.e.u-tokyo.ac.jp/mmrc/dp/index.html

製品開発における分業構造とプロセスの相互関係-製品開発プロセスにおける重層的問題解決の構造“Multi-layered problem solving” in new product development: process and structure of task
allocation that maximize the profit of communication.
東京大学大学院経済学研究科 企業・市場専攻 博士課程 東 秀忠

要旨
製品開発プロセスに関する諸研究の多くは、「連携調整の利益」と「過剰分業の弊害」を指摘している。一方で、製品開発組織における分業構造についてはこれまであまり言及がされてこなかった。
本稿で筆者は、日本自動車メーカーにおける製品開発プロセスを、特に「実験部門」の視座から描写することを通じて製品開発組織における分業構造と製品開発のパフォーマンスとの相互関係を検討した。
本稿の主張は大きく分けて2点である。第一には、製品開発組織における分業構造の再検討である。既存研究は「各機能部門が問題解決サイクルの各ステップに特化し、連携調整を通じて問題解決を遂行する」という前提に立つ物が多いが、実際には各機能部門がそれぞれ独力で、異なる種類の問題を解決しているという並行分業の構造がそこには存在いる。このことより、分業度のみならず、分業構造もまた、製品開発のパフォーマンスに影響を与えていると考えられる。
第二には、製品開発プロセスにおける「重層的問題解決サイクル」の存在である。各機能部門が独力時遂行する「小さな問題解決サイクル」の成果を統合するために、各機能部門が緊密に連携調整を行う「大きな問題解決サイクル」が存在しているという重層構造が、製品開発プロセスには存在していると言える。

Abstract:
Many researchers have emphasized the "profit of communication" and "loss ofover-division of labor" in new product development process. However fewer articles
discussed on the structure of task allocation in product development organization.
In this paper author tries to examine the interplay between the process and the structureof task allocation by describing the detailed process of product development in someJapanese automotive OEMs focusing on testing division.
There are two major findings in this paper. One is the "Multi-layered problem solving."
Two types of problem solving cycle construct the multi-layered structure. One is the"Micro problem-solving," which is done inside of each division. And the other is the"Macro problem-solving," which integrates the outcome of Micro problem-solving.
The other finding is the horizontal structure of task allocation. Each functional division
runs the Micro problem-solving by themselves and relies the other divisions less. AndHeavyweight product manager integrates the outcome of Micro problem-solving throughintensive communication among divisions.
キーワード：自動車・製品開発・問題解決・実験・重量級プロダクトマネジャー・分業・連携調整
Key word: Automotive, Product development, Problem solving, Experimentation, Heavy Weight
Product Manager, Task allocation, Communication, Coordination,

1

1. 問題意識
本稿は、自動車の製品開発組織における部門間の分業構造に関するケーススタディを通じて、分業構造と製品開発のパフォーマンスとの関係に関する議論の出発点となることを目指す物である。本稿の基礎となる問題意識は、「専門化の経済性と連携調整の利益を両立するためにはどのような条件が求められるのか？」ということにある。
製品開発組織に関する研究はこの20年の間、つねに経営学の分野における主たる研究分野の一つであり続けてきた。そこで一貫して論ぜられてきたのは、「連携調整の利益」と「過剰分業の弊害」である。すなわち、「適切な分業度」で、かつ「緊密な連携調整」を行うことが製品開発のパフォーマンスを高めるという主張である。
しかしながら、製品開発プロセスに関する研究が多い一方で製品開発組織の分業構造そのものについては相対的にあまり検討が為されていない感がある。本論において、筆者は製品開発組織の中でも特に自動車メーカーの製品開発組織における「実験部門」に焦点を当てて詳細な描写を行うことを通じて、製品開発組織の分業構造と製品開発プロセスのあり方について再検討を行う。

2. 製品開発組織における分業と連携調整に関する既存研究2.1. 分析の視座：「問題解決サイクルの束」としての製品開発活動
本稿では製品開発プロセスを描写・分析するにあたり、Clark&Fujioto(1991)が提唱している「問題解決サイクルの束としての製品開発」のモデルに立脚する。これは、Simon(1969)が定式化した問題解決サイクルに対して製品開発組織における各機能部門を割り当て、「問題認識→代替案のサーチ→モデル制作→シミュレーション実行→評価→選択」という各ステップをそれぞれ設計部門、試作部門、実験部門が担当する、というモデルである。不完全な因果知識の元でコンセプト実現のための解を探索するという製品開発プロセスは、まさにこのような探索的問題解決サイクルの束であると指摘している。そして、この「問題解決サイクルの束」としての製品開発活動というモデルは多くの既存研究が前提とするものとなっている。

本稿は、この既存研究の多くが前提としている「問題解決活動のステップに添った分業構造」を再検討し、製品開発組織における望ましい分業構造のあり方に示唆を与えることを目指す。

2

図1：「問題解決サイクルの束としての製品開発」

2.2. 製品開発組織のにおける連携調整と分業度
製品開発組織におけるコミュニケーションと連携調整の重要性についてはImai, Nonaka &Takeuchi(1985) や Clark&Fujimoto(1991) 以 来 、 様 々 に 行 わ れ て き た 。 Imai, Nonaka &Takeuchi(1985)は「ラグビー方式」という表現で日本メーカーの製品開発におけるコミュニケーションとその効果を表現し、Clark&Fujimoto(1991)においては、プロジェクトチーム内でのコミュニケーションに加えて、「オーバーラップ型開発」に代表される生産技術部門など他部門との緊密なコミュニケーションによる連携調整を重量級プロダクトマネジャーが強力に推進することで、製品開発組織が高いパフォーマンスを実現出来ると指摘している。
また、Thomke(1998)やThomke(2004)では、自動車の製品開発における衝突実験を例に取り、CAEの活用による問題解決のフロントローディングとクロスファンクショナルな実験チームの結成による開発リードタイムの短縮について詳しく議論している。即ち、問題発見と問題解決を迅速に行うためには実験部門、設計部門、CAE部門といった関連する各部門の担当者が緊密に連携を取りつつ学習を進めることで、問題解決サイクルが効率的に遂行されると主張している。

3

図2；分業とコミュニケーションによる問題解決サイクルの遂行

出典：Thomke(2004)より筆者が作成

2.3. 「分業度」と製品開発のパフォーマンス一方で。製品開発組織とそのパフォーマンスに関する理論の多くは、「過剰分業の弊害」をも説く。
その端緒ともなったのがBrooks(1975)である。Brooks(1975) は、コンピュータのソフトウェア開発プロジェクトを例に取り、「人月の神話」と呼ばれる現象の存在を提唱した。これは、調整ロスが発生しないような、完全に分割して独立に施行できるタスクであれば人員投入によるリードタイム短縮効果は大きいが、タスクの分割が不可能である場合には、プロジェクト人員に関わらずリードタイムは短縮できず、むしろタスク間の相互依存関係が大きくなるにつれ調整ロスが増大していくという現象である。そして一定の程度を越えると調整ロスが分業のメリットを上回り、人員投入量の増大とともに開発リードタイムが伸びてしまうのである。
そして、Clark&Fujimoto(1991)においても、プロジェクトの参加人数と製品開発パフォーマンスの関係を分析し、「プロジェクトへの参加者が少ないほど、プロジェクトのパフォーマンスが高い」という関係の存在を指摘している。プロジェクトへの参加者が多いほど調整による問題が発生しやすいとして、パフォーマンスの低いプロジェクトにおいては過剰分業が発生している可能性を示唆している。
伊藤（1995）はClark&Fujimoto(1991)が指摘した自動車産業における効率的な製品開発組織の4

在り方に関して、「重量級プロダクトマネジャー制」と「幅広い業務分担」という点に焦点を絞ってその理論的含意を検討している。業務分担の幅が広まることにより、分権的調整に基づく優位性が生まれる一方専門化の経済性は喪われる。しかし、業務間の相互依存関係が深まるほど、調整面での優位性に基づく利得が専門化の経済性による利得を上回ることとなり、「低い分業度」の持つ優位性を高めるのである。そして、その優位性は調整とコンセプト創出を強力に担保する「重量級プロダクトマネジャー」の存在によりさらに強化される。不確実性の高いタスクとしての製品開発活動を遂行する際にはエンジニアの活動を直接調整するよりも、より自律的に行われる調整の成果が首尾一貫性を担保することを確実にする方が容易かつ効果的だと指摘している。

2.4. 「分業構造」の観点から製品開発を分析することの意義だが、伊藤(1995)が指摘する、自立した問題解決活動を統合的に調整する、というモデルと、「プロセスの流れに沿った分業」と部門間の連携調整に基づく問題解決の実施という前提にはある種の齟齬が存在している。というのも、連携調整の節約を実現するために低い分業度が設定される一方で、問題解決サイクルを回すために連携調整が必要であるというのはある意味矛盾していると考えられるのである。特定の問題解決活動に焦点を当てた場合、既存研究が前提してきた分業構造では過剰分業が発生しかねない。
このことは、製品開発のパフォーマンスを説明するために単に「分業度」を測定するにとどまらず、プロセスの面から見た「分業構造」を分析する必要性を示唆しているといえる。

これに関連して、Loch&Terwiesch(1999)は、製品開発組織におけるプロセスと分業構造の関係について、自動車用エアコンユニットのサプライヤーのケースから興味深い考察を提示している。調査対象企業における設計変更のリードタイムを短縮するために、プロセスを詳細に分析した上で待ち行列理論や制約条件理論を利用して最適化を図ったケースである。各プロセスのリードタイムが短い一方、プロセス間の待ち時間が長いことがリードタイムを延ばす主因であり、その改善のために「業務の統合」や、「部門間での業務の再配分」を行ったところ、リードタイムが大幅に縮んだと指摘している。このケースで社、エンジニアを追加せずに生産性が向上している。換言すれば、Loch&Terwiesch(1999)は製品開発組織において、分業度を一定とするならば分業構造がそのパフォーマンスに対して重要な影響を与えることを示唆しているといえる。
では、製品開発組織において求められる適切な分業構造と連携調整の在り方とはどのようなものなのか。本論文では日本自動車産業の製品開発組織におけるケースを取り上げることを通じて、一つの仮説を提示する。

3. ケース分析：日系自動車メーカーにおける製品開発組織と実験部門の在り方
本節においては、日系自動車メーカーにおける製品開発組織と実験部門の在り方についてのケーススタディに基づく描写を行う。筆者は本論文のために2社の自動車メーカーの計7名（A社1名、B社6名）に対して、計12時間のインタビュー調査を行っている。

3.1. ケース1：A社の製品開発組織における実験担当者の業務の進め方
A社は日本の中堅自動車メーカーであり、その製品開発組織にはClark&Fujimoto(1991)が指摘5

する「重量級プロダクトマネジャー制」を採用している。また、実験部門は大まかには「エンジン・パワートレーン」と「車体」に分かれており、それぞれの中に「NVH」、「操縦安定性」など自動車の評価基準ごとに得意分野が異なるグループがいる。たとえば操縦安定性を得意とする人がいてグループを形成している。同社には「テストドライバー」という職種は存在せず、実験は全て技術者により行われる。そもそも同社の製品開発組織においてはいわゆるブルーカラーの技能職を設定していない。
製品開発プロジェクトの中心となるべき技術者は、プロジェクトリーダーによって指名される。
「うちの会社では、プロジェクトチームは「内閣」の様な物だと考えています。プロジェクトリーダーが総理大臣で、中核を担うメンバーをまさに『組閣』の要領で選んでいきます。その際には走行性能や振動・騒音といった各領域について、予算と権限を持った『大臣』を設計部門と実験部門から一人ずつ選んでいく形を取ります。『大臣』は、担当する領域の性能などについて責任を負います。」
製品のコンセプトを決定し、開発試作車を作成するまでにはプロジェクトの中核メンバーが全員参加する会議にて徹底的に議論を行い、コンセプトに関する共通の理解を深めていく。その上で、コンセプトを実現する為の性能をある程度設計担当者が図面を作成し、開発試作車を生み出す。
開発試作車が完成したら、実験担当者が実際に試作車での実験を始める。
そして、そのグループから指名されたプロジェクトメンバーが予算と権限を持って、自分の手で製品を改良するのである。たとえば、振動騒音担当の場合は以下のような流れでもって改良がすすんでいく。
まず、完成した試作車を実際に運転し、問題点を発見するところから実験担当者の仕事は始まる。
「あるモデルの振動騒音の実験を担当していたときの話です。ミーティングで、エンジンから振動と異音は出ているという話を聞いたのでまず自分で試作車を走らせてみます。そうすれば原因がある程度予想できて、キャブレターの周辺が怪しいと考えたわけです。それを確認するためにセンサーや測定器を試作車に取り付けてまた走る、というのを繰り返して原因を突き止めていきます。」
原因を突き止めたら、その問題を解決するために、自らの手で試作車を改造する。納得がいくまで試行錯誤を繰り返して、問題点を解決する。
「測定の結果を分析してみると、やはりキャブレターが原因だった。キャブレターが振動して周囲にぶつかることで振動と異音が発生していることがわかりました。これを解決するために、実験場においてある鉄棒やボルトナットを使って自分で支えとなる棒を作りました。これは他の部門に頼んだりせず自分でやります。実験の担当者は皆、そういった作業が出来るし、しなければならない。」「問題点を設計担当者に説明して、改良案を出してもらったりはしないのか？」という疑問に対しては、以下の通りの返答であった。

6

「設計担当者は設計図を書いたり生産技術部門との調整をしたりすることに忙しく、部品の改造までは頼めません。ただ、必要に応じて実験への立ち会いや、手伝いを頼むことはあります。また、よほど大がかりなものでなければ試作部門にも頼りません。」
満足のいく改良部品ができあがったら、その改良を採用するかどうかをプロジェクト全体で検討し、最終的にプロジェクトリーダーが決定を下す。
「部品を改造して、問題が解決したと考えられたらプロジェクトのミーティングに持っていきます。たいていの場合、いくつかの案を準備しておいて、ミーティングで一つを選ぶ事が多い。いずれにせよ、ミーティングでプロジェクトリーダーからOKをもらって初めて、改造した部品が設計担当者に渡されることになります」
プロジェクトのミーティングで採用が決まった改良点を量産車に導入するために、設計担当者は改良部品を受け取ってそれを解析し、量産に耐えうるものにする。それにもとづいて、部品の図面が更新される。
「設計担当者は、受け取った改良部品を解析して、性能を維持しつつコストや生産性を考慮した部品にしていくのが仕事です。それが図面に反映されると全ての試作車にとりつけられて、更に改良が進んでいきます。」

以上の様な流れで、製品開発のプロセスが進んでいくことになる。

3.2. ケース2：B社の製品開発における実験プロセスとその組織
B社もまた、日本の中堅自動車メーカーであり、その製品開発組織においては「重量級プロダクトマネジャー制」を採用している。1990年代のB社では、実験部門はおおきく「実験企画」と「担当実験」の2部門に別れていた。A社と同様、実験担当者は全て技術員であり、試作車の運転や改良を一手に引き受けることが出来る。
「実験企画」部門には製品の商品性を評価するグループがある。このグループは、コンセプトを体現した機能設計がどのようなものかをイメージとして周知する役割と、試作車を総合的に評価することを通して進行中の試作車育成活動が当初のコンセプトとずれてきていないかをチェックする役割とを持っている。いわば、重量級プロダクトマネジャーをコンセプト実現の側面でサポートを行う役柄である。
「実験企画の仕事は、試作車が目指すべき目標を総合的に設定して、それを他のプロジェクトメンバーに伝えることです。例えば、『人馬一体という言葉で表現されるべき自動車はこういった性能を実現しなければならない』というイメージを固めていきます。ただ、その目標はどちらかといえば大まかなものです。『人馬一体を実現するためにはサスペンションブッシュの横剛性がどの程度必要か？』といった具体的な所までは立ち入りません。それはどちらかといえば設計担当者の領分です。」

7一方で、「担当実験」部門の仕事は試作車を「育成」することである。これは、試作車の性能とコンセプトとのずれを、各担当の領域について修正していく作業を指す。

「試作車というものは、どれだけ周到に設計しても、出来てすぐはまだコンセプトを十分実現しているとは言い難いものです。そんな試作車を、実験しながら改良していって、最終的にコンセプトを実現できるようにするという意味で、『試作車を育成する』という表現を使います。例えば、操縦安定性の担当者だったらコーナーでのリアの挙動が『人馬一体』的でなかった場合に、それを修正していくわけです。」「担当実験」の技術者は、試作車を用いた実験を行うことで、想定していたコンセプトと実物の差異を比較する。コンセプトが実現されていると見なす事が出来るようになるまで、試作車の改良を繰り返すのである。このため、実験担当者は車両やコンセプトに対する認識が.重量級プロダクトマネジャーとずれていてはならない。B社では、このプロセスを「自覚症状」と「医者」の関係になぞらえていた。
「出来たばかりの設計図は、コンセプトとの間にずれが多い。けれども設計担当者はそれに気づいていません。つまり、『自覚症状のない患者』です。一方実験担当者は、いわば医者のようなものです。まずは言葉で設計担当者に「ここがこういう風にイメージとずれているぞ」と話をします。
それでも設計担当者が理解できないようなら、試作車に同乗させて説明をします。そうして設計担当者に、自らの設計と目指すべきコンセプトとの間のずれを認識してもらいます。」「そして「医者」と言うからには薬も出します。コンセプトを実現するような改良を図面に落とし込むために、手作りで改良部品を作って設計者に渡すのです。要するに、『この部品を使えばコンセプトを実現できますよ』ということを示すわけです。受け取った改良部品を元に、設計担当者はそれと等価の性能を持ち、かつコストや重量、製造性などを最適化した部品の図面を作成する事になります。」
改良部品を作るために、以前は実験部門の中に試作を専門に担当する要員が配置されていた。
必要なものはすぐ作ってくれるため、試行錯誤や試作車の改良が迅速に行えたのである。
「例えば試作部門に部品を作ってもらうとなると、まず図面を作らねばなりません。しかも上司に決済を仰いで、それから部品を作ってもらう、という流れになります。それに比べたら、自分たちの手で部品を改良できればその方が手っ取り早い。いちいち別の部署に話を通してまで改良をする気には、なかなかなりません。」
操縦安定性やNVH、乗り心地といった各種の要素について、「担当実験」の技術者がそれぞれ並行して改良を行う。このため各担当者によって行われた改良が、互いに矛盾を来してしまうことも少なくない。たとえば操縦安定性とNVHなどは相反した方向性の改良を行おうとする場合がある。
このようなことがないよう、「実験企画」がイニシアティブを取り、事前に話し合いを行うことでコンセプトとそれを実現する方向性に関して合意をまとめておく。合意形成における最終的な決定権は、重量級プロダクトマネジャーにある。

8

「プロジェクトリーダーと、実験企画の技術者が音頭を取って、『今度のモデルはこういう方向の味付けで行こう』という事を固めておきます。実験企画の技術者の仕事は、担当実験の技術者による改良が、その味付けから外れていないかを確認することにあるわけです。」「改良を行っていると、しばしばトレードオフが発生します。乗り心地を良くしようとして操縦安定性を犠牲にするような改良と、その逆に操縦安定性を高めるために乗り心地を犠牲にするような改良がそれぞれ出てきたりします。そういう対立が起こったときにはその都度会議を開いて、どちらの改良を採用するか、もしくは他の対策を考えるかということを決めていきます。最終的にはプロジェクトリーダーが判断することになります。」
こうしてできあがった改良については重量級プロダクトマネジャーによる審査を受ける。そしてその了承が取れて初めてその改良が図面に反映される。これは設計担当者の仕事である。担当実験の技術者が実現した性能を、コスト・重量・生産性といった面で最適化することが設計担当者の仕事である。
「一旦開発試作車が完成したら、製品開発の主役は実験担当者になります。一方、設計担当者は実験担当者のフォローに回ることになります。設計担当者の仕事は、「担当実験」が生み出した改良部品を、性能を維持しつつ量産対応させることと、図面を更新することです。」「「担当実験」が行う改良は、コンセプトを実現する性能を出すことに特化していて、コストや重量、生産性の面では実質使い物にならないのです。このため、設計部門も実験部門も、単独では設計変更を出来ません。設計担当者が設計変更を行うときは実験担当者の、実験担当者が設計変更を行うときには設計担当者の了解を得なければならないのです。」

4. 考察と含意
前節においては、実験部門における業務の進め方に焦点を当てて自動車メーカーにおける製品開発を描写した。これを通じて、自動車メーカーの製品開発組織、並びに製品開発プロセスに関する含意を検討する。

4.1.製品開発組織の分業度・分業構造と製品開発プロセスの相互関係
本稿で取り上げたいずれのケースにおいても、実験担当者の任務は「試作車を改良すること」と定義されていた。同時に、「実験担当者」を技能職ではなく技術職と捉えており、単純に実験を行い、そこから得られたデータを報告するのみならず、ある種の設計活動を行う技術者であると捉えられていた。つまり、実験担当者ないし実験部門は独力にて問題解決活動を遂行でき、それを実施していると言うことになる。
一方、設計担当者・設計部門の任務は部品のコスト・重量・生産性面での最適化である。つまり、設計部門は「実験部門が実現・提示した性能を維持しつつ、量産が可能なものへと設計を改良すること」が求められている。この活動そのものについても、設計部門は基本的に独力でそれを行っていると考えられる。
すなわち、いずれの部門も独力にて「問題解決」を行っているが、その内容と成果の面で異なる領域について責任を負っているということになる。そして、同時にこの事実からは、既存の製品開発組織に関する分業度の研究からは見えてこない職務の幅に関する示唆が確認できる。すなわ

9ち、問題解決のプロセスの面から検討すると、両社のケースともに、それぞれの部門が行う「活動の幅」が広いという点である。
自動車の製品開発組織における分業度に関する既存研究は、例えば特定の設計技術者が「左ヘッドランプのみ」を担当するのか、「ヘッドランプシステム全体」を担当するのか、といった担当する部品の面から見た業務の幅に着目している場合が多く、「その技術者が問題解決におけるプロセスをどの程度担当しているのか」といった面で業務の幅を検討しているものは相対的に少ない。
本稿のケースは、「プロセスの観点から見ても、製品開発組織における分業度はある程度低い方が、パフォーマンスを高めうる」という点を示唆しているといえる。
これらの事実は、Clark&Fujimoto(1991)などが前提としてきた「製品開発活動に際した問題解決サイクルを構成するステップ毎の分業」という分業構造との間に齟齬を来すものである。先に論じたとおり、既存研究においては設計部門が設計し、試作部門が試作した試作車に対して実験部門がそれを試験して、その結果や評価を設計担当者へフィードバックするという、「各部門がステップ毎に分業した上で連携調整に基づいた問題解決サイクル」が暗黙のうちに前提とされてきたが、実際にはこの前提と異なる形の分業構造が存在していたと言える。そして、既存研究の前提において発生しうる過剰分業を回避しているとも考えられる。
かくのごとき分業構造は、製品開発組織における諸研究で明確に指摘されてはいない。このような形の分業構造が、プロセス面での幅広い職務の幅と相まって製品開発のパフォーマンスに対して好影響を与えていると考えられる。

4.2. 製品開発プロジェクトにおける部門間の連携調整のあり方
前節では、「連携調整を必要としない問題解決活動」の存在と、それを実現するための製品開発組織における分業構造について指摘した。しかしそれは製品開発プロジェクトにおける連携調整の重要性を否定するものではない。
実験部門と設計部門はそれぞれ異なる種類の成果を実現し、それがプロジェクトマネジャーを通じた連携調整により連鎖することによって、全体としての製品開発プロセスに貢献している。すな
わち、製品開発プロジェクトにおいては、「連携調整を必要としない問題解決活動」と、「連携調整が必要となる問題解決活動」が併存しているのである。
伊藤(1995)は、製品開発組織において幅広い業務分担を採用することの利得として、タスクの相互依存性を軽減しつつ自立的に問題解決を行うことが出来るという点を指摘しているが、組織内の分業構造についてまでは詳細に議論してはいない。本稿は、伊藤(1995)が指摘する様な現象が発生するための必要条件としての分業構造のあり方に示唆を与えた物であるといえる。
本稿で筆者がとりわけ指摘したいのは、製品開発のパフォーマンスを説明する際に、分業度と分業構造の双方から検討を行うことが必要であるという点である。単に幅広い業務を分担するというだけの話ではなく、どのような形で自己完結的な業務をそれぞれのエンジニアに配分していくか、という点を明確にすることで、首尾一貫性の担保された連携調整が可能になるのである。

4.3. 製品開発プロセスにおける重層的問題解決
先述のケースから、両社の製品開発プロセスを概念的に表現すると以下の通りとなる。
1. 製品コンセプトが決まったら、まずそれに従って初期的設計が行われる。コンセプトを実現10するために必要と考えられる性能を想定し、それに基づいて設計図を作成する。一般に「詳細設計」と呼ばれるプロセスの前半部分がこれに当たる。これに基づき開発試作車が製作される。
2. 開発試作車が完成したら、実験部門が試作車を用いて実験を行う。この活動を通じて実験担当者は試作車と製品コンセプトの間の乖離や、商品性に関わる諸問題を発見し、その解決策を探索する。その成果として試作車に取り付けられていた部品を改良する。
3. 実験部門による改良の成果はプロジェクトメンバーによる会議で検討し、プロジェクトリーダーにより採用の可否が決定される。採用が決定したら、設計部門が改良部品を解析し、性能を維持した上でコスト、重量、生産性などの最適化を行い、設計図を更新する。更新された設計図に基づき部品が製作され、試作車が更新される。
4. プロセス2、３を繰り返して、試作車に製品コンセプトを実現する性能を達成させ、その部品を量産可能な物として設計図を完成させる。
これより、本ケースにおいては大別して2種類の問題解決サイクルが存在しているということが示唆される。一つは試作車を元にそれを改良し、設計図を更新するという「大きな問題解決サイクル」、そしてもう一つは実験部門、設計部門の担当者がそれぞれ独自に推進している「小さな問題解決サイクル」である。実験部門では「製品コンセプト実現のための性能の探索と達成」が、設計部門では「実験部門が実現した性能の量産化を実現すること」が「小さな問題解決サイクル」での任務となる。これを図で示すと以下のようになる。

11

図3：製品開発組織における重層的問題解決「小さな問題解決サイクル」を回す際には、基本的に担当者は独力でそれを行う。試行錯誤を行う中で、独力で試作車に対する小規模な改造を行いながら担当している領域における問題解決を進めていくのである。彼らがそれを独力で行うのは、「他部門を介するとその分だけ時間がかかる上、狙ったとおりのものが出てくるとは限らない」ためである。また、彼らが解決すべき問題の多くは音、振動や乗り心地など感覚的要素に頼りつつ問題を解決していくことが求められるものであるという点も大きい。これらより、彼らが解決すべき問題の特質として、「頻繁な試行錯誤を素早く行う必要がある」という点と「感覚的な要素が大きな位置を占めている」という2点が指摘できよう。
つまり、Von Hippel(1994)が指摘する「粘着性の高い情報」に基づく問題解決を行う際に、その粘着的な情報をそのままに取り扱うために、部門間での調整、コミュニケーションを介さずに問題解決を進めているということになる。
そして、このような「小さな問題解決サイクル」が並行して進みその解を統合する際にはプロジェクトメンバーの間のコンセンサスや重量級プロダクトマネジャーの了承が必要となる。これが「大きな問題解決サイクル」である。「大きな問題解決サイクル」を推進するためには、部門間の緊密なコミュニケーションや重量級プロダクトマネジャーの強力なリーダーシップが必要となる。重層的問題解決を構成する2種の問題解決サイクルは、それぞれが大きく異なる特徴を持っていると言えよう。

5. まとめと今後の課題
本論において、筆者は製品開発組織における分業構造とパフォーマンスの関係という観点から、新たな発見並びに仮説を提示した。第一に、実験部門と設計部門がそれぞれ異なった分野の成果を実現するために自己完結的に問題解決サイクルを遂行するという並行分業の構造が発見されたことが挙げられる。そして、製品開発活動は単なる問題解決サイクルの束と定義するのみでは足りず、異なる種類の問題解決サイクルが重層構造を為しているという可能性が提示された。

12つまり、自己完結的な「小さな問題解決サイクル」と、連携調整を通じて達成される「大きな問題解決サイクル」の重層構造が存在することが指摘されたのである。これにより製品開発プロセスにおける連携調整の重要性についても追認されたと考えられる。
また、本論の実務的なインプリケーションとしては、製品開発組織の設計に際してその分業構造を再検討し、組織に配置するべき人材に求められるスキルや知識の幅、育成方針などにおいて自律完結的に問題解決サイクルを遂行できるようにするという方向性を採用することの価値を提示している。とりわけ、実験担当者を技能職ではなく技術職として捉え、測定・評価にとどまらず部品の改良や機能設計に準ずる活動に携わらせる事が重要である。
本論の限界と今後の課題としては、以下の点が挙げられる。第一に、本論で取り上げたケースはその数並びに調査対象の面で限定的であり、一般化は尚早であると考えられる。また、第二にはサプライヤーによる製品開発活動への関与に関する検討が為されていない点が挙げられる。また、第三の点として、3次元CADやCAEなど、情報処理技術やツールの進展が製品開発組織並びにプロセスに与える影響に付いての検討が為されていない点も問題であると言えよう。これらについては今後のさらなる調査研究が必要である。

謝辞
本稿作成に当たり、インタビュー調査にご協力いただいたA社並びにB社の方々に心より感謝申し上げます。

参考文献
Brooks, Frederick P. Jr. (1975) The Mythical Man-Month. Addison-Wesley
Clark, K. B. & T. Fujimoto, (1991) Product Development Performance: Strategy, Organization, andManagement in the World Auto Industry.Harbard Business School Press, 邦訳, 藤本隆宏, キム・B・クラーク(1993) 『製品開発力』田村明比古 訳, ダイヤモンド社
H. Ito(1994), Coordination, Specialization, and Incentives in Product Development Organization,'' in M.
Aoki and R. Dore (eds.), The Japanese Firm: The Sources of Competitive Strength. Oxford UniversityPress, 邦訳, 伊藤秀史(1995)「製品開発組織における調整・分業化・インセンティブ」青木昌彦，ロナ
ルド・ドーア（編）『国際・学際研究 システムとしての日本企業』 NTT出版
Imai, K., I. Nonaka and H. Takeuchi. (1985). Managing the New Product DevelopmentProces: HowJapanese Learn and Unlearn. In K.B. Clark, R. H. Hayes and C. Lorenz (Eds.), The Uneasy Alliance:
Managing the Productivity-Technology Dilemma, HBS Press
Loch, C. H. & Terwiesch, C (1999) Acceralating the Process of Engineering Change Orders: Capacityand Congestion Effects, Journal of Product Innovation Management, 16, pp145-159
Simon, H. A. (1969) The Art of Artificial. MIT Press,邦訳,ハーバート・A・サイモン(2001)『システムの科学 第3版』稲葉元吉・吉原英樹 訳, パーソナルメディア
Thomke, S. H. (2004) Experimentation Matters: unlocking the potential of new technologies forinnovation. Harvard Business School Press
Thomke, S. H. & T. Fujimoto (2000) The Effect of Front-Loading Problem-Solving on ProductDevelopment Performance. Journal of Product Innovation Management 128-142,
Thomke, S. H. & 藤本隆宏 (1998) 「フロント・ローディング型問題解決による製品開発期間の短縮」,
CIRJE, CJ-1
von Hippel, E. (1994) Sticky information and the locus of problem solving. Management Science, 40,
pp429-439

13