仮説思考―ＢＣＧ流 問題発見・解決の発想法 を読んで
今回この本を読んだ目的
- 仕事のアウトプットのスピードを上げるため
- 新規事業をより深い思考で考えるようになるため。
仮説思考とは
- 仕事ができる人は人より答えを出すのが早い。まだ十分な材料が集まっていない段階、あるいは分析が進んでいない段階で自分なりの答えをもつ。この答えを仮説と呼ぶ。仕事の遅い人の特徴はとにかく沢山の情報を集めたがること。
- 仮説思考とは物事を答えから考えること。課題を分析して答えを出すのではなく、まず答えを出し、それを分析して証明する。
- 常に自分の仮説を持つ。あなたの仮説は何かと問い続ける
情報収集
- 情報は集めるよりも捨てるのが大事
- 意思決定をするときは、今すでにある選択肢を狭めてくれる情報だけが役立つ。情報コレクターでは、アクションに繋がらない。
- 迅速な意思決定のためにはいかに絞り込むかという視点で情報収集すべき
- 網羅思考は非効率。
- 全ては相対的であり、自社が何をするかによって相手の動きも変わる。自分がこう動くという実行案志向、すなわち答えの仮説から入るアプローチをとるべき。
先に枝葉ではなく幹を作る
- 十分な分析や証拠がない状態でも問題に対する解決の方向性や具体的な打ち手まで踏み込んで、全体の仮説を作る。そうすると、ごく一部の証拠は揃っているけれども大半は証拠がない状態になり、自分が作った仮説を検証ために必要な証拠だけ集めればいいので、無駄な分析や情報収集の必要がなくなり、効率が良くなる
現状分析をするとこういう分析結果が得られるだろう。その中でもこの問題の真の原因はこれでその結果としていくつかの戦略が考えられるが、最も効率的なのはこの戦略だ。
- あまりに間違った仮説だと、ストーリーの正しさを証明するために証拠集めを始めた段階で仮説を肯定するような証拠がなかなか集まらない。そのため自分の作ったストーリーが間違いであることにすぐに気がつく。
空パッケージ
- 中身が埋まっていないスライドがたくさんあるパッケージ。具体的に言えば30枚くらいのスライドのパッケージのうち、大半が埋まっていないか、あるいは言いたいこと、証明したいことは書いてあるが、内容は書かれていない、あるいは分析されていないスライドの集まりのこと。
- ストーリーラインのみがわかるもの、そして言いたいことを言うために必要な資料のイメージだけのパッケージのこと。
- 自分が何を考えているか明白になる
- すでに証明されていることがわかる
- 何が足りないのか、そのためにどんな情報収集や分析をやらなければいけないかがわかる。
プレゼン
- 聞き手の立場で再構成する
- プレゼンを通して成し遂げたいことを明確にしたうえで、そのために何をどういう順番で話すのが良いのかを逆に考えて行く。
仮説構築のためのインタビュー技術
目的三種
1.業界、業務を理解する 2.問題を発見、整理する 3.仮説を構築、検証する
- 深く掘り下げた質問ができるかがカギ
- hogeと言われた時に、hogeかと納得するのではなく、hogeなのはなぜかちゃんと聞く。相手が言ったことに対して5w1hを投げる。
インタビューで大切なことはたいての本音を引き出すこと。インタビューは和やかに話を進めるだけではいけない。ときには相手の嫌がる質問も必要。相手に自分から気づいてもらう、あるいは勘違いしてたかもしれないと思ってもらうような質問の仕方をする。
インタビューが一件終わるたびに結果を咀嚼し、インタビューの目的と照らし合わせながら質問の内容を変えたほうがいいかどうかを考え、次のインタビューに臨む。相手の出方や答えに応じて臨機応変に質問の内容を変えていくのが重要。
インタビューメモ 頭の整理、メモの構造化をする。時系列→内容別 仮説の検証結果を書く。自分の仮説が相手に受け入れられたのか、拒絶されたのか、概ね受け入れられたけれど、いくつかの問題点を指摘されたなど。
他人とシェアするために、客観と主観を明確に区別する
ヒラメキ
- 顧客、消費者の視点 一人のユーザーになりきる
- 現場の視点
- 競争相手の視点 自分が競争相手の社員なら
- 両極端に振って考える どちらかに振り切ってみる
- ゼロベースで考える 目的にたいして、白紙の段階から考えようとする姿勢
よい仮説
- 掘り下げられている
- アクションに結びつく
- 問題発見が早くなる
- 解決策が早く立てられる
- 解決策が絞り込める
仮説の構造化
- イッシューツリー、論点の構造化、立てた仮説を検証して絞り込む
仮説を検証する
実験による検証(消費者刺激型開発戦略, テストマーケティング)
- 商品開発のスピードが重要
- まだ世にないコンセプトの商品を開発する場合市場調査はあてにならない。
- ユーザーは必ずしも自分のニーズを的確に表現できないし、自分でも何が欲しいのかわかっていないことが多い。
- コストが大きすぎるものは実験に向かない。
ディスカッションによる検証
- 分析による検証(まず仮説ありき、次に分析)
仮説思考力
- 仮説と検証の経験によって直感が生まれる。
- so whatを常に考える
- なぜを繰り返す
- 信じていない仮説の正しさを証明する
名言
- 世の中には、こうした思いつきの意見を言って仕事のやり直しを命じる上司が多く、部下が苦労している。
- 何も実行しないことが大きなリスクになる今日、いつまでも選択肢を広げる情報収集を続け、意思決定のタイミングを遅らせるわけにはいかない。
- リーダーに求められるものは、先見性、決断力、実行力
Reference from
- 作者: 内田和成
- 出版社/メーカー: 東洋経済新報社
- 発売日: 2006/03/31
- メディア: 単行本
- 購入: 29人 クリック: 187回
- この商品を含むブログ (161件) を見る
最近RTFMについて思ったこと
生産性を上げるためには情報へのアクセス手段が必要で、それこそwebであり、document, manualと呼ばれるものなのではないか。基本的にggrksとかRTFMとかなるたけ、同期的なコミュニケーションをなくすことで時間のロスをなくそうという方針があり、それには大いに賛成である。でもそもそもその参照先が間違っていれば、RTFM!と言っても、間違っていると言われてしまってかっこわるい。だからその参照先のドキュメントもしっかり書く必要がある。そして、自分が書くようなドキュメントはweb上の公式ドキュメントの補足のようなもので、極論ドキュメントは書かれない、つまり公式ドキュメントでこと足りるという状態になることが理想である。したがって、ドキュメントを書く場合は正確にかつわかりやすく書く必要がある。
じゃあどうすれば、わかりやすく書けるのかというとそれはおそらく、ありとあらゆる事象の命名をきちんとすることである。これはプログラミングにかぎらず他人と意思疎通を図る上でもっとも大事なことなのではないのだろうか。そもそもその語の命名がうまくできていなければ、その語が指しているものが何かわからずコミュニケーションとるまえに自分がその事象を理解することができない。だから命名ってプログラミングにかぎらず大事なのだと思った。それは商品名をつけたりとか、会社とか、人の名前もそうで、ものをある意味で定義する名前という概念になんか感動した。
https://www.slideshare.net/masuda220/ss-59756718
今日も一日、We Go Fast!!
（随時更新）gitよく使うやつまとめ
git addしたファイルをもとに戻すとき
$ git reset HEAD hoge.html
commitを取り消ししたいとき
$ git reset --soft HEAD^
or
$ git reset --hard HEAD^
空コミット
$ git commit --allow-empty -m "initial commit"
stashしているものを見るとき
$ g stash list
diff単位でstashするとき
$ g stash -p stash this hunk?
最新のmasterを今いるブランチに反映させたい場合
$ git rebase master
特定のブランチを今いるローカルで使いたい
$ git fetch origin -p $ git checkout -t origin/hoge
ローカルのブランチの名前を変えたい
$ git branch -m <old branch> <new branch>
そのキーワードの最新のdiffを見たい時
$ git show `g log -S hoge --oneline | awk '{print $1}'`
プルリク作成
$ hub pull-request --push -f -o -l wip -a tenshotanaka
直前のコミットに特定のdiffを含める
$ git add hoge $ git commit --amend --no-edit
GitHubでFork/cloneしたrepositoryを本家repositoryに追従する
$ git clone git@github.com:youraccount/hoge.git(forkしたrepositoryのurl) $ git remote add upstream git://github.com/hoge.git(本家のrepositoryのurl) $ git checkout master $ git pull upstream master
HEADのsha1を取得する
$ git rev-parse HEAD
特定のコミットに移動する
$ git checkout 3fa4g4
ref
Google HTML/CSS Style Guide を読んで意外だと思った点まとめ
HTML
-<!-- Not recommended --> -<a class='maia-button maia-button-secondary'>Sign in</a> +<!-- Recommended --> +<a class="maia-button maia-button-secondary">Sign in</a>
CSS
-/* Not recommended */ -border-top-style: none; -font-family: palatino, georgia, serif; -font-size: 100%; -line-height: 1.6; -padding-bottom: 2em; -padding-left: 1em; -padding-right: 1em; -padding-top: 0; +/* Recommended */ +border-top: 0; +font: 100%/1.6 palatino, georgia, serif; +padding: 0 1em 2em;
Do not use units after 0 values unless they are required. flex: 0px; /* This flex-basis component requires a unit. */ flex: 1 1 0px; /* Not ambiguous without the unit, but needed in IE11. */ margin: 0; padding: 0;
Do not use put 0s in front of values or lengths between -1 and 1. font-size: .8em;
-/* Not recommended */ -color: #eebbcc; +/* Recommended */ +color: #ebc;
Alphabetize declarations.
-/* Not recommended */
-a:focus, a:active {
- position: relative; top: 1px;
-}
+/* Recommended */
+h1,
+h2,
+h3 {
+ font-weight: normal;
+ line-height: 1.2;
+}
-/* Not recommended */ -@import url("https://www.google.com/css/maia.css"); -html { - font-family: "open sans", arial, sans-serif; -} +/* Recommended */ +@import url(https://www.google.com/css/maia.css); +html { + font-family: 'open sans', arial, sans-serif; +}
Teem Geekを読んで
チーム
チームは個人の生産性や幸福に直接影響する ソフトウェア開発はチームスポーツ
- 素晴らしいアイデアを隠しておいて、それが完成するまで誰にも話さないというのはリスクの高い大きな賭け
- 検証を重視した「早い段階で、高速に、何度も失敗せよ」の精神
- バス係数（「プロジェクトメンバーが何人バスに轢かれたらそのプロジェクトが破たんするか」という数値）を高める
邪魔されない時間があったとしても間違ったことをしていたら時間のムダ →できるだけ同じ空間で作業をする
邪魔されないまとまった時間が必要＝クリエイターの時間
A:「break point, tenshotanaka」 tenshotanaka:「ACK」
HRT
謙虚(Humility) 自分は絶対に正しいわけではない。常に自分を改善していく必要がある。
尊敬(Respect) 相手を一人の人間として扱い、その能力や功績を高く評価しよう
信頼(Trust) 自分以外の人は有能であり正しいことをすると信じよう。
あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるもの
チームでの振る舞い
ほんのすこしの手間が大きな見返りにつながる。組織を使う必要があることを認識し、組織を自分の仕事に使うことを学べば、組織を自分の要求に合わせられるようになる。
何かを成し遂げるための関係を構築する
- 批判の配分と対応
- 批判するべきなのは、オブジェクトではなく、振る舞い。
- 相手に対する疑問ではなく、自分の疑問として謙虚に聞く
「このメソッドの制御フローは完全に間違ってますよ。みんなが使ってる標準的なxzxyyコードパターンを使うべきです。」 →「この部分の制御フローがよくわからないのですが、xzxyyコードパターンを使えば読みやすくなるでしょうか？」
学習のための時間をのこす チームのなかで局所最適化してしまうと学ぶのをやめてしまうこと。 → コンフォートゾーンの外側に自分を置く
影響を受けやすくする 影響を受けやすくなれば、それだけ影響を与えやすくなる。弱いところを見せれば、それだけ強い人だと思われる。
文化
- チームの文化の基礎を作るのは、チームや会社に最初からいるメンバーたち。
チームの文化の定義、維持、制御に責任を持つのは、かならずしもリーダーではなく、チームメンバー。
強い文化は改善に対してオープンだが、害を与える急激な変化に対しては防御的。
強固な文化を構築すると「自己選択的」になる
優秀なエンジニアは他の優秀なエンジニアと働きたいと思っている。
- 優秀なエンジニアは優秀なチームリーダーを求める
- チームがエゴを持つのは大丈夫だけど、個人がエゴをもつのは良くない
- 意思決定をする際の衝突を解消するプロセスそのものではなく、衝突を解消するプロセスを持っていること、それを守っていることが重要
前向きな批判をしてくれる友達や同僚を見つけたら、貴重な存在なので、手放さないようにしておきたい
成功する文化のコミュニケーションパターン
同期的コミュニケーション(ミーティング) ＜ 非同期（チャット） できるだけ多くの人が、プロジェクトの文書からすべての情報を取得できることが重要
- ハイレベルの同期 集中するにはやらないことを決めること
効率的なミーティング
- dailyは15分なら問題ない。
- 新しいものを設計するのであれば、ミーティングに5人以上参加させてはいけない
1.絶対に必要な人だけを呼ぶ 2.アジェンダを作ってミーティング開始前に配布する 3.ミーティングのゴールを達成したら時間前でも終了する 4.ミーティングを順調にすすめる 5.ミーティングの開始時間を強制的に中断される時間(お昼休みや就業時間)の前に設定する
- FaceToFace を過小評価してはいけない。
leader
- エンジニアは代替可能な労働者ではなく、数ヶ月間かけて新しいチームに追いつく。
- リーダーの役割として最も重要なのは、執事や召使のように、チームに奉仕すること
友人関係とチームをリードすることを混同してはいけない。
リーダーの仕事は、チームの合意形成や方向性の決定を支援することであり、目標の達成方法はプロダクトを作る人が決定すべきこと
ミスをしたときに謝るということ、失敗したときに謝罪できるリーダーは尊敬される
エンジニアが相談をもちかけるのは、君に問題解決をしてほしいからではない。彼が問題解決をするのを手伝ってほしいから。問題を整理したり調査したりすることで彼が自分で問題解決できるように支援する
リーダーは、障害を取り除くための答えを知る必要はない、取り除ける人を知るだけでいい。多くの場合、適切な答えを知るよりも、適切な人を知るほうが価値がある。
チームに安心感を与えればリスクを取れるようにできる。
言えないようなことや知らないことがあれば、そのように伝える。→ 答えがわからないことを聞かれたときは答えがわからないと言う。
褒め言葉のサンドイッチは、本当に伝えたいメッセージを聞いてくれないので避ける。
フィードバックや批判を伝えるときは、メッセージが正しく伝わっているかが重要
時間を作ってチームの幸せを計測する
- 1対1のMTGのあとに「何か必要なものはある？」と質問する
- オフィスのそとに生活がないと考えてはいけない（家庭が大変な時期に余裕を与えておくと納期が迫ったときに長時間労働をしてくれたりするもの。）
- チームメンバーのキャリアを追い求める（有能なリーダーになりたければ、そのメンバーの暗黙的な目標を明確にして、どうすれば実現できるか考えるべき。）
- リーダーになって間もないころ（自分でやったほうが早くても、できるだけチームに仕事を任せる）
- チームをリードした後（自分で手を汚す。チームの尊敬を集めることができるし、仕事のペースが上がるから。特に誰もやらないような仕事を担当する。）
- 自分自身を置き換えようとする
- 事を荒立てるときを知る
- できるだけ多くの情報をチームに共有すべきだが、チームに関係ない組織の話でわずらわせる必要もない。
- チームのいいところをフィードバックする
- 優秀なリーダーは取り返しがつくかどうかの判断に優れている。
有害な人の対処
- やりたくないことを明確にする。
- 排除するのはあくまで振る舞いであり、特定の個人ではない。
- 完璧主義を回避する
- 返信した方がいい相手とそうでない相手を区別する
- 有害な人の放つ辛辣な言葉の中にも有用な知恵が埋もれている
長期的に考える
- 短期的にはチームの注意や集中を無駄にしても長期的にはプロジェクトにメリットがあるだろうか？
- その衝突は有益な方法で解決できるだろうか？ 上記の答えがノーの場合はできるだけ早くその振る舞いを中止する必要がある。
HRTをベースにした強い文化はかけがえのないもの。
技術的に貢献できる人は確実に交換可能。短期的なメリットのために文化を妥協する必要はない。
多くは、誤解や見当違いが原因。
立ち回り
誰かを説得するときは、あらかじめ賛同してくれる人を探しておいて、対象となる相手との会話の中でアイデアについて触れてもらう（提案や要求を出してもらう）と成功率が上がる。
攻撃的な仕事（ユーザーに見えるもの）と防御的な仕事（プロダクトを長期的に健全にするためのもの）があり、防御的な仕事で政治的な信頼性を獲得することはできない。→ 技術的負債がどれだけあっても、防御的な仕事に時間や労力の1/3~1/2をかけない。
自分の仕事に関係がなくても、他の人の仕事を手伝うようにすれば、いづれ誰かが喜んで手伝ってくれるようになる。
親切の経済で少しだけ信頼を稼ぐことができる。
忙しい人にお願いする方法
3つの箇条書きと行動要請のテクニック
問題について説明する（最大）３つの箇条書きと、一つ（一つだけ）の行動妖精がふくまれる 箇条書きは短い文章にする（改行なしで1行にまとめること） 行動要請もできるだけ短くすること
良いプロダクト
エンジニアは客観的に高品質で効果的なものが売れると思っている → 多くの人間は論理と感情を同じだけ使い、マーケティングの人間は感情操作に精通している。ソフトウェアに対する感情的な知覚に配慮しなければならない。一分後にどのように感じるか。
簡潔でよく考えられたユーザーインターフェース
プロダクトの最初の体験が超重要
ソフトウェアを技術系と非技術系の両方の人に使ってもらい、最初の1~2分を観察する。
アプリケーション速度（科学的に言えばレイテンシー）の重要性
成功しているソフトウェアというのは、問題を限定してそれをうまく解決したもの。あらゆる問題を下手に解決するのではなく、多くのユーザーの共通の問題をうまく解決している。
コードを書く側の都合ではなく、ユーザーに集中しよう。
- 複雑なことであっても、簡単なことをしているように感じられるようにするべき。
名言
- 「人間は断続的なバグの大きなかたまり」
- 「自分は自分の書いたコードではない」
- 「できるだけ約束は小さくして、届けるものは大きくしたほうがいい。それでノーと言う機会が増えるとしても、できないことを約束しない。頻繁に締め切りを守らなかったり、機能を落としたりしていると、会社の人は信頼してくれなくなる。」
- 「ダウンロードではなく、利用されなければならない。」
- 「エンジニアの文化は「事実」に満ちあふれている。」
- 「ソフトウェア以外のことに注意と集中を浪費しない。」
