Kindle版もあります。
「怠惰であれ!」「早く失敗せよ」――
米マイクロソフトの現役ソフトウェアエンジニアの著者が、超巨大クラウドの開発の最前線で学んだ思考法とは?
“三流プログラマ”でもできた〈生産性爆上がり〉の技術!・試行錯誤は「悪」。“基礎の理解”に時間をかける
・より少ない時間で価値を最大化する考え方とは?
・「準備」と「持ち帰り」をやめて、その場で解決する
・マルチタスクは生産性が最低なのでやらない
・“脳の負荷を減らす”コミュニケーションの極意
・コントリビュート文化で「感謝」の好循環を生む……etc.仕事と人生を「自分の手でコントロールする」最高のスキルがここに!
著者は1971年生まれで、ITエンジニアとして実績を積んだあと独立し、2015年にアメリカのマイクロソフトに入社された方です。
本のオビには「三流プログラマでもできた！」と書かれていますが、「三流」は誇大（過小）広告ではないか、とは思います。
「三流」には、「一流」の凄さを言葉にするのは難しいでしょうし。
僕がいままで本で読んだり、ネットで見聞きしてきた、一流エンジニアが切磋琢磨し、明日出社したらいきなり自分のデスクがなくなっているかもしれない状況でバチバチにやりあっているグーグルやアップルなどの最先端IT企業、というイメージがかなり変わる内容でもありました。
著者はこの本の冒頭で、「プログラマへの憧れ」をずっと持っていた、と述べています。
とくに才能があるわけでもないのに子供の頃からずっとプログラマに憧れていた。日本で就職した最初の会社では、「UNIXのコマンドを担当したいです！」と意気込んだが、希望かなわず5年連続営業職を務めた。あるときようやくシステムエンジニアとして働くチャンスを与えられたが、全くプログラムが書けない不甲斐ない日々が続く……。
実は大人になってからADHDと診断された私は、自分の不器用さや記憶力の低さ、頭の中で思考が乱れ飛んでまとまらず、ぐったり疲れてしまう感覚に、長年悩んでもいたのだ。だから、どうやったら不得意なことでも効率よく人並みのことができるのか、仕事の生産性を上げる方法を意識的に研究してきた。
そのおかげで、できる人だと構造的に見落してしまう部分──初心者はどこでつまづき、何に無駄な時間を使ってしまうのか、どうやってなるべく楽に「底上げ」してマシにするか、への感覚が人一倍高まった。
そんな頼りない私でも、社会人経験を重ねるうちに、いくばくか才能を発揮できる分野があることを発見した。それはすべて「誰かにやってもらう仕事」だった。
そうか、ADHDだったのか……これを読んで、専門家の知人に聞いた「ADHDでも、知能が高ければ『普通の人の生き方をエミュレート（模倣）できる」という言葉を思い出しました。
著者は、自分の弱点を克服するための試行錯誤を「効率化」「生産性の向上」の方法として自分の「強み」に変えていったのです。
コンサルティングやマネジメント、エバンジェリスト（ITのトレンドや技術についてわかりやすく説明し、啓蒙する職種）などの立場で成功をおさめていたにもかかわらず、著者はあえてプログラマとして、優秀な人材が居並ぶマイクロソフトで働く道を選びました。
僕は著者と同世代で、「マイコン（パソコン）」の黎明期に、すがやみつる先生の『こんにちはマイコン』（1982年）を読んで、「世の中を変えるかもしれない機械」に魅了され、マイコン少年からインターネット老害になってしまいました。
だから、現場でプログラミングをしたい、創造的な仕事をしたい、という「人生の夢」みたいなものは、わかるような気がするのです。
でも、好きでも得意でもないけれど、長年やってきて他者からはそれなりに評価され、定期収入と安定した生活が得られる仕事から、中年になって方向転換するというのは、すごいといえばすごいし、無謀でもありますよね。趣味でプログラミングをやれば良いのでは……と言いたくなるのだけれど、それでは自分を納得させられなかったのだろうなあ。
僕がこの本を読んで驚いたのは、著者がマイクロソフトで出会った「世界一流のエンジニア」たちの多くが、「他者に対して親切で、助け合いの気持ちと心の余裕を持っている」ということでした。
彼らの問題解決能力は圧倒的に高いのだけれど、一瞬のひらめきよりも、やみくもに手を動かすよりも、問題のボトルネックになっている部分をじっくり探し、仮説をしっかり立てて考えてから、それを検証していく、というアプローチをしているのです。
＜手を先に動かさない。まず仮説を立て、アプローチを選定してから動く＞──この鉄則を踏まえたうえで、何にでも応用可能な「未来の生産性」につながる本質的な頭の使い方について考えていこう。
ある若い同僚2人）まだキャリアこそ短いが非常に優秀で抜群に頭がいい）とランチをしたさい、新しいプロジェクトに取り組むときの話になった。
チームのアーキテクチャは非常に複雑なので、各マイクロサービスごとに誰かがつくった内部用のビデオが存在し、シリーズとして各項目を勉強できるようになっている。そんな複雑なアーキテクチャを把握している彼らのやり方に、私は興味があったのだ。
「いやあ、ビデオを見ても難しいので10回は見てるね。何回も見直して、わからないところはポーズしてメモして見てます」
もう一人の同僚も「やっぱそうなるよね。自分も何回も何回も見た」と言う。
技術イケメン2人の同じコメントは、目からウロコだった。
普段私は、難しいから1回見ても理解できないし、あまり頭に入ってこないので、実行したり、デバッグ（ソフトウェアを実際に動かして内部の状態を見る作業）して、ちょっとずつ理解していくステップをとっている。賢い人はああいう教材を見て一発で理解できてうらやましいなぁと思っていたが、全く違った。
どんなに頭がいい人でも理解には時間がかかるものなのだ。頭のいい人が理解が早いように見えるのは、そうやって時間をかけて基礎を積み重ねているので、既に理解していることに関して頭のメモリにコンテキスト（文脈）が載っているからだ。
私は、理解というものは最初から完璧にはできなくて徐々に身についていくイメージを持っていた。しかも、私は「とにかく生産性を上げなければ」「どうやったら早くできるだろう」と常に焦燥感にかられ、アウトカム（成果）を出すことに集中してきた。
しかし、皮肉なことに「早くできるように頑張る」ということが最終的な生産性をむしろ下げていたように思う。
プログラミングを例にいえば、Stack Overflow（プログラミング技術に関するコミュニティサイト）で調べて、コピペに近いことをしたほうが「成果」は出る。しかしそんなやり方では毎回調べることになるし、根本を把握していないからトラブルに弱く、結局は効率が悪い。今だと、Bingなり、ChatGPTに聞くとソリューションを教えてくれるだろう。だが、「理解」して「実践可能」にしていればそんなことすらする必要はない。
これを読んでいて、将棋の羽生善治さんが「直感」について書いておられたことを思い出しました。
直感は、本当に何もないところから湧き出してくるわけではない。考えて考えて、あれこれ模索した経験を前提として蓄積させておかねばならない。また、経験から直感を導き出す訓練を、日常生活の中でも行う必要がある。
もがき、努力したすべての経験をいわば土壌として、そこからある瞬間、生み出されるものが直感なのだ。それがほとんど無意識の中で行われるようになり、どこまでそれを意図的に行っているのか本人にも分からないようになれば、直感が板についてきたといえるだろう。
さらに、湧き出たそれを信じることで、直感は初めて有効なものとなる。
僕もけっこう長く生きてきたので、けっこうたくさんの「デキる人」を見てきましたが、彼らはみんな「ちゃんとふだんから勉強している人」でした。人間もパソコンと同じで、どんなに高性能のCPUを積んでいたとしても、ソフトやデータが全く入っていない状態では、その性能を活かせない。
そうやって、時間をかけて基礎を積み重ねられるのも「才能」なのだ、と言われてしまうのかもしれないけれど。
総じてイケてる技術者の人ほど、知らないことは知らないと素直に明かして気軽に質問する。これはアメリカのカルチャーによるところも大きいと思う。理解できないことを聞くことは恥ではないし、聞かれたほうも不愉快に思わない。
以前、あるアップルの製品発表のときに、故スティーブ・ジョブズが、iPhoneの新機能の特徴をプレゼンテーションした直後の質問コーナーで、「新機能の特徴を教えてください」と質問した聴衆がいた。私は「今、話したばっかりやん！」と思ったのだが、ジョブズは「Good question！」と言って、先ほどの説明をまったく同じように繰り返したのだ。
私の職場ではとても優秀な人でも、日本だったら「えっ、そんなこと聞く？」ということでも知らないことは簡単に隣の人に聞く。「Azureって何？」みたいな初歩レベルの質問をしても誰も問題視しない。
実際に全員が気軽に質問することを実践すると、組織全体の効率が相当上がるのは確かだ。聞けば自分より何倍もわかっている人から教えてもらうことができる。自分でググれば、調べる力はつくかもしれないが、意外に時間がかかってしまう。聞いたほうが圧倒的に早いのだ。
実は、この「気軽に聞ける仕組み」は、「気軽に断れる空気」とセットになっていることが肝心なポイントだ。これはスポーツカーが速く走れるのは、良いブレーキがついていて、いつでも止まれるから、ということに似ている。
例えばハッカソン（特定のテーマに対してそれぞれが意見やアイデアを出し合い、集中的に開発をすすめるイベント）をしていて、サポートしてくれる同僚がいるとする。彼らに助けを求めると気楽に答えてくれるが、自分がわからないと「あいつに聞いたほうがいいと思うよ」「うーん、わからないな。サポートに聞いたら？」と簡単に言う。これは、社内だからではなく、お客を相手にしていてもそんなスタンス。サポートを受けたほうも「助けてくれてありがとう」と笑顔で返して終わりだ。
アメリカのデキる人たちは合理的だよなあ、と感心しながら読んだのですが、同じ対応を日本で、日本人の同僚や会社のサービスセンターでされたら、「素っ気ないやつだなあ」とか「親身になって対応してくれない」と僕は感じてしまいそうです。
著者は、ソフトウェアの開発効率を考えると、助けになれない場合は、すぐに「ごめん」で済ませてくれたほうが聞くほうも聞かれるほうも気が楽だ、と述べています。
そこに「あっさり断るなんて、なんか自分には塩対応だな」というような不快感がなければ、たしかにそうですよね。
マイクロソフトという職場の空気や、本当に優秀な人たちは、どんなふうに仕事をしているのか。
一流エンジニアは、内部での競争よりも、組織として、全体としての成果を得るための協調を優先するのです。
僕はプログラミングには疎い中年男なのですが、読んでいて、「せめて、職場の風通しが良くなるように自分を律しなければ」と痛感しました。
こういうところで働けなかったのは、僕がそのレベルに至れなかったから、なのだろうなあ。
なんかちょっと悲しくなってきた……
