For
going
back to English pages, press buttons.
編集ノート (中川 徹, 2005年 3月24日)
この論文は、来月米国で開催される予
定のTRIZCON2005 に 3月5日に提出した「第2の論文」です。実は、昨年 9月の論文アブストラクトの提出の際には、「ソフトウェア工学と
TRIZ (1)」の論文を申請しました。その後11月にフィレンツェでETRIA主催の国際会議があり、そのときのVictor
Feyの基調講演に対して、ぜひ反論をしておきたいと考えました。そこで、Altshuller
Instituteにメールして、もう一つの論文を提出することを願い出た次第です。論文集には入れるが、プレゼンテーションとしては待ち行列に並ぶとい
う条件で、受け入れていただきました。そして書き上げたのが、この論文です。
TRIZ
マスターの一人Victor Fey
が言ったのは、「TRIZの普及が遅れているのは普及のさせ方に問題があるだけで、TRIZが悪いのではない。ASIT
やUSITのようにTRIZを簡易化しようとするのはTRIZの能力を損なう。TRIZをいじるな (Don't Touch
TRIZ!)」ということでした (ETRIA国際会議報告参照 )。
私のこの論文はFeyの議論に正面から反論しているものです。結論としてつ
ぎの点を主張しています。
- TRIZの問題は、その全体的な手続きが複雑・非統一であることであり、その根本の原因は、TRIZの全体構造がデータフローで的確に表わせ
ないことである。
- TRIZの全体を再編成して、統合化することによってやさしくしたのがUSITである。TRIZはもう既に十分に再編成されており、強力だ
が、やさしくなっている。
- USITがつくり上げた新しい全体構造は、創造的問題解決にパラダイムシフトを促すものである。
論文のタイトルを提出してから、執筆を完了するまでに数ヶ月あり、いつの場
合も論文の内容はそのタイトルよりも先に進んでしまっているように思います。この論文もその典型です。自分としては非常に重要な論文が書けたと思っており
ます。TRIZCON2005での発表に先立ち、日本語に訳して掲載いたします。圧縮した形で書いておりますので、難解かもしれませんが、意のある所をご
理解いただけると幸いです。
なお、下記のHTML形式とともに、PDFファイルも掲載します。使いやすい方をお使いください。
<< PDF ファイル 1069
KB A4 26頁 >>
目次
1. はじめに
2. TRIZの全体構造と全体手続きを検討する
2.1 TRIZの知識ベースと個別の諸方法
2.2 TRIZにおける問題皆生の全体構造
2.3 TRIZにおける問題解決の全体手続き
2.4 強制類比によって諸モデルを使う基本的な方式
3. USITの全体構造と全体手続き
3.1 USIT
(統合的構造化発明思考法) の基本
3.2 USITの全体構造
3.3 USITにおける全体手続き
4. TRIZはすでにUSITに再編成されている
4.1 TRIZをUSITに再編した歴史と戦略
4.2 TRIZからUSITへの再編成 (1) 問題定義段階について
4.3 TRIZからUSITへの再編成 (2) 問題分析段階について
4.4 TRIZからUSITへの再編成 (3) 解決策生成段階について
4.5 創造的問題解決における4箱方式からのパラダイムシフト
5. USITによる問題解決の実際
5.1 USITトレーニングのための2日間セミナー
5.2 日本におけるUSITの推進と普及の事例
5.3 USITの今後の開発と普及に対する要求
6. おわりに
参考文献
編集ノート (中川 徹, 2005年 6月15日)
4月17-19日に開催されたTRIZCON2005においては、当初の予定を変更して、本論文を口頭発表しました。別ページの学会報告を参照ください。
何人かの人たちが、良い発表だったと言ってくれました。今回、英文の論文を『TRIZホームページ』に掲載します。またすでに、2005年5月号の
TRIZ Journalに 掲載されています。
TRIZ/USITにおける創造的問題解決のための
データフローの
全体構造
(Overall Dataflow Structure for
Creative Problem Solving in TRIZ/USIT)
中川 徹 (大阪学院大学)
TRIZCON2005、第7回Altshuller
Institute主催TRIZ国際会議、
デトロイト、米国、2005年4月17-19日発表予定 (英文)
(和訳:
2005年3月20日)
概要
TRIZそ
の他多くの科学技術上の問題解決手順において、共通に理解されていることの一つは、「各自の具体的な問題からその具体的な解決策に向かって直接進もうとす
るのではなく、何らかの標準的なモデル中の一般化した問題とその一般化した解決策を経由して迂回するのがよい」ということである。しかしながら、この方式
は、しばしば類比思考による写像を基礎にしており、分析する前にモデルを選択することの不明確さと、選択後の分析にそれぞれ異なるやり方を強いるという欠
陥をもっている。
USIT
法
における創造的問題解決の全体構造を、データフロー表現による6箱方式の形で構築した。ユーザの具体的ではあるが曖昧な問題を、まず適切に定義されたユー
ザの問題に変換し、そしてそれを分析して現在システムおよびその理想のシステムについての理解を得、ついで
(USITの解決策生成オペレータを用いて)
新しいシステムのアイデアに変換し、さらに解決策コンセプトを構築して、最終的にユーザの具体的な解決策として実装する。
そこでは
類比思考における写像が除去されていることに注目すべきである。問題解決者はその手続きの全過程を通じて、論理的でなおかつ創造的に導かれる。TRIZに
おける複線的な処理構造のもつ困難がなくなり、すっきりした処理構造になっている。TRIZにおいて開発されたすべての方法や知識ベースが、この新しい方
式に再構成され、統合され、単純化されている。
1. はじめに
TRIZその他
多くの科学技術上の問題解決手順において、共通に理解されていることの一つは、「各自の具体的な問題からその具体的な解決策に向かって直接進もうとするの
ではなく、何らかの標準的なモデル中の一般化した問題とその一般化した解決策を経由して迂回するのがよい」ということである。その基本的な方式は、「4箱
方式」[1] として表現できる (図1参照)。
図1. 問題解決一般における
「4箱
方式」
問題解決におけるこの「4箱方式」において、われわれはまず、ユーザの具体的な問題 (a) から一般化した問題 (b)
へと抽象化のレベルを「上がる」。そこでは、もとの問題の何らかの意味でのエッセンスを抽出して、その他の詳細あるいは本質でない部分を捨象している。つ
いで、一般化した問題 (b) を解決して一般化した解決策 (c)
に導くのに、理論、モデル、方法論などと呼ばれている何らかの標準的な方法を使う。そして最終的に、一般化した解決策 (c)
を手がかりとして使って、問題解決者は自分の具体的な問題 (a) に適用可能な、一つの具体的な解決策 (d) を見つけることが必要である。
しかしながら、この方式は、思考方法の骨格を示しただけであり、われわれが実
際に採用しようとする方法論に応じて、その内容を具体的にする必要がある。TRIZの中の個別の方法
(例えば、アルトシュラーの矛盾マトリックス法や物質-場モデルの方法など) は、この方式で比較的よく理解されている
(抽象的なレベルの理解であるが) [1]。ところが、
TRIZ方法論の全体構造はいままでこの方式で表現されたことがなく、筆者が最近表現した [2] のが初めてである。
TRIZの全体構造は、伝統的なTRIZ [3-6] においても、またDarrell Mann
による最近の現代化されたTRIZ [1]
においても、あいにく単純ではなく、どちらかというと混乱させる状況にあることが分かった [2]。この知見は驚くにあたらないともいえる。なぜなら、大抵の
TRIZの
専門家たちは、「TRIZによる問題解決の全体手続きに関して、専門家たちの間に多くの違ったやり方があり、対立するさまざまな意見がある」ことを前から
知っているからである。ここでのポイントは、「4箱方式」のような「データフロー図」の形式で表現した「全体構造」の方が、よく知られている「フロー
チャート」すなわち「処理フロー図」の形式で表現した「全体手続き」よりも、ずっと明瞭にTRIZの欠点の根源を示した [2]、ということである。
筆者が従来から推奨してきたのは、Ed Sickafus [7, 8] が開発し、筆者 [9-13] が拡張してきた USIT (統
合的構造化発明思考法)
を、TRIZを適用する簡単
で統合的で効果的な全体手続きとして使うことである。USITの全体手続きを示すフローチャート表現は、USITの開発の初期から、その単純ですっきりと
構造化された手続きを示すために使われてきた。USITの「全体構造」が描かれたのは、つい最近の筆者による文献 [2] が初めてであり、創造的問題解決の方法論のエッセンス
を理解するのにそれが非常に示唆に富むことが分かった。
本稿では、USITの「全体構造」と「全体手続き」とを、TRIZのものと比
較しつつ、さらに検討する。それらがもつ意味を、USITの適用法に関連させて、また創造的問題解決の一般的な方式の文脈において、議論する。
2. TRIZの全体構造と全体手続きを検討する
2.1 TRIZの知識ベースと個別の諸方法
よく知られているように、TRIZ [1, 3-6]
は、創造的問題解決を支援・リードするために、事例 (事実) と原理の多数の知識ベースを開発した。それにはつぎのものを含む。
- 物理的効果のデータベース
- 40の発明原理
- 矛盾マトリックス
- 76の発明標準解
- 技術システムの進化のトレンド、 な
ど
TRIZはまた、創造的問題解決を実施するための
非常に多くの個別の方法・技法を開発した。それらの一つ一つをどのように使うとよいかは、TRIZ専門家たちの間ではよく理解されている。つぎのようなも
のがある。
- 9画面法
(システム・オペレータ法とも呼ばれる)
- 物質-場モデル
- 技術的矛盾の方法
- 物理的矛盾の方法
- 小さな賢人たちによるモデリング
- 原因-結果分析
- 機能分析、機能属性分析:
など
2.2 TRIZにおける問題解決の全体構造
TRIZにおける問題解決の全体構造は、図2に示すように表現できる [2]。この図は基本的に「データフロー図」の形式で表現されてい
る。問題や解決策や知識ベースの情報を長方形の箱で示し、手続きとしての方法は楕円を伴った矢印で示している。主要な知識ベースおよび手続き的な方法につ
いて、それらの役割と位置は、TRIZの専門家たちの間では [この図に示したような] 基本的な意見の一致があるように見える [1, 3-6]。
図2. TRIZにおける問題解決の全体構造, 文献 [2]
この図は、TRIZにおける問題解決の全体構造に
ついて、つぎのような特徴的な点を示唆している。
- TRIZにおける知識ベースは、一般化した問題と一般化した解決策
の位置に置くことができる。いくつかの場合には (発明標準解や発明原理のよう
に)、一般化した問題は一般化した解決策から分離されているけれども、その他の
場合では (進化のトレンドや物理的効果のデータベースのように) 一般化した問題が一般化した解決策からあまりよく分離されていない。
- TRIZの主要な知識ベース (複数) は並行に位置づけられてい
る。なぜなら、それらは論理的に、逐次的な順序を一切持たないからである。それらは互いに多かれ少なかれ独立であるが、ある程度の重なりを持っている [1]。
- 問題分析段階の主要な方法は、それぞれ特定の解決策生成ツールと結びついている。その結果、問題の分析は一度に一つの方法で実施するのが普通
であり、問題の理解が部分的にしか形成されない [13]。
- 事例の例示が、一般化した解決策からユーザの具体的解決策へと具体化する段階に対しての、唯一の支援である。
2.3 TRIZにおける
問題解決の全体手続き
TRIZにおける問題解決の「全体手続き」とは、「上述の知識ベースや個別の
諸方法のすべてを効果的に使うような何らかの標準的な手続き」を意味する。[このような「全体手続き」をどう作るか]
はTRIZ専門家たちの間で従来から最も議論が分かれる点であった。ゲンリッヒ・アルトシュラーは、これらの知識ベースや個々の方法を、少しずつ、ときに
は並行して、またときには逐次的に開発していったのであり、それはより強力でより効果的な構成要素と全体手続きを探索した歴史であった。その結果、アルト
シュラーが [1] (ARIZと呼んで) 開発した全体手続き [3]、そしてその後に彼の多くの弟子たち
(例えば:Boris ZlotinとAlla Zusman [5]
や、Yuri Salamatov [6])
が提案した [それぞれの] 全体手続きなど、多数のバージョンが存在する。
図
3.
TRIZの全体手続き (Darrell Mann の「体系的技術革新」[1])
最近Darrell Mann [1]
が、「体系的技術革新」という名前で、TRIZの新しいバージョンを確立した。彼の方法論の全体手続きは図3に示すようである。この図で示している
[個別の] 諸方法は、彼の教科書 [1]
の章タイトルを基礎にしたものである。
図3の全体手続き [1] の主要な段階はつぎのように要約できる。
- (1) 問題定義段階: 3方法
(すなわち、問題探索、機能/属性分析、およびS-カーブ分析) が必須であり、あと一つ (すなわち、究極の理想解)
が強く推奨されるものである。9画面法はこの段階に最も関係するが、[後の段階をも含めて] 手続き全体で働きをもつものである。
- (2) ツール選択段階:
問題の状況に対応して、一つの特別な表が、解決策生成ツール群のうちの適切なものをいくつかユーザに推奨する。問題状況の19の場
合に応じて、それぞれ 4つまでのツールを優先度をつけて推奨する。
- (3) 解決策生成段階:
解決策生成のためには11個の個別ツールがある。これらのツールを学ぶのに、自分自身の問題で適用する必要が出てきたときに一つず
つ学ぶことを、Mannは薦めている。
- (4) 解決策評価段階:
いままでに生成した解決策の中でどれが最も優れているかを決め、そしてその解決策が十分良いものかを判断する。もしまだ不満足な
ら、ツール選択段階 (2) に戻るか、あるいは、問題を定義し直すために手続き全体の最初に戻る。
Mannはこれらの方法のすべてを明快に記述しているけれども、彼の
(新しい世代の) TRIZの全体手続きはつぎのような問題点を含んでいる。
- 問題とその[対象の]
システムとを分析するフェーズが明確にされていず、ばらばらになって問題定義段階中 (例えば、機能/属性分析) と解決策生成段階中
(例えば、矛盾マトリックスの方法、物質-場分析など) に含まれている。
- ツール選択表があまりにも大きくて複雑であり、記憶できない。
- 解決策生成段階に非常に多数のツールがあり、それらは互いに多か
れ少なかれ独立であるが、それでいて互いに重複があり [その重複のしかたに] 明確な思想がない。
- 解決策生成段階のツールの大部分がそれぞれ独自の分析法を内蔵あ
るいは要求しており、各分析法では問題状況の部分的な理解しか与えない。
2.4 強制類比
によって諸モデルを使う基本的な方式
TRIZにおいてモデル (または知識ベース)
を使う上での基本的な前提は、多くの科学・技術の方法論と同様に、図4のように示すことができる。
図4. 問題とその解決策のモデルを使って問題解決を行う4箱方式
この方式
は、図1に示した基本的な「4箱
方式」をほんの少し修正したものであり、それは、図で破線の箱で囲んで示しているように、一般化した問題と一般化した解決策とを組にしている点である。こ
れは極めて自然なことである。なぜなら、非常に多数のモデルがすでに構築されており、各モデルは典型的に問題とその解決策の組として与えられているからで
ある。そのようなモデルはあらゆるところにあり、教科書や、特許データベースや、ソフトウェアツールなどの形になっている。それらのモデルをごちゃ混ぜに
して、違ったモデルに属する解決策を選び出すことは、全く無意味なことである。
しかしながら、このわずかの修正が、問題解決手続きに重要な違いを引き起こ
す。その理由は、異なるモデルが異なる抽象化の方法を必要とするのが普通だからである。一つのモデルの一つの一般化した問題が、[この際の]
抽象化の目標である。そこで、手元にある一つの具体的問題に対しても、問題を解決しようとする者は、さまざまなモデルによって要求されるさまざまに異なる
方法で抽象化しなければならない。
そのため、この方式では、一つの具体的な問題を以下のやり方で解決しようとす
る [2]:
- まず最初に、一つのモデルを選択する。
- ついで、そのモデルが要求してくるやり方で、自分の具体的な問題
を分析し (あるいは、抽象化する、写像するという)、一般化した問題を得る。
- さらに、そのモデルの方法に従って、一般化した問題を解決して、
一般化した解決策を得る。
- 最後にそれを一つの具体的な解決策とするように具体化を試みる。
- 得られた具体的解決策を評価し、さらに、異なるモデルを一つまた
一つと選択して上記の手続きを繰り返し、満足する解決策を見つけるか、あるいはすべてのモデルを試し終わるまで続ける。
こ
の手続きは、「前もって任意に選んだ一つのモデルの問題に、具体的な問題を写像する」ことにクリティカルな基礎を置いている。この写像過程を論理的に行え
るように支援する分析方法をモデルが備えている場合もある。しかし、発明の文脈で言えば、モデルというのが単に先行事例であり、この写像過程をリードする
明確な方法をもっていないことがしばしばである。後者の場合にはこの手続きは「強制類比」と呼ばれる。直感的な思考やひらめきが、そのような場合の問題解
決の主要な源である。
図4の方式においては、問題解決の有効性に一つの逆説が生じる。
- 「モデルが多くなるほど有効性が減少する」逆説: 一つの方法論が持つモデ
ルの組において、各モデルは諸問題を解決するのに部分的な適用性しか持たないとすると、その方法論の中にあるモデルの数が多くなればなるほど、その方法論
全体としては、より強力になるが、有効性は減少する。
この状況において、われわれはいままでのどのモデルも万能ではないことを知っ
ているので、われわれはさらに多くのモデルを持ちたいと思う。一つのモデルを選んで、図4に
示した手続きを実行して、ある程度の満足度の一つの具体的解決策を導き出すことができよう。しかしわれわれはもう一つのモデルを選択したいと思う。なぜな
ら、そのモデルで、より満足度の高い違った具体的解決策を導き出す可能性があるかもしれないからである。すべてのモデルについてやってみた後で初めて、わ
れわれはその方法論で得られる最良の解決策を見つけたのだと自信をもっていえる。モデルを増やすことによって、モデルの組全体から得ることができる解決策
の最良のもの (すなわち、その方法論の「強力さ」)
は、より良くなるかあるいは前と同じである。しかしながら、コスト-パフォーマンスの意味での、そ
の方法論の「有効性」は、(増大することもあるが) 減少することがある。
伝統的なTRIZにおける全体手続きに関連した現在の状況は、そのような逆説
に陥っているように見える。主要なモデル (すなわち、発明原理、発明標準解、および進化のトレンドなど)
およびそれらの内部での多数のサブ原理が、並列した位置関係にあることが、この「モデルが多くなるほど有効性が減少する」逆説を引き起こしている。
そのような逆説的状況にある全体手続きの有効性を増大させるために、われわれ
はさまざまに異なる戦略を取ることができる。理論的なものもあり、実際的なものもあるが、以下に列挙するようである。
- ある範囲の問題に対しては高い満足度の
(一般化した、または具体的な) 解決策をつくり出すようなモデルにする。-- 例: 物理的矛盾のタイプの問題に対する分離原理 [3]
- 個々のモデルを、ある領域/タイプの問題に対して高い適用性を持
つようにし、またその適用性がすぐに分かるようにする。-- 例: 進化のトレンド [1]
- 各モデルの強力さと有効性とをあらかじめ
(経験またはベンチマークテストにより) 評価しておき、その評価結果から決定される優先順位に従って個々の方法を使う。-- 例:
Mannによるツール選択表 [1]
- 個々のモデルで強力さに劣り、有効性に劣るものを除去する。--
例: イスラエルのSIT および ASIT [14]
- 先行するモデル [を使ったときの]
情報が後続のモデルを使うときに助けになるような順番に、複数のモデルを並べる。-- 例: ARIZ (技術的矛盾、その後に物理的矛盾) [3]
- 共通の抽象化 (すなわち、分析)
の方法を適用できるような一組のモデルを作る。-- 例: 機能分析を多数のツールのための共通の基礎として使う [1]
- 関
連するモデル群をより単純で強力で有効性が高いような新しいモデルに統合できるような、何らかの共通の枠組みを導入し、古いモデルを除去する。--
例: USIT [7] (第3節参照)
3. USITの全体構造と全体手続き
3.1 USIT
(統合的構造化発明思考法)
の基本
USIT
は1995年にEd Sickafus [15]
が開発したもので、フォード自動車社で集中的に使われた。彼は最初に、TRIZを大幅に簡略化したイスラエルのSIT (体系的発明思考法) [14]
を導入し、その後に新しい枠組みを導入してUSITを作った。筆者は1999年以来USITを日本に導入して [9]、さらにTRIZの解決策生成の諸方法をUSITの枠組み
に再編成することによりUSITを拡張した [10]。
USIT (特に、日本での現行のもの) は、つぎのような一般的な特徴をもつ [2]。
- USITは、創造的な問題解決のための、統合され、構造化された
方法論であり、技術分野を主要な目標とする。
- USITは、特にその思想においてTRIZを基礎にし、また
TRIZから導いた多くの方法を含んでいるので、TRIZを適用する新しいやり方、あるいは新しい世代のTRIZであると見なすことができる。 [注1: Ed
Sickafus自身は、USITがTRIZの一部分であるとか、TRIZの一つの形であるとかと言ったことはまったくない。(Sickfus
私信) ]
- USITは、製品のライフサイクルの任意の段階での技術的問題に
適用して、概念レベルでの創造的な解決策を得ることを、意図している。
- USITは問題解決者を、特にその考えるステップ、考える方法の
点で、道案内する。
- USITは明確に定義された全体手続きをもち、それは
3段階で構成される (すなわち、問題定義段階、問題分析段階、および解決策生成段階である)。
- USITはまた、明瞭な全体構造をもち、各段階での入力・出力の
情報に対する要求が明瞭に定義されている。
- USITは、オブジェクト-属性-機能という概念を、方法論の新
しい枠組みとして統一的に用いる [7]。
- USITは、伝統的なTRIZとは対照的に、知識ベースやハンド
ブックやソフトウェアツールなどに依存しない。
3.2 USITの全体構
造
USITにおける創造的問題解決の全体構造は、図5に示したようである [2]。
図5.
USITにおける問題解決の全体構造, 文献 [2]
図5中の6個の箱は、問題解決の各段階における情報を示している。それらを以下に簡潔に
まとめる。
(a) ユーザの具体的問題: ユーザが一つの問題を
認識しており、それはぼんやりしていることもあれば先鋭的なこともあり、しばしば複雑でこんがらがった状況の中にある。
(b) 適切に定義された具体的問題: 問題定義段階の結果で
あり、そこではこの [問題解決の] プロジェクトで解決しようとする一つの問題が決定された。その問題は以下の情報を持っていなければならない
[明示
していなければならない]。
- 望ましくない効果:
われわれが除去したい/防止したい/減少させたいなどと思っている一つの効果。
- 問題宣言文: [問
題解決の] プロジェクトの課題と目的を明確にして、1-2行で書いた宣言文。
- スケッチ: 問
題の状況をそのメカニズムが分かるように描いた簡単な図。
- 考えられる根本原因:
望ましくない効果の根本原因を記述したもの。実験によって同定されたものであることが望ましいが、そのメカニズムをできる限り分析
して推測したものであってもよい。複数の原因を列挙してよい。
- 最小限のオブジェクトの組: そ
の問題を含むのに必要な最小限の関連するオブジェクト (すなわち、構成要素) の組。
(c) 現在のシステムおよび理想のシステムの理解: 問題分析の結果として
得られたものであり、この情報が一般化した問題を形成する。問題とする現在のシステム (あるいは、現在の技術で可能と思われる基本システム)
について、つぎのような点から表現する [7]。
- オブジェクト-属性-機能: オブジェクト間の機能的関係を機能分析図として表現する。特に、本来の設計が意図したメカニズムを明
らかにすることを目的とする。また、オブジェクトの諸属性 (すなわち、性質のカテゴリのことで、性質の値ではない)
で、望ましくない効果に関連するものを列挙する。その目的は、考えられる根本原因を確認し、望ましくない効果を変えるさまざまな可能性を明らかにすること
である。
- 空間と時間: システムと問題の状況
の特性を、空間と時間とに関して明らかにする。この情報は [問題の基本的な理解として重要であるが、特に]
物理的矛盾を解決するための背景となる手がかりを提供する。
また、問題に対する理想のシステムを同定し、つぎのような点から分析する
[7]。
- 望ましい行動:
理想のシステムの振る舞いをイメージし、平易な非技術的用語を使って望ましい行動を階層的に示す。
- 望ましい性質: 理想のシステムの望ま
しい行動を支援するために [理想のシステムがもっているとよい] 望ましい性質を思いつくままに列挙する。
(d) 新システムのための新しいアイデアの断片: 一般化した解決策の初
期の形であり、現在のシステムの要素を修正したり、あるいは新しいシステムの何らかの部分を構築するための新しいアイデアの断片である。それらは、(c)
の情報の用語で、また、(c) の情報を背景として表現される。
(e) 解決策コンセプト: コンセプトレベルの新
しい解決策で、適切に定義された具体的問題 (b)
の要求に適合するように組み立てたもの。それらはまだ定性的なものであり、工学的に設計されたものではなくてよい。これが、創造的問題解決法としての
USITに
おける解決策生成の目標である。
(f) ユーザの具体的解決策: [ユーザの具体的問
題]
(a) におけるユーザの要求や要望を満たす具体的な解決策であり、解決策コンセプト (c) に
対して実際にそれを実現するための作業をしてはじめて得られるものである。最終的な解決策は、技術的、ビジネス的、社会的な判断基準で検証した後に、新し
い製品として提供したり、装置に組み込んだりして、実現する必要がある。問題解決の全過程が成功したといえるのは、この解決策 (f)
が、技術的、ビジネス的、社会的な状況の中で、うまく受け入れられたときに初めていえる。
3.3 USITにおける全体手続き
図5に示
した創造的問題解決の全体構造は、USITにおいては、図6のフローチャートに示すような全体手続きを使って実現される。USITのフローチャートは、
USITの開発の初期段階
[7]からずっと使われてきたものであり、そのときどきに微小な改良を繰り返してきた [9, 2]。注目すべきは、USITのフローチャートは主要な
3段階がすっきりと逐次構造で表現されていることである。すなわち、問題定義段階、問題分析段階、そして解決策生成段階である。(これらのUSIT手続き
に後続するものとして、「実装段階」を追加した上で) 以下に簡単に説明する。
図6. USITにおける問題解決の全体手続き (フローチャート)
(1) 問題定義段階:
ユーザの具体的問題 (a) を適切に定義された具体的問題 (b)
に変換するプロセスである [7]。このプロセスは通常、USITプロジェクトチームのグループ討議によって実施される
(5.1節参照)。適切に定義さ
れた具体的問題 (b) に対する要求項目がグループに示され、USITではそれ以上の特別な手続き的方法は提供されていない。
(2) 問題分析段階:
(c) 適切に定義された具体的問題 (b) において、現在のシステムと理想のシステムの理解を得るために、以下の3つの分析法を逐次実行する
[7, 8, 9]。
(2-1) 現在のシステムの機能と属性の分析 (「閉世界法」): 問
題の現在のシステムをつぎの二つの方法を順次使って分析する。
- 機能分析 (「閉世界ダイアグラム法」): 現
在のシステムのもとの設計における機能的関係を描く。システム中の最も重要なオブジェクトを最上位に描き、その他のオブジェクト
を逐次その下に、より上位のオブジェクトの機能を支援するための「機能的に好ましい関係」 (すなわち、有用機能) の順に記述していく。
- 属性分析 (「定性変化グラフ法」): 望
ましくない効果を代表するパラメータ (あるいは、逆に、性能を代表するパラメータ)
を選び、システム中のすべてのオブジェクトの関連する属性について、望ましくない効果のパラメータと正の相関があるか負の相関があるかを区別した上で列挙
していく。
(2-2) 空間と時間の特性の分析: シ
ステムあるいは問題について、空間そして時間に関する特性を明確にすることを目的にして、何らかの図を描く。典型的には、システムの振る舞いを表現する適
当なパラメータを、特徴をとらえた空間の座標に関してプロットし、また同様に時間座標に関してプロットする [9]。またときには、特徴的な空間軸および時間軸に対して、実際
に作用している機能を単に書き並べるだけでも有用である。
(2-3) Particles法: 理想の解決策を同定し、その望ましい行動と望ましい性質をイメージするための一つのプロセスを、つぎ
の順で実施する [7, 9]。
- 現在のシステムのスケッチを描く:
特に、問題の起こるメカニズムを示すようにする。
- 理想のシステムのスケッチを描く:
理想の結果をイメージして、それを描く。その結果を実現するための手段を描きこもうとしてはいけない。
- 'Particles' を x 印で描く: 理想のシステムのスケッチが現在のシステムのスケッチと違っている位置にx
印を描く。このx印をこれからは'Particles' (「粒子」)
とみなし、任意の望ましい行動をすることができ、任意の望ましい性質を持つことができるような、魔法の物質または (TRIZの意味での)
「場」であると想像する。
- 望ましい行動をイメージし、それを階層的な図に描く: 魔法のParticlesに理想の解決策の目標を実現して貰うように頼み、そして、
Particlesたちがわれわれの代わりにやってくれている行動をイメージして、それを逐次詳細化する。望ましい行動は論理的なAND/OR
ツリー図の形式で記述していき、それによって解決策の階層的な表現のプロトタイプを作り出す。
- 望ましい性質を列挙する:
望ましい行動のそれぞれを支援するのに望ましい性質を列挙する。この段階では、アイデアの空間を広げることが、アイデアの実現可能
性を判断して選択していくことよりもずっと重要である。
(3) 解決策生成段階:
新しいアイデアの断片 (d)
を多数生成し、そして、新しいシステムのための解決策コンセプト (e)
を組み立てるためのプロセスである。USITオペレータの形式の、5種の解決策生成法を、特に順番にこだわらずに繰り返し適用する [7, 10-12, 16]。
- オブジェクトの複数化: ここでの「複数」とは
[英語のセンスで] 1以外の任意の数を意味する。すなわち、0、2、3、... ∞、1/2、1/3、...
1/∞、0.9、1.1、などである。そこで、オブジェクトをトリミングする
(0)、複数倍する (2、3、... ∞)、分割する (1/2、1/3、...1/∞)、修正する
(0.9、1.1、など)、新規に導入する、などの操作がある。
- 属性の次元的変化:
各オブジェクトは広範囲の属性をもっている、すなわち、性質に関する多数の次元をもっている。そこでUSITオペレータは属性についての次元的な変化を提
供している。すなわち、新しい属性を使う
(あるいは活性化する)、ある属性を消去する (あるいは非活性化する)、ある属性に空間的あるいは時間的依存性を導入する、などの操作がある。
- 機能の再配置: システム内の諸機能
を、オブジェクト間および空間と時間に関して再配置し、それによって有用機能をよりよく作用させ
(あるいは新しく導入し)、また有害機能を防止あるいは
減少させるようにする。
- 解決策の対の組合せ: 解決策
(あるいは解
決策の要素) の対を、さまざまなやり方で (空間的に、時間的に、機能的関係で、構造的関係で、など)
組合せ、それによって対をなす両方の解決策の弱点を克服して、よりよい解決策にする。
- 解決策の一般化: さまざまな解決策を、
一般化 (すなわち、抽象化) と特殊化 (すなわち、具体化)
とを繰り返し適用して、拡張・強化し、またそれを通じて解決策の体系を階層的な構造に組み上げる。
これらの5種のUSITオペレータは、オブジェクト-属性-機能という用語で
表現されている現在のシステムと解決策のシステムの諸要素に対して、また既知のおよび新しく生成した解決策に対して、いつでも適用可能である。そこで
USITに
おいては、(c) から (d) への過程 (すなわち、新しいシステムのためのアイデアの断片を得る過程) と、(d) から (e) への過程
(す
なわち、解決策のコンセプトを組み立てる過程)とは、不可分の繰り返し過程として実施される。
(4) 実装段階 (USITの
直後の段階):
解決策のコンセプ
トを、評価し、実験し、試作し、設計し、製造し、組み込み、試験などをしてはじめて、ユーザにとって成功といえるような具体的解決策にまで実現していくこ
とができる。この段階は技術的なまたビジネス的な能力と決断とを必要とする。そのためこの段階は、創造的問題解決の方法論としてのUSITの枠外にある。
4. TRIZはすでにUSITに再編成されている
4.1 TRIZをUSITに再編した歴史と戦略
TRIZ
の諸方法、諸原理、および思想が、どのようにしてUSITのものにすでに再編成されたのかを、本節に記述する。歴史的に、この再編成は3つの大きな段階を
経て達成された。
- Genady Filkovski が、1980年代にイスラエルにおいて、TRIZをずっと簡略化してSIT をつくった。文献 [14] 参
照。
- Ed Sickafus が、1990年代後半に米国において、SITを導入・強化し、USITの新しい枠組みをつくった [15]。
- 中川
徹が、近年日本において、TRIZの諸方法を再編し
てUSITオペレータにすることにより、USITの解決策生
成法を豊富にした [10]。
注意すべきは、一つ
の方法論をもう一つのものに変換するためには、さまざまなタイプの変換 (とそれらの組合せ)
が理論的には可能なことである。それらの中には、無変化、消去、分割、摘出、修正、併合、柔軟化、もう一つの次元の導入、追加、パラメータの変更、拡充、
組み合わせ、標準化、トリミング、単純化、分類、グループ替え、統合、新しい枠組みの導入、再編成、などなどがある。
TRIZ
からUSITへの変換の場合には、TRIZがすでにあまりにも大きく、豊富で、複雑であったから、最も意味のある戦略は、「新し
い枠組みへの再編成」と「統合による単純化」であった。(2.4節末尾のコメントを参照されたい。また、多くの
他の戦略、例えば、TRIZに手を触れずにTRIZを強力なものに保とうとする戦略 [17]、どれかの方法を強化したり追加の方法を導入したりして
TRIZをより強力にしようとする戦略、あるいは、TRIZの一部分だけを使うことにより適用しやすくしようとする戦略、などとの対照に留意されたい。)
この再編
成の結果について以下に記述するにあたり、日本における現在のUSIT
[2] の各構成要素と、Darrell
Mann が編纂した現在の形のTRIZ [1]
の各構成要素との関係を示すことにしよう。
4.2 TRIZからUSITへの再編成
(1) 問題定義段階について
問題定義
段階のためのUSITの諸方法は、Sickafus
[7] [11]が再編成を行った [7]。
Mann によるTRIZの諸方法 [1] と
USITの諸方法との間の関係は、図7に示すように要約できる。
この段階に対するUSITは、随分単純であり、USITのプロジェクトメン
バーの間の討論によって得るべき情報に対する要求を示すだけである。USITで重点を置いているのは、問題宣言文 (すなわち、問題解決の目標の宣言)
と、考えられる根本原因 (すなわち、解決しようとする問題の起源についての理解) である。
図7. TRIZからUSITへの再編成 (1) 問題定義段階について、文献
[11] 参照
4.3 TRIZからUSITへの再編成 (2) 問題分析段階について
問題分析段階に関して、現在のTRIZの諸方法と現在のUSITの諸方法との関係は、図8に示すように要約できる [11]。Sickafus [7]
は、イスラエルのSITから閉世界法を採用し、アルトシュラーから小さな賢人たちによるモデリングの方法を採用したが、彼はそれらをさら改良し豊富にし
た。
図
8. TRIZからUSITへの再編成 (2) 問題分析段階、文献 [11] 参照。
Sickafus [7] が、オブジェクト-属性-機能という基本概念を導入した
ことが、システムを理解するためのUSITの新しい枠組みとして重要である。USITの機能分析が、最小限のオブジェクトの組の間での意図された有用機能
を簡潔で理論的なやり方で表現し、一方、望ましくない効果に関連する属性が定性変化グラフの中で列挙される。システムの空間と時間に関する特性がまた、
USITにおいては簡単なグラフ表現を用いて分析される。これらすべてのUSITの方法は、現在のシステムを理解するのに、簡単で、十分で、同時に効果的
であるように設計されている。[TRIZの] 物質-場分析は機能分析で置き換えられている。
技術的矛盾お
よび物理的矛盾を定式化するためのTRIZのプロセス [1] は、USITでは意図的に消去されている
[7]。技術的矛盾を矛盾マトリックスのパラメータで定式化する代わりに、望ましくない効果に対するさまざまな属性の関係が検討され、問題の状況をより明
らかにしている。そして、USITでは、少数の解決策生成オペレータを選択することは必要ないから、矛盾マトリックスを使わない。また、USITでは、シ
ステムの特性を空間と時間に関して必ず検討し、物理的矛盾がもしあるとすればそれを解決するための準備にしている。(この準備により、物理的矛盾は、明確
に定式化しないでも、解決策生成段階で解消することができる。) このようにして、初心者にとって最も難しいTRIZの二つの部分
(すなわち、矛盾マト
リックスにおける [技術的] 矛盾の定式化と、ARIZにおける [物理的] 矛盾の定式化) を、USITではトリミングしたのである。
アルト
シュラーの「小さな賢人たちによるモデリング」[4] (す
なわち、空想を自由に刺激するために代理人を使うもの) は、USITではParticles法として強化された [7]。Particles法は、理想のシステムを望ましい行動
と望ましい性質という用語でイメージすることが [アルトシュラーの方法に]
結合され、さらに、解決策コンセプトの階層的な体系を構造化して考えるための準備とも統合されている。
4.4 TRIZからUSITへの再編成
(3) 解決策生成段階について
TRIZ
の解決策生成の諸方法は、イスラエルのSITにおいて4方法だけに単純化され [14]、そして、
Sickafusによって5方法に改良された [7,
8]。その後、筆者らが、TRIZの解決策生成法の全体をUSITオペレータの枠組みに、図9に示すようにして、再編成した[10]。
図9.
TRIZからUSITへの再編成 (3) 解決策生成段階、文献 [10]参照
かくてUSITは、解決策生成オペレータの階層
的体系をもち、5種の主要なオペレータおよび、合計32種のサブオペレータ) から構成されている (3.3節の説明を参照)
[10, 16]。この再編成は、分類のし直し、統合、そして体系化をしたケースであるといえる。解決策生成法の全体系は、はるかに単純に
なり、その強力さを失わずにより効果的になった。以下の諸点に注目すべきである。
- USITオペレータは、現在のシステムと新しい [解決策の]
システム中のさまざまな可能な対象 (すなわち、オブジェクト、属性、機能、解決策など) にすぐに適用可能である。
- 矛盾の解消 (特に、物理的矛盾の解消)
は、解決策組合せ法のUSITオペレータを使うことにより、容易に (ときには、矛盾に気づかないうちに) 達成される。[この解決策組合せは]
TRIZの分離原理を適用するときに最も難しい第3フェーズに対応するものである。
- 解決策一般化法のUSITオペレータは、TRIZに起源を持って
いない。この方法は可能な解決策コンセプトを体系化するのに非常に有用である。
4.5 創造的問題解決における4箱方式からのパラダイムシフト
図5に示
したUSITの全体構造は、一層簡単な形式で図10に示すように表現できる
[2]。この図は単純であるが、それでいて多くの観点から非常に有意義であることが分かった。それは特に、創造的問題解決一般に関してわれ
われにパラダイムシフトを促すものである。この図がもっている3つの主要な含意を本節で議論しよう。
図10. 「6箱方式」:
USITにおける創造的問題解決、文献 [2] 参照。
(1) 「6箱方式」: 基本的な「4箱方式の詳細化」としての見方
「6箱方式」がもつ第一の主要な含意を、図11に示す。われわれは、箱
(a) と箱 (b)
とを一緒に囲んで、「具体的問題」という箱にしてもかまわない。それは、問題定義のプロセスを具体的問題を宣言する内部での詳細化過程であるとみなしてい
ることになる。われわれはまた、箱 (e) と箱 (f)
とを一緒にして、「具体的解決策」という箱にしてもよい。なぜなら、実装のプロセスは具体的解決策の内部の詳細化であるとみなしてもよいからである。この
ようにして、われわれのUSITの「6箱方式」(図10) は、図1の基本的な「4箱方式」を実現する一つの形式であると解釈できる。
図11. 「6
箱
方式」: 基本的な「4箱方式」の詳細化としての見方
図
11に関連
して、つぎの諸点に留意されたい。
- 創造的問題解決のためには、具体的問題は「適切に定義された」もの、すなわち、焦点を絞ったものとして用意するべきである。
- 抽象化は、現在のシステムと理想のシステムをよく理解することを目的として、なんらかの標準的な分析法を用いて実施するべきである。
- 現在のシステムとそれに対応する理想のシステムについての抽象化した理解が、一般化した問題を形づくる。システムを理解する枠組みは、オブ
ジェクト-属性-機
能と空間および時間である。一般化した問題が、教科書中のモデルから来るのではまったくないことに注意すべきである。枠組みが [教科書で] 与
えられているだけであって、一般化した問題の中身はユーザ自身の具体的問題だけから来るのである。
- 一般化した解決策は、その初期には、システムの抽象的な理解における新しいアイデアの核となる断片として得られる。そのようなアイデアは、抽
象化した世界でのシステムまたは解決策の要素に対する何らかの単純な操作によって形成できる。USITオ
ペレータ群は、この過程における変換操作の体系的な一つの組を提供している。
- そ
のような新しいアイデアの核となる断片は、一つの解決策コンセプトに組み上げる必要がある。解決策コンセプトは、まだ定性的なものであるが、工学的に試行
してみる価値があるものである。これは具体化のプロセスの初期部分であり、工学面での創造的な能力を必要とする。解決策コンセプトが創造的問題解決方法論
の目標 (ゴール)
である。
- 解決策コンセプトはさらに、ユーザの現実世界での具体的な解決策にまで実装・実現されなければならない。このプロセスはユーザの具体的問題の
詳細化であるとみなしてよい。
(2) 簡単なアイデア生
成が抽象化から具体化への飛躍を創り出す
「6箱方
式」の第2の主要な含意を図12に図示する。左の列の3個の箱、そして右の列の3個の箱が、それぞれグループ化されている。この図はつぎのような意味を示
唆する。
図12. 「6箱方式」:
単純なアイデア生成が抽象化の系列から具体化の系列への飛躍を創り出す
- 左
の列の3個の箱は、ユーザの問題を抽象化する系列である。USITが提供する枠組みを使って、標準的なやり方で、問題をまず定義し、さらに問題を解
析する。この抽象化のプロセスは、(USITのような) 創造的問題解決の一つの方法論によって導かれる必要がある。
- 右の列の3個の箱は、新しい一つのアイデアをユーザの世界で具体的
に適用できる現実の解決策にまで実現する (具体化する) 系列である。一つのアイデアを、解決策コンセプトに組み立てる必要があり、さらに、
それを実際の解決策にまで実装する必要がある。この実現プロセス (具体化プロ
セス) は、適用する分野に依存した、なんらかの創造的な工学的方法論によっ
て導かれる必要がある。
- 最もクリティカルなプロセスは、核となる新しいアイデアの有用な断片を生成することである。この生成プロセスはUSITオペレータによって効果的に支援される。USITオペレータの個々の操作は小さくて単純であり、核となるアイデアもまた (たとえ大発明の場合でさえ) 小さく
て単純であろう。
- 図4における「一般化した問題と解決策の対」というモデルは、この
図12で (ま
た、図10や11で
も) 消滅してしまっていることに注意されたい。これが意味するのは、(USITにおける) 創
造的問題解決の「6箱方式」は、もはや「強制類比」の思考ではまったくないこと
である。われわれは、モデルを選択して、モデルに依存した抽象化-具体化の試行
を繰り返すというループを、もはや必要としないのである。
(3) 問題解決の抽象世界を問題がある現実世界に位置づける
「6箱方式」がもつ第3の主要な含意を、図13に示す。上部の4箱をグループ
化して、それらがUSITにおける問題解決の抽象化した世界に属していることを示し、一方、下部の2箱が現実世界に属することを示す。これが意味するのは
つぎのような点である。
図
13. 「6箱方式」: 問題解決の抽象化世界を問題の現実世界に位置づける
- 創造的な問題解決は、考えることが強力で効率的な推進力である
「抽象化した世界」で行う必要がある。
- ユーザの現実の世界において、ユーザの具体的な問題を「適切に定
義された具体的な問題」 (すなわち、焦点を絞った問題)
に変換して、抽象化した世界に手渡せるようにする必要がある。このプロセスは、現実世界の技術的、ビジネス的、社会的文脈で行う必要があり、従ってそれら
判断基準で評価すべきである。
- (上部の4箱は抽象化した世界に属し、そこでは、
「適切に定義された具体的問題」を最終的に)
なんらかの解決策コンセプトに変換することが要求されている。結果として得られる解決策コンセプトは、現実世界の文脈において、創造的で、適用可能である
べきである。
- 解決策コンセプトは、現実世界で利用可能な資源と方法を使って、
ユーザの具体的解決策にまで実装する (実現する) 必要がある。
- 問題解決方法論を適用した「成功事例」を学びたいと人々が望むと
き、彼らはしばしば、実装された具体的解決策で、現実のビジネスの文脈で成功した事例を見たいと望んでいることが多い。
- 創造的問題解決方法論の有効性あるいは価値は、その出力としての
解決策コンセプトに基づいて評価するべきである。その一方、問題解決の事例の有効性あるいは価値は、現実世界の文脈で実装された解決策に基づいて評価され
るのが自然である。
- 問題解決を成功させるためには、現実世界でのエキスパートたち
(例えば、技術者、知的財産関係者、ビジネスマネジャ、など) と、創造的問題解決の抽象化世界でのエキスパートたち (例えば、USITの専門家)
との協力が、現実世界のレベルだけでなく、方法論の [抽象化した] レベルにおいても、重要である。
- この点は、創造的問題解決の方法論を、他の何らかの方法論、特
に、問題定義を支援するための方法論 (例えば、QFD (品質機能展開)、マインドマッピング、など)、および解決策を実装するための方法論
(例えば、ロバスト設計 (品質工学)、CAD/CAM、ディジタルエンジニアリング、など) と、組み合わせて用いることをわれわれに促すものである。
5. USITに
よる問題解決の実際
5.1 USITトレーニングのための2日間セミナー
USIT
をマスターする/トレーニングするための最も効果的なやり方は、筆者が講師をしている2日間USITトレーニングセミナーである [9]。典型的には、組織者が企業内でのトレーニングセミナーを
準備し、解決すべき3件の実地の技術課題と15〜25人の参加者を見つける。扱う問題は実地の、未解決の、また解決することが大事なものであるべきであ
る。参加者として含めるべきは、その問題に責任を持つ技術者、その [問題の]
プロジェクトの中および周りの技術者たち、異なる背景素養をもつ人たち、知的財産に関わる人、そしてマネジャ、などである。TRIZ/USITにいくらか
の経験をもつメンバーが数人加わっていることは望ましいが、他のほとんどすべての参加者はUSITの初心者であってよい。
トレーニ
ングセミナーは図14に示すプログラムで実施する。TRIZとUSITについての入門の講義を2時間した後に、USITの手続きに従って
5セッションか
らなるグループ演習で3件の実地問題の解決を試みる。各セッションは3つのサブセッションで構成する。すなわち、そこでのプロセスに関する小講義、並行し
たグループ演習、そしてグループ発表と討論のための全体会である。
図14.
USITの2日間トレーニングセミナーのプログラム
トレーニン
グセミナーでは通常、それぞれの実地問題に対して3〜10件の新しい解決策コンセプトが得られる。各参加者はすべて、一つの問題をUSITで実際に解決し
た体験を得、またUSITを3つの異なるケースに適用するしかたを理解する。教科書問題でなく、実地問題を扱うことが重要なのは、参加者たちの動機を高め
るため、USITを用いて自分たち自身で考えて解決するという実地の経験をもつため、そして、講師が解決策を知らなかった問題について、方法論が彼らを助
けたのだということを理解するためである。
5.2 日本におけるUSITの推進と普及の事例
1999年以来、筆者はTRIZ/USITを日本で推進してきており、多数の
紹介記事や学会論文を書き、多数の講演や1日セミナーをし、そしてUSITの3日間または2日間トレーニングセミナーを合計17回実施してきた。
TRIZ/USITの日本での企業や学界における普及の現状は文献
[13]
(で報告した。つい最近、ある公開のTRIZ/USITセミナーにおいて、5社すなわち、日立製作所、JR東日本、富士写真
フイルム、日産自動車、および松下電工) が、TRIZおよびUSITの推進・適用の経験を発表している。
日産自動車では、知的財産部が筆者を招き、筆者が2002年3月に研究所の人
たちを対象にして3日間USITトレーニングセミナーを行い、さらに2003年2月にもさらに2日間トレーニングセミナーを行った。知的財産部が日産自動
車におけるTRIZ/USITの推進者であったことは [13]
で報告しているとおりである。その後2003年9月に日産自動車の技術部門の一つに筆者が招かれ、USIT
2日間トレーニングセミナーを行った。2005年2月に [上記の公開セミナーにおいて]、この技術部門の西村公男は (飯泉雅彦の代理として)
つぎのように発表している [18]。「われわれの技術
部門では、約200人いる技術者のうちの90%が、われわれ自身でやっているTRIZ/USITの半日セミナーを受けた。われわれの部門では
TRIZ/USITを日常的に使っており、特に、特許のアイデア出しのグループ会合において、アイデアの生成と解決策の強化のために使っている。[そのや
り方は、] 問題を定義して (Darrell Mann の問題定義ツールを使って)
から、関連する特許を検索し、ロードマップの形式にまとめる。そして約1ヶ月後に、プロジェクト全体の1日ワークショップを開き、ロードマップ上に問題の
焦点領域 (複数)
を決め、並行したグループ討論を行い、TRIZ/USITの解決策生成法を使って、それらの問題に対する解決策コンセプトを多数生成する。各解決策コンセ
プトは、特許提案に似た項目の簡潔な書式に書き出す。これらの結果として、われわれの部門は最近、従来よりもずっと多数の、良質の、より強い特許を創り出
している。」
松下電工 [19]
は以下のように発表した。「わが社では、2000〜2002年にTRIZとそのソフトウェアツールとを一つの研究所で導入したが、その後 [使用が]
中断した。2003年12月に中川教授を知的財産部の研修会に招き、TRIZ/USITの講演をしてもらった。そして、USITを試行することに決めた。
本社で技術管理を担当する3部門 (すなわち、知的財産部、技術管理部、R&D企画室)
が共同でUSIT推進チームを形成し、本社直轄の3研究所を対象にUSITトレーニングを組織することを始めた。2日間USITトレーニングセミナー
(講師: 中川教授) を、2004年3月〜2005年2月の間に合計
3回、研究所の人たちを主対象として開催した。典型的には、実地の問題それぞれに対して
5〜10件の解決策コンセプトが得られた。トレーニング直後での参加者たちの評価は表1にまとめたようである。これらの評価が良かったので、わが社では
USITをさらに実地使用に導入して行くこと検討している。社内講師を養成すること、USITの適用に適する問題のタイプや領域を見定めていくことが、今
後必要である。」
表1.
USIT2日間トレーニングセミナーに関する参加者の評価
時期 |
主対象分野 |
USITの理解度
(5点法) |
テーマへの有用性 (5点
法)
|
USITを他の人たちに勧めるか? (人
数割合)
|
2004年3月 |
機構系 |
3.8 点 |
3.1 点 |
71 %
|
2004年9月 |
システム系 |
3.4 点 |
3.0 点 |
69 %
|
2005年2月 |
材料系 |
3.5 点 |
2.6 点 |
64 %
|
5.3 USITの今後の開発と普及に対する要求
USIT
をさらに開発・普及させるために、以下の諸点が現在必要とされている。
- 実地適用事例を多数作り、事例研究として公表すること。
- 公募のUSITトレーニングセミナーを実施し、[新規に学習/導
入したいと考えている] 企業技術者や大学人などのボランティアをUSIT実践者として養成すること。
- USITをさまざまなタイプや分野の問題に適用する実際的な方法
を確立すること。
- USITの解決策生成法を適用した分かりやすい事例集をつくるこ
と。
- USITをTRIZの知識ベースソフトウェアツールと組み合わせ
て使う実際的な方法を明確にすること。
- 企業においてUSITを推進・適用する実践的な方法を開発して、
その方法を広く普及させること。
- USITのトレーニングだけでなく、USITでのコンサルティン
グができる能力と組織とを開発すること。
- USITを中小企業にも普及させ、創造的問題解決の成功事例を作
ること。
これらの要求の複数のものを同時に満
足するための鍵として、公募制のUSIT
トレーニングセミナーを2005年4月から開催しようとしている。そのような公募制のセミナーは、三菱総合研究所の主催で、2001年1月〜2002年9
月に5回開催した
[9]
が、その後2年半は開催できていない。その主要な理由は、自分自身の実地の問題を持ち込もうとする参加者を得ることに困難があったからであ
る。文献
[9]
に報告しているような、1年間の守秘義務を誓約するというやり方が、大企業にとってはまだリスクが大きいと考えられたようである。いまわれわれが開催しよ
うとしている公募制のトレーニングセミナーでは、同様の
[ただし守秘義務期間を2年間に延長して] 守秘義務誓約を行い、実地の問題を持ち込む技術者たち (主として中小企業から)
と、問題を持ち込まないでUSITをマスターしたいという技術者たち
(主として大企業から) とを [区分して] 募集しようとしている。
6. おわりに
USITにおける創造的問題解決の「全体構造」を、データフローの表現形式で
「6箱方式」としてつくり上げた。ユーザの具体的だがもやもやした問題 (a) を、まず、適切に定義されたユーザの問題 (b)
に変換し、現在のシステムと対応する理想のシステムとの理解 (c)
を得るために分析し、それから、解決策生成のUSITオペレータを使って新システム
のための新しいアイデアの断片 (d) を創り出し、さらに、解決策コンセプト (e) に組み立て、そして最終的に、ユーザの具体的な解決策 (f)
に実現する。
問題解決者は、USIT
手続きの全体を通して、論理的かつ創造的なやり方で導かれる。TRIZにおける複線並列構造の困難さ、また、(強制)
類比思考の曖昧さが、ともに消去されている。TRIZで開発された諸方法と諸知識ベースのすべてが、USITのこの新しい方式中に再編成され、統合され、
簡単化されている。USITの「6箱方式」は創造的問題解決にパラダイムシフトを促すものである。USITの有効性と容易さは近年の日本企業での実践にお
いて実証されてきている。
参考文献
[1] Darrell Mann: "Hands-On
Systematic
Innovation", CREAX Press, Ieper, Belgium, 2002; 中川 徹監訳、知識創造研究グループ訳:
『TRIZ 実践と効用
(1) 体系的技術革新』、創造開発イニシアチブ刊、東京、2004年。[同出版案内と資料: 『TRIZホームページ』, 2004年6月 (和・英
)]
[2] 中川 徹:
「TRIZにおける解決策生成のためのUSITオペレータ: 問題解決のより明確な道案内」, ETRIA国際会議"TRIZ
Future 2004", フィレンツェ, イタリア, 2004年11月5-7日; 『TRIZホームページ』, 2004年10月 (和), 2004年11月 (英); TRIZ Journal,
2005年3月 (英)
[3] Genrich
Altshuller: "Creativity as an Exact Science", Gordon &Breach,
1984 (E).
[4] Genrich S. Altshuller:
"The Innovation Algorithm", Technical Innovation Center, Worchester,
MA, USA (1999) (E); ゲンリッヒ・アルトシュラー原著: 『超発明術TRIZシリーズ1. 入門編「原理と概念に見る全体像」』,
日経BP刊, 1997年11月。
[5]
Boris Zlotin and Alla Zusman: "Tools of Classical TRIZ",
Ideation
International Inc., Southfield, MI, USA, (1999) (E); 産能大学TRIZ企画室監訳:
『超発明術TRIZシリーズ6、
理論編「クラシカルTRIZの技法」』、日経BP社刊、2000年 9月。
[6]
Yuri Salamatov: "TRIZ: The Right Solution at the Right Time",
Insytec, 1999 (E); 中川 徹監訳、三菱総研訳: 『超"発明術TRIZシリーズ5:
思想編「創造的問題解決の極意」』、日経BP社刊、2000年11月。[同出版案内と資料:
『TRIZホームページ』、2000年11月 (和
・ 英 )]
[7] Ed. N. Sickafus:
"Unified Structured Inventive Thinking: How to Invent", NTELLECK,
Grosse Ile, MI, USA (1997).
[8]
Ed Sickafus: "Unified Structured Inventive Thinking:
An Overview", eBook, URL:
http://www.u-sit.net/; 川面恵司・越水重臣・中川 徹 訳: 『USIT の概要 (統合的構造化発明思考法): USIT
eBook』、『TRIZホームページ』、2004年10月。
[9]
中川 徹: 「やさしいUSIT法を使ってTRIZのエッセンスを教え・適用した経験」、TRIZCON2002:
第4回Altshuller Institute
TRIZ国際会議、2002年 4月28-30日、セントルイス、ミズーリ州、米国; 『TRIZホームページ』、2002年 1月 (和)、5
月 (英)。
[10]
中川 徹、古謝秀明、三原祐治: 「TRIZの解決策生成諸技法を整理してUSITの5解法に単純化する」、ETRIA国際会議、TRIZ
Future 2002、ストラスブール、フランス、2002年11月6-8日;
『TRIZホームページ』、2002年9月 (和)、11月(英)。
[11]
中川 徹、古謝秀明、三原祐治: 「USIT解決策生成法の使い方 --
TRIZを簡易化・統合化したシステム」、TRIZCON2003、フィラデルフィア、米国、2003年3月16-18日;
『TRIZホームページ』、2003年1月 (和)、
4月 (英) 。
[12] Toru
Nakagawa, 'USIT Approach in Japan for Simpler and Powerful Process of
Creative
Problem Solving in TRIZ', ETRIA World Conference "TRIZ Future 2003"
held at Aachen, Germany, on Nov.
12-14, 2003; TRIZ HP Japan, Dec. 2003 (E).
[13] 中川 徹:
「日本におけるTRIZ/USITの適用の実践」、TRIZCON2004、シアトル、米国、2004年4月25-27日;
『TRIZホームページ』、2004年5月 (英); 2004年8月 (和)。
[14]
Roni Horowitz: "From TRIZ to ASIT in 4
Steps", TRIZ Journal, Aug. 2000; 中川
徹訳: 「イスラエルのSIT法とその利用(1) TRIZからASITへの 4ステップ」, 『TRIZホームページ』, 2001年
9月。URL: http://www.start2think.com/ (E).
[15] Ed Sickafus: 'A
Rationale for Adopting SIT into a Corporate Training Program',
TRIZCON99,
Altshuller Institute 主催, Novi, MI, 米国, 1999年3月7-9日; 中川徹訳,
「SITを企業研修プログラムに採用した論拠」,『TRIZホームページ』, 1999年5月 (和)。
[16]
中川 徹、古謝秀明、三原祐治:
「USITの解決策生成技法−TRIZの解決策生成諸技法を整理してUSITの5解法に単純化した」、ETRIA国際会議発表論文付録、TRIZ
Future 2002、ストラスブール、フランス、2002年11月6-8日; 『TRIZホームページ』、2002年9月 (和) 、11月 (英) 。
[17] Victor Fey: 'Why Does
TRIZ Fly But Not Soar?', presented
at ETRIA TRIZ Future 2004 Conference, held at Florence, Italy, on Nov.
3-5,
2004 (E).
[18] TRIZ/USIT 西村公男:
「効率的な特許網の形成」、技術情報協会主催、技術革新の技法の企業導入実践セミナー、東京・品川、2005年2月24-25日。
[19] 辻公志、橋爪二郎:
「松下電工におけるUSITの導入と今後の展開」、技術情報協会主催、技術革新の技法
TRIZ/USITの企業導入実践セミナー、東京・品川、2005年2月24-25日; 『TRIZホームページ』、2005年3月 (和)。
注:
『TRIZホームページ』, 中川 徹編集: URL:
http://www.osaka-gu.ac.jp/php/nakagawa/TRIZ/
(和文)
http://www.
osaka-gu.ac.jp/php/nakagawa/TRIZ/eTRIZ/ (英文)。
最終更新日 : 2005. 6.16
連絡先: 中川 徹 nakagawa@utc.osaka-gu.ac.jp