SE が押さえておくべきロジカルシンキングの基本

なぜ SE にロジカルシンキングが必要か

「バグの原因がわからない」「要件が曖昧なまま実装してしまった」「なぜか会議でうまく説明できない」——こうした悩みの多くは、思考の構造化ができていないことに起因します。

ロジカルシンキングは、情報を整理し、根拠のある結論を導く思考の枠組みです。コードを書く前の問題分析から、設計レビューの場まで、あらゆる場面で役立ちます。

MECE（ミーシー）

MECE（Mutually Exclusive, Collectively Exhaustive）は「漏れなく、重複なく」整理する考え方です。

悪い例：バグ調査の観点

• フロントエンドのバグ
• バックエンドのバグ
• データベースのバグ
• ネットワークのバグ

上記は一見 MECE に見えますが、「ミドルウェアのバグ」「設定ファイルの誤り」が漏れています。

良い例：問題の発生箇所を層で分ける

1. プレゼンテーション層（UI）
2. アプリケーション層（ビジネスロジック）
3. データアクセス層（DB アクセス）
4. インフラ層（OS・ネットワーク・ハードウェア）

OSI 参照モデルや TCP/IP の層構造のように、すでに確立された分類軸を借りるのが MECE を素早く実現するコツです。

ピラミッド原則

説明や提案を行う際は、結論を先に述べ、理由・根拠を後から補う構造（ピラミッド構造）が伝わりやすい。

        【結論】
       /        \
   【理由 A】  【理由 B】
   /     \     /     \
[根拠] [根拠] [根拠] [根拠]

設計レビューでの応用

NG：「まず現状の問題点を説明します。Aがあって、Bがあって、Cがあって…だから今回こういう設計にしました」

OK：「今回はキャッシュ層を追加します。理由は 3 つです。①レイテンシ削減、②DB 負荷軽減、③スケーラビリティ確保。根拠は計測データと過去の事例から…」

仮説思考

仮説思考は「答えを先に仮定し、検証しながら絞り込む」アプローチです。

調査なし（非効率）：ログを上から全部読む → 原因を探す

仮説思考（効率的）：

1. 「直近でリリースした機能が原因では？」と仮説を立てる
2. リリース直後のタイムスタンプを確認する
3. 仮説が外れたら次の仮説へ移る

SE の現場では「全部調べてから考える」より「仮説 → 検証 → 次の仮説」のループが圧倒的に速い。

まとめ

3 つを使いこなすだけで、会議での発言・バグ調査・設計提案の質が大きく変わります。