PAGE TOP

関連情報

印刷する

「具体と抽象」という本を読みました

さぼ郎
具体と抽象」という本を図書館から借りて読みました。自分的には得るものがほとんどありませんでしたが、それはひとえに抽象化能力が欠如しているからのようです。

img01

抽象」の対義語として「具象」「具体」があります。

ネットで調べたら「具象」「具体」の他に「具現」を対義語としている記述もありましたが、これは明らかな間違いのような気がします。

リアルな仕事の世界では「抽象」化した表現をすることは、きっとタブーで、「抽象」とは「あいまい」「意味不明」「不明瞭」「空想」「絵空事」のように捉えられることが一般です。

しかし、本では抽象化能力があることで、世界の見え方が大きく変わってくるとまで言い切っています。

似ているもの、共通の特徴点取り出して「ラベル」化して表すことを抽象化といえば良さそうです。

例えば、鮭やまぐろ、ブリなどを「」といえば、それはそれで肉や野菜と違うという意味で通じるわけで、鮒でも鯉でも「」になるわけで、個々の具体的な魚の抽象的概念の呼称になるわけです。

img02

かといって、「」という個体は実在しないわけです。

そもそも、事実・実態に対して「言語」そのものが、すでに「抽象化」されており、著者は人間の「抽象化能力の賜物」が言語ということになります。

「山」といえば、個々の実在する山でなくても、誰でも「山」という言語からくるイメージは共有することができます。

つまり、抽象化するということは特徴を取り出すこと。事象の汎用性を高めることで、少ないリソースで効率を上げることも可能となっていきます。

しかし、会話の抽象レベルと具体レベルが噛み合っていないと、せっかくの抽象化が伝わらず、かえって相手を混乱させたり誤解されたりしてしまいます。

img03

と、このような話が続いていきますが、読み始めたから最後まで読みましたが、読みながら考えていたことがあります。

それは前田裕二という人の「メモの魔力」という本です。

img04

このヒトは自他ともに認めるメモ魔なのだそうですが、なぜ、メモを取るかとおいうと、メモとしてまず、事実を列記していく。書き出した事実を、まとまり単位でキーワードをつけていく。

次に、それらの事実を抽象化して普遍的な性質を見つける努力をする。抽象化ができたら、それを転用できないか徹底的に考える。

まとめると、事実から抽象化をし、汎用性・普遍性が見つかったら、そこからひねりを入れて「転用」できないかを考え、そこにビジネスチャンスを見つけるのだそうです。

そのツールは「なぜ?」か「どのようにして?」を徹底的に考えることで「転用」へのヒントが生まれることから、メモがアイデアを生み、ビジネスに繋がるといいます。

img05

ちょっと視点を変えます。

抽象化というと、かつてC言語でプログラムを書いていた時代のことですが、何かをさせるために「関数(function)」を作りますが、その関数の汎用性を高めると、似た種類の処理に同じ関数が使えるようになります。

しかし、一般的には引数として渡す変数は具体的なことが一般です。整数、実数、ストラクチャー、配列、文字列などと具体的な値を引数として関数に渡すことで関数が処理をして結果を出すのが一般です。

COBOLもfortranも、そのような具体的な値を渡すことで、具体的な処理をするというのがプログラムの一般でしたが、C言語が登場することで、変化が起きました。

それが「ポインタ」という考え方です。「ポインタ」とは、かいつまめばアドレスのことです。今のパソコンは64ビットが普通になっていますが、64ビットパソコンの整数は「18,446,744,073,709,600,000」というとほうもない値になります。

img06

もし、メモリを実装してさえいれば、これだけのメモリ空間を自在に使うことができるわけです。ちなみに32ビットだと「4,294,967,296」という値で、通常4Gといわれる大きさでしかありません。

つまり、4Gバイト以上のメモリ空間を使うことができません。メモリの実装料を16Gだろうが32Gだろうが、4Gバイト以上のメモリ空間を使うためには64ビットのOSにする必要があります。

このメモリ空間の特定のアドレスを使って処理をするのが「ポインタになります。そもそも「変数」とはアドレスにつけたラベルに過ぎません。通常は変数、あるいは配列として固定的にメモリを確保するわけですが、ポインタを使えば、必要に応じたメモリ空間の確保が可能になりますが、動的にパソコンが確保するメモリのアドレスを自前で管理しなくてはならなくなります。

そこで「ポインタ」という形式の変数を使うわけです。

変数が「具体」「固定」であるなら、「ポインタ」は「抽象」「動的」と言えそうです。メモリ空間の効率的使用という効率性の側面がありますが、それ以上のメリットもありますが、話が抽象的になるのでここらでやめます。

一つ言えることは、関数の抽象化が進むほどに、利用範囲が広がると同時に、ともすれば使い方をつねに意識しておかなければならなくなります。要するに何をする関数なのかが分かりにくくなるという、具体性を読み解きにくくなる「諸刃の剣」状態になっていきます。

これって、抽象の最大のメリットであると同時に最大のデメリットでもあると思います。

よって、抽象化できたら、即座に「転用」という具体策を考案するというのは、とても理にかなっていると思います。抽象的解決で終わりにできるのは哲学とか芸術では有りなのでしょうけれど実用場面では、必ず「具体」化しなければビジネスにはなりません。

小説でも、テレビドラマでも、あるいは広告宣伝のキャッチコピーでも「いい!」と思ったら「なぜ?」あるいは「どのようにしているのか?」と考え、その理由を列記してみる。

img06

そこから自分のビジネスへの転用を考えることで、日々流れていく時間の中で思考という抽象化能力を存分に活かせることから鉱脈を掘り当てられるかもしれません。

キーワード