イタレーションに関する先行研究

設計プロセスにおけるイタレーションが設計負荷の重要な要因であるにもかかわらず、

従来の設計管理手法ではイタレーションについて明確に言及していない。従って、多くの 複雑なシステムの開発プロジェクトではイタレーションに対する処理が行われてこなかっ た。そして設計プロセスのモデルにイタレーションを、十分反映させることが行われてこ なかった。

しかし全くないわけではない。後述する管理手法やツールが欧米を中心に提案されてき ているからである。そこで次項では先行研究で議論されているイタレーションに対する管 理手法、イタレーションの発生と含意、そして分類と効率化について述べる。

2.3.1 イタレーションと既存の管理手法 

企業は優れた製品を提供している間にも、製品開発にかける所要時間と所要コストの低 減を求める。その理由の一つはそれが競争の激しい市場に投入されているのであれば、競

概念設計

図2.6  一般設計プロセス

実体設計

詳細設計 要求仕様

設計解

争優位を継続させるために必要だからである。実際に、製品開発の効果的管理手法が存在 するなら、その企業の競争優位の持続につながる(Clark & Fujimoto, 1991; Clark, 1993;

Wheelwright, 1992）。設計プロセスを改善することの裏には、まず効率的な設計プロセスの 本質を理解することである。この目的を達成する為に、設計プロセス内のタスク間で生じ る設計知識や設計情報の流れを認識することが重要事項の一つである。その複雑な流れは、

タスク間で相互依存関係にあるか否かの活動として見ることができる。

タスクへの分解と統合化という作業は、作業プロセスの成功を左右する重要な意思決定 である(von Hippel, 1990）。製品開発における設計プロセスは、長年蓄積されてきた知識に基 づく手順に従ったものである。そして繰り返されてきたものでもある。従って、現在の設 計プロセスを見つめ直し、適切なプロセスのモデル修正と構築の検討が求められていると 言える。

複雑化しているシステムの設計プロセスの主たる特徴は、設計プロセス内部のタスク間 が相互に依存関係にあるものである。すなわち、この相互の依存関係とはタスク間のイタ レーションである。そしてその源泉は多くの研究者によって観察されている(Fredriksson, 1994; Peters, 1983; Safoutin & Smith, 1996; Singh et al., 1992; Susman, 1992; Whitney, 1990）。イ タレーションを持つ設計プロセスは、要求仕様書にできるだけ近づける様に繰り返される 設計過程でもある。現在では複雑な工業製品のシステムを設計する場合、一度も手戻り修 正せずに要求仕様書を完全に満足させて具現化させることは困難である。

従って多様な代替案が検討される。場合によっては、概念設計の初期段階に仮想的なプ ロトタイプを構築し、問題点を洗い出しておくこともある。その他に、プロセスの枠組み として明示的なイタレーションを予め含み入れておく場合もある(Alford, 1994; Blanchard &

Wolter, 1990; Clausing, 1994; DoD, 1992; DoD, 1994; Pugh, 1991; Shishko et al., 1995)。ただしこ の明示的なイタレーションとは順方向の手順で流れる一連のプロセスの中に組み込まれた ものである。そしてイタレーションの周期や回転の数は固定している。つまり、スケジュ ール的に確実に予測されたタスク集合である。これらは、不確実性を持ったイタレーショ ンに対処できる設計プロセス管理について多く言及されてはいない。

プロジェクト管理の枠組みでは、イタレーションを予め想定している手法は少ない。例 えば、設計プロセスのモデル化に一般的に利用されてきた PERT (Project Evaluation and

Review Technique)は、一方向の表現しかできない。PERTだけでなく、作業工程や処理の順

序を図式化したフローチャート図（flowchart:流れ図とも呼ぶ）もイタレーションを表現す ることができない。PERTやフローチャート図は元来、イタレーションの存在を想定してい なかったのである。

ただIDEF (Integration Definition for Function Modeling)の基本モデルは双方向の流れを表現 することが可能である。IDEFとは業務改革の推進と情報システム統合を目的としたビジネ ス・モデリング手法である。IDEFは1970年代初期に米国空軍のICAM (Integrated Computer Aided Manufacturing)プロジェクトで空軍の調達機材の製造にコンピュータを活用して効率

化を図ろうとした結果からまとめられた(Marca & McGowan,1988)。しかしこのIDEFは手戻 り方向、すなわち逆向き方向だけの表記はできない。従ってIDEFも潜在的にタスク間のイ タレーションを想定して開発はされてはこなかったのが実態である。もちろん、スケジュ ール管理の代表的ツールであるガント・チャート(Gantt Chart)もイタレーションを表現する 機能を持ち合わせていない。

この様に、既存の管理手法やツールは根本的にイタレーションを潜在的に想定していな かった。しかし近年の経営科学やOR (Operating Research)の領域では、この本質的課題に取 り組む姿勢が散見される(Ahmadi & Wang, 1994; AitSahlia et al., 1995; Belhe & Kusiak, 1996;

Carrascosa et al., 1998; Denker & Steward, 1996a; Eppinger et al., 1994; Eppinger et al., 1997; Ford, 1995; Grose, 1994; Koushik & Mookerjee, 1995; Krishnan et al., 1997; Loch & Terwiesch, 1998;

Singh et al., 1992; Smith & Eppinger, 1997a; Smith & Eppinger, 1997b; Smith & Eppinger, 1998;

Steward, 1981a; Steward, 1981b; Taylor & Moore, 1980, Yassin & Braha, 2003; Yu et al., 2003）。そ れらの論文は米国の宇宙航空産業、自動車、機械、精密機器といった工業製品を対象とし たものである。しかしながら、それらの研究では設計プロセスのタスクが大きくなく、最 大40程度である。また半導体設計という工業製品を取り上げてはいない。そして、その半 導体設計で持つイタレーションの特徴を解釈した解決策を提供しているわけではない。

その半導体設計におけるイタレーションの特徴とは、50 以上の設計タスクで構成されて いること、偶発的な要因によりプロジェクトのリスクが大きいこと、イタレーションに従 属してタスク内容が変更されること等である。こういった特徴を持った設計プロセスは、

既存の設計管理手法や上記の先行研究の枠組みで適用することは困難である。従って、実 践で対処することができない状況にある。

そこで本研究ではその特徴と現象を把握し、モデルとして定式化させることが重要な一 項目と言える。

2.3.2 イタレーションの発生と含意 

設計のイタレーションの含意はタスク間の手戻り作業や改善という修正工程である。こ の修正工程は設計に関する情報によって生み出される。例えば設計上の目標値を達成でき ない場合に、その達成できないと言う情報に基づき以前のタスクに戻って修正を重ねる。

それ以外にも数多く存在する。その一つは、新しい情報取得によるものである。例えば、

設計途中で改善に向けた情報が新しく得られた場合に、その情報を設計に反映させるため の修正行為が行われることがある。

他に設計と設計検証の反復である。設計はその作業が終了してから、その設計の検証作 業が行われる。この時には検証結果次第によっては設計の修正作業が求められることがあ る。設計から検証という工程の流れを順方向と呼ぶなら、検証作業を終了してから再設計 するという逆方向が発生する場合もある。

イタレーションは自動車産業でも見られる。Clark&Fujimoto (1991)は、自動車産業におけ

る技術者の設計工程を詳細に研究している。そこでは技術者間で設計に関する情報がやり とりされ、修正作業が双方で繰り返されているのを発見している。つまり上流から下流に 向けた修正作業と、下流から上流に向けた修正作業が各タスクを起点として生じているの である。各タスクを起点として生じる新しい情報がイタレーションの勢いを強めていると 指摘している。

イタレーションは、設計目標を満足させようとする行為からも生じる。Eppinger et al.

(1997)は、そのイタレーションを“the repetition of activities to improve an evolving design”と定 義している。つまり、進展過程にある設計を更に改善させようとする繰り返し活動である。

設計仕様通りに収束させることが困難な状況は実際、存在する。それは、例えば予め最初 に設定しておいた性能目標が不適切な場合である。その様な状況下ではその目標値に足り ないと想定される因子を抽出する。続いて設計プロセスの上流に戻ってその因子が発生し ない様に仕様の再検討を行う。これも手戻り修正である。

他に設計上の必要条件や目標値が明確に決定されていない場合にも、イタレーションが 生じる。これは十分な設計情報を入手しようとする行為の繰り返しである。この行為は不 安定な状況をつくり出す可能性が高い。この様な不安定な状況を引き起こす行為は、設計 プロセス上の真の目標を見失いやすい。ここでその真の目標とは、設計プロセスの所要コ スト、スケジュール、そして製品性能である。

先行研究の中では、設計プロセスの所要時間を決定付ける因子としてイタレーションを 取り上げている論文もある（Cesiel, 1993; Clark & Fujimoto, 1993; Eisenhardt et al., 1995;

Eppinger et al., 1994; Gebala & Eppinger, 1991; Singh, 1992; Wheelwright, 1992; Whitney, 1990）。

しかしイタレーションは、所要時間やスケジュールだけに影響を及ぼしているのではない。

所要コストや製品性能にも影響を及ぼしうる。むしろ設計プロセスを一つのプロジェクト と考えて、イタレーションを反映させた方が全体を見渡すことができる。つまり、スケジ ュールだけでなく、設計プロセス上の所要コスト、製品性能も検討に含み入れる方が、経 営の視点では有益である。

2.3.3 イタレーションの分類と効率化 

設計プロセス内の各タスクが複雑な依存関係にある場合には、イタレーションが発生す る。このイタレーションが大きくなれば、スケジュールとコストを目標値以内に着地、す なわち設計を収束させることは困難になる。従って設計プロセスを成功に導くには、設計 のイタレーションを戦略的に計画策定することである。この計画策定を勧めるには、設計 プロセスで生じるイタレーションをまず二つの領域に分けると判りやすい。それは想定内 のイタレーションと想定外のイタレーションである。

想定内のイタレーションとは想定範囲にあるイタレーションである。このイタレーショ ンには設計目標を達成させるために有効な設計情報の交換が含まれる。その他にイタレー ションの効果は学習効果である。学習効果は習熟曲線理論によって裏付けされている。習