人に依頼する、伝える機会が多くなってきたためどのように話せばよりよく伝わるのかを知りたくて読み始めた 第5章まで読んだがここまでの結論は 「結局話す時もロジックツリーなんだな」 だった つまり伝えたいことという大元の要素があってそれが構成される根拠その根拠を説明する事実 のような形を形成し、それを基本的なフレームワークに従って伝えていく感じなのかなあと思った 自分も人の見様見真似かこれに近い話し方自体はしていたが、上記ロジックツリーで伝える部分は左脳に訴えていて実際にイメージしてもらう（例えば〜や具体的にいうと〜など）が右脳に訴えている両方の脳に訴えることで伝わりやすいということが言語化されていて方針としてはあっているんだなと思った ただ自分の話し方を見ていると上記のベースの部分は思ったよりはできているように感じたが本の中でも触れられていたが冗長な言葉が多いっていうのが弱点だなと思った 冗長な言葉の例を挙げると - 〇〇さんもおっしゃっていた通り〜〜 - 2年分のデータでは足りなかったので10年分のデータをみて〜〜 - 求められていない不必要な補足や説明 が特に自分には多いのかなと思った 〇〇さんもおっしゃっていた通りって丁寧に言っているつもりで自分は言ってしまっているかと思うんだけど文脈でわかるのでまずこれはいらないんだろうなと思った 2年分の〜みたいなのは自分がやったプロセスアピールみたいなもので正直なところ関係ないので説明に入らないよなと あとやりがちなのが求められていないところまで説明しちゃうところ相手に伝えるべきは何かをちゃんと考えられていないときに発動してこれも伝えなきゃあれも伝えなきゃになっちゃっているんだと思う やっぱりこれもロジックツリーからやるべきことやらないべきことを削ぎ落とすのと一緒で本当に伝えなきゃいけないことを絞れていないから何だろうなと思った 本の中で謙りすぎるとか丁寧すぎるために〜っていうのも挙げられていたが個人的にはこれは相手との繋がりと伝わりやすさのトレードオフだと思うので自分的には相手をリスペクトする点についても重視しているので気にしなくていいなと思った

終章まで読了をした この本を読んで自分的に解釈したのは仮説検証というのは問題解決（ロジックツリーなど）で門dないとなる可能性を羅列した上でどれが一番筋がいいかを判断し、判断したもの以外には目をくれず筋がいいと思ったもののみ検証を行い効率性を上げていこうぜといった内容だったかなと思った ポイントなのはあくまで可能性の羅列だけをする全てに検証をかけないと言ったところ やっぱりこれが全てだなと思った 筋がいいものを検証して当たれば最高、外れればさらにいい仮説を立てるための仮説の種が手に入るというのを繰り返していくのが良さそう また何より大切かなと思ったのはいい仮説を立てるには経験や知識が必要だということ 羽生さんの例にあった通り1手を打つたびに80数通り打ち手はあるが良さそうだと思うものは直感的に2,3手しかない さらにその中で自分が筋が良さそうというものを高速で頭の中で検証（シミュレーション）する って言うのがまさに仮説検証でやりたいことだよなと腹落できた 仮説検証って日々の生活でトレーニングできると思うので意識的に鍛えてやっていきたいなと思った

第二章 ~ 第三章を読んだ 個人的に大切だと思った要素を書いていく まず、仮説を立てるには経験とか知識みたいなところがかなり重要だなと思ったところが感想 例えば日常的な仮説として雲が分厚く空が暗くなっていたとしたときに雨が降りそうだなという仮説を立てて傘を持っていくと言う対策をとる いわゆる、「空・雨・傘」にあたるがこれはこう言う空の状態だと雨が降るんだよなーっていう経験があるからこそこの仮説が有力だと仮説立てができるわけであってこの空の状態を知らなければできないよなと思った 経験は大切とかよく言うけどこう言う部分を強くする意味で重要なのかなとも思ったりする また経験については機会が巡ってくるかみたいなところもあるにはあるので知識という能動的に鳥に行けるのもはそれはそれで強いなと思った また、仮説をひらめく思考方法についても面白なと思った よく言われる - 反対から考える - 0/100で考える - ゼロベース思考で考える と言った内容が出てきた これらの内容ってよくHow自体は書かれているけどなぜこの思考法がいいのかについてはあまり書かれていないことが多かったので知っていたけど意識的に使うぞ！って言う場面は今まであまりなかった 本の中では仮説を立てるためにこの思考法を使うんやでと書いてあり腑に落ちた 例えば、反対から考えるだとコストダウンがゴールだとしたときに私たち的にこの施策を行うとコストダウンになって嬉しいがこの施策を行うと顧客目線からすると使用感が悪くなるので売り上げが落ちるからコストダウンすることよりデメリットが大きいからこの仮説は良くないなど判断ができる やっぱりなぜ？がわからないと使わないよなーって改めて思った 最後にロジックツリーの話が出てきたが仮説思考と問題解決の繋がりが言語化できてよかったと思う 要は問題解決のロジックツリーを作成してその中の有力なのはどれ？って言うのが仮設思考なんだなと腹落ちした

仕事を円滑に進める方法をいろいろ知りたかったので読んでみた とりあえず第1章だけ読み終わったのでまとめる 結論から言うとこれ将棋とかカードゲームで想像するのが一番腹落ちできる話だと思った 第1章の要点としてはこの2点だと思った - 網羅的に検証しない有力な仮説を立ててその仮説を検証する - 情報が多ければ多いほどいいわけではない 羽生さんの話が一番腹落ちしたので例に挙げると 数ある手駒すべてのパターンを考えると80パターンぐらいあるが有力なものは2, 3パターンその中で自分の経験からこれが良さそうと思うものを選んでシミュレーションする 仮にその仮説が的外れだったとしてもシミュレーションの中で仮説の種（例えばここに駒を進めると絶対に取られたくない駒が取られるなど）が得られるので他の一番有力な仮説を検証する そうすることで80パターン全てを検証するよりはるかに速い速度でいい手が考えられる ゲーム性あるもので考えると確かにそうだよなってすごいわかりやすかった 情報が多ければ多いほどももそうで情報には - 不確実性を下げるもの - 不確実性を上げるもの この二つがあるってことが言語化されていてよかった 例えばランチする場所を考えるとき 様々な選択肢がある中であの人はフレンチが好きみたいな話があれば日本食・中華などの選択肢がはずせるので不確実性が下がる ただ、あの人は気分屋でフレンチがいいと言う日もあればフレンチを選ばれると怒る時があるみたいな情報を得ると一気に選択が難しくなる これもそうだなーと思った 要は情報ってあればあるだけいいわけじゃなくて不確実性が上がったり下がったりするんだから今ある手持ちの情報で一旦有力なものを考えてそれを検証してみなさい 情報を集めるのであれば不確実性が下がる情報に焦点を合わせて集めなさいなのかなと思った

マネージャーとはの基礎を再確認するために読み始めた 良くも悪くもそうだよねやっぱり大切だよねということを思い出させてくれるいい本だなーと思った 特に大切だなと思ったのは 1. 外発的には人は変わらない、変わる時は内発的 2. メンバーの成長の先に目標達成を作る（同じ線上にある） 3. How指示はしない なぜこれをやるかを伝える 4. メンバーは有能だと考える 5. 適切な難易度のタスクを渡す 1 関しては外からガミガミいうよりメンバーが内側から変わりたいって思える状況をつくろうねという話 これは自分もまさにそうなので納得感が強い 怒られたり注意されたから変わるんじゃなくて個人の中でこうしたいとかあるべき姿へのギャップを感じるからそれを埋めたいっていうのが成長だと思うのでここに持っていくための指導をしようねってことだと理解 2 自分の弱点でやっぱりメンバーの育成みたいなところがまだあんまり見えていない 著者もチームとしての目標達成はできていたがメンバーの成長につながっていない経験を多くされたようだが結構これに近いのかなって思った メンバーを駒としてみているわけではないけど成長については考えられていなかった これって今内省してみると考えが短期的なのかなって思った現状をクリアするためにどうするかを重点的に考えているから成長にある意味興味がないのであって中長期的にみると成長にリソースを使うことは大きなリターンを得るために必要なことなのでここの考えは変えていくべきだなと思った 3 いわゆる方法だけ、やることだけを伝えるHow指示良くないよねの話 問題解決本でよく出てくる話なのでやっぱりどの本も言うんだなと思って印象に残った ビジネス本とかの面白いところって煮詰めるとみんな同じこと言っていることが結局大切だよねに気づく瞬間なのかなとも思う まさにこれもその一個だと思ったので大切にしていきたい 4 結構自分の中でも考えている考え方だったので刺さった 牛尾さんの世界一流エンジニアの思考法の中でもあったと思うのだが基本的にメンバーは常に最善を尽くしてくれているベースで考えた方がマネージャーとしても気持ち的に楽だし（手抜いてるんじゃないかとか考え出すとキリがない）チームの雰囲気もよくなるんだろうなあっていう定性的な感覚がある ここうまく言語化したいけど出てこないんだけどなんかいいってぐらいにしか今はできなさそう ただこれを書いていて思い出したが、格ゲーの梅原さんが言っていた「なんか面白い」みたいな感覚って一番大切だよねって言う考え方がすごい好きなので今はなんかこれはやっておくといいんだろうなに収めていてもいいのかなと思った 5適切な難易度のタスク、本の中ではアチーブメントゾーンのタスクを渡そうぜ！とあった メンバーの成長系の話に繋がると思うんだけど成長みたいなところが個人的に意識できていなかったのでめっちゃゆるゆるなタスクの渡し方をしてしまっていたなーと反省（本の中ではコンフォートゾーンと表現されていた） 具体どんな感じでゆるゆるだったかと言うと適切な期限が設定できていないのが個人的に弱みなのかなと思った メンバーの進め方とかを特にみることもなく当初ひいていた期限に間に合わなさそうだから伸ばすみたいなことを安直にやっていた と言うのもこれは良くも悪くも世界一流エンジニアの思考法にめちゃくちゃ感銘を受けていてマネージャーはメンバーの障害を取り除くって言うことを少し履き違えて注力してしまっていたかなとも思う 長くなったが要は何も考えずに期限を伸ばすのではなく進め方あってるのかやそもそも期限設定時に考えていたタスクより工数がかかりそうだったかなどを検討した上でどのようにするかを判断し、タスク遂行時にはメンバーの障害を取り除いてあげることに注力するみたいな話が現状良さそうだと感じた

第5章 ~ 第7章に関しては今までの問題解決の視点とはまた別な組織・チームとして問題解決をする時の運用のコツが書かれているような章だった 正直なところ今自分が欲しかった要素が問題解決自体のノウハウだったので他の章よりかはほーという感じで読んでしまった ただし吸収できるものはいくつかあって 1. 新しい取り組みをするときは既存の運用に乗っけられないかを考える 2. How指示はやめる 3. 対策はすぐに実行に移す 4. 対策の最後は標準化 この辺は普遍的に使えるなと思った 1に関しては何か新しい取り組みを行うときに新しく何かをするというのは時間的制約や心理的ハードルが高いので既存の取り組みに付け加える形で対応すると進めやすいよといった話 ここら辺は習慣化のコツみたいなところと似ていて既存の仕組みに付け足すとやりやすいは感覚的にわかるので仕事でもそうだなーと思った 2に関しては対策だけを伝えられてもうまくできないということ 例えば理由がわからないままこのタスクはシュリンクするみたいなのを頑張ってる人が言われたとしたら反感を買うし、なぜこれをやらないといけないのかということがわかっていないと当の本人が考えられずタスクを進行するためアウトプットの質が下がってしまう 納得は全てに優先するぜって言葉は改めて深いよなーと思った 3に関しては鮮度の問題で日々ビジネスは変わっていくので例えば今検討したものを半年後にやろうとしたら全然違う対策になってしまっているみたいな話これはそう 4に関してはいわゆる属人化の話 個人で問題解決ができたとしてそこで終わりではなくて誰がやっても同じ問題解決ができるように標準化しようねって話 大体の仕事って個人で解決で終了してしまうが標準化までちゃんとやりたい 忙しいの一言で標準化しないが標準化しないことによってその人が一生対応しないといけなくなって結局忙しいっていうのはよく見るので長期的に見るのであればやっぱり最初に苦労して後から楽にの方針だよなーとここに関しては投資とかと一緒だよねみたいなことを読んでいて思った

第4章 あるべき姿を設定する 問題解決の基本であるあるべき姿についての話 意外と言語化されてこういうものだと理解したことがなかったので言われてみれば確かにというものが多くあった 1. 発生型と設定型 発生型：誰がみても共通で認識できる問題 → 画面がエラーで表示できない 設定型：未来に対してこうありたいを設定することでできる問題 → ユーザー数を来年までに100人から1000人にしたい 現状の理解だと、発生型は目に見えて明らかな問題つまりマイナスな問題で設定型は現状困っているというわけではないがこのようにすべきという未来に対しての問題なのかなと思った 本にも書いてあったが発生型は問題を共通認識できるのに対して設定型は共通的な問題ではないのでその問題を他の人といかに共有できるかが大切 2. あるべき姿の設定の仕方 あるべき姿を設定するには 「目的・内部・外部」の3つの視点から設定をする また目的は細分化すると「目的と目標」の二つに分けることができる 目的とはどちらの方向に進むべきかという方針を決めるもので目標とは定めた方向に対してどの程度までやるのかを決めることになる 内部とは自分たちがどのぐらいできるのか？を指し、外部は自分たちがどのぐらい期待されているのかを指す 要は、なにすんねんを決めるにはどのぐらいキャパあんねんとどのぐらい期待されてんねんを確認し、じゃあどの程度やるねんを決めようねという感じかなと思った んで一般的なas-is to-beを考えてそのギャップが課題だよねを考えていくのかなという理解 ここでそれこそロジックツリー使ったりエッセンシャル思考的にやらないこと決めてどれをやるべきかとか決めるんだろうなと思った

第3章 原因を追求する を読んでの感想 where why howのwhyについての考え方を紹介している章 重要なこととしては、 - コインの裏返しの考え方やめようね - 因果の構成図を作って考えようね なのかなと思う 1つ目はシンプルだけでよくやりがちなことで 「朝の売り上げが減っている」という問題があった時に「朝の売り上げを上げるにはどうすれば良いか？」というコインの裏表のような関係で問題を考えてしまうのは良くないよねといった話 なぜこれが良くないのかというと、売り上げが減っている原因を詰めずに売り上げが減ったという箇所にのみピン留めをして問題を解決しようとしている点がよくない もうすこし簡潔に書くと、 他にも原因がある可能性があるのに原因を追及せず直感的に対応してしまっているため原因が外れていた場合効果がない打ち手になってしまう 本で読んでいるタイミングではあー確かにちゃんと分析・深掘りした上で対応考えるべきだよなと思うんだけどふとこの場面に出会した時にコインの裏表の考え方をしてしまいがちなのでここは意識して気をつけたい 2つ目の因果の構成図を使って考えるは1つ目に比べると複雑だが要は - 原因の深掘りをする時に使えるフレームワークだよ - ロジックツリーなどで表現できないことができるよ原因の深掘りをする上では優先的に使うべきだよ - 深く広く図を使って原因を掘り下げていくよ - 書き終えたらMECEになっているか確認するよ - その後実際にどの原因に対して対策を打つかを決めるよ といったもの 実際に業務でこのフレームワークを使ってやってみたんだけど結構難しい というのも深くは掘り下げられるんだけど広さとかを持たせるのが難しい 自分の場合だが大体これでしょという原因で思考ロックされてしまって広さが見えづらくなっている点がある 俯瞰して見れるといいんだけどここは鍛えるしかないのかな？ また補足的に書くが対応すべき原因を出し切る・選ぶには - 打ち止めになるまで原因を深掘りする - 自分ごとで考える - やっていないだけを見つけたら即対応する - 末端の原因だけをやるというわけではない ここら辺が重要そうだった 特に末端の原因だけをやるわけではないというのは目から鱗で、ロジックツリー的に考えると末端 = タスクになるので基本対応だなーという認識だったが構成図的には長期的・短期的視点でどこのレイヤーの原因を対応するかを考えると書いてあってなるほどと思った つまり末端は時間がかかるけど根本的な対応 上に行けばいくほど即時的な効果があるが暫定的な対応の関係になっている 結局日々こういうフレームワークを知って実践的にやっていかないと身につかないなーと思った

第二章 問題を特定するを読んだ 結論 問題がどこにあるのかのwhereが一番大切でここを見間違えると後続のhowとwhyがどんなに良くても価値がなくなってしまうよね だけどwhereの特定が一番難しいよね だったと思う 1. MECEにwhereに当たる箇所を出す 2. クリティカルな問題の場所を狭めていく が大筋の王道パターンという感じだと思うのだけれどこのMECEに出すというのが難しいよなと思った 本の中でも書かれていたが広げようと思ったらどれだけでもwhereの箇所って広げられるわけで 例えば、会社が働きづらいという問題があった時 〇〇チームというwhereもあるがその上位レイヤーとして△ △部署というレイヤーでもみられる 最終的には××会社までレイヤーを上げられるがここまで上げ過ぎてしまうと問題の範囲が広過ぎて対応しきれない だから周りの期待つまり、今解決しようとしている問題の温度感で区切りを切った上でMECEとするしかない なのでここら辺はある程度意識して経験積まないと際限なくやってしまいそうなので気をつけたい あと重要だなと思ったのは一次分析をして仮説を立ててwhereを探求するということ 先の例を挙げれば働きづらいと思っている人が〇〇チームに所属している人の割合がかなり大きいとなった場合〇〇チームにスコープを絞って考えるといった感じ これはトレードオフで、ある意味ピン留めしてやる行為だから俯瞰したからこそ見えるwhereもあると思うのでいわゆるよしなにやらないといけなさそう こういうファジーなところがある程度あるのでwhereの特定は難しいんだろうなと思った 自分としては 1. 一次分析はやってみる 2. ざっくりピン留めで検討してみる 3. 特定したwhereに問題解決の妥当性があるか検証 4. あれば3で終わりなければ俯瞰してサイド考えてみる ぐらいの気持ちでやっていくのが良さそうだなと思った

第一章まで読んだ 問題解決って普段からやることだけれどいわゆるベストプラクティス的な手法は学んだことがなかった 第一章だけでもかなり学びがあった 特にこの本のコアな部分である 「where why howの順番で考える」というのは改めて認識すると確かにそうかもって思えた やっぱり人間ってhowから考えることが多くて お金が足りない → 節約しよう みたいな思考に陥りやすい だけどそれって本当に節約がベストな対策になるのかと言われたらわからない ベストな対策を打つためにはhowの前にwhereとwhyを考える必要がある 例えば、アプリケーションの機能が不評 という課題があった時に where: 具体的にどこの機能が不評なのか why: なぜその機能が不評なのか how: どのような対策を打つか を順に考えていく必要がある where: お気に入り登録機能が不評 why: お気に入り登録機能がpostボタンに近く誤動作を起こしてしまうため不評 how: uiを変更する みたいな話だと思っていて 例えばちゃんとwhereとwhyを考えていないと的外れな機能を修正してしまったり、whyを考えていないと機能のレスポンスが悪いからパフォーマンス改善しようなど的外れな対策をしてしまったりと改めて羅列してみるとwhere, whyの重要性がわかる また、where why howをとりあえず出せばいいわけではなくちゃんと全て繋がりがあることの確認は大切だと思った whyに対してhowが全然違うみたいなのはおかしいよねって この章の最後の方に仮設検証思考の話が出てきたが、基本はwhere why howの順番で考えていくが 例えばこの方法いいんじゃない？って思った時に そのhowを実行してみるというのはいわゆるhow思考の罠にハマってしまっているがそのhowが正しいのか検証するつまり how why where の順番で繋がりができているかをやる方法が仮設検証思考なんやでと書かれていて仮設検証ってどうやんねんって思っていた私にはすごい刺さった

3章から終章までガッと読んだ 気になった点としては - パレートの法則はどの組織でもあるよね - 無駄をなくそうね - ポジティブであれ - 何かしら挑戦しようぜ この四つが良さげだなと思った パレートの法則についてはまさに先週読んだエッセンシャル思考みたいな話で全体の2割ぐらいしか重要なタスクはないんだからそれに集中しようねって話やっぱりここら辺の意識は何の本でも出てくるから重要なんだなと 無駄をなくそうねに関しては当たり前のように見えるが最近特に感じるところ 例えば決まった形の仕事があった時ワークフロー組んだりテンプレート作るみたいな作業をしておくと先行投資で福利が働いて加速していく感覚は開発の現場で良くあるので大切だと再確認 ポジティブであれはこれも当たり前っちゃ当たり前なんだけどリーダーがネガティブな発言してるとモチベーション下がるよねって話はまあそう これよくビジネスの場で言われるキングダム理論だと思う結局士気が大体何とかするからその士気をいかにあげるかだよなーってその要素の一つがポジティブであることだよねの理解 何かしら挑戦しようぜに関してはこれもまあ月並みだよねって感じではあるけど やっぱり新しいことに挑戦している時が1番何でも伸びている感覚あるので現状維持は衰退とはよく言ったものだなと再認識できた ざっと復習とか再確認するって意味合いでいい本だったサラッと読める部分も良かった

マネージャーの基礎的な内容が書かれている 要はこれさえやっておけばというものは無いのだけどいろんなパターン考え方知っておいてそれぞれ自分の最強のマネージメントにしようねってテイスト 二章まで読んだところでこれはそうだよねって思ったところは - 人によってマネジメントするレベルは違うよね例えばマイクロマネジメント系の人もいればaboutな指示で自走させた方がいい人もいるよね - タスクを与える時のwhyは大切だよねwhyがあるとなぜそれをやらなければならないかが示せるから考える力つくし、考えるからこそいいもの出てくるよね - 一癖ある人はもう割り切るしか無い苦手なものは苦手苦手なりに距離感作って上手いことやろう苦手を克服するは無理だよね - ストレッチアサインは大切だよねちょいムズぐらいのタスクを与えていき伸ばしていこうね - 自分でやった方が早いは誰もが通る道グッと堪えて長期的にみたらやってくれるようになれば自分が楽になるって考えようね - 報告は健全に疑おう、基本的に自分もそうだったように悪いところを隠して伝える可能性はあるのでそれとなく聞き出す - パレートの法則は理解しておく組織は基本2-6-2になる - 会議はリーダーが喋りすぎない - 会議終わりはネクストアクションを定めてから終わる - 期限は決めておくべき期限決められると辛いけどパーキンソンの法則的に決めておかないとやらないし長く設けすぎるとそれはそれでぐだぐだやっちゃう ここら辺は普段意識しているしまだできていないところなのかなーと思った 基礎中の基礎が復習できている感じがいい