# 世界一流エンジニアの思考法 チートシート
「場面 → 行動 → 根拠(章)」形式。詳細は `chapters/` 配下の各章ノートを参照。
## 生産性
| 場面 | 行動 | 根拠(章) |
|---|---|---|
| 障害調査やバグ対応にあたる | いきなり手を動かさず「事実を一つ見つける→仮説を立てる→検証する」というループを回す | 第1章 |
| コードやドキュメントを読む | 感覚で「わかった気になる」で済ませず、サンプルの数値を実際に書き出すなどして正確に理解するまで時間をかける | 第1章 |
| 複雑な機能を実装する前 | Scope・Background・Problem Statement・Proposalの4項目からなる数ページのデザインドキュメントを先に書く | 第1章 |
| 一人で悩み続けている | 自力で粘るより早めにエキスパートに質問・相談し、回答を待つ間は他のタスクを並行して進める | 第1章 |
| タスクが多すぎる | 全部を並行してやろうとせず「一番重要な一つ」だけを先にピックアップする | 第2章(前半) |
| 会議や作業に着手する前 | 使える時間を先に固定し、その制約の中で最大の成果を出すことに意識を切り替える | 第2章(前半) |
| 会議に臨む | 準備や持ち帰りに頼らず、会議の場だけで意思決定や問題解決を完結させることを目指す | 第2章(前半) |
| タスクの優先順位をつける | 上位20%の価値あるタスクに絞り込み、残り80%を思い切って手放す(2-8の法則) | 第2章(前半) |
| 納期を死守したい | 品質やコストを削るのではなく「スコープ(機能の範囲)」を柔軟に出し入れして調整する | 第2章(前半) |
| 依頼を受ける・予定を立てる | 火急の対応を美徳とせず、見通しを立てて「計画通り」に進められる量に絞る | 第2章(後半) |
| 「無理を承知で」の依頼が来た | 安易に引き受けず断る練習をし、自分に厳しいルールを他人に押しつけていないか点検する | 第2章(後半) |
| KPIやノルマを設定する | 「定時で無理なく楽に達成できる」水準に設定し、達成後に改善点やベストプラクティスを振り返る運用にする | 第2章(後半) |
| 一度採用した実装やアイデアに固執している | より良い方法が見つかったら、書いたコードへの執着を捨てて大胆に作り直す(コードを捨てる勇気) | 第1章 |
| ツールやアーキテクチャの選択で迷って決めあぐねている | 検討に時間をかけすぎず、実際に試してみて判断する | 第2章(前半) |
| 自分自身に「納期厳守」などの厳しいルールを課していると気づいた | 他人だけでなく自分自身に対しても、そのルールを緩めてよいと許可を出す | 第2章(後半) |
| 「これは無理」と感じている | 早めに言葉にしてチームでシェアする。個人が黙って抱え込むと、負荷はチーム全体に波及して疲弊を生む(願いの連鎖) | 第2章(後半) |
| リリースの意思決定に時間がかかっている | 機能を先に実装してスイッチはオフのまま置き、検証できたらオンにする(フィーチャーフラグ)ことで、始める判断コストを下げる | 第2章(後半) |
## 情報整理・記憶
| 場面 | 行動 | 根拠(章) |
|---|---|---|
| 他人のコードを読む | 全部を精読せず、クラスの役割・構造・インターフェイスの理解にとどめ、実装の細部は必要になったら読む | 第3章 |
| 新しい課題に取り組む前 | 「何もググらず即実装できる(L1)」〜「自分では無理(L4)」のどのレベルかを見極める | 第3章 |
| 「自分には難しすぎる」と感じたとき | 才能不足を疑う前に脳を酷使している可能性を疑い、基礎(L1)に立ち返る | 第3章 |
| 複数の仕事が同時に押し寄せる | マルチタスクは一切やらず、一つの仕事に30分〜1時間集中し、中断時は再開できるよう状態を記録してから移る | 第3章 |
| 一日のスケジュールを組む | 最低4時間はチャット・メール・会議通知をすべて閉じ、自分だけの集中作業時間としてブロックする | 第3章 |
| 何かを学んだとき | ブログやノートに書いて記憶に定着させ、コーネルメソッド(ノート/キュー/サマリー)で復習可能な形にまとめる | 第3章 |
| ミーティングに出席する | 議事をその場でメモに書き出すのではなく、頭の中でビジュアルイメージやメンタルモデルとして整理する練習をする | 第3章 |
| 頭の中だけで整理する訓練を始めたい | 準備のいらない場面(雑談・礼拝など)で「その場で記憶するつもり」で聞く練習から始める | 第3章 |
| 新しいことを覚える(暗記) | 通しで繰り返しインプットするのではなく、最初の一部から少しずつ「思い出そうと頑張る」ことに切り替える | 第3章 |
| 学んだことを記憶に定着させたい | 覚えた翌日と1週間後に振り返り、24時間以内に10分間復習する習慣をつくる | 第3章 |
| 自分がつくったコードでない複雑な実装に手を入れる | 無理な「努力」で理解しようとせず、コピー&ペーストして改造するなど脳の負担を減らすアプローチを恥じずに使う | 第3章 |
## コミュニケーション
| 場面 | 行動 | 根拠(章) |
|---|---|---|
| プレゼンやメッセージを作る | 情報を盛り込みすぎず、まず本質だけを簡潔に伝え、詳細は相手から聞かれたときに答える | 第4章 |
| 技術説明やプレゼンの準備をする | 時間をかけて丁寧に準備し、基礎的なことから順序立てて説明する(非ネイティブの弱みを補う武器になる) | 第4章 |
| メモやドキュメントを作る | 「自分がわかるため」ではなく「見る人が欲しい情報が簡潔に書かれているか」を基準に作成する | 第4章 |
| コードを書く | 読んだ人がどう感じるかを意識し、コメントで目的や意味を添えて読み物として成立させる | 第4章 |
| 文章のやり取りで行き違いや停滞を感じる | すぐにクイックコール(予定外のビデオ・音声通話)を申し出る | 第4章 |
| 質問しやすいチームを作りたい | 「気軽に聞ける空気」だけでなく「知らない」「今は答えられない」と気軽に言える空気もセットでつくる | 第4章 |
| 議論で意見が対立する | 相手のアイデアそのものを否定せず、切り出しは「自分の意見では〜」から始め、最後に感謝を伝える(Agree to disagree) | 第4章 |
| 周囲の成果物に反応する | まず「ありがとう」「助かった」を先に発信し、改善提案はその後に添える | 第7章 |
| コードのコメントを書くか迷う | 丁寧に書く。コメント不足はレビューに時間がかかり質問対応に追われる悪循環を招くと心得る | 第4章 |
| CIエラーなどの状況を報告する | 「これをやったらこのエラーが出た」程度の簡潔さで十分と心得る | 第4章 |
| 異なる文化的背景の相手と接する | 正しいか間違っているかではなく「違う」こと自体を尊重し、自分の物差しで裁かない | 第4章 |
## チーム
| 場面 | 行動 | 根拠(章) |
|---|---|---|
| チームを設計する | マネージャが細かく指示するのではなく、ビジョンとKPIだけを明確に示し実行方法はメンバーに委ねる | 第5章(前半) |
| 大規模プロジェクトを組織する | 10人以下の小さな自己組織チームに分割し、各チームが自ら意思決定しながら他チームと連携する構造をとる | 第5章(前半) |
| マネージャーとして部下に接する | 仕事の進め方に細かく口出しせず、ゴール・ミッションの共有とOne on Oneでのサポートに徹する | 第5章(後半) |
| チームや個人が困っている | 進捗管理ではなく「何がブロッカーになっているか」を探して取り除くことに時間を使う(アンブロック) | 第5章(後半) |
| 一度仕事を任せた後 | 途中経過を逐一チェックせず、結果が出るまで信頼して待つ | 第5章(後半) |
| スクラムなど自己組織チームの手法を導入する | コマンド&コントロール型のマネジメント習慣を本気で手放さない限り機能しないと心得る | 第5章(後半) |
| 部下や同僚に仕事を依頼する | 命令口調ではなく「お願いモード」を基本にし、困ったときに自分から助けを求められる「プル型」の空気をつくる | 第5章(後半) |
| メンバーが失敗した | 責めるのではなく「よくあることだよ」と受け止め、次のチャレンジを促す | 第5章(後半) |
| 部下や同僚が失敗を報告してきた | 批判ではなく「フィードバックをありがとう」と感謝を返す | 第2章(前半) |
| メンバーが休暇を取っている | 極力連絡せず、休暇から仕事を完全に切り離せる文化をチームでつくる | 第5章(後半) |
| 自己組織チームを組織に導入する | トップ層には数値効果、ミドル層には管理負担軽減、現場メンバーには指示待ち脱却支援と、層ごとに異なる不安に応じた説明・支援を用意する(図17) | 第5章(後半) |
| チームに質問しづらい空気がある | 「気軽に質問してみよう!」というメッセージを繰り返し伝える(Ask For Help)。ただしアドバイスは求められたときだけ行い、決定は本人にさせる | 第5章(後半) |
| 初対面のメンバーに大きな仕事を任せる | 「私の力じゃないよ、君の実績があるからだ」など本人の実績を理由に伝え、信頼を示す | 第5章(後半) |
| 新人を迎える | 「まだできない人」として扱うのではなく、最初から「できるもの」として大人扱いし、必要なときだけ周囲が助ける前提でチームを設計する | 第5章(後半) |
| 自分の意見が誰かと対立した | それは単に「意見が違う」だけの話であり、相手の人格や関係性を損なうものではないと割り切る | 第5章(後半) |
## 生活習慣
| 場面 | 行動 | 根拠(章) |
|---|---|---|
| 生産性を上げたい | 長時間労働ではなく「定時で終わらせる」という制約を先に設定する | 第6章 |
| 学習や集中を要するタスクに取り組む | 頭が冴えている朝の時間帯にタイムボックスとして固定配分し、終了時刻をアラームで強制的に区切る | 第6章 |
| 頭が働かない・疲れている | 5〜10分タイマーをセットして呼吸に意識を向ける瞑想の時間を確保する | 第6章 |
| 就寝前の過ごし方を見直す | ディスプレイから意識的に離れる時間をつくり、ブルーライトカット眼鏡なども併用する | 第6章 |
| 睡眠時間を削りたくなる | 最低5時間、できれば7時間を目安に確保し、睡眠不足を気合いで乗り切る発想を捨てる | 第6章 |
| 作業や家事に取りかかる | 中途半端にせず、着替え→洗濯籠に入れるなど一つひとつの行為を「完了」させる習慣をあらゆる場面に適用する | 第6章 |
| 部屋やデスクが散らかっている | いきなり全体を片付けようとせず「机の周りだけ」など小さな範囲から始める | 第6章 |
| 運動の優先度を上げたい | 「時間があったらやる」ではなく、テストステロンを増やす・脳を活性化させる目的で意識的に高いプライオリティを与える | 第6章 |
| 周囲と働くペースが合わず気になる | 「みんなと同じペースで働く」ことにこだわらず、自分に合ったペースを尊重する/されることを大切にする | 第6章 |
| タイムボックス制を運用する | 「完了」できたかどうかより、何にどれだけ時間がかかったかを記録し、データドリブンに配分を見直す | 第6章 |
| パソコン内や頭の中の情報を整理したい | 「デスクトップ」「頭の中」「コンピュータのデータ」という複数レイヤーで並行して整理する | 第6章 |
| 自己流のトレーニングに限界を感じる | パーソナルトレーナーの指導を受け、追い込みすぎを防いで継続可能な負荷に調整する | 第6章 |
## AI時代
| 場面 | 行動 | 根拠(章) |
|---|---|---|
| AIに仕事を奪われる不安がある | 代替可能性を恐れるより、自分が積み上げてきた専門性をAIとどうアラインさせるかを考える | 第7章 |
| クラウドやAIサービスの動向を追う | 技術ニュースとして消費するだけでなく、自分の業務に組み込めるインテグレーションの機会を探す | 第7章 |
| 不具合や課題を見つけた | 頭ごなしに批判せず「こうしたらもっと良くなる」という建設的な貢献(コントリビュート)の形で伝える | 第7章 |
| 「会社のルールだから」と感じる | それが本当に外的制約なのか、単なる自分の思い込みなのかを一度疑ってみる | 第7章 |
| キャリアや働き方に不満がある | 環境を変える・会社を辞めるという選択肢も現実的な手段として検討する | 第7章 |
| 日々のコーディングや調べ物で悩んでいる | 一人で抱え込まず、AI(ChatGPTやCopilotなど)に積極的に聞いてから動く順序に切り替える | 第7章 |
| 他者のプロジェクトの不具合に気づいた | 指摘するだけで終わらせず、可能なら修正コードそのものを送るところまで踏み込んで貢献する | 第7章 |
| 挑戦して失敗した人を見かけた | 批判や冷笑ではなく、まず労いと感謝を示してチャレンジ精神を守る側に回る | 第7章 |
| 日々の選択に迷う | 「自分がやりたくないことは一切やらない」を基準に、自分が幸せになる方向を選び直す | 第7章 |