Imported from CYLIU2003/master-course (.codex/skills/mit-thinking-process/SKILL.md). Install upstream with npx skills add CYLIU2003/master-course --skill mit-thinking-process. Copyright stays with the author.

MIT-Style Thinking Process Skill

"The goal is not to give people fish. The goal is to change the way they think about fishing."
— MIT Media Lab 創設者 Nicholas Negroponte

0. 判断の説明

結論と、それを評価するのに必要な前提・根拠・検証結果を簡潔に伝える。 内部の逐語的な思考や内的ダイアログの開示を求めない。

適用範囲

以下は必要な観点を選ぶための例であり、全工程の実行・回答の固定形式・ユーザーへの質問リストではない。関係する節だけを使い、既に確認済みの根拠を再利用する。

説明例: 「方式Aを選びました。既存の入力形式を保ち、対象の回帰テストも通過しています。
         方式Bは移行が必要なため、今回は採用していません。」

1. 必要な前提の確認

結果を左右する不明点を調べる

既存の依頼・証拠・承認で判断できる場合は進める。調査でも解消できない重要な不明点や未承認の操作だけをユーザーに確認する。明確な依頼を毎回問い直さない。

受け取った依頼: 「このページを速くしてください」

必要な場合に調べる観点:
   - 「速くする」とは何を指すか？（FCP？TTI？LCP？体感？）
   - なぜ速くする必要があるか？（ユーザー離脱？コンバージョン低下？）
   - 測定したのか？本当にパフォーマンスが問題か？
   - 他に根本原因があるのでは？

問い直しの4つの軸:

1. 定義: 用語・目標が曖昧ではないか？
2. 原因: 表面の問題の根本に何があるか？
3. 制約: 実は制約と思っていたものが変えられるのでは？
4. 目的: これを解いて何が達成されるか？

2. コーディング時の思考プロセス

フェーズ1: 問題の完全理解（読解・分解）

[仕様を整理するための例]

「タスク: ユーザーリストをフィルタリングする関数を書く」

↓ まず問う:
  - 入力は何か? (型・サイズ・形式・null可能性)
  - 出力は何か? (型・保証すべき性質)
  - エッジケースは?
    → リストが空の場合
    → 全員がフィルタに引っかかる場合
    → 誰もフィルタに引っかからない場合
    → フィルタ条件が複数ある場合
  - パフォーマンス要件は?
    → 100件か、100万件か
  - 呼び出し頻度は?
    → ホットパスか否か

↓ 次に設計:
  - Pure functionにできるか? → Yes → そうする
  - 副作用は必要か?
  - 命名は自己説明的か?

フェーズ2: コードを書く前のアルゴリズム設計

[選択肢を比較する観点の例: ソートアルゴリズム]

「入力サイズは?」
→ n < 50: insertion sort (cache friendly, low overhead)
→ n < 1000: timsort (Python default, 実用最速)
→ n > 1万: 並列化を検討
→ n > 100万: メモリに乗るか検討、external sort?

「データの特性は?」
→ ほぼソート済み: insertion sort が O(n)
→ ランダム: quicksort が平均最速
→ 安定性が必要: mergesort / timsort
→ メモリ制約あり: heapsort (in-place)

「数値か文字列か?」
→ 数値: 比較コスト低い
→ 文字列: locale-aware sortが必要か?
→ オブジェクト: key関数で何を比較するか明確に

フェーズ3: 実装中の思考

[変更の影響に応じて選ぶチェック]

必要な観点を選び、実装時やレビュー時の確認結果を再利用する:
  □ この関数の責任は1つか?
  □ 名前は意図を語っているか?
  □ 引数が3個超えたら → データクラスを検討
  □ コメントが必要と感じたら → まずリネームを試みる
  □ 同じコードを2回書いたら → DRYにする
  □ if文が3段ネストしたら → 分割 or Early return

エラーハンドリングの思考:
  「ここで何が起きうるか?」
  → ネットワーク切断・タイムアウト → リトライ可能か?
  → 不正な入力 → バリデーションで弾くか、型システムで防ぐか
  → DBが落ちている → Circuit breakerが必要か?

フェーズ4: 書いた後の自己レビュー

[提出前5分の思考]

「もし別の人がこれを明日読んだら理解できるか?」
「6ヶ月後の自分はこれを見て何が起きているか分かるか?」
「最悪のケースで何が起きるか?」
「テストケースは仕様をテストしているか、実装をテストしているか?」
「このコードを消すとしたら、どこから消せるか?」

3. 研究・設計時の思考プロセス

研究アイデアの評価観点

研究アイデアの評価を依頼された場合に使う観点:

1. 「誰が気にするか?」(So what? テスト)
   → 解決されたとして、誰の何が良くなるか?
   → もし答えられなければ、動機が弱い

2. 「既にやられていないか?」
    → 新規性の裏付けが必要な場合に、関連文献を調べる
   → 似た研究があるなら: 差分は何か?
   → 差分がないなら: やらない

3. 「実験で示せるか?」(Falsifiability テスト)
   → 反証できる形の仮説になっているか?
   → 「示せない」なら仮説ではなく信念

4. 「自分にできるか?」(Feasibility テスト)
   → データが取れるか?
   → 計算コストは現実的か?
   → タイムラインに合うか?

5. 「最悪の結果でも価値があるか?」(Null result テスト)
   → 「効果がなかった」という結果でも論文になるか?
   → なるなら進める価値がある

設計時の思考プロセス（システム設計）

[新しいシステムの設計判断を説明する観点]

Step 1: 要件の明確化
  「機能要件と非機能要件を分ける」
  機能: 何ができるべきか
  非機能: どのくらい速く、安全に、スケーラブルに

Step 2: 制約の列挙
  「何が変えられないか?」
  → 既存システムとの互換性
  → チームのスキルセット
  → 予算・タイムライン
  → 法規制・コンプライアンス

Step 3: トレードオフの可視化
  「何かを最大化すると何かが犠牲になる」
  → 一貫性 vs 可用性 (CAP定理)
  → 速度 vs 正確性
  → 柔軟性 vs シンプルさ
  → 今の開発速度 vs 将来の保守コスト

Step 4: 最悪ケースのシミュレーション
  「これが壊れるとしたらどこからか?」
  → SPF (Single Point of Failure) はどこか?
  → 10倍のトラフィックが来たらどうなるか?
  → データが消えたらどう復旧するか?

4. デザイン思考のプロセス

デザインに取り組む時の思考の流れ

[UIデザインの判断を説明する観点]

まず問う:
  「これは誰のためのデザインか?」
  → デザイナー自身のため? → それはアート
  → ユーザーのため? → それがデザイン

  「ユーザーの目標は何か?」
  → 表面の目標: 「ボタンを押す」
  → 本当の目標: 「商品を買う」
  → 潜在的目標: 「後悔しない選択をしたい」

  「このデザインで本当の目標が達成されるか?」

構造を決める時:
  「最も重要な情報は何か?」
  → それを最初に、最大きく見せているか?
  
  「ユーザーの視線はどう動くか?」
  → F字型 or Z字型の視線誘導を意識しているか?
  
  「タップ・クリックのコストは最小か?」
  → Fitts's Lawで計算してみる

Typography・色を決める時:
  「この色に意味はあるか? 感情はあるか?」
  「色覚多様性のユーザーに伝わるか?」
  「コントラスト比はWCAG AA (4.5:1) を満たすか?」

5. 問題解決の普遍的思考フロー

デバッグ・障害対応の思考

[不具合の原因を説明するための観点]

Step 1: 現象の正確な記述
  「何が起きているか?」(主観的解釈を排除)
  ❌ 「なんか遅い」
  ✅ 「p99 latency が通常50msのところ、2023-01-15 14:32以降 2400msになっている」

Step 2: 再現条件の特定
  「いつも起きるか? 条件は?」
  → 特定ユーザーだけか?
  → 特定のデータだけか?
  → 特定の時間帯だけか?
  → 最後の変更は何だったか? (git log)

Step 3: 仮説の生成
   「証拠に合う原因候補を挙げる」
   → 数を満たすための仮説は追加しない
  
Step 4: 最も反証しやすい仮説から検証
  「最短で棄却できる仮説から試す」
  → ログを見る
  → 単純な再現スクリプトを書く
  → バイナリサーチでコミットを特定する

Step 5: 根本原因の特定（5 Whys）
   「なぜ?」を、再発防止に必要な原因が分かるまで確認する
  → 表面の修正ではなく、根本を直す

意思決定の思考フロー

[重要な技術的意思決定をする時]

1. 「この決定は後で変えられるか?」
   → 変えやすい (Type 2): 今すぐ決めて進む
   → 変えにくい (Type 1): 時間をかけて検討する
   （Amazon の Two-way door / One-way door 原則）

2. 「自分のバイアスを特定する」
   → 確証バイアス: 都合の良い証拠だけ見ていないか?
   → 埋没コストバイアス: 「もうここまでやったから」で判断していないか?
   → 近直性バイアス: 最近の事例だけで判断していないか?

3. 「反対意見を先に言語化する」
   → 「この選択に反対する立場の最も強い論拠は何か?」
   → それに答えられなければ、まだ考えが浅い

4. 「判断基準を先に決める」
   → 「どの指標がどの値なら、この選択が正解だったと言えるか?」
   → 事後合理化を防ぐ

6. 説明の例

説明が必要な場合だけ、次の要素から必要なものを選ぶ。短い回答で十分なら見出しは不要。ユーザー指定の形式・順序を優先する。

結論: 採用した判断・提案
根拠: 確認できた事実と主要な選択理由
検証: 実施結果、未検証の範囲、判断に影響する限界

7. 思考を止める4つのサイン（メタ認知）

自分の思考が浅くなっているサインを自覚する:

1. 「とりあえずやってみよう」が出た時
   → 問いへの答えを先に出してから手を動かす

2. 「これで大丈夫なはず」と感じた時
   → 何を根拠に「大丈夫」と言っているか問い直す

3. 反対意見が思い浮かばない時
   → 視野が狭くなっているサイン。Devil's Advocateをやる

4. 「前もこれで上手くいった」が理由になった時
   → 状況の違いを列挙する。過去の成功は今回の保証ではない