皆さんの近くに、管理技法から発想技法まで、問題解決に役立ちそうな手法・技法を片っ端からつまみ食いをしている手法・技法マニア（以下、単にマニアといいます。）がいませんか。

マニアがTRIZの社内担当になると、TRIZが社内に普及することはありません。

マニアの特徴は、上に対しては「自分はまだ勉強中なのでアイデアを出すことができません。」といい、下に対してはアイデアを出すための方法といって「自分がよく理解していない書籍やセミナーで得た知識」を押し付けます。

マニアは、自ら実務問題（解決することで顧客から対価をいただく問題）についてTRIZを使ったことがないため、質問されても教科書的な答えしかしません。

わけのわからない手法・技法は誰も使いたくありませんので、マニアから指導を受けた方は、それ以降TRIZを実務に使用することありません。

マニアからアイデア発想の訓練を受ける方は不幸としかいいようがありません。

マニアが上に対して問う質問は、決まって「成功事例を教えてください。」です。なぜなら、自分では成功事例を作れないから。

マニアは他社の成功事例がないと上を説得できないといい、実務問題についてTRIZ専門家のコンサルを受けたり、TRIZのソフトウェアを導入することはありません。

そのため、マニアが指導するTRIZの訓練は「矛盾マトリックスと発明原理」程度のワークシートを使えばできる簡単な手法だけでお茶を濁すことで終わっています。

それでは、従来の○○法と同じレベルの結果しか出ませんので、他の手法・技法と同様にTRIZは使えないという烙印が押されてしまいます（どこかで聞いたことありませんか？）。

これではTRIZが可哀そうです。

TRIZを普及させようとしているTRIZ担当者が、実はTRIZを駄目にするTRIZキラーになっていることがないでしょうか。

TRIZ担当者がTRIZキラーにならないようにするには、手法やツールに振り回されないようにすることです。TRIZの手法やツールを一生懸命勉強するより、TRIZの基本的思想をよく理解することの方が実務問題を解決する早道です。

マニアは上に対して重箱の隅をつつくような質問をします。そして、上からどんな回答をもらっても納得することはありません。その方が、自分を納得させるためにも、下を指導するのに都合がよいからです。

「TRIZは難しいものなので、そう簡単には理解できるものではない」といことにしておけば、下の人を納得させる指導ができないときの責任逃れができるからです。その方が、本人にとっても精神衛生上好ましいからです。

マニアは自分が納得できないものは、下の人もわからないと思い込んでいます。

マニアの典型的な傾向は、人間の心理的惰性を排除することの重要性を謳っているTRIZを使っているにもかかわらず、TRIZの個別の手法やツールの厳密性に拘るあまり、反って思考の幅を狭くしてしまっていることである。

たとえば、「この指針や推奨文に従うと、出せるアイデアが限られてしまう。」という批判をいう人がいますが、本末転倒ではないかと思います。指針や推奨文は、あくまでも問題解決のための一つの手段を提供してくれていると考えれば、それらの意味を厳密に捉えることに固執する理由はないでしょう。

「そういうこともいえるよね。」くらいの柔軟性をもった受け止め方をしないと、出るはずのアイデアも逃げて行ってしまうのではないでしょうか。

より重要なことは、（１）問題解決とは理想性（有益機能の総和／有害機能の総和）を高めることである、（２）問題解決とは資源（問題解決に役立つ要素：物質資源、エネルギー資源、空間資源、時間資源、情報資源、機能資源）に何らかの変更を加えることである、といった点を押さえておくことです。それにより、指針や推奨文をどの資源に適用すればよいかがわかるため、自然にアイデアが出ることになります。

ちなみに、矛盾を解決することがTRIZの基本的な概念であるといわれていますが、実務問題には矛盾を解決しなくとも、有害機能を排除・軽減したり、有益機能を改良することで十分な場合もあります。そのような場合にもTRIZは有効です。

１９５０年代半ば頃アメリカから導入され、日本企業の製造原価低減活動に広く適用され、日本企業の高度成長に大きく貢献したＶＥ（Value Engineering：価値工学）という技法があります。

日本で発行されているＶＥ（Value Engineering：価値工学）に関する書籍のほとんどは、ＶＥで取り扱う価値の概念として「価値＝機能／コスト」という公式が記載されています。

しかしながら、この公式はＶＡ（Value Analysis：価値分析）の創始者のマイルズが提唱したものではなく、アメリカ国防総省によって制定された公式に始まるとされ、その価値公式は「Value Index（価値指数）＝Worth（値打ち）／Cost＝Utility（効用）／Cost」というものを提示しているとのことです（「市場価格対応の品質展開実践手法」、持本志行著、（株）日科技連出版社発行）。

日本の「価値＝機能／コスト」というＶＥの公式は、日本企業への普及に努めた産能短大の当事者がアメリカ国防総省の価値公式の分子を単に「機能」と略称し、アメリカＶＥ協会もこれをまねて、それを再輸入した日本ＶＥ協会がこれを再確認し、ＶＥ公式「価値＝機能／コスト」が同協会のマニュアルなどに定着した（「市場価格対応の品質展開実践手法」、持本志行著、（株）日科技連出版社発行）、とされています。

マーケティングの世界では、「顧客はモノが欲しいのではなく、そのモノが実現する機能が欲しいのである。」といわれます。

アメリカ国防総省が単なるモノの機能ではなく、モノの機能の値打ち（価値評価額）を問題にしていたわけです。

現在のマーケティングでは機能の先にある「顧客価値」を問題にしていますが、アメリカ国防総省はこの概念を先取りしていたわけです。

同じような考え方を取り扱う技法でも、その概念の定義の仕方や捉え方によって、生まれる成果が大きく異なることを教えてくれる案件といえるでしょう。

ＴＲＩＺの基本的な考え（発見）として、「技術システムは理想性が増加する方向に進化する」という概念があります。ここで、理想性については「理想性＝有益機能の総和／有害機能の総和」との公式で表現されます。

そのため、システムの有益機能を改良・増加する一方で、有害機能を排除・軽減するといった「矛盾を解決する」方法がＴＲＩＺの問題解決の方法であるとされています。

Ｉ－ＴＲＩＺでは問題解決という概念をより広く捉えています。

たとえば、分母である有害機能に着目して理想性が増加する方向を考えると、システムはより小さく、コストはより少なく、エネルギー効率はより良く、環境破壊はより少なくなる、などが進化の方向であると考えます。

また、分子である有益機能に着目して理想性が増加する方向を考えると、有益機能を現在より向上させることや従来と違う方法で同じ有益機能を実現することも、進化の方向であると考えます。

実際の現場では、敢えて難しい矛盾を解決することに取り組まなくとも、問題解決できるケースがたくさんあります。

Ｉ－ＴＲＩＺでは、問題解決を（１）有害機能の排除・軽減・防止、（２）有益機能を得る他の手段、改良、（３）矛盾の解決、といった３つの観点で捉えますので、実際の現場の状況に合った効率的な問題解決を実現することができることになります。

アイディエーション・インターナショナル社が開発した不具合予測（FP：Failure Prediction）は、革新的なものづくりプロセスにはなくてはならない手法であると考えます。

I-TRIZでは「結果の評価」という名の下に、当初の問題の解決案に関連して新たに生じる二次的問題を解決する段階が設けられていますが、「不具合の予測と予防」はその二次的問題の一つと考えることができます。

そして、この二次的問題についての解決策を求めることで、当初の解決策の実現性を高めることになります。

ブレーンストーミングのような方法で「気がつかないようなどんな不具合が起こるだろうか」と考える代わりに、次のテンプレートを使って、問題を逆転させて不具合を故意に引き起こす、あるいは、可能な不具合を「発明する」ことを試みます。

以下に、不具合予測（FP）の基本的な手順を示します。

ステップ１．問題を逆転させる

新たな改良（変更）を加えることによって生ずるかもしれない不具合を推測する代わりに、 問題を逆転させ、不具合を能動的に作り出すことを考えます。

具体的には、次のテンプレートを用います。

[対象システム名]および／またはその環境で、考えうるすべての不具合を[新たな改良（変更）] を用いて発生させなさい。

角括弧［　］内の指示に従って、言葉を置き換えます。初めの括弧には対象システム名、次の括弧には、導入しようとしている（した）新たな変更点を記入してテンプレートを完成させます。

ステップ２．システムの因果関係ダイヤグラムの作成

当初の問題の解決案が実現するまでの過程で起こるすべての事象をリストアップします。

具体的には、最初に、システムがどのように機能するかを示す因果関係ダイヤグラム１を作成します。

ステップ３．焦点の特定と不具合仮説の作成

システムの機能の焦点、つまり、システムにおいて要点となる（弱いまたは危険な）機能／作用／状態（通常複数）を選択します。因果関係ダイヤグラム１を眺めながら、焦点の事象に関連して引き起こすことが可能な不具合の仮説を、次の各項目を参照しながら考えます。

（１）専門分野の経験と知識を駆使して、リストの事象の結果として明らかに生じる可能性のある不具合や有害な影響をリストアップしてください。

（２）「弱いゾーン・危険なゾーン」で起こすことができる不具合を考えてください。

（３）「装置や物などに関連して予測される不具合」を考えてください。

（４）「解決策を実現に移すそれぞれの段階で予想される有害な影響／作用」を考えてください。

（５）「潜在的に危険な瞬間／期間」について考えてください。

ステップ４．不具合のシナリオの作成

不具合のシナリオを書くには、不具合の仮説を一つずつ検討します。それぞれについて、

（１）最も危険な不具合を引起す不具合の仮説に基づいて、より複雑な不具合のシナリオを書くために、仮説を更に複雑に、あるいは危険なものとすることが出来ないか考えて下さい。

（２）複数の「不具合の仮説」を結び付け、より複雑な「不具合のシナリオ」へとまとめ、不具合の相互作用により生じ得る結果も記入します。

（３）こうして得た「不具合のシナリオ」をそれぞれ記録します。

この段階では、アイディエーション・インターナショナル社が作成した「不具合を起こすためのオペレータ」（知識ベース）を使って不具合のシナリオを作成します。その結果、複数の不具合のシナリオ（不具合発生メカニズム）が考えられます。

ステップ５．不具合発生の可能性を確認する

次に、複数の不具合シナリオを、非常に危険な不具合と非常に危険ではない不具合に分類し、それぞれについて発生の可能性を確認します。

不具合発生の可能性は、まず、その不具合を発生させるのに必要な要素をすべてリストアップします。次に、その不具合が生じるために不可欠な要素が資源として実際に存在するかを確認します。

ステップ６．発見した不具合を予防する対策の検討

発生の可能性が高いことが確認された不具合シナリオのうち、非常に危険な不具合について不具合の予防策を考えます。以下、不具合発生の可能性と危険度の高いものから順に、その予防策を考えていきます。

不具合を回避する理想的な方法は、その原因を取り除くことです。しかし、さまざまな理由からこれを行うのが不可能な場合があります。

例えば、費用がかかり過ぎる、手遅れ、変更のためには他社などの同意が必要といった具合です。いずれの場合も、不具合の原因を取り除くのと、その結果を是正するのとどちらがより良いか決定しなくてはなりません。

潜在的不具合の予防策は、対策を要する不具合のシナリオのすべてについて、それぞれに対応する不具合の因果関係ダイヤグラムを作って行います。

具体的には、アイディエーション・インターナショナル社が作成した「不具合を是正するオペレータ」と呼ばれるブレークスルーのための知識ベースを使って予防策のアイデアを考えます。

不具合予測（FP）は、いわば設計品質の保証作業を行うことに相当します。つまり、現在時点で製品の未来の品質を管理することです。

なお、この考え方を知的財産の分野に採用すると、発明者から提案された発明を第三者から真似され難い権利に育てることができます（これを知的財産制御（CIP）では発明強化という）。

発明強化では、発明者から提案された発明の潜在的な不具合を予測して、その不具合が発生しないようなアイデアを追加することを考えることになります。

アイディエーション・インターナショナル社が開発した不具合分析（FA：Failure Analysis）は、革新的なものづくりプロセスにはなくてはならない手法であると考えます。

問題解決の最初の段階では、問題を抱えているシステムの現状を詳細に把握することが重要になります。問題状況の把握ができると、取り組むべき課題が明確になり、問題解決までの距離が一気に縮まります。

I-TRIZでは「問題情報の把握」という名の下に、問題を多くの観点で観察するシステムアプローチを行って利用可能な資源を把握し、システムを変化させるうえでの制約と制限を明らかにします。制約と制限は問題解決の良否を判定する際の評価基準になります。

システムアプローチには、（１）システム階層、（２）機能、（３）時間、（４）問題といった４つの観点がありますが、不具合分析（FA）は問題の観点に関係します。

問題の観点では、問題の直接の原因は何か？、解決すべき問題は何か？、問題の状況が改善されないとどのような望ましくない結果が起きるか？、などの内容を確認します。

問題解決案を出すには、問題を抱えているシステムを何らかの方法で変化させて、問題の原因がなくなってしまうか、原因が望ましくない結果を引き起こすことがないようにすることが可能かを考えます。

このときに重要なのが、原因はどのようにして結果に変わるのかという問題発生のメカニズムを知ることと、問題が起こるにどのような条件が必要か？、といことです。

問題発生のメカニズムを明らかにするには、一般に、その問題がなぜ起きたかという原因を順に辿っていく根本原因分析という手法が採用されますが、初めての問題や複雑な問題にあっては簡単には明らかにできません。

初めての問題や複雑な問題の問題発生のメカニズムを見つけるには、以下のような手順による不具合分析（FA）が最適です。

システムにはシステムの目的である基本有益機能とその基本有益機能をもたらすためのシステムの本来のメカニズムがあります。そして、システムの有益機能のそれぞれに伴う、またはそれによって引き起こされる有害機能もあります。

不具合分析（FA）では、不具合が不具合として認識される直前に起こった事象（最終事象）を特定します。どのようなことの直後に、あるいは起こった直接の結果として、不具合が発生したとみなされるか、その機能、作用、あるいは状態が最終事象です。

その不具合に伴って生じる、または、 不具合の際にいつも観察される事象（併発事象) あるいは特徴的な状況（特徴的状況）を確認します。不具合の出現に何らかの相関性を持つ、システム（およびその環境）の特性値やその他の事象をすべて抽出します。

システムの有益機能と有害機能が明らかになったら、システムの有益機能および有害機能それぞれのボックスを作成し、それぞれの間の関係を示すリンクでつないだダイヤグラムを作成します。

ダイヤグラムの中に「最終事象」「併発事象」および「特徴的状況」のボックスを作成し、これらと不具合とを、相互関係を示すリンクによって結びつけます。

出来上がったダイヤグラムを見ながら、すべてのボックス同士の因果関係の整合性を確認することで、どうしたら不具合が起こせるかの仮説を立てます。次に、その仮説を可能にする資源がシステムの中やその環境に存在するか否かを確認します。

複数の仮説が考えられた場合には、作用する力が大きいメカニズム（弱い力しか働かない現象よりも、大きな力の働く現象の方が生じる可能性が高い）や単純なメカニズム（少数の前提条件が同時に成立つ確率は、多くの前提条件が同時に成立する確率より高い）を選びます。

選ばれた仮説に基づく再現試験（因果関係が確認できる程度の工作レベルの簡単な試験）を行い、その有効性を確認します。これによって不具合が発生するなら、その仮説を有効な仮説とみなすことができます。

自社の専門分野の問題であれば、問題発生のメカニズムがわかってしまえば、解決案を出すことはそれほど難しくないはずです。

解決策が出せないのは、問題発生のメカニズムがわからない場合がほとんどでしょうから、問題解決に取り組むうえで不具合分析（FA）で問題発生のメカニズムを明らかにすることが重要なのです。