Post
JA EN

『シンプルに作る』が一番速い——熟練エンジニアの『毎回確認』が仕事を遅くする科学

Posted
By
38 min read
『シンプルに作る』が一番速い——熟練エンジニアの『毎回確認』が仕事を遅くする科学
  • 想定読者： 中堅〜上級のITエンジニア、テックリード、アーキテクト
  • 前提知識： Web/DBアプリ開発の基礎経験
  • 所要時間： 約14分

概要

「N+1が起きていないか？」「インデックスは足りているか？」「このループは本当に問題ないか？」——ミクロな最適化スキルを身につけたエンジニアほど、コードを書くたびに、こうした確認衝動に駆られる。そして大抵、答えは「今のところ問題ない」だ。

問題ないことを毎回確認する作業に、本来やりたかった仕事の時間が静かに溶けていく。Gloria Markらの古典研究は、1回の中断から元の作業に戻るまで平均23分15秒かかると示した1。週に数回の「ちょっとEXPLAINで確認」が、チーム全体で1人月分のキャパシティを毎月消す。

本記事の主張はシンプルだ。事前に少し手間をかけて『シンプルに作っておく』ことが、結果的に最速で最も楽な戦略である。具体例を1つ挙げよう。「公開ページのリスト表示では関連データを最初から JOIN / eager loading で取る」——たったこれだけを設計の標準にしておけば、N+1かどうかを毎回確認する必要が消える。N+1の実害は800件で10倍速の差2、5,000件規模で47秒障害と$18,347の損失3という形で十分に定量化されている。毎回ベンチマークで証明するより、最初からシンプルに書いてしまうほうが、書く側の労力も後工程の事故率も同時に下がる。

なぜシンプルに作るほうが速いのか。Googleが2018年に公表した報告は、その構造を端的に示している。同社が静的解析ツール FindBugs を導入し、検出されたバグをトラッカーに自動投入した時、警告の約84%は開発者によって修正されなかった4。同じ検査ロジックを後継ツール Tricorder でコードレビューのフロー内に統合した瞬間、開発者は自発的に毎日数千件を修正するようになった。差は「警告の質」ではない。仕事のフローの内側にあるか外側にあるか——それだけだ。

「シンプルに作る」は、この洞察を設計レベルで実装することに他ならない。複雑な設計は「あとで気をつけて確認する」を前提とする。シンプルな設計は そもそも気をつける必要がない 状態を作る。本記事ではこのメカニズムを、認知負荷研究、N+1の実害データ、Sadowskiらの発見、DORAの業界データを土台に解剖し、「シンプルさが速さに直結する」構造を明らかにする。

💡 戦略レベルの意思決定における Simple Rules 理論（Eisenhardt/Sull, HBR 2001）の応用は Lean Startup・Simple Rules・AIの三層ハイブリッドプレイブック で別途扱った。本記事は コード品質判断という日々のミクロループ に焦点を絞る。

1. 熟練エンジニアが陥る「証明地獄」

ある程度経験のあるエンジニアは、コードを目にした瞬間、潜在的な性能問題を反射的にスキャンする。「ここでクエリが回るな」「N+1のリスクがある」——これは熟練の証であり、本来は望ましいスキルだ。

問題は、このスキルが「毎回証明モード」に入ったときに起きる。

  • ループ内クエリを見つける → EXPLAINを叩く → 件数が少ないと確認 → 「今は問題ない」と返答する
  • 別の機能でも似た構造を見つける → 再びEXPLAIN → 「今は問題ない」
  • レビューでも同じパターンを発見 → コメント付ける → 議論が始まる → 「今は許容範囲」で着地

一回ごとの確認は数分でも、これが日々積み重なる。さらに厄介なのは、この確認作業が 「やった感」を強く生む 点だ。EXPLAINを叩き、数字を見て、判断を返す——技術的な達成感がある。だが プロダクトの前進にはほぼ寄与していない。

そして「今は問題ない」という判定の前提は、現時点のデータと現時点のアクセスパターンだ。プロダクトはほぼ確実に、データが増え、アクセスが増え、表示件数が増える。N+1は線形に悪化する典型例で、PlanetScaleが公開したベンチマークでは800件のデータに対するN+1クエリは18クエリで1秒超、JOINに置き換えた1クエリでは約0.16秒（およそ10倍の差）で完了している。「数千、数百万レコードになれば、その差はタイムアウトとロード時間の差になる」と同社は警告する2。

実際、Dev Geniusに投稿された障害ポストモーテムでは、4,981ユーザーが同時にあるエンドポイントを叩いた瞬間、N+1クエリが4,982本発火し、APIレスポンスは通常180msから 47秒 に膨張、47分のダウンタイムと約$18,347の売上損失、847件のサポートチケットが発生した。修正は1行——select_related('preferences') を追加するだけだった3。

ここで起きていることは構造的だ。ミクロ確認の判定は「今のデータでは大丈夫」だが、線形に悪化する性能問題は データが閾値を越えた瞬間に災害になる。一回ごとに「今は問題ない」と判定する戦略は、閾値を越える瞬間を予測できない以上、いずれ必ず外す。確認に時間を払い、それでも事故も起きる——これが「毎回確認戦略」の典型的な末路である。

2. ミクロ確認1回のコストは23分15秒

カリフォルニア大学アーバイン校のGloria Markらが2008年に発表した調査は、知識労働者の中断と復帰に関する古典的な研究だ。マネージャー・金融アナリスト・ソフトウェア開発者・エンジニア・PM計36名を3日間観察し、すべての作業を秒単位で記録した結果、以下が判明した1。

  • 1つの作業に集中している平均時間: 3分5秒
  • 中断から元の作業に戻るまでの平均時間: 23分15秒
  • 中断後、人々は元の作業に戻る前に 平均2つの別タスク をこなす
  • 内的中断（自分で別作業に切り替える）は外的中断（同僚から声がかかる）と同じ頻度

「ちょっとEXPLAINかけてみるか」「念のためベンチマーク叩いておくか」は、まさに 自発的な内的中断 の典型だ。EXPLAIN自体は5〜10分で終わるかもしれないが、復帰までを含めた真のコストは 23分 単位になる。

5人チームで各人が週5回のミクロ確認を発動すれば、週125回の中断。1回あたり追加で15分以上の文脈再構築コストが乗ると考えれば、チーム全体で週30時間以上が「確認とその回復」に消える。これは1人月以上のキャパシティだ（あくまで概算であり、Markの23分15秒はすべての中断の平均値で、ミクロ確認1回が必ずこのコストを伴うわけではない。だが頻度の高いタスクスイッチほど復帰コストが累積するという方向性は、後続研究でも一貫して確認されている）。

Markの後続研究では、頻繁に中断されるほどストレス・フラストレーション・時間圧迫感が増し、作業速度自体は逆に上がる（人は中断を予期して急ぐ）が、エラー率も上がる ことが示されている5。中断は速度と精度の両面で代償を要求する。

参考までに、DORAの2024年State of DevOpsレポートでは業界全体のソフトウェア配信パフォーマンスが2023年から2024年にかけて悪化しており、高パフォーマンス層が31%→22%に縮小、低パフォーマンス層が17%→25%に拡大している6。チーム生産性の議論は、いまや個人の熟練度勝負だけでは支えきれない局面に入っている。

3. シンプル設計＝事前に難所を一度で済ませる

ここまでの議論を一行でまとめれば、「ミクロ確認を毎回回すより、最初からシンプルに作っておくほうが速い」となる。これは精神論ではなく、構造的な命題だ。

flowchart TB
    A[コードを書く瞬間] --> B{設計が<br>シンプル?}
    B -->|複雑| C[毎回判断モード]
    C --> D[EXPLAIN/<br>ベンチマーク/<br>議論]
    D --> E[判定: 今は問題ない]
    E --> F[23分の中断<br>+ 後で再発]
    B -->|シンプル| G[判断不要]
    G --> H[迷わず書く<br>後工程も楽]

「シンプルに作る」とは、頻発する判断パターンに対し、事前に1回だけ難所を考え抜いて答えを固めておくことだ。N+1の例で言えば「公開リストでは最初から eager loading」という1つの設計判断を一度入れておけば、その後そのパターンに対する 個別判断は発生しない。

これがGoogleのSadowskiら（2018, Communications of the ACM）が示した教訓と同型である。Tricorder導入以前、FindBugsの警告をバグトラッカーに自動投入する仕組みでは、約84%の警告が修正されないまま放置された4。理由は単純で、開発者の作業フロー（コードを書く → レビューに出す → マージする）の 外側 で警告が出る仕組みでは、関心ループに乗らないからだ。Tricorderチームは検査ロジックを変えず、結果が表示される場所 だけをコードレビュー内に変えた。それで開発者は自発的に毎日数千件を修正するようになった。

「シンプルに作る」も同じ非対称性を利用している。複雑な設計は 「あとで気をつけて毎回判断する」を要求する が、人間は判断ループの外にある検査をほぼ無視する。シンプルな設計は そもそも判断不要の状態を作る。前者は84%失敗の構造、後者はTricorder型の自然な遵守を生む構造だ。

💡 ここで言う「シンプル」は、手抜き ではなく 事前の難所整理 を意味する。select_related を1行書く設計判断は、書く側の労力としても5秒で終わる。一方、ループ内クエリを書いたあと「今は問題ないが将来どうか」を毎回議論するのは5分でも30分でも溶ける。書く側の労力は前者のほうが小さい。シンプルさは設計の事前投資から来る、楽さの結果である。

4. 「シンプルに作る」を実装するための4つの問い

具体的なルールリストを並べることはあえてしない。チームの技術スタック・規模・事業フェーズによって、答えは変わる。代わりに、自チームで「シンプル設計の標準」を決めるときに使える 4つの問い を提示する。

問い1：過去6ヶ月、同じパターンで何度ミクロ確認したか？

レビューやSlackで「これってN+1じゃない？」「このログ大丈夫？」「このマイグレーション安全？」が繰り返し発生している領域は、シンプル化候補の一級品だ。再発頻度が高い話題は、毎回判断するよりも「最初からこう書く」と決めておく価値がある。

具体的に過去のPRやIssueから「同じ話題が何度も出ている」パターンを掘り出す：

1
2

gh pr list --state merged --search "N+1" --limit 50
gh issue list --search "N+1 in:comments" --limit 50

問い2：許した時の最悪コストが、定量的に語れるか？

シンプル化の労力は無料ではない。投資判断のフィルタは1つだけ：

そのパターンを許した時の最悪コストが、具体的な数字で語れるか？

N+1：47秒のダウンタイム、$18,347の損失（語れる）。境界の型なし：API側変更で内部全域が一斉に瓦解（語れる）。タブかスペースか：定量的コストが語れない（フォーマッターに任せる）。シンプル化の投資は、コストが語れる領域に集中するのが鉄則だ。

問い3：判断を仕組みに押し付けられるか？

シンプル設計を「みんな気をつけよう」で運用するのは、Sadowskiの84%失敗パターンの再生産だ。機械的に検出され、フローの内側で気づける 仕組みを必ずセットにする：

仕組み層例検出タイミング
エディタ層linter, type checker入力中
プリコミット層pre-commit hookcommit直前
CI層テスト失敗、クエリ数カウンタpush後
レビュー層PRテンプレートPR時

検出が早い層ほど修正コストが低い。理想はエディタ〜プリコミット層、レビュー層は最後のセーフティネット。

問い4：例外条件を明文化したか？

シンプル設計は 法律ではなく、安定したデフォルト だ。Tricorderが「Not useful 評価が10%超えた解析器は probation（保護観察）対象とし、改善されなければ無効化する」というメタルールを持つように4、シンプル化の標準にも 「いつ破ってよいか」「いつ見直すか」 を組み込む。

「公開リストではN+1禁止。ただし管理画面で表示件数が固定100件以下、かつデータ件数の最大値が定義されている場合は例外」のように、例外条件が明文化されていれば、例外申請の議論も「条件を満たすか」で判定が終わる。状況次第で柔軟に運用しつつ、毎回ゼロから判断する状態には戻らない——これがバランス点だ。

四半期に一度、棚卸しもする。技術スタックや事業フェーズが変われば、不要になる標準も出てくる。Codacyの調査が示す通り、開発者の 58%が「コードレビューで最大の課題は時間が足りないこと」 と回答している7。レビュー負荷を上げるだけの形骸化したルールは、本来の目的（仕事を楽に速くする）と逆行している。

5. よくある反論と応答

「シンプルに済ませる＝手抜き」

逆である。シンプルに作られたコードは、初動が速く、後工程の修正コストも低く、事故率も下がる。「考えに考えてミクロ最適化を施したコード」のほうが、得てしてメンテ困難で再発リスクを抱えている。シンプルさは事前投資の結果であって、手抜きの結果ではない。

「上級者ほどミクロで細かく調整するもの」

熟練者の真の特徴は「細部を見るが、見るべき場所を選別している」ことにある。「ミクロを毎回見ている熟練者」は、実際には注意リソースを浪費している。シンプル設計は「ここは選別済みなので見なくていい」を明示する装置で、熟練者の注意を 本当に判断が必要な場所 に集中させる。Sadowskiの84%の発見は、Googleの一流エンジニアでも、判断ループの外に置かれた検査は処理しきれないという現実を示している。

「ケースバイケースで判断したい」

ケースバイケース判断は 判断者にスキルがあるとき には正しい。ただしそのコストは「毎回判断する時間 + 平均23分の中断回復」だ1。再発頻度が高いパターンに対してケースバイケースを続けるのは、毎日同じ問題を新規問題として解いている ことに等しい。判断スキルは保ったまま、頻発パターンだけを「考えなくていい状態」に押し出す——これがシンプル設計の本義であり、判断力の放棄ではない。

「ルールを増やすほどルール疲れが起きる」

正しい指摘だ。だからこそ本記事は 「実害が定量化できる領域に絞る」 ことと 「例外条件と棚卸しを組み込む」 ことを強調している。シンプル化の標準は 増やすだけでなく減らす 対象でもある。ルールの累積による別の問題については、姉妹記事 なぜルールは増え続けるのか を参照してほしい。

まとめ

  • 熟練エンジニアほど「毎回確認」の衝動に縛られる が、Markの研究によれば1回の中断は平均23分15秒の復帰コストを伴う1。チーム全体で1人月以上のキャパシティが毎月「確認と回復」に溶ける。
  • N+1のように線形悪化する問題は、現時点のミクロ確認では将来の事故を予測できない23。「今は問題ない」を100回出しても、閾値を越える瞬間が必ず来る。
  • Sadowskiらの2018年研究は、コードレビュー外で報告された警告の84%が放置されると示した4。判断ループの内側にあるかどうかが、検査が機能するかを決める。
  • 「シンプルに作る」は手抜きではなく、事前に難所を1回考え抜いて答えを固めておく設計戦略 である。複雑な設計は「毎回判断する」を要求するが、シンプルな設計は判断そのものを不要にする。
  • 自チームでシンプル設計の標準を決める4つの問い: (1) 何度繰り返し確認したか、(2) 最悪コストを定量化できるか、(3) 仕組みで検出できるか、(4) 例外条件と棚卸しを明文化したか。
  • シンプル設計は法律ではなく安定したデフォルト。状況次第で更新するメカニズムを最初から組み込む。これがTricorderから学ぶべき設計思想でもある。

「シンプルに楽して仕事が速くなる」は、根性論でも気持ちの問題でもない。シンプルに作る = 事前投資で後の判断コストを大幅に下げる、という単純な構造的取引だ。次のレビューで「これN+1じゃない？」と書きたくなったら、その瞬間が、自チームでシンプル設計の標準を1つ追加する好機である。

関連記事

このテーマに関連する他の記事もご覧ください：

参考資料

本文中の引用番号に対応する参考資料を番号順に記載しています。

  1. The Cost of Interrupted Work: More Speed and Stress - Mark, G., Gudith, D., & Klocke, U., CHI 2008 Proceedings. マネージャー・金融アナリスト・ソフトウェア開発者・エンジニア・PM計36名を3日間観察し、平均作業継続時間3分5秒、中断からの復帰平均23分15秒、内的中断と外的中断はほぼ同頻度という結果を報告。【信頼性: 高】（CHI査読論文、エスノグラフィック実観察） ↩︎ ↩︎2 ↩︎3 ↩︎4

  2. What is the N+1 Query Problem and How to Solve it? - JD Lien, PlanetScale Blog (2023年1月18日). 800件データで18クエリが1秒超に対しJOIN1クエリ約0.16秒（およそ10倍）の再現可能なベンチマーク。データ量増大で線形悪化することへの警告含む。【信頼性: 中〜高】 ↩︎ ↩︎2 ↩︎3

  3. Our API Went From 200ms to 47 Seconds (The N+1 Query Horror Story) - The Unwritten Algorithm, Dev Genius (2026年3月22日). 4,981ユーザーで4,982クエリ発火、APIが180ms→47秒に膨張、47分のダウンタイムと$18,347損失。修正は select_related('preferences') 1行。実プロダクションのインシデントレポート。【信頼性: 中】 ↩︎ ↩︎2 ↩︎3

  4. Lessons from Building Static Analysis Tools at Google - Sadowski, C., Aftandilian, E., Eagle, A., Miller-Cushon, L., & Jaspan, C., Communications of the ACM, 61(4), 2018. FindBugs旧運用で約84%のバグが未修正のまま放置されたが、Tricorderでコードレビュー内に統合した結果、開発者が自発的に毎日数千件を修正するようになったとの報告。誤検知率は10%上限、「Not useful」評価が10%超の解析器は probation（保護観察）対象となり改善されなければ無効化されるメタルール。【信頼性: 高】（CACM査読論文、Google社内大規模実運用データ） ↩︎ ↩︎2 ↩︎3 ↩︎4

  5. Gloria Mark research project page - Gloria Markの研究プロジェクトページ。中断頻度とストレス・エラー率の関連について複数の追加研究を掲載。【信頼性: 中〜高】（研究者公式ページ、複数の査読論文への一次リンク） ↩︎

  6. 2024 Accelerate State of DevOps Report - DORA / Google Cloud (2024). EliteパフォーマーはLowに対しデプロイ頻度182倍、リードタイム127倍、復旧時間2,293倍。Eliteは全体の19%、Highは22%（前年31%から減少）、Lowは25%（前年17%から拡大）。業界全体としては2023→2024でパフォーマンスが悪化。【信頼性: 高】（年次大規模調査） ↩︎

  7. Coding Standards: What Are They and Why Are They Important? - Codacy Blog (2026年3月4日更新). Codacy 2024 State of Software Quality 報告（開発者の58%がレビュー時間不足を最大課題に挙げる）など複数調査を引用。【信頼性: 中〜高】 ↩︎

ソフトウェア開発
開発生産性 シンプル設計 認知負荷 N+1 アーキテクチャ
This post is licensed under CC BY 4.0 by the author.