前回は、「ひらめき」は無意識の脳の機能であるため、意識的に得ることはできないといいました。

しかし、「ひらめき」が起きやすい環境を整えることはできるともいいました。

その方法は、対象となる問題について論理思考で徹底的に考えること。つまり、もうこれ以上考えられることはないと思えるまで考えること。ここまでは、意識してできることです。

この段階まで来ると意識側からの手立てがなくなり、意識の脳はその働きを停止しますが、常にその問題が気になる状態が作り出されます。すると、自動的に無意識の脳が過去のイメージ記憶の中を問題解決に役立つヒントを走査し始めます。

そして、あるとき突然その解決のヒントがひらめくことになります。しかし、いつひらめくはわかりません。何等かの外部刺激が影響しているはずですが、今すぐひらめかそうとしてもひらめくわけではありません。

実は、人間には意識的な論理思考と無意識の脳の働きの他に、意識的に行えるイメージ思考という思考方法があります。

私たちは、日常的に外部から新しい情報を取り入れて、「コトバにつながっているいつでも思い出せるイメージ記憶：◎」を増やすことを行っています。

そうすることによって、自分の持っている膨大な量の「思い出そうとしても思い出せずに忘れているイメージ記憶：☆」を、「コトバにつながっているいつでも思い出せるイメージ記憶：◎」に変換するようにしています。

そして、「イメージに直結したコトバ記憶：〇」を使って、これとつながっている「コトバにつながっているいつでも思い出せるイメージ記憶：◎」を介することによって、目的とする「思い出そうとしても思い出せずに忘れているイメージ記憶：☆」を引き出すようにします。

そのための手段としては、考えている問題に一見関係のないことをイメージしてみることが効果的です。

その場合のアナロジー（類比）は、身の回りのものや趣味に関係するものの他、うそのない自然界の生物や現象に求めるのがいいとされています。それは、それらにまつわるイメージが豊富だからです。

問題解決に役立つのは、「思い出そうとしても思い出せずに忘れているイメージ記憶：☆」です。

創造技法とか発想法といわれるものは、すべてこの「思い出そうとしても思い出せずに忘れているイメージ記憶：☆」をどのようにして思い出させるかという手法であるといってもいいでしょう。

ブレーンストーミング、ゴードン法、シネクティクス、等価変換理論、ＮＭ法、ＴＲＩＺなども同じです。

そのため、意識しているか意識していないかは別にして、これらはすべてイメージを操作するためのアナロジー（類比）を使っています。

研究者、技術者であれば、「アイデアがふと思いつく」といった経験をしたことがあると思います。しかし、なぜ思いついたかは本人にもわからないのではないでしょうか。

ということは、そのアイデアにいたるまでの脳機能が無意識のうちに経過したということです。つまり、脳が自動的に働いたことを意味しています。

この新しいことに気がつく無意識の脳の機能を「ひらめき」といいます。

脳科学者の千葉康則氏は、「自分にわからない自分を無意識といい、自分にわかる自分を意識という。」と表現されています。そして、「本当にわかるとは、言葉ではっきりと表現できること」だといっています。

そうすると、「意識の働きを抑えれば、自然に言葉に結びつかない無意識の脳の機能が働きだす」という性質を利用すれば、「ひらめき」を得るための条件を整えることができそうです。

とはいえ、意識を働かせないために何も考えないのであれば、無意識の脳の機能が特定の問題について働き出すことはありません。

実は「ひらめき」を得るには、その問題についてのあらゆる知識を動員して、意識的にあれこれと熟考する（考える種がなくなるまで考える）といった積極的な行動を起こすことが必要です。そによって、「常にその問題が気になる」状態を作り出すことが重要であるという意味です。

考える種がなくなるまで考えると、その問題を考えていない時に、自動的に無意識の脳機能が働き出して、あるとき突然その解決策がひらめくことになります。この熟考の後のひらめくまでの期間を、創造心理学では「あたため」と呼んでいます。

ところで、「ひらめき」には、自分が抱えている問題の解決に役立つものと、そうでないものとがあります。

「ひらめき」が役立つかどうかを評価するために、また「ひらめき」を問題解決に役立てるためには、そもそもその問題についての深い理解がなければなりません。

つまり、「ひらめき」を有効に利用するためには、前提として問題に関連する知識の情報収集とそれらの情報を使った論理的思考が必要になります。

問題を徹底的に考えたうえで、あたための期間を持つことで「ひらめき」を得ます。そして、この「ひらめき」をさらに論理的思考で具体化していくことで、真に役に立つ解決策が得られることになります。

技術的問題を解決するために採用されるIPS（Inventive Problem Solving：発明的問題解決）ソフトウェア（ソフトウェアの名称はIWB（Innovation WorkBench®）という。）には組み込まれているオペレータは、技術的なアイデアを発想する際のヒントを提供するものです。

１つひとつのオペレータは、過去の発明のパターンを体系的に整理したデータベースの中の特定の知識です。IWBではオペレータの「タイトル」と「解説」と「事例」を知ることができます。IWBではオペレータのタイトルが約５００あるといいます。

すべてのオペレータに習熟すれば、そのタイトルを聞いただけで適切な発明パターンを活用することができることになるでしょう。それは理想ですが、一般の研究者、技術者にそこまで求めるのは酷です。

オペレータはタイトルとその解説を読んだだけでは何のことを言っているのかわかりづらいものもあります。ロシア語を英語に翻訳し、それを日本語に翻訳したわけですから、無理もないかもしれません。

そこで、特定のオペレータの意味を理解するのに役立つのが、事例ということになります。オペレータの事例は、過去の特許にかかわる技術やアイディエーション・インターナショナル社が手掛けたコンサルの事例に基づいて作成されています。

ただし、IWBに出てくる事例は軍事関係の技術や機械分野、建築土木分野、電気分野、化学分野のものが多いことは否めません。そのため、最新の情報技術分野などについてのものは見当たらないのも事実です。

たとえ、自分が関係する技術分野の事例が見つかったとしても、その事例は具体的なものですので、その用途特有の事情がわかっていないと（それについての予備知識がないと）理解できないものもあります。

また、機械、建設土木、電気、化学、その他にわけた場合のすべてについて、少なくとも１つの事例があるということでもありません。

そのような状態のオペレータを有効活用するにはどうしたら良いでしょうか？

実は、オペレータに付随している事例を自分の問題に直接類比させて使おうとすると辛いと思います。

これは、TRIZやI-TRIZに限った問題ではありません。一般の知識であっても、自分の知らないものは自分が知っているものになぞらえて理解するしかないのです。

初めて電気回路について学んだ時のことを覚えているでしょうか？

電気回路を水が流れる水路に見立てて、電圧を水路の落差に、電気抵抗を水路にかかっている水車に、電流を１秒間に水路を流れる水の量に、電池を上流まで水を汲み上げるポンプに、それぞれなぞらえて理解したのではないでしょうか。電気は目に見えませんが、水の流れなら見てわかるからです。

つまり、類比思考をする際に使用する他の分野の事例は、自分のよく知っている内容のものでなくては役に立たないということです。日本で生まれた創造理論である「等価変換理論」では、これを熟知系といっています。

オペレータの事例を使ってアイデアを発想する場合、そのオペレータを使う人によって知識経験が異なるわけですから、その事例はその人が良く知っているものでなければならないということです。

IWBに掲載されている事例がわかり難いということであれば、一つひとつのオペレータについて、あなたはあなたのよく知っている事例を新たに加えていくことが必要になります。

これがオペレータを使いこなすための極意です。

I-TRIZでは、問題の種類に関係なく同じ思考プロセスをたどることで、問題の状況が因果関係のダイヤグラムで表現されるため、課題が明確になりその課題を実現するための方策を考えるためのヒントを入手できます。

研究者、技術者はそのヒントを参考にして思いついたアイデアを記録していくことで、従来の試行錯誤法による場合に比べて短時間で課題を実現するための網羅的な検討が可能となります。

このようなステップ・バイ・ステップによる思考プロセスで円滑なアイデア発想を可能にしているのが、アイディエーション・インターナショナル社が開発した「オペレータ・システム」です。

I-TRIZのオペレータは、I-TRIZのソフトウェアの種類ごとに別個のオペレータが用意されています。

（１）技術的問題を解決するために採用されるIPS（Inventive Problem Solving）ソフトウェア（ソフトウェアの名称はIWB（Innovation WorkBench®）という。）には、IPS専用のオペレータ・システムがあります。

（２）故障・不具合分析と再発防止のために採用されるFA（Failure Analysis）ソフトウェアには、FA専用のオペレータ・システムがあります。

（３）故障・不具合予測と予防対策のために採用されるFP（Failure Prediction）ソフトウェアには、FP専用のオペレータ・システムがあります。

（４）新規事業や新商品の企画のために採用されるDE（Directed Evolution）ソフトウェアには、DE専用のオペレータ・システムがあります。

（５）発明強化、特許回避、発明評価を行うため採用されるCIP（Control of Intellectual Property）ソフトウェアには、CIP専用のオペレータ・システムがあります。

研究・開発部門、生産技術・品質管理部門、企画部門、知的財産部門などは、それぞれ特有の性質を持った問題を抱えているため、その問題の性質に合わせて特別な別個のオペレータとその体系を持ったものになっています。

問題の性質に応じて、それぞれのオペレータ・システムを使い分けることが理想になります。

たとえば、故障・不具合に関する技術的問題の場合であれば、IPS専用のオペレータ・システムを使うのではなく、FAまたはFP専用のオペレータ・システムを使ってその問題のメカニズムを明らかにすることで、故障・不具合に関する問題解決が一層容易になります。

（１）汎用オペレータ（どのような状況にも適用できる汎用性の高い方法）、
（２）一般オペレータ（機能を改良して、望ましくない作用を排除するための方法）、
（３）専用オペレータ（製品やプロセスの特定の特性を改良するための方法）、
（４）補助オペレータ（主要な方法を更に改善し、実現性の高い物とするための方法）、
（５）進化のパターン／ライン（I–TRIZの進化のラインに基づいて製品やプロセスを改良するための方法）

人間は常に新しいものを求める本能があります。同時に、自らの痛みを伴う「好ましくないと思える」変化には激しく抵抗する生き物です。

この２つの願望は、人間の抱えている本質的な矛盾の一つです。

新しい管理手法を導入しようとする場合に、必ず起きる葛藤でもあります。

あなたがI-TRIZを社内に導入しようとしているとしましょう。その際、導入予定先の部署の研究者、技術者の抵抗が大きい場合には、失敗する可能性が大きいといえます。

そこで、いかにしてそれらの研究者、技術者を納得させるかが問題になります。

生産現場の生産効率の向上を実現するための制約条件理論（TOC：Theory of Constraints）では、「変化に対する抵抗する原因」が何かを見定め、抵抗を力ずくで排除することなく、納得して「変化」を現実のものとすることを考えます。

TOCによれば、次のように「人間が変化に対して抵抗する６つの段階」があるといいます。

1. 問題そのものに対して同意しない

• 解決の方向性に同意しない

• 解決策が問題を解決することに同意しない

• 解決策を実行すると新たな問題が発生する

• 解決策実行前の障害を克服できない

• 未知の問題や障害に対する不安と恐れ

ここで、「（１）問題そのものに対して同意しない」とは、普段の研究開発効率が十分に高いと考えているため、そもそもI-TRIZを導入する必要性を感じていないという意見があがるようなことです。

「（２）解決の方向性に同意しない」とは、全員に強制しなくとも、仕事の遅い人たちだけが取り組めばいいという意見があがるようなことです。

「（３）解決策が問題を解決することに同意しない」とは、I-TRIZを導入しても研究開発の生産性が著しく向上するようなことは考えられないという意見があがるようなことです。

「（４）解決策を実行すると新たな問題が発生する」とは、従来の仕事のやり方を大きく変えることになるのではないかという意見があがるようなことです。

「（５）解決策実行前の障害を克服できない」とは、研究開発の成果を形にしようとした場合にいろいろな部門との調整作業が必要になるのではないかという意見があがるようなことです。

「（６）未知の問題や障害に対する不安と恐れ」とは、知らない手法が身につくかどうかわからない。従来の方法の方が馴染みがあって安心できるという意見があがるようなことです。

TOCは、これらの６つの抵抗の階層を克服してゆくためには、次の状態を順番に作っていけばよいといいます。

（１）問題について合意する
（２）解決の方向に合意する
（３）解決策が問題を解決することに合意する
（４）解決策の実行後に問題が起こらないことに合意する
（５）解決策実行前の障害を克服できることに合意する
（６）解決策の実行に合意する

実はこの思考プロセスがI-TRIZの基本的な思考プロセスと同じなのです。

I-TRIZの基本的な思考プロセスは、IWB（Innovation WorkBench®）という革新的な問題解決のためのソフトウェアに組み込まれている「アイディエーション・プロセス」というものです。

アイディエーション・プロセスは、（１）問題の情報把握、（２）プロブレム・フォーミュレーションとブレーン・ストーミング、（３）方策案のまとめ、（４）結果の評価、（５）実行計画の策定、といった項目からなっています。

（１）「問題の情報把握」の前半では、①問題状況を詳細に記録する、②システムアプローチを使って状況を多角的に分析する、ことを行います。つまり、プロジェクトメンバー全員が「問題の現状について合意する」ことに該当します。

（２）「問題の情報把握」の後半では、③問題が解決された理想的な状態を想定する、④システムとその環境に関連する資源を明らかにする、⑤システムを変化させるうえでの制約と制限を明らかにする 、⑥問題解決の成否を判定する評価基準を明らかにする、ことを行います。つまり、プロジェクトメンバー全員が「解決の方向に合意する」ことに該当します。

（３）「プロブレム・フォーミュレーションとブレーン・ストーミング」では、原因と結果の関係で結ばれた因果関係ダイヤグラムを作成し、問題状況に関する知識を整理します。その結果、問題解決に利用可能な思考上の領域を大きく広げることができ、問題を解決するための複数の指針（課題）が見えてきます。複数の指針の中から、検討する必要があると思うものを選んで、選んだ指針それぞれについて、指針が示唆するオペレータを使ってブレーン・ストーミングでアイデア発想をします。

また、「方策案のまとめ」では、問題の様々な側面にそれぞれ対処する複数のアイデアを組み合わせることによって、状況を大きく改善する方策案としてまとめあげます。つまり、プロジェクトメンバー全員が「解決策が問題を解決することに合意する」ことに該当します。

（４）「結果の評価」の前半では、満足できていない評価項目あるいは制限を、方策案を改善するために解決しなくてはならない新たな（二次的な）問題ととらえて、二次的問題を解決します。つまり、プロジェクトメンバー全員が「解決策の実行後に問題が起こらないことに合意する」ことに該当します。

（５）「結果の評価」の後半では、当初の問題を完全に解決する完璧な方策案でも、実行に移すと予期せぬ不具合がおこることがあります。既存のシステムを改善する新しい方策を導入した際に起こるかもしれない潜在的不具合を事前に予測し、予測した不具合を予防する対策を検討します。つまり、プロジェクトメンバー全員が「解決策実行前の障害を克服できることに合意する」ことに該当します。

（６）「実行計画の策定」では、方策案を実行に移す前に、効果を確認するために必要な調査／研究／実験の計画を立てる必要があります。実験をする場合には、実験の結果が何らかの判断について「はい」を意味するのか、あるいは「いいえ」を意味するのかが明確になるように計画します。また、はい、いいえ、それぞれの答えが出た場合について、次のステップはどうするのかあらかじめ計画しておきます。これで、研究開発のリスク管理は整いました。つまり、つまり、プロジェクトメンバー全員が「解決策の実行に合意する」ことに該当します。