8. ユーザの具体的問題を概要記述する ([TechOptimizerモジュール] の基本部) いままでで, いろいろなデータベースを提供している 3つのモジュールの使い方を学 んだ。 [Prediction モジュール] トレンドと改良方法([Method tree]) [Effectsモジュール] 科学技術の原理と事例 [Principles モジュール] 発明の原理と「矛盾解消のマトリクス」 そこで, つぎに[TechOptimizerモジュール] を習得しよう。このモジュールは, 実は ソフトツール[TechOptimizer Pro] の入り口のモジュールである。このモジュールは一 般的なデータベースを持っているわけでなく, ユーザが自分で解決したいと考えている 問題について, 具体的に入力していかないと何もできない。ユーザがいままでの学習で , このＴＲＩＺ法のソフトツール[TechOptimizer Pro] の有用性を認識して, 自分のプ ロジェクトについて実際に適用してみようというときに, この[TechOptimizerモジュー ル] を習得すればよい。実地適用でプロジェクトの課題を的確に問題解決していくため には，プロジェクトの問題把握と管理, ツールの使用経過の管理と記録などが必要であ り, そのためには，このモジュールが有用で, 最初に使うべきもの (入り口) なのであ る。 8.1 自分の問題 (プロジェクト) の記述 〔操作法： [TechOptimizer Pro] を立ち上げると，この[TechOptimizerモジュー ル] の主画面に入る。画面の[Welcome to TechOptimizer ウィンドウ] の質問 に対して, 新しいプロジェクトだから[New Projectボタン] を押す。図8.1 の ような [Project Data画面] になるので, 各ウィンドウに自分の問題について 記述していく。また, 画面左端下の[Project Data メニュー] を開いて[Team ボタン] をクリックすると, チームと期間を記入できるようになる。〕
図8.1 [TechOptimizerモジュール] の[Project Data 画面]: プロジェクトの記述
自分の問題 (プロジェクト) について記述するのは以下の項目である。 プロジェクト名 オブジェクト名 (課題のシステムの名称） 課題の状況の初期段階での記述 (問題のステートメント) 目的 (Objectives)(目標パラメタと, その現在値, 仕様値, 重要性 (10段階評価)) 制約 (制約のあるパラメタとその値 (の範囲)) チーム (プロジェクトメンバの一覧表) 期間 (開始日, 終了日)
8.2 現在システムの機能モデル つぎに, 自分の問題について, 現在のシステム (または, 構想中のシステム) の機能 モデル (Function model) を, グラフ (図式) に表現する。 〔操作法： [TechOptimizerモジュール] の主画面で，左端の[Function Model ボ タン] をクリックして, 機能分析のモードに移る。この主画面は, ドロー系の 描画ソフトであり, 組み込みの簡略化された規約に従って操作して, 例えば, 図8.2 のような, システムの機能モデルを描く。〕
図8.2 [TechOptimizerモジュール] の[Function Model 画面]: 機能モデル [TechOptimizer Pro] では，機能モデルを表現するのに，以下の 5要素を用いる。 Component (部品, 構成要素) 長方形のノード Supersystem (上部システム, 環境, 外部要素) 六角形のノード Product (製品, 出力) 長円形のノード Useful action (有用な作用, 機能, 効用) 青色の矢印 Harmful action (有害な作用, 悪影響) 赤色の矢印 この機能モデルの図式の操作法は, ドロー形の描画ソフト (例えば, MacDraw や PowerPoint) の一般的な方法と同じであり, ドロー機能が専用化されていて, 大変描き やすく, よくできている。この専用化のポイントは, システムの要素の間の作用 (action)をより詳細に記述でき, それらの詳細データが (図には現れないが内部で) い ろいろ関連して分析に利用されることにある。 〔操作法： 機能モデルのノード間の矢印 (作用) の中点にある小さな丸印をクリ ックすると, 図8.3 のような[Link Analysisウィンドウ] が開く。ウィンドウ の左部の[Actionsウィンドウ] に, 作用の名前を書く (必要なら複数の作用を 同一ノード間に指定できる) 。その作用の有用/ 有害を指定する。さらにその 作用がどのような物理的パラメタで表現できるかを[Parameters ウィンドウ] に記入すると, [Link Analysisウィンドウ] の右部分が開き, さらに詳細を指 定していくことができる。〕
図8.3 [TechOptimizer モジュール] の[Link Analysisウィンドウ]: 機能モデルにおける作用のパラメタの記述
ユーザのシステムの問題点を理解するための基本の「機能分析」においては, 作用 (action) として, つぎの項目だけを指定すればよい。 作用([Action])の名称 作用主体Component と作用対象Component 有用作用/ 有害作用の区別 その結果は, 図8.2 とほぼ同様の形式の図式として表現される。ここでは, システムの 各構成要素の関連とそれぞれの作用を, 概念的に表現し, 理解できる。このような表現 を作っただけでも, 随分と問題の整理になり, 問題解決の焦点を絞るのに役に立つ。 ( [TechOptimizerモジュール] では, これだけを行なって, 本稿の 2〜7 節で扱った他の 3モジュールを使っていくことも, 十分実践的な活用法である。)
9. ユーザのシステムの機能分析を行なう ([TechOptimizerモジュール] の機能分析) [TechOptimizerモジュール] では, 前節で概要を記述したユーザシステムの機能モデ ルを, さらに詳細に記述していくことにより, より明確な機能分析 (どの機能を改良す るのが有効かなど) ができる。 9.1 機能モデルをパラメタで表現する この, より高度の機能分析のための基礎は，ユーザが機能モデルの各作用を適切なパ ラメタで定性的/ 定量的に表現し, 入力することである。この記述には，つぎのような 項目が可能で, そのうちの本質的な項目 (側面) だけを選んで記述すればよい。
作用を表現するパラメタ([Parameters]) (一つの作用に複数指定可能) パラメタの定性的/ 定量的の区別 (あるいは分析の定性的/ 定量的の区別) パラメタの値 (定性値/ 定量値) による表現 現状の値, 必要とする値 (仕様値)(とその誤差許容度), このパラメタの目的 この仕様値を満たすことの重要性([Significance]) パラメタの時間依存性に関する表現 現状の時間的振る舞いのグラフ, 必要とする時間的振る舞いのグラフ パラメタの場所依存性に関する表現 現状の場所依存振る舞いのグラフ, 必要とする場所依存振る舞いのグラフ 別のパラメタに対する依存性の表現 上記のようにいろいろ記述する中で, ソフトツールとしての[TechOptimizerモジュー ル] が特に (内部のロジックで) 利用するのはつぎの二つである。
パラメタの重要性([Significance]) (ユーザの入力値): この作用のパラメタが仕様を満たすことが, 全システムの最終的な目標パラメ タ(Objectives)の改良にどれだけ重要かを, 定性的に±10段階で表現。 パラメタの乖離度([Difference]) (ユーザの入力値から次式で計算): 乖離度 ＝ ABS (仕様値−現状値) / (2* 仕様値誤差許容度) 各作用について個別に指定した結果を整理して見るためには，[Function Model]の画 面から使える[Browser] 機能がある。 〔操作法： [Function Model 画面] で, 画面左端の[Structureメニュー] を開き [Browserボタン] をクリックする。[Browserウィンドウ] が開き, いくつかの 表現法と機能を下部のタブで選択できる。図9.1 は, [Function Table タブ] をクリックして得られた機能の一覧表である。この表の欄のうち，[Rank]と [Performance] の欄はグレー表記されており, ツールが内部ロジックで判断し たことを示している。〕
図9.1 [TechOptimizer モジュール] の機能モデルの[Browser画面]: 機能モデルにおける作用の一覧表の例
また, コスト面からも機能分析を補強できるようになっており, 図9.1 の下部に示さ れている[Component Cost タブ] をクリックすると, 各部品のコストの概算を入力でき るようになっている。 9.2 局所化された問題リスト 上記のような入力をユーザがすると, ツールは解決すべき問題を局所化してリストア ップすることができる。図9.2 は, 主画面の左下端にある[Problem Managerボタン] を クリックして開いた[Problem Managerウィンドウ] であり, ここには，問題のリストが 一覧として示されている。 〔操作法： [TechOptimizerモジュール] 主画面において, その左下端の[Problem manager ボタン] をクリックすると, [Problem Managerウィンドウ] が開く。 その左上には[List of Problems]がある。 [天秤ボタン] をクリックすると, 問題のリストを問題の重要性の点数順に並べ替えて表示できる。〕
図9.2 [TechOptimizer モジュール] の[Problem Managerウィンドウ] 機能分析から得られた問題の一覧とその一つの説明 図9.2 の例に示すように, リスト中の一つ一つの問題を選択すると, その説明が右半 分の[Problem description] として表示される。ここには, どの部品間のどの作用のパ ラメタを改善することが課題であるかが, 文章として示されている。この文章の構文は 決まり文句であるが, その中に, ユーザが入力した情報を埋め込んで, 適切な意味の通 るものにしている。このような技法は, [TechOptimizer Pro] (あるいはＴＲＩＺ法?) の得意芸であり, 感心させられる。 リストアップされた問題の重要性の算出方法は, この画面で[Help メニュー] をクリ ックすると, 定義を読むことができる。ここで使っている情報は, つぎのものである。 問題にしているパラメタの乖離度 ([Difference]) そのパラメタの重要性([Significance]) システム全体の目標パラメタ (複数可能) の相対的重要性([Importance]) これらは, ユーザが入力した情報であり, その大部分が定性的なものであるから, ツー ルが判定する「問題の重要性」の数値を後生大事にすることはない。ユーザが適切にデ ータを入力すれば, それだけ意味のある判定が得られる。要するに, ユーザの問題理解 が深くなればなるほど, ツールも適切にサポートできるのであり, そのように仕向ける ことがこのような思考支援ツールの役割なのである。
9.3 問題を局所化する意義 ここで注目すべきことは, ユーザは最初, 自分のプロジェクトが解決すべき問題を一 つ持っていると考えて, そのシステム構成を[TechOptimizerモジュール] の機能分析に 入力している。そのシステムは, 問題を抽象化して簡単に描いたつもりでも, 数個の Component から構成され, 数個あるいは十数個の作用やパラメタを含んでいることであ ろう。ところが, [TechOptimizer Pro] (あるいはＴＲＩＺ法) では, この一つ一つの 作用のパラメタを「解決すべき課題」として列挙するのである。 これは, ＴＲＩＺでは, 「発明は小さな部分で行なわれる」という認識を持っている からである。局所化した, 一つのぎりぎりの課題, 突き詰めた「矛盾」を解決したとき に, 技術革新 (発明) が生まれる。一ヶ所で行なわれた技術革新を活かすように, シス テムの他の部分が改造されていく。ＴＲＩＺは技術革新をこのように捉えている。この ため, [TechOptimizer Pro] の問題解決の 3モジュール ( [Predictionモジュール] , [Effectsモジュール] , [Principles モジュール] ) では, システム全体を一括して問 題とするのでなく, 局所化された個々の問題を扱うのである。
9.4 問題解決の管理([Problem Manager]による管理) 〔操作法： [Problem Manager] の画面で, 一つの［Problem]を指定している状態 で, ツールバーから, 問題解決の 3モジュールの任意のもののボタンをクリッ クして, 問題解決を実行することができる。このときに開かれる画面は, 例え ば図9.3 ([Effectsモジュール] の場合) のようである。〕
図9.3 [Problem Manager]の管理下で[Effectsモジュール] を使っている例 [Problem Manager] から問題解決のモジュールを呼んだ場合は, 問題解決の機能その ものは従来 ([TechOptimizer Pro] から直接呼んだ場合) と同じであるが, 処理が [Problem Manager] に管理されているサブモードである点が異なる。図9.3 の例のよう に, そのツールバーは, [Problem Manager] の機能と, その問題解決モジュール (この 図では [Effectsモジュール])の機能とを, 総合したものになっている。また, 図9.2 で指定していた問題が, 自動的に画面上部の課題ウィンドウに表記される。図9.3 のよ うに問題解決をいろいろ試みた後に, ツールバーの[Problem Managerボタン] をクリッ クして, 図9.2 の画面に戻ることができる。
10. システムの機能構成を吟味する ([TechOptimizerモジュール] の[Trimming]と [Feature Transfer モジュール]) 10.1 トリミング ([TechOptimizerモジュール] の[Trimming]) [TechOptimizerモジュール] の機能として, さらに「トリミング (Trimming) 」の機 能が備えられている。前節の機能モデルの入力をベースにして, システムの中から一部 のComponent を摘出・削除して, 代替案を作ることをユーザに試みさせる機能である。 [TechOptimizer Pro] の通常の説明では, このトリミングの機能を最初の段階で延々と 説明するが, 筆者は煩わしい機能であると思う。ある程度のエンジニアリングの素養の あるユーザであれば, 8節・ 9節のような機能モデルの記述と分析を行なえば, 何が無 駄なComponent であるかは, 自ずから考えられると思う。そして, 新しいシステム構成 を持つ機能モデルを描くであろう。 10.2 Feature Transfer ([Feature transfer モジュール]) [TechOptimizer Pro] の第 5番目のモジュールは, [Feature Transfer モジュール] である。これは, ＴＲＩＺの一つの技法である「特長の転用 (Feature transfer) 」を ツール化したものである。現状のシステムに対して, (実現性は問題にせずに) 究極の 理想形を考える。特に, 別の角度から見た, 別のメリットを持つ理想形を複数考える。 それらには，実現できなかったり, この問題では適当でなかったりする短所もある。そ こで, 複数の理想形からそれらの良いところ(Feature) を取り出してくるようにして, 新しいシステムの構成を考えようとするのである。筆者はこの方法 (およびこのモジュ ール) をまだ試してみていないので, ここに書くことは控える。ともかく, ＴＲＩＺや [TechOptimizer Pro] を十分に使いこなしてから, その後で使ってみるとよい機能であ ると思っている。
| 本ページの
先頭 |
8-1 プロジェクト記述 | 8-2 ユーザの
システムモデル |
8-3 機能リンク | 9-1 作用の表 | 9-2 問題マネジャ | 9-3 問題解決 | 次の
ページへ |
| 1. はじめに | 2.
技術トレンド
(Prediction 1) |
3.
科学技術体系
(Effects 1) |
4. 目標を実現する方法
(Effects 2) |
5. システム改良法
(Prediction) 2 |
6.
発明の原理
(Principles 1) |
| 7.
矛盾の解決
(Principles 2) |
8.
問題の記述
(TechOptimizer 1) |
9.
システムの機能分析
(TechOptimizer 2) |
10.
トリミングと機能移転
(TechOpt. 3 ) |
11.
レポート機能
(Reporting) |
12. おわりに |
| ホームページ | ソフトウェアツール | 論文・技術報告集 | 本技術ノートの先頭に戻る | 
English
home page |
