# 世界一流エンジニアの思考法 用語集
本書に固有の用語、および本書が独自の意味づけで使う一般用語。カテゴリ順に整理。
## 思考法・生産性の基本概念
| 用語 | 定義 | 参照章 |
|---|---|---|
| 一流エンジニア | 単にプログラミング技術が高いだけでなく、独自の思考法・マインドセットを持ち高い生産性を発揮するエンジニアを指す、本書における理想像 | はじめに |
| 思考法(マインドセット) | 小手先のテクニックではなく、仕事への向き合い方や頭の使い方そのものを指す本書の核心概念 | はじめに |
| メンタルモデル | 人が世界を理解・予測・解釈し、新しい状況に適用するための脳内イメージや理論。目に見えないソフトウェアの動作を頭の中でシミュレーションできる状態を指す | 第1章 |
| 理解の3要素 | 説明可能(explainable)・いつでも使える(anytime usable)・応用可能(applicable)。表面的な暗記と区別される「本当の理解」の判定基準 | 第1章 |
| 試行錯誤は「悪」 | 手を動かす前に仮説を立てず闇雲に試すアプローチを戒める著者の造語的フレーズ。頭脳労働の効率を著しく下げるとされる | 第1章 |
| デザインドキュメント | 実装前にScope・Background・Problem Statement・Proposalを数ページでまとめる軽量ドキュメント。手を動かす前に理解を深めるための実践手法 | 第1章 |
| システム思考 | ソフトウェア全体をアーキテクチャ・クラスの構造・相互作用として俯瞰的に把握する考え方 | 第1章 |
| Be Lazy(怠惰であれ) | より少ない時間・労力で価値を最大化しようとするマインドセット。本書全体を貫く鍵概念 | 第2章(前半)・第5章(後半) |
| 2-8の法則 | 20%のタスクが80%の価値を生むという経験則。優先順位の低いタスクを手放す判断の根拠として使われる | 第2章(前半) |
| Fail Fast | 早く失敗し、そこから素早く学んで方向修正するという開発思想 | 第2章(前半) |
| Miserably Failed(惨めに失敗した) | インターナショナルチームでよく使われる表現。失敗をオープンに語ることを厭わないアメリカの文化を象徴する言葉 | 第2章(前半) |
| VUCA | Volatility(変動性)・Uncertainty(不確実性)・Complexity(複雑性)・Ambiguity(曖昧性)の頭文字。予測が困難な現代のビジネス環境を表す略語 | 第2章(前半) |
| QCD+S | 品質(Quality)・コスト(Cost)・納期(Deadline)・スコープ(Scope)の4要素。トレードオフの関係にあり、納期を固定するならスコープを調整すべきという文脈で使われる | 第2章(前半) |
| バリューストリームマッピング(VSM) | ソフトウェアがリリースされる時点からさかのぼり、どのプロセスにどれだけ時間と人がかかっているかを可視化する手法。LT(リードタイム)=PT(実処理時間)+WT(待ち時間)で分解する | 第2章(前半)・第2章(後半) |
| 「楽に達成できる」計画 | 火急の依頼を避け、余裕を持って自分や他人の仕事量を設計する考え方 | 第2章(後半) |
| 「結果を出す」から「バリューを出す」へ | プレッシャーで結果を絞り出す姿勢から、取り組みの中で得た学びのシェア自体を組織の財産とみなす姿勢への転換 | 第2章(後半) |
| 25倍の生産性差 | 「できるプログラマとできないプログラマの差は25倍ある」という言説を、著者は才能の差ではなく頭の使い方(仮説検証か手当たり次第の試行錯誤か)の差として再解釈する | 第1章 |
| コードを捨てる勇気 | 一度書いたコードへの執着を手放し、より良い実装が見つかれば大胆に作り直す姿勢(COLUMN) | 第1章 |
| アジャイル/スクラム | 2001年の「アジャイルソフトウェア開発宣言」に端を発する開発手法(COLUMN)。ウォーターフォールとの対比で語られ、短いサイクルでのリリースとチームのオーナーシップを特徴とする | 第1章 |
| DevOps | 開発(Development)と運用(Operations)の役割の対立を解消し両者を統合する考え方(COLUMN) | 第1章 |
| ハックフェスト | 「お客さんのもっとも難しい問題を解決する」取り組み。失敗しても「今日はたくさん失敗しよう!」と歓迎される空気の象徴的エピソードとして紹介される | 第2章(前半) |
| ノーバリュー | 工数を使ったにもかかわらず何も価値を生み出せていない案件のこと。検討に時間をかけすぎることの弊害を表す言葉 | 第2章(前半) |
| 不確実性の忌避 | 日本人がとくに苦手とする文化的性質。先を予見し緻密な計画を立てることに時間をかけすぎ、「計画通り」への固執がプロジェクトの炎上を招くと指摘される | 第2章(前半) |
| フィーチャーフラグ | 機能を先行実装しておき、後からオン・オフを切り替えることでリリースタイミングを制御する仕組み。リリースの意思決定コストを下げてリードタイムを短縮する | 第2章(後半) |
| 願いの連鎖 | 個人が無理をしてプロジェクトの帳尻を合わせる行為が、問題の先送りとなってチームや組織全体の疲弊を生み出す構造 | 第2章(後半) |
## 情報整理・記憶
| 用語 | 定義 | 参照章 |
|---|---|---|
| 仕事の難易度レベル1〜4 | L1=何もググらず即実装できる、L2=ググれば解決、L3=スパイクソリューションがあれば何とかなる、L4=自分では無理、の4段階分類 | 第3章 |
| アウトカム至上主義 | 成果を急ぐあまり難易度の高い課題ばかりに挑み、基礎的な習熟(レベル1の拡充)を怠ってしまう罠 | 第3章 |
| WIP=1(Work In Progress=1) | 今手を付けている仕事を一つに限定する原則。マルチタスクの逆 | 第3章 |
| コーネルメソッド | 米国コーネル大学発祥のノート術。ノートエリア(学んだことを書く)・キューエリア(後から思い出すための質問を書く)・サマリーエリア(後日要約を書く)の3分割で構成 | 第3章 |
| 理解・記憶・反復の黄金則 | 物事を使えるレベルまで習得するために外せない3つのファクター | 第3章 |
| エビングハウスの忘却曲線 | 記憶の減衰と復習タイミングの関係を示す研究。24時間以内の10分間復習で記憶が100%戻るという知見の根拠 | 第3章 |
| 「思い出そうと頑張る」記憶法 | 通しで繰り返しインプットするのではなく、最初の一部から少しずつ想起の負荷をかけることで記憶を定着させる方法。著者の歌詞暗記の自己実験に由来 | 第3章 |
| コードリーディングは「極力読まない」 | 実装は動くものと信じ、インターフェイスと構造の理解に絞る読み方。同僚クーパーの助言に由来する | 第3章 |
## コミュニケーション
| 用語 | 定義 | 参照章 |
|---|---|---|
| 「情報量を減らす」コミュニケーション | 詳細を先回りして伝えず、聞かれたら答えるという情報設計の原則 | 第4章 |
| 見る人を意識したメモ | 自分用ではなく、他者が読んで即座に使える形式で整理されたメモやドキュメント | 第4章 |
| クイックコール(Quick Call) | 予定外に即座に行う短時間のビデオ・音声通話。ミスコミュニケーションの防止と生産性向上に直結する | 第4章 |
| 気軽に聞ける空気と気軽に断れる空気 | 質問しやすい文化を成立させるためにセットで必要な2つの心理的安全性 | 第4章 |
| Agree to disagree | 意見の正誤を決めるのではなく、相違を認め合い相手を理解する姿勢 | 第4章 |
| 図13「ディスカッションのコツ」 | 間違えたら恥ずかしいと思わない/初心者こそ遠慮なく参加する/相手を理解して尊重する/切り出しは「自分の意見では〜」/感謝を忘れない/楽しんだもの勝ち、の6項目 | 第4章 |
## チーム・組織
| 用語 | 定義 | 参照章 |
|---|---|---|
| サーバントリーダーシップ | リーダーがビジョンとKPIを示し、実行方法はチームが主体的に意思決定するマネジメントスタイル。ロバート・K・グリーンリーフの1970年のエッセイ『The Servant as Leader』が起源 | 第5章(前半) |
| コマンドアンドコントロール | マネージャが部下に指示を出し、部下がそれに従う従来型のマネジメントスタイル | 第5章(前半) |
| 自己組織チーム/フィーチャーチーム | 10人以下で構成され、自ら考えて意思決定しながら開発を進める小規模チーム | 第5章(前半)・第5章(後半) |
| ステークホルダー | 大人として扱われ、探求し疑問視することを期待される、サーバントリーダーシップ制における組織メンバーの位置づけ(「社員」との対比概念) | 第5章(前半) |
| IC(Individual Contributor) | 管理職ではない専門職としてのキャリアパス。個人商店のように担当領域の設計・実装に責任を持つ開発者。マネージャーより給料が高いプログラマも多い | 第5章(前半)・第5章(後半) |
| BusinessConduct | マイクロソフト社員に義務づけられている行動規範教育コース。規則を最小限にしつつ、必要な統制だけを担保する仕組みの一例 | 第5章(前半) |
| アンブロック(unblock) | マネージャーの主要な役割の一つ。開発者(IC)が業務上詰まっている障害物を取り除くこと | 第5章(後半) |
| プル型/お願いモード | 上司が部下に細かく指示する「押し付け型」ではなく、困ったら本人が自分から助けを求め(プル型)、依頼するときは丁寧に頼む(お願いモード)フラットな職場文化のあり方 | 第5章(後半) |
| two pizza team | ピザ2枚を分けられる程度の人数(10人前後)でチームを構成する考え方(Amazon由来)。マイクロソフトの自己組織チームでもこの規模が基準とされる | 第5章(後半) |
| Demo or Die | 新機能デモで失敗しても「問題ないよ」「よくあることだよ」と励まされる、マイクロソフトの失敗許容の文化 | 第5章(後半) |
| Ask For Help | 質問しやすい空気を促す文化。「気軽に質問してみよう!」というメッセージを繰り返し伝える一方、アドバイスは求められたときだけ行い決定は本人にさせる | 第5章(後半) |
| 図17「自己組織チーム導入にあたってのコツ」 | 自己組織チーム導入を組織の層ごとに攻める三層構造。トップ層には定量的効果を示して承諾を得る、ミドル層(最も抵抗が強い)には管理負担軽減のメリットを伝える、チームメンバー層には指示待ち脱却をファシリテーター役が促す | 第5章(後半) |
## 生活習慣
| 用語 | 定義 | 参照章 |
|---|---|---|
| タイムボックス制 | 特定のタスクや活動に対して開始・終了時刻を厳格に区切って割り当てる時間管理手法。著者は学習の時間を朝の就業前に固定配分することで生産性向上を実現した | 第6章 |
| 完了(タスクを完了させる) | 一つひとつの行為(着替え、片付けなど)を最後まで終わらせて「完了」の状態にすること。頭の中を整理しコントロール感覚を取り戻すための鍵となる概念 | 第6章 |
| HIIT(High Intensity Interval Training) | 高強度インターバルトレーニング。短時間の全力運動と休息を繰り返すトレーニング法。一日10分程度でも効果があるとされる | 第6章 |
| テストステロン | 男性ホルモンの一種で、集中力・気力・筋力の維持に関わるとされる。運動・食事・サプリメントなどで意識的に増やすことが推奨される | 第6章 |
| 超整理術 | 「必要なものをいかに簡単に取り出せるか」を整理の本質とする整理法の考え方 | 第6章 |
| データドリブン(タイムボックス制の運用) | 何にどれだけ時間を使ったかを記録・分析し、実働時間の配分を可視化しながらタイムボックス制を改善していく手法 | 第6章 |
| マインドフルネス | 瞑想を通じて「今この瞬間」に意識を向ける実践。脳の酷使をやめる工夫の一つとして紹介される | 第6章 |
## AI時代・キャリア
| 用語 | 定義 | 参照章 |
|---|---|---|
| アライン(align) | 自分の専門性や積み上げてきたスキルを、AIなど新しい技術の流れと「方向性を合わせる」こと。AI時代のキャリア戦略として本章で提示される中心概念 | 第7章 |
| コントリビュート(contribute) | 批判ではなく、建設的な貢献という形で他者やコミュニティに関わる姿勢・文化。GitHubなどのオープンソース文化に象徴される | 第7章 |
| 批判文化 | 完璧でないものを許さず、挑戦した人を頭ごなしに叩く日本特有の風潮として本章で批判的に扱われる概念。COCOAアプリなどの炎上事例が象徴とされる | 第7章 |
| Sler(エスアイヤー)の下請け構造 | プログラミングを低レベルの仕事とみなして外注する日本のIT産業の構造。大手SIerの技術力低迷の根本原因として指摘される | 第7章 |
| 専門性 | AI時代において最も強みとなるとされる資質。特定分野を長年追求してきた深い知見・スキルのこと | 第7章 |
| やめること(荷下ろし) | 管理・持ち帰り・情報の詰め込みすぎ・マルチタスク・批判といった負担を一つひとつ手放していくことで、心身が楽になり生産性が向上するという、本書全体を通じて繰り返し強調される考え方 | あとがき |