牛尾さんの、エンジニアとしての思考法について、とても楽しそうな本が発売されたので、気になって読んでみました〜

「思考法」(マインドセット)が高い生産性を形づくっている

手を動かす前に仮説を検証する
1.情報収集(データ集め)
2.仮説を立てる
3.仮説の検証
　不十分なら1.に戻って再度仮説を考える
4.実行(手を動かす)

理解の3要素
1.その構造をつかんで、人に説明できること
2.いつでもどこでも即座に取り出して使えること
3.知見を踏まえて応用がきくこと

「理解は時間がかかるもの」として、急がず、徹底的に理解する習慣をつけていく

デザインドキュメントの2つの利点
・ドキュメントを書くことで自分の頭が整理される。抜け落ちていた視点などに気づくことができる
・考えているときに書けば、自動的に「ドキュメント」になるので、それをシェアするだけですむ。後でまとめて退屈なドキュメントを書かなくてよい

メンタルモデル
人々が世界を理解し、予測し、解釈し、新しい状況に適用するための、自己の心の中のイメージや理論

1つのことで、2時間以上ブロックされたら、質問するなり相談するなりして寝かせておいて、他の仕事をやっておく方が断然生産性が高い

Be Lazy (怠惰であれ)
「より少ない時間で価値を最大化するという考え方」

Be Lazyを達成するための習慣
・望んでいる結果を達成するために、最低限の努力をする
・不必要なものや付加価値のない仕事(過剰準備含む)をなくす
・簡潔さを目指す
・優先順位をつける
・時間や費やした努力より、アウトプットと生産性に重点を置く
・長時間労働をしないように推奨する
・会議は会議の時間内で効率的かつ生産的に価値を提供する

ソニックガーデン 倉貫さんの一言
会議の準備をしないで、無駄だから。そうじゃなくて、会議の時間を価値の高いものにする

成功しようがしまいが、まずはやってみて、早くフィードバックを得て、早く間違いを修正していく　Fail Fastの精神

「無理を承知で」のお願いの連鎖はみんなの疲弊を生み、チームや組織の業務改善に全くつながらない

自分にとって難しすぎると感じるときは、たいてい脳の使い方が間違っているサイン。脳に余裕がない状態で酷使している可能性が高い

コーネルメソッド
「ノート / キュー / サマリー」の形式で作業を記録し、その日の終わりに整理し「作業内容を人にそらで説明できるかどうか」を記憶できたかのチェックポイントにする

自分にその分野の「メンタルモデル」や「コンテキスト」がなければ、すぐさまエキスパートに聞いたほうがよい

In my optinion
「自分の意見では」とか「自分の意見を述べさせてもらいますね」みないなニュアンス

サーバントリーダーシップ
リーダーは『ビジョンとKPI』は示すが、実際にどのように動くかは、チームが主体的に考えて意思決定をしていく

開発者(IC)がどこかで詰まっている状態になると、ブロックされているものを取り除いて(アンブロック)くれる

開発は25人ぐらいのチームがマックスで、Amazonでも「two pizza team」(2枚のピザを分けられるくらいの人数の意)といわれるように、ソフトウェア開発は少人数でないとまわらない

生産性を上げるためには学習だよ。だから、僕は仕事を定時ぐらいで切り上げる。その後で、自分のやりたいトピックを勉強したり試したりする。ずっと仕事をしていると疲れる

良いプログラマになるためのコツ
・新しいことを学んだらブログを書く
・ブログを書くとき、サンプルコードそのままではなく、少し変えて試してみる

「専門性を高める」という蓄積に価値が置かれ、スピードは思ったより重視されない。結局は時間をかけて小さな努力を、積み重ねるほうが圧倒的に良いものがつくれる

アメリカには「コントリビュート」する文化がある。Contributeは「貢献する」人に何かを期待するのではなく、まず「自分がどういう貢献ができるか？」という公共性をベースに考える

自分の人生が、自分で決められないと思っている人があまりにも多い。「会社のルールで決まっているからできない」なら、会社のルールを変えるように動けばいいだけの話。どうしても嫌なら辞めればいい

どうやったら自分の人生が幸せになるかを主体的に考えて、仕事の仕方を「選択」している

思考法で生産性が変わるという、具体的な事例やトピックスがたくさん書いてあり、エンジニアだけでなくビジネスしている人たちすべてに参考になる思考法で、とてもおすすめの1冊です