バリューのある仕事をすること

  • イシュー度
    • 自分の置かれた局面で答えの出す必要性の高さ
  • 解の質
    • イシューに対してどこまで明確に答えが出せているか

※issueとは「根本に関わり白黒の付いていない問題」と「2つの集団で決着の付いていないもの」を表す

①大量の仕事を沢山こなして一つ当てるというタイプ
生産性が低くてダメ、根性に逃げてはいけない

②イシューを見極めて解の質を上げていくタイプ
これがバリューのある仕事、圧倒的な生産性への唯一の道
このためにはイシューからはじめる必要がある

イシューから始めるアプローチ

  • イシュードリブン
    • 本当に答えを出すべき問題（イシュー）を見極める
  • 仮説ドリブン①
    • イシューを解ける粒度まで砕いて、ストーリーの流れを整理する
  • 仮説ドリブン②
    • ストーリーの検証に必要なアウトプットのイメージを描き、分析を設計する
  • アウトプットドリブン
    • ストーリーの骨格を踏まえて検証する
  • メッセージドリブン
    • 論拠と構造を磨いて文書化する

イシューの見極め方

まずは以下をはっきりさせる

  • 何に答えを出す必要があるのか
  • そのためには何を明らかにする必要があるか

そこから咲の検討に大きく影響を与えるものであること

相談する相手を持つ

そのイシューがインパクトがあるかどうかを判断するには、その分野の経験を持っていて「見立てる力」が必要になる

  • 知恵袋的な人を持つこと
    • 課題領域に関して直接の経験を持っている人
    • 研究所
    • シンクタンク
    • etc…

仮説の立て方

ふんわりと方針を決めるよりも強引にでも仮説を立てて検証をはじめたほうが早く進む
そのためにはスタンスを取ること

その仮説に対するスタンスから生まれる疑問がイシューとなる

  • 答えを出すことできる
    • 仮説が単なる設問をイシューにする
      • 仮説はYes / Noで答えられるQ&Aになるようにすること
  • 必要な情報や分析すべきことがわかる
    • 仮説を立てなければ何を議論してどんな答えを出そうとしているのかが明確にならない
  • 分析の解釈が明確になる
    • 分析結果が十分なのかがわかる

イシューを定義する際には…

  • 主語と動詞を書く
  • 「WHERE」「WHAT」「HOW」で書く
    • 「WHY」には仮説がなく、何を白黒はっきりさせるのかがわからない
  • 比較表現をいれる
    • なにを対比しているかが明確になる

よいイシューとは

  • 本質的な選択肢である
    • 答えが出ると咲の検討方向性に大きく影響を与える
  • 深い仮説がある
    • ここまでスタンスをとるのか、というところまで決める
      • 検証をすれば価値を生むと誰もが納得できるもの
        • 常識を覆すような洞察
        • 新しい構造で世の中を説明する
        • etc…
  • 答えを出せる

本質的な選択肢である

  • 右か左かを決めたら大きく意味合いが変わること
  • 鍵となる質問である

cf. 診断フレームワーク「書く技術・考える技術」

なんちゃってイシュー

一見もっともらしいが、その局面で答えの出す必要のないもの

  • 「無理してやる必要がなかった」と後悔しないように
    • 「本当に今それに答えを出すべきなのか」
    • 「本当にそこから答えを出すべきなのか」

イシューは動く標的

イシューは「今、答えを出さなければならないもの」である

  • 会社、部署、チーム、あるいは今日、明日、時間ごとに、あるいは話している人ごとにイシューは変わるものである
  • 自分にとってのイシューが他人にとってイシューでないこともままある
  • 大きな意思決定により周りのイシューが根こそぎイシューでなくなることもある

深い仮説がある

常識を否定する

一般的に信じられていることを並べて、そのなかで否定できる、あるいは異なる視点で説明できるものがないかを考える
ようは直感に反したものを探す

ex. 地動説、相対性理論、ビッグバン理論

その分野における「常識」を手に入れるには、その分野に詳しい人にインタビューするのがよい。

新しい構造で説明する

見慣れたものに対して、これまでにない理解を与えると衝撃を与えられる

2つ以上の既知の情報に新しいつながりを発見する

  • 共通性の発見
    • 比較軸として利用できる
  • 関係性の発見
    • 片方がわかればもう片方を推測できる
  • グルーピングの発見
    • それまではとは違う洞察を得られる
    • ex. セグメンテーション
  • ルールの発見
    • 2つ以上のものに何らかの普遍的なしくみ・普遍的な関係があることを示す
    • 深い洞察が得られる

cf. ピラミッドにおける左右の関係「書く技術考える技術」

  • 分類（重要性の順序）
  • 因果関係（時間の順序）
  • 構造（構造の順序）

otakumesi memo

この部分の話、
Web開発の現場では「ユーザーストーリー」などがあたるのだろうか…？
あるいはシステム設計…？
データドリブンな仮説検証、あるいはリーン的な？

答えを出せる

ありふれているが、解く方法が未だに存在しないモノは手を付けないほうがいい。
本当に既存の手法、現在着手しているアプローチで答えを出せるかどうかを見極める必要がある。
誰もが答えを出すべきだと感じていて「手のつけようがない」と思っている問題を「自分の手法なら答えを出せる」と感じる「視覚的なイシュー」を発見することが必要。

学術や事業の分野を超えた経験が物を言うのはこの「自分だけの視点」を持てるからである。

イシュー特定のための情報収集

一次情報に触れる

  • 現場に立つ
  • ユーザーに聞く
  • 当事者に聞く
  • その場所へ赴く
  • 元のデータを見る

面識がなくても外部の専門家へインタビューを申し込みむのも選択肢のひとつ

cf. リーンスタートアップ、社会学的なフィールドワーク、インタビュー、知的複眼思考法

基本情報をスキャンする

ようは常識や基本的なもののような通年的なものをMECEに確認する

  • 状況
    • 事業の上流・下流
    • 業界構造
    • 技術・イノベーション
    • 法制・規制
    • etc…
  • 対比情報
    • 競争関係
    • 新規参入者
    • 代替品
    • etc…
      • etc..

数字を確認する
この数字を知らなきゃ議論しても仕方ないとなる数字はすべて把握する

ex.

  • 規模感
  • シェア
  • 営業利益率
  • 変化率
  • KPI
  • etc…

問題意識を確認する
歴史的背景などを踏まえた業界に通じる常識や、課題領域に通じる一般的な通年などを把握する

フレームワーク
課題にかかわる領域がこれまで解決に利用してきたフレームワークなどを把握する

知りすぎない、集めすぎない

  • 情報収集はあるところで頭打ちになりやすい
  • 知りすぎると「自分ならではの視点がゼロに近づきがち」
    • ほどよいくらいに止めておくこと

イシュー特定のためのアプローチ

  • 変数を削る
    • 要素を削ってみたり、固定してみたり….
      • ようは微分したり、偏微分だったりとか？
      • 抽象化とかも方法の一つ
  • 視覚化する
    • 構造やプロセスを図示したり、空間（地図）を図示したり、グラフなどにあらわしてみたり…
  • 最終形から辿る
    • 「最後になにがほしいのか」から辿っていく
      • cf. 「生産性（著：伊賀泰代）」のブランクを埋めてく方式、ロジックツリー
  • 「So What？」を繰り返す
    • イシューの候補に対して「だから、何？」を繰り返してより具体的にしていく
      • cf. 「書く技術・考える技術」の診断フレームワーク、なぜなぜ分析
  • 極端な事例を考える
    • 要素が多い場合に重要な変数を極端な値にするとどの要素が動きのカギになるのかがわかりやすい

これらを組み合わせてみる
たとえば、極端な値に振って視覚化してみるとか…

分析の仕方

イシューを見極めたあとに「解の質」を高める方法

  • イシュー分析
    • ストーリーラインづくり
      • イシューを分解して…
      • ストーリーラインを組み立てる
    • 絵コンテづくり
      • ストーリーラインの個々のサブイシューに対して必要な分析・検証のイメージをまとめる

cf. 「書く技術・考える技術」の「S→C→Q」みたいな、「創造の方法学」

イシューを分解する

イシューは大きな問題のため、分解する必要がある。

  • MECEであること
  • 本質的な固まりで切り分けて意味のある分解をすること
    • 似たようなサブイシューになって同じような検証をすることを避ける
      • ex. 売上×シェアと個数×単価、ユーザ数×ユーザあたりの打ち上げみたいな

問題のモデル化をする

イシューを分解することで全体像が見えやすくなり、優先順位をつけやすくなる

イシューを分解する型

ドメインの問題を分解する型を使う

  • 事業戦略立案なら

    • WHERE
    • WHAT
    • HOW

  • 脳神経科学なら

    • 生理学的（機能）
    • 解剖学的（形態）
    • 分子細胞生物学的（しくみ）

WEB業界なら…？

  • システム単位？
  • ドメイン単位？
  • 設計単位？
  • etc…？

型がない場合は逆算する

「最後にほしいもの」から考える

いつ誰がどこで…、なぜそれが既存のものよりも… → …
最後に何がほしいのかから考え、必要となる要素を何も仮想的にシミュレーションする

cf. リーンスタートアップ

分解をした上でそれぞれに仮説を立てる

分解して見えてきたサブイシューについてもスタンスをとって仮説を立てる。
メッセージをすっきりさせるほどの必要な分析のイメージを明確にすることがでｋる

フレームワーク

分野ごとに分析のためのフレームワークが存在しているが、フレームワークにこだわりすぎて無理やりフレームににはめ込んで本質を見失ったり、自分の洞察や観点を生かせなくなったりしないこと。

「金槌を持っていればすべてがクギに見える」

ストーリーラインを組み立てる

「仮説が正しいとすれば」という前提でストーリーを作る

  1. 必要な問題意識・前提となる知識の共有（S→C→Q）
  2. カギとなるイシュー、サブイシューの明確化（キーラインポイント）
  3. それぞれのサブイシューについての検討結果
  4. 総合した意味合いの整理

ストーリーラインづくりは脚本作り、ネームづくり（筋書きやラフなイメージをまとめる）に近いプロセスである

ストーリーラインの役割

ストーリーラインは検討が進み、サブイシューに答えが出る、新しい気づき・洞察が得られるたびに書き換えて磨いていく

  • 立ち上げ段階
    • カギとなるサブイシュー（見極めどころ）を見つけ、何を検証するためにどのような活動をするのかという目的意識を揃えて、検討に範囲を明確にする
  • 分析・検討段階
    • イシューに対する仮説の検証がどこまでできているかが明確になる。
    • 分析結果や新しい事実が生まれるたびに肉付けをして刷新する
  • まとめの段階
    • サマリーや要約になる

ストーリーラインは生き物であり、分析もデータ収集もこれに従う

何も浮かばない場合…

  • イシューと仮説だし
    • 主語と動詞を明確にして、何を言おうとしているのかを箇条書きで明確にする

ストーリーラインの型

ピラミッド構造となる2通りのロジック構造の型がある

WHYの並べ立て

ex.
以下の理由で案件Aに投資すべきだ

  • 「なぜ、案件Aに魅力があるのか。…」
  • 「なぜ、案件Aを手がけるべきなのか。…」
  • 「なぜ、案件Aを手がけることができるのか。…」

cf. 帰納的「書く技術・考える技術」

空・雨・傘

ex.

  • 空… 「西の空が晴れている」
  • 雨…「今の空の様子では、当面雨がふることはなさそう」
  • 傘…「だとすると、今日は傘を持っていく必要がない」

cf. 演繹的「書く技術・考える技術」

otakumesi memo

システム設計でも、関係やI/Oでつながりを表現できそうだなーとか思った。
あるいは、ユーザーストーリーをからトップダウンで考えるとか？

絵コンテとは

イシューが見え、ストーリーラインができれば、グラフや図表などの分析のイメージをデザインする。
memo: （Web系ならペーパープロトタイプ？落書き的な画面遷移図？）

絵コンテとは「最終的に伝えるべきメッセージ（イシューの仮説が証明されたもの）」をどういう結果であれば納得できるか、納得させられるかを考えて、ストーリーラインに沿って前倒しで作ったもの。

絵コンテは紙を縦に割って、サブイシュー（ストーリーライン上の仮説）、分析イメージ、分析手法、情報源なおをまとめていくとよい。

ex.

軸を整理する

分析では適切な比較の軸がカギとなる。

どのような軸で何と何を比較するとそのイシューに答えが出るのかを考える。
定量分析だろうと定性分析だろうと、どのような軸で何と何を比べるか、どのように条件の仕分けを行うが分析の本質。

cf. 創造の方法学

定量分析の3つの型

  • 比較
    • なんらかの共通の軸で2つ以上の値を並べる
    • ex. 棒グラフ
  • 構成
    • 全体に対する部分の比較
    • 「何を全体として何を抽出した議論をするか」の意味を考えることが軸の整理となる
    • ex. 構成比
  • 変化
    • 同じものを時間軸上で比較すること
    • 「何と何を比較したいのか」という軸の整理が重要
    • ex. 折れ線グラフ

どんなチャートでもこの軸を組み合わせて作られる。

分析は比較する条件である「原因」と評価する値である「結果」の掛け算から構成される。
つまり、軸を考えるとは原因側と結果側で何を比べるかを考える事である。

分析の軸を考えるときの方法の例

  1. 比較の際の条件を出せる限りすべて並べる
  2. 似ているものを束ねる

イメージを具体化する

軸の整理が終わると、具体的な数字を入れて分析・検討のイメージを作っていく。

数字の入ったイメージを作る

  • 最終的にどの精度のデータが欲しいかをイメージする
    • 50%か60%かを見極めようとしているときに、0.1%の精度はいらない

分析の意味合いとは「比べた結果違いがあるかどうか」となる。

  • 典型的な違い
    • 差がある
    • 変化がある
    • パターンがある

方法を明示する

絵コンテを作り終えたあとに、そのデータをどうやって取るのかを明示する必要がある

  • どんな分析手法を使ってどんな比較を実現するか
  • どんな情報源（データソース）から情報を得るのか

科学の世界では大きな発見の前に大きな手法の開発があることが多い
システム開発でも多い…？

欲しいものからアプローチをすれば「何が足りていないのか」「何が必要なのか」がわかる
手法から考えるとその既存の枠から出ることができない

アウトプットを生み出す

いきなり検証をはじめない

それぞれのサブイシューの軽重を見極めてもっともバリューのあるものから分析をおこなう。

必ずはじめに粗くても結論や骨格に影響の大きいものの検証ができるかの答えを出す。
カギとなる「前提」と「洞察」の部分

理想的な実験とは論理も実験も簡単で、どんな結果が出ても意義のある結論ができるものである

  • 自分たちの仮説のみが正しいと言えることばかり集めるのはダメ
  • 反対の説（対案）ですら実は自分の説の方が正しく解釈できることを証明する必要がある

トラブルをさばく

  • 重要なものにはヘッジをかけること
    • 二重三重の検証の仕掛けを考えて、一つ目が転んでもなんとかなるようにする

ほしい数字が出ない

  • 構造化して推定する
    • フェルミ推定的な式を組み立てる
  • 足で稼ぐ（直接検証する）
    • ex. 出店場所の検証（日中に歩いている人の人数を実際に調査）
  • 複数のアプローチから推定する
    • 全体の値やセグメントの値などの他の変数を使って逆算して比較する
      • 複数の逆算結果からおおよその近い値を推定できる

自分の知識や技ではうまくいかない

  • 他力を活用する
    • 経験者に話を聞くことで知恵やアイデアをもらえるかもしれない
  • 期限を決めて、そこを目安に解決の目処がつかなければさっさよ手法に見切りをつける
    • 手法に愛着がある場合でもこだわりをほどほどにしなければならない

軽快に答えを出す

いくつもの手法を持つ

  • 方法であれ、考えであれ、人であれ一つのものに固執しないこと
  • バリューを生み出すことに直接関わる資質
    • 持っている手札の数
    • 自分の技となっている手法の豊かさ

いくつもの方法を組み合わせたり、既存の手法に自分なりの視点を加えたりすることで初めて答えに近づく

だからこそ、使える手法が大いに越したことがなく自分の仕事の関連する分野の手法には一通りなじんでおくべき

回転数とスピートを重視

  • 丁寧にやりすぎず60%ほどの完成度で作り上げて、はじめから見直すほうがよい
    • 数字をこねくり回さずに手早くまとめる
      • 1回の完成度よりも取り組む回数（回転数）を重視する

cf. MVP、プロトタイピング

memo: アジャイル的な考え、リーン的な考えに近い気がする（？）

受け手にとって十分なレベルを自分の中で理解しやりすぎないようにする
memo: システムの設計も同様

「本質的」「シンプル」を実現する

検討報告における最終的なアウトプットは「聞き手・読み手と自分の知識ギャップを埋める」ためにある

  • 受け手には次のようになってもらう必要がある
    • 意味のある課題を扱っていることを理解してもらう
    • 最終的なメッセージを理解してもらう
    • メッセージに納得して行動に移してもらう

聞き手を想定する時、聞き手は専門知識は持っていないが基本的な考えや問題、イシューを共有し、結論を伝えれば理解してくれると信頼すること

要は賢いが無知だと想定する

ストーリーラインを磨く

  • 論理構造を確認する

    • ピラミッド構造、WHYの並べ立て、空・雨・傘を確認し、スッキリ整理できているかを確認する
      • ex. 「書く技術考える技術」
    • 分析の結果全体のメッセージに影響が出るときは全体のストーリ構造を見直す必要がないかを確認する
      • 仮説が崩れたら発見だ！と思うくらいでよい
        • 誰も想定していない答えのほうがインパクトが強いため

  • 流れを磨く

    • 紙芝居形式の荒磨き
      • めくりながら説明をして話の順番やメッセージのメリハリを修正する
    • 人を相手にした細かい仕上げ
      • 本番同様のリハーサルをする
      • 素朴な疑問を得るためにもプロジェクト、テーマ、内容などを一切知らない人に見てもらうとよい
  • エレベータテストに備える
    • CEOとエレベータに乗り合わせて降りるまでの間に簡潔に説明できるか

チャートを磨く

  • チャートの構成要素

    • メッセージ（チャートの説明）
    • タイトル
    • サポート（実際の図など）

  • 優れたチャートが満たす条件

    • イシューに沿ったメッセージがある
    • （サポートの）タテとヨコの広がりに意味がある
    • サポートがメッセージを支えている

チャートを優れたものにする

  • 1チャート・1メッセージを徹底する
    • 「最近の動向」といった意味のないメッセージは不要
      • このチャートでなにをいいたいのかを書く
  • チャートがひとつのメッセージしか無いことを確認する
    • パッと見て何をしてるのかがわかるレベル
  • サブイシューとつながっていることを確認する

    タテとヨコの比較軸を磨く

    答えを出すための適切な比較ができているかどうか
  • 軸の選択をフェアにする
    • 恣意的な比較が見つかると信頼性が落ちる
  • 軸の順序に意味をもたせる
    • プロセスの順序、アルファベットの順序、etc..
    • ex. ピラミッドの横の関係の順序「書く技術考える技術」
  • 軸を統合・合成する
    • 重なり合っている条件を比較している場合がないかを確認する
    • あった場合はMECEに整理する
  • 軸の切り口を見直す
    • 明確なメッセージにつながらない場合は切り口にノイズが混ざっている可能性がある

メッセージと分析表現を揃える

  • 様々なチャートの中から他に適した表現方法がないかを確認する
  • 軸の刻みが適切化を確認する
    • ex. 差分の表現、指数の表現、相対…

仮説を持って絵コンテ作りをした上で分析・検証すると、結果は完全には一致しないのが普通である。
このズレは貴重な情報で、それを元にメッセージやチャートを磨き込んでいく。

感想

これまで読んできた本のいくつかと重なるものがあって、
問題解決の総まとめ本を読んでいるように感じました。

私はWebエンジニアであるため、そのまま利用するということはできないと思いますが、
読みつつ「こういうふうにすれば、あの使うことができるんじゃないか？」と考えるのが楽しかったです。

本書の考え方は割りと多くのWeb開発者が納得できるやり方が多いんじゃないかなと思います。

読んだままで終わらたくないためにブログをはじめたこともあって、すぐにでも実行に移そうと考えてます。
とりあえず本の内容を元に「こうやって運用してみよう」という問題解決プロセスをまとめました。

それを運用してみて、効果を感じられた暁にはブログにまとめてみようと思います。