製品開発の過程で起きる品質問題の解決に時間がかかっている？！
製品システムが複雑になったからか、技術者の実力不足なのか、製品開発で起きた品質問題、トラブルが発生するとその解決に大きな時間がかかり、全体日程に大きな影響が出ていて、開発組織の大きな問題になっている。問題解決能力を上げるにはどうすればいいか？
製品開発で、そもそも品質問題を起こさなうように開発するというのが、弊社が推奨し実践しているリーン製品開発の狙いなのですが、それでも起きてしまった問題をどのように短期間で解決できるようにするか、組織として問題解決能力を高める方法、及び問題解決に強いプロフェッショナルを育てる方法について解説します。
本記事の内容
品質問題は製品の動作原理、アーキテクチャーの理解不足で起きている
品質問題が起きてしまう原因は、大きく言うと人的ミスと技術者の理解不足の２つだと考えています。
どちらの問題も、設計レビューやユニットテストなどで早く問題を発見する仕組みを開発プロセスに入れ込むことで対応していると思います。
問題を出来るだけ上流で発見する、あるいは問題を作りこまないような開発プロセスにすることが、ある意味、企業間の競争でもあり、結果的に企業間で差が出来るところでもあると思います。
多くの企業での取り組みで共通することは、「問題を作らない」ための開発プロセスに変えようということではないでしょうか？
弊社が進めるリーン製品開発手法の重要要素であるセットベース開発は、学習しながら開発をしていく方法であって、学習サイクルを進める過程で開発技術者の製品動作原理に関する理解が深まることによって、開発の中で問題を作りこまなくなると考えられています。
つまり、問題を発生させる要因のうち、理解不足による問題発生を防いでくれるわけです。
では、どんな理解が足りないのか、ということです。
多くの製造業の開発部門に共通しているのは、製品全体の原理、つまりアーキテクチャーを完全に理解している人が激減しているということです。
製品開発の分業化が進んで、一人一人の技術者は、全体システムの中でほんの小さな部分を担当することが多く、担当ユニットや部品に関しては、それなりの知識と経験を持っているものの（これすら危うい状況もあるのですが）、ユニット間のつながりや、全体の構成、全体での機能配分などをきちんと説明できる人が少なくなっているのです。
同じような機種開発を繰り返していると、部分ごとの小改善を繰り返しているので、全体がわからなくても開発そのものは出来てしまうのです。
開発する間に、ユニット間の連携、つまりアーキテクチャー（全体構成）によって成り立っている機能や性能などに疑問を持つことなく、数年を過ごしてしまった技術者、あるいは技術組織から知識が失われていきます。
製品全体の動作原理を深く理解していたベテランも、後進の技術者から求められない知識を会社に残す必要を感じないまま、定年退職してしまうのです。
品質問題の約70%はユニット間の連携やアーキテクチャー上の問題
経験上、開発中に起きる品質問題の7割以上は、ユニット間の連携、つまりユニットとユニット、あるいは部品同士の間のインターフェイスの問題であると言えます。
ユニットや部品の中の設計上の問題であったとしても、アーキテクチャ設計で決めた役割を果たしていないことでの問題がほとんどです。
設計の再利用、過去のユニット設計を再活用するというときに、過去の機種で正常に動作していたユニットや部品が新しい機種で動かなくなるのは、ほぼ間違いなくインターフェイス、あるいはユニット間の機能配分、性能配分が変化していることに気づかないことが原因であると考えています。
モジュール化設計という考え方は、設計の再利用を可能にして、開発の大幅な効率化を図れる手法として広く使われていますが、アーキテクチャー設計による機能配分、性能配分を無視して進めると失敗します。
アーキテクチャー、つまり全体構成を設計することは、機能、性能、品質確保の仕組みを配分する、非常に重要な任務を持っています。
類似機種を繰り返し開発していくと、このアーキテクチャー設計がなおざりになり、アーキテクチャーの穴がたくさん出来て、問題を拡散します。
問題解決は医師の病気診断のように真の原因を探る
仮説を立てて検証する力
製品開発における品質問題を解決することは、お医者さんが患者さんを問診しながら、真の病気の原因を見つけていくのと同じだと思っています。
患者さんの症状、どこどこが痛いとか、どんな時に痛むとか、どんな種類の痛みなのか、頻度は？などは最終的に表面に現れる症状に過ぎません。
症状の組み合わせから、いくつかの可能性を思い浮かべて、その可能性を一つずつチェックしていきます。
優秀でない（誰かを非難しているのではありません）お医者さんは、可能性を広げて考えられずに、ある一点の可能性で決め打ちしてしまいます。
「それは風邪だよ。大丈夫。」みたいなこと。
でも実は怖い病気が隠れていたなんてことは、よく聞く話です。
優秀なお医者さんは、この可能性なら「こういうチェックでこういう結果が出る」という検証方法を持っています。
そのチェックが外れたら、次の可能性をチェックする。あるいは、問診で聞き切れていないことはないか、もう一度、患者さんと向き合って症状、つまり起きている現象を確かめます。
お医者さんの知識というのは、人間の体の構造を知り尽くしているということですよね。
正常な状態では、人間の体はたくさんの臓器や血液やその他の体液などが連携することで健康な状態が保たれます。
人間の体の働きについて素人が語れるものではありませんが、お医者さんはその知識をベースに、異常が起きる原因を特定していきます。
製品の品質問題が起きる場合も、何かの異常な症状が現れます。
兆候のようなものであったり、症状がめったに再現しなかったりすることもあります。
製品開発の品質問題を解決するには、製品の原理原則を考えながら、現象を発生させる原因の可能性を思いうかべます。
たくさんの可能性を仮説として挙げて、それらを一つ一つ潰していくことで真の原因にたどり着くというのが、問題解決の最善の方法だと思います。
そのためには、製品全体の原理、構成、機能配分、性能配分などを理解していることが絶対的に必要だということです。
優秀なお医者さんとそうでないお医者さんを区別するということではなく、優秀なお医者さんは、人間の体の仕組みを知っていることに加えて、起きている症状から考えられる可能性、仮説をどれくらい引き出せるかということがあると思いますが、これは知識とは別に経験とか能力（あるいはセンス）という部分になるのだと思います。
製品開発の問題解決も同じですね。
問題解決が出来る優秀な技術者は、製品に対する知識がベースにあって、さらに症状から原因の可能性を引き出せる能力があるのだと思います。
疑問を持ち続ける”なぜなぜ力”
問題の本質に早く到達するためには、知識から仮説を立てる力が重要ですが、さらに言うと、思い込みを排除して正しい仮説を立てるためには、様々なことに疑問を持ち、いつも”なぜなぜ”を頭のなかで繰り返すことも重要なのです。
人間は思い込みの塊のようなものかもしれません。
偏った知識や経験だけに頼って失敗することは誰にも経験があるのではないでしょうか？
問題解決が遅い人は、後でわかることですが、”思い違い”をしていることで思考が止まってしまったことが原因で問題の本質に到達できないことがあります。
自分にも思い込みがあるかもしれない、と疑ってみることが問題解決を早めてくれる場合が意外に多いのです。
そして思い込みを排除するためには、常に”なぜそうなるのか？”という疑問を持ち続けることが大事なのです。
チーム内で、”それはどうしてですか？”という質問をお互いにするようになると、チームの問題解決力は格段に上がります。
特に製品原理について、わかったような気になっていて実は得わかってない人って、組織内に少なからずいるように思います。
専門分野のことはわかるけど、製品全体についてはよくわかってない場合もあります。
わかってないことって、多くの人は勝手に自分の考え（いわゆる思い込み）で、無知の領域を自分勝手に埋めてしまうことがあるということです。
だから、お互いに”なぜ”を繰り返すことで、問題の本質を追及していくのです。
製品のアーキテクチャーを学び、組織的に問題解決能力を上げる
最初にお話ししたように、多くの製造業の製品開発において、製品全体のアーキテクチャーや動作原理をすべて把握している人間が社内からいなくなっており、さらに既存製品の繰り返し開発で、製品の原理に戻る必要もなく部分的な改善設計を行い続けたことで、組織の問題解決能力が低下していると考えられます。
だとしたら、もう一度、製品の原理原則、アーキテクチャー設計に立ち返ることで、製品力を上げ、また問題が起こった時の問題解決能力も高めることが出来ると考えています。
さて、それでは、失ってしまった製品の原理などの知識をどうやって取り戻すかということですが、具体的には組織として愚直に学んでいくしかないと思います。
以下のような方法を考えてみました。
- 残っている全体を理解しているベテランからの伝承を仕組み化する
- 全部を知らないメンバー同士でツールを使って組織的に学習する
それぞれについて説明していきます。
残っている全体を理解しているベテランからの伝承を仕組み化する
もし、まだ製品全体を理解しているベテランが会社に残っているならば、ベテランの知識を会社に残す仕組みを早急に作って実施するべきです。
具体的には、
- 報告書として知識を残す方法
- 講義形式で口頭で伝承する方法
の２つが考えられます。
ベテランが気持ちよく報告書（弊社ではA3報告書をお勧めしてます）を書いてくれれば一番良いのですが、「そんなこともわからないのか？」なんて思っているベテランも多く、ここはベテラン任せにするよりは、伝承を受ける人たちが主体になる方法を取るべきだと思います。
まずは、どんなノウハウが隠れているか、つまりベテランからすると当たり前のように思っている、いわゆる「暗黙知」が何であるかを伝承する側、される側で組織的に議論します。
つまり、何を引き継いでおかなければならないかの定義をします。
いくつかのテーマを決め、伝承する内容を決めたら、伝承を受ける担当を割り振って、割り振られたメンバーが報告書を書く任務を持ちます。
テーマを与えられたメンバーは、ベテランからノウハウを聞き出す形で報告書を作成していきます。
ベテランの協力も当然必要で、ヒアリングに対応するだけでなく、報告書を書いている過程でレビューとアドバイスをします。
さらに、上位マネージャーもできるだけ状況を見て、アドバイスに参加する必要もあります。
組織的に「知識」財産を回復させる重要な仕事になるという認識を持って進めましょう。
報告書を残すよりは、伝承の濃度は下がってしまうかもしれませんが、講義形式で口頭で伝承する方法もあります。
ベテランにお願いする形で、暗黙知を開示するためのテーマを決めて、必要な日数を使って講義形式で複数のメンバーに伝承します。
ある程度、ベテラン自身に問題意識があればうまく行くし、講義の資料が残るので、完全にノウハウが消えてしまうことは避けられると思います。
報告書方式に比べると、伝承を受ける担当に責任とモチベーションを与えられる報告書方式に比べて、伝承を受ける責任が分散されることだけがデメリットかもしれません。
いずれにしても、ベテランと現場任せにせずに、マネージメントがしっかりと介入して、確実な伝承を完成させましょう。
全部を知らないメンバー同士でツールを使って組織的に学習する
製品全体の構成や原理を組織メンバー自身が学習して習得する２つのツールを紹介します。
- 機能構造展開図
- 因果関係マップ
どちらのツールでも構わないので、チームを作って製品全体構成や原理をツールで表現していくというミッションを与えてください。
製品全体を知らない人たちが集まって作業をしても、そうスンナリと完成させることは出来ないはずです。
自分たちが多くのことを知らない、ということに気づくことも大事なことなのです。
そして、メンバーで議論することも非常に意義のあることです。
メンバーでも解決しなければ、メンバー以外に知っている人がいないかを考えて、周囲に聞いて回ることになり、このことも社内の技術コミュニケーションの活性化、あるいは社内の知識の棚卸しをすることに繋がり、開発組織の活性化に非常に大きな効果をもたらします。
２つのツールは、ツールを作ること自体はそんなに難しくありません。アーキテクチャーの内容がわからないから苦労するということです。
マネージメント主導で、組織の重要活動として展開してみてください。
それぞれのツールを簡単に説明しておきます。
機能構造展開図
機能構造展開図は、VA（Value Analysis）などでも使われるツールですが、製品の機能を階層的に分析し、分解された機能とユニット構成や部品構造を結び付けます。
具体的には、左側に機能の階層を書いて、右側にユニット、部品の構造を書いて両者を繋げたものです。
下図は、LED電球を機能構造展開図にしたものです。
機能構造展開図の右側は、いわゆる部品構成図になります。
VAでは、この図を使うことで、部品のコストがわかるので、機能のコストとして読み替えることで、機能に対してどんなコストがかかっているかをチェックして、適正なコスト構造への変革を目指していきます。
この図によって、機能がどんなユニットに分解されて、どんなユニット間の連携があるかを理解することができます。
因果関係マップ
因果関係マップについては、別記事「因果関係マップを活用して製品開発革新を加速させる」でも詳細に説明しています。
因果関係マップは、リーン製品開発手法の中でも非常に重要なツールで、顧客価値変数と設計変数を因果関係で結んだ図になります。
開発の主たる目的は、顧客価値を上げることという大前提で、顧客価値同士が設計変数を介してどんな関係になっているか、新たな顧客価値を求めるために、どんな技術開発をすべきかなどがわかるツールです。
現状の製品を顧客価値と技術の観点で、全体を俯瞰するには非常に都合が良いツールといえます。
下図は、電気掃除機の因果関係マップになります。
因果関係マップは、今回説明しているように、製品全体の構成や原理を組織が理解し、問題解決力を向上させるという目的以外でも多くの活用方法があります。
まずは、因果関係マップを開発プロセスの中で定着させ、組織内で因果関係マップ作成の熟練度を上げることで、開発組織の活性化に役立てて欲しいと思います。
ぜひ、下記の参考記事をご参照ください。
参考記事：
製品開発プロセスで品質問題に対する問題解決力を向上させる方法
まとめ
製品開発組織が目指すべきことは、開発プロセスの中で品質問題を起こさない開発を行うことです。
そのために、リーン製品開発手法を取り入れて、開発組織の改革を進めていただくということが、弊社が目指す方向の一つであります。
しかしながら、そんな中でも製品開発において品質問題の発生をゼロにすることは難しいのだと思います。
そこで、この記事で説明してきたのは、品質問題が起きたときの問題解決能力を組織としてどうやって高めるかということです。
優秀なお医者さんが、患者さんの症状から病気の原因を突き止めるのと、製品開発の問題解決能力とはその解決能力のあり方に共通性が高いというお話をしました。
結論としては、問題解決能力を高めるには、製品全体の構造、構成、原理、つまりアーキテクチャーを深く理解することが最も有効な方法ということです。
組織全体が、製品全体のことを深く理解できるような、普段からの活動の流れ、プロセスをしっかりと仕組み化する必要があります。
マネージメント主体で、組織が学ぶ仕組みを設計し、それを確実に実行していきましょう。
組織を改革するには、今回説明したような方法論をしっかり学ぶことと、それを実現するリーダーシップとがかみ合うことで初めて達成できるものだと思います。
弊社では、製品開発組織の組織力を高めるための様々な方法論と、マネージメント手法の実践を多数経験しております。
開発組織の組織改革についてのご相談をお受けしています。
下記フォームよりご連絡ください。
こちらからコンタクトさせていただきます。
この記事を気に入ってくれたら、下の”いいね”ボタンをお願いします！！
