電車の路線図を思い浮かべてください。あの図には、実際の距離も、線路の曲がり具合も、川も山も描かれていません。それなのに——いや、描かれていないからこそ、乗り換えが一瞬で分かります。
これが3つ目の道具、抽象化です。一言でいえば、いまの目的に関係ない情報を捨てることです。
目的が変われば、捨てるものも変わる
同じ「東京」を表すのでも、
- 乗り換えを知りたい人には、路線と駅の順番だけあればいい
- 徒歩で移動する人には、道路の形と距離が要る(路線図では歩けない)
- 地質を調べる人には、地層の情報が要る
どれが正しい地図か、という問いは意味がありません。目的に対して適切かどうかだけが基準です。抽象化は「情報を減らす技術」ではなく、「目的に照らして残すものを選ぶ技術」なのです。
名前を付けることは抽象化そのもの
「野菜を切る」という言葉には、包丁の握り方も、まな板の位置も入っていません。それでも私たちは通じ合えます。名前を付けた瞬間、中身の細かさを一段隠せるからです。
プログラムでも同じことをします。
- 変数に
totalと名前を付ける → 「この箱には合計が入っている」以外は考えなくてよくなる - 関数に
printReceiptと名前を付ける → 中で何十行動いていようと、呼ぶ側は気にしなくてよい
つまり良い名前を付けられる人は、抽象化ができている人です。逆に名前が決まらないときは、その部品の役割がまだ1つに定まっていないというサインでもあります。
抽象化には階段がある
もう一つ、抽象化には「高さ」があります。同じ料理でも、
- 一番低い段: 「包丁を右手で持ち、玉ねぎに刃を当てる」
- 中くらいの段: 「玉ねぎを薄切りにする」
- 高い段: 「下ごしらえをする」
- もっと高い段: 「夕食を作る」
どの段で話すかは、相手と目的で決まります。友達には「夕食作っといて」で通じますが、料理をしたことがない人には低い段の説明が要ります。プログラムを書くときも同じで、上の段から下の段へ降りていくように設計します。上の段だけ見れば全体の流れが分かり、必要なときだけ下を覗く。この構造ができていると、あとから読み返しても迷いません。
捨てすぎの危険
抽象化には失敗もあります。必要な情報まで捨ててしまうと、あとで困ります。
- 「客の情報」とだけ決めて作ったら、電話番号を持たせるのを忘れた
- 「金額」を整数だけで考えていたら、消費税の小数で困った
捨てる前に「この目的で、本当にこれは要らないか」と一度だけ問い直す。それが安全策です。
この道具の効き目
分解で細かくし、パターンでまとめ、抽象化で名前を付けて隠す。この3つが揃うと、大きなプログラムでも頭の中に収まるようになります。人間が一度に考えられる数はせいぜい5個か6個。だから隠すのです。抽象化は、人間の記憶力の限界に対する対策だと考えると腑に落ちます。