「いろいろ学んだけど浅い気がする」という不安の声をよく聞きます。よく観察していると，この悩みには2通りのタイプがあります。「⁠深い理解」軸の知識が足りていないタイプと，「⁠抽象化」フェーズのやり方に慣れていないタイプです。

自分の知識が浅い気がする原因

「深い理解」方向の知識が足りない

一つは，ある程度経験を積んだプログラマによく見られるものです。いろいろなことを学んで，それを応用して成果も出している，なのになんだか不安，というものです。

このタイプの人は，自分の中では抽象化を行ってモデルを作ることができているのですが，その理解に名前が付いていません。そのため，自分で気付けなかったり，他人に説明できなかったりします。また，そのモデルが世間でどう呼ばれているのかを知らないため，本当は理解できているのにそのモデルについての会話についていくことができず，「⁠自分は理解できていない」と感じてしまいます。

この症状は「深い理解」軸の語彙（ごい）が足りていないことが原因です。意識して「深い理解」軸の知識収集を行うことが必要です。そうすると「あー，それMediatorパターンって名前が付いてるのか！ 知らずに使ってた！」とか，「⁠あー，なんか言語によって違いがあるなーと思ってたけど，『⁠静的型付け』と『動的型付け』の違いだったのか！」というように理解が整理されます。

「抽象化のフェーズ」に慣れていない

もう一つは，「⁠抽象化のフェーズ」に慣れていないタイプです。抽象化のフェーズでは，自分でモデルを生み出さなければいけません。しかし「正解のモデルが本に書いてあって，それを見つけて読めばよい」と勘違いをして，片っ端から本を読んだりと「情報収集のフェーズ」ばかりを行ってしまいます。情報収集にはゴールがないので，いくら情報収集を繰り返しても不安が解消されません。

不安を解消し，自信を持つには，学んだことを成果につなげる必要があります。「⁠情報収集」だけでは成果は出せません。得た知識を自分の中で「抽象化」してモデルにし，自分の問題に応用して，はじめて成果が出ます。

なぜ抽象化が必要？

なぜ抽象化が必要なのでしょうか。高校数学の問題を解くときのことを考えてみましょう。ある問題Q1を読んで，あなたは解き方がわからなかったとします。しかたがないので解答A1を読み，理解できて，Q1は解けるようになったとしましょう。では，よく似た問題Q2をあなたは解けるでしょうか？ 解けないかもしれません。しかし，似た問題をいくつも解いているうちに，この種の問題の「解き方」をあなたは体得します。そうすると，類似の問題Q3がテストに出たときに，あなたは正解できるわけです。

このたとえ話で，A1を丸暗記していても，Q3を解けるとは限りません。A1は「抽象化されていない具体的な知識」だからです。一方「解き方」を理解したあなたは，Q3を解くことができます。「⁠解き方」は，より一般的な対象に応用できる知識だからです。抽象化によって応用範囲が広がります。抽象化は一般化・汎用化なのです。

帰納による抽象化

高校までの数学では，「⁠一般的な知識」を「具体的な問題」に応用して「具体的な答え」を出すことが多く，その「一般的な知識」をどうやって作るかについてはあまり時間が割かれていないように思います。抽象化・一般化は帰納によって行われます。たとえば数学的帰納法では，n=1のときに命題Xが成立することを示し，n=2のときにもXが成立することを示し……と任意の自然数で成り立つことを示すことで，「⁠任意の自然数kについてXが成り立つ」という一般的な知識を導きます（図1・注1⁠）⁠。

注1）

無限にある自然数一つ一つの証明文を書く代わりに，「⁠n=k-1のときに成り立つならn=kのときにも成り立つ」を示すことで，無限回のステップを1回に圧縮してしまうテクニックが使われますが，ここでの本題ではありません。

間違えてでも抽象化するメリット

みなさんは，普段の生活ではここまで厳密な証明をしていないことでしょう。かわりに，2～3個の事例を見てそこから帰納をしています。たとえばQ1とQ2の解き方から「この手の問題はこうすれば解ける」と考えたり，ハトやスズメやツバメが飛ぶことから「鳥は飛ぶものだ」と考えたりします。こうやって作られる抽象的な知識は，間違っていることもあります。たとえば，鳥類でもペンギンは飛ばないですね。

しかし，たとえ間違えてでも抽象化は必要です。抽象化をしないと，ウグイスを見たときに「ウグイスが飛ぶかどうかはわからない」と考えることになります。論理的には正しくても，実用的にはどうでしょうか。間違えることのコストが低い場合には，間違えるリスクよりも抽象化によって得られるメリットのほうが大きいでしょう（注2⁠）⁠。

第1章では，Windowsにもlsがあるという間違いの例を見ました。間違えたことで，何か大きな問題があったでしょうか？ むしろ学びのきっかけになったのではないでしょうか？（注3）

注2）

ケーブルを直列でつなぐ場合は1つでも壊れていると全滅なので，間違わないことを強く求められます。一方並列でつなぐ場合には1つでも動いていればよいので，質が低くてもたくさんあることが重視されます。数学的なきっちり詰めていく考え方と，ブレスト的な数を求める考え方があるのは，求められることに違いがあるからです。間違いに対するリスク許容度で適切なバランスが変わります。

注3）

この話をもっと詳しく知りたい人は，次の書籍を参照してください。
Jules-Henri Poincare著／河野伊三郎訳『科学と仮説』岩波書店，1959年

どうやって抽象化するか

抽象化の確率を高めるツール

抽象化はどうすればできるのでしょうか。これは難しい問題です。正直なところ，「⁠確実に抽象化を行う方法」はまだ知られていません。「⁠情報を集めて，それからヒラメキを待つ」といった運頼みの方法しかありません。しかし同じ運頼みでも，確率が高まるとされる方法は，KJ法（注4⁠）⁠，思考関連図（注5⁠）⁠，グラウンデッド・セオリー（注6）などいくつか考案されています。これらの方法の共通点を簡単にまとめると次の3点になります。

• 情報をたくさん収集する
• 情報を一覧できるようにする
• 関連のありそうなものを見つけて集め，ボトムアップで構造を作る

何がモデルを作るために有益な情報であるかは，モデルを得る前に知ることはできません。そこで，まず関係あるかもしれない情報をたくさん収集します。これが最初の一歩です。

人間が頭で考える場合，同時に検討できることはあまり多くありません。一方，ふせんに書き出して机の上に並べれば，100個ぐらいは同時に扱うことができます。机という「仮想記憶」を使うことで，人間の認知能力を底上げするわけです。

100枚のふせんを整理する際に，ボトムアップで構造を作ることはなぜ大事なのでしょうか。トップダウンで分類してしまう間違いがよくあるのですが，それは「すでに脳内にあるモデル」に合わせてふせんを並べているだけです。この作業の目的は「モデルを作ること」つまり「未知の構造を発見すること」です。ボトムアップでまとめていく過程で，予期しない構造を発見することが目的なのです。トップダウンで分類するとこのチャンスを失ってしまいます（注7⁠）⁠。

筆者は2013年に『コーディングを支える技術』（⁠注8）という本を書いたのですが，このときにKJ法がとても役に立ちました。1,000枚以上のふせんを作り，それをボトムアップで構造化し，その結果としてこの本があるわけです。

今回，KJ法について詳しく解説するには誌面が足りません。2013年夏に筆者が「京都大学サマーデザインスクール」で行った講義資料が公開されていますので，そちらを参考にしてください（注9⁠）⁠。

注4）

川喜田二郎著『発想法─⁠─創造性開発のために』中央公論社，1967年

注5）

畑村洋太郎著『技術の創造と設計』岩波書店，2006年

注6）

Barney G.GlaserとAnselm Leonard Straussにより考案されました。次の書籍に詳しく書かれています。
戈木クレイグヒル滋子著『ワードマップ グラウンデッド・セオリー・アプローチ─⁠─理論を生みだすまで』新曜社， 2006年

注7）

第2章で学んだことを別の言葉で表現すると「既存の構造は大まかにトップダウンで読むと効率が良い」となります。トップダウンとボトムアップの使い分けが重要です。

注8）

西尾泰和著『コーディングを支える技術─⁠─成り立ちから学ぶプログラミング作法』（⁠WEB+DB PRESS plus シリーズ）技術評論社，2013年

注9）

「チームワークのデザイン」講義資料