世界一流エンジニアの思考法 牛尾剛

3行まとめ
感想
引用&コメント

3行まとめ

脳が使用するリソースをできるだけ削減するようにする
理解するのに時間をかけるほうが効率的である
エキスパートの力はどんどん活用する

感想

この種の思考法とか考え方のフレームワークに関する本ってなんか胡散臭いし、多くの読者が単に「イケてる感」を出すために読んでいるのではないかと疑っていたし、読んだ後実践してるやつ1割もおらんやろと思って敬遠してた。けれどもエンジニアからの評判が頗るよく、著者が出演していたpodcastを聴いたところ胡散臭さがなく、あっけらかんとしていた人だったので、読んでみようと思った。結果、しっかり勉強になったし、今後の行動とかマインドセットを変えてみようと思うこともできた。わかるわかる！と共感することも、なるほどなぁ～と感嘆することもあったが、中でも刺さったのが3行目まとめに書いた内容である。もう少し詳しく説明していく。

まず1つ目、「脳が使用するリソースをできるだけ削減するようにする」。これは頭脳労働をするなと言っているのではなく、むしろ頭脳労働で真価を発揮するために何も考えずに実行できる作業を増やせと言っている。また、これに関連して生産性を上げるとは、自分ではどうあがいても解決できない問題を時間をかけて調べたりエキスパートに質問したりして何とか自力で解決できるようにすることだけではなく、ちょっと調べたらできるような作業を何も調べずにできるようにして作業効率をあげる、という考え方もあるのではないか、という話があった。受験生時代にさんざん言われた応用問題に手を出す前に基礎をしっかり身につけようという話と似ているなと思った。受験もプログラミングも難しい問題を解決できるほうがかっこいいし、取り組んでいて楽しい。もちろん難問を解決するための努力も必要だと思う。ただ、基礎をふんわりとではなく完全に身につけるほうが受験では点は稼げるし、プログラミングでは作業効率が上がるんだろうなと思う。

続いて2つ目、「理解するのには時間をかけるほうが効率的である」。上と内容が被っているところもあるが、この話はなぜ一流プログラマーは自分のコードについて質問された時に一発で回答できるのか？という疑問に対する著者にとっての答えである。単に記憶力がいいというわけではなく、内容を完全に理解しているから忘れるという事象が発生しないのであろう、と。逆に自分では理解しているつもりでもその場しのぎのレベルでしか理解できていない普通のプログラマーは作業内容が頭に残っていないのだろう、と。個人的には作業していくうちに仕組みは理解していなくても体に感覚がしみ込み、形式上は使いこなせるようになり、そのあとにようやく仕組みが頭に入ってくるという事もよくあるのでとりあえず作業してみるのも大事なのではないかと思う。けれども、仕組みを完全に理解してしまうほうが忘れにくいというのはその通りだと思うので、理解できないことから逃げずに、徹底的に疑問点をつぶしていくことは肝に銘じたい。

最後に3つ目、「エキスパートの力はどんどん活用する」。現代では知識があるという事の定義が自分自身がその内容を知っていることではく、その内容にアクセスすることが可能である、といった旨のことが「知ってるつもり　無知の科学」という本に記載されていた。そういった意味でいうと、エキスパートの力を活用するとは、まさに自分の知識を増やすことに他ならないと思う。自分にとってもそのほうがいいし、さらには全体最適でもあると思うので、自分で解決できない問題に手間取るのは悪であるということを忘れずにチーム作業には臨みたい。

一冊を通して図の多用、太字とハイライトの使用、専門用語の解説など、IT関係の仕事をしてない人や技術書をよく読むわけではない人に対しても読みやすいように工夫が凝らされていて、サクサク読めた。ビジネス書や専門書を読むときは自分が知らない概念を知ることにしか価値がないと思っていたが、自分が強い信念を持っているわけではないが何となく考えていたことが自分以外の人も同様に考えているのだと知ることで、自信をもって今後遂行していくことができるようになる、という事にも価値があるのかなと思えた。読んだだけで実践しない口だけ野郎にはなりたくないので、読んだからには行動を変えていきたいし、この本からの引用という形で同僚にも同じマインドを共有してもらえるようにしたい。

引用&コメント

本文から印象に残った箇所の引用&コメントです。表現は適宜変更しています。

思いつきによる試行錯誤は「悪」。
手を動かす前に理解を深める強力な方法として、デザインドキュメント（Design document）を最初に書く、というコツがある。ワード数ページぐらいで設計のアイデアと大まかな仕様を書いた、すごく小さなドキュメントだ。
- 闇雲に検証するのではなく、仮説を立ててから挑めと言っている。なるほど、と思うだけでなく、きちんと実践したい。
LeetCode（コーディング面接の準備のための学習サイト）を一番簡単なレベルから毎日やる。
- 言うのは簡単で、実際に行なうことに価値がある。自分は三日で終わることはないにしても、一か月坊主になることが多いので、耳が痛い……

どんな人も、最初は難しく、理解には時間がかかるという真実──その本質的な気づきは、最後のワンピースとなって、私が人生で心から欲しかったものを与えてくれた。自分が仕事をコントロールできているという感覚、何かわからないことがあっても「自分ならやれる」と思える感覚だ。
- 自分に対しての自信は何をするうえでも大事だなと思う。
ソフトウェア開発では、例えば建築と比較すると変更が簡単で、逆にソフトウェアをつくらない段階で要件定義するのはとても難しいため、手戻りが発生したさいのロスが大きいウォーターフォールは正直向いていない。工程管理がしやすいので日本では重視されていたが、私が米マイクロソフトで様々なシステム開発の現場をみた中で、採用しているところはただの一つもなかった。
- ソフトウェア開発においてはウォーターフォールが優れていることは一切ないと言い切っていて笑った。自分は経験が少ないので判断を下せないが、アジャイルを推しているエンジニアは世間にも会社にもよくいる一方で、ウォーターフォールを推している人は確かに見たことない。世のエンジニアはぶっちゃけウォーターフォールのほうが向いてるプロジェクトなんかねえよって思ってんのかな？
アジャイル開発の有名な手法の一つに「スクラム」というものがある。ラグビーのスクラムにちなんだ5～10名からなるこの体制では、メンバー全員がオーナーシップを持って開発を進めるため、チーム内のコミュニケーションが非常に重要になってくる。各開発メンバーの役割は臨機応変で、他にプロダクトオーナー、スクラムマスターという役割が存在する
- アジャイルってスクラム以外聞いたことない。
「バックログ」（やるべきことリスト）
- 知らない単語だったのでメモ。バックログって言うんすね。
100個のタスクがあったら、本当に重要なのは20%程度なのだ。海外チームのメンバーを観察すると、20%のタスクを終えて80%の価値を出したら、残りの80%の価値を生む20%の新しいタスクに取り組んでいる。そうすれば、100%の仕事に時間を費やしたケースに比べて、40%の工数で160%の価値を持つ仕事だできるようになる。ざっくりとしたイメージでいうと、彼らが無理なく生産性が高いのは、こうした理由による。実施すべき「物量」が少なく「価値」が高いものを如何につくっていくかの工夫を常日頃からしているのだ。
- 「生産量」ではなく「生産性」を高めるってこういうことだなあ、と言われたら当たり前なのにハッとさせられてしまった。
会議に出たら「会議の時間内だけで完結」するよう訓練すると、非常に生産的だ。
- 本当にそう思う。宿題として持ち帰らない、会議中に資料は修正する、はすぐに実践できそうなので次からやる。
誰がやってもうまくいくようなことを無難に実施してミスがなくても、それは評価の対象にならない。
- これはちょっと過言な気がする。どんな単純な作業でもミスはつきものなので、ミスが少ないことに価値はあると思う。単純作業ノーミスよりミスしてでも専門性の高い作業をすることのほうが価値があるとは思うけど。
失敗して「怒ったり」「批判する」のはあなたと対等であるチームメイトを「子供扱い」しているのと同じだ。
- めっちゃいいこと言うやん。人に対して怒ってる人をみると、いつも自分はそうはなりたくないなと思う。
（アーキテクチャやツールに関して）圧倒的に差があるのなら、決めあぐねるはずがないので、何方を選択しても大差はないのだ。
- これはアーキテクチャやツールのことを完全に理解したうえで、という話かな？情報、知識、経験が足りていなければ、どのツールを使うかの調査に時間をかけることって意味がある気がする。
「納期は絶対」の神話は捨てよう。Q(品質)C(コスト)D(納期)+(スコープ)は、トレードオフの関係にある
モダンなソフトウェア開発メソッドでは「不確実性を受け入れる」のは、基本中の基本となってくる
- 本当にそう思う。作業時間の見積もりって完全に実装の方法が思い浮かんでいても難しいのに、やったことない作業の見積もりの時間とか意味あるの？って思う。自分が作業見積もりに時間使うのが嫌いだから逃げているだけの可能性もあるけど。
海外では火急の依頼はマネジメント能力の欠如と見なされる。「無理を承知で」のお願いの連鎖はみんなの疲労を生み、チームや組織の業務改善に全くつながらない。
日本人は時間厳守は当然という感覚だが、他の国だと時間通り待ち合わせに来るのが失礼という国すらある。
- 文化の差異を示すおもしろ具体例。時間通りに来るのが失礼ってどういう意味？
「計画の変更」は悪ではない。現実を見てフィードバックを受けて納期や使用が変わっていくのはむしろ「善」ということだ。
- 精度ってそうやって高めていくものですよね。
プログラマの場合は、細かい技術の積み重ねが勝負であって、コンサルティングのように具体的なサービスを提供するさいの「アウトカム」勝負ではない。アウトカムに集中すると一時的には良くても、中長期の「生産性」は上がらないのだ。
- ぶっ刺さりました。細かい技術の積み重ねが勝負だから自分はプログラミングが楽しくて、プログラミング力の高い人に憧れるのかもしれない。
マルチタスクは生産性が最低なのでやらない。
- 社内の勉強会でも似た内容のことを聞きました。社内ではマルチプロジェクトいっぱいあるけど、なくならんやろうな。
大前研一氏は、何かを変えたいときは、「住むところ」「付き合う人」「時間配分」のいずれかを変えるべきで、それ以外は意味がないという考察をしていた。
- 企業参謀の大前研一さん。企業参謀気になってるけど分厚くて手が出ない。
人間が記憶をするために有効な方法は、シンプルに「思い出そうと頑張る」ことだ。
- これ小学生のときにテレビで光浦靖子(本物)が勉強法として語ってて、それ以来実践してるやつ。暇を感じた瞬間に何かを思い出そうとするのおすすめです。
物事をできるようになるには三つのファクターが外せない。理解・記憶・反復。
クイックコールを頻繁に使うこと。(中略)配慮すべきポイントは、<相手が労力を要せず解答できるものか>どうかだ。(中略)この「気軽に聞ける仕組み」は、「気軽に断れる空気」とセットになっている。
- リモートワークでの必須スキル。聞いたほうが絶対早いよな、と思ったことはすぐに聞くようにしましょう。悩んでいる時間がもったいないので。だいたいは結局聞くことになります。
「自分が知らないときほどリプロ(ソフトウェアの問題の再現)するんだよ。効率がいいから」
- 「効率がいいから」が切れ味鋭い。
ディスカッションで鍛えられる重要な資質は、「合意できないことに合意する」力だ。
- めちゃくちゃいいこと言ってる！そういう人もいる、俺は違うけど。の精神は全人類持ってほしい。というかこの精神を持ってない人とは議論したくねえな。
新人は「できるもの」として大人扱いすると、周囲の助けを借りつつきちんとやれるのだ。スキルの習得も早く、皆堂々と自信を持った顔をしている。今の自分の実力以上のことは仲間が助けてくれるという安心感があるからだ。(中略)ただし、あまり成長が無かったり向いてなかったりすると、違う仕事にアサインされたりはする。だからみな、やりたい仕事は頑張って成果を出そうと思って取り組む。
- 権限委譲しましょうという話。仲間が助けてくれるという安心感は精神衛生上とても大事だと思う。中略以降の但し書きはシビアと思うけど、このほうがやる気出るし、もし合ってなかったら別の環境に移れるしで、個人にとっても組織にとっても幸せだと思う。
世界規模のグローバルなシステム開発でも、実際は小さなチームで行う。
- 絶対そのほうがいい。でかいチームは無理です。
会社のルールなんて所詮どこかのオジサンが過去に決めたものだ。過去にはそのルールが有効だったが、現時点で有意義かどうかはわからない。ルールは時代とともに変化していくもので、そこに人間が縛られるのはナンセンスだ。
- 専門職にも高いランクの立場があることだ。日本の企業にいたときは、例えばプログラマで良い給料をもらうのは難しかった。どこかでマネージャーにならないと給料ランクが上がらないので、たいていの人はマネージャを目指していた。
「責任の追及」や「批判」によっていったい世の中のなにが前進するというのだろう。
「プログラミング」を低レベルの人がやることと見なして外注し始めたことが、日本の大手SIer衰退の分岐点となってしまった。