で、今回はプログラミングの上級者が備えてると個人的に考えてる抽象的思考とアナロジー思考ですが、色々本に投げちゃいます。
前々からプログラミングは地頭の良さで差が出て、IQ高い人ほど学習が早いようなことを書いていましたが、「抽象的思考」と「アナロジー思考」という表現のツールを手に入れて、やっと少し言語化ができそう。IQの高い人＝抽象的思考・アナロジー思考が得意な人とも思えていて、IQは考え方で伸びるものだと思っています。この記事があなたの思考を加速させられれば幸いです。
プログラミング学習を加速させる抽象的思考
まず、抽象的思考です。日本人が苦手なやつです。
抽象的思考周りで読むと良さそうな本はこの辺とか。
谷川さんは東大らしいなぁ、という感じです。本人も抽象化は得意だけど、具体化はあまり得意でないようなことを言ってて、少し例えに違和感感じたりします。抽象化からイノベーションに繋がる考え方になってるけど、個人的にはもう1段階あって、ただの具体化は抽象化した知識を個別案件に当てはめてるだけで、イノベーションに繋げるにはアナロジー思考が必要だと思います。つまり、抽象化した場合に近い構図になる完全に別の事象に対して、そのスキームを当てはめて新しい発想を作る、という発想の転換が必要になります。賢さは抽象化と具体化を行き来することで磨かれるような感じの話で、抽象/具体はピラミッドで書かれる事が多いけど、横に倒した方がわかりやすいという主張がありますが、個人的には上下の方がわかりやすい。なぜなら、抽象化は情報の圧縮(大事な共有化できる部分だけを抜いてモデル化するので→抽象化に失敗すると大事な部分が漏れて曖昧なだけになる)なので、上に行くほど小さくなって具体に降りるにつれて裾野が太くなるのはピラミッドのイメージ通りです。この辺の例の出し方はアナロジー思考です。また、谷川さん自身が具体から抽象を抜き出すのが得意な人のせいか、左右にしても正の方向、進んだ結果の向きに抽象を置いています。個人的には抽象は土台なので、0の位置に抽象があって、先に進んだところに具体が合った方がイメージに合う気がします。ちょっと思考を言語化するツール(概念)が足りてないように感じました。
後はこの辺も。
抽象化して学ぶということ
抽象化というのは結局の所、大事な部分だけを取り出してモデル化するということです。モデル化できると、同じモデルが適用できる場合は既に知っていることの流用なので、改めて学ぶ必要は有りません。抽象化して学習できる人は、類似したケースを転移学習でショートカットできるわけです。フレームワークとかは抽象化したものの枠組みだけを具体化してるというか、大事な部分を抜いて典型的な処理で初期化してるようなイメージです。なので、フレームワークを抽象的に理解できれば、色んなプロジェクトで応用するのは簡単です。どのフレームワークが適切かの判断は後述のアナロジー思考が関わってきます。
抽象化して学習するのが下手な人は、毎回が個別案件で類似していても1から学び直すことになります。そりゃ、効率悪いし時間がかかりますね。また、個別で考えると、重要な部分だけ抜き出すより情報量が多いので忘れやすく、知識の分断が起きて、ところどころしか理解できていない、憶えていない状態になります。
前述の通り、正しい抽象化は情報の圧縮(抽象化の得意さによって圧縮率変わるかも)なので、記憶に使う領域も少なくて済むし、良い事づくしです。物覚えがよく、なんでも記憶してるように感じる、前に会議で話したことはほとんど覚えてる上司がいましたが、会議の内容を無意識に要約して少ないスペースで重要な点のみを記憶に残していたのだと思います。彼は情報を抽象化して出し入れする天才だったのでしょう。
また、プログラミングの独学で本を読んで、「全然わからない、無理。」と諦める人もいますが、初学者に言いたいのは、あなたは学生時代、学校の授業で初見で全部理解できたのか、と。書いてあることの全部がわかるわけないんですよ。最後まで読んで、やることやって、読み直して。5年後に読み直したら全然理解が違ったりもします。わからないことをもやっと理解する。構造だけをなんとなく抽出して理解した気になる。それも抽象化だと思っています。ただ、この場合は圧縮率が低いというか、重要な点が漏れてたりしますが、先に進むにつれて霧が晴れてきて解ることが増える。学生時代ってそうだったんじゃないですか？大学だと次の学期の内容をやってる途中に、前の学期で言ってたあれって、そういうことだったのか！という経験はあったのでは？ちなみに、僕はDigital Image Processingの授業で、これは101の内容だ、と言われてんのに、宇宙語か？というところから入りました。Theory of Computationもきつかった。最初はわからなくて当たり前です。霧の中で、それでも何かの形を見出して、霧が晴れた時の快感が知識欲という知の道につながってるんだと思います。CSはそれを何度も感じられる素晴らしい道だと思う。
変数の例
プログラミングの学習というのは、最初は手を動かす事が多いです。簡単な課題を作ってみたり。そんな簡単な、レールを敷かれた簡単な課題でも、学習には差が出るものです。学習が早い人が何をやってるかと言うと、「情報の抽象化」です。特に学習が早い人は、抽象化するときの抽象度を適切に扱えます。例えば、nという変数をnumに変更した場合にどう全体のコードが変わるか勝手に試したり、データベースに勝手にカラムを追加してみたり、ということを試して、ここが変わると、ここに影響があるのか、ということから変数の概念を学んだりします。また、%を使うと0~nの数字を取れる、と理解してグループ化に使える！と考えたりします。抽象化して学習をストックしていくと、似たようなケースでそれを使えます。考える習慣がある人は、「なんで、変数名がこれなんだ？ああ、これじゃなくてもいいのね」、と気付けたりする。
抽象化出来てない人は、変数がnからaに変わると何をしていいかわからなくなったりします。変数自体が、データの置き場に名前を付けてる、と抽象的に解ると、他の変数名になっても、名前に紐付けてデータが取れるんだ、となりますが、 ただ写経してる人はnをaに変えられてもnを使ったり、型が変わっても気にせずエラー出したり、文字列にcntみたいな名前を付けたりします。名前というのは具体化の極みなわけで。
実際にプログラミングを教えてる時にあった話で、変数の宣言で変数名のnをaに変えたら、他の箇所はどう修正する必要があるか？と聞いて全くわからなくなってしまう人がいました。これは変数をnと宣言した個別事例だけに目が向いていて、視線が近すぎるから起きたと思います。個別の変数の宣言・利用でなく、変数という概念を理解すると簡単に使えるようになるので、学習として理解するべきレイヤーが違うという話です。逆に抽象に目が行ってる例では、子供が「年配者」を「おじさん」と憶えたら、おばちゃんをおじさんと呼んでしまうような感じで、一個上の抽象的な事象に具体的な名前を紐付けたり、ということが起きえます。
データの持ち方
C言語を最初に学ぶと良いと言われたりするのは、ポインタという概念を学べるわけで、個人的にはメモリでのデータの持ち方がわかってればC言語学ばなくてもいいとは思います。大学1年生がCS概論で学ぶ話です。抽象的な概念を先に学んでいるので、抽象化が下手な人は具体的なコードとの繋がりが理解できない。Cでポインタと普通の変数の違いが、スタックとヒープというレベルで理解出来てると、他の言語でデータを持たせた時もどっちにデータがあるかイメージが付いたりします。また、データ構造を理解出来ていれば、言語ごとに違っていても中での処理がだいたいわかるし、どういう時にどの構造を使うべきかの判断も簡単です。CSの授業が実務に役立たないと言う人は抽象的な学びができてないから、コードの裏の動きがイメージ出来ていないと思います。役に立たないと言う人のいる、自分で実装の必要がないCSの基礎を世界のトップ企業が軒並み求めてくるのは何故だと思いますか？基本的に座学で習うのは抽象化された概念で、課題で具体化して学びを定着させます。理論(抽象)と実践(実装)が一致すると知識は頭に根付いて定着します。
アルゴリズム
アルゴリズムはCSの授業でも、技術書でも擬似コードで書かれていることが多いです。これは処理の抽象化ですね。抽象的な処理の手順が理解できれば、自分の使いたい言語に翻訳(具体化)するのは簡単です。逆に言うと、難しめの問題を解く場合は、まず抽象化して、言語に依らない本質的な解法を定義し(かなりの場合、帰納的になる)、制約を満たせることを確認してから実装するのが正しい手順だと思います。自明な問題はサクッと書いちゃいますが。一部のプログラミングスクールで誤解されてたりしますが、アルゴリズムという領域はモデル化がベースになっていて、個別の問題の解き方の手順を考えることでなく、抽象化されたモデルを解く方法を考えることで、多くのモデルを理解し、使いこなせると、個別ケースがそのモデルに当てはまると判断したら、モデルに紐づく手順(アルゴリズム)で問題解決ができるというわけです。
インターフェース設計
インターフェースの定義も抽象化です。そのままですが。大事な共通した処理を抜き出してインターフェースとして定義します。抽象化の粒度があっていれば無駄のない設計になります。抽象化の粒度が正しくないと、抽象メソッドの引数が実装クラスによって必要だったり要らなかった、そもそも抽象メソッド要らんねん、という実装クラスが出てきます。そういう場合は中間に抽象クラスを足して分岐させるわけですが、この辺の判断にも抽象的思考が必要です。若干、ここは学びとずれるかもですが。
障害対応
障害対応の学びでも、抽象化した方が効率的です。開発環境で問題なかったのに、本番環境で速度が遅い場合、DB周りやネットワーク周りが原因の事が多い、という大雑把な当たりの付け方は個別事例を1つずつ当たるより明らかに効率的です。何段階か抽象度を持って、徐々に絞り込めると対応は早くなるし、学びとしても早いと思います。
抽象的思考力を付けるためには
Anyways, 抽象的思考の身につけ方は谷川さんも書いていますが、「読書の要約」が有効です。論点のみを抜き出して短くまとめるのは抽象化です。具体例は基本的に要約に入ってこないのが普通だと思います。アメリカでOSの授業で教科書の指定の章を、DBの授業で論文を毎回要約して授業前に提出する課題がありましたが、この辺は理解の確認には良いでしょう。プログラミング教室で読書の課題を出すなら、1パラグラフで要約(300文字以内とか)という提出物を付けると理解がわかります。アメリカはパラフレーズ(言い換え)の文化があるので、たいてい教科書そのままじゃなく、自分の言葉に変換して書くのでかなり知識定着しやすいです。論文の最初にAbstructの項目がありますが、これはまさに論文自体の重要な点のみを抜き出して圧縮、抽象化したものです。子供にもできることなので、数学もできないうちからプログラミングスクールに通わせるより、読書をさせて、章ごとに要約書く習慣を付けさせたほうがよっぽどプログラマーとしての資質を磨けると思います。
あとは、究極の抽象化は数学です。公式を導く過程はたいてい抽象化した上で解いて一般化します。理系がプログラミングが得意なのは、抽象化して学習する数学の習慣が身についてる部分が大きいと思います。公式も丸暗記は意味がなく、公式を導く手順や過程を理解すると、忘れることも少ないし、忘れても自分でたどり着けます。数学を公式の暗記で解いていた人は抽象的な学習は苦手かも知れないので、線形代数辺りからやり直してみてはいかがでしょうか？
線形代数は下記の本がお薦めです。かなりわかりやすいので、これを読んだ後に演習をいっぱい解いたりすると、一見適用出来なそうな問題に公式を適用する、という部分でアナロジー思考ができると思います。
また、過去に↓こんな記事を書いてましたが、これは日常でできる抽象化の訓練ですね。何故を習慣にすると、愚かだと思われるような、気づかずにしてしまう行動が減ると思います。
谷川さんの本でもトヨタ式「5回のなぜ」の話がありますが、なぜを考えるごとに、思考は抽象化されて問題が1つ上のレイヤーに遡って、新しい分岐や問題の出どころがわかったりするようです。普通にやってました。5回はしてないかもだけど。歩きスマホは今すぐ止めて、周りの気になったこと、自分の感情を揺さぶるもの、違和感の何故を考えると抽象的な考え方が磨かれるのでは、と思います。
https://news.yahoo.co.jp/articles/64382195dab534eb3378990e048381cdc64ffbd3
抽象化の悪い例
最近の自治体の対応で悪い例がでてきたので、ついでに紹介です。小池都知事と大村愛知県知事がカラオケに営業時間の短縮要請を出しましたが、実際のところカラオケボックス(専門店)でクラスターは起きていません。自粛警察が暴走しそうな、パチンコと同じ完全なミスリードの事例です。
http://www.jkba.or.jp/uploads/news/62093dc9ab4d37b4c4dd30d813f210fc.pdf
https://news.yahoo.co.jp/articles/b91f094fc90708715c557b450e32abec9e109b0f
8/1の千葉の例では「カラオケ店」と書いている記事もありますが、他の記事を見ると、これも北海道と同じで「昼カラオケ」らしく、要は昼から開いてるカラオケ喫茶とかたいていがスナックの昼営業でのカラオケです。そもそも「昼カラ」という言葉は完全に命名が最悪でカラオケ業界からすると風評被害以外の何でもないわけで、その上に自治体の長が名指ししており、業界の感染症対策を台無しにする行為です。千葉のクラスターで「カラオケ店」と書いてる共同通信の記事なんて、誤報道のレベルです。複数グループが同じ部屋に、とか書いてあって、そんなカラオケ店あるかよ、という。愛知県では、「酒類の提供があるカラオケ店」という謎の表現ですが、20時以降の制限なので、もはや何を対象にしてるのかよくわかりません。カラオケボックスは20時以降種類の提供を止めればよいだけの話でしょうが、自粛警察が発動しそうですね。
なぜ、これが抽象化の間違いかと言うと、確かに大声で歌うのは感染リスクが高い行為かも知れません。しかし、構造をちゃんと考えると、カラオケボックスでクラスターが起きずにスナックで起きる理由はわかります。自分の想像(Google画像検索で出るのもそんな感じ)ですが、カラオケ喫茶とかスナックでのカラオケというのは、ステージ的な歌う場所がお客さん側を向いており、視界に小型モニターが入る状態で客席に向かって歌う構図です。こういう配置のカラオケボックスはあまりない(たまに大人数向けパーティルームであるけど、今は配置変えてそう)し、複数グループが同じ部屋に入ることはありません。この構図で分類するなら、スナックでのカラオケはカラオケボックスでなく、ライブハウスと似た構図と言えるでしょう。ライブハウスではクラスターが起きています。
つまり、多くの人の方に向かって大声で歌うことが問題ということです。舞台やライブで声を出す人は腹式呼吸でお腹から発生しているので、かなり指向性を持って飛沫は遠くまで飛んでそうです。カラオケボックスで歌詞を完全に覚えてる人は殆どいない(腹式呼吸も少なそう)ので、歌う人は前面の画面に向かって歌詞を見ながら歌うでしょうし、聞く側も基本的に画面を向くでしょう。大声になるほど、飛沫は前方への勢いが強くなるので、大きい飛沫が直接他者に入るとしたら、画面との間に人が座って歌ってる人に向いている状態です。また利用後に消毒を徹底して、ドアを開けて一定時間置いてるところも多く、JOYSOUNDではマスクをしたままでも歌えるノイズ除去のエフェクト機能まで出ています。マスク無しじゃないと歌えない、なんて自然法則はないのです。そして、喉や肺に少しでも症状がある時にカラオケボックスに行く人はほとんどいないし、歌わないでしょう。飲みに行ったついでに歌を勧められるスナックと歌をメインに行くカラオケボックスは全く別物です。また、昼カラオケの報道を見ると年配(60代以上)の方が多く、感染すると表面化しやすいのでしょう。逆に言うと、「カラオケで感染」「60代以降中心」となると、スナック(カラオケ喫茶)でしょ？と記事をちゃんと読まないと勘違いします。情報を抽象化してストックしておくと、判断が早くなるのはアナロジー思考で取り上げますが。
おそらく自治体や専門家委員会では昼カラであったようにカラオケはクラスターが起きやすい、という先入観で、カラオケボックスをライブハウスや演劇の劇場と同じ区分にしており、抽象化に失敗して間違った構図に対する対応をしてることになります。
更に言うと1人カラオケなら入れ替え時の消毒・換気をしっかりやれば感染リスクは低いと言えるでしょう。感染症対策をしっかりやっている感染リスクの高い遊びと感染症対策がずさんな感染リスクの低めの遊びだと後者の方が危険な気がします。
問題の本質としては、大人数で、特にグループをまたがった範囲で飛沫が直接かかる、もしくは排気性の低い状態複数グループが長時間で過ごすのは避けるべきということで、カラオケボックスや飲食店に制限をするなら、4人以上もしくは複数人での2時間以上の利用を制限というのが妥当では？と思います。グループ内では感染る可能性は高いですが、グループを跨いでいない以上、更にグループを分割することで範囲を狭められます。抽象化に失敗すると、そこから導かれる結果が全く見当違いになる良い例だと思います。パチンコは嫌いですが、構造的には思い込みでの勘違い(実際は対面で飛沫を飛ばし合わない/排気性が高いで感染リスクはさほど高くない)で、同じ轍をまた踏もうとしてるように思えます。首都圏のみのカラ鉄は崖っぷちですが、倒産したら都の責任と言って良いでしょう。
そもそも、都の22〜5時に感染リスクが高いエビデンスがよくわからない。若者とか、飲食店駄目なら、より狭い誰かの部屋で宅飲みするだけで感染リスク上がりそうですが。小池都知事が何も考えてないのがわかってしまったのが、お酒を飲んで気持ちよくなって大きな声を…というようなことを言ってたことです。僕はなんで飲み会で声が枯れるんだろう？声が大きくなるんだろう？と観察したことがありますが、簡単な話で、皆が話して周りの騒音レベルが上がっているため、また逆位相での打ち消しもありうるので声が大きくなると思います。会食、つまり飲み会での会話は実際は2〜4人位ずつで話してる事が多く、隣や対面に向かって大声を出すことになります。これがリスクが高いのは当たり前です。ちゃんと考えているのが京都府で、5人以上を禁止するのは妥当だと思います。3人組で2人で話すと1人あぶれるので3人で話すでしょう。4人だと2−2にもなりえますが、全体で話す時間の方が長い印象があります。5人くらいからは同時に2組話したりして、声が大きくなっていくと思います。4人以上を禁止がベストな気もしますが、テーブルが4人掛けと考えると妥当と言えそうです。
スナックでのカラオケではまだクラスター発生しているので、カラオケボックス(専門店)以外でのカラオケ利用に自粛を要請して、リース代を負担する方がよほど筋がいいです。最近の大きめの自治体の対策で芯を喰ってそうなのは僕が知る中では(そこまで積極的に情報収集していませんが)京都府くらいで、言わば、大きな地震が起きえない地盤のところ(プレート的に)に最高級の耐震工事を要求しているようなバカみたいな話。カラオケなんて、大きいところのチェーンがほとんどなんだから、専門店以外での利用を止めて、専門店は徹底した感染対策を確認、指導した方が、業界の努力に報いる話だと思います。今の対応は風評被害の傷口に塩を塗っているだけ。感染リスクの高い業界ながら、クラスターをほぼ完璧に封じ込めてるカラオケ業界は称賛されるべきであっても避難されるべきではない。現時点では。
[2020/08/06追記]
何故か自粛要請のタイミングから突然カラオケ感染報道が増えてますが、千葉とかはほとんどカラオケ喫茶ですね。「カラオケを伴う飲食店」ってなんですかね。また、唯一カラオケボックスと思われる東京のカラオケ6人ですが、これがカラオケ目的に集まった6人なのか、飲み会後にカラオケに流れたものなのかも不明です(この時世でカラオケのみに6人集まるのは不自然)。飲食店での会食で感染するのであれば、カラオケでも感染するでしょう。コンボなら確率はかなり高いのでは？カラオケに限らず、個室に感染者を含めて6人入ってみんなが声を出せば、カラオケに限らず何をしても(麻雀とかゲームでも)感染するでしょう。まぁ、店側もなるべく6人来ても3人3人に分けるとか20人パーティルームに入れたほうが良いと思うけど。マイクを1人1本になるのがベスト＝2人ずつ？と思います。流石に、カラオケ擁護派でも6人で来て1部屋に入れるのはどうかと…。人が増えるほどに感染者が混ざる確率は上がるので、感染りやすくなるのは当たり前です(1/10が感染してるとして誰も感染していない確率は(9/10)^Nで1人いると全体に感染る可能性がある)。クラスターとして問題になるのは複数グループをまたがっての感染であり、カラオケかどうかに関わらず濃厚接触して遊んでいたグループに感染者がいたら何をしても感染る可能性が高いというです。カラオケで問題になるとしたら、次に入ったグループや店員を介して他のグループにも感染することです。それをカラオケを強調して報道するよう発表するのは自治体が勘違いの圧力を正当化したいように思えて仕方ないですね。最近思うのはグループを跨いで感染する可能性のある屋内の広い空間と個室だと、感染者が増えているフェーズでは個室の方が拡大防止になる気がします。店員がミツバチ(グループ間で運ぶ人)にならない前提ですが。
そして千葉も休業要請やらかすみたいでが、肝はそこじゃなくて、何をして遊ぶより、4人以上を防ぐ方が大事で、カラオケを休業させても集まって他の遊びしたら変わらないと思います。カラオケの代わりはやっぱり宅飲みになりそうだよなぁ。
その上で言いますが、カラオケで別に部屋に感染が広がったり、同じ部屋で次のグループが感染したりが複数発生した時、自治体がもし休業要請したりするなら、そのタイミングです。そうなったら人数関係ないです。カラオケは特に店員の部屋への出入りの時間も短く(歌の邪魔しないように)、部屋間の飛び火はしにくいと思ってますが、それが起きたらヒトカラでも危険。現段階でもカラオケ喫茶はカラオケ機器の利用を休止させる(リース会社にも請求止めさせる)か壁に向かって歌わせるとかはした方がよくて、カラオケボックスはまだ規制の対象になる段階ではない、という認識です。現状、部屋を跨いでいないので、2〜3人で楽しんでる分にはその2〜3人の間でしか感染らない場所ということです。カラオケボックスで1件出てほら見ろ、と言っても会食の飲み屋やホームパーティ、ジムなど他の特定施設で何十倍も発生しているので何言ってるのという話です。ジムやライブハウス、舞台など、面識の無いグループをまたがって感染してる場所とは完全に別次元です。感染しやすいように思える業種でこれだけ少ないって逆にすごくないか、という話で。報道でバイアスかかりまくってるので、「ほらカラオケで出たよ」という思考に誘導されると思いますが。もはや自治体の長はカラオケ喫茶とかカラオケバーの事例が出過ぎでパニック状態で、それがカラオケボックス寄りでなく、ライブハウスと同じ枠組みだと考えようとせず、視野狭窄に陥って要請している状態に見えます。パチンコの時とまるで同じです。
また、カラオケ問わず、感染がほぼ無くなるまで、自分は4〜5人以上で遊ぶのは止めた方が良いと思っています。何しても遊ぶ＝会話するなので感染る可能性はかなり高くなります。自分は遊ぶにしても、基本的に2人でという生活してます。
なんか、追記で若干矛盾してしまった気がしますが、
- カラオケ喫茶(スナック昼営業)はライブハウスと同じ構図
- カラオケボックス自体はライブハウスとかと比べると明らかに感染リスクは低めと思われる
- 会食で感染るような遊び方をする人達はカラオケボックスに限らず何をしても感染る
- カラオケボックスでの感染が同じグループ内で留まっている内は危険とは判断できない
留まっている内というのは感染者が増えて、本当に無症状の感染者(肺や喉といった感染箇所は本気で歌うには負担がかかるので通常カラオケだけ目的に参加しない)も歌いに来てる状態になると、要は感染者が半分の部屋にいるような状態だとヒトカラでも感染る可能性あるかもね、ということです。感染が出た瞬間に危険な遊びになるわけでなくフェーズの問題。遊びに来る人に含む割合が増えると危険なのは間違いないです。
まぁ、そもそも論として、6月以降、検査が増えて感染者数倍増してるのに死亡者や重傷者が全然増えない辺り、僕らが戦っている相手は恐怖が肥大化させたハリボテな可能性はありますが。何回もかかるみたいだし、「かからないこと」を最優先に規制かけたりするより、「かかったら危険な人を守って通常の生活に近づける」フェーズなのかと。高齢者や特定疾患を持ってる人を守れる社会づくりの方がウィズ、もしくはアフターコロナで重要になってくる気がします。
この項目いるのか、という気になりつつもあります。まぁ、自治体の対策が状況の分析の過程の抽象化を誤って違う構造の問題を紐付けて対策を打っている、という例ということで。問題や前提を取り違えると答えには基本的にたどり着けません。例えば処理速度を早くしたいのにリファクタでコードを短くしてもほとんど意味がないように。
学習を活かすためのアナロジー思考
アナロジーとは要は類推です。アナロジーに関して学ぶにはこの辺の本があります。
アナロジー思考と抽象化思考は被ってる部分もあるように感じられ、分類が難しいところもあります。
アナロジーに関してはストックした抽象化のモデルの枠組みに合いそうなものを持ってきて、未知のものを既知のスキームに乗せます。正しく乗せないと機能しないわけで、フレームワークの選定や、効果的なアルゴリズムの利用、データ構造の選択などもここに入ります。アナロジー思考と抽象的思考が結びつくと、抽象化した学習をそのまま早く出す、判断力だけでなく、一段飛ばしのアイデア、イノベーションにも結びつきます。
類推というのは、情報の圧縮を解く鍵の一種でもあると思っているので、会話の理解が早い人は似たような話と紐付けて情報を解凍して、より深く話を理解できるというのもありそうです。
アナロジー思考を身につけるには
物事を説明する時に例を出すのはアナロジー思考の良い訓練だと思います。話し相手の身近なドメインの言葉でうまく同じモデルに乗せた例が話せれば、相手の理解も早いと思います。文章を書いていて、わかりにくい、ちょっと抽象的かな、と思った時は聞き手のわかる話をたとえ話にして説明する訓練をすると、引き出しから情報を出すのが上手く、速くなったりすると思います。また、格言なんていうのも、よくある失敗や意識しておくべきことを一般化・抽象化しているものなので、会話で適切に投げ込めると抽象化してものを引き出す訓練になるのではないでしょうか。要は言葉遊びはアイデア力に役立つ、ということかも知れないですね。会話も面白くなるだろうし、常に上手いこと言ってやろうと考えなら自分の引き出しを開け閉めすると楽しく磨いていけそうです。
また、プログラミングコンテストもアナロジー思考を磨く絶好の場です。問題から、どんなモデルを適用でき、どんなアルゴリズムやデータ構造が助けになるかの判断が早くなると、抽象化した学びがどんどん活きてきます。当然ですが、前提として、ストックされた抽象化済、モデル化済の知識があってこそ活きる話で、類推(アナロジー)は知っていないものに寄せることはできません。毎回プログラミングコンテストに参加するだけじゃなく、正解できなかった問題の解き方を理解し、考え方を抽象化してストックすることで解ける問題はどんどん増えていくと思います。
コミュ力とは
前にも書いたかも知れませんが、コミュ力というのは、適切な抽象度を選択できることだと思います。発信側の抽象度は相手の知識レベルに応じて、情報を解凍して、「伝わる内容」で話すことです。技術力があるけど、コミュ力がない、と言われる人は情報が圧縮されたままなので、受け側が理解できません。暗号化されてるようなものです。稀に圧縮できるけど解凍できない人がいるのも事実です。受け側で言うと、圧縮された情報を解凍して理解できることでしょう。1聞いて10理解する人はこれです。コミュ力がない、と言われる場合、発信側と受信側で許容できる圧縮率に差がありすぎる時に起きやすいと思います。「あの人はコミュ力ないから言ってることわからない」と言っちゃう人は受信者としてのコミュ力がないわけで、抽象化された情報も理解できるなら圧縮された情報の方が会話は速いので、コミュ力がないと言われた技術者がハイレベルな技術者同士の会話では話が弾んでることはよくある話です。本当にコミュ力のあるマネージャは情報の圧縮にも解凍にも対応できると思います。技術力あって圧縮した情報ばかり投げてくるメンバーの言ったことを解釈して、他のメンバーが理解できる抽象度に理解して言い直したりできるのがこういったマネージャの強みです。また、自分の技術力が発信者の圧縮された情報に対応できない場合、上手く誘導して抽象度を下げさせれば良いわけです。圧縮率の高い情報を解凍するには見合った技術力が必要なので、技術力が追いついていなくて解凍できない場合もあるわけで、マネージャが技術力が不足している場合メンバーの評価が下がる恐れもあります。
個人的に抽象度をコントロールする訓練はプレゼンテーションとかで聞き手を意識して話すことを繰り返すと身に付いてくるので、技術力があって抽象度のコントロールができていない人は積極的に登壇の場を作って話させるとよいのでは？と思います。
まぁ、いきなりキレるとか、論理的に成り立たないことを主張し続ける人はいますが、そういう人はコミュ力以前に雇っちゃダメなやつで、コミュ力を問題にする場合、せめて、その人が技術力のある人であって欲しい。正しくない主張で会話が成り立たないのはコミュ力以前で、ただの愚か者では、という…。
まとめ
抽象化によってコンパクトに圧縮した情報をストックし、アナロジー思考により単純な具体化だけでなく、似た構造にも適用できることがプログラマとして、エンジニアとしての学びと実力を加速させる方法だと思います。少しでも思い当たった人は、是非お試しを。
まだ読めてないけど、↓も良さそう。「インゲニウム」という概念も理解できると、言語化がもっと深まるかも知れない。
[2020/08/30追記]
この本はマルクス主義の人の本の模様。社会主義には共感全くないし、冒頭から信頼できないメディア代表の朝日新聞の名前が出てちょっと怯みましたが、思考を磨く上では主義としては共感できない側の「思考法」だけを盗むのもありかと。序盤で聖書はアナロジーという話があり(ある種究極の例え話)、欧米圏がそういうの得意なのも解る気がする。数学の進みが遅いと言われてるのも日本みたいに公式を理解しないで使ってるのでなく、抽象化のプロセスとその理解に重きを置いているので時間がかかるけど、本当に重要な芯の部分を固めているため、大学で一気に抜かれる、というわけです。入試の弊害ですね。慣れでツボにはまれば解ける問題数を増やすより、理解で確実に解けるカテゴリーを増やす方が強いのでは。
この記事があなたの学びのお役に立つことを願います。
