こんにちわ。Webエンジニアをやっているモリヤスです。
牛尾 剛さんの「世界一流エンジニアの思考法」という本を読んだので、特に印象に残った部分の紹介のまとめと感想を書いていきたいと思います。
牛尾さんはアメリカでマイクロソフトのソフトウェアエンジニアとして働いている方です。
マイクロソフトということで、会社で働いている周りのエンジニアはまさに一流。
そんな環境で働いている牛尾さんが、周りのエンジニアから学んだ思考法などを紹介されている本になります。
最初の理解に時間をかければ、最終的な生産性が上がる
(前略)
私は「とにかく生産性を上げなければ」「どうやったら早くできるだろう」と常に焦燥感にかられ、アウトカム(成果)を出すことに集中してきた。
しかし、皮肉なことに「早くできるように頑張る」ということが最終的な生産性をむしろ下げていたように思う。
プログラミングを例にいえば、(中略)調べて、コピペに近いことをしたほうが「成果」は出る。しかしそんなやり方では毎回調べることになるし、根本を把握していないからトラブルに弱く、結局は効率が悪い。
(中略)
理解が十分でないまま手を動かして努力しても、空回りになるだけで身につかず、あやふやの試行錯誤は取り組んだことも忘れやすく頭に残らない。
(後略)
(P28,29)
世界一流エンジニアの思考法 | 牛尾 剛
僕自身も、完全にコピペで済ませてしまっているということはないものの、理解が不十分のままにしてしまっている時があるので、改めて新しく使う技術など、根本の部分から理解を深めるようしていきたいと思いました。
ただ、言い訳にはなってしまいますが、各エンジニアの働いている環境に左右されてしまうことではあると思っております。(著者の方も、おそらくそういったことも理解した上で話してはいると思いますが…)
著者の方が働いている環境は自社のサービスを開発する環境であり、納期が絶対ではないと思っております。(僕がそう思っているだけなので、実際はわからない→本書に「納期は絶対ではない」という考えが述べれていました)
例えば、受託で開発しているような会社に所属しているエンジニアの場合は、もちろん案件にはよるとは思いますが、基本的には納期が絶対だと思います。
後者の環境で働く場合、「どうしても『成果』にとらわれてしまうよな〜」なんて思ったりしました。
さっさとやる
成功しようがしまいが、まずはやってみて、早くフィードバックを得て、早く間違いを修正していく
(P71)
今の時代、検討ばかりして、さっさと「やらない」ことのほうが最大のリスクだということを肝に銘じてほしい。
(P73)
世界一流エンジニアの思考法 | 牛尾 剛
「どんなに時間をかけて設計をしても、実際に作ってみないとわからないことが多い。実際に作ってみるとやっぱり無理だったなんてこともある。だから、検討ではなく、検証をしよう」というようなことが書かれていました。
どういった経緯だったかは忘れてしまいましたが、僕自身はある程度、上記のような考えで日々過ごせていると思ってますし、完全に同意できる内容でした。
歳をとってきてより感じているのですが、人生あっという間ですからね!( ;∀;)
とにかく
さっさとやるです!
仕事においては
特に成果物のゴールがわかりにくいものは、(認識が間違っていないかを確認してから)できる限り早く一通り作ってしまって、一度依頼者の方に確認してもらう
ようには意識してるし、
プライベートでは
やりたいと思ったことはできる限り、やってみる
ようにしています。
それでも日々を振り返って、「もっと早くできたよな〜」なんてことも、実はまだやりたくてやれていないこともたくさんあるので、僕自身もまだまだですね!
人生あっという間だぞ!(念押し)
言語化できて初めて理解
(前略)
そこで、時間は気にせず、自分がやったことをクリアに説明できるように時間をかけて言語化してみる。すると、いろいろな箇所で「あれ、俺なんでこここうしたんだっけ?」「ここって、他の実装でもいけないかな?」(中略)と疑問点が湧いてきた。
(中略)
説明可能にするということは、構造を整理して把握して、脳のメモリに乗せる必要がある。
(P116,117)
世界一流エンジニアの思考法 | 牛尾 剛
昔から、「人に教えられるようになったら自分のものになったと考えていいよ」ということを学校の先生や親から教わってきたことなので、上記のようなことは、なんとなくですが自分に染み付いている考えでした。
また、「言語化すると疑問点が湧いてくる」ということにはとても共感できました。
僕が、Web制作を学ぶ際に「デイトラ」というオンラインのスクールを受講していたときの話です。
そのスクールでは決まった時間内に、チャットツールでメンターさんに教材の内容を質問できるのですが、質問する際にテンプレートが用意されており、その通りに言語化して質問しようということが徹底されていました。
僕も質問する機会にテンプレート通りに言語化してみるのですが、その言語化している最中に、さらにわからないことが増えていくということがありました。
逆に、言語化をすることで質問する前に自分自身で解決できたということもありました。
言語化することで「疑問点が明確になり、自分で解決ができる」ということもありそうです!
情報量を減らす
アメリカで発見したのが、対クライアントでも社内のやりとりでも「脳の負荷を減らす」端的なコミュニケーションが喜ばれるという事実だった。
(中略)
それはプレゼンテーションや会議に限らず、日常業務のコミュニケーションでもそうだ。
(P132)
世界一流エンジニアの思考法 | 牛尾 剛
上記だけだとなかなか伝わらないかもしれないですが、本当に少ない情報でやり取りをしているそうです!
例えば、何かエラーが発生して質問するときは
(前略)
このエラーメッセージが出てるけど、何か知ってる?ぐらいでOK。付加的な情報は聞かれた時でいいよ」
(P133)
世界一流エンジニアの思考法 | 牛尾 剛
という感じだそうです!
本書にも書いてありましたが、質問をする際に、日本(というか、僕のこれまでの常識)ではどういう状況なのかを詳しく説明するのが良いとされています。
僕の常識を一気にひっくり返されてしまい、とっても驚きました!( ^ω^ )
ちなみに、前のセクションの「言語化できて初めて理解」で述べた、問題点を言語化することで自分で解決できるという可能性も出ててくるという話とこんがらがりそうだったので、僕の理解を下記にまとめてみます。
- 問題点はしっかりと言語化する
- 問題点の詳しい状況も自分の中でまとめておく
- 質問する際、アメリカでは本当に簡潔にする方が良い(詳しい状況は聞かれたら教える)
第6章
第6章では「仕事と人生の質を高める生活習慣術」というタイトルで、牛尾さんが仕事での生産性を高めるために行なっていることが書かれています。
簡単にまとめると以下のようなことを行なっているそうです。
- 定時あがりをして足りないと思う部分の学習をする
- 朝型
- 作業の節目ではなく、時間が来たら必ず終える「タイムボックス」制の導入
- 1日に何にどのくらいの時間を使っているのかを正確に分析し、何にどのくらい使うかを配分を決めて生活をする
- 脳の酷使を止める
- 脳が疲れたり、何かに飽きたりしたら、全く違うことをやる
- 整理
- 運動・筋トレ
特に上記の③と④は自分も見習わないといけないと強く感じました。
というのも、僕も1日の何時から何時に何をどのくらいやるというルーティーンを決めてはいるものの、どうしても時間で終えるのが難しく、節目までやってしまっているからです。
節目までやってしまうことで、確かに中途半端に終わるということは無くなっている気がするのですが、他にやりたかったことができなくなってしまい、なんとも残念な気持ちになってしまいます。(1日をトータルで見ると、なんか中途半端になってしまう)
また、そういったことが積み重なり、就寝時間が遅くなり、次の日の起きるのも遅くなり、やりたいことができず…
という悪い循環に入ってしまうことがあるからです。
なので、今後は覚悟を持って決めた時間内で何事も終える。
を徹底して生活していこうと思いました!
※僕の1日のスケジュールで、あれもこれもやりたいとかなり詰め詰めのスケジュールを立ててしまっていることも中途半端になってしまっている要因かもしれません…
やはり言い訳なのだ
本書を読んでいく中で、
「素晴らしい考え方だな〜」「いい働き方だな〜」なんて思う反面、
常に「でもそれって、みんながそういう考え方を持っている組織にいるからだよな」とか「まだまだエンジニアとしての実力もない自分なんかじゃ無理だ」とか。。。
心の中では「俺には無理だ」と思ってしまっている自分がいました。
(「最初の理解に時間をかければ、最終的な生産性が上がる」のセクションでもちょっと言い訳してしまったしww)
でも、それは全て言い訳だと思わされました。
「会社のルールで決まっているからできない」なら、会社のルールを変えるように動けばいいだけの話だし、どうしても嫌なら、会社を辞めればいい。
(中略)
厳しい言い方をすれば、面倒臭いことをするパワーがないから「自分でやらないことを選択」しているだけなのだ。
(P264)
世界一流エンジニアの思考法 | 牛尾 剛
幸いにも、僕は現在の働き方に不満はなく、楽しく働けています。
その中でも、常に自分の人生を自分でコントロールするという気持ちを持っていたいし、言い訳をせず、基本的に自責思考で人生を生きていきたいと思いました。
終わりに
働いていく上での考え方や生活の仕方も参考になることが多かったので、エンジニアではない社会人の皆さんにもおすすめの一冊な気がします!d( ̄  ̄)