連載
» 2011年05月18日 11時52分 公開

TRIZは使えないと思っていますか?災害未然防止のための設計とTRIZ【活用編】(1)(2/2 ページ)

[桑原正浩/アイデア,MONOist]
前のページへ 1|2       

 ではそれぞれを、自動車のブレーキシステムを実例にして説明します。

1.マルチスクリーン(9画面法)

 これは、改善を考えているシステムを、問題が発生している状況だけではなくさまざまな視点から観察してみようというものです。具体的には、時間と空間を2軸とする9つの視点でのシーン観察といえるでしょう。一見すると「マンダラート」に似ていますが、こちらの方は、横軸を3つの時間(問題の発生前、問題の発生時、問題発生後)で、縦軸を3つの視点(スーパーシステム、エンジニアリングシステム、構成要素)で観察するところに特徴があります。とは言っても、実際には分析する構成要素の数が増えたりしますから、必ずしも「9画面」ではないのですが。

 人間の心理として、システムで発生している問題状況だけに視点が固定されて対策を考えてしまう場合はありませんか? どうしても解決しなければいけないという切迫感故か、その部分に思考が集中しすぎて周りのものが見えなくなる。自動車の運転などでも視点は前方3割、後方7割という風に一点集中しないはずです。マルチスクリーンを書くということは、「いま起こっている問題について、時間軸や空間軸という視点で観察することで問題解決につながるリソースを探る」ということになります。その結果、当初の問題が新たな真の問題に再定義されることがあります。

 作り方は至極簡単。まず、A3以上の広さの用紙か、ホワイトボードを用意します。個人で考えるときは机の上で作業できますから紙で良いですが、チームで議論をする場合はホワイトボードぐらいの広さのモノに書きながら作業する方がいいでしょう。

 次に、それらの紙もしくはホワイトボードに、9つの枠を書きます。そして、横軸には左から「問題発生前」「問題発生時」「問題発生後」、縦軸には上から「スーパーシステム」「エンジニアリングシステム」「構成要素」という項目を付けます。図3を参考にしてください。

図3 図3 自動車のブレーキシステムのマルチスクリーン例

 今回は、文章で表現していますが、実際に作成する場合は、「ポンチ絵」や「写真」などを使用して、ビジュアルにした方がより具体的な問題の把握に役立ちます。

2.機能-属性分析

 これは、システムを構成する部品や要素、およびそれらが持っている属性などを連関的に記載することで、システムの全体像を理解するのが目的です。例えば、自動車のブレーキシステムを構成しているブラケットやディスク、パッドなどの役割や存在意義を明確にすることで、問題を起こしている原因部分のそれぞれの関連性をつかむのです。TRIZに「物質-場分析」という手法があります。それはシステムをモデル化して問題点を明確にしようという抽象化の考え方です。これをシステム全体でモデル化してみようというのが「機能-属性分析」なのです。これをやると、システムへの理解が進むだけでなく、チームとしての知識や視点の共有化ができるのが良いという感想をいただきます。今回は、「Goldfire Innovator」(インベンションマシーン社)というソフトウェアの「デバイス分析」モジュールを使って作成してみました。図4を参考にしてください。

図4 図4 自動車のブレーキシステムの機能-属性分析例

 このモデル化によって、発熱という原因とブレーキ油の性能の問題、およびタイヤと路面との接地部分に本質的な原因がありそうだと分かります。

3.原因-結果分析

 これは、問題を起こしている状況を、システム内で起こっている因果関係で展開/分析していくものです。TPSに「なぜを5回繰り返せ」という手法がありますが、それと似ていますし、FTA的な展開でもあるといえます。今回のブレーキシステムの場合、「なぜ、ブレーキが利かなくなるのか?」という問いかけから、その原因をブレーキシステムの内部に切り込んでいくイメージです。そういう意味では、ブレーキシステムで発生している現象(問題)の原因を、ミクロベースに分解していく「要素還元的」な分析とも言えます。この展開も技術者の論理的な思考力を高め、問題とその原因をチームで共有化するために大変有効であるとの評価をいただいています。

 そもそも、技術者の思考は「こういうことが起きた原因はなんだろう?」という問いかけを得意としているはずですが、それを表現しようとするとなかなかうまくいかないのが現実です。コツとしては、システム構成を1つ1つばらばらにして、一段一段丁寧に原因を深堀していくことでしょうか。そのために、一度絞り込んだ原因から、拡散思考へ変換しそうになることに注意してください。例えば、トラッキング火災発生の原因を分析するために、「トラッキング火災が発生する」←「プラグのすき間に埃がたまるから」←「埃がたまるのは、すき間ができるから」とすべきところを、「埃がたまるのは、掃除をしないから」としてしまうことはやめましょう。これも、機能-属性分析と同様、Goldfire Innovatorの「根本原因分析」モジュールを使って作成してみました。図5にブレーキシステムの原因-結果分析の例を示します。

図5 図5 ブレーキシステムの原因-結果分析例

 このようにして、問題の本質をとらえてアイデアを考える部分を明確にすることが、優れた解決策を生み出すポイントなのです。漫然とした問題の解決策を考えるのではなく、問題を起こしている原因をつかんで対策を考えること。これをTRIZでは最小問題と言い、理想的な解決策につながると考えています。この場合、例えば「ブレーキパッドの放熱面積の小ささ」や、「ブレーキ油の熱に対する特性」などが根本原因になりそうだということが理解できます。

 では、このようにして本質的な問題の原因をつかんだ後、どのようにしてTRIZを活用するのか? 次回以降、実際にアイデア発想のプロセスについて説明します。それまでに、皆さん方が抱えている問題を上の3つの方法で分析してみることをお勧めします。いわば、「習うより慣れろ」が、この手の手法の有効性を体感し、習得するカギだからです。

Profile

桑原 正浩(くわはら まさひろ)

熊本県生まれ。1985年鹿児島大学卒業。KYB(カヤバ工業)株式会社、オムロン株式会社で研究開発や商品開発に勤務後、技術問題解決コンサルタントとして独立。現在は、株式会社アイデア、コンサルティングセンター長。実務型TRIZコンサルタントとして、国内外企業の技術開発テーマの創造的問題解決のコンサルティングに携わる一方、大学や産業振興財団の中小企業支援育成事業、日科技連の次世代TQM構築PJなどでも活躍中。「TRIZで日本の製造業を元気にする」が合言葉。

著作物に「効率的に発明する:ロジカルアイデア発想法TRIZ」(SMBC出版)、「使えるTRIZ」(日刊工業新聞社「機械設計」連載)、韓国では「TRIZによる論理的問題解決:アイデアレシピ」(韓国能率協会出版)がある。ブログ「TRIZコンサルの発明的日常閑話」

Twitterアカウント:@kuwahara_triz



前のページへ 1|2       

Copyright © ITmedia, Inc. All Rights Reserved.