講義ノート: 創造的問題解決の方法論(5)
 問題を見つけて絞り込む
  創造的問題解決の方法論
− 大阪学院大学情報学部 2年次「科学情報方法論」講義ノート (第5回講義)
  中川  徹 (大阪学院大学) , 2001年 11月 1日
   [掲載: 2002. 3.28]   [ 注: 固定ピッチのフォントで読んで下さい]
 English translation is not planned for a time being.
For going back to the English page, press: 

 
本連載のトップ 前回講義 本ページの先頭 1. はじめに 2. 人生の大事な問題の捉え方 3. 問題を捉える一つのヒント 4. 技術における問題の例 5. 問題を捉える諸観点 6. 問題の設定のしかた 7. 問題の明確化のプロセス (ＵＳＩＴの問題定義段階) 次回講義(6)

 
 

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

  問題を見つけて絞り込む

目標:  問題解決のためには, 何よりもまず, 「問題」に気がつき, 見つけて, 絞り込むこと
        が大事である。そのための意識と方法について学ぶ。
 
 
前回:  情報の収集 (その2: インタネットを利用した情報の収集)

   目標:  インタネットを利用した情報の収集が非常に便利で強力であることを学び,
          情報検索のしかた, 重要な情報の所在, 情報検索技術の進歩を学ぶ。

 要点:  インタネットによる情報検索の主要技術として, WWWのしくみを学ぶ。
          ファイル記述形式HTML, 所在表記URL, ハイパーリンク, WWWサーバ,
          WWWブラウザ

        検索エンジンを用いたキーワード検索の諸方法と注意点。

        本講義用のリンク集を例示し, 自分用のリンク集を作ることを奨めた。 

 

1.  はじめに:

  講義の最初に話したように, この講義の成績評価は「レポート」の提出による。
    そのテーマは, 「本講義に関連する項目について, 自分で選ぶ」。

      注: 「本講義に関連する」というのは, 広く考えてよい。

    レポートの予備提出の締切りは12月3日です。

       「アウトライン」2頁程度
           テーマ名, 目的・意義, 内容の要点 (ポイント), 主要参考文献  を書くこと。

  質問: テーマの選択の目処はついてきましたか?
          どんな分野のどんなことを考えますか?
          いままで, その問題についてどんなことを学び/考えてきましたか?
 
 

  「テーマ」を見つけるのは苦しいものです。
      (今回の講義で説明する) 「解決すべき問題」を見つけるのが難しいのと同じです。

    「テーマを自分で見つける」ことは,
        「与えられたテーマでレポートを書く」ことよりも, 大事で, 難しいことです。

  テーマを見つけるには, 「問題意識」が必要です。

    人間は, 何か困ったこと, 必要に迫られないと, 突っ込んで考えません。
      目の前にノルマがあり, 締切りがあり, 具体的問題があって,
                はじめて真剣に考える。

      しかし, 同時に将来のことも見据えて考えておかないといけない。

         (日本の完全失業率がいま5.3%に上がった。経済不況と就職難がまだ続く。)
         (パソコンを「使える」のは当たり前で, それ以上の技術・素養が求められる。)

    テーマ (「問題」)を見つけるには, 切羽詰まった気持ちがどうしても必要である。
        いろんな問題が山積していても, 見る気がなければ見えない。
            自分の問題として解こうとはしない。

2. 「人生の大事な問題」についての捉え方

  ここで, 中川が総合科目(1)で講義したことの一部を要約しておく。

    [この講義資料は, 1年次の「情報科学序論」の講義の最終回に全員に配布した。]

  中川  徹: 「創造的な問題解決の思考法 -- 大学生活で何をしようとするのか?」
    『ＴＲＩＺホームページ』, 2001.6.19 掲載 http://www.osaka-gu.ac.jp/php/nakagawa/TRIZ/

  人生の大事な問題 (人生や仕事の上での岐路になるような問題) の考え方:
 

3.  問題をとらえる

  (1) 何が問題なのかを, 意識することが最初。
  (2) 問題の範囲を大まかに考えてみる。
  (3) 関連した情報を集める。
  (4) 問題の設定を考える。
          問題を階層的な「システム」として捉え, 問題の範囲を明確にする。

  (5) 問題の本質 (問題の中心の課題とその「性格」)を考える。
        問題の「性格」:
          (a) いま何らかの原因で, 悪い状況・困難・障壁があるのか?
          (b) 周りの状況がよく把握できていないことが問題なのか?
          (c) なんらかの明確な選択を迫られているのか?
          (d) 広く緩い選択枝の中で方向・目標を設定することが必要なのか?
       「問題の性格」に応じて, 問題解決の思考の過程も変わる。

4.  問題を解く意欲と動機をもつ

  問題を解くには，「解くための技術や方法」よりも前に, 「心」の準備の方が大事。
      問題に対処し解決していく意欲と動機を持たねばならない。
        (「心」の持ち方と鍛練は「教室外での体験」を通して，身に付けるべきこと。)

  (1) 自分の可能性を信じる。
  (2) 自分を客観的に見る。良さと悪さの両方の面を見る。
         「思い詰める」のでなく, 自分の心の緊張を解き, 気持ちを静める。
  (3) 感動する心。  (感動が自分の将来を決める原動力になる。)
  (4) きっかけ・動機をつかんで集中する。偶然をきっかけに変える。
  (5) 視野を広く持ち, 柔軟に考える。基本的な姿勢・予備知識・日頃の心がけ。
  (6) 感情に関わる問題・問題点はデリケートだが, やはり乗り越えるべきこと。
        自分自身の感情に関わること; 関係する他者の感情に関わること。
  (7) 人に話すこと, 人の話を聴くこと。
  (8) 問題を考える段階でも積み重ねが必要。
        背景の理解, 解決の種々の方法の理解など。
  (9) 転んでも, また起きる。
  (10) 人生の目標 (ゴール) は一つではない。
 

  以上の記述は, 「人生の大事な問題」を想定しており,
     「技術的な問題」よりもずっと包括的で, 自分の「心」の問題の比重が大きい。

 

3.  問題を捉えるための一つのヒント

  下記のテレビ番組を推薦する。

  NHK総合テレビ 『プロジェクトX  挑戦者たち』
     毎週火曜 夜 21:15 - 22:00  (再放送: 毎週木曜 深夜 24:15 - 25:00)  [2000年3月〜]
     ビデオあり  図書館 (NHKビデオ 第1〜10巻); 教務課 (学内収録分 本年6月以降)
     本あり  図書館 (第1巻〜第8巻まで。約48週分)
     http://www.nhk.or.jp/projectx/

  例: 「窓際族が世界規格を作った〜VHS・執念の逆転劇」(ビデオNo.1, 本第1巻第2話)
     「ガンを探し出せ〜完全国産・胃カメラ開発」 (ビデオNo.4, 本第1巻第4話)

    今週: 「謎（なぞ）のマスク  三億円犯人を追え〜鑑識課指紋係・執念の大捜査」

  この番組は, 戦後の日本の技術・社会を発展させた大きなできごと (プロジェクト)の
      背後にある情熱 (「執念」, 挑戦する心) とその苦闘と喜びを伝えてくれる。
      「有名人」ではない技術者・庶民とそのリーダたちの生き方が感動的。

    どのようにして「問題」を捉え, その困難を解決していったかが分かる。

4.  技術の世界で問題を捉えた種々の事例

  以下に, 大小さまざまな問題の事例を簡単に述べる。(今後例題として話す予定のもの)

  (1) 額縁掛けの問題

        額縁掛けのキット (額縁上の二つのフック, 一本のひも, 一本の釘) を改良して,
          傾かないで安定に掛けることができる方法を作れ。

  (2) トラックの燃料タンクの保持法の問題

        大型トラックの円筒形の燃料タンクを車台下に横抱きにベルトで固定している。
        トラックの振動でこのタンクが少しずつ回転するケースがあり, 注入口を壊す。
        タンクが回転しないような固定法を作れ。

  (3) 発泡シートの製造における発泡倍率の増大の問題

       溶融したポリマーに高圧でガスを溶かし, これを細いスリットから吹き出させて引
         っ張って, 発泡シートを作る。このとき, ガスを高効率でシートに残し, 発泡倍率
         を向上させよ。

  (4) 動画像の著作権表示の問題

       ディジタル動画像 (映画など) に著作権表示を入れる適切な方法を見いだせ。
       著作権表示は, 邪魔にならず, それでいて明確に権利を主張できなければならない。

  (5) 高層ビルの避難階段の設計の問題

        高層ビルでの火事になると, エレベータが止まり, 階段に煙や火が入ると煙突状
        になって避難できなくなることがある。安全に避難できる階段の設計を考えよ。

  (6) 業務用のVTRをベースにして, 家庭用のVTRを開発せよ。

        大規模で高価なVTRの装置を大幅に小型化・安価にして, 家庭用に消費者が買え
        るものを作れ。高い画質を持ち, 十分長時間録画できるものにせよ。

  (7) ソフトウェアの品質向上のための開発方法の問題 (その1)

        プログラミングにおいては, 常にバグの問題が存在し, 規模が大きくなると急激
        に品質確保が難しくなる。既存の信頼できる部分と新規開発の要テスト部分とを
        分離して, 品質の確保を確実にする開発方法 (ソフトウェアの構造) を考えよ。

  (8) ソフトウェアの品質向上のための開発方法の問題 (その2)

        ソフトウェアの開発において, 内部機能はあまり変わらないのに対して, ユーザ
        インタフェースの部分がカストマイズ・拡張により変化することが多い。ユーザ
        インタフェースの変更が内部機能のソフトウェアに影響を与えないようなソフト
        ウェアの開発方法 (ソフトウェアの構造) を考えよ。

  (9) ソフトウェア開発におけるプロトタイプの問題

         大規模ソフトウェアを開発するときに, ユーザ (すなわちソフトの発注者) 自身
         もその要求仕様 (どんなものを作ればよいのかということ) を明確に分からない
         ことが多く, ほぼ出来上がってからはじめて問題箇所がわかり, 改造する必要が
         出ることが多い。これを防ぐには, 初期に使い勝手が分かる工夫が必要である。
         そのためにプロトタイプ (「模型」)を作って, テストするしくみを作れ。

  (10) 情報の共有化の問題

        いろいろな情報を (相互に流通させて) 共有できれば, 知的生産の活動にも社会的
        な活動にも非常に有効である。そのためのしくみを考えよ。

  (11) ソフトウェア開発のパターンの共有化

         ソフトウェアの開発には, 設計のレベルから, アルゴリズムやプログラミングの
         レベルまで, いろいろなレベルで先人が作った優れた方法があり, それらを模範
         (モデル, パターン) として収集・蓄積・洗練・共有できれば, 有効である。その
         ための方法を考えよ。

  以上の事例は, 最近あるいは歴史的に, 考えられたものであり,
    それぞれの問題設定により, いろいろな技術に発展した/するものである。

　　　[注: ここの(7)〜(11)の諸問題は, ソフトウェア工学に関連するものであり, 情報学部
           の学生諸君と一緒に考えるとよいテーマであると思い列挙したが, これ以後の講義
           において説明・展開するに至らなかった。2002年 4月からのソフトウェア工学の講義
           の中で改めてとりあげて行きたい。  (2002. 3. 3) ]


 

5.  問題を適切に捉えるための諸観点

  まず第一は, 「必要性」:

      どうにも困っている「問題」(害悪, 欠点・難点, 障壁, 不便, 不可能など) がある。

  第二に,「解決すれば得られる利益」が大きいこと。

      それが解決すれば, ユーザが利益を受ける (害がなくなる, 便利になるなど)。
                       メーカとして利益を得る (安価に作れる, 短納期, 競争優位など)
                       社会的に利益が大きい。

  第三に, 社会的ニーズ (需要) があること。

      この問題の解決が, 個人や少数者の問題だけでなく, 社会的な広い需要があること。

  そして (あるいはまず最初に), 問題を解決しようという「情熱」 (挑戦する心)。

  以下は, オプショナル。 (必ずしも十分備わってなくても, 目処が立ってなくてもよい)

    ・ 当事者であること:  自分たちこそその問題を解決するべき立場にある(との自覚)。
    ・ 時宜にあっていること:  長年の懸案, 現下の急務, 将来のための基盤など。
    ・ 技術的基盤があること:  技術的な蓄積, 技術的な設備, 技術の芽など。
    ・ 経済的基盤があること:  問題を解決するまでの開発費, 生活費
    ・ 人材的基盤があること:  リーダ, 協力者, いろいろな素養・能力をもった人々。
    ・ 問題解決の方向性と目処があること。

    これらがオプショナルだという意味は,

        本当に偉大な技術開発 (例えば, 『プロジェクトX』の諸事例)では,
        これらのいくつもの点でハンディを持っていた人々が成功していることである。
            ハンディを克服するところにこそ本当の情熱が生まれるとも言える。

  大事な (意義のある) 「問題を見つける」ことは,
      解決できそうな問題を見つけて, それを解決していくよりも, ずっと大事である。

6.  問題の設定のしかた

  問題は多くの場合に, 最初から適切な形で設定されているわけでない。
     (問題が持ち込まれる場合も, 自分で見つける/考える場合でも)

  例: 「高層ビルの避難階段の設計の問題」の場合:
        出典:  中川  徹: TRIZCON2001発表。http://www.osaka-gu.ac.jp/php/nakagawa/TRIZ/
 

中川は, ＴＲＩＺの教科書を英語から翻訳していて,
つぎの演習問題に出会った。(要約) 

『演習43:  高層ビルの火災での救命技術が必要である。
  階段やエレベータは   巨大な煙突となり使えない。
  はしご車も12階までしか届かず,
  ヘリコプタもあてにできない。
  緊急避難の簡単で確実な方法が必要。
  Vilchinskyが「重力エレベータ」を発明した。
    (ゴムのチェンバーに人が乗ると,
     空気圧を溜めて, ゆっくり下りる。)
  これをさらに改良してほしい。』

この図の方法は分かりにくくて, うまく働きそうにない。
    もっと根本的に考え直す必要があると思った。

そこで, (頭の中で) つぎのような図 (問題ツリー図) を作った。

  高層建築が増えている。(20階〜100階など)
  → 火災対策が必要
     → 避難および救命対策を取り上げる
        → 通常の手段を用いた避難
            → エレベータによる避難       × 煙突になるからだめ
            → 階段による避難             × 煙突になるからだめ
        → 消防による救出活動
           → はしご車による救出          △ 12階までしか使えない
           → 救助隊による救出 (ロープ, はしご, ヘリコプターなど)
                                          △ あまり期待できない。
           →  窓からの救出活動
        → 緊急避難の手段
           → 救命チューブによる緊急避難    × 誰にでもは使えない。
           → ビルチンスキーの重力エレベータによる緊急避難  × 改良の余地多い。
              → 新しい緊急避難方法の提案

この図のような論理で, 演習問題は「新しい緊急避難の方法」を求めている。
    しかし, 中川はそれを本質的であるとは思えず, つぎのように考えた。

    この問題の最初に戻って,考え直す必要がある。
    火災の早い段階で避難でき, 救助できることが一番大事だろう。
    通常の手段を用いた避難をベースにして何か良い方法を見つけるべきだ。
        実際的で広く使えるものでなければならない。
    「火事のとき、階段やエレベータは煙突になるからだめだ」 と言っているが,
    どうしても煙突になるのだろうか? 防ぐ方法はないだろうか? .

この結果, つぎのような問題設定にした。
  問題設定:  「火災時に安全に避難できるような階段を設計する。
                 特に，煙突状態にならないようにする。」


  この例での中川の思考過程・問題解決過程は, 上記論文に詳細に発表した。

  問題設定で考えたこと:

    問題自身を「問題システム」としてみる。
      大きな問題からその細部の小さな問題まで階層的に関連させて考える。
      また各問題に対する今までの解決策とその課題を考える。

      このうちのどのレベル, どのブランチをとりあげるべきかを考える。
         それぞれの問題の意義を 上記5節の諸観点から検討している。

 

7.  問題の明確化のプロセス (ＵＳＩＴ法の問題定義段階)

  ＵＳＩＴ法 (Unified Structured Inventive Thinking, 統合的構造化発明思考法) は,
    1995年に 米国Ford社のEd Sickafusが開発した問題解決の思考プロセスである。

    ロシアのＴＲＩＺ(「発明問題解決の理論」) の影響を受け, その簡易版として作られた。

  ＵＳＩＴは, 技術的な問題を取り上げ, それを分析し, 解決策の諸案を考え出すための
      一貫した思考プロセスである。
        問題定義, 問題分析, 解決策生成の3段階からなる。

    通常, グループで問題解決を図る。
        ＵＳＩＴ法をマスターしている1〜2名と,
        ＋ 解決したい技術問題に関わる技術者 数名 (技術背景が異なる人たちが良い)

  ＵＳＩＴでの最初の段階は, 「問題定義段階」。

    問題を持ち込んだ技術者が, その問題と背景についてグループメンバに説明し,
      グループで質疑, 討論を行って, 以下の項目を簡潔に書き出す。

    (a) 問題定義文:  解くべき問題を 1-2 行の文で定義する。目標, 課題, 制約状況など
    (b) 図解:       問題状況を理解するための簡明な概念図
    (c) 根本原因:   問題を生じている根本の原因 (と考えられるもの)を記述する。
                       (複数列挙してもよい)

    (d) オブジェクト群:   問題のシステムを構成するオブジェクトを列挙する。
    (e) 最小限のオブジェクト群:   問題を必要最小限に絞ったときのオブジェクト群

  例えばつぎのようなものを作る。









  この方法は, 「簡潔に表現し, 迅速・的確に考える」ことをモットーとしている。

    通常, 一つの技術的な問題を説明するには, 少なくとも1頁の文や図を使う。
      問題を持ち込んだ担当者は, 背景にあるいろいろな技術を知っており,
        問題の起こった状況, 経過, いままでの対応策, メカニズム, 物理原理など
        の知識を持っている。(これらは必要に応じてもっと詳しくできる。)

    「簡潔に表現する」のは, あいまいさをなくし, 明確にするためである。
        詳しく書いていると, いくつものことに言及し, 中心が不明確になる。
                           何を今解決する目標にするのかが, 不明確になる。

    図解においても, 装置の詳細を描くのでなく,
        問題のメカニズムに関係する部分のみを簡潔に描く。

    根本原因を書くには, 現在の方法・システムの基本原理や構造を知っており,
        問題が起こるメカニズムを (観察・実験などで)理解していないといけない。

      (オブジェクトについては, 後の講義で説明する。)

  「問題定義」の段階は, 「何が問題であるか?」を記述・確認しているのであるが,
                        「何を解決したいのか?」を記述していることでもある。

        その結果, これ以後の問題解決の方向を大きく決めてしまうことになる。
        その意味で, この最初の段階が非常に大事な段階である。
            特に, 「問題定義文」と「根本原因」の記述が問題の方向を決める。
 

  注意:  本節で述べた「ＵＳＩＴの問題定義段階」は, 問題を明確化するもの。
          「どんな問題」をこのＵＳＩＴ法に持ち込むかは, これより前に考えること。

         この意味で, 「レポートのテーマに何を選ぶか?」
                     「そのテーマのためには何を調べればよいか?」
                     「何がそのテーマでの本当の技術的課題であるか?」 などは
             ここの (ＵＳＩＴでいう) 「問題定義」よりも前の段階である。
 

  休講連絡:  次週 (11月8日) 休講  (欧州ＴＲＩＺ国際会議 (英国) に出張のため)
 
 
本連載のトップ 前回講義 本ページの先頭 1. はじめに 2. 人生の大事な問題の捉え方 3. 問題を捉える一つのヒント 4. 技術における問題の例 5. 問題を捉える諸観点 6. 問題の設定のしかた 7. 問題の明確化のプロセス (ＵＳＩＴの問題定義段階) 次回講義(6)

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

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

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