とりあえず、まだ読んでいる最中ですが、
実際に自分が仕事をしていて、
ああ！なるほど！ということがたくさん☆
「エンジニアの仕事は「駅伝のリレー」に似ている」
とか、
「「プライオリティー思考」と「仮説思考」」
とか。
前者はまさにその通りで、新しい製品を作るためのラインを引く、
そんな仕事をしているわけですが、そこにも多くのチームが携わり、
生産活動の下流へ向けてチームからチームへ情報を引き継ぎます。
最も大切なのは、タスキを如何に上手に引き継ぐか。
あるチームが努力の末に得た情報が、チーム内でそのまま停滞して
引き継げなかった場合、引き継いだチームがまた同じ事をしてしまう。
そんなの普通に引き継げるでしょう！
と、思いきや、これがチーム戦で扱う情報量も多いもんだから、
忙しい中で埋もれてしまいがち。
さらに、チームなので、
「誰かが伝えるだろう。」
な～んて思っていたら、絶対に伝わらない。
それをしっかり標準化して伝えられる形に残すクセをつける。
(半分持論が入ってますが…)
これが重要だと思っております。
また後者。
QC的にはパレート図を思い浮かべてもらえればと思いますが、
何が最も重要なタスクか。
また、問題点なのか。
そこに最初に取り組む。
当たり前のようで、なかなかその見極めが難しい。
日頃から思考をパレート図的にしておき、いざというときに使えるようにしたいですね。
見極めたらば、仮説を立ててまず実行してみる。
それが違えばまた別の仮説を立てて…
何度もトライしていれば、何がダメで何が良いのか分かってくる。
現実はそんなに素直じゃなくて、全部ダメで、ダメ同士で論理立てていくと
結論が見えずに全部ダメじゃね??って結果になったり(笑)
さあ、後半は更に面白い内容のようなので、
続きを読むのが楽しみです。
