内容
解決法
いきなり手を動かさない。
まずは、事実（データ）を一つ見つける→いくつかの仮説を立てる→その仮説を証明するための行動をとる。
思いつきによる試行錯誤は「悪」
理解
どんなに頭がいい人でも理解には時間がかかるものなのだ。
頭のいい人が理解が早いように見えるのは、そうやって時間をかけて基礎を積み重ねているので、既に理解していることに関して頭のメモリにコンテキスト（文脈）が載っているからだ。
理解の３要素とは次のようなものだ。
・その構造をつかんで、人に説明できること。
・いつでもどこでも即座に取り出して使えること。
・知見を踏まえて応用がきくこと。
そして、「基礎」練習は「誰でもできる」ことだが、習得には「時間がかかる」
「理解は時間がかかるもの」として、急がず、徹底的に理解する習慣をつける。
デザインドキュメント
デザインドキュメントを書くのは、次の二つの利点があると説明してくれた。
・ドキュメントを書くことで自分の頭が整理される。抜け落ちていた視点などに気づくことができる。
・考えているときに書けば、自動的に〝ドキュメント〟になるので、それをシェアするだけですむ。後でまとめて退屈なドキュメントを書かなくてよい。
機能
統計によると実際はソフトウェアの機能のうち40％ぐらいしか使われないからだ。
いかにやることを減らすか
一番重要な「一つだけ」をピックアップする癖
時間は固定して、その中で価値を最大化する
常に「会議の場」だけで完結する。
会議の時間を価値の高いものにしましょう
不確実性を受け入れる
「納期は絶対」の神話は捨てよう。
Ｑ（品質）Ｃ（コスト）Ｄ（納期）＋Ｓ（スコープ）は、トレードオフの関係にある。
進捗の「実績」だけで状況判断し、「納期」を固定したまま「スコープ」を出し入れするのが現実的
アメリカでは納期が近くなっても、「無理して機能を完成させなくていいから、品質の良いものをつくるようにしようよ」とマネージャから言われる。
最初衝撃を受けたが、さほど問題になりもしない納期とリリース機能を守るために、プログラマの生活や健康を犠牲にしてまで取り組むことは、中長期的には疲弊して生産性が低下してしまうことになるので、マネジメント的に効率が悪いのだ。
決して無理はしないほうがいい。
なぜならチームの適正な生産量を超えた量を一定期間で達成した結果、組織の問題を覆い隠すことにつながるからだ。
「今回できたのだから、次回もこれぐらいできるよね」と、無理が積み重なる悪循環に陥りがちだ。
チームの実態が上層部や周りに伝わらず、問題点も改善されない。
KPIは定時で無理なく楽に達成できる程度のものであるべきだ。
定時でできる量になるようシンプルに「作業量」を今の実力でできる範囲内に調整する。
重要なことは、自分がしんどいと思う「努力」は一切やめてしまうこと。
マルチタスク
・どんなすごい人でも、時間がかかることはかかる。焦らずに時間をかける。
・30分から１時間を割り当てたら、そのこと「のみ」に取り組む。すぐに終わらないものは、人に問い合わせるなど、物事を進めておいて、待ち状態にして、次のタスクに進む。
・一つのことをやっているときは、他のことは一切せず集中する。
・一つのタスクを中断する場合、次に再開するときに、すぐにその状態に戻れるように記録したり、整理しておいたりする。
・タスクの残骸は消しておく──例えばブラウザのタブは、そのタスクが終わったら閉じて、必要なものは記録する（そうしないと、気移りしてしまう）。
記憶力
時間は気にせず、自分がやったことをクリアに説明できるよう時間をかけて言語化してみる。
説明可能にするということは、構造を整理して把握して、脳のメモリに乗せる必要がある。
人に説明可能な状態にもっていく訓練として最良の手段の一つは、ブログを書いてみることだ。
記憶に関するもう一つの重要な要素は、記憶しやすくなる復習のタイミングを習慣化する。
次に私が実施した訓練は、「頭の中のみで整理する」
「どうやって複雑なことをその場で理解するかだって？それは頭の中にフレームワークをつくって考えるんだよ」
脳の負荷を減らす、という発想だ。
ベーシックな理解が深いとさほどの負荷もなく記憶しやすく、しかもメンタルモデルを使ったイメージで構造的に要点を把握してしまえば圧倒的に楽だ。
翌日見返すのも、記憶の定着を考えたときに結局はもっとも脳が楽だからだ。
それが理解→記憶→反復の好循環を生む。
日頃から人に伝えることを前提とした準備をしておくと、なにか聞かれたさいの工数削減にも直結する。
ソフトウェアエンジニアは、開発の効率化ばかり考えがちだが、こうした「自分が主体ではない」タスクの省力化をしていると、自分が好きな「開発」にもっと時間を使えるようになる。
私自身、他の人にシェアできる形式を意識して文書を書いて、リンクひとつでシェアできるようにしている。
そこは時間を惜しまずやるようにしているのも、必要に応じてそのリンクをシェアするだけで終了するからだ。
クイックコール
リモートワークが実際に生産性に結びつくかは、個人個人の成果を出す作業にどれだけ集中できるか次第だ。
会議は目的にそって、「簡単な進捗報告と、今抱えている問題のシェアだけ」にするか、後述するような「問題についてディスカッションする場」のどちらかに絞るのが効率がいいだろう。
ではどうやってチームメンバー同士、オンライン上のコミュニケーションの欠点を補ったらいいのだろう？
答えは、クイックコール（Quick Call）を頻繁に使うことだった。
周りを観察すると、リモートワークでも生産性が高い人はほぼすべてクイックコールをよく活用していた。
クイックコールとは、予定されていないビデオ通話のこと。
必要なときに Teamsとかのチャットで、先方から「今クイックコールしていい？」（Can I have a quick call?）と言われるので、良ければ「いいよ！」（Sure!）と送り返す。
するとコールがかかってきて１対１でコミュニケーションをとる。
そこから画面を共有して一緒に作業したりもする。
音声のほうが100倍以上情報量があってインタラクティブ性があり、フィードバックが速い。
問い合わせへの対応は面倒だと感じてしまうタイミングはあるだろうが、質問は自分の成長のきっかけになる。
中長期の貢献を考えると、自分のカバー分野以外のリプロやデバッグ（バグとり）を気軽にやってみる、という投資は非常にいいことなのだ。
この「気軽に聞ける仕組み」は、「気軽に断れる空気」とセットになっていることが肝心なポイントだ。
これはスポーツカーが速く走れるのは、良いブレーキがついていて、いつでも止まれるから、ということに似ている。
助けになれない場合は、すぐに「ごめん」でクールに済ませたほうが、聞く方も聞かれる方も気が楽なのだ。
ディスカッション
ディスカッションは「どちらが正しいか」はどうでもよく、「自分の考えを自分なりに深めるための行為」なので、初心者こそやったほうがいい。
コツは、「間違えたら恥ずかしい」という感覚は一切捨てること。
英語圏で、反対意見を言うときや他と異なる自分の意見を言うときに頻繁に出てくるフレーズが、「In my opinion」。
日本語でいうと、「自分の意見では」とか「自分の意見を述べさせてもらいますね」みたいなニュアンスだ。
このノリで話すと、たとえ相手のアイデアと正反対の意見でも、言われたほうが「心にぐさっとこない」感じになる。
心が痛まないのだ。
「相手を否定しない」「相手のアイデアを否定しない」、そして「自分の考えとして意見を言う」という鉄則を守れば、互いのメンタルを傷つけることなく、議論を生産性の向上に直結させることができるだろう。
チーム全体が強くなるためには、気軽に互いの知見を交換できるコミュニケーション文化が大切だ。
聞くことを恐れずに、人に頼ろう。
そして自分も役に立とう。
「みんなコーチって初心者に必要と思っているだろ？だけどオリンピック選手にも必ずコーチがいるんだ。誰だって人は、過去に経験がある人から学んでいくんだよ」
サーバントリーダーシップ
サーバントリーダーシップの場合、リーダーは〈ビジョンとＫＰＩ〉は示すが、実際にどのように動くかは、チームが主体的に考えて意思決定していく。
サーバントリーダーシップ制のもとでマネージャが重視するのは、各メンバーのメンタル面だ。
「ツヨシ、仕事をエンジョイしているか？」
マネージャのダミアンが私とOne on One（一対一の面談）をするときに必ず投げかけるのが、この言葉だった。
いかにメンバーたちが幸せに働けるかに高い関心を寄せ、エンパワーしてくれるのだ。
ゴール設定はかなり親身になって一緒にやってくれる。
私がそのゴールを達成するために困って相談をするといろいろアドバイスをくれるが、「あれしろ、これしろ」と細かく指示することはない。
マネージャの主な仕事は「アンブロック」だ。
つまり開発者（ＩＣ）がどこかで詰まっている状態になると、ブロックされているものを取り除いて（アンブロック）くれる。
そしてエンジニアたちが中長期的にどうキャリアアップしていけるか、相談に乗って支援もしてくれる。
各人の思い描く将来像に合わせて、どうやってスキルを高め、充実したキャリアを積み上げていけるか親身になってサポートしてくれるのだ。
結局自分の能力を上回る領域にチャレンジするからこそ「失敗」は起こる。
生産性
生産性を上げるためには学習だよ。
だから、僕は仕事を定時ぐらいで切り上げる。
その後で、自分のやりたいトピックを勉強したり試したりする。
良いプログラマになるコツ
私の技術の師匠のかずきさんは、良いプログラマになるためのコツを二つ挙げていた。
・新しいことを学んだらブログを書く。
・ブログを書くとき、サンプルコードそのままではなく、少し変えて試してみる。
つまり、書いて「整理する」プロセスで、頭の中も整理されて記憶に残りやすくなり、実践可能な知識に近づきやすくなる。
自分が思い出すプロセスを実行するので、記憶の定着にも貢献する。
アメリカではみんな「専門性を高める」という蓄積に価値が置かれ、スピードは思ったより重視されない。
結局は時間をかけて小さな努力を積み重ねるほうが圧倒的に良いものがつくれるのだから。
面白かったポイント
元エンジニア、生産性中毒の私にとってめちゃくちゃ刺さる内容。
すぐに着手しない、時間で管理する、学び続ける、言語化する、は私も実践している内容で共感。
若手のエンジニアは絶対読んだ方がいいと思う。
エンジニアだけではなくビジネスマンにも理解しておいてほしい内容。
私も何度も読み返したい本。
満足感を五段階評価
☆☆☆☆☆