slim-down

スリム化 — スコープを絞り、拡張性を保つ

大きくなりすぎた計画や設計を、価値をもたらし、将来の拡張を妨げない1つの小さな段階まで絞り込みます。

まず動くものを作り、そのあとで磨き上げましょう。ただし、後戻りできない設計にはしないでください。

使う場面

• 計画や設計が過剰に複雑に感じられるとき
• ユーザーが「これは大がかりすぎる」「まず何が必要？」「MVP」と言ったとき
• スコープが膨らみ、次に作るものとして現実的な範囲を超えているとき

基本原則

**手を抜かずに、スコープを絞ります。**品質ではなく、機能を減らします。小さくても拡張可能な段階にし、行き止まりや「あとで捨てる」設計を避けます。

ワークフロー

ステップ 1：現状を把握する

何かを削る前に、すでにあるものを理解します。

• 現在のコードベースを読む — 何が作られていて、どんなパターンが使われているか
• スリム化する計画／検討結果／仕様を読む
• 新たに必要な作業と、すでに完了している作業、または一部完了している作業を特定する

次の内容を短くまとめます。

• 現状 — 今あるもの（2〜3行）
• 最終目標 — 計画で実現しようとしていること
• 不足分 — 現状と最終目標の間で欠けているもの

ステップ 2：核心を特定する

次の問いを考えます。「この計画が役に立つために、必ず実現すべきことは何か？」

核心となる価値を1文で表します。ユーザーに提示してください。これが基準となり、ほかのすべてをこれに照らして判断します。

ステップ 3：維持／延期／除外に分類する

計画に含まれるすべての項目を分類します。

	基準
維持	核心を機能させるために必要です。これなしではリリースできません。
延期	価値はありますが、今は必要ありません。後から追加できるように設計します。
除外	あれば便利なだけのもの、推測に基づくもの、まだ存在しない問題を解決するものです。

表を提示します。ユーザーが項目を移動できるようにしてください。

分類のルール：

• 10倍の規模になって初めて必要になるもの → 延期
• まだ発生していない例外的な状況に対応するもの → 延期
• なくしても核心が損なわれないもの → 延期
• 「柔軟性のため」に新しい抽象化レイヤーを追加するもの → 必要性が証明されていない限り除外
• 現在のコードですでに部分的に対応しているもの → 維持（作り直さず、完成させる）

ステップ 4：拡張性を確認する

延期する項目ごとに、次の点を確認します。

• 維持する項目によって、後から追加できなくならないか？
• 今回の段階が、作り直しを強いる行き止まりにならないか？

該当する場合は、その項目を維持に戻すか、設計を調整します。

ユーザーが「拡張できる？」と尋ねたら、仮定ではなくコードに基づいて正直に答えます。

ステップ 5：今回の段階を定義する

何を作るか、短い定義を一緒に作成します。

• 目標 — 1文
• 実現すること — 維持する項目の箇条書き
• 延期すること — 忘れないよう、延期する項目の箇条書き
• 対象外 — 除外する内容とその理由
• 完了条件 — 完了をどう確認するか

ユーザーが希望する場合は、ファイルに書き込みます。それ以外の場合は、認識が一致していることを確認します。

削るときに大切なこと

• **既存コードを尊重します。**すでに動いているものの置き換えは提案せず、それを基盤にします。
• **除外より延期を優先します。**除外は取り消せないように感じられますが、延期なら選択肢を残し、ユーザーも安心できます。
• **実現への道筋を示します。**何かを延期するときは、現在の設計で後から追加できることを簡潔に説明します。
• 具体的にします。「認証を延期する」では曖昧です。「OAuth は延期し、当面は API キーを使う。認証ミドルウェアのインターフェースは変えない」なら実行に移せます。

してはいけないこと

• スリム化の最中に新しい機能を追加しない
• アーキテクチャを再設計しない — 既存のものを活用する
• 具体的な定義を示さずに「とにかく MVP にしましょう」と言わない
• ユーザーがすでに作ったものを削らない — それはスコープの節約ではなく、作業の無駄です
• ユーザーが最も安い選択肢を望んでいると決めつけない — ユーザーが求めているのは、最小の有用なものです