ＴＲＩＺをコンピュータサイエンスに (40の発明の原理) (Kevin Rea, 2001)

ＴＲＩＺ研究ノート：コンピュータサイエンス
ＴＲＩＺをコンピュータサイエンスに導入する　－　４０の発明原理についてのソフトウェアのアナロジー
Kevin C. Rea (Global Platforms Corporation, 米) 出典: TRIZ Journal, 2001年 9月号, 11月号和訳: 中川徹 (大阪学院大学) 2002年 1月13日 [掲載: 2002. 2. 4]

For going back to English pages, press

buttons.

編集ノート (中川徹, 2002年 1月13日)

本稿は, Bell Labs の研究者 (そして自分でコンサルタント会社を興している) Mr. Kevin C. Rea の論文を翻訳したものである。原論文はTRIZ Journal に前/後編として掲載され, つぎの表題であった。
    "TRIZ and Software - 40 Principle Analogies, Part 1", TRIZ Journal, September 2001.
    "TRIZ and Software - 40 Principle Analogies, Part 2", TRIZ Journal, November 2001.
この翻訳と『ＴＲＩＺホームページ』への掲載を許可いただいた著者およびTRIZ Journalに厚く感謝する。
著者: Mr. Kevin C. Rea (Global Platforms Corporation, 米国) http://globalplatforms.com   email: kevin@globalplatforms.com
TRIZ Journal:   編集者: Dr. Ellen Domb & Dr. Michael Slocom,

コンピュータ・サイエンス, ソフトウェア開発, あるいは情報通信技術 (IT) という分野は, 1970-1980年代を中心にしてロシアで開発されたＴＲＩＺにとっては, 新しい応用分野である。急速に高度情報社会に移行しつつある現在, この「ソフト分野」にＴＲＩＺをどのように適用するとよいかは, ＴＲＩＺの重要なフロンティアである。その意味で, ＴＲＩＺの40の発明原理をソフトウェア分野に適用して, アナロジーをまとめたこの論文は貴重である。
この論文の翻訳の許可を得たのは 9月16日であった。その翻訳がいままでできなかったのは, 一つには多忙だったからだが, もう一つはこの論文がコンピュータ・サイエンスの最先端の技術を扱い, それでいてずいぶん圧縮した記述になっているからであった。私自身も情報科学の分野に属しているから, この論文が言おうとしていることはかなり分かるが, 一部にはその真意が分からないところもある。この論文を理解するには, ネットワーク関連のソフトウェア技術, およびオブジェクト指向ソフトウェアに関する素養が必要であると思われる。特に, 以下の用語は技術分野 (たとえばシステム工学) での一般的な用語ではなく, オブジェクト指向ソフトウェアにおける専門用語として使っているので, 注意されたい。
     「エージェント」, 「オブジェクト」, 「クラス」, 「クラス階層」, 「モニタ」, 「プロセス」, 「プロトタイピング」
本論文の主要な目的が, ソフトウェア分野の技術者の人たちにＴＲＩＺの原理を紹介することであると考えるので, 敢えてこれらの用語の注釈を補足していない。訳文の誤り/不十分に気がつかれた方はぜひメールで連絡いただきたい。
なお, 翻訳にあたって, 40の発明の原理の訳は『革新的技術開発の技法- 図解ＴＲＩＺ』 (三菱総合研究所知識創造研究部編著, 日本実業出版, 1999年) を使わせていただいた。Reaの原論文では, サブ原理の一部しか記述していないが, 今後の考察の便を考えて全サブ原理を併記した (Reaが扱っていないサブ原理は ( ) 内に示した)。ＴＲＩＺの原理とサブ原理を赤色で, Reaの記述を黒色で表記している。
情報技術, 特に, ソフトウェア開発の分野は, いつもハードの分野や社会分野から概念を導入して, 自ら概念構築・モデル構築を行うことによって進歩してきた。いままた, ハード分野を端緒にしたＴＲＩＺの概念を導入することによって, ソフトウェアの懸案の諸問題を解決するための新しい思考法が構築できるものと期待される。

ＴＲＩＺをコンピュータサイエンスに導入する
　－　４０の発明原理についてのソフトウェアのアナロジー

著者まえがき (2001年9月号)

この数年の間, 私がさまざまに思いをめぐらせてきたのは, ＴＲＩＺをコンピュータサイエンスや情報通信技術 (IT) に使えるに違いないということであった (TRIZ Journal 1999年 8月号の私の論文参照) 。それ以来, 私はＴＲＩＺの概念を使って興味深い問題を解くのに成功し, 13件の特許申請を行った。ソフトウェアの問題にＴＲＩＺを適用するにはまだまだ考えるべきことがある。しかし, それでもなお, 私はＴＲＩＺジャーナルにこれからいくつかの記事を投稿して, ＴＲＩＺという強力な方法論を情報通信技術およびその他の「ソフトウェア関連」の問題に適用することを促進したいと思う。

この論文では, ＴＲＩＺの40の発明原理を, ソフトウェアとコンピューティングの文脈に私の観点から読み替えたアナロジーを提示する。付言すると, これらのアナロジーは進展中の作品であり, 後日増補・更新されるであろう。(この9月号では, 最初の20の発明原理について述べ, 残りの20の原理については, 後続の号 [2001年11月号] に掲載する予定である。)

(2001年11月号)

この論文では, 残りの21-40番のＴＲＩＺの発明原理について, ソフトウェアとコンピューティングの文脈に私の観点から読み替えたアナロジーを載せる。はじめの20の発明原理のアナロジーは2001年9月号を参照されたい。

ここに提示したソフトウェアのアナロジーは, 決して最終的なものではない。これらのアナロジーが試みようとしているのは, ＴＲＩＺをソフトウェアの問題解決に適用するための思考プロセスを刺激することである。

背景

ゲンリッヒ・アルトシュラーが40の発明原理を開発したのは20年以上前である。彼とその協力者たちは, 先端的な産業において, 技術的な矛盾を発明的に解決したものを選んで, 何千という世界の特許を調べた。アルトシュラーが興味を持っていたのは, 矛盾が妥協なしに解決された事例の研究であった。

技術的な問題を解決するためには, 以前に他の同様の問題を発明的に解決した事例を学び, そこで使われた原理を使えばよいことをアルトシュラーは見出した。例えば, 研磨機の製造における「磨耗問題」と, パワーシャベルの刃先の「磨耗問題」とは, ともに, 「分割」の原理を使って解決された。この相関に気づいてから, アルトシュラーは研究・分析を続けて, 以下のような40の原理を識別することができた。

アルトシュラーの発明の原理とそのソフトウェア・アナロジー

1. 分割原理

a. 物体を個々の部分に分割する。
ソフトウェアでのアナロジー：　システムを自律的な構成要素に分割する。
ソフトウェアでの事例：　インテリジェント・エージェント。インテリジェント・エージェントは相互に独立に動作することができ，一つの共通の目標を達成する。
b. 物体を容易に分割できるようにする。
ソフトウェアでのアナロジー：　類似の機能や性質を分離して，自己充足的なプログラム要素たち (すなわち, モジュールたち) にする。
ソフトウェアでの事例：　C++のテンプレート。C++のテンプレートは, プログラムコードを入れる容器の役目をし, このコードのランタイムの実行をモジュラーにする。
c. 物体の分裂または分割の度合いを強める。
ソフトウェアでのアナロジー：　分割のレベルを上げて, 知られている原子的な閾値に達するまでにする (原子的な閾値とは, 物体や構成要素の最小の構造単位を意味する。例えば, ビットはエンコーディング方式の文脈における原子的なものと考えることができる。)
ソフトウェアでの事例： 機密を要するオブジェクトを細分化する。設計時にオブジェクトを細分化することに基づいているこのアイデアは, 機密のオブジェクトを処理するのを減らすことである。設計時に非機密のオブジェクトを多く作ることができれば, それだけ多くの応用的なオブジェクトを, 信頼度の低い共有コンピュータ上でも処理することができる。原子的な閾値というのは, 機密のオブジェクトを分割していって, もはや機密オブジェクトに値しない小ささに達した点をいう。　

2. 分離原理

a. 物体の「干渉」部分または特性を分離する。あるいは物体の必要な部分または特性だけを選抜する。
ソフトウェアでのアナロジー：　一つの言語が与えられたときに, その言語の文法表現と, その表現を使ってその言語の中の文を抽出・解釈するようなインタプリタとを [分離して] 定義する。
ソフトウェアでの事例1：　画像の中からテキストを抽出する。画像中にあるテキストのブロックの所在を見つけ, それを抽出するのに有用な, テキスト分離技術。そのアルゴリズムは, テキストの向き, サイズ, フォントなどを予め知っていないでも働く。背景の画像情報を除去し, テキストを含んでいる画像の領域をハイライトしたり, 識別したりするように, 設計されている。
ソフトウェアでの事例2： パーザー [構文解析ソフト]。データを構文解析するとは, そのプログラムを使って入力データを解析し, 解釈しやすく処理しやすいような, より小さく, より区分された情報の塊の集合に, 分解することをいう。

3. 局所性質原理

a. 物体の均質な構成を不均質な構成に変更する。均質な外部環境または外部の影響を不均質なものに変更する。
ソフトウェアでのアナロジー：　技術システムでのオブジェクト分類を, 均質的な階層分類から, 不均質な (多重の) 階層分類に変える。
ソフトウェアでの事例1：　文字認識のための, 非一様なサンプリング法。与えられた行方向に垂直な方向に関して, 一次元的に特徴をサンプリングする特徴抽出法を規定する。特徴のサンプリングを非一様な間隔で行い, 近接した 2本の線を 1本の線と誤って認識しないようにする。
ソフトウェアでの事例2： 非一様アクセスのアルゴリズム。無線通信の環境では, 情報は通信チャンネルで放送され, 電池で動作する強力なパームトップ機器を使う利用者たちに届けられる。エネルギー消費を省力化するために, 放送する情報をうまく組織化して, 利用者たちが放送の中の欲しい部分に選択的にチューニングできるようでなければならない。既存の方法の多くは一様な放送を用いている。しかしながら, 非常によくあることは, 小部分の情報が多数の利用者からしばしばアクセスされ, 他方残りはアクセスの需要が少ないことである。この局所性質原理を使うと, 特定の運用に対して適切なアクセスの振る舞いを予測する, 非一様なアルゴリズムを開発できる。
(b. 物体の各部分を, その物体の動作に最適な条件下で機能するようにする。)
c. 物体の各部分が, それぞれ別の有用な機能を遂行できるようにする。
ソフトウェアでのアナロジー：　上記サブ原理と同じ。
ソフトウェアでの事例：　シングルインデックス・ツリーにおいて, データオブジェクトをより高いレベルに上げる。この例として, プロセス技術とデータマネジメントにおける空間的 (地理的) データの場合について述べよう。データの外延が非一様であることは, 空間的データの一般的な特徴である。そのような非一様なデータ群を, R-ツリーのような従来型の空間インデックス構造を使ってインデックスを作るのは, つぎの二つの理由から非効率である。(1) 非一様性のために, インデックスの項目が重なり合う可能性が増える。 (2) 非一様なデータ群をクラスタリングすると, 一様なデータ群の場合よりも, より多くのデッドスペースをインデックスする可能性がある。ＴＲＩＺの考え方を使って, この状況を考察し, 有用な機能を達成するようにしなければならない。これらの特異性の影響をより「有用」にするために, われわれは新しいスキームを発明し, ツリーベースのインデックス構造において, データオブジェクトをより高いレベルに上げるようにした。するとこれらのオブジェクトたちは, インデックスツリー中の位置に応じて, さまざまの機能を実現するようになる。

4. 非対称原理

a. 物体の対称な形を非対称に変更する。
ソフトウェアでのアナロジー：　技術システムの非対称性を変化させて, 計算処理の望ましい結果に非一様に影響を与えるようにする。
ソフトウェアでの事例：　ランダム化負荷分散, 動的資源割り当て, あるいはハッシングに関連して, われわれはボールとビン (箱) のプロセスたちを持っていると想定しよう。n個のボールをn個のビンに割り当てることを想定し, それぞれのボールを入れるときに, 今までのボールの場所分布を知らないで入れねばならないとしよう。われわれのアルゴリズムの目標は, 割り当てができるだけ均一になり, どのビンも平均よりずっと多くのボールを割り当てられるということがないように, 割り当てを実現することである。
(b. 物体が非対称である場合は, 非対称の度合いを強める。)

5. 組み合わせ原理

(a. 同一のあるいは類似した物体をより密接にまとめる, または組み合わせる。同一のあるいは類似した部分を組み立てて並列動作を遂行するようにする。)
b. 作業を隣接または並行させる。同一時間内にまとめる。
ソフトウェアでのアナロジー： プロセスたちを並列して走らせる。
ソフトウェアでの事例：　実行のスレッドたちを時間的に同期させる。「モニタ」と呼ぶ同期プリミティブが, さまざまの優先度を持つスレッドたちを, 一つの主アービトレータに「統合」して, どのスレッドが, いつ, プロセッサに割り当てられるかを決定する。

6. 汎用性原理

a. 部品や物体に複数の機能を持たせ, 他の部品の必要性をなくす。
ソフトウェアでのアナロジー：　一つの技術システムが, その文脈に応じて, 複数のダイナミックなクラス体系をサポートする。
ソフトウェアでの事例：　ユーザのログイン設定に基づいて, 振る舞いを特定的にする要求の結果として, 一つのコンテキスト (文脈) が作られる。状況あるいはコンテキストに応じて, 技術システムはそれぞれに特徴的なアイデンティティを示し, コンテキストに応じた性質 (あるいは一般に, コンテキストに応じた振る舞い) を持つ。

7. 入れ子原理

a. 物体を別の物体の中に入れ, その物体をまた別の物体の中に入れる。
ソフトウェアでのアナロジー：　一つのオブジェクトの基本クラスの内側に, 他のオブジェクトたちのそれぞれのクラスを入れ子にして持つことにより, 他のオブジェクトたちの機能を継承する。
ソフトウェアでの事例：　オブジェクト指向システムにおける入れ子のオブジェクト。オブジェクトたちが他のオブジェクトたちの中に住み, サービスや機能を強化する。クラスを他のクラスに入れ子にして設計することにより, これを実現する。
(b. ある部品が別の部品の空洞中を通過するようにする。)

8. つりあい原理

a. 揚力を与える他の物体と組み合わせることで, 物体の重さを軽減する。[*訳を訂正した]
ソフトウェアでのアナロジー：　多数の細粒度オブジェクトたちを効率的にサポートするために, 共有化を使い, 技術システムへの動的な負担を軽減する。
ソフトウェアでの事例：　一つの共有化オブジェクトを複数のコンテキスト (文脈) で同時に使えるようにする。そのオブジェクトは各々のコンテキスト中では一つの独立なオブジェクトとして行動する。それは, 共有化されていないオブジェクトの一つのインスタンスと区別することができない。
(b. 空気力, 流体の力, 浮力, その他の力を利用するなどして, 環境と相互作用させて, 物体の重さを軽減する。)

9. 先取り反作用原理

(a. 有用な効果と有害な影響を同時にもたらす動作を遂行する必要がある場合は, 有害な影響を減らすために, 事前にその反作用を働かせておく。)
b. 物体中にあらかじめ応力を発生させておき, 後に発生する望ましくない動作応力と相殺する。
ソフトウェアでのアナロジー：　システムにおいて予備的なプロセサ動作を行い, その後の計算処理を有利にする。
ソフトウェアでの事例：　改行のマッチングをとる前に, テキスト行を逆転させておき, パターンマッチングの能率を上げる。

10. 先取り作用原理

a. 物体に対して必要な変更の一部またはすべてを事前に行う。
ソフトウェアでのアナロジー：　上記のサブ原理と同じ。
ソフトウェアでの事例：　Java仮想機械は, その (プログラム) コードを実行する前に, あるいは (and/or), マシン依存バイナリコードに翻訳する前に, 予めテキスト形式から中間形式に変換しておく。
(b. 最も都合のよいところから動作を遂行できるように物体をあらかじめ準備して, 動作の遂行に無駄な時間がかからないようにする。)

11. 事前保護原理

a. 緊急手段をあらかじめ準備しておいて, 物体の比較的低い信頼性を補う。
ソフトウェアでのアナロジー：　ワーストケースの有害な効果を扱えるアルゴリズムを使い, グローバルな安定を維持する。
ソフトウェアでの事例：　無線パケットネットワークにおける公正なスケジューリング。

12. 等ポテンシャル原理

a. 重力場中では, 上下の移動を制限する。(たとえば, 作業条件を変化させて物体を上げ下げする必要性をなくす。)
ソフトウェアでのアナロジー：　アルゴリズムの動作条件を変化させて, 一つのプロセスに入出するデータのフローを制御する。
ソフトウェアでの事例：　透明で消えないオブジェクト記憶。(電圧がポテンシャルエネルギーであり, データがポテンシャルの情報である。) [?]

13. 逆発想原理

a. 問題の解決に利用する作用を, たとえば物体を冷却する代わりに加熱するといったように, 逆にする。
ソフトウェアでのアナロジー：　トランズアクションを, 実行失敗に備えて, 逆順に収納する。
ソフトウェアでの事例：　修復とバックトラッキッグのシステム (データベース)。
(b. 可動部分や外部環境を固定したり, 固定部分を可動にしたりする。)
(c. 物体やプロセスを「逆さま」にする。)

14. 曲面原理

a. 直線状の部品, 表面, 形を使用する代わりに, 曲線状のものを使用する。平坦な表面を球面にする。立方体形状の部品を球状の構造にする。
ソフトウェアでのアナロジー：　線形のデータ型を, 循環形の抽象データ型に置き換える。
ソフトウェアでの事例：　バウンデッド・バッファ。バウンデッド・バッファのデータ構造は, プログラム変数のようなディジタル情報を収納するための無限の記憶メカニズムを提供する。この循環形の構造は, アルトシュラーの円形滑走路のアナロジーと同様である。(彼の飛行機は滑走路から離陸するか, そうでなければ [後続の飛行機に] 轢かれてしまうだろう。それと同様に, プロセサがバウンデッド・バッファの同じ位置に書き込みをする前に, 有効なデータを使ってしまうように, プログラマが保証しなければならない。)
(b. ローラー, 球, 螺旋, ドームを使用する。)
(c. 直線運動を回転運動に変え, 遠心力を利用する。)

15. ダイナミック性原理

a. 物体の特性, 外部環境, プロセスを変更して, あるいは変更するように設計して, 最適にするかまたは最適の作業条件を見出す。
ソフトウェアでのアナロジー：　上記のサブ原理と同じ。
ソフトウェアでの事例：　ダイナミック・リンク・ライブラリ (DLL)。
(b. 互いに相対的に運動できるように, 物体を部分に分割する。)
(c. 物体またはプロセスが不動あるいは不変である場合は, 可動にするかまたは適応性を高める。 )

16. アバウト原理

a. 指定された解決法で100%の効果を獲得するのが困難なときは, 同じ解決法で効果の程度を「もう少し小さく」または「もう少し大きく」する。これにより, 問題をかなり容易に解決できることがある。
ソフトウェアでのアナロジー：　摂動分析を用いて, 測定可能で決定論的な計算の性能を向上させる。
ソフトウェアでの事例：　プログラムの動作に対して性能測定を行うと, 実際の実行の振る舞いは摂動を受ける。例えば, 同期 (システム) において, 同期動作 (例えば, バリア, セマフォア, および進め/待ての同期など) の測定とその分析により, 実際の実行の振る舞いのずいぶんよい近似が得られる。そこで, 摂動分析により, われわれの処理の性能結果に対して多少とも影響を与えることができる。 [?]

17. 他次元移行原理

a. 物体を二次元または三次元空間内で移動する。
ソフトウェアでのアナロジー：　クラスオブジェクトを, 単層でなく, 多層の集合体にする。
ソフトウェアでの事例：　継承されたオブジェクトたちを集めて, 機能を新しく構成する。
(b. 物体を単層ではなく多層に配列する。)
(c. 物体を傾けたり, 方向を変えたり, 横向きに置いたりする。)
(d. 指定された領域の「反対側」を利用する。)

18. 機械的振動原理

a. 物体を振動させる。
ソフトウェアでのアナロジー：　アルゴリズムの実行の率を時間について変化させて, 望む結果を得られるようにする。
ソフトウェアでの事例：　一つのオブジェクトに対するアルゴリズムの実行の率を周期的に変えることにより, システム全体が理想的な状態に共振するようにする, というビジュアルなアナロジーを要求する。
(b. 振動数を超音波になる程まで増大させる。)
(c. 物体の共振振動を利用する。)
(d. 超音波振動と電磁界振動を組み合わせて使用する。)

19. 周期的作用原理

a. 連続的な動作の代わりに, 周期的または脈動的動作を利用する。
ソフトウェアでのアナロジー：　一つのタスクを継続的に実行する代わりに, 時間帯を決めてそのタスクを周期的に実行する。
ソフトウェアでの事例：　スケジューリングのアルゴリズム (例えば, 警告のメカニズム, クローン・ジョブ, イベントの複製など)。
(b. すでに周期的な動作の, 周期の程度や頻度を変更する。)
(c. 連続的な動作の間の一時停止を利用して, 別の動作を遂行する。)

20. 連続性原理

a. 作業を連続的に遂行する。物体のすべての部分が常に最大負荷で動作するようにする。
ソフトウェアでのアナロジー：　プロセサを最大負荷で利用するような, 細粒度の解決策を開発する。
ソフトウェアでの事例：　さまざまな人気の映画たちを, 最大効率でかつ最小の平均位相ずれで提供するための, ニア-ビデオオンデマンド (NVoD) スケジューリング。バッファを利用したビデオの連続性の確保 (例えば, リアルプレイヤーや Windows のメディアプレーヤー)。
b. 遊休状態あるいは断続的な動作や作業をすべてなくす。
ソフトウェアでのアナロジー：　ブロックするようなプロセスや実行スレッドをすべてなくした, 細粒度並列化の解決策の開発。^文献3)
ソフトウェアでの事例：　バリア同期の解決策。読み出し/書き込みのデータベース・トランザクション・アルゴリズム。

21. 高速実行原理

a. 破壊的, 有害, あるいは危険な操作等のプロセスや段階を高速で実行する。
ソフトウェアでのアナロジー：　ワーストケース・シナリオの直前において, データをバーストモードで [一挙大量に] 転送する。
ソフトウェアでの事例：　ATM (非同期転送モード) ネットワークでの大量通信のために, バーストレベル優先度方式を用いる。ATMネットワークにおいて, 大量通信の接続を確率論的に資源共有させることにより, 統計的にみてスループットを増大できる。さまざまのサービス品質 (QoS) の要求を持つ接続が同一資源を共有する場合には, 一つのリンクの受容可能な負荷を決めるのに, 最優先要求がリミティング・ファクタとなることが典型的に起こる。この結果, 低いQoS要求の接続が, 要求しているより以上のサービスを受けることになり, 資源全体では利用率が低くなる結果になる。この問題を軽減するために, われわれはバーストレベル優先度スキームを使って「高速実行」をする必要がある。このスキームは, ネットワーク中の関連するセルたちを, バースト・バイ・バーストのベースで扱う。バーストに対して, その優先度に従って, その場で帯域を割り当てる。

22. 「災い転じて福となす」の原理

(a. 有害要因, 特に環境や周囲条件の有害な影響を利用して, 有益な効果を獲得する。)
b. 主な有害作用を別の有害作用に追加して相殺し, 問題を解決する。
ソフトウェアでのアナロジー：　有害なプロセスの役割を逆転させ, それを発信もとに送り返す。
ソフトウェアでの事例：　分散サービス拒否 (DDoS) 攻撃を打ち負かす。DDoS攻撃はネットワークを飽和させるものである。それは, 標的とするサーバに膨大な数の通信を送って単純に圧倒してしまい, その結果通常のユーザがそのサーバにアクセスすることができなくする。DoS攻撃のうちの他のタイプが個別ベースで実行するのに対して, この分散DoS攻撃は, 多数の「ゾンビー (幽霊)」コンピュータ群を作り, 標的の犠牲者サーバを溢れさせるための攻撃に知らない間に一斉に参加させるようにする。被害が大きいのは, この攻撃が分散して起こすという性質による。攻撃者たちは, インターネットのセキュリティが十分でなく容易にアクセスできるチャンネルを使って, 膨大な数量の通信トラフィックを集め, セキュリティチャンネルに対して, 潜り込むわけではないが効果的に渋滞させてしまうことができる。そこで, ＴＲＩＺを適用すると, われわれは, 害 (コンピュータを過負荷にさせること) を益 (ゾンビーの効率を低下させる) にすることができる。そのためにはゾンビーのコンピュータにボトルネックとなるプロセスを作り, 攻撃能力を限定すればよい。このためには, 接続を確立する前に, 攻撃をしようとするコンピュータが小さなパズルを正しく解かねばならないように要求すればよい。パズルを解くのにいくらかの計算パワーを必要とするので, 攻撃者がそれと並行して出せる接続要求の数は限定されることになる。

23. フィードバック原理

a. 前の状態を参照したり, クロスチェックするなどのフィードバックを導入して, プロセスや作用を改善する。
ソフトウェアでのアナロジー：　閉じたループ中にフィードバック変数を導入し, 後続の反復を修正・改良する。
ソフトウェアでの事例：　ATM (非同期転送モード) システムにおけるレイト-ベースのフィードバック。閉ループ入力レイト規制方式が, ATMでのABR (利用可能ビットレイト) トラフィックサービスのカテゴリの伝送で, 重要な役割を果たすようになった。フィードバックシステムを有限QBD (Quais-Birth-Death) プロセスとしてモデル化することにより, 一つの渋滞ノードと多数の接続よりなる遅延フィードバックシステムの性能向上を達成した。
(b. すでにフィードバックを利用している場合は, その程度や影響度を変更する。)

24. 仲介原理

a. 中間のキャリア物質または中間プロセスを利用する。
ソフトウェアでのアナロジー：　データのビューを, プロセスの応用空間の文脈においてプロセスに提供するために, 仲介者を利用する。
ソフトウェアでの事例：　ある程度構造化されたデータを強化するために, XML (拡張可能マークアップ言語) と組み合わせて, メディエータ (仲介者) を用いる。仲介は, XML における重要な部分である。DTD (ドキュメントの型定義) と組み合わせて用いて, メディエータが他のプロセス (例えば, [データベースの] 質問の構成と質問の処理のためのユーザ・インタフェース) をより効果的に支援する。つぎの図がこの事例の概念図である。

(b. ある物体を, 簡単に除去できる他の物体と一時的に組み合わせる。)

25. セルフサービス原理

a. 補助的な機能を付加することにより, 物体がセルフサービスを行うようにする。
ソフトウェアでのアナロジー：　上記のサブ原理と同じ。
ソフトウェアでの事例：　シマンテック (Symantec) の更新。このアプリケーションソフトは, 自分自身を更新する必要かあるかどうかを周期的にチェックする。もし更新を必要とする新しいものがあれば, 依存関係グラフが作られて実行され, それによってアプリケーションソフト自身がサービスを受ける。
(b. 廃棄資源, 廃棄エネルギー, 廃棄物質を利用する。)

26. 代替原理

a. 入手しにくく, 高価で壊れやすい物体の代わりに, 単純で安価なコピーを使用する。[* 訳を一部訂正した]
ソフトウェアでのアナロジー：　オブジェクトを新しく作って不必要に資源を使う代わりに, 浅い (表面的な) コピーを作る。
ソフトウェアでの事例： 浅いコピーというのは, 新しい複合オブジェクトを作り, そしてもともとのオブジェクトたちへの参照を (可能な限り) その中に組み込むことである。
(b. 物体またはプロセスを, 光学的にコピーしたものと置き換える。)
(c. 可視光学的コピーがすでに使用されている場合は, 赤外線または紫外線コピーを使用する。)

27. 「高価な長寿命より安価な短寿命」の原理

a. 寿命など, ある属性を犠牲にして, 高価な物体を多数の安価な物体に置き換える。
ソフトウェアでのアナロジー：　上記のサブ原理と同じ。
ソフトウェアでの事例：　プロトタイプから完全なアプリケーションソフトウェアを開発して高価なコスト超過を起こす代わりに, 使い捨ての (ラピッド) プロトタイピングを使う。使い捨ての (ラピッド) プロトタイピングは:

できる限り迅速に作る (このため, 工学的にしっかりしたものにしない)。

よく分かっていない要求部分だけを実装する。

実証せずに言われている要求群のうちの, 何が本当で何が本当でないかを, 学ぶために用いる。

必要な情報が得られた後は, 用済みで捨てられる。

28. 機械的システム代替原理

a. 機械的手段を, 光学, 音響, 味覚, 嗅覚などの知覚手段に置き換える。
ソフトウェアでのアナロジー：　上記のサブ原理と同じ。
ソフトウェアでの事例：　これは直截的な事例である: (今私がやっているように) タイプし, ミスタイプし, そしてバックスペースを押すという機械的な動作を, 音声認識で軽減する。
(b. 電界, 磁界, 電磁界を利用して物体と相互作用させる。)
(c. 固定フィールドから可動フィールドに, 構造化されていないフィールドから構造化されたフィールドに変更する。)
(d. 強磁性体のようにフィールドによって活性化される粒子とフィールドを組み合わせる。)

29. 流体利用原理

a. 膨張, 液体充填, エアクッション, 静水圧, 流体反応など, 物体の固体部分ではなく気体または液体部分を使用する。
ソフトウェアでのアナロジー：　今は無し。
ソフトウェアでの事例：　今は無し。

30. 薄膜利用原理

(a. 三次元構造の代わりに柔軟な殻や薄膜を使用する。)
b. 柔軟な殻や薄膜を使用して物体を外部環境から分離する。
ソフトウェアでのアナロジー：　ラッパーオブジェクトを使って, 外部環境から一つのオブジェクトを分離する。
ソフトウェアでの事例：　ラッパー (包み) オブジェクトとか, アダプターオブジェクトとか言われるものは, 一つのオブジェクトを外部環境から分離するものであり, 内部のオブジェクトと外部のオブジェクトとの間に固定的なインタフェイス (すなわちラッパーオブジェクト) を保持する。

31. 多孔質利用原理

a. 物体を多孔質にする, あるいは多孔質要素を追加, 挿入, コーティングする。
ソフトウェアでのアナロジー：　今は無し。
ソフトウェアでの事例：　今は無し。
(b. 物体がすでに多孔質である場合は, 細孔を使用して有用な物質や機能を導入する。)

32. 変色利用原理

(a. 物体または外部環境の色を変更する。[* 訳を訂正した])
b. 物体または外部環境の透明度を変更する。[* 訳を訂正した]
ソフトウェアでのアナロジー：　上記のサブ原理と同じ。
ソフトウェアでの事例：　画像処理あるいは描画プログラムにおける透明化機能。

33. 均質性原理

a. 物体を, 同じ材料, または同一の特性を持つ材料の物体と相互作用させる。
ソフトウェアでのアナロジー：　特定の型の純粋なオブジェクトたちを作り, 同一の性質を保証する。
ソフトウェアでの事例：　配列のような, データ容器オブジェクト。配列の各要素は同じ型でなければならず, それによって一貫した書き込み/読み出し操作ができる。

34. 排除/再生原理

a. 機能を完了した物体の部分を, 溶融, 蒸発などにより廃棄, 排出する。または動作中にその部分を修正する。
ソフトウェアでのアナロジー：　アプリケーションソフトの使われない記憶を廃棄する。
ソフトウェアでの事例：　Javaプログラミング言語におけるガーベジコレクション (ごみ集め) プロセスは, 周期的に記憶を掃除し, すでにそのスコープが終了したのにまだ存在するオブジェクトたちを廃棄する。
b. その逆に, 動作中に物体の消耗部分を直接回復させる。
ソフトウェアでのアナロジー：　上記のサブ原理と同じ。
ソフトウェアでの事例：　データベースのバックトラッキングは, アプリケーションが以前のトランザクションの状態に回復 (すなわち後戻り) できるようにする。

35. パラメータ変更原理

(a. 気体, 液体, 固体などといった物体の物理的状態を変更する。)
(b. 濃度や均一性を変更する。)
c. 柔軟性の程度を変更する。
ソフトウェアでのアナロジー：　上記のサブ原理と同じ。
ソフトウェアでの事例：　一つのアプリケーションソフトウェアが, その性質を動的に変化させることにより, 異なるサービスを提供するように変換できる。この柔軟性は, 一つのアプリケーションでオブジェクトたちが複数の役割を果たせるようにする。
(d. 温度を変更する。)

36. 相変化原理

a. 体積の変化, 熱の損失や吸収など, 相転移の間に発生する現象を利用する。
ソフトウェアでのアナロジー：　今は無し。
ソフトウェアでの事例：　今は無し。

37. 熱膨張原理

a. 材料の熱膨張や熱収縮を利用する。
ソフトウェアでのアナロジー：　今は無し。
ソフトウェアでの事例：　今は無し。
(b. 熱膨張を利用している場合は, 熱膨張係数の異なる複数の材料を使用する。)

38. 高濃度酸素利用原理

a. 通常の空気を, 高濃度の酸素を含んだ空気と入れ替える。
ソフトウェアでのアナロジー：　今は無し。
ソフトウェアでの事例：　今は無し。
(b. 高濃度の酸素を含んだ空気を純粋な酸素と入れ替える。)
(c. 空気や酸素に電離放射線を照射する。)
(d. オゾン化酸素を利用する。)
(e. オゾン化またはイオン化酸素をオゾンと入れ替える。)

39. 不活性雰囲気利用原理

a. 通常の環境を不活性な環境と入れ替える。
ソフトウェアでのアナロジー：　今は無し。
ソフトウェアでの事例：　今は無し。
(b. 中性な部品や不活性添加剤を物体に加える。)

40. 複合材料原理

a. 均一な材料を複合材料に変更する。
ソフトウェアでのアナロジー：　ソフトウェアの均一な抽象化から, 複合的な複合化に変更する。
ソフトウェアでの事例：　ソフトウェア・デザインパターンは, ソフトウェアの設計においてたびたび必要とする問題解決を成功させるための, 中核となる抽象化の例である。複合デザインパターンが, たびたび起こる枠組みをうまく抽象化する中心である。複合デザインパターンとは, 一組のパターンであって, それらを統合したことにより, それらをただ単に合計したより以上のものを創り出したシナジー効果を示すものである。本論文は, 複合パターンの事例たちを提示しており, 分析と複合の方法を議論し, さらに, 複合パターンにより, パターンの概念を, 単一の問題解決策たちからオブジェクト指向の枠組みにまで拡張できることを, 例示したのである。

結論 (9月号)

われわれはまだ, ＴＲＩＺがソフトウェアの問題に対してできることのほんの表層部分を扱っているに過ぎないと私は思う。この線に沿って, ソフトウェア問題へのＴＲＩＺの適用について, 複数テーマの一連の記事を書くことを私は約束した。TRIZ Journalの11月号から始める予定である。各シリーズは特定の問題領域を扱うつもりである。まず最初は情報セキュリティに関連し, 最近インターネット上で重大な被害を及ぼしたCode Red Wormについて見, その次に不可避なワームに対する防備にＴＲＩＺがどのように使えるかを考えよう。

(11月号)

ここに提示したアナロジーたちは, ＴＲＩＺを頭に置きつつソフトウェアの諸問題を観察したときに, われわれが使うことができる多くの橋の中のほんのいくつかである。ＴＲＩＺのいくつかの物理的原理はソフトウェアへの応用からは非常に離れているように見えるけれども, ソフトウェアを見るには多くの抽象化の方法があることを思い出すべきである。また, われわれがＴＲＩＺをもっとしばしばソフトウェア問題に適用するにつれて, 隠れていたアナロジーたちを見出していくことであろう。

参考文献

1. "The Invention Algorithm", Genrich Altshuller著, Lev Shulyak & Steve Rodman 英訳, Technical Innovaton Center, Inc., 2000年 7月。
2. "Engineering of Creativity: Introduction to TRIZ Methodology of Inventive Problem Solving", Semyon D. Savransky 著, CRC Press, 2000年。
3. Kevin C. Rea, "Using TRIZ in Computer Science - Concurrency", TRIZ Journal, 1999年 8月。

著者について

Kevin C. Reaは, Global Platforms Corporation の主任コンサルタントである。この会社は, 構造化技術革新のトレーニングを提供し, 情報通信技術 (IT)/コンピューティング/軍事に専門化して, ＴＲＩＺを使った問題解決を提供する。彼はまた, Lucent Technologies - Bell Labs で 8年の経歴を持つベテランであり, 第3世代のワイヤレス製品 (UMTS) の開発を担当するコンピュータ研究者である。電子工学の学士, コンピュータ・サイエンスの修士の資格をもち, コンピュータ・サイエンスのPhD資格を追求中で, 「高度なコンピューティングの諸問題へのＴＲＩＺの適用」をテーマとしている。