人間は常に新しいものを求める本能があります。同時に、自らの痛みを伴う「好ましくないと思える」変化には激しく抵抗する生き物です。
この２つの願望は、人間の抱えている本質的な矛盾の一つです。
新しい管理手法を導入しようとする場合に、必ず起きる葛藤でもあります。
あなたがI-TRIZを社内に導入しようとしているとしましょう。その際、導入予定先の部署の研究者、技術者の抵抗が大きい場合には、失敗する可能性が大きいといえます。
そこで、いかにしてそれらの研究者、技術者を納得させるかが問題になります。
生産現場の生産効率の向上を実現するための制約条件理論（TOC：Theory of Constraints）では、「変化に対する抵抗する原因」が何かを見定め、抵抗を力ずくで排除することなく、納得して「変化」を現実のものとすることを考えます。
TOCによれば、次のように「人間が変化に対して抵抗する６つの段階」があるといいます。
- 問題そのものに対して同意しない
- 解決の方向性に同意しない
- 解決策が問題を解決することに同意しない
- 解決策を実行すると新たな問題が発生する
- 解決策実行前の障害を克服できない
- 未知の問題や障害に対する不安と恐れ
ここで、「（１）問題そのものに対して同意しない」とは、普段の研究開発効率が十分に高いと考えているため、そもそもI-TRIZを導入する必要性を感じていないという意見があがるようなことです。
「（２）解決の方向性に同意しない」とは、全員に強制しなくとも、仕事の遅い人たちだけが取り組めばいいという意見があがるようなことです。
「（３）解決策が問題を解決することに同意しない」とは、I-TRIZを導入しても研究開発の生産性が著しく向上するようなことは考えられないという意見があがるようなことです。
「（４）解決策を実行すると新たな問題が発生する」とは、従来の仕事のやり方を大きく変えることになるのではないかという意見があがるようなことです。
「（５）解決策実行前の障害を克服できない」とは、研究開発の成果を形にしようとした場合にいろいろな部門との調整作業が必要になるのではないかという意見があがるようなことです。
「（６）未知の問題や障害に対する不安と恐れ」とは、知らない手法が身につくかどうかわからない。従来の方法の方が馴染みがあって安心できるという意見があがるようなことです。
TOCは、これらの６つの抵抗の階層を克服してゆくためには、次の状態を順番に作っていけばよいといいます。
（１）問題について合意する
（２）解決の方向に合意する
（３）解決策が問題を解決することに合意する
（４）解決策の実行後に問題が起こらないことに合意する
（５）解決策実行前の障害を克服できることに合意する
（６）解決策の実行に合意する
実はこの思考プロセスがI-TRIZの基本的な思考プロセスと同じなのです。
I-TRIZの基本的な思考プロセスは、IWB（Innovation WorkBench®）という革新的な問題解決のためのソフトウェアに組み込まれている「アイディエーション・プロセス」というものです。
アイディエーション・プロセスは、（１）問題の情報把握、（２）プロブレム・フォーミュレーションとブレーン・ストーミング、（３）方策案のまとめ、（４）結果の評価、（５）実行計画の策定、といった項目からなっています。
（１）「問題の情報把握」の前半では、①問題状況を詳細に記録する、②システムアプローチを使って状況を多角的に分析する、ことを行います。つまり、プロジェクトメンバー全員が「問題の現状について合意する」ことに該当します。
（２）「問題の情報把握」の後半では、③問題が解決された理想的な状態を想定する、④システムとその環境に関連する資源を明らかにする、⑤システムを変化させるうえでの制約と制限を明らかにする 、⑥問題解決の成否を判定する評価基準を明らかにする、ことを行います。つまり、プロジェクトメンバー全員が「解決の方向に合意する」ことに該当します。
（３）「プロブレム・フォーミュレーションとブレーン・ストーミング」では、原因と結果の関係で結ばれた因果関係ダイヤグラムを作成し、問題状況に関する知識を整理します。その結果、問題解決に利用可能な思考上の領域を大きく広げることができ、問題を解決するための複数の指針（課題）が見えてきます。複数の指針の中から、検討する必要があると思うものを選んで、選んだ指針それぞれについて、指針が示唆するオペレータを使ってブレーン・ストーミングでアイデア発想をします。
また、「方策案のまとめ」では、問題の様々な側面にそれぞれ対処する複数のアイデアを組み合わせることによって、状況を大きく改善する方策案としてまとめあげます。つまり、プロジェクトメンバー全員が「解決策が問題を解決することに合意する」ことに該当します。
（４）「結果の評価」の前半では、満足できていない評価項目あるいは制限を、方策案を改善するために解決しなくてはならない新たな（二次的な）問題ととらえて、二次的問題を解決します。つまり、プロジェクトメンバー全員が「解決策の実行後に問題が起こらないことに合意する」ことに該当します。
（５）「結果の評価」の後半では、当初の問題を完全に解決する完璧な方策案でも、実行に移すと予期せぬ不具合がおこることがあります。既存のシステムを改善する新しい方策を導入した際に起こるかもしれない潜在的不具合を事前に予測し、予測した不具合を予防する対策を検討します。つまり、プロジェクトメンバー全員が「解決策実行前の障害を克服できることに合意する」ことに該当します。
（６）「実行計画の策定」では、方策案を実行に移す前に、効果を確認するために必要な調査／研究／実験の計画を立てる必要があります。実験をする場合には、実験の結果が何らかの判断について「はい」を意味するのか、あるいは「いいえ」を意味するのかが明確になるように計画します。また、はい、いいえ、それぞれの答えが出た場合について、次のステップはどうするのかあらかじめ計画しておきます。これで、研究開発のリスク管理は整いました。つまり、つまり、プロジェクトメンバー全員が「解決策の実行に合意する」ことに該当します。