頭の中がぐちゃぐちゃ思考が整理できない。思い悩むな、考えろと言われても、どうすれば頭の中が整理できるかわからない。 マインドマップやロジックツリーなど「効く」と言われているツールを使ってもなお、考えが進まない。 気づいたら時間ばかりすぎていて、手元に残ったのは文字が書き殴られた紙と依然整理されない頭だけ。
このように、考えてみたけどダメだったという経験がある方は多いのではないでしょうか。 世の中にあふれる「思考の整理」に関するツールやノウハウを使ってなおこんな状態。 ひょっとしたら自分は圧倒的に頭が悪いのではないだろうか・・・と思われたこともあるかもしれません。
そのかたわら、サクサクものごとを考えてパパっと先に進んでしまう人、いますよね。 一体何が違うんでしょうか。思考整理ノウハウの量?経験の差?それとも単なる嗅覚の違い?
一番大きな違いは、考える準備として整理の切り口を考えているかではないでしょうか。
というわけで今回は、思考整理の「切り口」についてです。
思考整理ツールを使っても考えがまとまらない理由#
考えたことを箇条書きにしてみよう。マインドマップで整理しよう。縦軸と横軸を切ってマトリクスにしてみよう。 さまざまな思考整理系のツールを使ってみても、おそらく一発で思考を整理しきるのは難しいでしょう。
その理由は切り口が甘いからです。 上にあげたツールを使った思考整理で陥りがちな「考えがまとまらないアンチパターン」を見てみましょう。
箇条書き#

たとえば、箇条書き。 たかが箇条書きと思われるかもしれませんが、「超・箇条書き」という本にもあるように、箇条書きはものごとを整理するための最もシンプルかつ強力なツールです。
頭の中を整理しようと箇条書きを書く場合、はじめはブレインストーミング的に考えついたことを書き下してみると思います。(いわゆる「ゼロ秒思考」方式)
たとえば「ToDoリスト」というお題で箇条書きを作たとします。 リストには「今夜の献立を考える」「昼寝したい」「年収1000万になる」が並んでいたとします。 さて、これは思考が整理された状態と言えるでしょうか。
不十分です。なぜなら、
- 主題がざっくりしすぎている(「やること」ってそもそも何?)
- 主題に沿った内容が書かれていない(「昼寝したい」はやりたいこと)
- 項目同士のレベル感がバラバラ(「今すぐ」「未来に」が混在)
などなど、主題と項目、項目と項目で不整合を起こしているからです。
もちろん思考を言語化することは大事ですし、言語化できる能力はすばらしいものです。 しかし「思考の整理」という文脈においては、思考のダンプに価値はありません。 切り口が甘く粒度もバラバラなリストは、単なる未整理のリストです。
箇条書きは「行頭に点をつける」以外にフォーマットが決まっていません。 そのため何をどう書くかはすべて筆者にゆだねられますし、思考の整理状況がそのまま箇条書きの品質につながります。 箇条書きにすれば思考が整理される、ではなく、整理された思考を箇条書きに落とすから、箇条書きは整理されるんです。
つまり**「箇条書きは思考整理ツールだ」と思ってしまうこと自体が、箇条書きを使う際のアンチパターン**ということになります。
とはいえ、思考整理の中間成果物として箇条書きを使うのはよい方法です
マインドマップ#

たとえばマインドマップ。 中心に主題とするトピックを書き、まわりに関連するサブトピックを書き、どんどん枝葉を伸ばすことで思考を整理するツールです。 おそらく世界で最も有名な思考整理ツールでしょう。
しかしマインドマップも万能ではありません。 中心にすえるトピックや最初に枝を伸ばした先の内容によって、考えるうちに**「中心ってこれでいいんだっけ?」**という自問に陥ってしまう場合があるからです。 トピックを分解しているうちに「なんか全然整理できない」「むしろこの枝の内容がメイン?」と思考が交錯してしまうんですね。
そして今まで書いたマインドマップを横に置き、その時点で気になったトピックを中心とした別のマインドマップを書きはじめる。 そこであれこれ考えているとまた**「中心ってこれでいいんだっけ?」**というタイミングがきて、またふりだしに戻る。 結局、中心とするトピックが異なるマインドマップが量産され、「結局なにを考えていたんだ?」と途方に暮れ、思考は整理されないまま時間が過ぎていく。
切り口が甘いあまり思考がリープするというアンチパターンです。 中心に据えた切り口(主題)に沿って考えているつもりが、いつのまにか視点がずれていく。 こうなるとマインドマップ形式でモノを書いている意味がなくなってしまいます。
マインドマップ=入れ子にした箇条書きなので、箇条書きのアンチパターンも当てはまります
マトリクス#

たとえばマトリクス。 ものごとを2つの視点(縦軸・横軸)から眺め、マッピングすることで考えを整理するツールです。 汎用的ですし、なにごともお手軽に2次元の平面にビジュアライズできるので、何かと整理する際に使っている方も多いのではないでしょうか。
しかし気をつけなければならないのは、マトリクスにマップしたからといって思考が整理されるわけではないということ。
たとえば「今夜のおかずはなににしよう」というお題をマトリクスで整理するとします。 縦軸は「おいしいか(好きか)」、横軸は「健康によいか」としました。 そして思い浮かんだメニューをマトリクス上にプロットしていきます。 さて、このマトリクスは思考の整理に役立つでしょうか?
残念ながらNoです。 なぜならこのマトリクスにメニューをプロットしても、結局「おいしい(好き)」かつ「健康によい」のハコにばかり目が行くからです。 結論があまりに当たり前すぎてマトリクスにした意味がありませんよね。 たとえばどちらかの軸を「食材調達+調理にかかる時間」にするともっと現実的で意味のあるマトリクスになりそうです。
つまり、縦軸と横軸の切り口が甘いというアンチパターンです。 マトリクスの品質は縦軸と横軸の定義(切り口)がすべて。 問いへの答えが導かれない切り口でマトリクスを作ると、なんとなく整理した「つもり」になって思考停止に陥るリスクがあります。 とりあえず十字を書くのはやめたほうがいいです。
縦軸と横軸に依存性があってマトリクスとして機能しない、という別のアンチパターンもあります(例…縦軸:車の故障率、横軸:年式)
思考整理ツールは「切り口」は教えてくれない#
3つのアンチパターンについて見てきましたが、いずれにも共通するのが切り口という点です。
箇条書きにしろマインドマップにしろマトリクスにしろ、思考整理ツールは整理作業を補助してはくれますが、適切な切り口を教えてくれることはありません。 これが思考整理ツールの限界です。
にもかかわらず、考えを整理する際にやってしまいがちなのが
- 考えるトピックを決める
- 思考整理ツールを選ぶ
- ツールの定めるフォーマットに則ってとにかく考える
という手順です。
これ、思考整理ツールが切り口を教えてくれることを暗に期待してしまっていますよね。 だから「とにかく考える」の段になって切り口の甘さゆえ考えがぶれるです。
つまり、思考整理ツールの使いかたを覚えて「ツールありき」で考えたところで思考は整理されません、ということです。
思考スピードが速い人が「考える前」に考えていること#
では逆に、思考スピードの速い人はどのような手順で考えているのでしょうか。
こちらです。
- 考えるトピック(問い)を決める
- 答えを出すために適切な「切り口」を決める
- 切り口の数やタイプに適した思考整理ツールを選ぶ
- ツールの定めるフォーマットに則って考えを整理する
考えるべきトピックについて具体的な検討を始める前に、どのような切り口で考えるかを考えています。
実はこの「切り口」をいかに上手に決めるかによって、思考整理の品質はだいたい決まってしまいます。 下手な切り口で考えたら、アンチパターンの事例でご紹介したとおり、
- うまく整理が進まず途中で迷子になる
- 整理したつもりで整理されていない
- トピックに対する答えに永遠にたどり着かない
という憂き目を見ることになります。
思考整理の「切り口」を見つける方法#
ではどのようにして思考整理に効く「切り口」を見つけるのか。
方法は大きく3つあります。 フレームワークを使う、変数を減らす、枝刈りをする、です。
フレームワークを使う#

一つ目が、フレームワークを使うことです。
フレームワークを使う利点は、だいたいきれいに整理できることが経験的にわかっている点です。 (そうでなければフレームワークと呼べません・・・)
有名どころで言うとSWOTや4P、3Cなどのいわゆるビジネスフレームワークを思い浮かべる方が多いかと思います。
参考: 図解と事例でわかるビジネス問題解決フレームワーク20選
しかし使えるフレームワークはそれだけではありません。 だいたいMECEに(漏れなく、ダブりなく)ものごとを分類したものならなんでもフレームワークとして使ってOKです。
たとえばぼくの専門であるITの世界なら
- ITILの「システムライフサイクル」
- IPAの「ITスキル標準(ITSS)」
- 情報セキュリティ管理の国際基準「ISO/IEC15408」
など、国や標準化団体が定義している「XXX標準」にある分類はだいたいMECEにできているので、結構使う機会があります。 (なので新しい標準や勧告が出たら目を通すようにしています)
もちろんフレームワークに当てはまるだけでは考えたことにならないのですが、思考整理の「たたき台」に使うにはちょうどいいので、覚えておいて損はないと思います。
「XXX標準に則って観点漏れがないことを確認しました」はコミュニケーション上も有効です
変数を減らす#

二つ目が、変数を減らすことです。
思考整理の際にありがちな「切り口のぶれ」の原因は、そもそも考慮するポイント(変数)が多いから。 あちらの事情を重く見ればこっちが立たず、そっちを考慮するとあっちがダメになる。 そのようないわゆる「多変数」の状態で考えようとするからものごとが複雑になり、頭の中は整理しにくくなるんです。 そこで、変数を減らして問題をシンプルにすることで切り口の安定化をはかります。
たとえば「今日のデートのファッションをどうするか?」を考えたとき、考慮ポイント=変数が3つ出てきたとします。
- TPOにふさわしいか?
- 相手の好みか?
- まわりの人にはどう映るか?
デートという文脈を考えると、この中で優先度が低いのは「まわりの人にどう映るか」ですよね。 だってデートとは相手とどこかに行って楽しむという行いであって、通行人に愛嬌を振りまくものではないからです。(人によるかもしれませんが) そこで変数を「TPO」と「相手」のみに絞ることで思考整理の難易度ははるかに低くなるはずです。
つまり変数を減らすとは、結論を大きく左右しなさそうな考慮ポイントを捨てることを指します。 結論に最も大きく影響しそうな変数を初段の切り口に持ってくると、思考整理の手戻りが少なくなります。
「方針を決める」「前提をつける」「スタンスを固める」とも言えます。インプットをあえて減らすのもこの1つです
枝刈りをする#

三つ目が、枝刈りをすることです。
「枝刈り」はプログラミング(アルゴリズム)の世界で使われる言葉です。 詳細な説明は省きますが、要するに無駄なパターンや組み合わせ(枝)を考えない(刈る)ことでプログラムの処理スピードを早めよう、というアイデアです。
たとえば「何県に引っ越すか?」を考えたとき、現実ラインが四国圏内だけだという見通しがあれば、47都道府県すべてでなく香川・徳島・高知・愛媛だけ比較検討すればいいはずです。
また「これから発売する1粒1万円の超高級梅干しの想定購入者層」を考えるとき、年収100万円未満の低所得者層は一旦検討対象外にすることになると思います。
前項の「変数を減らす」では考慮ポイント(変数)そのものの数を減らしましたが、「枝刈り」の場合は**変数の取りうる値(パターン)**を減らしにかかる、ということですね。 枝を刈ってもパターンが10個以上ある、もしくは逆にパターンが2つくらいになってしまった場合、切り口そのものが悪い可能性が高いです。
個人的には値が3〜5個くらいなら伝わりやすいしキレイかな、と思います
思考整理の切り口を考える際のチェックポイント#
思考整理の切り口を見つけるために、フレームワークや変数減らし、枝刈りという方法を紹介しました。 しかしこれらは万能ではありません。時には思考整理の切り口をゼロから考える必要が出てくると思います。
そこで「いかに切り口を考えるか」を体系立てて考える手順(スキル)がほしいところなのですが・・・
これ実は、スキルよりアートの領域に近いんです。 なので「こうすればいいよ!」という手順は正直思い浮かびません。
ただ、切り口が切り口として機能するかの最低限のチェックポイントはあります。
- どんな観点で切ったかを一言で表せるか
- 切った結果出てきた項目はMECEか
- 同じ階層にある項目の粒度はあっているか
1点目はたとえば「ココは日本の地方別に切っています」など。 切り口の定義そのものが複雑だとそのあとの整理が進みにくいため、わかりやすく一言で表せることがとても重要です。
2点目は「フレームワーク」の点でも触れたので詳細は割愛します。 一言加えるなら、ダブりよりも漏れがないほうが重要だということでしょうか。(「考慮漏れ」による手戻りは痛い)
3点目は「箇条書き」で触れたポイントです。 たとえば「日本」と「東京都」が同じ階層にある場合、そもそも切り口を疑う必要がありそうですよね。
ここらへんについては下記書籍に詳しく書いてあります。 2001年発売と古いですし、もうずいぶん手垢がついた本ではありますが、それでもなおオススメできる一冊です。
まとめ:「切り口」から考えよう#
というわけで、思考整理が速い人は考える前に「整理の切り口」を考えているというお話でした。
思考整理ツールは整理の補助はしてくれますが、切り口を教えてはくれません。 切り口がよくないと整理がうまく進まず手戻り、余計に頭がぐちゃぐちゃになります。
だからこそ「よし整理するぞ」と思考整理ツールを開くその前に切り口を考えること、そして切り口を決める材料や方法、良い切り口の条件を知ることが大事なのではと思います。
ツールに頼った思考整理から脱却し、「切り口」から思考整理の品質を高めてみませんか?



