nDiki : 仮説思考

仮説思考 (hypothetical thinking)

2006年8月27日 (日)

問題解決プロフェッショナル 「思考と技術」

「理論としての汎用性」を満たすために、2つの思考<ゼロベース思考><仮説思考>と、2つの技術<MECE><ロジックツリー>、そしてそれらを総合した1つのプロセス<ソリューション・システム>の、5つの基本的な考え方に集約させた。-- 問題解決プロフェッショナル p.200

rimage:ISBN:4-478-49022-8

というのが今日1日で読み切った「問題解決プロフェッショナル 『思考と技術』」の内容である。

様々な種類の問題に向き合うときに使える本質的な考え方であるが、本書はビジネス書としてビジネスの視点での適用を中心に説明されている。

ゼロベース思考

<ゼロベース>思考とは、「既成の枠」を取り外して考えるということである。 — 問題解決プロフェッショナル p.19

自分の狭い枠を越えて思考するという話。否定的に要素よりも、可能性を求めること。 その際に「顧客にとっての価値」を考えるとよいとのこと。

本書が述べている中では、ゼロベース思考が一番抽象的で捉えずらい部分である。 言っているところは理解できるが、実際にそうい風に考えるのは最初かなりの意識が必要のように感じる。習慣化する必要がありそうだ。

仮説思考

必ずその時点での「アクションに結びつく」結論(仮説)を持ち、実行に移すという考え方。 まずなにか仮説を立て、SO WHAT? (だから何なの)を繰り返すことで、アクションに結びつく結論(仮説)を出していく。

またそうすることで、「背後の理由やメカニズム」を自然と考えるようになるとのこと。

具体的なアクションまで落としていくという点では GTD に通じるところがある。

またスピード重視なのも特徴だ。絶対的な正解のないビジネス世界において時間をかけてベストな策を模索し続けずに、ベターな解決策を見つけたらすぐに実行に移すこと。 情報収集に時間をかけすぎないこと。

ソリューション・システム

「課題の設定」「解決策の仮説」「解決策の検証・評価」という3つのステップによる解決策立案方法。

主要課題をロジックツリー(SO WHAT?)で個別課題にし、個別課題に対して個別解決策(SO HOW)を考え、YES/NO の結論(仮説)を出す。そしてこの個別解決策を組み合わせて主要課題に対する総合解決策を立案する。で、この個別・総合解決策を検証評価する。

一旦課題をMECE/ロジックツリーでブレークダウンし解決策を考え、また総合解決策にまとめあげるというステップが興味深い。

読んで

特に実行を重視している「仮説思考」が非常に興味深くまた、実践的に感じられた。 すごい考え方でいうところの「で、どうしたいの」だ。

また、「いつまでも辿りつけないベストな策」よりも「ベターな策で実行に移して、起動修正しながら精度を高めていく」方が効果的というスピード志向なところもカッコイイ。

早朝会議革命 - 元気企業トリンプの「即断即決」経営」での「稚拙でもいいから速く」というのも同様な考えからきているのかもしれない。

仮説思考についてはもう少し掘り下げて実践してみたい。

…… SO WHAT? (自分)

[ 読書ノート ] [ お薦めの本 ]

[ 8月27日全て ]

2006年8月31日 (木)

仮説思考トレーニング

Think! 2004 AUT. No.171 仮説思考トレーニング 最近仮説思考がマイブームである。

Think! のバックナンバーに仮説思考の特集があったので買ってみた。 Think! は薄いように見えるが中身が濃くて読み応えあり。

[ 8月31日全て ]

2013年7月19日 (金)

新生東横のれん街とか、仮説思考とか【日記】

新版 問題解決プロフェッショナル—思考と技術

2013年4月4日に渋谷マークシティに移転しグランドオープンした、東横のれん街に昼休みに行ってきた。なにこの移転前に比べての高級感アップ。もう一般人が入ってはいけないような贅沢感の中、鳩サブレーがやさしく出迎えてくれましたよ(まあよくみると見慣れたテナントが多いんだけれど)。

あと午後の仕事的には、こう、なんとなく見てみたいのでデータ抽出してっていうリクエストじゃなくて、まず仮説立ててみてよと思ったり(したのでそう伝えた)。データなんて取ろうと思えばいろいろな切り口があってキリがないので、きちんと何を裏付けたいのか考えた方が良い。で仮説立てて調査した結果、違ったっていうのは全然かまわない。そこから方向修正すれば良いのだから。

あと別グループで、分析分析分析にちょっとはまっているところがあるかな。分析して結果どういうアクションにつなげたいのかまで目線を上げた方がいいよね。

[ 7月19日全て ]

2016年6月21日 (火)

TOKYO CS JAM #2 「最高のチーム/組織づくり」

https://www.naney.org/nDiki/2016/06/21/CS-JAM.png

株式会社メルカリ主催の TOKYO CS JAM #2 に参加してきました。メルカリ主催の CSイベント参加は今日が3回目。いつもありがたく参加させていただいております。

CS JAM は

CS レベルアップのための企業混合 Study Session」をコンセプトにした Customer Support 業界 (Customer Experience, Customer Service, Customer Success なども含む)を盛り上げるための、勉強会、交流会的なコミュニティイベント — http://csjam.connpass.com/event/33258/

で東京開催は今回が2回目。メルカリは CS に関するイベントを積極的に開催されています。ネットサービス関連のスタートアップ事業/ベンチャー事業界隈での CS 交流については、メルカリが主導してくれているといっても過言じゃないと思います。

今回のテーマは「最高のチーム/組織づくり」。2つのセッションに分かれていて前半は「株式会社メルカリ 山田和弘氏」「ランサーズ株式会社 冨樫謙太郎氏」「freee株式会社 中島伸吾氏」によるパネルディスカッション。去年のスクーの「スタートアップCS担当によるカスタマサポートの極意」というオンライン授業の続編という位置づけで、その時のモデレーターだった大木しのぶさんが進行をされていました。トークと仕切りはさすがの超プロでした(スクーの宣言もうまく織り交ぜてたり)。

そして後半はそのディスカッションを踏まえての各テーブルごとのグループディスカッションです。

グループディスカッションの時間は30分。私たちの7人のテーブルは「組織文化」がお題でした。模造紙に発表内容を書き出すのも含めて30分はあっという間です。ディスカッションでは組織において「大切にしたい考え方」をきちんと共有・浸透させていくことが重要だという切り口で「ロールモデルとなる人を軸に組織に新しく入る人も含めて定期的に共有していく機会を作っていこう」という結論になりました。

30分ではもちろん議論が尽くされたとは言いがたいのですが、ほぼ初対面の方々と集中してまとめていくというワークは良い刺激になりました。

山田氏が締めの言葉で「ネットサービス業界とその CS 部門では、スピードある意思決定と対応が必要」と言われたのを聞き、今日のグループディスカッションの30分の意味をあらためて理解したのでした。

限られた情報と時間の中で不完全な状態でも答えを出して走りだし、フィードバックを得ながら方向修正しつつ進んでいく仮説思考の大切さを思い出させてくれる良い機会になりました。

何度か意見交換させていただいているメルカリの方と久しぶりにお話できたりもして今日は良い刺激を得られるセッションでした。メルカリの方々・登壇者の皆さま・参加者の方々ありがとうございました。

(画像は http://csjam.connpass.com/event/33258/ より。)

[ 6月21日全て ]

2021年7月3日 (土)

『イシューからはじめよ』

イシューからはじめよ (単行本)

問題に取り組む前に「今本当に答えを出す価値のある問題(イシュー)」かどうかを見極める。そしてスタンスをとり、イシューに対して「問い」ではなくいきなり「答え(仮説)」を出す。

という考え方を紹介しているのが『イシューからはじめよ』だ。いかにして意味のある仕事を選択し成果を出していくかかが説明されている。

「問題を見極める」重要性をここまで明確にしているのを読んだのは本書が初めてだ。仮説思考の徹底ぶりもすごい。この2点を常に意識できるようになれれば本書を読んだ価値があるだろう。

第1章から「イシューからはじめる」アプローチ

  1. イシュードリブン 今本当に答えを出すべき問題=「イシュー」を見極める。
  2. 仮説ドリブン イシューを解けるところまで小さく砕き、それに基づいてストーリーの流れを整理する
  3. 仮説ドリブン ストーリーを検証するためのに必要なアウトプットのイメージを描き、分析を設計する
  4. アウトプットドリブン ストーリーの骨格を踏まえつつ、段取りよく検証する
  5. メッセージドリブン 論拠と構造を磨きつつ、報告書や論文をまとめる

について各章でポイントを解説している。ソリューションを考え出してプレゼンテーションをまとめる際に何度も読み返したい。

個人的に刺さったのは「イシューと仮説は紙や電子ファイルに言葉として表現することを徹底する。」というくだり。やはり「文章で書く」こと大切だよね。

本書を知ったのは Developers Summit 2019 の「ITエンジニアに読んでほしい!技術書・ビジネス書大賞 2019」プレゼン大会。同年のビジネス書部門大賞となっている。その後2020年5月に思い出して読んだ。読書ノートをまとめてなかったので、読み直してみたのが今日だ。

本書では問題設定から問題解決案/論文のアウトプットまでが主なスコープで、読んだ多くの人がコンサルティング的な仕事を思い浮かべるのではないだろうか。

ネットサービスのプロダクトマネジメントでは、承認を得るのがゴールではなくユーザーに価値を届けて成果を出すのがゴールである。仮説検証の段階でプロダクトをリリースしてできるだけ早くフィードバックを得て、検査と適応を繰り返していく。ライトウェイトなループの中にうまく本書の考え方を取り込んでいきたい。

[ 読書ノート ] [ お薦めの本 ]

[ 7月3日全て ]

2021年8月19日 (木)

アンケートの前にしっかりと仮説を立てる

アンケートの分析で、アンケート回答に流されて何を調査しているのかを見失った分析結果出そうとしていたのを指摘した。

アンケートで新しい発見を得ること自体はいいのだけれど、調査の前にしっかりと仮説を立てていないと、何のための調査かわからなくなるよね。

[ 仮説思考 ]

[ 8月19日全て ]

2021年10月15日 (金)

第4回 『Hacking Growth グロースハック完全読本』を読む会 第2章 プロダクトの渇望度を測る (後半)

rimage:ASIN:4822255824

『Hacking Growth グロースハック完全読本』を読む会の第4回目。前回 第2章の前半で時間を使い切ってしまったので今回は第2章の後半だ。以下2回分のまとめ。

第2章は「プロダクトの渇望度を測る」。

プロダクトのコアバリューが最重要

グロースするには大前提として顧客に愛されるプロダクトでなくてはならない。価値あるプロダクトであり、顧客がその価値を感じた瞬間「アハ体験(本書ではアハ・モーメントとも)」に愛が生まれる。

プロダクトのコアバリューとユーザーのアハ体験を見つけるのは容易ではないが、プロダクトが「マストハブ」であると思われているかどうかは、著者であるショーン・エリスが開発したユーザーアンケート「マストハブ・サーベイ」と顧客維持率測定によって判別できるという。

プロダクトのコアバリューとアハ体験が発見できておりマストハブなプロダクトであれば、グロース実験へ進むことができる。

そうでなければ追加のユーザー調査(顧客インタビュー・実施調査・試作品・文言変更実験・プロダクト変更実験・ユーザーデータ分析)を通して、まずプロダクトのコアバリューとアハ体験を探すことになる。

プロダクトのコアバリューが無いままにバイラル性を作り込んで一時的にグロースすることができても結果失速してしまうであろう。

たった一人の分析から事業は成長する 実践 顧客起点マーケティング』でも良いプロダクトでなければプロモーションを工夫しても限界があると述べられている。

ただし SNS ではそう単純な話ではない。

プラットフォームの利用者がコアバリューであるソーシャルネットワークサービスなどは例外

と括弧書きで小さく書かれているのを見落とさなかった。 そうそう、 SNS にとっては多くのユーザーがいる事自体が大きな価値なんだよね。

ユーザー調査

すでにプロダクトがあり顧客があるならば、プロダクトのコアバリューとアハ体験を発見するためにプロダクト上で実験したりユーザデータ分析したりできる。

ユーザーデータ分析については「顧客体験のあらゆる側面からデータを集めて細かく分析」するために「適切な追跡機能を付加」し「ユーザー行動の緻密な全体像に仕上げ」て、ロイヤルユーザーに特徴的な行動を見つけるとある。分析を通じた予想外の発見のためにもデータ収集と実験が必要だという。

プロダクトが小さい初期段階ではデータ収集処理を網羅的に仕込んでいきやすそうだが、有限の資金と時間の中で進めていかなければならないだろうから、ほとんどの場合取捨選択が必要だろう。

「予想外の発見」とは結果である。予想できないからと闇雲にデータを集め眺めていてはいくら時間があっても足りない。やはり仮説思考で進めるべきだ。

[ 10月15日全て ]

About

Naney Naneymx

Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。

※本サイトの内容は個人的見解であり所属組織とは関係ありません。

Process Time: 0.0431550000000001s / load averages: 0.22, 0.29, 0.25