編集ノート
(中川,
2001年 3月10日, 補足 3月21日)
別掲[1] のように, Ed Sickafus 博士のUSIT教科書[2] の一つの例題を翻訳・掲載でき, USITの諸方法の原著者による説明を紹介できたのは幸いである。ところが, 方法の細部で今までの説明と異なる部分があり, 戸惑われる読者もあるかと思う。この違いの大きな理由は, USITの方法論自身が改良・発展しているからである。本ぺージでは, この発展の状況を簡単に説明して, 読者が細部の違いにとらわれずに, USIT法の本質を学ばれるようにしたい。
USITの成立と変化について,
本ホームページの読者に理解いただきたいのは, つぎの各段階である。
(0) AltshullerのTRIZ
(特に 1970年代)
(1) イスラエルのSIT法
(1980年代に成立。論文は Horowitz & Maimon (1997))
(2) フォード社Sickafus
のUSIT法 (1995年開始, 教科書 1997年)
(3) フォード社Sickafus
のUSIT法の改良形 (1999年 3月 USITセミナー (中川参加))
(4) 中川によるUSIT法の説明
(1999年3月以降)
イスラエルのSIT法については, 本ホームページに翻訳掲載した Horowitz & Maimonの論文 [3] を参照されたい。
フォード社SickafusによるUSIT法については, その成立経過[4] と活動状況[5] が学会で発表されているが, 方法自身の紹介は1997年出版のUSIT教科書[2] だけであった。今回別掲した例題[1] がこの教科書での方法を例示したものであり, Particles法以外のほとんどの要素に言及している。イスラエルのSIT法からこのUSIT教科書が成立するまでの過程について記載した部分を, USIT教科書から翻訳して本ぺージ (A)に掲載した。
ついで, 本ページ(B)に解説するのは, 1999年3月のUSITセミナー[6] の段階でのSickafusによるUSITの改良形である。USIT教科書の成立後のSickafusによる改良点を説明する。
さらに, 本ぺージ(C)は, 1999年 3月のセミナーにおける中川とSickafusの討論[6], およびその後の中川によるUSITの紹介[7] において改良した点について述べる。USIT自身のいろいろな進化が, 分かりやすく, 適用しやすい方向への努力であることを理解して, 読者自身で消化吸収して頂ければ幸いである。
[補足: 3月23日]
本ページを掲載するに至った経過は, 別掲
[1] の編集者まえがきに記したとおりである。3月11日にSickafus博士から翻訳掲載の許可の返事があったと同時に,
本ページ(B)(C)の中川の解説に対する補足のコメントを頂いた。開発者自身が各方法に対して考えている点が一層明確になったので,
本ページ(B)(C)の対応箇所に補足として訳出・掲載した。Sickafus博士のご厚意に重ねて感謝する。
本ページの先頭 | A. イスラエルのSITからフォードのUSITへ | B. USIT教科書からUSITセミナー | C. 中川の紹介での改良 | English
page |
(A) イスラエルのSITから フォードのUSITへ
Ed
Sickafus, USIT 教科書 (1997年) , pp. 439-442. 本節の原題: "Motivation
for this book"。
訳: 中川 徹 (大阪学院大学), 2001年 3月10日。
私が, イスラエルで学んだ「体系的発明思考法 (Systematic Inventive Thinking, SIT)」についての実験を始めたとき, 私の目標は, SITをそのままの形でフォードの技術者たちに導入することができるかどうかを見分けることであった。もともとの方法論には, その弱点を凌ぐずっと多くの強みがあった。しかし, その中に, 私を困らせた, あるいは私が特に価値を見出せなかった手続きが二つばかりあった。
困った側面の一つは, 方法論について, ずっと広い能力 (包容力) をもっているのに, 発明を強調することであった。アカデミックなコースとしては, 発明に焦点をあてるのはすばらしい目標であり, また同時に受講者 (学生) を引きつけるはずの (そして実際ひきつけた) 目標である。 しかし, 発明に焦点をあてるのは, 方法論の能力 (包容力) を過小評価しており, また, 企業技術者に対しては非現実的なように, 私には思えた。方法論を過小評価しているという理由は, この方法論が, 発明的な解決策だけでなく, ルーチン的な解決策をも探すのにすぐに適用できるからである。企業技術者に対して非現実的な強調のしかただという理由は, 彼らの大多数にとって, 時々必要となる発明よりも, ルーチン的な解決策の方がはるかに重要だからである。
このような理由から, フォードのコースでは, 問題に対して, 発明的な解決策だけでなく, すべての解決策を見出すことを強調した。しかしながら, 発明的な解決策もまた必要とされている。いかにして発明するかを売り物にし, 教え, 学ぶことは, 問題に対してルーチン的な解決策を見つけることよりずっと, 興味深い。
このことから, 改良したコースは, 問題の特性を解明するアイデアとともに, [SITの] 閉世界法の概念をすべて残す必要があった。その結果は, なかなか良かった。すべての解決策をまず認識すべきであるということを受講者たちが理解したときに, 解決策コンセプトの地平を彼らが広げ始めていく様子は, 見ていて大変興味深いものであった。発見のプロセスの後で, 技術フィルターを適用し始めた段階で, 得られた解決策の中から良いものを残せばよいのである。
イスラエルのアプローチから方法論として変えたもう一つの側面は, [彼らの] 「戦略」 の使用についてであった。閉世界アルゴリズムまたはParticles法を適用して分析した後に, そして, 解決策生成技法を適用する前に, 彼らの方法では, 二つの解決戦略のうちの一つを選択することを要求している。彼らは 4種の解決策生成技法を使う。 [属性の] 次元の増大, [オブジェクトの] 多数化, [オブジェクトの] 分割, および [機能の] 統合である。そして彼らはこれを二つずつの対に分ける。二つの戦略のそれぞれに一対の解決策生成技法が属する。分析者が一つの解決戦略を決定した後で, その戦略に属している二つの解決策生成技法を使うのである。二つの戦略を使うことは, 閉世界における発明的解決策を見つけることを強調するのには適したアプローチである。しかし, 解決策空間の全体に興味があるような, より広い応用にとっては, [これらの戦略の区別は] 不必要である。
イスラエルの方法論の最も大きな長所は, 解決策生成技法を 4種に絞ったことである。これは, [SITの] 方法論をTRIZよりもはるかに適用しやすくしたいくつかの洞察の中の一つである。より適用しやすくなった理由は, TRIZにおける40以上の解決策生成技法を学ぶ必要がなくなったことである。
私は最初から, 「uniqueness」 [訳注: 空間・時間特性分析] が, 他のものに伍して, 解決策生成技法としての資格があると感じていた。自分自身が問題を分析するときに, 非常に信頼できる方法であった。しかしながら, uniquenessは, 問題の解決策生成技法というのではあまりなく, むしろ問題解決に向けた最初の組織化のステップである。それは, 解決策の好機を明らかにする観点を, もう一つ探索するのである。そのため, uniqueness を第一のステップとして, 他の解決策生成技法を適用する前に使用することを薦める。その他の解決策生成技法はどんな順序で使ってもよい。
もう一つ分かったのは, イスラエルの人たちも気がついていたことだが, [オブジェクトの] 多数化と [オブジェクトの] 分割が, 別の解決戦略に属しているのに, しばしば同じ解決策コンセプトを作り出すことである。解決戦略という考えをなくしたので, 多数化と分割とをグループにして一緒に教えることは簡単なことであった。ついで, イスラエルの用語「解決のトリック」を「解決の技法」に改めて, 私たちは, uniqueness [特性分析], [属性の] 次元の増大, 多数化/分割, および [機能の] 統合 の四つを教え始めたのである。
これがフォード社において過去2年半に渡って教えてきたプログラムの核心部である。初期のクラスで, 英語での印刷教材がなかったため, すぐに問題が発生した。SITについて何もなかったのである。構造化発明思考法のこの第一バージョンを用いてクラスを教え, 多数の工業的な問題を分析し始めたのにつれて, 教科書を書く基盤になる材料が豊富に存在することが明らかになってきた。私は, 余暇を使って, そのような本のためのアウトラインをつくり, 材料を書きはじめた。このプロセスを通じて, 方法論の論理に明白な抜け道や欠陥が沢山見つかった。この観察によって, 方法論を一つにまとめる基本的な理論が必要だということが分かってきた。
オブジェクトと [オブジェクト間の] 機能的なつながりの役割については, イスラエルの方法の中ですでによく確立されていた。しかしながら, 属性とオブジェクトと機能との基本的な性質が分かってきたのは, いくつもの非論理的な閉世界ダイアグラムと格闘して, どこに共通の [間違った] 筋道があるのかを思案した後からであった。これらの 3要素 [オブジェクト, 属性, 機能] の基礎的な性質が一旦明らかになると, SITのすべての部分を統合して, 論理的で, 学習可能で, 適用可能な一つのプロセスにすることができた。解決策生成技法が, お互いに, また, 三つの基本要素と, どのように関係しているのかが, いまや明らかになった。
属性, オブジェクト, 機能の三つの [基本] 要素に基づいて, 方法論を修正・追加し,
統合化された構造化発明思考法の方法論を形成した。このようにして得られた統合化SIT
[すなわち, USIT] は以下のような特徴をもっている。
(B) USIT教科書から USITセミナー(1999年3月)まで
解説: 中川 徹 2001年 3月10日; 補足: Ed Sickafus 2001年 3月11日 (中川訳)
1999年3月にSickafusが指導したUSITセミナーについては, 中川の参加報告[6] を本ホームページに掲載している。ただし, 報告の中の記述は, 中川の解釈・整理した形で示しており, ここには改めてSickafusの資料と講義に基づく形で説明しておく。
SickafusによるUSIT法の全体フローチャートは, (全体フローを横から縦に書き直して)
下図のようである。
USIT教科書からの主要な改良・変更点は下記のようであった。![]()
図B1. SickafusによるUSIT法のフローチャート
(a) 閉世界ダイアグラムで, オブジェクトと機能の図の下に, 各オブジェクトの考えられる属性を思いつくままにリストアップする。
[Sickafus博士のコメント (2001. 3.11):
私の経験では, 大抵の研修者はオブジェクトの概念を容易に習得し, 機能の概念もうまく習得するが, 属性の概念には困難を感じる。しかしながら, かれらの適応 (習得)はメタファとしてよりも, むしろ字義的である。USITの能力は, メタファを用いた分析と解決策生成技法の適用において, より優れたものになる。だから, USITインストラクタがすべきことは, 一般的な物理・化学・生物学および数学を活用して, 根本原因たちとその現象論的な解釈を通じて, USITが問題に対していかにありきたりでない観点を提供するかを, 示すことである。この手順の鍵は, 属性をうまく識別し, 利用することにある。
このような経験から, 私は現在, [問題中ですでに] 同定された機能や効果に関連するだろうような属性をリストアップすることを強調している。言い換えれば, [思いつくままにというよりも, 問題に] 関連する属性をリストーアップさせるのである。]
(b) 定性変化グラフで, 縦軸と横軸を選んで一つずつのグラフを書く代わりに, 右上がりと右下がりの二つの作り付けの図を使い, 縦軸には共通のもの一つを選んでから, 横軸部分には, 全オブジェクトの考えられる属性を左右に分類してリストアップする。この趣旨は, 属性をできるだけ多くリストアップすることである。グラフそのものは定性的な変化であり, 個別に描く必要がない。(なお, これらのグラフから技術的矛盾を導出する過程については, 簡単に言及されただけで, セミナー時間の範囲では省略された。)
[Sickafus博士のコメント (2001. 3.11):
私は二つのグラフを使うことを推奨する。ただし, (少数ではあるが) 一部の研修生たちは一つのグラフ [縦軸と横軸に属性をとったもの] を使うことを好むので, 両方のやり方を教えている。
二つの定性変化グラフ (すなわち, 二つの異なる望ましくない効果を示すグラフ) を, 技術的矛盾に関連づけることは, [セミナーで] 言及した。しかしながら, イスラエルで開発され, そして私のクラスで継続しているように, 技術的矛盾を導出することは試みない。それはTRIZの要求であり, SIT/USITの要求ではない。USITをもう一度TRIZの型にはめようと試みる多くの人たちが, この点で困難に出会っている。TRIZでは技術的矛盾を求めてから, 解決の技法として, それを矛盾しない二つの効果に分離する。SITとUSITでは, 解決のスピードを上げるため, この不必要なステップを取らない。USITを教えた私の経験では, 技術的矛盾を見いだし, 記述しようと試みる分析者たちは, ずいぶん時間をロスしている。つぎのステップは技術的矛盾を二つの効果に分離することだから, [技術的矛盾を導出することは] 時間の無駄になる。SIT/USITでは, これらの [分離した] 効果が二つの定性変化グラフなのである。スピードの問題だけでなく, 解決策を生成する効率と解決策の数の問題も存在する。USITのクラスでは, できるだけ沢山の望ましくない効果を見つけ出し, 矛盾については気にしないように, 強調している。ただし, もし矛盾が [先に] 見つかったなら, それらを創造的な思考の出発点に使えばよい。]
(c) OAF [オブジェクト-属性-機能] 宣言文および OAFダイアグラムについては, 3日間セミナーの範囲からは省略された。
(d) Uniqueness [空間・時間特性分析] においては, その問題の特徴を捉えた空間の座標および時間の座標を選んで, 特性をグラフの形で表現する。
[Sickafus博士のコメント (2001. 3.11):
問題状況について, 選択したオブジェクトを含む単純なスケッチを描くことに,
ある程度習熟してくると, それらのスケッチが空間の特性のプロットになっていることに気がつく。そうすると,
機能の時間的なプロットだけを描けばよいようになる。]
(C) 中川によるUSITの紹介における改良点
解説: 中川 徹 2001年 3月10日; 補足: Ed Sickafus 2001年 3月11日 (中川訳)
上記の1999年3月のUSITセミナーにおいて, USIT法のフローチャートを書き直し,
Dr. Sickafusと討論した[6]。中川が書いたフローチャートは, (いままでにくりかえし紹介したものであり)
以下のようである。
(a) Uniquness [空間・時間特性分析] は, 解決策生成技法ではなく, 分析技法と位置付けるのが適当であると中川は考える。その理由は, まず本来的にシステムの空間・時間の特性を捉えて表現することだからであり, 他の解決策生成技法とは違って, それらの前に一度行えばよいだけだから。(Sickafusは, この方法が多くの解決策を思いつかせてくれる点で, 分析と解決策生成の中間にあると解釈していた。)![]()
図C1. 中川よるUSIT法のフローチャート
[Sickafus博士のコメント (2001. 3.10):
私は, uniqueness [空間・時間特性分析] を, 問題の定義と分析が完了した後に使う方を好む。分析の思考から解決の思考への変化をもたらす。それは特に
[機能] 配分法の導入として効果的である。私はuniquenessの考察を解決策生成技法として強調している。それは,
問題解決にありきたりでない思考を導入すること, すなわち, 革新へのステップとするためである。]
(b) 全体のフローチャートを上図のように書き直し, フローチャートのより標準的な書き方に近づけた。
(c) OAF宣言文とOAFダイアグラムは, その属性の書き方が非常に難しいと思う。また, あまりにも厳密に考えようとしていて, 自由な思考を妨げるように思う。このため, この方法の解説・普及は試みない。
[Sickafus博士のコメント (2001. 3.10):
これらの方法が難しいことには同意する。しかし,
これらの方法は, 研修者たちに有用な属性を識別させ, それらの属性がなぜ有用なのかを理解させるきっかけとして,
私が見つけた中で最良のツールである。USITを深く知るようになれば (そしてそれにはそんなに沢山の練習を必要としないが),
属性の概念を使って考えることが容易になり, それを有効に適用できるようになる。そうなれば,
この分析ツール [OAF宣言文とOAFダイアグラム] を完全に省略することができる。]
(d) 解決策を一般化する方法を模式的に表して, その利用を推奨している。
(e) USITの用語の翻訳・紹介にあたっては, できるだけ分かりやすいように,
意味を適切に表現するように努力している。主要な例は以下のようである。
・ Closed-World Diagram, CW-Diagram:
閉世界ダイアグラム
・ Quatitative Change Graph, QC-Graph:
定性変化グラフ
・ Particles Method:
Particles 法 (まだ適切な訳ができない)
・ OA-tree:
(Particles法の) 行動性質ダイアグラム
・ Uniqueness:
空間・時間特性分析
・ Dimensionality:
属性次元法
・ Pluralization:
オブジェクト複数化法
・ Distribution:
機能配分法
・ Transduction:
機能連結法
(f) USITの 3日間研修セミナーのやり方について, Sickafusのセミナーをベースに改良試行している。
本ページの先頭 | A. イスラエルのSITからフォードのUSITへ | B. USIT教科書からUSITセミナー | C. 中川の紹介での改良 | English
page |
USIT例題 (Sickafus, 1997) | イスラエルSIT (Horowitzら) | USIT成立経過(Sickafus論文, 1999) | SickafusのUSITセミナー(1999.3) | USITの紹介 (中川, 2000) |
ホームページ | 新着情報 | TRIZ紹介 | 参考文献・関連文献 | リンク集 |
ニュース・活動 | ソフトウェアツール | 論文・技術報告集 | TRIZフォーラム | English
Home Page |
最終更新日
: 2001. 3.23 連絡先: 中川 徹 nakagawa@utc.osaka-gu.ac.jp