サーベイ
Home News Enterprise +D Mobile PCUPdate LifeStyle Games Shopping Jobs
OPINION | TOPICS | マーケットニュース | Security | IT Premium | 用語辞典 | ケータイ・サービス
ブログ | Site Map | Ranking Top30
記事検索 ?
最新記事

トピックス
2004/04/19 13:30 更新

製品開発のプロジェクトマネジメント
第5回:相互依存的なタスクはどこから着手すればよいか

前回に引き続き今回もDSMを使ったプロセスの分析方法を説明する。今回説明する方法は「テアリング」だ。

相互依存的なタスク

 これまでDSMの特徴として、タスク間の相互依存関係を表現できるという点をあげてきた。相互依存関係とは、例えばAを決めるにはBの情報が必要であり、同時にBを決めるにはAの情報が必要である、というように、お互いが相手に依存しているような関係である。これを拡張すると、3つ以上のタスク間で形成される相互依存関係も考えられる。すなわち、複数のタスクが「ループを形成している」という状態である。図1は、相互依存的な(すなわちループを形成している)4つのタスクの例である。AはDに、DはCに、CはBに、BはAにそれぞれ依存している。その結果、どのタスクも相互に依存していることになる。言い換えると、どこから手を付けたらよいか分からない状態、になっている。

図1

図1:相互依存的な4つのタスク

 DSMで業務プロセスを表現すると、このような相互依存関係の存在が可視化される。しかし可視化されたからといっても、実はまだ問題が残っているのである。なぜならば、現実にはこれらのタスクを処理しなければならないわけで、どこから手を付けたらよいか分かりません、では済まないからである。では、どのタスクを最初に実行するのが最も効率的だろうか? 今回説明する「テアリング」は、それを導くための分析手法である。

プロセスのループを断ち切る

 図2は、ループを含むプロセスを表したDSMの例である。赤いセルに記入した依存関係は「A→B→C→D→A」というループを表している。このプロセスにはさらに2つの依存関係(D→B、A→C)が存在する。このプロセスを構成する4つのタスクのうち、どのタスクに最初に着手するのが最も効率的だろうか?

図2

図2:ループを含むプロセス

 4つのタスクはどれも他のタスクからの情報を必要としている。しかし実際には、どれかのタスクに最初に着手しなければならない。ということは、最初に着手するタスクは、本来必要としている他のタスクからの情報を得ずに取り掛かることになる。すなわち、本来は必要な情報を「仮定」してタスクを開始する、ということである。

 例えば最初にAに着手する場合、本来必要なDからの情報を「仮定」して開始することになる。これをDSMに反映すると、図3のように「D→A」の依存関係が取り除かれた図になる。

図3

図3:最初にAに着手した場合

 最初にAに着手することで4つのタスクが形成するループを断ち切ることができた。しかし図3には、まだ「B→C→D→B」というループ(赤いセル)が残っていることが分かる。

 今度は、最初に着手するタスクがAではなくDだった場合にどうなるか見てみよう(図4)。DはCからの情報を必要としているので、最初にDに着手する場合は「C→D」の情報を「仮定」することになる。図4は、それを反映して「C→D」の依存関係を取り除いたDSMである(青いセル)。

図4

図4:最初にDに着手した場合

 この図4のDSMに対してさらに「パーティショニング」(前回参照)を実施すると、図5のようになる。その結果、このDSMには対角線の右上にx印が存在せず、もはやこのプロセスにはタスクのループが残っていないことが分かる。

図5

図5:図4に対してパーティショニングを実施した後のDSM

 以上で見てきたように、DSM上のx印を取り除くことで相互依存関係(すなわちループ)を解消することを「テアリング」と呼んでいる。

 どの依存関係を取り除くのがよいのか考える際に考慮すべきこととして、次の2点があげられる。

1. 取り除く印(依存関係)をできるだけ少なくすること。印を取り除くとは、「近似」「推測」「仮定」をすることである。その数は、少ない方が望ましい。

2. 大きなループを断ち切ること。大きなループの中に小さなループが含まれるような場合、大きなループによっても小さなループが何度も繰り返されることになってしまう。大きなループは断ち切り、小さなループだけで繰り返しを行うほうが望ましい。

 前回と今回はタスクの意味を考えずDSMを記号的にだけ見てきたが、次回は実際の製品開発プロセスをDSMで表現した時に考えられる改善策について説明する。

関連リンク
▼米マサチューセッツ工科大学(MIT)
▼Problematics
関連記事
▼第4回:プロセスの改善を行うパーティショニング
▼第3回 DSMの読み取り方
▼第2回:DSMによる業務プロセスの記述
▼第1回:従来の方法による業務プロセスの記述
▼連載開始にあたって

iTiDコンサルティング
2001年、電通国際情報サービスと米ITIの合弁会社として設立。 両社の特長を受け継ぎ、「製品開発の“品質”にフォーカスをあて、その抜本的な改革を支援する」ことを事業コンセプトに、わが国初の開発生産性定量指標『iTiD INDEX』の開発や独自の『ワークストリーム』の導入など、独創的な手法で製品開発プロセスの抜本的な改革を支援している。

著者

水上博之
電通国際情報サービスでCAD/CAM/CAEシステムの導入支援などに従事した後、2001年より現職。主にメカニカルエンジニアリング領域における設計業務改革のコンサルティング活動に携わっている。

[水上博之,iTiDコンサルティング]

Copyright © ITmedia, Inc. All Rights Reserved.

この記事についてのご感想 【必須】
役に立った 一部だが役に立った 役に立たなかった
コメント
お名前
メールアドレス

サーベイチャンネルは、専門スタッフにより、企画・構成されています。入力頂いた内容は、ソフトバンク・アイティメディアの他、サーベイチャンネルコーディネータ、及び本記事執筆会社に提供されます。


記事検索 ?
@IT sbp 会社概要 | 利用規約 | プライバシーポリシー | 採用情報 | サイトマップ | お問い合わせ