製品開発のプロジェクトマネジメント

第8回　数値DSMによる定量分析

数値DSM

　これまでの連載では、DSMを使って製品開発プロセスを表現する際に、タスクからタスクへの情報の流れを「X」印で表していた。しかし、DSMの各セルをどのような記号で埋めるかということに決まりがあるわけではない。例えば「X」の代わりに数値を記入してもよい。

　各セルに数値を記入したDSMを、数値DSM（Numerical DSM）と呼んでいる。

何の数値をDSMに記入するか？

「X」を記入するDSMでは、タスクとタスクの間に、情報の流れや依存関係が「ある」または「ない」のどちらかしか表せなかった（そのため、バイナリDSMと呼ばれることもある）。しかし数値を記入することにより、情報量、ばらつき、再作業の発生確率といった様々な観点でタスク間の依存関係を表現できるようになる。

（1）タスク間の依存関係の強さ

　タスクAからタスクBに情報が渡るとする。タスクAの情報を受け取らなければタスクBに着手することができない場合は、タスクBはタスクAに強く依存していると言える。逆に、タスクAの情報が不十分であってもタスクBに着手できる場合、タスクBのAに対する依存度は弱いと言える。このような依存関係の強弱を、数値で記入することが考えられる。

　図1は、依存関係を3段階で表した数値DSMの例である（依存度が強い場合を3としている）。「試作評価」は「試作図面作図」タスクから図面を受け取らなければ着手できないため依存関係は強い。「試作図面作図」は、必ずしも「シミュレーション」によって基本設計案の妥当性が検証されていなくても作図できるため、依存関係が弱い。そのような強弱が、数値で表現されている。図2のバイナリDSMと比較すると、違いが一目瞭然だ。

　このように、ただ依存関係の有無だけでなく強弱も評価することで、何の「仮定」の精度を高めてどこの「手戻り」を優先的に回避すべきなのか、より有効な改善の指針を得ることができるのである。

（2）タスク間を流れる情報の量

　タスク間を流れる情報の量を測り、それを記入する。対角線より右上に記入された情報量の総和は、フィードバックの情報量となる。フィードバック情報量の最小化によるプロセスの最適化が考えられる。

（3）タスク間を流れる情報の変化量（バラツキ）

　過去に行われた複数の製品開発プロジェクトにおいて、タスク間を流れる情報にどれだけのバラツキがあったかを測ることで、やり取りされる情報の不確実性を評価することができる。不確実性の高い情報を扱うタスクは、そうでないタスクよりも重点的に管理されるべきである。

（4）再作業の確率

　図1では、「基本設計」が「シミュレーション」に依存していることが示されている。これは、シミュレーション結果が変わった時、場合によっては基本設計をやり直す可能性がある、ということでもある。

このように、情報を渡す側のタスクのアウトプットに変更があった時、それを受け取る側のタスクをやり直す確率が、「再作業の確率」である。

（5）再作業の量

　実際に再作業が発生した場合、今回は前回同じタスクをやった時の何割程度の作業をしなければならないか、というのが、この「再作業の量」である。再び図1を使って説明してみよう。例えば、最初に「基本設計」を10日で終えたとする。次に、その設計案の妥当性を評価する「シミュレーション」を行った。その結果が思わしくなく、再度「基本設計」を実施することになった。この場合、必ずしもまた10日かける必要はないかも知れない。では、それはどの程度なのか、1日で済むのか、5日かかるのか、というのが、この値である。

期間予測シミュレーション

　いろいろな数値DSMの例を示したが、どれも同じように効果的である、というわけではない。例えば2（情報量）と3（情報の変化量）については、実施するのは困難かも知れない。それでも、あるフェーズやタスクに限定して適用すれば、効果的な結果が得られる可能性もある。

　1（依存関係の強さ）は、比較的オーソドックスと言えるだろう。

　今回特に注目したいのは、4（再作業確率）と5（再作業量）である。これらの数値DSMを活用することで、製品開発に要する期間や工数、また手戻りが全体期間に与える影響度、などを定量的に評価することができるのである（そのためには、他の数値情報も必要となるが）。

　次回は、そのシミュレーション方法について説明する。

この記事の著者