多事想論articles

製品開発における地図

 見知らぬ土地へ旅行に行くとき、多くの人は地図を持って行くと思います。地図がないと遠回りしてしまったり、道を間違えたり、行き当たりばったりの旅行になってしまいます。 地図があれば、今の自分の位置や行きたい所までの最短の行き方を把握できるので、より多くの名所をまわることができます。 また、もし仮に道に迷ったとしても、その土地の人々にその地図を見せて訊ねれば、今の位置と目的地までの行き方を教えてもらえるでしょう。もしかしたら自分の地図には載っていない近道を教えてもらえるかもしれません。

 製品開発においても、行き当たりばったりの開発にならないためには「地図」を活用しながら進めることが有効です。 製品開発における「地図」とは、FMEA(※1)、FTA(※2)、QFD(※3)、チェックシート、設計手順書など技術的なノウハウを整理したものや、日程表、課題リスト、WBS(※4)などスケジュールやタスクを整理したものを指しています。 製造業の企業であれば、何かしらの形でこのような「地図」は既に活用されていると思います。

 しかしそれでも、想定外の不具合や手戻り作業がなかなか減らないというケースも多いのではないでしょうか。そのようなケースにおける「地図」には次のような問題を含んでいることが多いと感じています。

  (1)局所的である
  (2)縮尺(粒度)が粗い
  (3)最新になっていない

 (1)の「局所的である」というのは、各人の担当領域のみに着目し、周辺部品や前後工程との関係が考慮されていないパターンです。例えば、エンジンのエキゾーストマニホールドの設計において、排気効率や搭載性は考慮していても、触媒の浄化能力への影響を考慮できていない、などです。 そのような場合、単体試験ではOKでも統合試験でNGが発覚し、設計のやり直しが発生してしまいます。

 (2)の「縮尺(粒度)が粗い」というのは、深堀が足りないパターンです。例えば、検証すべき項目として「疲労強度」は盛り込まれていても、繰り返し圧力による疲労なのか、熱による疲労なのか、振動による疲労なのか、腐食による疲労なのかまでは深堀されていない、などです。 そのような場合、十分な試験がされないまま量産され市場で不具合が発生してしまいます。

 (3)の「最新になっていない」というのは、状況に変化があってもそれが反映されていないパターンです。例えば、設計変更に伴うある部品の出図日程の変更が、製品全体の日程表には反映されていない、などです。 そのような場合、関係者間でスケジュールの認識に違いが生じて無駄な待ちが発生し、それが積み重なると全体の遅れに繋がったりします。

 (1)~(3)のような問題を解決した「地図」を作成し運用するのはハードルが高いように感じるかもしれませんが、実際に開発業務のコンサルティングを行う中で有効だと感じている具体策があるのでご紹介します。 それは『完璧ではなくとも、とにかく「地図」を作っておき、打合せ時には毎回必ず机の上に広げでおく』ことです。なんだそんなことか、と言われそうですが、この効果は大きいと感じています。

 まず、打合せ時に毎回机の上に広げておくことで、その「地図」をベースに話がされるようになります。ただし最初は、司会進行者やファシリテーターがその「地図」をベースに話がされるよう意図的に進める必要はあります。
 そしてもしその「地図」が局所的であった場合、関係者がその足りない部分を指摘するでしょう。例えば、エキマニ担当者が作成した局所的な「地図」を触媒の担当者が見たら、浄化能力への影響が盛り込まれていないことに気付くはずです。
 また、縮尺(粒度)が粗い場合、関係者は深堀できていないことを指摘するでしょう。例えば、試験担当者が評価項目として「疲労強度」としか書かれていないのを見たら、試験条件を検討する為に、何による疲労なのか、詳細を確認するはずです。
 最新になっていない場合も同様に、関係者がそのことを指摘するでしょう。例えば、ある部品の出図日程の変更が日程表に反映されていないことをその担当者が見たら当然指摘するはずです。

 このように「地図」を囲みながら開発を進めることで、地に足のついた議論が抜け漏れなくできるようになります。 このようなことを開発の早い段階から関係者を巻き込んで実施できれば、想定外の不具合や手戻り作業を減らすことができるはずです。またこうして作り込んだ「地図」は資産となり次モデルの開発にも活かせるでしょう。
 この「地図」を作る上で特にポイントとなるのは、全体を見渡せるようにしておくことです。どのような内容をどのように表現するかは、製品の特徴やその企業の開発スタイルとも関わってくるため一概に決めつけることはできませんが、各企業に合った「地図」があるはずです。 自社に合った「製品開発の地図」を見出し、それを囲みながら開発を進めることに一度トライしてみてはいかがでしょうか。

  ※1 FMEA・・・Failure Mode and Effect Analysis(故障モード影響解析)

  ※2 FTA・・・Fault Tree Analysis(故障の木解析)

  ※3 QFD・・・Quality Function Deployment(品質機能展開)

  ※4 WBS・・・Work Breakdown Structure(作業分解図)

執筆:寺村 良寛
※コラムは執筆者の個人的見解であり、iTiDコンサルティングの公式見解を示すものではありません。

資料ダウンロードはこちら