世界一流エンジニアの思考法
「怠惰であれ!」「早く失敗せよ」――
米マイクロソフトの現役ソフトウェアエンジニアの著者が、超巨大クラウドの開発の最前線で学んだ思考法とは?
“三流プログラマ”でもできた〈生産性爆上がり〉の技術!
・試行錯誤は「悪」。“基礎の理解”に時間をかける
・より少ない時間で価値を最大化する考え方とは?
・「準備」と「持ち帰り」をやめて、その場で解決する
・マルチタスクは生産性が最低なのでやらない
・“脳の負荷を減らす”コミュニケーションの極意
・コントリビュート文化で「感謝」の好循環を生む……etc.>
仕事と人生を「自分の手でコントロールする」最高のスキルがここに!
読む目的
凡人が仕事で高い生産性を出す方法を知ること
masuyama13.iconまとめ
頭のいい人でも理解には時間がかかる。基礎をきちんと学び、徹底的に理解する癖をつける。
マルチタスクをやめて1つだけのやることに全集中。全てを完璧にしようとするのをやめて、最も価値の高いものを見極めて1つだけを完璧にする。
プログラミングの基礎をおろそかにせずきちんと学ぶこと
理解に時間をかけること(その方が試行錯誤が減り結果的に早い)
コードを書く前にドキュメント(Design Doc)を書く
1つの最も大事なことにフォーカスする
早く失敗する
挑戦→失敗→フィードバック→修正 のサイクルを速く回す
比較検討より検証
不確実性を受け入れる
コードリーディングのコツはコードを極力読まないこと
何も見ないでできることを増やして、脳の負担を減らす
マルチタスクは生産性最低なのでやらない
WIPは1個まで
記憶力が悪いのは理解が浅いから
頭の中だけで整理する訓練をする
「理解・記憶・反復」によって脳の負荷を減らす
家も PC 内も片づける
毎日30分は運動する
メモ
生産性の高さの秘密
いきなり手を動かさない
少ない事実から仮説を立てて、検証する
試行錯誤は悪
時間を無駄にして学びはない
理解に時間をかける
頭のいい人でも理解には時間がかかる
それまでの積み重ねがあるから理解が早いように見えるだけ
プログラミングの基礎を学ぶこと
コピペでコードを書いていると基礎が身につかない
応用が効かない
LeetCode
徹底的に理解する習慣をつける
メモを取るより理解することに力を注ぐ
感覚よりファクトを重視する
感覚は思い込みの場合もある
コードを書く前にドキュメント(Design Doc)を書く
書くことで自分の頭が整理される
実装後に書くのは退屈
頭の中に「メンタルモデル」をつくる
メンタルモデルとは、人々が世界を理解し、予測し、解釈し、新しい状況に適用するための、自己の心の中のイメージや理論のこと
システム思考
なぜなぜ分析
自分なりの思考フレームワーク
まずエキスパートに聞く
既存システムがある場合、考えたり調べたりする前にエキスパートに聞く
知らないことで2時間以上使ったら、誰かに質問・相談する
偉大な習慣を身につけたプログラマになる
マインドセット
Be Lazy
より少ない時間で価値を最大化する
優先度の高い1つにフォーカス
日本では優先度が高い順に全部やろうとしがち
いかにやることを減らすかに頭を使う
ソフトウェアの機能のうち40%ぐらいしか使われない
100%を全力で作っても60%は使われない
やることを「減らす」こと自体に価値がある
一番重要な1つだけピックアップする癖をつける
時間を固定して、その中でできることを最大化する
その場で解決する
会議の場だけで完結させる
準備や持ち帰りをしない
どれだけやったか?(量)ではなく、どれだけ会社にインパクトを与える仕事ができたか?が重要
リスクや間違いを快く受け入れる
失敗から学ぶ
Fail Fast
挑戦→失敗→フィードバック→修正 のサイクルを速く回す
検討ではなく検証を
早くフィードバックをもらう
ツールなどが複数あって迷うときは「どれでもいい」
さっさと決めて早く検証に進むことが大事
比較検討に時間をかけるより、やってみてだめだったら乗り換える
早く失敗することはそれ自体に価値がある
最初から正しい方法がわかっている人はいない
不確実性を受け入れる
日本人が苦手な分野
納期より品質
スコープで調整
バリューストリームマッピング
開発プロセスを見える化して改善ポイントを見つけ、リードタイム短縮につなげる
「しないといけない」と思い込んでいるだけで実際には省けるプロセスは多い
機能リリースは縦スライス
フィーチャーフラグ
楽に達成できる計画で仕事をする
急な依頼は「マネジメント能力の欠如」
生産性が高い≠たくさんこなす
生み出すものの価値にフォーカス
「断る」練習をする
鏡の法則
人は自分に適用しているルールを無意識に他人に適用してしまう
寛容になりたかったら自分自身へのルールも緩やかに
自分の常識は他国の非常識
計画は変更されうるもの、計画変更は善
目標も変更していい
何を学んだかが大事
情報整理・記憶術
コードリーディングのコツはコードを極力読まないこと
インターフェイスと構造を理解するようにする
自分にとって難しすぎると感じるもの
基礎的な学力が足りていないパターン
無理なやり方をしているパターン
脳の使い方が間違っている
難易度の低いもので練習する
自分だけの力で即実装できるものを増やしていく
マルチタスクをやらない
WIP は1つにする
問題はその場で解決するか、ステップを1つ進める
1つのタスクに集中
中断するときは、再開しやすいように記録しておく
ブラウザのタブは閉じる
1日4時間自分だけの時間を確保する
すぐに返事を返さなくても思っているほど悪影響はない
記憶力が悪いのは、理解が浅いから
説明可能なレベルで理解すれば記憶に残る
ブログを書く
ノートの書き方「コーネルメソッド」
Note: 学んだことを思い出しながら書く
Cue: Note が答えになるように、質問を書く
Summary: 後日振り返って要約を書く
エビングハウスの忘却曲線
頭の中だけで整理する
ミーティングの議事をその場で書かない
人の話を聞くときは、他の人に説明することを想定して、聞きながら頭の中で整理する
文章を書き出して考えるのではなく、頭の中で考えて、完全に整理し終えてから文章に書く
理解・記憶・反復という黄金則
「脳の負担を減らす」ため
コミュニケーション
脳の負荷を減らす
情報は少ない方がよい
細かいことは聞かれてから答える
相手が本当に欲しい情報は何か?
コードもレビュアーのことを考えて書く
相手目線で質問・回答する
クイックコールする
エキスパートに聞いた方がよい
相手が忙しいかどうか考える必要はない
チーム全体の生産性が上がる
バグ対応を学びの機会にする
知らないことは気軽に聞く
わからなければわからないと答ればいい
ディスカッション
お互いが持っている意見を交換して、知識や考えを深めること
どちらが正しいかではなく理解を深める場
Agree to disagree
理解しがたい相手の意見や振る舞いも尊重して、受け入れる
In my opinion
自分の考えとして意見を言う
相手を否定しない
自分の理解を助けてくれてありがとう
会話力は気合いと慣れの要素も大きい
伝わるまで話して、理解できるまで聞く
知識をシェアして高め合い、エンジョイする
チームビルディング
サーバントリーダーシップ
リーダーはビジョンと KPI だけ示し、あとはチームが主体的に考えて意思決定する
<=> コマンドアンドコントロール(マイクロマネジメント)
自己組織チーム
仕事は楽しむもの
休暇を尊重する
生産性を上げる生活習慣
長時間労働はかえって効率が悪い
生産性を上げるには学習
タイムボックスを守る
瞑想
脳を休ませる
十分な睡眠
Time off
いつもと違うことをするのが大事
成功した人が幸せになるのではなく、幸せな人が成功する
片づけ
理解に時間をかける
新しいことを学んだらブログを書く
サンプルコードを少し変えて試してみる
脳の負荷を減らして整理する
毎日30分の運動
AI 時代をどう生き残るか
日本の「批判」文化、「責任の所在」や「完璧」を過剰に求める文化
ソフトウェア開発者の心を折ってしまう
少しでも失敗すると叩かれる
アプリには不具合があって当然
人間は失敗するもの
どうやったら自分の人生が幸せになるかを主体的に考えて、仕事の仕方を「選択」する
自分がやりたくないことはやらなくていい
自分の人生や幸せに責任を持って、自分でコントロールする