2024 / 11 «« ■ »» |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
meaning of mark :: nothing , comment
Pageview
Online Status
Profile
hHandleName = Fe+;
某メーカ勤務の怪しい会社員。
40代に突入しても不惑の域に達しない。
某メーカ勤務の怪しい会社員。
40代に突入しても不惑の域に達しない。
Recent Diary
Recent Comments
RSS & Atom Feed
2005/05/13
TRIZって結局・・・
[Fe+の外部記憶]
うーん・・・
まだ自分の中で消化できていない部分が多すぎなので全く見当違いなコメントの可能性があるのですが、ご容赦ください。
TRIZ(発明的問題解決の理論)という研修を二日間に渡って受講しました。
ちなみに上記「TRIZ」は「トゥリーズ」と読むそうです。
基本的にFe+はソフト屋さんなので、ソフト屋としての視点からTRIZを語らせて貰うと
デザインパターンみたいなもの
かなと。
賢い学者さんが研究している理論なので、Fe+のような一介のエンジニアには多少分かりにくい点が多くって、「何を言っているのか、何をやりたいのか、何を解決したいのか」という核となる事柄がぼやけてしまっている気がします。
ですが、分かりやすく言えば「デザインパターン+フレームワーク」かなと。
ロシアのアルトシュラーというおじさんが、かつてロシア軍(当時はソ連ですけど)軍属の特許審議官をやっているときに、
なんか特許って発明や解決方法にパターンがあるな〜
と気付いたらしいんです。
それも利用する産業分野が異なっていても、ある程度のパターンが存在すると。
そこで、アルトシュラーおじさんは、
250万件
の特許を調査し(!!)、そこからある一定のパターンを抽出、抱える問題から、解決方法となる「ヒント」とを結びつけて、容易に問題解決(や発明)ができるような
フレームワークとデザインパターン(らしきもの)
を作ったという事らしいです。
極論すると、
「サルでもできる発明フレームワーク」
を作ろうとしたって感じですか(かなり極端な表現ですが)
この辺りのマインドはデザインパターンと重なるものがあります。
つまり、「とっても賢い人達がウンウン唸って、発明した方法を、利用しちゃえ」という発想ですからまさにデザインパターンと言って良いと思います。
Fe+的に感じたTRIZのミソを以下に示します。
1.マインドはデザインパターン(なのでTRIZを利用=「銀の弾丸」ではない)
2.「改善点・リスク」というマトリクス表に基づき「技術的ヒント」を導出できるのがミソ
3.上記以外のフレームワークがたくさんある
4.たくさんあるフレームワークを利用者が適宜選択する必要がある
5.たくさんあるフレームワークを「どんな状況の時にどう選択するか」が曖昧
6.そういう意味で導入段階でのアクティビティがよく分からない
7.物理現象を含めて「モデリング」を行うフレームワークがある
8.モデリングで利用される記号の定義が曖昧(UMLのようなモデリング言語はない)
次にFe+的TRIZのノリ予想を以下に示します。
1.「直感」とか「自己の経験」だけで設計するのはやめようよ
2.フレームワークにより技術者同士の意思疎通の円滑化
3.デザインパターン的な「同じ土俵」での議論(「ストラテジーパターンね」的ノリ)
4.「あさっての方向」的発想の排除
5.物理現象を伴うモデリング→パターン適用というトップダウン的開発手法の普及
ちなみにアルトシュラーおじさんが250万件の特許を調査したのはかなり古い時代とのことで、基本的にTRIZは、
物理現象を伴う発明(問題解決)
に焦点を当てています。
そのため、自然科学と多少切り離された「ソフトウェア」の発明(問題解決)には、あまり効果がなさそうです。
(ソフトウェアに適用した事例もあるそうですが・・・)
つまり、メーカ系で言うと「メカ屋さん」「電気屋さん」「化学屋さん」などが利用することが前提のようです。
逆にソフト屋さんは、ソフト屋さんとしてTRIZのようなフレームワークがたくさんあるので、
無理に使う必要はないかも
というのが正直な感想です。
マトリクスから「技術的ヒント」を導き出すという点と、モデリングからパターン適用の時にデータマイニングのような事をするらしいのですが、その辺りが参考になりそうです。
あと「特許書き」の時には威力を発揮しそうなんですよね〜。
逆にモデリングの表記方法が曖昧だったり、先程の「どのフレームワークを利用して分析をするか」という明確なアクティビティの定義といった部分に関しては、UMLを導入した方が良いのではと思っちゃいます。
Fe+的にはフレームワーク思考というアプローチは嫌いではないので、なかなか勉強になりましたが、TRIZは強力なツールに「化けるポテンシャル」は秘めているのですが、
かなり発展途上で体系化されていない感
が強いというのが正直な感想です。
フレームワークとは「考え方の方向付け」だと思うので、このような手法により、「技術レベルの底上げ」を行い、エンジニア同士で「共通語(認識)」を持ち、意思疎通を円滑にすることは非常に良いことでしょう。
Fe+的に研究対象として今後、TRIZもウォッチしていきたいなと思う今日この頃でした。
ちなみにTRIZの教科書の冒頭には、
マインドマップ
もしっかり登場します。
利用方法はJUDEでの提案と同じですね。
やはり、マインドマップ最高です!
トニーブザン大先生には本当に感謝しなくては。
マインドマップの放射思考は大脳生理学の研究で明らかになった、人間の記憶システムと同じであるという科学的根拠があります。
この話については、いずれ詳しく書きたいと思います。
(以前から温めているネタなんで)
つまり、どのような「論理思考」を行うにしても、
全ての「論理思考」の原点となる
という事が素晴らしいんです。
なんだか最後にはマインドマップ絶賛ネタになってしまいました。[:にこネコ:]
まだ自分の中で消化できていない部分が多すぎなので全く見当違いなコメントの可能性があるのですが、ご容赦ください。
TRIZ(発明的問題解決の理論)という研修を二日間に渡って受講しました。
ちなみに上記「TRIZ」は「トゥリーズ」と読むそうです。
基本的にFe+はソフト屋さんなので、ソフト屋としての視点からTRIZを語らせて貰うと
デザインパターンみたいなもの
かなと。
賢い学者さんが研究している理論なので、Fe+のような一介のエンジニアには多少分かりにくい点が多くって、「何を言っているのか、何をやりたいのか、何を解決したいのか」という核となる事柄がぼやけてしまっている気がします。
ですが、分かりやすく言えば「デザインパターン+フレームワーク」かなと。
ロシアのアルトシュラーというおじさんが、かつてロシア軍(当時はソ連ですけど)軍属の特許審議官をやっているときに、
なんか特許って発明や解決方法にパターンがあるな〜
と気付いたらしいんです。
それも利用する産業分野が異なっていても、ある程度のパターンが存在すると。
そこで、アルトシュラーおじさんは、
250万件
の特許を調査し(!!)、そこからある一定のパターンを抽出、抱える問題から、解決方法となる「ヒント」とを結びつけて、容易に問題解決(や発明)ができるような
フレームワークとデザインパターン(らしきもの)
を作ったという事らしいです。
極論すると、
「サルでもできる発明フレームワーク」
を作ろうとしたって感じですか(かなり極端な表現ですが)
この辺りのマインドはデザインパターンと重なるものがあります。
つまり、「とっても賢い人達がウンウン唸って、発明した方法を、利用しちゃえ」という発想ですからまさにデザインパターンと言って良いと思います。
Fe+的に感じたTRIZのミソを以下に示します。
1.マインドはデザインパターン(なのでTRIZを利用=「銀の弾丸」ではない)
2.「改善点・リスク」というマトリクス表に基づき「技術的ヒント」を導出できるのがミソ
3.上記以外のフレームワークがたくさんある
4.たくさんあるフレームワークを利用者が適宜選択する必要がある
5.たくさんあるフレームワークを「どんな状況の時にどう選択するか」が曖昧
6.そういう意味で導入段階でのアクティビティがよく分からない
7.物理現象を含めて「モデリング」を行うフレームワークがある
8.モデリングで利用される記号の定義が曖昧(UMLのようなモデリング言語はない)
次にFe+的TRIZのノリ予想を以下に示します。
1.「直感」とか「自己の経験」だけで設計するのはやめようよ
2.フレームワークにより技術者同士の意思疎通の円滑化
3.デザインパターン的な「同じ土俵」での議論(「ストラテジーパターンね」的ノリ)
4.「あさっての方向」的発想の排除
5.物理現象を伴うモデリング→パターン適用というトップダウン的開発手法の普及
ちなみにアルトシュラーおじさんが250万件の特許を調査したのはかなり古い時代とのことで、基本的にTRIZは、
物理現象を伴う発明(問題解決)
に焦点を当てています。
そのため、自然科学と多少切り離された「ソフトウェア」の発明(問題解決)には、あまり効果がなさそうです。
(ソフトウェアに適用した事例もあるそうですが・・・)
つまり、メーカ系で言うと「メカ屋さん」「電気屋さん」「化学屋さん」などが利用することが前提のようです。
逆にソフト屋さんは、ソフト屋さんとしてTRIZのようなフレームワークがたくさんあるので、
無理に使う必要はないかも
というのが正直な感想です。
マトリクスから「技術的ヒント」を導き出すという点と、モデリングからパターン適用の時にデータマイニングのような事をするらしいのですが、その辺りが参考になりそうです。
あと「特許書き」の時には威力を発揮しそうなんですよね〜。
逆にモデリングの表記方法が曖昧だったり、先程の「どのフレームワークを利用して分析をするか」という明確なアクティビティの定義といった部分に関しては、UMLを導入した方が良いのではと思っちゃいます。
Fe+的にはフレームワーク思考というアプローチは嫌いではないので、なかなか勉強になりましたが、TRIZは強力なツールに「化けるポテンシャル」は秘めているのですが、
かなり発展途上で体系化されていない感
が強いというのが正直な感想です。
フレームワークとは「考え方の方向付け」だと思うので、このような手法により、「技術レベルの底上げ」を行い、エンジニア同士で「共通語(認識)」を持ち、意思疎通を円滑にすることは非常に良いことでしょう。
Fe+的に研究対象として今後、TRIZもウォッチしていきたいなと思う今日この頃でした。
ちなみにTRIZの教科書の冒頭には、
マインドマップ
もしっかり登場します。
利用方法はJUDEでの提案と同じですね。
やはり、マインドマップ最高です!
トニーブザン大先生には本当に感謝しなくては。
マインドマップの放射思考は大脳生理学の研究で明らかになった、人間の記憶システムと同じであるという科学的根拠があります。
この話については、いずれ詳しく書きたいと思います。
(以前から温めているネタなんで)
つまり、どのような「論理思考」を行うにしても、
全ての「論理思考」の原点となる
という事が素晴らしいんです。
なんだか最後にはマインドマップ絶賛ネタになってしまいました。[:にこネコ:]
posted at 2005/05/13 1:31:48
lastupdate at 2005/05/13 1:40:24
【修正】
Comments
Post your Comment
Menu
Category
Pageview Ranking
Search
Link