本棚登録 : 
感想 : 
- Amazon.co.jp ・電子書籍 (248ページ)
感想・レビュー・書評
-
「世界一流エンジニアの思考法」
を読んでいる所です。
自分が本当にその事をちゃんと理解しているか、
理解するにはどんなに頭のいい人でも
当たり前に時間がかかると分かった上で、
改めていろいろな事を確認しようと思えた事は
今後の生き方に良い影響をもらえた気がして
とても嬉しい。
自信のない自分を変えられたら良いな。
まだ途中だけど、
すでに充分読んで良かった。
#世界一流エンジニアの思考法
13
詳細をみるコメント0件をすべて表示 -
読みやすい、ただ、「これはアツい、今日からやろう」ってなるのがあったかというと…？「良さそう〜」の温度感には全体的になれたが覚えてられたのは
・理解はゆっくり行う(頭では理解したけど実践方法まで具体的にできてない)
・コードは全てを理解しようとするんでなく全体像を見る
くらい…？
ADHDという属性も同じだったので期待高まったけどこれだ！には出会えなかった…
海外だからできるんだ、と思考停止せずに実践してみようも、ほんとにおっしゃる通りではあるんだが、とはいえ土壌が整ってない場所で文化から変えるとなるとそのコストは爆上がりになるわけでどうしてもメリットが霞んでしまう
・必要なことしか言わない
も楽だし伝えやすそうと思ったがそれを日本でやったら「こいつ仕事できねえな」になるわけで
レビューはあくまでimoとするのとかは自分主体でも始められるかも
1
-
私が職場に違和感がある理由がわかった
すごく面白かった。私は職場では変わり者として扱われています。会社は純日本風にマイクロマネジメントで報告を求めてきます。しかし、私は自分で考えて自分で動きます。単にジコチューなだけかと思ってたんですが、本書に非常に近しい動きをやっていたことがわかりました。だから今年も昇格しなかったのか。そうか会社と俺はまるであってないんだな。すごく転職したくなってきますww
古い慣習で動いている偉い人々にこそ読んでほしいけど、古風な会社で偉くなった人は変わりたくない人だから読まないだろうな。
【引用】
（障害調査など）まずは、事実（データ）を一つ見つける→いくつかの仮説を立てる→その仮説を証明するための行動を取る。むやみやたらに試行錯誤するのではない。
理解の3要素
* その構造をつかんで、人に説明できること
* いつでもどこでも即座に取り出して使えること
* 知見を踏まえて応用がきくこと
デザインドキュメントを書くと良い（プログラマのために）
* score...このドキュメントの範囲
* bsckground...なぜこよプロポーザルを行っているかの背景
* problem statement...解決したい問題
* proposal...どういうデザインにするか、その理由
質問を恐れない！エンジニアがより賢くなるのはチームの幸せにつながる
メンタルモデル…人々が世界を理解し、予測し、解釈し、新しい状況に適用するための、自己の心の中のイメージや理論
2時間以上ブロックされたなら、質問するなり相談するなりして寝かせておいて、他の仕事をやっておく
既存システムなら、「まずエキスパートに頼る」
Be Lazy..やることを減らす
* 1つだけピックアップ
* 時間を固定して、その中で価値を最大化する
* 会議の場だけで完結させる
* 物理的にやることを減らす
検討ばかりしてさっさと「やらない」ことのほうが最大のリスク
「無理を承知で」のお願いの連鎖はみんなの疲弊を生み、チームや組織の業務改善に全くつながらない。
「計画の変更」は悪ではない。現実を見て、フィードバックを受けて納期や仕様が変わっていくのはむしろ「善」ということだ。
マスコミュニケーションロスサインがあらわれた時点で、手を動かす前に「何かおかしいぞと」と気づいてオフラインで話そう。音声のほうが100倍以上情報量かあってインタラクティブ性があり、フィードバックが速い。
「気軽に聞ける空気」は、「気軽に断れる空気」とセットになっている
「相手を否定しない」「相手のアイデアを否定しない」そして「自分の考えとして意見をいう」
「他人を否定しないこと」を職場のカルチャーの出発点にすべきなのだ。
人をコントロールして働かせようとする時代はもう終えなくてはいけない。
チーム全体が強くなるためには、気軽にお互いの知見を交換できるコミュニケーション文化が大切だ。聞くことを恐れずに、人に頼ろう。そして自分も役にたとう。
チーム内ではスキルや経験に関係なく、全員が同じ責任を持っているフラットな「仲間」としてふるまう。
1
-
マイクロソフトで働く著者が、同僚との会話や同僚の仕事ぶりから彼らの考え方を、日米の違いも踏まえつつまとめた本。伝統とか商習慣で凝り固まった現状を打破したいエンジニアや、マネージャーが読むべき良書。
日本の考え方と一番違うと感じたのは、品質と納期に対する考え方。日本ではQCDという考えは皆共通のはずで、口では品質品質というが、納期が絶対である。納期のためならばテストを粗くしたり、バグに目を瞑ったりが横行している。計画からの逸脱を異常に嫌うが、本当に大切なのは計画を守ることではなく品質を良くすることのはずである。マイクロソフトでは、自社製品ということもあるだろうが計画は変わりゆくものであり納期はかなり調整しやすいパラメータの一つである。一方で、品質については妥協がなく、品質を高めるために早期の（日本人の嫌いな）失敗をし、フィードバックを歓迎する。
本当に品質を良くするためには自分たちは何をしなければならないのかを考えさせてくれる一冊である。
1
-
これは良著です。
あくまで自分視点で書きます。同世代でエンジニアの端くれにいる私が見習うべきことが多過ぎました。仕事は効率よく、残業しないって昔は思ってました。ただ、今の会社に入ってから特に仕事が山積みで終わらないということが続き、それに慣れてしまっていました。確かに、前職までは割と時間でスパッと帰ってたような記憶ですが、今は、ここまで終わったらみたいな感覚でダラダラしちゃってる。
ここからは私の思いです。ダラダラと仕事をするから平日に何か他のことをやるエネルギーがないんです。だから、今の働き方で言えば、しっかりと9:00に仕事を始められるように朝、寒くでもダラダラと布団にいることを我慢し、18:00には遅くとも店仕舞いできるように、できればもっと早くても何も悪くないんだと思い直します。空いた時間に何かを学ぶ、読むでもいいですし、最近、完全にサボっているOUTPUTをするのも必要でしょう。
最後にまた本からの感想として、Cocoaの件は私も非常に悲しい。こんな国だからIT後進国になってしまう訳です。エンジニアがいないと言っている文系脳にお前がやればいいじゃんと私は言いたい。
私もプログラミングは商品として出すものとしては学生時代のバイトだけで、あとは社内ツールや業務効率化とかでやっているだけで、必要な時にやるが、必要なくなるとやらない。その波が数年周期でくる。ここ1、2年はまたコードに向き合うかという時期です。そのきっかけは、あるタスクが私にアサインされたこと。それをクリアする方法はいくらでもあるが、私はこれはエンジニアリングとして取り組んだ方がいいタスクだと判断し、今はコードと向き合っている。
自分でコードに向き合えることは武器になる。年をとり、固まっていない課題、タスクが降りてくるようになると解決策は武器の多さが大切になる。それが社内外の人脈だったり、お金を引き出す力とそれを使って解決する力だったりもするが、自力で挑めることも武器になっている。
最近、文系脳な人によく言っていること。「Excel使ってるでしょ。昔はExcelなんて文系人は使ってなかった。だから、今、SQLをやりなさい。」って。Excelでできるデータ取り扱いなんて、パソコンのスペックで限界がきている。ExcelよりDB、SQLだと思っている。
この国でもっとエンジニアリング寄りな思考を持てる人が増えてほしい。
1
-
米マイクロソフトにてAzure Functionsの開発に従事するエンジニアの方が執筆した一冊。
販売される前から気になっていてふと書店に寄ったら発売日よりも前に発売されていたので思わず手に取ってしまいました。
特に印象に残っていたのが以下の３つ。
1. 頭がよくても「理解」には時間がかかる
2. 頭の中に「メンタルモデル」をつくる
3. なぜ同僚達は「記憶力がいいのだろう」
1. 僕は新人とシニアの中間のエンジニアに分類されると思うがどのレイヤーにいてもものすごく頭が良い人たちは一定数いて、自分と頭の作りが違うんだなぁと思っていました。ただ、本書ではどんなに頭がいい人がいても理解のために時間をかけている。言うなれば自分が見ていない知らないところでちゃんと物事を噛み砕いて自分の血肉にしているんだということがわかり何か親しみさえ覚えました。MSの上位ソフトウェアエンジニアでさえ時間がかかるのであれば僕が物事に時間がかかるのは当然とさえ思えてモチベーションを分けてもえらえました。
2. "メンタルモデルとは、人々が世界を理解し、予測し、解釈し、新しい状況に適用するための、自己の心の中のイメージや理論"とあった。ただ人の話を聞いてそうなんだではなく、自分の中で理解のためのイメージを構築するというのは刺さるものがあった。ただ、自分はその構築が上手くないのでシステム思考ないし、本書でも紹介されている「ガブリエル・ワインバーグ箸の超一流が実践する思考法を世界中から集めて一冊にまとめてみた」これも自分の読書リストに追加して引き出しを増やすことを自分の中のやることリストに追加してみる。
3. これは自分がやったことをただそのままにするのではなく、クリアに説明できるようにすることが本当のやったことになるのだということでした。確かに。確かに。本当それなと頭の中で首を縦にぶんぶん降っていました。タスクが多くてやったらそのままどこかにNoteを残して次に進むという僕のスタイルでは数日後にはそれどうやったっけというのが日常茶飯事なので明日から実践あるのみです。
他にもマルチタスクが悪であることや一番優先順位が上のものしかやらないなどは他の本でも良く紹介されていることでしたが、現役のエンジニアの方からの説明だとより説得力が増しますね！
他にも共感できたのが、"[技術者たるもの、どんな批判も甘んじて受け入れ、まさかりを投げ合ってせいちょうするもの]みたいな圧を感じていた"というものだ。日本のエンジニアはこんな文化ある！確かに！！。これが心理的安全性を脅かして自分自身が幸せに仕事するのを阻害しているなぁと。僕もそういった面があったことは否定しないが最近は極力していないと思っているし、そういった時はなんとなく流すように努めている。
マイクロソフトはいかにお互いが尊重され、心理的安全性のもと成果のためにコミットできる場所、文化が形成されているんだということがわかり実際にオフィスに行くないしは自分も働きたいという意欲も分けてもらえました！
1
-
このブログを見て買った。
https://shinyorke.hatenablog.com/entry/how-world-class-engineers-think
タイトルが釣り臭くて手に取るの一瞬をためらったけど、書かれている内容は刺さるものが多かった。
シリコンバレーのエンジニアはこんなにもすごい、日本のエンジニアは遅れている、といった主張の本はいくらでもあって、どうもポジショントークみ感じて受け付けなかった。
本書も主張としては似ているが、筆者のバックグラウンドが
日本ではできないエンジニアとして劣等感を感じていた -> アメリカのマイクロソフトで働いてみて、同僚のマインドセットや習慣に刺激を受けた -> 思考と習慣を変えて活躍できるようになった
という王道少年漫画的ストーリーなので、共感を伴って読むことができた。
以下、個人的に参考になった箇所
- 「基礎」が何よりも大事。コピペで解決するよりも、コードをじっくり読んで理解した方が、ロングスパンでの生産性が高い
- 優先度をつけて、もっとも重要なことに集中する（他は捨ててもいい）
- 頭の中にフレームワークを持つことで、即興での理解を早める
- わからなかったらエキスパートに聞く。回答が返ってくるまでの間は一旦そのことは忘れて他の作業する。
- アウトプットを意識した形でメモをとる
書き出してみるとどれもよく言われていることだと思うが、凡事徹底が大事ということかな
1
-
生産性が高いエンジニアになるためのヒントがたくさん紹介されていて勉強になった。
日本が、USが、と主語が大きいのは少し気になったが、国民性として言いたいことには概ね同意できた。
以下が特に自分も取り入れたいと思ったポイント。
- 理解することに時間をとることを厭わない
- アウトカムに執着しすぎず、学びの時間を作る
- ミーティングの時間内で完結するようにミーティングに集中する。持ち帰りを避ける。
- マルチタスクをさける
- タイムボックスを設け、時間を作って他のことをする
- 運動や休息は生産性のためにも優先すべき
0
牛尾剛の作品
この本を読んでいる人は、こんな本も本棚に登録しています。
