「なんとなく大丈夫」が結論にならない「見える化」のすすめ
上司:「生産技術部門との詳細検討を実施する件はどうなった？」
部下:「その件は2週間前に打ち合わせを実施しました。その結果、設計側は具体的に検討する項目はなさそうです。」
上司:「生産技術の意見を反映した図面の出図納期は来週だよな。間に合うのか？」
部下:「少し遅れるかもしれません。」
上司:「出図が遅れて、製品出荷までの全体計画に影響はないのか？」
部下:「生産準備の状況によると思いますが、多分、大丈夫だと思います。」
上司:「そうか・・・・（まあ、いいか）。」
上司と部下が製品開発の進捗状況を打ち合わせしている一場面です。
これでは自分の部下がミスをした場合にいったいどれだけまわりに迷惑をかけるのか、上司が正確に把握できているとは言えません。また、部下も自分の持っている断片的な情報をもとに業務を進めてしまい、自分の進め方がそもそも正しいのか不安になることが多いはずです。上司と部下はお互いにそんな不安を抱えながら結局、「なんとなく大丈夫」、「まあ、いいか」が結論になってしまっていることはありませんか。
このような結論に陥らないためには、日ごろから業務プロセスを自分の記憶だけにとどめず記録に残しておくこと、つまり自分の業務プロセスを「見える化」しておくことが必要です。その際、業務タスクをフローチャート式にただ書き並べるのではなく、業務タスクの処理に必要な情報の関係性に着目し、業務プロセス全体を俯瞰できる形にしておくことがポイントです。
ここでは、DSMを用いた見える化のやり方をご紹介します。まず、業務タスクの処理に必要な入力情報と業務タスクを処理した結果である出力情報をもとに、業務タスク間の関係性を明らかにします。図表１のＤＳＭを見てください。例えば、「生産技術の検討をする」には、「形状を決める」の出力結果である製品形状をはじめとして「デザインレビューを実施する」、「ＣＡＥを実施する」、「発注先を決める」の検討結果が必要です。その場合、それらに該当する部分には「×」を記録しておきます。
図１.製品開発をDSMで表現した事例
さらにもう少し現実に即した例を考えてみます。図表２のＤＳＭを見てください。
図２.DSM手法で情報の関係度合いを数値化した事例
例えば、必ずしも発注先が決まっていないと生産技術の検討に着手できないかというとそうとも限りません。一方、形状も決まっていないのに生産技術の検討を開始することは一般的な例では考えにくいことです。
このような場合には、「×」の関係性にさらに重み付けを与えて整理することをお勧めします。
この例では（「９」絶対に必要⇔「３」あれば助かる）で重み付けをしています。もう皆さんお解りのように、「生産技術の検討をする」ためになくてはならない情報は、図表中「９」の「形状を決める」だけであり、図表中「３」の「デザインレビューを実施する」、「ＣＡＥを実施する」、「発注先を決める」は結果があればより良いことを意味することになります。このように関係性を数値化しておけば、時間がない場合に最優先で取り組むべきタスクや自分のタスクが失敗した際にどこにどれだけ大きな迷惑をかけるかが一目瞭然になります。
自分の考えや知見を記憶にとどめておくのではなく、ＤＳＭを使って見える形で記録し、コミュニケーションツールとして活用することで、上司は部下がどういった手順や根拠をもとに業務を進めようとしているのかが把握しやすくなり、部下は困っている箇所を具体的に上司に指し示すことで事前にアドバイスをもらいやすくなるはずです。
こうしておけば、あなたの会社でも「なんとなく大丈夫」、「まあ、いいか」が結論にならなくなてすみます。
執筆：村山 誠哉
※コラムは執筆者の個人的見解であり、ITIDの公式見解を示すものではありません。
