今回読んだ資料
このスライドを読んでみての感想というか、大切だなと思った箇所の備忘録になります。
まず初めに
まず初めに今回紹介したスライドを読んで、改めてロジカルシンキングできてないかもなって感じました。（私のロジカルシンキングの理解度が浅い、、、、）
ロジカルシンキングと聞いて私は「論理的に筋道を立てて物事を考えればいいんでしょ」と考えるのですが、このスライドを読むとそれだけだと浅いなって感じたスライドでした。
ロジカルシンキングは苦手意識ある
これから個人的に思ったこと感じたことを書くので簡単に自分が
どんなやつなのか紹介させてください。
今、エンジニア歴約2年目になります。
エンジニアとしての実力は修行不足だなって思うことが多く
自分の実装した機能をレビューしてもらうとバチボコにされることもあります、、、、
あと完全リモートワークで仕事しているため
チャットベースでコミュニケーションを取ることが多いんですが
質問した相手に何を聞きたいのかわからないって言われたことがあります
逆に相手が何を聞きたいのかわからない時もあります。
最近よく悩むのは簡潔に質問しすぎても伝わらないこともあれば
逆に情報を付け足しすぎて結局何を質問したいの？ってなることです、、、、
ある程度関係値が作れていれば、簡潔に伝えてもコミュニケーションできますが
はじめましての人やオンラインでちゃんと会話したことがあまりない方だと
どこまで伝えるべきでどこを省くべきなのか悩みます、、、、
質問する側、聞く側、どちらの立場になっても
わからなくなるのは自分に少なからず原因があるんだろうなと感じてます。
そんな自分が今回紹介したスライドを読んで感じたこと
今回紹介するスライドはロジカルシンキングって結局なんなのってのを
掘り下げてる内容になるのかなって思います
個人的にロジカルシンキングってエンジニアにおいて、とても大切な思考法だとはわかっている反面ちゃんとできているかと言われると、どうだろう、、、、あまり自信はありません。
個人的に刺さったスライド
このスライドを前半、後半読み進めていくうちに刺さったスライドをページ順に紹介してきます。
前半のスライド
P8 「考える」の誤解と解消
正解をあてる× 精度の高い答えを探る⚪︎
仕事やっててバグ修正や機能実装時に詰まったときにどうしても
正解がどこかに必ず存在して、その正解を当てようとしているなと、普段の自分の動きを振り返ってみて思う節があります。
→「正解を当てるのではなく精度の高い答えを探る」、「答えを探すのではなく答えを作るべき」なんだなってこのスライド見たときに改めて思いました。
以前、保守系のタスクをベテラン先輩エンジニアが振られてたときに
「このタスクで修正範囲全部やると大変なんでまずはできそうな部分からこのタスクでやりますわ〜」
「このタスクを〜でやると大変なので今回は〇〇で対応します」
って企業側に提案してタスクこなしてたのがすんごい脳をよぎりました、、、、
(その人は企業側から評価されてたなぁ〜と)
答えをあてに行くのではなく探る、作るのが大切
実際やるのと思うのでは全然違うんですが「目的に合わせて答えをあてにいく」のではなく「探る、作る」ってのが大切
P9 ロジカルシンキングができると、、、
このスライドに記載してある「ロジカルシンキング」の中で、できてないなって感じる箇所がいくつかあり
できてないと感じた箇所
1. 考える対象を絞り込める
2. 会話や文章から情報を整理して受け取れる
3. 受け取った情報を組み立てて伝える
特に普段仕事していて、強いエンジニアの人は2の能力が高い気がしていて
お客さんやメンバーが何が言いたいのか的確に論点を掴んで、会話を進められているな、「凄っ！」てなります。
1~3の能力が上がると相手が言いたいことやフワッと投げてきた課題(issue)に対して
的確に解決方法や会話を進めることができるので1~3を意識しないとダメなんだよな、でもこれが難しい、、、
P19 求める答えを引き出す、最良の問いを作ること。
求める答えを引き出す最良の答えを引き出すこと
P8のスライドでも「最良の問いを作ることが大切」って書いてあり、
そのためにはまず「自分で問い」をなぜって作っていってどんどん考えを掘り下げて
求める答えを作っていくことが大切
何回も言ってるんですけど、頭ではわかっているつもりでも実際にやるとこれがなかなか難しかったりする
P22 問いを作る技術
繰り返しと分解が大切
さっき書いた
「このタスクを〜でやると大変なので今回は〇〇で対応します」
この例がまさしくで、ロジカルシンキングができる人は難しい、複雑な問題にあたったら、「繰り返し分解をする」作業が自然とできているんだろうなと思いました。
実装でもそうだけど、より複雑な実装をよりシンプルに分解する必要があるんだなと
→そのために必要なものが「分解」で問題をより簡単にして、「繰り返し」でより対応しやすい大きさまでその課題を分解していくのが大切なんだなと
P24 繰り返し分解するの具体例
このスライドで実際の具体例として勉強を挙げていました。「勉強をする」っていう抽象的な問題をより細かく、何度も繰り返し分解して「答えを探る」作業をしているスライドです。
こうやってみると、「勉強した方が良いか？」という抽象的な質問を答えと問いを繰り返すことでより具体的な問いや答えに掘り下げれています。
P25 繰り返しを使うコツ + 答えから"問い"
このスライドで面白いなって思ったのが何聞きたいのかわからない、何質問しているのかわからないって状態はこのスライドの左側の「問い」、「答え」(より浅い問いと答え)で結論を出しちゃってる状態なのかなと、、、、、
なので解決方法として自分でなんでなんだろうってどんどん自問自答することが大切なんだろうと思いました。
自分ごとでやってみた
今度は自分ごとで最近AWS関連の勉強やってみたいなという考えがフツフツと湧いてきており、それがなんでなんだろうということを自問自答してみました。
結論としては書いてある通り「収入も上がり安くなり、できる仕事の幅も増える、希少価値が高くなるから」ってのが答えになるのかなと思います
P27~28 問いの「掘り下げ」と「範囲を広げる」の具体例
P49 問いと答えの構造
このスライドは問いとその答えの具体例
P52 ロジカルに考える = より良い問いを作る
私も「答えの奴隷」にならないように気をつけないと思いました。
このスライドに書いてあるように「問い」を考えずにすぐに「答え」から入ってしまうと無意識に深く考えたり、広く考える機会を失ってしまい、適切な答えを探せなくなると思うので、「で、なんでそういう答えになったの？」と聞かれたときに「なんとなく」や「浅い理由」しか答えられず相手を納得しづらくなる傾向にあります
まず、複雑な課題や質問に当たったときは、
「問いによって選択肢を量産、整理」してより「精度」を上げる作業を行なっていきたいです。
後半のスライド
P17 ロジカルなコミュニケーションとは
ロジカルなコミュニケーションができると相手が何を言いたいか分解できるので的確なコミュニケーションがより取れるようになるのかなと
つまり、この人何いってるのかあんまよくわかんないなが発生しづらくなる、、、
よく、あの文章で理解して会話ができてるな、この人「相手が何言いたいのか」の聞き取る力がすごいなって思う人はこのロジカルなコミュニケーションができてるのかなって感じました。
P18~P19 「受け取る」と「伝える」の土台
「受け取る」と「伝える」の土台がしっかりしてる人は曖昧な表現を明らかにできる
→曖昧な表現がわからないときは質問してはっきりする必要がある
当たり前のことなんですけど、相手が曖昧な表現を使って何を言いたいのかわからない場合は質問してその曖昧な箇所を排除する必要があるなと改めて思ったスライドでした。
会話の流れや聞きづらい人だとスルーしてしまうこともあるので、これはこのスライドで言うところの「受け取る土台」ってのが作れてない状態なのかなと
P26 言葉を明らかにするための問いとは？
このスライドで激しく同意できたのは「この人って何言いたいんだっけ？」が発生する理由として、「相手に曖昧な表現で伝えてしまっている」が1つ主な理由としてあるんだろうなと思いました。
例えばチャットで
「この前言ってたやつなんですけど、あれを使うときにこれって必要でしたっけ？あと、前のそれと違うやり方でしたっけ？もしそれが無理なら、こっちであれをすればいいんですかね？」
こんな質問を受けたら
代名詞が多すぎて、混乱すると思います。
今回の例は極端すぎますけど、
「これ」や「あれ」が詳細に伝わる部分がないと当たり前だけど伝わらない、、、、
気をつけることとしては
「曖昧な表現は無くして、伝えたいことは簡潔にする」
ことが重要なのかと思います。
詳細に書かなくてはと思って、情報付け足しすぎても伝えたいことが曖昧になりやすいし、「簡潔に」を意識しすぎてシンプルにしすぎても情報が少なすぎて伝わらない,,,,,
あとは書いた後にわかりやすく書けてるか自身なかったら
自分でちょっと時間置いて読み返すってのも気をつけてますし、改めて気をつけなくてはって思ったスライドでした。
余談ですが、以下の記事がわかりやすく伝えるためのコツを書いてくれており、勉強になりました。
P34 抽象と具体を往復する
わからないが発生する時って確かに抽象的な部分が多くこのスライドでいう
言葉の輪郭がぼやけている時だと思うので
そんな時は具体性を上げていくようにすべきだなと
P35 ロジカルに考える＝より良い問い
詳細に書かなくてはと思って情報付け足しすぎても伝えたいことが曖昧になりやすいし、簡潔にを意識しすぎてシンプルにしすぎても情報が少なすぎて伝わらない,,,,,
↑さっき書いたこちらの結論がこの「P35 ロジカルに考える＝より良い問い」のスライドなのかな〜って思います。
まずは繰り返し「なぜ？」って自分で問いを与えてみて考えの深掘りと分解を行う
そして、その中で不要な問い（不要な情報）を取り除くことで相手にわかりやすく伝えることができるのかな〜と
P40~41 詰まったとき、課題取り組むときに使える考え方
バグの原因調査や改修作業がしっかりできる人はこのスライドの流れでしっかり考えられてると思うので、この考え方は見習いたい。
スライドの考え方をどう仕事に活かしていくのか？
スライドを読んだ上で、じゃあ今後どう仕事に活かしていこうと考えたかというと
- issue、機能実装、バグ修正時は正解を当てるの意識ではなく正解を探す
→答えをあてるのではなく、精度の高い答えを探る、作る意識で着手する - 目的を見失ったり、「結局何がしたいのか？」わからなくなったときは「なぜ？」ってのを紙やメモに書き出してみる
- 抽象的な表現をなくして、言葉の輪郭をはっきりした状態で相手に伝える
2の書き出し例
こんな感じでメモ帳や自分だったらNotionに書き出して自分の考えを整理、分解、繰り返しすることでより精度の高い答えが作れるようになる(?)のかなと思い書き出すようにしてます
今回のissue
↓
なぜ1？
↓
答え1
↓
なぜ2？
↓
答え2
↓
なぜ3？
↓
答え3
最後に
ロジカルシンキングを中心とした相手に論理的に伝える力、考える力ってのはエンジニアとして仕事するならもちろん、そのほかの仕事でもとても大切な思考法なため今後もアンテナを張っていきたい領域です。
ロジカルシンキング関連の本で良さげなものがあればどんどん読んでいきたい