トピックス
2004/05/27 01:03 更新

製品開発のプロジェクトマネジメント
第7回　DSMの作り方

今回は、製品開発プロセスをDSM形式に記述していく方法を説明する。

DSM作成の流れ

　これまでの連載で、DSMによる分析から製品開発プロセスに潜む問題点やその改善策に対する洞察が得られることを述べた。しかしそれが可能となるには、DSMが現状の開発プロセスを適切に表現していることが前提となる。それでは、現状の開発プロセスを適切に表現するDSMは、どのように作成すればよいのだろうか？

　DSMを作成するステップは、次のようになる。

Step1：目的と範囲の設定

Step2：メンバーの選定

Step3：タスクのリストアップ

Step4：依存関係の記入

Step5：レビュー

　それでは、それぞれのステップについて説明していこう。

Step1：目的と範囲の設定

　これはDSMに限ったことではないが、まず目的を明確にすることが重要だ。「製品開発のプロセス全体を概観し問題点を明確にするため」「設計パラメータを決定する順序の最適化を図るため」などのように、目的が違えば調査の深さや分析の方法が変わってくるからだ。

　目的が決まったら、調査対象の範囲とタスクの詳細度も決めておく。目的の達成にはどの範囲のプロセスを対象とし、どの程度の詳細度でタスクを拾い上げていけばよいのか検討するのだ。この時に、目的達成可能な最小のDSMを作るよう心がけると良い。範囲を広げることと詳細度を上げることは、どちらもタスク数を増やすことになる。しかし、広範にわたる業務を詳細なレベルで分析することが、必ずしも意味のある結果を導くとは限らない。むしろ詳細なレベルでプロセス分析を行う場合は、「詳細設計フェーズに絞る」「エンジンユニットだけを対象とする」などのように範囲を限定した方が有効な場合もある。

Step2：メンバーの選定

　調査の目的と範囲が決まったら、メンバーを選定する。まず必要なのが、ファシリテータだ。ファシリテータは各部署の協力を得ながらDSMに必要な情報を集めていく。より正確なDSMを作るには、調査対象とする業務の流れに対して一定の理解があり、関係部署に対して協力を呼びかけることのできる人物が望ましい。もちろん協力してもらうメンバーに対しても、調査の目的などを事前に説明し合意を得ておくことが重要である。

Step3：タスクのリストアップ

　ここから、実際の作成作業に入る。最初はタスクをリストアップことから始める。もしも開発標準日程表や過去プロジェクトの実績スケジュールなどが存在するなら、そこに書かれたタスクを抜き出し、たたき台として用意しておくと効率的に進められる。

　タスクをリストアップするときには、そのタスクの詳細度を揃えることに注意する。詳細度がマチマチでは、適切な分析ができないからだ。詳細度を揃えるための着目点としては、タスクの期間、依存関係（Step4で記入）の数、などが挙げられる。

Step4：依存関係の記入

　タスクをリストアップしたら、依存関係を記入するための表を作成する（図1）。一般的な表計算ソフト（マイクロソフトのExcelなど）で作成すると簡単だ。

図1：依存関係の記入用紙

　表を作成したら、タスク間の依存関係を記入していく。この時、各タスクが必要としているインプットは何か、という観点で調査していくとよい。なぜならば、多くの場合自分のアウトプットがどこで使われているかよりも、自分が何を必要としているか、の方がよく分かっているからだ。

　また、この調査はできれば関係者が一堂に集まって行うのがよい。集まらないで調査する方法、例えばこの表を配布し記入結果を回収するという方法は効率的に見えるかもしれないが、それだと依存関係の有無の判断にばらつきが出てしまうことが多い。全員が集まって進める場合でも、あらかじめ依存関係の判断基準を明確に定義しておくことは重要である。

　また依存関係は単に「ある」「ない」だけでなく、その強弱を考慮してもよい。強弱を考慮することで、手戻りの発生頻度や繰り返しの重要性を判断できる。図2は、依存度の大きさを数字で表した例である。

図2：依存関係の記入用紙図2・依存関係の有無のみの記入（上）と強度の記入（下）

Step5：レビュー

　依存関係を記入できたら、関係者でレビューを行う。レビューでは、調査時に情報提供したメンバー以外のレビュアーが参加することも有効である。しかし、あまり人数は増やしすぎない方がよいだろう。レビュー結果に応じて、タスクや依存関係を見直す。こうしてStep3からStep5を全員が納得するまで繰り返し、DSMを完成させる。

　こうして作成されたDSMをさらに分析していくことで、現状のプロセスに潜んでいる問題点や改善するための方策などについて洞察が得られる。しかし、このDSMを作成する過程そのものが、自分たちの業務を見直す良い機会となる。DSMの作成過程で挙げられた疑問点や指摘事項についてもDSMの作成終了後に課題としてまとめておき、その対策を図ることが重要である。

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

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

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

Copyright © ITmedia, Inc. All Rights Reserved.