『THINK BIGGER』を読んだ

migi
·
公開:2024/6/28

非常に面白かったのでメモ的に書く。

『選択の科学』を書いたシーナ・アイエンガー氏の新作。

先輩におすすめしてもらって読んだ。最近トライしている新規プロダクト立ち上げでも使える考え方が多くて、とても刺さった。

早速、今書いているドキュメントでもサブ課題(サブイシュー)をパクっている。

基本的には発想法・思考法の話。

自分が経験してきたアジャイルの探索プロセスとイシューからはじめよの課題に注目する考え方が混ざっているような、とても馴染みのよさそうな思考ツールだと思う。

とくに「そうだよな〜〜」と思ったのはこの一文。ドキッとした人は手に取ってみることをオススメする。

「試行錯誤」に頼ってはいけない

(ただ「Think Bigger」って名前はちょっとよくわからない…)


📝 軽く抜粋&つぶやき

  • 「Think Bigger」(もっと大きく考える、大胆に発想する)

    • あらゆる複雑な問題に価値ある解決策を生み出す方法

  • イノベーションを生むプロセス

    • 1. 課題を明確かつ具体的に定義する

      • 意味があるほどには大きいが、解決できるほどには小さい課題

      • 「問題を解決する時間が1時間あったら、問題を考えるのに 55 分、解決策を考えるのに5分費やしたい」(アインシュタイン)

      • "これは本当によくある間違いだ。課題はわかりきっていると考えてしまう。課題を考えて時間を無駄にしたくない、時間が何より大切だ、だからすぐに解決策を生み出そう、と。"

      • 書くことで課題を定義する

    • 2. 分解する

      • 分解それ自体がアイデア創出の行為であり、サブ課題を見れば、その人が課題を解決するカギだと信じている要素がわかる

      • 分解するプロセスそれ自体によって、課題の中にすでに存在する解決策が少しずつ見え始める

      • 専門家に話を聞いて、意見を求める

        • 専門家はなぜその課題が存在するのか、他の人が過去どんな方法で解決を試みたか、すでに何か存在するのか が説明できる

      • サブ課題を見直す

        • 8割テスト

          • サブ課題をすべて解決したら、課題全体の8割以上を解決したことになるだろうか?

    • 3. 成功した既存の解決策を探索する

      • 戦略的模倣

        • 新しいけど、なじみのあるもの

      • 「箱の外」の思考

        • 「ブレインストーミング」で最高のアイデアは生まれない

          • ブレインストーミングを真っ向から否定してて良かった。個人の思考から始まる

      • 「別領域」で過去にうまくいった解決策は何か?

        • 謙虚な姿勢から始まるということだ。 自分は答えを知っていると思い込まずに、いつかどこかで誰かが自分よりも優れた方法を考案したかもしれない、と

      • 「試行錯誤」に頼ってはいけない

        • 悪い実験は、できる限り避けたい

          • 科学者は実験を「実行」することより、それを「設計」することに多くの時間をかけている。失敗を恐れてはいけないが、失敗を求めるのも間違いだ。

      • 「汎用検索」「部分検索」「並行検索」

    • 4. 全体が調和するように組み合わせる

      • 急いで生み出したアイデアの価値は低い

      • 「新しいアイデアなんてものはない。そんなものはありえない。私たちはただ、古いアイデアをたくさん集めて、頭の中の万華鏡のようなものに放り込むだけだ。万華鏡を回せば、新しく興味をそそる組み合わせができる。私たちはいつまでも万華鏡を回し、新しい組み合わせを際限なくつくり続けている。だがそれらの組み合わせは、大昔から使われてきた、見慣れた色つきガラスの破片でできているのだ」(マーク・トウェイン)

      • 外の目を入れる

        • フラットに課題を捉えられる

  • 好奇心が根っこ

    • 最近、好奇心の結果に対してオチンギンをもらっているような気がしてきている

    • 探索するにも好奇心がいるのかもしれない

  • 「発明とは見抜くことであり、選択することなのだ」

    • 選択の科学とここでリンクするのか〜〜


最近1ヶ月に1-2冊のペースになっていて余裕のなさを感じる。

ようやく少し一息つけそうなので、積読を解消していきたい。

追記)最近読んだこのnoteも新規プロダクト立ち上げの参考にしている

  • 「誰のどんな課題を解くのか、を可能な限り解像度が高く理解した方が良い。しかし、ソリューションをその解像度に揃える必要は必ずしもない」

  • 「どんな仮説検証をするのかが明確であった方が良い」これはほぼ額面通り正しいのですが、「ある程度創発的な検証が含まれていてもいい」

  • 「できるだけ小さなMVPを市場に投下するのが良い」これも絶対的に正しいのですが、実情として「MVP(Minimum Viable Product) が期待しているほどは小さくならない」ということがあります

  • 「CPF/PSF/…/PMFを順番に検証していく」フェーズをそれほどしっかりと区切って認知して、ステップごとに進む、というほど綺麗なことができません。

「このフレームワークでうまくいく!」というのは幻想で、フレームをうまく活用して思考をショートカットしつつ、実態に合わせていく柔軟な考え方が必要だと日々感じる。

THINK BIGGERのような原理原則に近い考え方汎用性が高く、再現性も高い。久々に考え方を整理して、アップデートできた気がした。

おわり

@migi3
しまね生まれ しまね育ち とうきょう在住 駄文書く&プロダクトづくり