はじめに
下っ端プログラマとして日銭を稼ぎ続け10数年、一向に成長が見られない低スキルエンジニアが現状を少しでもマシにしようと読んだ本を紹介する。
エンジニアとはひたすらPCに向き合って黙々とプログラムを組むだけでないのは周知の通り。
実際は検討に検討を重ね、他者とコミュニケーションを取り、あらゆる観点から整理して形にしないといけない。
が、私の場合まず自分の考えを整理しまとめる段階から既に躓いており、様々な問題が発生している。
テスト項目を作ればレビューで漏れを指摘され、仕様検討のミーティングを開けば時間内に話がまとまらず延長してしまう限界社員っぷり。
そんな状況に少しでも希望を見出すべく読んでいった本を「あー学んだぞー」とやった感で満足せず、実際業務に活用できるかも加味して感想文を書いてみた。
選んだ理由
さて、プログラムのテスト項目作成で漏れが出る、ミーティングが時間通りに終わらず話がまとまらない等々。
どうすれば考慮漏れや行き当たりばったりの雑な会議を防ぎ、やり直しで時間を無駄にせずに済むか。
まず自分の仕事の進め方、すなわち考え方に問題があるのでは？と考える。
そこで興味を引いたのがこのロジカルシンキングの書籍。
自分なりの考えで進めても非効率的で時間を無駄にしているのは結果が証明している。
であれば思考から変えないと駄目ではと思い購入。
読んだ本一覧
世界一わかりやすいロジカルシンキングの授業（Kindle版）
点数
★★★☆☆
読んでみた感想
タイトルに「授業」と入っているからなのか、まるで講師が生徒に語りかけるような調子で進めていく。
ただ初心者向けに分かりやすく説明する意図なのか、本題に入る前の前置きや例え話がかなり長いと感じる。
ロジカルシンキングについて既に別の書籍や講習会で、ある程度学んだ人は飛ばし飛ばしで読むのが良さそうだ。
共感した点
- Lesson03：「バカの壁は見えないので「考えたつもり」になっている
経験・知識・常識といったものが発想の邪魔をするのはよくあるなと。
「これまでこの方法でやってきたから」との経験から、他の発想をやめてしまうのは結構やりがち。
とりあえず実践してみようと思った点
学び始めだけどこれなら直ぐできるし業務にも応用できそうだ、という点をまとめる。
- とにかく書き出す
- 書いた量＝考えた量
- 軸と境界線を意識する
- 何以上何以下 など
- 軸は定量的なもの（時間 今から2日以内、今から2日後）
- チェックリストを作る
- 「項目が網羅的」「項目が出来るだけ具体的」
- MECEに則して考えるのは高度なノウハウなので実は難しい
- 直感よりも多くアイデアが出せればいいと考える
- ツリー構造を意識して考えてみる
- Why型ツリー：問題 なぜ
- How型ツリー：課題 どうやって
- What型ツリー：その他
ITエンジニアのための【論理思考】がわかる本
点数
★★★★☆
読んでみた感想
会議運営、問題解決、説得やプレゼンなど用途がはっきり分けられており、いずれも働く上での考える力と伝える力を学べる内容。
下っ端エンジニアの自分としては「こういう場面弱いからそこを向上させる方法知りたい！」と思ったとき目次からパッと探せるので読みやすい。
上で紹介した「世界一わかりやすいロジカルシンキングの授業」よりも業務に特化して詳しく学べる。
共感した点
- 1-2 ITエンジニアが得意な論理思考の「思考の停止」
「普通の人は、解決策が出せたら、他の解決策を考えるのをやめてしまう傾向にあります」（21ページ：「Column 思考の停止」）
1個案が出るともうそれしか見えなくなること、これは本当によくある。
無意識にその案をベストと思ってしまい、あとはどう補強するかにリソースを全振りして他の案を考えられないことは何度も。
- 第4章：問題解決に役立つ論理思考（106ページ：4-4 原因を深く掘り下げるWhyツリー より）
課題の反省・掘り下げに有効と思った。
1つ2つ原因を掘り下げて停止せず、さらに深掘って「何故」を突き詰めるやり方
とりあえず実践してみようと思った点
スケジュールを組み立てることがとにかく苦手なので、まずこれを参考にやってみようと思う。
- 下記のステップ2〜4を繰り返し5の精度を高める
※1-1 論理的であるということ の図1-3より（5ページ：「論理的に考える」とはどういうことか）- ゴールを把握
- 現状を認識
- 現状からゴールに至る過程を計画（仮説を立てる）
- 検証
- 実行
まとめ
仕事で得た「経験」に頼り、深く疑問を持たないまま何となく進んでしまった自分にとって、別の視点での考え方を教えてくれる内容だった。
さて「はじめに」で触れたが、現在私には「作成したテスト項目に漏れが出る」「ミーティングが時間内にまとまらない」の大きな二つの課題がある。
今回読んだ2冊はこの課題を解消してくれたかというと、少なくとも「ミーティングが時間内に終わらない」課題には解消が見られ、大体5回やれば5回ともオーバーしていたのが、5回中2〜3回に抑えられるぐらいは改善した。
では読む前と後で変化した行動として、まず挙げられるのが「書く」こと。
次にゴールを決める。そして問題解決をツリー構造で考える、それが難しければチェックリストを作って考えをとにかく書き出す。
これを実践することで、ミーティングで決めるべき内容が何で、自分は何を相談したいのか、今話すべき内容か別で話すべき内容かが整理され
「えっ何それも決めるんだったの！？今やるべきか分からないけど話さなきゃ…」とあたふたしてズルズル伸びてしまう事態は、この本で改善に向かったかなと。
あと「作成したテスト項目に漏れが出る」課題について、これは何も改善しなかったのか、というとそんな事は無いのだが
テスト項目作成を実践する機会がまだ少なく、はっきり「効果があったぞ！」と断言がしにくいため。
ただ「境界を意識する」「チェックリストを作る」をする前と後で、作成にかかる時間が以前より少なくなったかもしれない。
読む前の私は作業スピードに気を取られて、調べるよりも経験に頼りその結果「本当にこれで良いのか？」という疑問が出にくい状態だった。
まさに「解決策が出せたら、他の解決策を考えるのをやめてしまう」に陥っていた。
チェックリストにしろツリーにしろ色々やり方はあるが、頭の中だけで考えずとにかく書いて出力することが大事だと気づく。
というわけで今一度、新人の頃のようにとにかく何でも書いて自分の思考を整理することから始めようと思う。