■ 障害対応・問題解決の基本 ・障害時はいきなり手を動かさず、まず仮説を立てて検証する ・「事実を1つ見つける → 仮説を立てる → 検証する」で進める ・検討より検証を優先する ・悩むくらいなら試す → 早く失敗し、早く修正する ・リプロ（再現確認）を徹底する ■ コード理解とアーキテクチャ理解 ・速さより「意図」と「アーキテクチャ理解」 ・理解には時間がかかると受け入れる ・細部まで読むことで全体像がクリアになる ・まずは if や構造を把握する ・実装を過度に疑わない ・メンタルモデルを作る 　- コードと構造を学ぶ 　- 挙動を頭の中でシミュレーションできる状態にする ■ ドキュメントと思考整理 ・先に小さく書く ・書くことで整理され、抜け漏れに気づく ・思考を書けばそのままドキュメントになる ・後から書くと負担になる ・ドキュメントは「設計のため」にも必要 ■ 生産性を高める働き方 ・2時間進展がなければ質問 or 切り替え ・効果の高いものだけやる ・最優先の1つに集中する ・マルチタスクは避ける ・成果＋タイムボックスで管理する ・深い集中は1日4時間が限界 ・疲れたら休むのではなく、別のことをする ・休息＝いつもと違うことをすること ■ 価値を生むための考え方 ・機能の約40％しか使われない ・「増やす」より「減らす」に価値がある ・スコープを絞り、価値を最大化する ・QCDSはスコープで調整する ・少ない物量で大きな価値を出す ■ 開発プロセス改善 ・VSMでリードタイムを短縮 ・事前資料より「随時合意」で早く着手する ■ 学習・定着の方法 ・難しいと感じたらやり方を疑う ・「調べずにできること」を増やす ・思い出すことが記憶を強化する ・人に説明する前提で聞く ・理解に時間をかける習慣を持つ ■ コーネルメソッド ・ノート：学んだこと ・キュー：それを問う質問 ・サマリー：復習後に要約 ■ コミュニケーションの原則 ・クイックコールを活用する ・専門外でも学びを優先する ・聞きやすさと断りやすさは表裏一体 ・「合意できないことに合意」する力 ・反対は「自分の意見では〜」で伝える ・相手を否定しない ■ リーダーシップと育成 ・サーバントリーダー移行は抵抗が出る ・不安を理解しながら支援する ・アドバイスは求められたときだけ ・主体性を育てる ・質問しやすい環境をつくる ・選択を促す質問をする ■ 印象的な視点 ・コードは「読むもの」でもある ・読み手視点で書く ・速さより理解の深さが重要 ■ 関連書籍 ・Take Off ・幸福優位7つの法則

とても面白かった。 生産性が上がるコツは学習。基本的なこと、初歩的なことをしっかり時間をかけて理解して整理する方がいい。理解の深さは記憶にも直結する。 人の話もその場で「理解」しながら聞く。後で人に説明するつもりで聞くだけでもプラス。つまりアウトプットを前提としたインプット(メモも人が見る前提で書いてみる)。

「時間をかけて理解する習慣が身についたことで、人生の様々な小さなことを「コントロールできている」感を得ることができ、「自分ならできる」という安心感も生まれてきた。 　結局のところ、シンプルな日々の積み重ねが一番強い。」

班メンバーのアウトプットの質に不満がある時はどうするんだろう？ めちゃくちゃ読みやすいけど、Xのポスト2、3回で足りる気がする。

第６章 タイムボックス、中途半端にせず完了する、身近なところの整理、運動

第7章 あとがき 感謝すること、日本の批判的文化は何も生まない、自分の人生は自分でコントロールして幸せに生きる

第４章 伝える情報量を減らす、クイックコール、気軽に聞ける空気作り、ディスカッション

第５章 サーバントリーダーシップ、自己組織チーム、主体的に責任を持つ、仕事を楽しんでいるかを確認する文化、チームの上下関係を無くす、いかに作業量を減らしてインパクトを出すか

『毎朝30分の有酸素運動だけで、大きくメンタル面が改善されたのだ。気合でもやる気の問題でもなく、物理的な「エネルギー量」の問題だった』

第2章 スピード意識、無駄なことを省いていく、失敗を恐れず実践していく

第３章 理解→記憶→反復、Noマルチタスク、集中時間の確保

最近、米国企業のエンジニアの方と一緒に仕事をしてこの本に書いてあることが実感として理解できました。

エンジニアのバイブル

前半は結構前に読んでたからまた読み返すけど、読んでると今の会社で苦しみつつ忍耐だと思いつつ働いている自分と著者とのギャップを感じてｳｵｵとなる。いろいろ参考にチームでのレビュー方法とかを変えてみたりしてます。 最後の「自分の人生や幸せは自分でコントロール」ってのが1番大事なメッセージに感じた。仕事も自分が振り回されるんじゃなくて自分がコントロールするんだって気持ちが大事よな。

アジャイルな開発での思考法、マイクロソフトなど海外で成功するのはわかりますが、みんなが一番知りたいのは日本企業で成功させる方法でしょう。（寛容さ、すぐに聞く、失敗する、などは参考になります）

脳の疲れを取るために瞑想する。

仕事は早く切り上げて、勉強の時間を確保する。

仕事に役立てたい。

メモを取らずにミーティングとか無理そう

マルチタスクをしない。

エンジニアだからこその思考があって、そのまま自分の仕事には活かしにくいかも？エッセンスを理解して、うまく転用すべし。

基礎をきちんと理解する、これができてないなあ。

noteを読んで面白かった＋実質半額だったので購入。

お正月に買った本で読んでたらサクサクと読み進めてしまった… 世界の話をしてるので日本主軸の自分とは相容れない部分もあるなあと読みながら思いました、でも参考になるのもあったなー批判のところとか、今のTwitterがそれだもんね 個人的にえ！？となったのが会議の前準備持ち帰りをしないってことだった、というかそもそも口頭だけじゃごちゃごちゃになりやすいと思うので視覚化は必須であろうと思ってたので…アメリカ、というかマイクロソフトではそうでは無いのか…とショックも受けた 運動と睡眠時間のところは割とそうだよねという感じ、人間なのでここはしっかり取らないとマジで体調が悪くなってしまう それから気軽に聞ける雰囲気大事だよなあ、質問とか…質問ではないかもだけど会議で主導権を握る時、どうもシン…と重苦しい雰囲気になってしまうのどうにかできないかなあと思ったりしてる あとやっぱり基礎って大事なんだな…コードもだけど正直、今スランプな絵も基礎が正直自分にはなってないところがあるから陥ってるなってところがある… 最後に1番びっくりしたのは納期についてだなあ、納期って人を動かすのに手っ取り早い手法だと思ってたし、私も私を動かすためには納期を決めることが手っ取り早いんだよなあ 納期決めなきゃやらずにダラダラしてしまうのでは？と思うけどむしろそれが問題ってことなのかなあ 咀嚼するのに時間はかかりそう〜またこれは再読がいるやつだなあ

マインドが学べる書籍 どういう姿勢で向き合うのが エンジニアとして成長できるのか 何に時間を掛けるべきか 軸というものが学べる 実務でも役立っており 一度立ち止まる勇気がもらえた

「Be Lazy」(怠惰であれ) ↪︎より少ない時間/工数で価値を最大化するという考え方 鏡の法則 ↪︎自分に適用しているルールを無意識に他人に適用してしまう ↪︎寛容になりたい場合は自分自身へのルールも緩やかにしてしまったほうがいい マルチタスクは生産性が悪い ⇨「WIP=1」 …WIP(Work In Progress)=今手をつけている仕事 何かを変えたいときは「住むところ」「付き合う人」「時間配分」のいずれかを変えるべき(大前研一) 合意できないことに合意する力 ⇨相手のことを理解して認める力 コマンドアンドコントロール制…マネージャーが部下に指示をする サーバントリーダーシップ制…メンバーで主体で動き、マネージャは彼らの障害を取り除く役割 ↪︎リーダーはビジョンとKPIは示すが、実際にどのように動くかは、チームが主体的に考えて意思決定していく “相手が間違っている”ではなく“意見が違う”というスタンスで ↪︎他の人の脳みそを借りて、最適なアイデアを選択しようという姿勢 two pizza team ↪︎Amazonで行われており、2枚のピザを分けられるくらいの人数の意