Skip to content

Instantly share code, notes, and snippets.

@kgbu
Created July 1, 2015 06:31
Show Gist options
  • Select an option

  • Save kgbu/1c689573f3709d3b51f8 to your computer and use it in GitHub Desktop.

Select an option

Save kgbu/1c689573f3709d3b51f8 to your computer and use it in GitHub Desktop.
「Issueからはじめよ」読書メモ20150701

#️ 「Issueからはじめよ」読書メモ

5つのキモ、というか常識をすてなくてはいけないところ

  • 「問題を解く」より「問題を見極める」
  • 「解の質を上げる」より「イシューの質をあげる」
  • 「しればしるほど知恵が湧く」より「知りすぎるとバカになる」
  • 「1つひとつを速くやる」より「やることを削る」
  • 「数字の桁数にこだわる」より「答えが出せるかにこだわる」

IMHO: こういうのは他人との差別化であるべきとは思わない。砂場で全員に叩き込まれるべきだ。その上で遊ぶ人、歌う人、絵を描く人がいてもいいじゃないか。彼らは多様性を生み出す。それは方法論の埒外だ。

IMHO: コンサルタントの秘密、をぎゅっとコンサイスにする。その過程で滋味みたいのが抜けているがそれでいいと思った。

生産性とは

アウトプット / インプット = 成果 / 投下した労力・時間

で、成果とはなにか? バリューのある仕事とはなにか?

バリュー = Issueを解決すること * 解決の質の高さ

Issueとは何か?

  • 2つ以上の集団の間で決着のついていない問題
  • 根本にかかわる、もしくは白黒がまだはっきりしていない問題

そう、脳みそこそがおれの考えるissueだよ。ゼラズニーの光の王の転生しすてむこそがおれのissueであるよ。

問題は、それについて「悩んで」いるかどうかだ。 悩んでいるのであれば、何もoutputは出ない、、という状況を受け入れていることになる。

仕事としてバリューを生み出すようになるためのベストプラクティス

自分の労働の量、質にこだわるのではなく、issueへの嗅覚を高めることだ。 で、issueの見極めができるのが上司やメンターである。そこに相談するのが近道である。 本を読む、というのもそういう意味で近道であることもある。乱読なら無意味。

Issue drivenの仕事のやりかた

  1. 今本当に答えを出すべき問題=イシューを見極める
  2. イシューを解けるところまで分解し、イシューの構造、作業の流れを整理する
  3. 作業のストーリーを検証するために必要なアウトプット(テスト入力も)のイメージを描き、作業の設計を分析する
  4. ストーリーの骨格を踏まえつつステップバイステップで検証する
  5. 論拠:イシューの構造とそれを解決する作業の構造を整理して、それができていることを示すアウトプットと整合させてレポートにする

Issueの見極め

メンターに問題の取捨選択をしてもらう

仮説をたててそれを検証する方向でIssueを整理する

仮説は言葉にする

明確化の手段として。人間がロジカルかつ客観的に対応できるのは言葉が必要だ。式も言葉である。図はその点論理解釈のオーバヘッドと誤差をはらむ。diagramやフローチャートやプログラムも式ではあるがほとんどそれは成果物。

ビジュアルに把握できる人もいるが、言語をベースにしないとやっていけない人との基盤として言葉が重要。

言葉で表現するときのポイント

英語でかけ。(命題論理だと思え)

  • 主語と動詞を入れる
  • Whyは後でわかることだからほかのWでくみたてる
  • 比較表現を入れる:命題にする

良いissueの条件

  • 本質的(パレート最適、でもある。アムダールの法則に照らしてインパクトがある)root causeである。その後の世界線をおおきく切り替える。
  • 深い仮説(命題)がある
  • 答えが出せる:命題であるだけではだめで、答えを得るプロセスが実現可能である。

洞察のパターン

  • 類似性の発見
  • 関係性の発見(同じ、反対、排他、、)
  • グルーピングの発見(ひとつのグループのなかでのカテゴリー分け)
  • ルールの発見

こういうのは洞察を導くのが主な仕事であるビッグデータの人にも役立つ。

結局、しぼりこむとこういうことだ 問題を100思いついても、良いissueは1つぐらいしかない

理想としては、他人が見逃している「答えを出せる可能性」に着目すること それがセレンディピティーにつながる。

だから、seedsの人たちはそういうことを考える。 たしかにブレークスルーがあれば、なんらかのissueが「生まれている」ことは確かなのだ。それが良質であるかどうかはともかく。

実践

一次情報でネタと仮説を仕込む

2、3日で終わるようにして、全体のサイクルを何回も回すべき。 現場とは何か、というセンス。 大抵は現場は自明。でもそこに行ったことがある人は少ない。

本などの「整理された情報」というのはバイアスから逃れられない。 他人の手のひらの上でにっちは探せない。

関係のないものの同居 関係ある「はず」のものの断絶、、、「はず」からのズレを現場に求める。 だから、「はず」もわかっていないといけない、これは経験で積み重ねるしかない。

現場というのは他所にあることもある。大学や研究所に電話インタビューだってできるのだ。きちんと説明する手間を惜しんではならない。

現場の感覚を持った上で「偏りのない」サーベイをさらっとする

自分のポイントにあまりとらわれないバックグラウンドを整備する。 とらわれないところが大事。 ここは機械的にやるべき。業界ごとにテンプレートがある。他人のサーベイが参考になる。 論文のリストの最大公約数みたいなものでいい。

そこで汲み出すものは

数字:有効性の検証に使える具体的なものはこれだけ

問題意識:共有されているissueの候補

フレームワーク:業界での知識の整理パターン

これからずれるにしても、利用するにしても。

で、知りすぎない、というかそこに時間をかけない。知識ではなくIssueのbrush upが目的 知りすぎると「自分なりの視点」が相対的に小さくなってしまう。

タブーを知りすぎることによる無意識の制約が発想を限定してしまう。

フレームワークの使い方

整理:もれなく、むだなくMECE

training

ストーリーラインへの道:

漠然としたアイデアしか浮かばない人は 主語と動詞を明確にし いいたいことを箇条書きで明確にするイシューと仮説だしを日々行う

作法

  • WHYの並び立て
  • 空・雨・傘:現状の課題の確認・課題の深堀り・結論

絵コンテ:分析イメージづくり

イシューを分解し、 ストーリーラインを組み立てる で、今度はストーリーラインの個々のサブイシューに対して必要な分析・検証のイメージを組みたてる

大づかみに結果としてほしいデータからback propagationする

どんなデータがあれば個々のサブイシューを検証できるのか、というリスト。

分析

分ける 比較する:何を軸として比較すれば結論が言えるのか

数値:比較、構成比、変化(経緯)

比較の意味合い:結果が違う。ということ。値に差がある。変化が出る。パターンがある。

どうやってデータをとるか

その分野の技を習得する、ということ。近道はない。 しかし、必要なデータがわかっているから、習得の目的意識が違う。あらたに開発する意欲も湧く。

知覚系の特徴とイシューの関係

  1. 閾値を超えない差は結果に結びつかない。0か1か
  2. アナログな差もうまく認知できない。断絶があるか、質、カテゴリが違うものを認知する。
  3. 理解、とは情報をstoreするのではなく、つながりができること。手持の概念と繋がらないものは認知できない
  4. 情報が何度もつながることが記憶になる。同じパターンではなく、つながるahaが繰り返されないといけない。(つながる:関係の認識。同値性の認識、、、、)プレゼンの中で「つながる」ことを何パターンか繰り返すことで相手を説得し、記憶してもらえる。AはBと同じ、AはBの2倍、AとCは相補的、、とか繰り返すうちにAが刻み込まれる

アウトプットを生み出す戦術

  • いきなり飛び込まない:いきなりworkをしない。Issueを絞って、ストーリーをたてて、brushupして、データが取れるみこみがついて、、Go
    • 一番大事なissueについての仮説が成り立っていることから裏をとっておく
      • そしてそれを検証することは、白黒がついた時点で知見としての価値がある。
      • 仮説を成り立たせることに意味があるのではない。重要な仮説はそれが否定されても意味があるし、ある局面では仮説がなりたたないことがもっともらしいことすらある。だからこれまではっきりしていなかったのだ。それをバイアスのかかった目で見るとデータを歪曲する恐れがでてくる。
    • あとは工数で割り振っていい
    • 一番大事な洞察こそプレゼン、論文のタイトルになる
  • 2重、3重の検証のヘッジをかけておく
    • そのためにストーリー作りの検討があり、保証のある絵コンテを吟味することが必要
    • そのための時間(早めの仕込み)が大切。無駄なデータ取りや過剰なサーベイを避けることでその時間をつくる
  • ほしいデータがドンピシャで得られない
    • 推定のための構造化にとりくむ
      • フェルミ推定のトレーニングが役立つ
    • 足で稼ぐ。ランダムサンプルを集める。
    • 複数のアプローチを試す
  • 自分じゃデータが取れない
    • 人に聞きまくる
    • ある手法がだめなら見切りをつける。1週間で見切る。
      • いくつも手法を持つ
        • まわりのムードに流されない自信
        • 本質をみていて枝葉末節には一喜一憂しない
        • 関連する分野に首をつっこんでおく
  • 停滞しない
    • 手抜きがなければサイクルをなんども回すことが鍵。60%から先はあまり投資効果がない。60%が何なのかはストーリーやコンテに照らせばわかる。
    • 解の質でもっとも重要なのは「答えをだせるかどうか」そのぎりぎりでやめておくことが生産性の鍵である
    • そして、そこでやめることが�発表のスピードにつながる。

アウトプットの戦術

論文、プレゼン

  • 本質的、シンプル
  • 一気に仕上げる

アウトプットの目指すもの

  1. 意味のあるissueをあつかっていることを理解してもらう
  2. 最終的なメッセージを理解してもらう
  3. メッセージに納得して、行動してもらう

聞き手についての想定

  • 相手は完全に無知だと思え
  • 聞き手は高度の知性を持つと想定せよ

賢いが無知

その上でイシューに答えを出す、ということに注力する。これがシンプルで無駄がないということ。

なんとなくおもしろい、 多分大切

というものは扱わない。

複雑さはいらない。相手の意識を散らすもの、あいまいなものは排除する。

流れ、構造を明確にする。

アウトプットの構造

ストーリーラインのbrush up

  1. 論理構造を確認する:前提と演繹と結果(とissueの解決が一致)
  2. 流れを磨く(詰まるところはないか、あいまいではないか、補強が必要ではないか)
  3. 3分でやれるか。エレベーターピッチたりえるか。 4. 結論だけをとりだせるか 5. 特定の部分だけを説明できるか

論理構造

WHYの並べたては並列、、1つがくずれても全体に影響は小さい 空・雨・傘のタイプは決定的だが1つくずれればアウト いずれにしても要素にダブり・漏れはゆるされない

流れ:ひとつのテーマから広がり、収束する

リハーサルは必要 自分でビデオを見返すだけでも違う

エレベータテスト:論理構造のtreeを自由自在に刈り込み、広げる

これまでつみあげてきたピラミッド構造のストーリーがあれば、話の深さは階層として制御できる。

チャートも磨ける

  • メッセージ(イシューに沿ったもの:1チャート、1メッセージ)
  • タイトル(チャートの説明で良い。凝る必要ない)
  • サポート(チャート本体):メッセージを支えている。データとして広がり(意味のある比較ができる漏れ、重複のないカバレッジ)と深さ(インパクト)を持つ
  • 引用元

人がチャートを見てわかるのは15秒かかる。これがプレゼンのリズム チャートの軸のとりかた

  • フェアである(結果ありきの恣意的なフレーミングでない)
  • 軸の順序に意味をもたせる(パレート最適であり、それが一目でわかる)
  • 漏れ、ダブりがない

チャートはデータの取り方がまずいこともありうる。だからこの段階からさらにもう一回サイクルをまわせれば挽回のチャンスがある。

チャートとしての表現の工夫、、はいくつかあるが、結局はメッセージを説明しているか、ということが問題。その範囲でのみ工夫する。

犬の道とはべつの道

結局はここに書かれたことを真剣に取り組み、経験を積まねばなんの結果もでないし、犬の道を進むよりほかはない。

重大なIssueが存在する局面で、それを解決するために白黒つけるべきもっとも重大な命題をみきわめ、論理的な知力だけでなく経験と自分の知覚、そしてコネ、チームをフルに動員して命題を検証するデータを集め、その結果を行為に結び付けてもらうべくプレゼンする、この経験1回1回をつみ重ねるとき、この本が役にたつ。

そう思った。

だから、やってみよう、という気持ちになっている。

@kgbu
Copy link
Copy Markdown
Author

kgbu commented Jul 1, 2015

このメモは網羅的なものではないです。あしからず。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment