エンジニアの勉強法

という本を書店で見てたら面白そうなので購入☆

とりあえず、まだ読んでいる最中ですが、
実際に自分が仕事をしていて、
ああ！なるほど！ということがたくさん☆

「エンジニアの仕事は「駅伝のリレー」に似ている」

とか、

「「プライオリティー思考」と「仮説思考」」

とか。

前者はまさにその通りで、新しい製品を作るためのラインを引く、
そんな仕事をしているわけですが、そこにも多くのチームが携わり、
生産活動の下流へ向けてチームからチームへ情報を引き継ぎます。

最も大切なのは、タスキを如何に上手に引き継ぐか。

あるチームが努力の末に得た情報が、チーム内でそのまま停滞して
引き継げなかった場合、引き継いだチームがまた同じ事をしてしまう。

そんなの普通に引き継げるでしょう！

と、思いきや、これがチーム戦で扱う情報量も多いもんだから、
忙しい中で埋もれてしまいがち。

さらに、チームなので、
「誰かが伝えるだろう。」
な～んて思っていたら、絶対に伝わらない。

それをしっかり標準化して伝えられる形に残すクセをつける。
(半分持論が入ってますが…)

これが重要だと思っております。

また後者。

QC的にはパレート図を思い浮かべてもらえればと思いますが、
何が最も重要なタスクか。
また、問題点なのか。

そこに最初に取り組む。

当たり前のようで、なかなかその見極めが難しい。
日頃から思考をパレート図的にしておき、いざというときに使えるようにしたいですね。

見極めたらば、仮説を立ててまず実行してみる。
それが違えばまた別の仮説を立てて…

何度もトライしていれば、何がダメで何が良いのか分かってくる。
現実はそんなに素直じゃなくて、全部ダメで、ダメ同士で論理立てていくと
結論が見えずに全部ダメじゃね??って結果になったり(笑)

さあ、後半は更に面白い内容のようなので、
続きを読むのが楽しみです。