想定外を想定する未然防止手法GD3

吉村達彦【著】

• 販売会社／発売会社: 日科技連出版社
• 発売年月日: 2011/09/02
• JAN: 9784817194121

商品レビュー

2016/04/10

この考え方は使えそう。リスクを見える化し、価値に変換する。どこを変えたのか分かりやすく示し、立場の違う人たちと徹底的に議論し、自分では気付かなかった問題に気づき、価値を高める。Good design / Good dissection/ Good discussion

2012/09/02

DRBFMという手法ばかりにとらわれていたが、本書を読む事によって重要なのはGD3という考え方である事が理解出来た。
「Good Designとはリスクそのレベルがが見える設計を行うこと」定義されているが、どの様なリスクを想定するか、タグチメソッドで言えは、どの様な実験空間を定義するか、この点に関しては、技術者に委ねられることになる。
勿論、一人の技術者が行うわけではなく、複眼的な視点を導入するGood Dissection、Good Discussionとのセットが重要になるわけだが、これらを成立させる為には、普段からのチームワークや次工程との溝の無いコミュニケーションを必要条件となる。つまり、手法の問題ではなく、日頃の多方面に渡るきめ細かなマネジメントがベースに無いと問題発見が遅れることを示唆していると受け止めた。
本書の中でもハインリッヒの法則が引用されている様に、どれだけ多くの事に目配りができるか、またそれをファシタティブ・リーダーとしてどれだけ漏れなく顕在化されることが出来るかに掛かっている。しかもそれは、社内に留めては行けなく、サプライチェーンをも対象とする必要がある。
シンプルで読みやすい本であったが、やるべき事の多さを思い出せ背てくれる良書であった。

2012/04/30

その１： GD3の3つについて

本書では、

　　筆者は “Good Design”、“Good Discussion”、“Good Dissection”の3つを合わせてGD3（ジーディーキューブ）とよぶことにした。日本語では「差の見える設計」「ワイガヤ」「現地現物」（サ・ワ・ゲ＝騒げ）ということになる。

いきなり、“Good Design Review”が、“Good Dissection”に変わっています。dissectionとは聞きなれない言葉ですが、
　　【名】切開、解体、解剖（体）、詳細な分析
といった意味だそうです。

現物（主に前回の設計と今回の設計）を持ってきて詳細に比較するということです。

★★★

その２： DRBFMとFMEA

次に、前著ではFMEAの改良版的位置づけでDRBFMが語られていたように思うのですが（誤読かもしれませんが）、本書ではDRBFMとFMEAの使いどころを明確に分けています。

　　もともとFMEAをしっかりデザインレビュー（Design Review）しようというところから始まったのでこの名前をつけたが、後に述べるように、FMEAとは別の道をたどることになった。

　　FMEAはAnalysis であるから、リスクを解析して、評価し、合理的に対策を施すことが目的であり、「問題を発見する」ことが目的ではないのである。これに対してDRBFMはリスクを正しく評価することが目的ではなく、リスク（差の情報）の背後に隠れている問題を発見することが目的なのである。だから、DRBFMでは「リスク（変更）のなかから問題を発見する」ことに徹底的にこだわることが大切である。

　　まったく新規のシステムを開発するときだけはFMEAを用いる。ただし、まったく新規のシステムにだけFMEAを実施するためにFMEAの回数は減るので、確実に問題を発見し、製品の改良に結びつくタイミングで行う。つまり、正しいタイミングでFMEAを実施することで、DRBFMと同様、問題発見を目的にすることができるようにしたのである。一方、DRBFMは、まったく新規以外の設計、および設計変更のケースで確実に行う。特に、開発途中の変更k（これまでこのケースについてはFMEAは行われていなかった）についても確実に行われるように、システムおよび管理規定を変更した。（GMの事例より）

つまり、目的を「問題発見」に絞っています。また、ターゲットもいわゆる派生開発を意識することによってGD3の良さである「差」に着目したレビューが前面に出ています。

★★★

その３： 試験の位置づけ

昨日の日記の話に続くのですが、本書では試験の位置づけについてこう書いています。

　　試験は製品に価値を付けるから必要

つまり、「製品出荷判定」のための検査が目的ではなく、試験は問題発見（＝リスクの未然防止）をすることで製品に価値を付けると位置づけています。

本書では、“Test to Failure”という視点を提案しています。
故障が生じるまでテストする。その意味は是非本書を読んでください。

とても勉強になりますし、ソフトウェアの世界にも応用できる考え方がたくさん入っている本なのでおすすめです。