読書まとめ『世界一流エンジニアの思考法』→成果で人生のコントロール感を取り戻す
『世界一流エンジニアの思考法』牛尾 剛
一言で言うと
成果で人生のコントロール感を取り戻す
概要
エンジニア界隈でよい評判を
たくさん聞いていた本です。
図書館の予約をキャンセルして、
購入して読んでみました。
著者は、大手SIer から独立を経て、
Microsoft 本社でエンジニアとして勤務しています。
プロジェクトマネジャーやエバンジェリストとして
成功してきたにも関わらず、
プログラマへの憧れからエンジニアの道を選んだとのこと。
note でも、学びの深い投稿をされています。
タイトルにあるとおり、
著者が一流エンジニアから学んだ
思考法・マインドセットの説明が中心です。
スキルやテクニックの引き出しを
増やすことももちろん大事ですが、
それよりも土台に注目しています。
本書の仕事術の真髄は、
何かをやめて身を軽くすること
だとあとがきで述べられていました。
本質的でないこと・効率が悪いことをやめて、
心身を楽にすることで、
高いパフォーマンスを生み出すことができる、
というワケですね。
また、自分の人生を自分で決めることも、
著者からの強いメッセージとして感じました。
本書の仕事術はかなり先進的であり、
日本企業で採り入れるにはハードルが高い…
という印象は否めません。
しかし、それは自分の人生を
他者にコントロールされている人の発想。
面倒くさいことをやるパワーがないから、
外的要因のせいにしているだけです。
世界一流のエンジニアは、
自分の幸せのために主体的な選択をしており、
不幸そうな人がいない、と述べられています。
自分の人生を自分でコントロールしている感覚、
いわゆる自己効力感が、
成果を上げるために重要な要素だと感じました。
成果が上がれば、自己効力感も上がり、
好循環ができあがっていきます。
自己効力感がパフォーマンスにつながることは、
『ヤバい集中力』からも読み取っていましたね。
本稿では、最速で成果を上げて自己効力感を高めるために、
心に留めておきたいことを 3点でまとめました。
① 試行錯誤をやめて、基礎を理解する
基礎の理解に時間をかけるべき、
という提言は、本書で何度も登場しています。
うまくいなかいことがあったときに、
試行錯誤して手を動かして、
うまくいったら OK、では
生産性は上がらないのだと主張されています。
なぜなら、うまくいかなかった理由を
理解していないと、再現性がないから。
一夜漬けの丸暗記と同様に、
自分の知識や能力の向上にはつながりません。
まったく同じ問題には対処できても、
少し条件が違えば対応できなくなるおそれがあります。
生産性向上のためには、
基礎の理解に時間をかけて、
ググらずにできることを増やす方が効果的です。
例えば、ある関数に対する知識が中途半端だと、
使い方を適宜検索・確認しながらコードを書くことになり、
生産性は上がりません。
一方、時間をかけてでもしっかりと理解していれば、
その部分に関する脳の負荷が減り、
自分が理解できていない他の部分を
考える余力も生まれます。
プログラムは複数のパーツの集まりなので、
難なく書けるパーツを増やすことで、
生産性向上が期待できます。
著者のまわりの「技術イケメン」たちも、
一目でコードを理解できているわけではなく、
理解に時間をかけているのだとか。
理解するために、
同じドキュメントを何度も読んだり、
詳しい人に聞きにいったりしています。
他者からは見えないところで学習を重ねて、
少しずつ理解を深めているわけです。
理解度を高めるためのアクションとして、
レベルの低い課題を侮らずにこなすこと
が挙げられています。
私の場合は、Power Apps や Power Automate で
簡単に実装できると思って構想だけして、
実際には作っていないアイデアがいくつかあります。
いざ作ってみると、
一筋縄ではいかないポイントがあってつまずく、
なんてことが多いんですよね。
簡単にできそうだ、ではなく、
実際に簡単にできるような能力を
身に着けなければいけないと感じました。
ググらずに使いこなせる関数・機能を増やすべく、
時間をかけてでも理解するようにせねば。
② 批判をやめて、フィードバックする
他者との関わり方においては、
コミュニケーションを通して
フィードバックを与え合うことが勧められています。
組織で働くときだけでなく、
社外コミュニティなどでも求められる姿勢です。
著者は、日本独特の批判文化が
イノベーションの機会を奪ってきた、
と断じています。
9割成功していても、
1割の失敗をクローズアップして、
批判したり責任を追及したりする。
失敗を許容しない完璧主義的な姿勢は、
特にアジャイルなソフトウェア開発の場においては
足を引っ張る考え方になってしまいます。
アメリカでは、人に何かを期待するのではなく、
「自分がどう貢献できるか」を考える
コントリビュート文化が根付いているそうです。
だから、成功に対して感謝するし、
失敗に対して自分にできることを考えて行動する、
と考察されています。
たしかに、失敗を批判することは、
完璧な成功を他者に要求していることの裏返しですよね。
以心伝心・阿吽の呼吸で空気を察する
文化を作ってきた日本人は、
他者への期待が大きすぎる側面があるのかもしれません。
失敗に対する考え方としては、
目標設定のくだりで出てきた
「取り組みの中で得た学びのシェアこそがバリュー」
という表現が至言だと思いました。
失敗しないような計画を長時間かけて作るより、
早くアクションして学びをシェアして、
フィードバックを得ながら前に進める方が
トータルでの生産性は高くなります。
note をはじめとした SNS では、
コメントが有効なフィードバック手段になりますね。
『デジタル・ミニマリスト』で指摘されていたとおり、
スキは 1 ビットの情報でしかありません。
相手にとって役立つ情報を与えられればベストですし、
たとえ感想だけであっても、
やはりコメントはスキよりもうれしいものです。
1 ビットの情報だけでなく、
自分の思いをちゃんと言葉にして、
コメントとして相手にフィードバックする。
毎日コメントに Try したこともありましたが、
もう少し低くても数値目標を決めておくことで、
フィードバックのトレーニングを試みようと思います。
③ 独力をやめて、他人の脳を借りる
他者を頼ることのハードルを下げる
マインドセットを持つべきだと感じました。
自分ひとりの力では、
効率や生産性の限界を避けられません。
自分ひとりでは成し遂げられないことも、
他者の力を借りることで達成できる可能性が高まります。
…というのはわかっているんですが、
私も他者を頼ることが苦手だという自覚があります。
なぜ他者を頼ることが苦手なのかを考えてみると、
相手に迷惑をかけてしまうかもしれないから、
という理由が思い浮かびました。
技術・知識に明るい人は大きな仕事を抱えているもので、
そんな相手に時間を取らせてしまうのは申し訳ないな、
と思ってしまうんですよね。
でも、自分が他者から頼られたら、
やっぱりうれしくないですか？
その他者を助けることで、
チーム・組織の生産性が向上しますし、
自分の成長にもつながります。
例えば、技術的な質問をされたら、
その技術をさらに深掘りしたり、
自分とは異なる捉え方を知ることができたりする
チャンスでもあります。
もちろん、頼られた場合に、断わったり、
あとで時間を取ったりする選択も必要です。
本書でも「気軽に聞ける仕組み」と
「気軽に断れる空気」はセット、
と述べられています。
頼る側も、たとえ依頼を断わられても
相手との関係性が悪くならないような、
「断わられやすい頼み方」を
身に着けておきたいところです。
気軽に頼れる・断われる環境をつくるには、
自分の得意なことや悩みをオープンにする
必要があると感じました。
これは『どこでも誰とでも働ける』で学んだ、
自分が何者で、何ができるかを宣言すること
とも重なりました。
自分がギブできること、
ギブしてほしいことを明示しないと、
コミュニケーションが生まれにくいですからね。
明示といえば偏愛マップ、
有休消化が完了するタイミングで更新しておかなきゃ。
また、②でも触れた「他者への期待値を下げる」ことは、
他者への依頼でも重要だと感じました。
他者に完璧な回答を求めてはいけないし、
その回答を採用するかどうかの責任は
自分が負わなければなりません。
また、どんな回答であれ、
回答してもらったことに対する感謝を
忘れないようにしたいですね。
Amazon.co.jpアソシエイトに参加しています。
#推薦図書 #読書 #書評 #最近の学び #世界一流エンジニアの思考法 #エンジニア #仕事 #思考法 #マインドセット
いつも図書館で本を借りているので、たまには本屋で新刊を買ってインプット・アウトプットします。