読書メモ｜世界一流エンジニアの思考法｜牛尾 剛
どんなに頭がいい人でも理解には時間がかかるものなのだ。
「お客さんの言ってることは聞くけど、信用せずファクトを検証していくのがいいよ」
「ドキュメントはコードを書く前に書くんだ。だって、コードを書いた後にドキュメントだけ書くなんて退屈だろ？」（略）考えているときに書けば、自動的にドキュメントになるので、それをシェアするだけで済む。（略）これはプログラマのためのものだということだ。第三者のステークホルダーのために書いているのではなく、自分がいいソフトウエアを書く上で理解して、効率よく開発するためにやっていることであって、誰かのためのものではない。
「メンタルモデルをつくるとそれができるようになる」（略）メンタルモデルとは、人々が世界を理解し、予測し、解釈し、新しい状況に適用するための、自己の心の中のイメージや理論のことだ。
一つのことで２時間以上ブロックされたなら、質問するなり相談するなりして寝かせておいて、他の仕事をやっておく方が断然生産性が高い。（略）既存システムがある場合は、あれこれ考えて調べる前にまずエキスパートに頼るというのはベストプラクティスだ。（略）エキスパートから情報がシェアされ、そのレベルから理解するフェーズに入れば、しっかりと肝心なことにフォーカスできる。
誰かが失敗したところで「あいつはダメだ」とネガティブに言っているひとはみたことがない。だから、より難しいことへのチャレンジがすごく気楽にできるのだ。（略）まずはやってみて、早くフィードバックを得て、早く間違いを修正していくFail Fastの精神だ。この考えはすべてのモダンな開発手法に共通する思想だ。人間は間違う生き物だということを出発点にしている。
検討ばかりして、さっさと「やらない」ことのほうが最大のリスクだということを肝に命じてほしい。
米国では「納期は柔軟」だ。Q（品質）C（コスト）D（納期）＋S（スコープ）は、トレードオフの関係にある。納期を短縮したければ、品質を落とすか、お金をたくさん払うか、提供する物量（スコープ）を減らすかのいずれかだ。
日本では「なるはやで」とか「明日までに」というオーダーで仕事を依頼されることが多いが、海外ではそうした火急の依頼は「マネジメント能力の欠如」とみなされる。（略）だれしも日々仕事では割り込みが入らないことのほうが少ない。（略）なにも「たくさん物量をこなすこと＝生産性が高い」わけではない。生み出すものの「価値」にフォーカスするマインドを身につけよう。
より少ない時間で価値を最大化できている集団ほど、会社内で「すべきこと」が圧倒的に少ない。インターナショナルチームではやるべき仕事はKPIの達成だけであり（略）やり方は本人の裁量に任されている。
コードリーディングのこつは、極力読まないことですよ。他のデベロッパーのことを信頼して、実装はちゃんと動くものとする
まず時間をかけて基本と構造を「理解」する。頭の中で整理された状態で「記憶」しないと何回も思い出す必要や調べ直す必要があるので時間ばかりかかって確信が持てなくなる。（略）ベーシックな理解が深いと、さほどの負荷もなく記憶しやすく、脳の負荷を減らす。（略）つまり技術イケメンでも複雑なものは複雑なのだ。でも、自分がゼロからつくったコードならすぐに理解できる。人間の脳の力にそんなに違いがあるわけではない。
特にエンジニアの人には「情報が少ない」方が好まれる。たくさん情報があっても消化できないだろう？という感覚。（略）メッセージを送っても無視されるのだ。「みんな忙しいだけ。たくさん書いてあると読むの大変じゃない？もっと単純なのでいいよ。（略）「要らないよ。負荷的な情報は聞かれたときでいいよ」
ものすごく賢い人たちでも技術の中身は即座に理解できるわけではない。（略）情報を最小限にし「簡単なこと」をしっかり説明する（略）理解してもらうことに丁寧に時間をかける（略）情報量をコントロールして説明すると一瞬で理解して、鋭い質問がバンバン飛んできたのだ。
彼女のメモは、見る人が欲しい情報はこれだろうという形で整理されている。エンジニアは開発だけではなく、他の人からの問い合わせ対応、障害の調査などにもかなりの時間を割かざるを得ず、引き継ぎの定期的に発生するものだ。（略）他のひとにシェアできる形式を意識して文書を書いて、リンクひとつでシェアできるようにしている
ディスカッションで鍛えられる重要な資質は「合意できないことに合意する」力だ。（略）どちらが正しいとか間違っているとか、意見に賛同するしないではなく、「相手のことを理解して認める力」といってもいい。「ああ、君は同意しないんだね」ということを理解するのだ。（略）「なんでイギリスに来ているのにイギリスのルールに則って振る舞わないんだろうね？」と言ったらホストファミリーのお母さんにこう諭された「ツヨシ、それは違うよ。私たちからみてむちゃくちゃでも、彼らには彼らの文化があるからそれを尊重しないといけないのよ」
コマンドアンドコントロールはメンバーを「社員」として扱い、サーバントリーダーシップはチームメンバーを「ステークホルダー」として扱うというのが大きな違いだ。アメリカにいると日本の企業にいたとき、いかに「子供扱い」されていたかを痛感する。
他のインターナショナルチームや、イギリスで仕事をしても、「仕事が辛くて」と言っているひとにはまず会ったことがない。（略）日本では、仕事は「我慢してなんぼ」の空気が濃厚にあって、楽しいと言っているひとは多くない。
そもそも知らないコードベースの開発は誰がやったって遅い。最初のアサインではすごく時間がかかるかもしれないが、そのジョブの次にはそのエリアではもっと早く仕事でできるわけだ。
日本から来たマネージャーはパワハラで訴えられることが多いという話を聞いたことがあるが、「お前は間違っている」とか「それは絶対違うだろう」みたいな発言をよく耳にしていた。（略）オラオラ系のマネジャーの態度は、国際的な職場において全く通用しない
実のところ、アメリカに来てから、失敗数は増えた。先のデプロイの話にしろ、大きなイベントが控えているのに、いろいろ自動化して工夫をしたり、必死でパラメータを調査したりしていたから起こったことだ。結局自分の能力を上回る領域にチャレンジするからこそ「失敗」は起こる。（略）失敗しても「よいフィードバックをありがとう」という声がけがあるからこそ楽しんで果敢にチャレンジできるのだ。
ある日ふと「もう挑戦はやめて日本に帰ろうかなあ。プログラマが自分に向いてないのはわかっているし・・・」と思った。（略）そんなおり、メンターのクリスとのメンタリングのセッションがまわってきた。（略）「生産性をあげるためには学習だよ。だから僕は仕事を定時くらいで切り上げる。その後で自分のやりたいトピックを勉強したり試したりする。すっと仕事していると疲れるし、同じプログラミングでも仕事と切り離したものはリラックスしてできるよね」（略）チーム内でもっとも忙しく技術力に秀でたファビオも「長時間労働はサステナブルじゃないって、よくメンバーに言ってるんだ」と言う。（略）一念発起して定時上がりに切り替えることにしてタイムボックス制で学習の時間を確保した。
あれ、もしかすると今まで散らかったいたのは「完了」させていないからではないか？（略）私は生活習慣において、あらゆることが「未完了」だったことに気がついた。（略）そこで意を決して何かをしたら必ず完了まで一息にやるように意識した。（略）するとどうだろう。20年前にADHDと診断されたとき、初めて薬を処方されて「普通の人の感覚」を一時的に体験できて驚いたが、それを薬を飲まないで再現できていたのだ。
例えばレストランなどで、AIが自動で完璧な美味しい料理をつくれたとしても、おそらく大半のひとは人間が料理し、給仕してくれるレストランで食事をしたがるだろう。
ジェフはこうリプライしてくれた「仕事がもはや面白くなくなったら、その時はなにか新しくて挑戦的なものを探すだけだよ」（略）クリスはこう返していた「いいトリックがあって、自分が何年も頑張ってきた分野のコンテキストで、どうしたらAIとアライアンスできるかを見つけ出して、そこから行くんだよ。それはたぶん、多くの分野でとてもインパクトがある。大勢のひとたちにとってたくさんの機会が存在するよ」とても救われた気分になった。
時流に惑わされず「専門性」を追求する姿勢こそが1番強いのではないだろうか。（略）誰もやったことのないものに取り組んでいる専門家は、AIにとって代わることは原理的にあり得ない。
日本にとって致命的な足枷になりかねない「批判文化」について検証したいと思う。（略）コロナ禍の惨状をみて「自分がなにか貢献できることはないか？」と考えてアプリ開発者である日本マイクロソフトの廣瀬一海さんが個人で始めたものだ。未曾有の危機をなんとかしようと善意でつくっていたものが、政府の目に止まって採用されたという経緯だ。ところがリリース後にプロジェクトに貢献したヒーローたちはボロカスに叩かれたのだ。（略）アプリケーションはどんなに優秀なチームが開発しようが、必ず何かしらの不具合は存在する。（略）このような展開はアメリカではまず発生しない。日本のSNSの寒々しい光景を見て、開発者たちはみな心が折れてしまったし、わたしもドン引きした。（略）この異常な完璧主義、先陣を切ってなにかにトライするひとに対する嫉妬にも似たくちさがない批判、冷笑、中傷が新しいことへのチャレンジ精神を根本的に奪い続けてきた。（略）「完璧なひとはいない」「物理的に無理なものは無理」という前提を社会の側が受け入れることが肝心なのだ。
失敗からは批判ではなく「フィードバック」が生まれるのだ。（略）アプリは不具合があるのは当然という考えがシェアされているので、報告した方もされたほうもありがとうという感覚を持っている。（略）一方日本では「誰に責任がある」とか「こうすべきだった」とか「品質が悪い」とか文句とダメ出しのオンパレードだ。それは困難な状況に立ち向かったひとに対して、椅子にふんぞり帰っているだけのひとがやっていることだ。
私が某大手SIerに入社した1994年頃は社内でも技術に優れた人がいて実際に自分でコードを書いていた人がおおかった。（略）ところがJavaでソフトウエアの設計がガラリと変わったのに多くの企業ではCOBOLのやり方を踏襲したようなやり方を続け、技術力がどんどん低下していったのだ。（略）平均レベルでいうと、今やヨーロッパと比べても低い。特に大手の低迷感が否めない。大きな理由は「自分でやらないから」だと思う。私は新技術導入のハッカソンのイベントを世界中でしてきたが、他の国のひとが全員みずから手を動かしてコードを書くのに、日本だけ、ハッカソンなのにコードをかけないひとが多かったのにはショックをうけた。何十カ国もの人が集まるなか「自分でやらない」ところは本当に日本ぐらいだった。（略）多くの企業で「力」を持つのは政治がうまいひとたちなのだ。実際に手を動かしてものをつくれるエンジニアたちは社内での扱いが低く、低い給与に留め置かれている。「プログラミング」を低レベルの人がやることとみなして外注し始めたことが、日本の大手SIer衰退の分岐点となってしまった。（略）海外のTEC大手のCEOがみんな技術畑出身なのは、現場的な鼻が利くことが意思決定に有効に働くことが増えているからに他ならない。
毎朝、ジムで5キロ走るのですが、そのとき見るyoutubeでみつけて一瞬で牛尾さんのファンになりました。エバンジェリストやっていただけあって、明るくてポジティブで楽しそうで本当にすてきなひとです。プログラミングが好きだけど下手で40過ぎてから渡米して英語にもプログラミングにも苦労しながら乗り越えて今があるところにもグッときます。苦手なことより得意なことを伸ばした方がいいってドラッカーはいうけど、「好き」に邁進して輝いているひとがいてくれるのは何よりの励みです。
同じマイクロソフトのエンジニアだからかもしれないけれど、考え方は中島聡さんに似てると感じました。