考え方の考え方を知る:物事を考えるときの手法/シンキングツールなど7個を紹介する!

考え方の考え方を知る:物事を考えるときの手法/シンキングツールなど7個を紹介する!
みるみ

今回は考え方のお話。

最近本業の方の仕事でもこういう色んなツールを使って「ああでもないこうでもない」ってやることが多くて、「そういえばPCのフリーソフトでもそういうの紹介してたな~」とか色々思い出したのでちょっと書いてみます。

  • 思考の整理
  • 計画立て
  • 選択に迷ったとき
  • アイデア出し

などにお役立てくださいー!

ちなみに「思考の整理」という言葉はこの有名な本から借りています。

気付いたらめちゃめちゃ有名な書籍になっているらしく、なんか今では東大生・京大生にもすごく読まれているらしい…。笑
僕が初めて読んだのは中学生のときですが、まあもちろん当時はちんぷんかんぶん。大人になってから読むと色々楽しいのでおすすめしておきます。

先に超大事なことを言っておきますが、今回の件は目的が手段にすり替わってしまいやすい最も典型的な例なのでそこはくれぐれも注意。

あくまでも「ゴールはその検討や思考が達成されること」であって、その手法を使うことに囚われすぎてはいけません。やり方にこだわると目的を見失います。

それと、この記事を書くにあたって「他のサイトはどういうまとめ方をしているんだろう?」と思ってググってみたんですが、なんかあんまりヒットしない。なんでかは分からないけどあんまり一般には知られていない情報?

というわけで、僕が会社で知ったものや外部のセミナーなどで知ったものも多いのでちょっとだけ期待してみてください。ちょびっとだけ。

1.ブレインストーミング

brain-Storming

「アイデア出し」と言ったらみなさんまずはこれを思い浮かべます。よね?

知名度も抜群というか、そもそもアイデア出し自体がこのやり方に概念的に近いと思っている。

ブレインストーミングには4つの基本原則というものがあるけれど、これはブレストに限らず「アイデア出しをやろう!」となったら普通に遵守するべきことのはず。それすらできずもし場を壊す人がいるようなら、アイデア出しよりまずそいつをなんとかした方が組織としては前進するでしょう(もちろん「量より質」っていうアイデア出しもあるとは思います)。

基本原則は以下。

  1. 判断・結論を出さない(結論厳禁)
  2. 粗野な考えを歓迎する(自由奔放)
  3. 量を重視する(質より量)
  4. アイディアを結合し発展させる(結合改善)

「とにかくしゃべれ!」っていう感じなので、全体の成果具合は進行役のファシリテーションスキルにとても依存します。あまり議論に参加しない人、できない人からもいかに意見を引き出せるか?を意識しないと、声が大きい人のアイデアに偏っちゃいますから。まあ物理的にも声が大きい人はやっぱり強くなっちゃうんだけど…。笑

とは言っても、実際にブレストの利用価値がどれくらいあるかと言われると、正直僕は微妙と思っています。

なんのお題目もない状態で「はい出して!」ってやってもやっぱり意見は出ないです。それができりゃたぶんそんな作業をやることになってないはずですもんね。

「ある程度制限をかけた状態でのブレスト」などはたまにやりますが、「大人数で完全フリー」っていうのはたぶん成功しにくいんじゃないでしょうか。

そして4つの原則からも分かる通りブレストは「発散」の作業なので、その出まくったアイデアをそのままにしておいてはどうしようもありません。発散させたものは「収束」させなければいけないので、そこで次の手を使います。

2.KJ法

kj-method-post-it

ブレストとセットで行われることが多いのがこのKJ法。KJっていうのは考案者(日本人)のイニシャルです。

こっちは名前の知名度は幾分か劣るので「知らない!」という方もいるかもしれませんが、必ず無意識にやっているはずです。

作業内容は「たくさんあるアイデア(データ)を似通ったもの同士でグループ化させるなどしてまとめていくこと」です。超シンプル。

ブレストをポストイットで進めていくのは定番の手法ですが、そこで出まくった1枚1枚をあとからホワイトボードとかでグループ分けしますよね。あそこで情報の分類が行われること、重複に気付けることなどがポイント。

そしてなにより、その複数でまとまったアイデア達を眺めていると新しい閃きも起こり得るっていうのが大事なところです。可視化されることで気付けることっていうのは絶対あります。僕もいつも思います。

もともとフィールドワークで収集した膨大なデータの整理方法として考えられたらしいんですが、そのメリットを思うとデータの整理よりアイデアの整理の方が向いているんじゃない?と僕は思ってます。

ちなみに僕も今回のタイミングで初めて知りましたが、「KJ法」は商標登録されているらしく、その正しい教育・指導方法は認定もなされているようです。

3.マインドマップ

mind-map

これも有名ですね。

考えたい対象の一番中心になるものを実際に真ん中に置いて、そこから関連すると思われる要素を放射状に描いていきます。その要素からまたいくつかの子要素に広がっていって…ということを繰り返す。

人間の脳の仕組み、そしてその考え方と非常に近いシステムであることが特徴らしくて、それゆえ人間にとってとても理解や記憶がしやすいんだとか。

なので完成した成果物自体に利用価値を見出すような使い方は厳密には正しくないと考案者は言っているようです。つまり「マインドマップとして完成された図解」とか、「ノートのまとめ方」とかそういうことではないんだと。後者は使い方としては合ってそうな気もするけど…。

マインドマップは僕も個人的にめちゃめちゃ使っているツールで、PCで作成できるフリーソフトもいっぱいあるのでよくお世話になります。有名なのはFreeMindXMind。僕は前者を使ってます。

使うシーンとしては以下。

  • 「ある事柄」について徹底的に検証したいとき。そいつが持っている要素にどんなものがあるのか網羅的に知りたい
  • 困っている課題があるとき、まずはその課題がどういう問題を孕んでいるのか色んな視点で書き出す
  • 単純に組織図的な「包含関係にあるもの」同士の関係を明確化したい

わざわざ言葉にしてみたけど、僕は普段の物の考え方がもうマインドマップみたいになっている気がします。

必ず中心になんかがいて、「そいつはどういう状況なのか?」「それを解決するにはどうすればいいのか?」みたいに順を追って考えることが多いです。でもたぶん、これを実際に書き起こすことに意味があるんでしょうね。ツールってそういうものだと思います。

もう一つ。

僕は考え事をしたり計画を立てたりするときは絶対にアナログ、つまり紙とペンでやることにしているんだけど、マインドマップだけはPCを使うこともあります。その理由は紙の面積的にも厳しいっていうのと、要素と要素の空間をどのくらい空けたらいいかの判断が難しいから。そういう余計なことを考えているうちに思考はどんどん断絶されていくので、さっさとPCに打ち込んでいった方がgoodだと思っているんです。

 

マインドマップと形が似ている「マンダラチャート」というのも紹介しておきます。

mandara-chat-example

これは野球の大谷翔平選手が高校時代に設定したものだそう。けっこう取り上げられて話題になったりしてました(このときは目標達成シートと呼ばれてた)。

いわゆるToDoリストなんだけど、確固たる意思のもと明確化された64個だけをひたすらに実行していくというような「かたさ」がポイント。

一番達成したい大きな目標がある場合、これはすごく良さそうに思えます。「夢」に近いのかな。

僕が使うなら、数値目標を入れて具体化するより、この大谷選手みたいに「常に意識すること」みたいなマインドの部分を書き出すと思います。「これを気をつけられれば夢は叶う!」みたいな。

いい感じに"マインド"がマインドマップとかかったのでこの辺にしときましょう(全然うまくない

4.OGSM

ogsm-thinking-tool

出た、アルファベット頭文字シリーズ。
「オージーエスエム」とそのまま読む。クソどうでもいいですが、これ「イニシャリズム」って言います(英語読みするのは「アクロニム」)。

  • O:Objective→目的
  • G:Goal→ゴール
  • S:Strategy→戦略
  • M:Measurement→評価

まあこれだけ見ればだいたい分かると思います。想像通りの運用方法でしかないですが、強力です。なぜなら「目的の制定が最も重要視されている」から。ゴールを見失いにくいんですよね。ってか「ゴール」もいるんだよな。

ビジネスで使われることが多いみたいですがこれはなんにでもイケます。

なにかを進めて行く以上必ず目的があってそれの評価指標となるゴールがあって、それを実現するための戦略があるはずだから。

で、これをどう「考え方の考え方」に活かすかというと、それも簡単ですよね。

目的は絶対に分かっているというか確定要素のはずなので、それに合わせて残りの3つを設定すればいいだけ。よく聞く「PDCA」とは違って文字の順番がそのまま作業手順になっているわけではないんだけど、これもまたOGSMの面白いところ。

捉え方は自由ですが、僕は「前半2文字が目標系、後半2文字は実際の行動系」みたいなイメージを持ってます。

つまり、

  • O:Objective→一番達成したいこと
  • G:Goal→その目的のための具体的な到達点
  • S:Strategy→ここはそのまま。戦略
  • M:Measurement→具体的な到達点かどうか知るための現在把握

みたいな感じ。で、この捉え方だとOGSMを何層もの構造にすることができるんですよ。

例えば

  • O:目的→日本中で知られるくらいの有名なミュージシャンになる
  • G:ゴール→日本武道館で3回ライブをする
  • S:戦略→とにかく身近な知名度を上げ、小規模のライブを増やす。その中で大きなライブのコネクションを見つけ出していく
  • M:評価→大きなライブができそうなコネをいくつ作れたか?

としてみる。言わずもがな、例はメチャクチャです。

そうすると、この後半2文字が次の下層の前半2文字に置き換えられるんです。

  • O:目的→大きいライブをさせてもらえるような人、組織と繋がりを増やす
  • G:ゴール→大手芸能事務所に3回アタック(営業)しにいく
  • S:戦略→自分の強みを明確化して、実演をかねて偉い人に見てもらえるように企画する
  • M:評価→営業の成果はどうだったか?効果は?回数は?

こんな感じ。PDCAとかとは違って、一番最初の目的をメインにしつつどんどん細分化していけるっていうのがOGSMの良いところですね!しかも下層になるほど目的(ゴール)も具体化されてどんどん下部組織に落とし込みやすくなっているっていうのが分かりますか?ウォータフォール型に使うのはすごくおすすめです。

まあひとりでやるのにはちょっと微妙ですけど。

5.ODSC

odsc

※注:全然関係ない画像ですw

もうずっとアルファベットシリーズです。どれもイニシャリズム。

ODSCとは

  • O :Objective→目的
  • D :Deliverables→成果物
  • SC:Success Criteria→成功基準

で、なんというトラップ、まさか4文字あるのに項目は3つしかないとは!!ややこしくて最初は怒りしかなかった。

とはいえこれも話し合いにはとても有用な考え方です。利用シーンは、アイデア出しというよりかはみんなの意思統一や作業内容を明確にするために行うような感じ。

例えば議題が「次回の社長へのプレゼン、なにやんの?」なら、

  • O :目的→今企画している新製品の良さを社長に伝えたい
  • D :成果物→プレゼンに使うPowerPointの資料、デモ用のモック、当日の配布資料
  • SC:成功基準→「おぉ、いいねぇ~!」と言ってもらう、開発の「GO」をもらう、など

のように置きます。成功基準も別に数値的な具体化されたものである必要はなくて、上のように定性的なものでもOK。成果物に関してはなにかしら目に見えるアウトプットを設定した方がおすすめですけど。

1つ前で紹介した「OGSM」はちょっと使い方がややこしくて取っつきにくいところもありますが、こっちのODSCはかなりシンプルで話し合いの基本的な手順に則っているのでぜひ取り入れるべきです。

ただし、もともとまともに話し合いが進むようなメンバーならわざわざこういうツールにこだわる必要はありません。きっと、そういう人たちは自然と最初に目的をみんなで擦り合わせたあと「じゃあ完了目標はどうする?なにを用意する?」って話せているでしょうからね!

6.FTA/FMEA

tree-analysis

技術職の方はこれは絶対知っているはず。
この2つはタイプが180°逆のものなんだけど、どちらも似た者同士なので同じ項目でまとめて説明しちゃいます。

FTAはFault Tree Analysis、「故障の木解析」というもので、事故や故障が起きたときの原因解析に用いるものです。しかしまあ、単に中身を置き換えれば問題解決全般に使えます。

本当のFTAを説明しようとすると「故障モード」っていうものについての説明が必要になったり確率の話が出てきたりで相当だるいので、ここはシンプルに簡略化します。要は「なぜなぜ分析」です。

「エレベーターが止まってしまった」という故障に関して、それを最上部に置いて、その下にツリー状に「なぜ?」を並べていきます。それぞれの「なぜ?」にまた「なぜ?」がぶら下がっていく感じですね。

実はここでORゲートとANDゲートっていうFTAの最も特徴的な話が登場するんですが、まあ今回はカットですね…。大事なのは故障が一番上にあって、その下に「なぜ?」をやっていく「トップダウン方式」であるということ。

FMEAという方はその反対でボトムアップで故障の分析を行う手法です。Failure Mode and Effects Analysis、「故障モード影響解析」なんて言ったりします。

つまり「それぞれの故障要因が他の(上の)要素にどれくらい影響を与えますか?」っていう考え方で、現場の小さなミスや不具合から最終的な悪しき結果にどう繫がるのかを考えるイメージです。

荷物を乗せ過ぎればエレベーターが止まる要因にはなるけど、それが他の「もっとひどい故障」を引き起こす要因にはなりません。荷物を降ろせばエレベーターは動きます。

こうやってそれぞれの要素(故障モード)から起こり得る故障を考えていくっていう感じです。
うーん、ちょっと例えが下手くそかな。すみません、あんまり良い例が思いつかなかったです。

長々とつまらん説明をしてしまいましたが、これをどう使うのかというと、やっぱり「日常的になぜなぜ分析を上からも下からもやる癖を付けましょうよ」ってことかなと思ってます。

物の考え方は段階的であるほど理論が崩れにくく一貫性が保たれやすいです。その順番が細かいほどその思考の精度は上がるでしょう。

そんなとき、考える順番として

  • 一番大元の問題から広げていくのか?(FTA)
  • 1つ1つの小さな要素から中心に向かっていくのか?(FMEA)

のように分けられると思います。

FTAとFMEAは思考ツールというよりは本当に解析方法って感じで、実際にJISで規格が決まってたりするくらい技術寄りのものなんですが、今回はそれをもとにしたら「普段の物の考え方」から使えるんじゃないの?っていうお話でした。

7.TOC/CCPM

theory-of-constraints-ccpm

最後は最近巷で話題のTOCとCCPM。アルファベットだらけでもういい加減うざい?
これらはプロジェクト管理ツールなんですが、今回はそれを個人での活用法に置き換えてみます。

TOCってのは「制約条件の理論」と言って、まとめると弱者を助けようという考え方です。ちょっと意訳し過ぎかもw

物理学者が「ザ・ゴール」って本で提唱した概念なんだけど、さすが理系というか、超理論的です。

組織で一番弱いところ(作業をこなす能力が低いポイント)が常にボトルネックになっていて、他の人がスキルアップしようがそいつらが弱いままだとチームとしてのアウトプット量は増えない!って言ってます。なので一番時間がかかりそうなタスクにとにかく着目します。余裕がある人は助けに行ってもいい。

それらをプロジェクト管理的に可視化させるための手法がCCPM、クリティカルチェーン・プロジェクトマネジメントです。わざわざカタカナで書いたのは、「クリティカルチェーン」という単語にはそれなりにピンと来る人が多いかも?と思ったから。「PERT図」で「クリティカルパス」とかは聞いたことある人多いんじゃないでしょうか。

とにかくこの「時間の掛かりそうなところに着目して計画は立てるべき」っていう考え方がすごく大切だと思っていて、仕事以外でも自分でなにかを進めるときは僕はいつも気にするようにしています。ここで引っかかると他の計画も全部破綻しちゃうから。

その「弱い部分」で余裕を持たすことは許されていて、そのバッファと呼ばれる猶予工数を管理するっていうのがCCPMの一番の特徴です。自分の立てた計画が常に「余裕を残せているか?」っていうのはとても大事。気持ち的にも楽になるしね。

ccpm-fever-chart

これがそのバッファを管理するためのCCPMで使われる「フィーバーチャート」というもの。余分な工数がなくなっていくと赤に近づいていくようになっていて、毎日ひと目見たら分かるような管理ができるという仕組みです。

これは体系化されてやり方がかなりバッチリ決まっているので、会社でも普段の業務で進め方に不都合を感じている人は導入を検討してみるといいです。定型業務であればあるほど効果は超発揮されます。お試しあれ。

おわりに

実はこの記事を書いていて「僕自身も目的を見失いかける」というすごくアホな再帰的スパイラルに陥ったりしてました。

これを書くことで「読んでくれる人になにを伝えたいんだろう?」ってかなり何回も考えました。ちなみに考えた結果は「僕がどういうことを考えている人なのかなんとなくその雰囲気を知ってほしい」みたいな感じかなと思ってました。キモいですね、死にます。

最近はこの「目的を常に考え続ける」っていうのが本業でもブログ運営でもすごく癖になってきていて、どんな思考方法を利用するにしても一番大切なのはやっぱり"目的"だよなと強く思えるようになりました。本当はそういうところを発信したくて書いた記事なのかな?(もう目的見失ってる

とはいえ、僕も今まで普通に生きてきて最近まで知らなかったものが結構あったので困ったときにちゃんと使える情報ではあったと思います。自分の中で考え事をするときでも、誰かと話し合いをするときでもいいので、良かったらちょっと参考にしてやってみてください。

いつもと違うことをするだけで新鮮な気分にもなりますよ~

今回はこの辺で!

みるみ
みるみ

ブロガー、ソフトウェアエンジニア。

この「みるめも」というブログの筆者です。

この記事へのコメント
コメントはまだひとつもありません :)

新しいコメントを書く

  • 必須項目はコメント本文のみですが、お名前はぜひご記入いただけると嬉しいです。
    ※メールアドレスを書いた場合も公開されることはないのでご安心ください。
  • 特定のコメントに返信したい場合は各コメントにある「返信する」ボタンからどうぞ。
  • コメントはこちらで承認の作業を行うまでは表示されません。ご了承ください。
    ※ここ数年スパムが激化しており、誤って削除されてしまうケースが増えてきました。スパムボックスも毎日自分の目で確認するようにはしているのですが、どうしても限界があります。確実に僕に連絡を取りたい方は メールTwitter からお願いします。