賀門 宏一 
製品開発において、開発中に如何に品質問題を発生させないか、また発生させてしまった場合、如何に早く問題解決するかということが大きな経営課題になっています。
出来るだけ開発プロセスの上流で問題の発生を防ぐために、開発手法、プロセスに様々な工夫をしているかと思いますが、本記事では、問題が発生した場合の問題解決速度を上げ、組織としての問題解決力を高める方法について解説していきます。
問題を発生させないことと瞬時に問題解決することは表裏一体
製品開発において、品質問題を発生させない、つまり設計段階の品質を高め、問題が発生しない製品開発を行うことが非常に重要なのですが、そうは言っても完ぺき、100%問題を発生させないということはなかなか難しいことかもしれません。
顧客価値を高めるために、チャレンジ度の高い開発を行うことが、企業として使命でもあり、チャレンジ度が高いということはそれだけリスクもあるということです。
リスクのない安全な開発では、競合他社に負けてしまうということもあります。
では、どうやってリスクのある開発で、品質問題の発生を防ぐかということですが、リスクをしっかりと認識して、その上でリスクをコントロールすることだが必要なのだと思います。
リスクを知り、リスクと向き合い、問題を発生させないように最善の開発を行う。
どんなに最善を尽くしても、それでも問題が発生してしまったのなら、とにかくすぐに問題の根本原因を追究して問題解決することで、後工程、ひいては顧客への損害を最低限に留めるということが必要です。
予期しなかった問題を解決することで、新しい知識を得て、次の開発へのリスクを低減させることが、開発における学習ということになります。
過去に経験してきた問題解決に関する知識は、新たなチャレンジの際の知恵となり、リスクを緩和してくれます。
つまり、問題を解決することによって生まれた知識と、問題を発生させない開発というのは表裏一体であると言えます。
問題解決力を組織的に高める３つのステップ
製品開発のリスクと向き合い、組織的に問題解決力を向上させるために、以下のような3ステップの組織改革が効果的です。
- 製品全体の原理を理解する必要性を組織が理解する
- 仮説検証型の思考法（リーン思考）を身に付ける
- 失敗を活かすためのナレッジ共有の仕組みを作る
では、一つずつ細かく説明していきます。
製品全体の原理を理解する必要性を組織が理解する
問題解決力を高める、さらに製品開発の質を高めるために最も重要なことは、製品の原理をしっかりと把握することです。
当たりまえのことなのですが、このことを組織としてきちんと理解しているでしょうか？
優秀なお医者さんが、患者の病気の真の原因をどうやって見つかるかを考えてみましょう。
優秀とは言い難いお医者さんは、患者の症状に対して、たくさんの仮説を持っていないことが多く、例えば咳が出て喉が痛いと言われれば、それは風邪だろうと、簡単に答えを出します。
それに対して優秀なお医者さんは、問診で患者さんから出来るだけ多くの情報を聞き出そうとします。
患者さんから聞き出した情報から、人間の体の仕組みと、その仕組みによって起こり得る多くの仮説を持っています。
過去の経験や、学会等で報告された事例なども頭に入れて、患者さんの症状と、起こりうる様々な真の原因とを結びつけながら、患者さんの病気の原因を深掘りしていきます。
つまり、優秀なお医者さんほど、人間の体の仕組みを深く理解し、起こりうる原因と症状との因果関係を知識として備えているということです。
さらに、自分以外の医師からの情報については、成功事例、失敗事例ともに理解されていて、自分自身の経験・知識と、外から入って来た情報を組合わせて、患者さんの診察・治療をしていくわけです。
製品と人間を同じレベルで考えるわけではありませんが、仕組みやプロセスとしては、製品開発における問題解決と病気治療は共通することが多いと思います。
製品開発において問題を早期に正しく解決するためには、
-
製品の動作原理（人間の体の仕組み）
-
起こりうる症状と真の原因の因果関係
-
過去の成功事例・失敗事例
をしっかりと把握した上で、起きている症状を正しく認識して、真の原因を突き止め（いくらかの仮説検証は必要ですが）、正しく対処していくことが重要なのです。
すべての開発者が、製品の原理を把握すれば良いのですが、時代とともに製品システムはどんどん複雑になっており、全開発者が完璧に製品原理を理解するのは難しいことになっているかもしれません。
なので、弊社が推奨するのは、組織全体で製品原理を大まかに理解しておく、ということなのです。
そして、組織として（特にマネージメントが）、製品原理を理解する重要性を理解して、手を打つということが大切です。
弊社が推奨しているのは、リーン製品開発のツールの一つである因果関係マップの活用です。
因果関係マップとは
製品全体、あるいは特定のユニット、技術要素などの原理を図として見える化するためのツールです。
まず、対象とする製品やユニットにおける、顧客価値変数と設計変数（技術変数）を求めます。
次に、顧客価値変数と設計変数の間に因果関係があるものを線で結びます。
そして、その因果関係において、片方が増加すればもう片方も増加する正の因果関係か、あるいは片方が増加したときにもう片方が減少する負の因果関係かによって、<+>か<->の符号を線上に書き入れていきます。
製品の価値を高めるためには、まず顧客価値を高めなければなりません。
そして、顧客価値を高めるためには、どの設計変数、つまり技術要素に手を入れなければならないかが一目でわかるようになっています。
さらに、一つの顧客価値を上げようとすると、別の顧客価値が下がってしまう、つまりトレードオフを把握することで、現状の技術の限界を理解することが出来ます。
また、原理の理解という意味では、顧客価値はある意味製品の表に出てくるものなので、これを症状と捉えることで、起きている症状と技術要素の関係を理解することに繋がります。
図を見ると、一見簡単そうに見えるのですが、製品の中身を良く理解していないと正確に書くことが出来ません。
ぜひ、試してみてください。
因果関係マップについては、「因果関係マップを活用して製品開発革新を加速させる」を参照ください。
仮説検証型の思考法（リーン思考）を身に付ける
製品の原理を理解出来たら、その知識を使って起きている現象と原理を結びつけます。
ただし、現象と原理は必ずしも1対1で繋がっているとは限りません。
現象を説明できる複数の原理、つまり原因があるかもしれません。
あるいは、もしかすると自分がまだ知らない原因が他にもあるかもしれません。
優秀なお医者さんの問題解決アプローチと同じように、製品開発の中で問題解決スピードを上げて、組織としての品質レベルを高めるためには、仮説検証サイクルを高速に回すことが大事なのです。
トヨタが実践するリーン製品開発には、セットベース開発手法という考え方があります。
これは、まさに小さな試行錯誤を繰り返しながら、小さな知識を積み上げて高い品質の製品を開発していく考え方で、このような小さな試行錯誤、つまり仮説検証を高速に継続的に行っていく考え方を弊社ではリーン思考、つまりリーンシンキングと呼んでいます。
組織として、リーン思考を取り入れていくことで、問題解決力を高めるだけでなく、納期遅れの常態化を修復することが出来ます。
参考記事：製品開発の組織力を強化する～リーンシンキングとトップダウンで文化を変える
失敗を活かすためのナレッジ共有の仕組みを作る
組織としての問題解決力を高めるためには、組織内の知識・知恵を結集することが求められます。
いわゆるナレッジ共有、ナレッジマネージメントをきちんと整備するということですが、ナレッジマネージメントは、知識を一か所に集め（データベース化）、それを引き出せる（検索）仕組みを作るだけでは求める成果を得られないということを理解いただきたいと思います。
多くの企業が取り組んでいるナレッジ共有、ナレッジマネージメントは、文書管理システムの構築と検索性の向上で終わってしまっているように感じることがあります。
たしかにデータ管理と引き出すための検索の仕組みも大事な要素ではありますが、大事なことは、
- 活用できる情報、使える情報を蓄えること
- 活用して成果を挙げるまでがナレッジマネージメント
という2点を忘れてはならないと考えています。
使えない情報、活用できない情報をいくら集めても役に立たないということと、いくら情報が集まっても、実際に活用されて成果を出さなければ意味がないということです。
トヨタが実践するリーン製品開発の一つの要素が「A3報告書によるナレッジ共有」です。
トヨタは、組織内でA3報告書を使った知識伝達を見事に定着させ、それによって大きな成果を継続的に生み出しています。
参考記事：
ナレッジ共有の中でも特に重要なことは「失敗」を活かすということです。
「失敗学」という言葉があります。
一つの例として、航空機業界では失敗を繰り返さないために、業界を挙げて失敗を活かす仕組みが出来ていると言えます。
それが現在では飛行機が世の中で最も安全な乗り物だと言われる所以なのかもしれません。
過去トラブル（通称過去トラ）を活かそうという取り組みは様々な企業で行われいます。
形だけでなく、失敗を隠さず、組織として失敗を守り、むしろ失敗を許す文化を作ることで成長を促すシステムが求められているのかもしれません。
組織として問題解決力を高めるための最後の仕上げステップとして、強固で意味のあるナレッジマネージメントを実現させてください。
futureship.jp