世界一流のエンジニアは、どう考えるか
一流とは、難しい技術をたくさん知る人ではありません。不確実な問題を分解し、事実を確かめ、失敗を小さくし、チームが安全に前進できる判断を積み重ねる人です。
Minibank全体の地図、システム開発の基本、学び方の土台を作る。
先に学ぶ内容 — Prerequisite: なし学ぶこと — LEARNING GOALS
このページで学ぶこと
- 複雑な問題を解く思考の順番
- 正解が1つでない時の判断方法
- 失敗を個人責任で終わらせず仕組みに変える方法
体験20 · ENGINEERING MINDSET（一流の思考法）
経験豊富なエンジニアほど、すぐコードを書き始めるか確かめよう
まずは予想をひと言。本文を読んだ後、教材内の参照元で実際のバグ修正例を確認します。
- 01まず予想する — PREDICT
まずここだけ：思ったことをひと言書く
経験豊富なエンジニアほど、実装を始める前に多くのコードを書き始めるでしょうか？
正解でなくて大丈夫です。「〜だと思う」から始めてみましょう。
ヒント1を見る
正常に動く例を1つ確かめることと、「壊れる例」を探すことは、同じくらい重要でしょうか？
ヒント2を見る
障害が起きたとき、最後に操作した人だけを原因にしてよいでしょうか？
もっと詳しく：この問いで使う専門用語
- 不変条件は、どの経路でも絶対に壊してはいけない約束です。
- 反例は、説明や設計が正しくないと証明する1つの例です。
- Feedback loopは、結果を測り学びを次の設計へ戻す循環です。
日常語で理解する — PLAIN LANGUAGE
まず、ここだけつかむ
優れたengineerは、すぐ答える前に『誰の何の問題か』『絶対に守る条件は何か』を明確にします。
事実・仮説・未確認事項を分け、正常例だけでなく、主張を壊す反例、同時実行、失敗、再送を考えます。
失敗を隠さず、小さな変更・review・test・監視・振り返りで個人の経験をteamの仕組みへ変えます。
順番に理解する — DIFFICULT PARTS, STEP BY STEP
難しいポイントを、順番にほどく
専門用語を覚えることより、「なぜ必要か」「このシステムのどこで使うか」を理解することが目標です。
不変条件
どの経路でも絶対に壊してはいけない約束です。
画面や実装方法が変わっても、安全性の中心を保てます。
借貸一致、posted Ledgerの追記専用、同じ依頼で資金移動1回などです。
反例
説明や設計が正しくないと証明する1つの例です。
成功例を増やすより、隠れた前提を早く見つけられます。
同じ残高を2requestが同時利用するscenarioを試します。
Trade-off
選択の良い点と、代わりに失うものを両方示します。
唯一の正解がない設計で、判断理由と前提を共有できます。
lockは整合性を守る一方、待ち時間・deadlock・throughputへ影響します。
Blast radius
失敗した時に影響する利用者・金額・時間の範囲です。
障害を完全に防げなくても、被害を局所化できます。
小さなcommit、権限分離、取引上限、段階releaseの候補として考えます。
Feedback loop
結果を測り、学びを次の設計へ戻す循環です。
最初の設計だけで未来の全条件を予測できないからです。
回帰test、照合、audit、incidentからconstraint・test・Docsを改善します。
発展 — ADVANCEDもっと詳しく確認する最初の学習では読まなくても問題ありません。仕組みをもっと深く理解したい場合に開いてください。
最初に：『すごい人の勘』をまねしない
世界中の優れたengineering組織に完全に同じ方法はありません。共通するのは、権威や好みより利用者・制約・観測事実を重視し、仮説を小さく検証し、判断理由を他者が追える形にする姿勢です。
経験者の直感も、過去の大量の失敗とfeedbackから作られた圧縮された仮説です。大切なのは結論だけをコピーせず、『何を守るための判断か』『前提が変わったら結論も変わるか』を聞くことです。
問題を解く8つの問い
- 01誰が、何に困っているのか
- 02成功を何で測るのか
- 03絶対に壊してはいけない不変条件は何か
- 04システムの境界と責任者はどこか
- 05事実・仮説・未確認事項を分けたか
- 06正常時だけでなく、失敗・再送・同時実行ではどうなるか
- 07最小で安全な検証は何か
- 08導入後に観測し、戻し、学べるか
思考の道具箱
| 考え方 | やさしい意味 | Minibankの例 |
|---|---|---|
| First principles | 前例をコピーせず、守る事実と制約まで戻る | 送金では『片側だけ確定しない』からtransaction境界を考える |
| Systems thinking | 部品単体でなく、つながりと遅れて出る影響を見る | UI変更がAPI、DB権限、監査、運用へ与える影響を追う |
| Invariant | どの経路・順番でも絶対に破れない条件を決める | 借方合計=貸方合計、同じ依頼で資金移動は1回 |
| Counterexample | 正しい例より、主張を壊す1例を探す | 2つの送金を同時実行して残高不足制御を試す |
| Trade-off | 利点だけでなく、失うものと運用費も並べる | 強いlockは整合性を守るが待ち時間とdeadlock riskを増やす |
| Reversibility | 判断を戻せるかで、検証方法と承認を変える | UI文言は戻しやすいが、Ledger migrationは戻しにくい |
| Blast radius | 失敗した時に影響する人・金額・時間を小さくする | 段階release、上限、feature flag、権限分離を使う |
| Feedback loop | 結果を測り、次の判断へ戻す | test、監視、照合、incident reviewを設計へ戻す |
速さは、タイピング速度ではない
大きな変更を一度に作ると、reviewが難しく、失敗原因もrollback範囲も大きくなります。小さく独立した変更は、早くfeedbackを得て全体の手戻りを減らします。
ただし金融不変条件を途中版で壊してよいわけではありません。小さな変更それぞれが安全にdeploy可能で、test・監視・文書を含むことが前提です。
- 設計の核心と最大riskを先にreviewする
- 証拠が取れる最小実験を作る
- 未知を隠さず、仮定と期限を記録する
- 同じ事故を注意力ではなく制約・test・自動化で防ぐ
- 自分しか分からない仕組みを成功と呼ばない
障害時ほど、思考の品質が出る
| 順番 | 行うこと | 避けること |
|---|---|---|
| 1 止血 | 影響範囲を測り、拡大を止める | 原因不明のまま大きな変更を重ねる |
| 2 事実 | 時刻、変更、log、metric、取引状態を保存 | 推測を事実として共有する |
| 3 復旧 | 安全な手順で重要業務を戻し、整合性を確認 | 画面が開いただけで復旧完了とする |
| 4 原因 | 技術・process・組織の防御がなぜ抜けたか分析 | 最後に操作した個人だけを原因にする |
| 5 学習 | ownerと期限付きで制約・test・alert・runbookへ反映 | 反省会だけで終える |
実際のMinibankでは
引数を変えたexecute_transfer()で旧overloadが残った問題、終了したOTPをWHERE句で消した問題、生DB errorが画面へ漏れた問題は、いずれも『正常時に動く』だけでは見つけにくい例です。signature、状態空間、信頼境界まで広げて考える必要がありました。
Minibankのmigration、回帰test、E2E、Learning Docsは、実装だけでなく判断理由と失敗例を将来へ残すfeedback loopです。ただし一流という称号を証明するものではなく、継続的にcode healthと理解可能性を改善する練習材料です。
体験学習の続き · LEARNING LOOP
ここまで読めましたか？続けて確認してみましょう
一流のエンジニアの思考法を読んだところで、教材内の参照元で実際のバグ修正例を確認し、自分の言葉で説明してみます。
- 02仕組みを確かめる — CONCEPT CHECK
画面操作なしで、仕組みを確かめる
この仕組みは、Mini Bankの画面には現れません。次のEvidenceとCode Trail、教材本文だけで理解を進めます。
- 03証拠を確認する — EVIDENCE
何を見たか、1つずつ確かめる
Evidence（判断の根拠となる記録）を確認したらチェックします。各項目の「何を見るか」を手がかりにしてください。
画面を開けない項目は、Source Trail（教材の参照元）と教材の説明で確認できます。失敗を実際に起こす必要はありません。
- 04コードの処理経路を追う — CODE TRAIL
コードを書く必要はありません
ここでは「説明されている仕組みが、実際のMini Bankのどこに実装されているか」を確認します。まずは日本語の役割説明を読み、入力した依頼がどこへ渡るかをつかみましょう。コードの全文を読む必要はありません。
実際に見つかった2つのバグ修正を順に見て、事実に基づく判断がどう行われたかを確かめましょう。
教材の参照元を確認する — Source Trail ↓function signatureの競合を修正した実例。事実に基づいて原因を特定した経緯を探します。
supabase/migrations/20260823170002_drop_old_execute_transfer_overload.sql状態空間をWHERE句で失っていた問題の修正。反例から設計を見直した経緯を探します。
supabase/migrations/20260823170003_fix_confirm_and_reissue_transfer_otp_bugs.sql - 05自分の言葉で説明する — EXPLAIN
LEVEL 1 — やさしい説明（まずここだけ）
なぜ「正常に動く例」を増やすことよりも、「主張を壊す反例」を探すことが重視されるのでしょうか？ 短い2文を目安に説明してください。
日常語だけで完了できます。専門用語の数や正誤を自動採点するものではありません。
ヒント1を見る
「事実」と「仮説」という2つの言葉を使って書いてみましょう。
ヒント2を見る
実際に見つかったバグの例を1つ挙げてみましょう。
もっと詳しく：LEVEL 2 — 専門用語を使った説明（任意）
不変条件、反例、Trade-off、Feedback loopの4つを使って、一流のエンジニアの判断の積み重ね方を説明してみましょう。
挑戦する場合は、上の説明欄に追記できます。追加しなくても完了できます。
説明の確認ポイント — Checkpoint- 正常系だけでは見つからない問題があると説明できる
- 個人の教訓が仕組みへ変換される例を説明できる
理解を確かめる — CHECK YOUR UNDERSTANDING
4問で理解チェック
答えを頭の中で考えてから、各項目を開いて確認してください。
Q1一流engineerは最初から正解を知っていますか？
そうとは限りません。不確実性を明示し、小さな検証で安全に学ぶ方法を持っています。
Q2正常系testが通れば設計の主張は十分ですか？
不十分です。失敗、同時実行、再送、境界値など、主張を壊す反例を探します。
Q3複雑な実装ほど高度ですか？
違います。必要な複雑性かを問い、利用者価値を保ちながら単純化できる方が変更・review・運用に強くなります。
Q4障害原因は最後に操作した人ですか？
個人の操作だけで終えず、なぜ防御・検知・復旧の仕組みが止められなかったかを分析します。
完全に暗記する必要はありません。大切な考え方を説明できそうなら押してください。
業界・外部の参照元 — INDUSTRY / EXTERNAL SOURCE
業界資料・参考文献
一般論と業界知識の根拠です。外部サイトを新しいタブで開きます。
- Google Engineering Practices — Code Review
設計、機能、複雑性、test、文書を含めてcode healthを改善するreview
- Google Engineering Practices — Small CLs
小さな変更がreview・理解・rollbackを容易にする理由
- Google SRE — Postmortem Culture
非難ではなく再発防止へ学びを変えるincident review
- NIST — Secure Software Development Framework
安全な開発を個人技ではなく組織的practiceとして扱うframework
教材の参照元 — SOURCE TRAIL
根拠と関連教材
CURRENT IMPLEMENTATIONは確認したrepository内の実装です。HISTORICAL IMPLEMENTATIONは導入・修正の履歴で、後続migrationによる再定義があり得ます。RELATED LESSONは教材への案内で、実装の一次Sourceではありません。ASSUMPTIONは仮定、UNKNOWNは未確認を表します。
確認基点: d02eae8914f39cbf06bfe422dc39c71886f82b3e / 2026-09-11。稼働環境への適用確認: UNKNOWN。パス実在の自動検査と、記述した技術的事実の確認は別です。
- 過去の実装 — HISTORICAL IMPLEMENTATION
supabase/migrations/20260823170002_drop_old_execute_transfer_overload.sqlfunction signatureを事実として確認した修正例 - 過去の実装 — HISTORICAL IMPLEMENTATION
supabase/migrations/20260823170003_fix_confirm_and_reissue_transfer_otp_bugs.sql状態空間をWHERE句で失わない修正例 - 過去の実装 — HISTORICAL IMPLEMENTATION
supabase/migrations/20260823170004_sanitize_confirm_transfer_otp_failure_reason.sql内部errorと公開messageの境界 - 現在の実装 — CURRENT IMPLEMENTATION
scripts/regression/仮説を再現可能な検査へ変える仕組み