第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 の順番で繋がりができているかをやる方法が仮設検証思考なんやでと書かれていて仮設検証ってどうやんねんって思っていた私にはすごい刺さった