抽象化の技術
@ITの記事に触発されて、抽象化の技術について一稿。
この記事にもあるとおり、エンジニアはもとよりエンジニアではない人
にとっても、抽象化は重要なスキルであると思います。しかし周囲を見
渡しても、意外とこの技術を身に付けている人は少ないようにも感じま
す。
相手が抽象化して物事を考えることができるかできないかは、会話して
みるとわかります。抽象化できない人は自分から抽象化した話をするこ
とはありませんし、相手が抽象化した話題をすると話を理解することが
できません。
抽象の世界では、これまで違うと思っていたものが実は同じであったり、
一見同じに見えるものが、その本質は違うものであったり、というよう
なことがおこります。これは抽象の世界に来なければわからないので、
相手が具象の世界にとどまっていると会話が成りたたないのです。
例えば相手に何かを説明する際、比喩を使います。比喩は相手が知らな
い事象を説明する際に、相手の知っている別の事象を提示し、それと同
じであることを説明することで相手の理解を促す方法です。これは、知
っていることとし知らないことの具象の世界では別の事象を、抽象化し
関係づけることで、成り立ちます。したがって、相手が抽象化のスキル
を持っていなければ比喩は役にたちません。
以前、ITエンジニアに会計の説明をする際、「仕訳はアーカイブログみ
たいなものだ(正しくはREDOログ)」という説明をしてみたことがあ
ります。ITエンジニアの知っているDBのログの仕組みと、知らない会計
の世界での記録の仕組みが似ているので比喩として持ち出してみたので
すが、あまりうまくいった感じはしませんでした。
このとき気が付いたのですが、比喩を使った説明が上手くいかない主な
原因は、以下の3つが考えられます。
1.比喩そのものの出来が悪い(例えになっていない)
2.相手が知っていると思って例えに持ち出した事象を、実は相手が知
らなかった
3.相手が抽象の世界にいけない(抽象化のスキルがない)
特に気をつけないといけないのは③です。比喩を使った説明に相手の反
応が悪かった場合、こちらは①か②だと思ってしい別の比喩で説明しな
おしてしまいます。その反応も悪ければ、また他の例えで、と当たるま
で繰り返してしまいがちです。原因が本当に①か②だとそのうち当たる
こともあるのですが(複数の比喩をもって本質をつかむこともある)、
じつは③に原因があると最悪。相手は全然関係ない事象を次から次と持
ち出されて、ただただ混乱してしまいます。
そもそも抽象化のスキルとはどういったものなのでしょうか。
それは、抽象の世界と具象の世界を自由に行き来できるスキルだと考え
ています。Googleマップみたいなものです(懲りずに比喩を出してみ
る)。Googleマップの移動は平面上の左右前後の動きに加えて、上下
(ズーム/視点高度)の移動が可能です。ズームのスライダーを一番上に
すると地図は大きくなり見える範囲は狭くなりますが、建物や道の一つ
一つが見えるようになります。これが具象の世界。このスライダを少し
ずつ下げてゆくと、建物や道はだんだん見えなくなり代わりに地形や国
の形が見えるようになります。これが抽象の世界。ストリートビューで
東京から北海道に向かおうとすると大変ですが、ズームを下げると、東
京と北海道は一つの画面に収まり移動が楽になります。皆さんはこの前
後左右とズームをうまく使って、地理を理解するのだと思います。これ
が抽象化のスキル。
このGoogleマップの比喩で抽象化のスキルを考えてみると、大きな二つ
の示唆を見つけることができます。
1.抽象度にはレベルがある
2.抽象度には方向性がある
1については当たり前のことかもしれませんが、Googleマップでズーム
のスライダーを動かすと、そのメモリに応じて縮尺が変わります。見え
ている範囲で縮尺は同じでないといけません。地図の右端ではビルが見
ていますが、左端では九州と九州がまるっと見える、ということはあり
ありえないのです。Googleマップでは当たり前の話ですが、実際はこの
抽象度のレベルをずらして議論している場面によく出くわします。例え
ば会社レベルの話をしているのに人類では、などと持ち出してくる人な
ど。
2については少しわかりづらいかもしれません。イメージとしては東京
でズームを下げていった人と、例え同じメモリまでズームを下げたとし
てもサンパウロで行った人では同じ光景は見えない、という状況です。
別の事例で考えてみます。
よくオブジェクト指向の教科書の例題として以下のようなものを見かけ
ます。
例 題「ネコ、人、机、ハシゴ。クラスを作りなさい」
回答例「哺乳類クラス:ネコ、人。道具クラス:机、ハシゴ」
クラスは抽象データ型です。実在物を見比べて、その性質(データと振
る舞い)が似ているもの集めて共通の性質をクラスとして定義します。
一見、ネコと人は生物なので、机とハシゴの道具とは違う感じはします。
しかし実際のシステム設計の中では、哺乳類クラスと道具クラスなどを
定義するシチュエーションはほとんどありません。哺乳類と道具が出て
くるシステムなんて、どんなシステムやねん!
システム設計の立場からすると例題への回答はただ一つ、「無理です」。
例えばホームセンターのシステム設計をする際には、
商品クラス:ネコ、机、ハシゴ
顧客クラス:人
としてクラスを定義するかもしれませんし、もしくはドローツールを設
計する際には人とハシゴを二本足のオブジェクト、ネコと机を四本足の
オブジェクトと形状で分類する方が現実的でしょう。要は何のシステム
を作るかによってクラス定義の仕方は変わるということです。言い換え
ると抽象化するには、その目的もしくは抽象化の方向が必要になるとい
うことです。もしかすると抽象化とは方向と量をもったベクトルである、
といえるのかもしれません。
少々長くなってしまったので話を戻して。
あらためて抽象化のスキルとは何かというと、
「具象の世界の物や事象を、目的(方向)とレベル(量)をあわせて抽
象化し、抽象の世界で得られた新しい気付きや発見を、また具象の世
界に戻して応用するスキル」
ということ。
それは言い換えるならば自分の認識す世界が広がる、ということでもあ
るので、とても大切なスキルだと考えています。
最新の投稿
コメント
hiro
わかりやすかったです。ありがとうございました。
山無駄
どうも hiro さん
あざーす