エンジニアの考え方 #3 - 連想をノードでつないで、頭の中を地図にする
思考シリーズ第3回は、考えを頭の外に出す道具の話。中心にテーマを置き、連想したものを枝でつないで放射状に広げていく——マインドマップと呼ばれるこの方法は、思考整理にも自己分析にも効いて、実はプログラミングの設計にまでつながっています。
頭の中だけで考えると、同じ場所をぐるぐる回る
何かを考えようとして、気づいたら同じ2、3個の考えを行ったり来たりしていた——そういう経験はないでしょうか。頭の中だけで考えごとをすると、人はわりとすぐ堂々巡りに入ります。一度に頭の上に載せておける量には限りがあるので、新しい考えを載せると古い考えが落ち、拾い直すとまた別のが落ちる。進んでいる感覚だけあって、進んでいない。
対策はシンプルで、頭の外に出すことです。ただ、箇条書きで出すより、もっと考えが伸びる出し方があります。今回はその型の話です。
中心にテーマを置いて、連想を枝でつなぐ
やり方はこうです。紙やホワイトボードの真ん中にテーマを1つ書く。そこから、連想したものを線でつないで書き足す。書き足したものからも、さらに連想を線でつなぐ。中心から放射状に、ノード(結び目)と枝がどんどん広がっていく——一般にマインドマップと呼ばれる方法です。
身近なモノでやってみます。中心を「傘」にして、思いつくまま枝を伸ばすと、たとえばこうなります。
mindmap
root((傘))
骨組み・布・持ち手
ビニール傘・折りたたみ傘
雨・梅雨・天気予報
濡れを防ぐ
レインコート・長靴
電車に置き忘れる
ビニール傘なら諦めがつく
部品もあれば、種類もあれば、使う場面も、働きも、あるあるネタまである。ジャンルはバラバラです。それでいいのです。関係がありそうなら、種類を問わずつなぐのがこの方法の流儀で、1つのノードを起点にまた広げられるので、箇条書きと違って考えが連鎖して伸びていきます。
ルールは「評価しない」、これだけ
広げる段階でのルールは実質1つです。出しながら選別しない。「これは関係ないか」「くだらないか」という評価は、広げる手を止めます。ブレインストーミングで「出す時間と評価する時間を分けろ」と言われるのと同じ原則で、くだらないと思った枝が、あとで思わぬ枝と手をつなぐことがよくあります。書くのは文章ではなく単語で。きれいに描こうとしない。量が正義です。
自分の頭にも使える —「自分」を中心に置く地図
このやり方、モノや仕事のテーマだけでなく、自分自身にも使えます。中心に「自分」や「やりたいこと」を置くマインドマップは、自己分析の定番手法として就活の世界でもよく紹介されています。
中心から「好きなこと」「得意なこと」「避けたいこと」「時間を忘れること」といった枝を伸ばし、それぞれをさらに具体へ掘っていく。すると、頭の中では出会わなかった枝同士が、紙の上で出会います。「好きなこと」の枝の先と「得意なこと」の枝の先に、同じものが顔を出していたり。「避けたいこと」を具体化していったら、裏返しに自分が大事にしたいものの輪郭が見えてきたり。
一つひとつの連想は全部自分が出したものなのに、つながりの全体像は、地図にして初めて見える。ここがこの道具の面白いところです。
広げた地図を眺めると、「仲間」が見えてくる
そしてもう1つ。広げ終わった地図をしばらく眺めていると、自然にやりたくなることがあります。似たもの同士をまとめたくなるのです。
さっきの傘の地図なら——骨組み・布・持ち手は「傘の部品」の仲間。ビニール傘・折りたたみ傘は「傘の種類」の仲間。レインコート・長靴は、傘とは別のモノなのに「濡れを防ぐ」という働きでは同じ仲間。
よく見ると、この「仲間」、まとまり方が一種類ではありません。部品としてのまとまり、種類としてのまとまり、働きが同じというまとまり。つまり、ノードをつなぐ線には、実は種類があるのです。
次回はこの「線の種類」に名前を付けます。実は、名前を付けて整理したその地図は、ほとんどそのままプログラミングの設計図になります。オブジェクト指向と呼ばれる考え方の話です。
まとめと次回
- 頭の中だけで考えると堂々巡りになる。まず外に出す
- 中心にテーマを置き、連想をノードと枝で放射状に広げる(マインドマップ)。箇条書きより考えが連鎖する
- 広げる間は評価しない。ジャンルを問わず、量を出す
- 「自分」を中心に置けば自己分析になる。つながりの全体像は、地図にして初めて見える
- 広げた地図には「仲間」が潜んでいて、まとまり方には種類がある
次回、この地図に「関係の名前」を付けます。それがオブジェクト指向への入り口です。
※ 本記事の内容は執筆時点の情報であり、正確性を保証するものではありません。ご利用の際は免責事項をご確認ください。
Series / 連載
エンジニアの考え方
- 01 エンジニアの考え方 #1 - 課題を「分解」するところから
- 02 エンジニアの考え方 #2 - 「要するに?」と「たとえば?」を往復する
- 03 エンジニアの考え方 #3 - 連想をノードでつないで、頭の中を地図にする(この記事)
- 04 エンジニアの考え方 #4 - ノードの地図に関係の名前を付けると、オブジェクト指向が始まる
Related / 関連記事
関連記事
エンジニアの考え方 #4 - ノードの地図に関係の名前を付けると、オブジェクト指向が始まる
前回描いた連想の地図には、種類の違う線が混ざっています。「〜は〜の一種」「〜は〜を持つ」——関係に名前を付けて整理した地図は、そのままソフトウェア設計の図になる。連想と分類という人間の頭の動きが、オブジェクト指向の直系の祖先だったという話。
エンジニアの考え方 #2 - 「要するに?」と「たとえば?」を往復する
思考シリーズ第2回は、分解とセットで効く「具体と抽象の行き来」。例え話のうまい人が頭の中でやっていること、抽象的な指示に手が止まる理由、認識合わせが速くなる2つの質問について。
エンジニアの考え方 #1 - 課題を「分解」するところから
考え方の話をするシリーズの第1回は、すべての土台になる「課題の分解」。ネットが繋がらない日のトラブル対応から、郵便受けの通知の仕組み作りまで、大きすぎる問題を解ける大きさに割る話です。
Comments / コメント