講義ノート: 創造的問題解決の方法論(8)
 問題の分析(1) 
 問題 (困ること) の「原因」をつきとめる 
  創造的問題解決の方法論
− 大阪学院大学情報学部 2年次「科学情報方法論」講義ノート (第8回講義)
  中川  徹 (大阪学院大学) , 2001年 11月29日
   [掲載: 2002. 6. 6]   [ 注: 固定ピッチのフォントで読んで下さい]
 English translation is not planned for a time being.
For going back to the English page, press: 

 
本連載のトップ 前回講義 本ページの先頭 0. システム (復習) 1. 問題分析のはじめに 2. 「問題(困ること)」が起こる原因は何か 3. 技術システムにおける原因分析の例 4. 原因-結果のネットワークによる表現とその利用法 次回講義(9)

 

講義「科学情報方法論」(情報学部2年次)  第8回  講義資料
                                                            2001年11月29日   中川  徹

  問題の分析(1)
      問題 (困ること) の「原因」をつきとめる
 

目標:   問題 (テーマ) の分析に当たって, まず何が「問題 (困ること)」なのかを明確にし, そして
        その「原因」をつきとめる。それには, 原因-結果の関係, メカニズムの理解が必要である。
 
 
前回: 「システム」とは:  構成要素とその関係, 階層性, 技術システム

目標: 「システム」という一般的な考え方を理解し, 構成要素間の関係と, システムの
         階層性を学ぶ。また特に「技術システム」の機能や完全性の法則を学ぶ。

 要点:「システム」 = 関連する部分たちの一群で, 一つの全体を形成して一緒に働くもの。

       大きくても小さくても, 物でも組織でも, 上記の性質をもっていれば「システム」である。

       システムは階層を成す。  ...← スーパーシステム ← システム → サブシステム → ... 

       ブラックボックスで表現した「システム」の機能:   入力 ==>  「 システム 」 ==> 出力

       技術システムの (内部の) 捉え方:  見るべき側面を明確にする。 特に機能面が大事。
         「技術システムの完全性の法則」   (道具・機械+人間で完全になる例あり)


 

0.  「システム」のイメージ (復習)

  「システム」とその階層性を表現するイメージとして, つぎのような図が描ける。


 

1.  問題の分析のはじめに: 何が「問題 (困ること)」 なのか?

  前回までの講義で, いろいろな情報を収集し, 「問題」を見つけて絞り込み,
       いろいろ試行しつつ「発想」することを学び,
       「システム」および「技術システム」という考え方を学んできた。

  今回から, 「問題」を「分析する」方法について考えよう。
       問題を「分析」するのは, 問題を解決するための重要な準備作業である。

  まずその手始めに, 何が 「問題 (困ること)」なのかを, はっきりさせねばならない。

    ところで, ここでいう「問題 (困ること)」は, 「問題 (テーマ, 課題)」 とは少し異なる。
      「問題」という言葉には, いろいろな意味があり, しばしば混乱する。

      「問題」 (広辞苑による):
        (1) 問いかけて答えさせる題。解答を要する問い。
        (2) 研究・議論して解決すべき事柄。
        (3) 争議の材料となる事件。面倒な事件。

      "Problem"   (Longman 英々辞典による):
        (1)  a difficulty that needs attention and thought
                (ひとつの困難なことで, 注目して考えることを要するもの)
        (2)  a question, esp. connected with numbers, facts, etc. , for which
                an answer is needed.
                (質問で, 特に数や事実に関連していて, 回答が必要なもの)

    この節でまず明確にしたいのは, 「困ること, 困難」という意味での「問題」である。
      課題としての「問題」が決まっても, 何が本当に「問題 (困ること)」かは自明でない。

  例:  「朝9時からの第1講時の授業では, 欠席者・遅刻者が多い。」
        この「問題」を取り上げよう。

     ここで, 何が「問題 (困ること)」 (注目して考えることを要する困難) なのか?
 

          [講義資料には数行の余白。学生たちに, 質問して答えさせる。]
 
 
 

      「問題 (困ること, 困難)」 はどのように考えを進めていけば明確になるのか?
         どのような観点を入れればよいのか?
 

          [講義資料には数行の余白。学生たちに, 質問して答えさせる。]
 
 
 

  同様の「問題 (テーマ, 課題)」はいっぱいある。

    ・ 受講カード: 「前回の授業に欠席したので, 今回の授業はよく分かりません」と書いてある。
    ・ 受講カード: 「今回の授業はよく分からなかったので, できたら次回復習して下さい」。

    ・ 欠席が多いゼミの学生を呼んで理由を聞くと,
        「コンビニでの夜勤のバイトを週3〜4日していますので...」と答えた。
         下宿生であるが, 授業料・アパート代+生活費7万円/月の仕送りがあるという。

    ・ 「一年生の必修の授業で, 約1割が試験に欠席し, 約1割が試験不合格であった。」
         (欠席が多い学生に不合格の率が高かった。)

    ・ 「ある学生は, 前期に登録した科目の約半分について単位履修に失敗した。」
 
 
 
 

  ある「問題 (テーマ, 課題)」 について, その「問題 (困ること, 困難)」を明確にするには,

    そのこと (ある一つの現象, 事実) が,
       どのような「結果」を生み出す (可能性) があるか を考える。

    「結果」は, (主として) 時間的に「後」 (将来) に起こる。

       「結果」が 「後 (将来)」でなく, もっと前に起こることもある。なぜなら,
           そのような「結果」を予測する人 (組織・機械) は,
             「今」 あるいは 「もっと事前に」 何らかの処置をしておこうとする。

    「結果」は, 当事者あるいは現在問題が起こっているもの (機械など) だけでなく,
       「システム」 (組織など) を作っている関連する部分 (人・機械など) にも作用する。
            「システム」の内部にある「関係」を通じて, 直接的に「作用」 (影響) が及ぶ。

      また, 「スーパーシステム」を通じて, 関連する他「システム」にも影響が及ぶ。

  結局, 「問題 (困ること, 困難)」を明確にするには,
      関係する「システム」 (サブシステム, スーパーシスム, 類似システムなどを含む)について
        それが作り出す「結果」・「影響」 を考えることが必要である。

      通常, 一つの事実に対して, その「結果」や「影響」は多岐に渡る。

    これらの「結果」「影響」を明確にするには,
       それらの結果を生じるメカニズム (「因果関係」) が分かっている必要がある。

      このメカニズムを 推測・予測すればよい場合と,
                     実証・論証しないといけない場合がある。

       このような「因果関係」は,
          必ず起こるのか?
          必ずでないとすれば, どの程度の割合で起こるのか?
          さらに, どういう場合に起こり, どういう場合には起こらないのか?

    これらの「結果」「影響」が分かったときに,
        それに対する「価値判断」が必要になる場合がある。

        社会的・人間的な問題では, 時としてこの「価値判断」が分かれる場合がある。
            「結果」や「影響」が多岐にわたり, 関係者によって受ける影響が違うから。

        技術的な問題では, この「価値判断」は比較的明確であろう。

 

2.  「問題 (困ること) 」が起こる原因は何なのか?

  「問題 (困ること)」 を解決しよう (無くそう) とするためには,
     それが起こる「原因」を考えることが大事である。

  例:  「君が, この「科学情報方法論」の講義に欠席・遅刻が多いのは何故か?」
 
 

          [講義資料には数行の余白。学生たちに, 質問して答えさせる。]
 
 
 
 
 
 
 
 

    通常「原因」 (として挙げられるもの) も多岐に渡る。

  「原因」を考えるときに, どのような観点 (考え方) が必要なのか?
 
 

          [講義資料には数行の余白。学生たちに, 質問して答えさせる。]
 
 
 
 
 
 

  「原因」として挙げる場合にも, そのメカニズム (「因果関係」) をはっきりさせる必要がある。






    この「因果関係」 についても, 前述と同様の検討が必要である。
      必ず起こるのか?
      必ずでないとすれば, どの程度の割合で起こるのか?
      さらに, どういう場合に起こり, どういう場合には起こらないのか?

 

3.  技術システムにおける原因分析の例

3.1  例: 「額縁掛けの問題」 [→ 原典]

  問題 (テーマ):  額縁が傾かない (傾きにくい) ような「額縁掛け (の方法)」 を作れ。

  原因検討: 現在のシステムでどんな場合に額縁が傾いてしまうのか?
       (a) 正しく掛けたはずなのに, 最初からすぐに傾いてしまう。  -- これがまず問題。
       (b) しばらく正しく掛かっていたが, 知らないうちに傾いた。  -- これも大事な問題。
       (c) 正しく掛かっていたが, 額縁にぶつかったら傾いた。  -- やむをえないことあり。

  傾く原因を調べる方法:

   (1) 傾いた「結果」を観察して, その観察から傾く「原因」を考える。

        ここで働く「因果関係」のメカニズムは, 大きくいえば, 「自然法則」だと分かっている。
          その「自然法則」の中の何が特に関係するのか。

          「物体は, エネルギー的に高い状態から, 低い状態に, 容易に移行する。」
          「物体が静止するのは, そこがエネルギー的に (局所的に) 最も低いからである。」
          「物体が静止しているときには, それに掛かっている力が釣り合っている。」
          「物体が静止しているときには, それに掛かっている回転力も釣り合っている。」
                ...

        これらのことを理解していて, 傾いた状態 「結果」を観察する。
           さらに, 「傾く前の状態」と「傾いた後の状態」を比較して, 観察する。
 
 





   (2) 「問題 (困ること) が起こる現場」を観察する方法

           額縁を掛けようとして手を離したらすぐに傾いた。
             そのときに何が起こっているのか?  額縁はどうなったか? ひもはどうなったか?

           正しく掛かっていた額縁が, しばらくした傾いた。
             その直前に何が起こったのか?
               風が吹いた。
               トラックが通って, 部屋が揺れた。
               子供が壁にぶつかった。

    (3) 「問題 (困ること) 」をわざと起こしてみる。  (「実験する」)

           どんな額縁だと傾くのか, いろいろ試す。
           額縁のひもの位置関係をいろいろ変えて, 実験してみる。
           手を離すときに, 額縁を壁につけてから手を離すようにする。

      これらのことをやって, 物理学 (理科) の知識があると, 正しい「原因」にたどり着く。
         物理学の知識は, この「原因」と「メカニズム」を明確に説明するのに役立つ。
            (その知識がなくて 「常識」だけだと, 説明があいまいで正確にならない。)

 

3.2  例:  「発泡樹脂シートの製造における発泡倍率の増大の問題」 [→ 原典]

  問題 (困ること): 十分な気体を使っているのに, 発泡倍率が小さく, 十分膨らまない。





    この例での「原因」の記述は,
        「結果」の (比較的マクロな) 観察
        「問題が起こる現場」のマクロな観察
      に基づいている。

    この例では, 「ミクロな観察」は記述されていない。

       表面や断面の詳しい観察, 特に, 電子顕微鏡を使った観察など。
       「問題が起こる現場」のミクロな観察はできていない。
          泡がどのようにできて, どのように大きくなり, どのように固まっていくのかなど。
          溶融樹脂や吹き出した樹脂シートの温度, 圧力などは記述されていない。
       また, さらに細部の「分子レベルの観察」は記述されていない。

    これらが記述されていないのは,
        この筆者 (中川) がこの問題の直接の担当者でなく,
        必ずしもこの問題の専門家でないからである。

   このように, この原因分析はやや「現象的」であるが,
      以後の分析でそれなりにきちんとした分析が行われ, 問題解決の指針が得られた。

 

3.3  例: 「トラックの燃料タンクが回転する問題」

  問題 (困ること): 下図のようにトラック車台の下に横抱きにした燃料タンクが,
                  走行中の振動により徐々に (どちらかに) 回転し, 燃料パイプが壊れる。
      [出典:  D. W. Clarke and B. Zlotin, TRIZCON2001, May 2001]

    (注: この問題は米国のトラックメーカーにとって20年来の懸案だったという。)

    原因の分析:  下記の「原因-結果のネットワークによる表現」で分析した。  (次節参照)

 

4.  原因-結果のネットワークによる表現とその利用法

  原因-結果の関係 (そして, 「根本原因」) は, しばしば非常に複雑なことがある。
    ビジネスの問題, 人間や社会に関係する問題では, とくに曖昧で複雑になる。
    技術問題でも必ずしも自明なわけでない。

  そこで, 原因-結果の関係を「ネットワーク図」の形で表現するとよいことがある。

  Ideation International 社による表現形式 とその利用法を以下に説明する。

    この方法の特長は, 原因-結果の関係をネットワーク型の図で表現するに当たって,
      起こる事象 (ことがら) が有益か有害かを判断して, 分類表記すること。





  適用
  この図法の長所は, 原因-結果のネットワークの中で,
     「どこの原因をなくせば問題が解決する可能性があるか」を, 簡単に示せることである。

    解決するための「観点」 (すなわち攻略するとよい所) を, この図から規則的に出せる。
      Ideation International社は, 実際に次のルールで, 「観点」を自動抽出するソフトを作った。

    具体的に, 上記の燃料タンクの例で, 多数の「問題解決の観点」を自動抽出し,
        それらに対する多数の解決策を生成し, 学会で報告している。 (2001年)

    しかし, この発表に対する中川の所感は以下のようである。
        (出典:  「TRIZCON2001: Altshuller Institute第3回TRIZ国際会議 参加報告」,
                  中川  徹, 『TRIZホームページ』, 2001年5月)
 

小生はこの発表を聞き, 論文を読み返して, 何かすっきりしないと感じる。一つは, 原因結
果の関係がネットワークで書かれ, いくつかの図でメカニズムが考察されているけれども,
メカニズムの捉え方が本質的でないのでないかと感じる。それに対応して, 解決案が核心を
ついていないのでないかと思う。

この事例に対して,小生が考えた解決案の方針は以下のようである。

(a) 摩擦を大きくしても振動による衝撃で瞬間的に摩擦力が弱まり, 回転力が働くのは避け
    られないものとして方針を立てる。

(b) 現在は, 摩擦がなくなったときに, 円筒形タンクの角度を指定する要因がない (円筒を
    周りから抱きしめているだけ)。そこで, 角度を積極的に指定する, また, その角度に
    安定化させることを考える。

(c) 具体的には, タンクの適当な所に2本のゴムベルトを固定し, 設定角度から (正・逆ど
    ちらにでも) 回転しようとすると元に戻る力が働くようにする。-- 小生はこれで問題
    がより簡単に解決すると思う。
 
 

  このように, 問題の「原因」を明確にすることは非常に大事なことであり,
     その「原因」の捉え方で, 問題解決の努力の全体が変わってしまう。
 
 
 
本連載のトップ 前回講義 本ページの先頭 0. システム (復習) 1. 問題分析のはじめに 2. 「問題(困ること)」が起こる原因は何か 3. 技術システムにおける原因分析の例 4. 原因-結果のネットワークによる表現とその利用法 次回講義(9)

 
講義ノートトップ 1. 導入: 経験と原理 2. レポートの書き方 3. 情報収集(1) 書誌情報 4. 情報収集(2) インタネット 5. 問題を見つけて絞り込む 6. 発想とは
7. システムとは 8. 問題分析(1) 困ることの原因 9. 問題分析 (2) 機能・属性分析 10. 問題分析(3) 空間時間特性と理想解 11. 解決策生成(1) 知識ベース 12. 解決策生成 (2) ブレークスルー 13. 解決策生成(3) 解決策の体系化

 
総合目次  新着情報 TRIZ紹介 参考文献・関連文献 リンク集 ニュース・活動 ソフトツール 論文・技術報告集 フォーラム Generla Index 
ホームページ 新着情報 TRIZ紹介 参考文献・関連文献 リンク集 ニュース・活動 ソフトツール 論文・技術報告集 フォーラム Home Page

最終更新日 : 2002. 7.15   連絡先: 中川 徹  nakagawa@utc.osaka-gu.ac.jp