【完全攻略】JavaScriptのif-elseで複数条件をスマートに記述する方法とベストプラクティス

JavaScriptを扱う開発者であれば、if-else文がプログラミングの根幹をなす要素であることをご存知でしょう。しかし、複数の条件を扱うようになると、途端にコードが複雑化し、可読性が低下したり、バグの温床になったりすることが少なくありません。

「このif文、もっとスッキリ書けないものか…？」 「条件が増えるたびに、ネストが深くなって読みにくい！」 「保守性の高いコードを書くにはどうすれば？」

もしあなたがこのような悩みを抱えているなら、この記事はまさにあなたのためのものです。

この記事では、JavaScriptにおける複数条件のif-else文の基本から、コードを劇的に改善するための様々なテクニック、そしてプロが実践するベストプラクティスまで、徹底的に掘り下げて解説します。単に「こう書く」という文法だけでなく、「なぜそうするのか」「どんな時に使うべきか」という本質的な思考まで、5000字を超えるボリュームで網羅。

この記事を読み終える頃には、あなたは複雑な条件分岐も恐れることなく、より堅牢で、より読みやすく、より保守性の高いJavaScriptコードを書くための強力な武器を手に入れていることでしょう。

さあ、あなたのJavaScriptコードを次のレベルへと引き上げる旅を始めましょう！

目次

1. JavaScript if-else文の基本をおさらい
   • 最も基本的なif文
   • if-else文
   • if-else if-else文
   • 複数条件の基本的な書き方 (&&, ||)
2. 複数条件を扱う際の共通の課題とアンチパターン
   • ネストが深くなる問題（通称：ピラミッド・オブ・ドゥーム）
   • 条件が複雑化し、意味が分かりにくくなる
   • 可読性と保守性の低下
   • バグの発生リスク増大
3. 複数条件をスマートに記述するためのテクニックとベストプラクティス
   • 3.1. 論理演算子の徹底活用とカッコによる明示
     • && (AND) の使い方
     • || (OR) の使い方
     • ! (NOT) の使い方
     • 優先順位とカッコ () の重要性
   • 3.2. 早期リターン (Early Return / Guard Clause) の導入
     • 早期リターンの基本
     • メリット：ネストの解消と可読性向上
     • 複数のガード句を連ねる
   • 3.3. switch文の活用
     • switch文の基本
     • if-else ifとの使い分け
     • 落とし穴：breakの忘れ、範囲指定の難しさ
   • 3.4. 三項演算子 (Conditional Ternary Operator) で簡潔に
     • 三項演算子の基本
     • 使うべき時と避けるべき時
   • 3.5. オブジェクト（またはMap）を使ったディスパッチテーブル
     • オブジェクトをディスパッチテーブルとして使う
     • Mapオブジェクトを使った場合
     • メリット：拡張性、保守性、可読性
   • 3.6. 配列のsome() / every()メソッド
     • some(): いずれか一つが真
     • every(): 全てが真
     • ユースケース
   • 3.7. 関数への切り出しと変数による意味の明確化
     • 複雑な条件式を関数として抽出
     • 変数を導入して条件の意味を明確化
   • 3.8. デザインパターン（Strategyパターンなど）の検討
     • Strategyパターンとは
     • JavaScriptでの実装例
     • 適用を検討すべきケース
4. 実践的な応用例と具体的なユースケース
   • ユーザー入力の検証
   • アクセス権限のチェック
   • UIの状態管理
5. パフォーマンスに関する考慮事項（短絡評価）
6. まとめ：複雑な条件分岐を乗りこなすプロの視点

1. JavaScript if-else文の基本をおさらい

まず、複数条件を扱う前に、JavaScriptのif-else文の基本的な構造を簡単におさらいしましょう。これは、すべての条件分岐の基礎となります。

最も基本的なif文

条件が真（true）の場合にのみ、特定のコードを実行します。

let score = 75;

if (score >= 60) {
  console.log("合格です！"); // scoreが60以上なので実行される
}

if-else文

条件が真の場合と偽（false）の場合で、異なるコードを実行します。

let temperature = 28;

if (temperature > 25) {
  console.log("暑いですね。エアコンをつけましょう。"); // temperatureが25より大きいので実行される
} else {
  console.log("快適な気温です。");
}

if-else if-else文

複数の条件を段階的に評価し、最初に見つかった真の条件に対応するコードブロックを実行します。どの条件も真でなかった場合は、最後のelseブロックが実行されます。

let grade = 85;

if (grade >= 90) {
  console.log("評価: A");
} else if (grade >= 80) {
  console.log("評価: B"); // gradeが80以上90未満なので実行される
} else if (grade >= 70) {
  console.log("評価: C");
} else {
  console.log("評価: D");
}

複数条件の基本的な書き方

JavaScriptでは、論理演算子である&&（AND）と||（OR）を使って、一つのif文の中に複数の条件を組み合わせることができます。

• && (AND): すべての条件が真の場合に真となります。
• || (OR): いずれか一つの条件でも真であれば真となります。

let age = 20;
let isStudent = true;
let hasLicense = false;

// AND条件: 年齢が18歳以上 かつ 学生である
if (age >= 18 && isStudent) {
  console.log("あなたは学生で、成人です。"); // 実行される
}

// OR条件: 年齢が18歳以上 または 免許を持っている
if (age >= 18 || hasLicense) {
  console.log("あなたは成人か、免許を持っています。"); // 実行される (age >= 18 が真のため)
}

// 組み合わせ
let hour = 10;
let isWeekend = false;

if ((hour >= 9 && hour <= 17) && !isWeekend) {
  console.log("平日の営業時間中です。"); // 実行される
}

これらはif-else文の基礎中の基礎ですが、これらをいかにスマートに、かつ読みやすく記述するかが、良質なコードを書く上での重要なポイントになります。

2. 複数条件を扱う際の共通の課題とアンチパターン

JavaScriptで複数条件を扱う際に、多くの開発者が直面する問題点や、避けるべきアンチパターンについて見ていきましょう。これらの課題を認識することが、より良いコードを書くための第一歩です。

ネストが深くなる問題（通称：ピラミッド・オブ・ドゥーム）

条件が増えるたびに、if文の中にさらにif文を記述していくと、コードのインデントが深くなり、コードブロックが右に寄っていく現象が発生します。これは「ピラミッド・オブ・ドゥーム（破滅のピラミッド）」あるいは「コールバック地獄」と似た状況で、可読性を著しく損ないます。

function processOrder(user, item, paymentMethod) {
  if (user.isLoggedIn) {
    if (user.hasValidAddress) {
      if (item.isInStock) {
        if (paymentMethod === 'creditCard' || paymentMethod === 'paypal') {
          // ここでようやく注文処理...
          console.log(`${user.name}様の注文 (${item.name}) を ${paymentMethod} で受け付けました。`);
        } else {
          console.log("無効な支払い方法です。");
        }
      } else {
        console.log("商品が在庫切れです。");
      }
    } else {
      console.log("配送先住所が無効です。");
    }
  } else {
    console.log("ログインしてください。");
  }
}

// このコードは読むのが非常に難しい

この例では、成功パスが一番奥にあり、コードの流れを追うのが困難です。

条件が複雑化し、意味が分かりにくくなる

複数の論理演算子を使って一つの条件式を長く記述しすぎると、その条件が「何を意味しているのか」が一見して理解しにくくなります。

if (user.age > 18 && user.isVerified && (user.subscriptionType === 'premium' || user.subscriptionType === 'gold') && user.lastLoginDate > Date.now() - (30 * 24 * 60 * 60 * 1000)) {
  // 特定の処理
}

このようなコードは、条件の意味を解読するのに時間がかかり、潜在的なバグを見過ごしやすくなります。

可読性と保守性の低下

上記の2つの問題は、直接的にコードの可読性と保守性の低下につながります。

• 可読性: 誰が読んでも理解しやすいコードは、バグの発見や機能追加、修正の時間を短縮します。複雑なif-else文は、その妨げとなります。
• 保守性: コードの修正や機能追加が必要になった際、複雑な条件分岐は変更箇所を特定しづらく、意図しない副作用を引き起こすリスクを高めます。

バグの発生リスク増大

条件が複雑であればあるほど、論理エラーが混入しやすくなります。特に、論理演算子の優先順位の誤解や、elseブロックの欠如によるエッジケースの見落としなどは、頻繁に発生するバグの元です。

これらの課題を克服するために、次に紹介する様々なテクニックとベストプラクティスを習得することが不可欠です。

3. 複数条件をスマートに記述するためのテクニックとベストプラクティス

ここでは、前述の課題を解決し、JavaScriptの複数条件をよりスマートに、読みやすく、保守性高く記述するための具体的なテクニックとベストプラクティスを詳しく解説します。

3.1. 論理演算子の徹底活用とカッコによる明示

論理演算子 (&&, ||, !) は、複数条件を扱う上での基本ですが、その使い方をマスターし、カッコを適切に使うことで、可読性を大きく向上させることができます。

&& (AND) の使い方

すべての条件が真である場合に処理を実行します。

// 悪い例: 不必要なネスト
if (user.isLoggedIn) {
  if (user.isAdmin) {
    if (user.isActive) {
      console.log("管理者がログイン中です。");
    }
  }
}

// 良い例: && を使って簡潔に
if (user.isLoggedIn && user.isAdmin && user.isActive) {
  console.log("管理者がログイン中です。");
}

|| (OR) の使い方

いずれかの条件が真である場合に処理を実行します。

// 悪い例: 冗長な else if
let userRole = "editor";
if (userRole === "admin") {
  console.log("管理者権限があります。");
} else if (userRole === "editor") {
  console.log("管理者権限があります。");
} else {
  console.log("管理者権限がありません。");
}

// 良い例: || を使って簡潔に
if (userRole === "admin" || userRole === "editor") {
  console.log("管理者権限があります。");
} else {
  console.log("管理者権限がありません。");
}

! (NOT) の使い方

条件を反転させます。否定的な条件を扱う際に役立ちます。

let isEmpty = false;

// 悪い例: ! を使わない場合
if (isEmpty === false) {
  console.log("配列は空ではありません。");
}

// 良い例: ! を使って簡潔に
if (!isEmpty) {
  console.log("配列は空ではありません。");
}

優先順位とカッコ () の重要性

論理演算子には優先順位があります (! > && > ||)。これを理解し、必要に応じてカッコ () を使って明示的に優先順位を指定することで、意図しない挙動を防ぎ、可読性を向上させます。

// 例: (A AND B) OR C
// `&&` は `||` よりも優先順位が高いので、カッコがないと (A AND B) OR C と解釈される。
// しかし、意図を明確にするためにカッコを使うのがベスト。
if ((user.isAdmin && user.isApproved) || user.isGuest) {
  console.log("閲覧許可があります。");
}

// 悪い例: 意図が不明確
// user.isAdmin && user.isApproved || user.isGuest
// と書くと、もしあなたが優先順位を忘れていたら、user.isApproved || user.isGuest が先に評価されると誤解するかもしれない。

3.2. 早期リターン (Early Return / Guard Clause) の導入

早期リターンは、最も効果的な可読性向上テクニックの一つです。特定の条件が満たされない場合に、関数の早い段階で処理を終了させることで、深いネストを避け、コードを平坦に保ちます。

早期リターンの基本

関数の冒頭で、前提条件が満たされているかを確認し、満たされていない場合はすぐにreturnで処理を終了します。

// 悪い例: ネストが深い
function calculateDiscount(price, user) {
  if (user) {
    if (user.isPremium) {
      if (price > 1000) {
        return price * 0.8; // 20%オフ
      } else {
        return price * 0.9; // 10%オフ
      }
    } else {
      return price; // 割引なし
    }
  } else {
    return price; // 割引なし
  }
}

// 良い例: 早期リターンを適用
function calculateDiscountSmart(price, user) {
  // ユーザーが存在しない、またはプレミアムユーザーでない場合は割引なし
  if (!user || !user.isPremium) {
    return price;
  }

  // プレミアムユーザーで、価格が1000円以下の場合は10%オフ
  if (price <= 1000) {
    return price * 0.9;
  }

  // プレミアムユーザーで、価格が1000円を超える場合は20%オフ
  return price * 0.8;
}

console.log(calculateDiscountSmart(1200, { isPremium: true })); // 960
console.log(calculateDiscountSmart(800, { isPremium: true }));  // 720
console.log(calculateDiscountSmart(1200, { isPremium: false })); // 1200
console.log(calculateDiscountSmart(1200, null)); // 1200

メリット：ネストの解消と可読性向上

• ネストの解消: コードが左に寄った状態を保ち、視覚的に追跡しやすくなります。
• 可読性向上: 正常な処理フローが一番上に位置するため、ロジックを理解しやすくなります。前提条件を最初に処理することで、「もしこれが違ったらどうする？」という思考を排除できます。
• バグの削減: 各ガード句が独立した条件をチェックするため、間違いが入り込む余地が減ります。

複数のガード句を連ねる

複数の前提条件がある場合でも、早期リターンを連ねることでコードを簡潔に保てます。

function sendEmail(user, message) {
  if (!user) {
    console.error("ユーザー情報が提供されていません。");
    return false;
  }
  if (!user.email) {
    console.error("ユーザーのメールアドレスが不明です。");
    return false;
  }
  if (!user.isVerified) {
    console.error("ユーザーは認証されていません。");
    return false;
  }
  if (message.length === 0) {
    console.error("メッセージが空です。");
    return false;
  }

  // すべての条件をクリアした場合のみ、メール送信処理
  console.log(`Email sent to ${user.email}: "${message}"`);
  return true;
}

sendEmail({ email: "test@example.com", isVerified: true }, "Hello!"); // Email sent...
sendEmail({ email: "test@example.com", isVerified: false }, "Hello!"); // ユーザーは認証されていません。

3.3. switch文の活用

switch文は、一つの式の値に基づいて複数の分岐を行う場合に非常に強力です。特に、複数のelse ifが同じ変数や式の値を比較している場合に有効です。

switch文の基本

let command = "save";

switch (command) {
  case "open":
    console.log("ファイルを開きます。");
    break;
  case "save":
    console.log("ファイルを保存します。"); // 実行される
    break;
  case "print":
    console.log("ファイルを印刷します。");
    break;
  default:
    console.log("不明なコマンドです。");
}

if-else ifとの使い分け

• switch文: 特定の変数や式の単一の値に対する分岐が多数ある場合に適しています。列挙型の値やステータスコードなど。
• if-else if文: 複数の変数や複雑な条件式（範囲指定、論理演算子を組み合わせたものなど）を評価する場合に適しています。

例: switch文のメリット

// if-else if の例
let userStatus = "active";
if (userStatus === "active") {
  console.log("ユーザーはアクティブです。");
} else if (userStatus === "pending") {
  console.log("ユーザーは保留中です。");
} else if (userStatus === "suspended") {
  console.log("ユーザーは停止中です。");
} else {
  console.log("不明なステータスです。");
}

// switch の例
switch (userStatus) {
  case "active":
    console.log("ユーザーはアクティブです。");
    break;
  case "pending":
    console.log("ユーザーは保留中です。");
    break;
  case "suspended":
    console.log("ユーザーは停止中です。");
    break;
  default:
    console.log("不明なステータスです。");
}
// switchの方が、同じ値を何度も比較するif-else ifよりも意図が明確で、新しいケースの追加も容易。

落とし穴：breakの忘れ、範囲指定の難しさ

• breakの忘れ: caseブロックの最後にbreakを忘れると、次のcaseブロックの処理も実行されてしまいます（フォールスルー）。これは意図しないバグの温床です。
• 範囲指定の難しさ: switch文は基本的に厳密な値の比較(===)を行うため、age > 18のような範囲指定の条件には直接的に向いていません。

// 範囲指定にswitchを使う場合のトリッキーな例（非推奨）
let score = 85;
switch (true) { // switchの式を常にtrueにする
  case (score >= 90):
    console.log("A");
    break;
  case (score >= 80):
    console.log("B"); // 実行される
    break;
  default:
    console.log("C");
}
// この書き方は可能ですし、動きますが、if-else if の方が自然で分かりやすいでしょう。

3.4. 三項演算子 (Conditional Ternary Operator) で簡潔に

三項演算子は、非常に簡潔なif-else文を書くためのショートハンドです。条件 ? 真の場合の式 : 偽の場合の式 という形式で記述します。

三項演算子の基本

let age = 20;
let message = (age >= 18) ? "成人です" : "未成年です";
console.log(message); // "成人です"

使うべき時と避けるべき時

• 使うべき時:

  • 単純な2択の代入: 変数に値を割り当てる際に、条件によって値を変えたい場合。
  • 簡潔な条件: 条件式が短く、かつ真と偽の処理も簡潔な場合。
  • JSX/TSX内: Reactなどのコンポーネントで、条件に基づいて異なる要素を表示する場合。

  // 例: React JSXでの利用
  // <div>
  //   {isLoggedIn ? <UserProfile /> : <LoginButton />}
  // </div>
  

• 避けるべき時:

  • 複雑な条件: 複数の論理演算子を使った長い条件式。
  • ネスト: 三項演算子の中に三項演算子をネストすると、非常に読みにくくなります。
  • 副作用のある処理: 三項演算子は式なので、複雑な副作用（console.logを複数回実行するなど）を伴う処理には不向きです。

// 悪い例: 三項演算子のネスト
let status = (age >= 18) ? (isVerified ? "成人認証済み" : "成人未認証") : "未成年";
// ↑これもまだ読めますが、これ以上複雑になると厳しい。

// 悪い例: 複雑な条件と副作用
(user.isAdmin && user.isActive) ? doAdminAction() : console.log("権限がありません。");
// ↑処理が関数呼び出し1つならまだ良いが、複数の処理が入ると可読性が下がる。

シンプルさを保つことが、三項演算子を有効活用する鍵です。

3.5. オブジェクト（またはMap）を使ったディスパッチテーブル

これは、多数のif-else ifやswitch文を、オブジェクトのプロパティやMapのキーとして条件をマッピングし、値として実行する関数を持つことで置き換える非常に強力なテクニックです。

オブジェクトをディスパッチテーブルとして使う

const actionMap = {
  "add": (a, b) => a + b,
  "subtract": (a, b) => a - b,
  "multiply": (a, b) => a * b,
  "divide": (a, b) => a / b,
  "default": () => "不明な操作です。" // デフォルト処理
};

function executeOperation(operation, x, y) {
  const func = actionMap[operation] || actionMap["default"]; // 操作が見つからない場合はデフォルトを使用
  return func(x, y);
}

console.log(executeOperation("add", 5, 3));      // 8
console.log(executeOperation("subtract", 10, 4)); // 6
console.log(executeOperation("power", 2, 3));    // 不明な操作です。

Mapオブジェクトを使った場合

Mapは、キーにオブジェクトや任意のデータ型を使用できるため、より柔軟なディスパッチテーブルを構築できます。

const statusMessages = new Map([
  ["success", "処理が正常に完了しました。"],
  ["error", "エラーが発生しました。"],
  ["warning", "警告があります。"],
]);

function getStatusDescription(status) {
  return statusMessages.get(status) || "不明なステータスです。";
}

console.log(getStatusDescription("success")); // 処理が正常に完了しました。
console.log(getStatusDescription("pending")); // 不明なステータスです。

メリット：拡張性、保守性、可読性

• 拡張性: 新しい条件や処理を追加する際に、if-else ifやswitch文に比べて、新しいcaseやelse ifを追加するよりも、単にオブジェクトに新しいプロパティを追加するだけで済みます。既存のロジックに手を加える必要が少ないため、サイドエフェクトのリスクが低減します。
• 保守性: 条件とそれに対応する処理が一箇所に集約されるため、保守が容易になります。
• 可読性: どのような条件でどの処理が実行されるのかが一目で分かります。

このテクニックは、特にコマンド処理、ステータスに応じた処理、ユーザーの役割に応じた機能提供など、多数の離散的な条件分岐がある場合に非常に有効です。

3.6. 配列のsome() / every()メソッド

条件が「配列内のいずれかの要素が満たすか」または「配列内のすべての要素が満たすか」という形である場合、Array.prototype.some()やArray.prototype.every()メソッドがif文を簡潔にするのに役立ちます。

some(): いずれか一つが真

配列の要素のいずれか一つでも指定された条件を満たせばtrueを返します。

const userRoles = ["viewer", "editor"];
const requiredRoles = ["admin", "editor"];

// ユーザーがいずれかの必要な役割を持っているか？
const hasRequiredRole = requiredRoles.some(role => userRoles.includes(role));
console.log(hasRequiredRole); // true (userRolesに"editor"が含まれているため)

if (hasRequiredRole) {
  console.log("アクセスが許可されました。");
}

every(): 全てが真

配列のすべての要素が指定された条件を満たせばtrueを返します。

const items = [
  { name: "Pen", price: 100 },
  { name: "Book", price: 500 },
  { name: "Eraser", price: 50 }
];

// すべての商品が1000円以下か？
const allItemsAffordable = items.every(item => item.price <= 1000);
console.log(allItemsAffordable); // true

if (allItemsAffordable) {
  console.log("すべての商品が予算内です。");
}

ユースケース

• アクセス権限のチェック（複数のロールのうちいずれかを持つか）
• フォーム入力のバリデーション（全ての項目が有効か）
• コレクション内のデータの状態チェック

これらのメソッドを使いこなすことで、冗長なループや複雑なif文を避けることができます。

3.7. 関数への切り出しと変数による意味の明確化

複雑な条件式は、それ自体が何をしているのか分かりにくくなりがちです。これを解決するために、条件式を意味のある関数や変数に切り出すことが非常に有効です。

複雑な条件式を関数として抽出

特定の複雑な条件式を、その意味を明確に表す関数にラップします。

// 悪い例: 複雑な条件式が直接if文の中にある
if (user.isActive && user.hasPaidSubscription && user.isEmailVerified && user.lastLoginDate > Date.now() - (7 * 24 * 60 * 60 * 1000)) {
  // プレミアムコンテンツへのアクセス許可
  console.log("プレミアムコンテンツにアクセスできます。");
}

// 良い例: 条件式を関数に切り出す
function canAccessPremiumContent(user) {
  const isRecentLogin = user.lastLoginDate > Date.now() - (7 * 24 * 60 * 60 * 1000);
  return user.isActive && user.hasPaidSubscription && user.isEmailVerified && isRecentLogin;
}

const currentUser = {
  isActive: true,
  hasPaidSubscription: true,
  isEmailVerified: true,
  lastLoginDate: Date.now()
};

if (canAccessPremiumContent(currentUser)) {
  console.log("プレミアムコンテンツにアクセスできます。");
}

この方法により、if文の条件がcanAccessPremiumContent(currentUser)という一目でわかる形になり、可読性が劇的に向上します。また、この条件が変更された場合でも、canAccessPremiumContent関数の中だけを修正すればよいため、保守性も高まります。

変数を導入して条件の意味を明確化

条件式を構成する個々の部分に意味のある変数名を割り当てることで、全体の条件式の意図を分かりやすくします。

let stockCount = 5;
let orderQuantity = 3;
let isRushOrder = true;
let customerStatus = "premium";

// 悪い例: 意味が分かりにくい
if (stockCount >= orderQuantity && isRushOrder === true && (customerStatus === "premium" || customerStatus === "gold")) {
  console.log("優先配送処理を開始します。");
}

// 良い例: 変数を導入して意味を明確化
const hasEnoughStock = stockCount >= orderQuantity;
const isHighPriorityCustomer = customerStatus === "premium" || customerStatus === "gold";

if (hasEnoughStock && isRushOrder && isHighPriorityCustomer) {
  console.log("優先配送処理を開始します。");
}

変数を導入することで、各条件が何を意味するのかを明確にし、複雑な条件式も「ストーリー」のように読み解くことができるようになります。これはデバッグ時にも非常に役立ちます。

3.8. デザインパターン（Strategyパターンなど）の検討

非常に複雑で、将来的に多くの条件やロジックの変更が予想される場合、デザインパターンの導入を検討することも有効です。特にStrategyパターンは、条件に応じたアルゴリズムや振る舞いをカプセル化し、実行時に動的に選択するのに役立ちます。

Strategyパターンとは

Strategyパターンは、アルゴリズムのファミリーを定義し、それぞれをカプセル化し、それらを交換可能にするパターンです。アルゴリズムをそれを使用するクライアントから独立して変更できるようにします。

JavaScriptでの実装例

例えば、ユーザーのプランに応じて異なる料金計算を行う場合。

// 各戦略（料金計算アルゴリズム）を定義するオブジェクト
const pricingStrategies = {
  "basic": (price) => price, // 基本料金
  "premium": (price) => price * 0.9, // 10%オフ
  "vip": (price) => price * 0.8, // 20%オフ
  "default": (price) => price // デフォルトは基本料金
};

// コンテキスト（料金計算を実行する関数）
function calculatePriceWithStrategy(userPlan, basePrice) {
  const strategy = pricingStrategies[userPlan] || pricingStrategies["default"];
  return strategy(basePrice);
}

// 使用例
console.log(calculatePriceWithStrategy("basic", 1000));   // 1000
console.log(calculatePriceWithStrategy("premium", 1000)); // 900
console.log(calculatePriceWithStrategy("vip", 1000));     // 800
console.log(calculatePriceWithStrategy("unknown", 1000)); // 1000

この例では、オブジェクトを使ったディスパッチテーブルとStrategyパターンが組み合わされています。新しい料金プランを追加する際には、pricingStrategiesオブジェクトに新しい関数を追加するだけで済み、if-elseやswitch文のようにコードの構造をいじる必要がありません。

適用を検討すべきケース

• ビジネスロジックが頻繁に変更される、または追加される可能性が高い場合。
• 同じ種類の条件分岐がアプリケーションの複数の場所で発生する場合。
• 条件分岐の各ブランチが、それぞれ複雑な独自のロジックを持つ場合。

デザインパターンは強力ですが、オーバーエンジニアリングにならないよう、コードの複雑性に見合った適切なパターンを選択することが重要です。

4. 実践的な応用例と具体的なユースケース

これまでに学んだテクニックを、実際の開発シナリオでどのように応用できるかを見ていきましょう。

ユーザー入力の検証

フォーム送信前などに、複数の条件をチェックして入力が有効かどうかを判断します。

function validateUserData(userData) {
  // 早期リターンで基本的な存在チェック
  if (!userData) {
    return { isValid: false, message: "ユーザーデータが提供されていません。" };
  }
  if (!userData.username || userData.username.length < 3) {
    return { isValid: false, message: "ユーザー名は3文字以上である必要があります。" };
  }
  if (!userData.email || !userData.email.includes('@')) {
    return { isValid: false, message: "有効なメールアドレスを入力してください。" };
  }
  if (!userData.password || userData.password.length < 8) {
    return { isValid: false, message: "パスワードは8文字以上である必要があります。" };
  }
  if (userData.age && userData.age < 18) { // ageはオプションだが、あれば18歳以上
    return { isValid: false, message: "18歳未満の方は登録できません。" };
  }

  // すべての条件をクリア
  return { isValid: true, message: "入力は有効です。" };
}

console.log(validateUserData({ username: "john", email: "john@example.com", password: "password123" }));
// { isValid: true, message: "入力は有効です。" }

console.log(validateUserData({ username: "jo", email: "john@example.com", password: "password123" }));
// { isValid: false, message: "ユーザー名は3文字以上である必要があります。" }

早期リターンを多用することで、コードの読みやすさが格段に向上しています。

アクセス権限のチェック

特定の機能やリソースへのアクセスを、ユーザーのロールや状態に基づいて制御します。

const user = {
  id: 1,
  name: "Alice",
  roles: ["editor", "viewer"],
  isActive: true,
  isPremium: false
};

const requiredRolesForAdminPage = ["admin"];
const requiredRolesForEditorPage = ["admin", "editor"];

function checkAccess(user, requiredRoles, requiresPremium = false) {
  // ユーザーが存在しない、またはアクティブでない場合は早期リターン
  if (!user || !user.isActive) {
    console.log("アクセス拒否: 無効なユーザーまたは非アクティブです。");
    return false;
  }

  // 必要なロールのいずれかを持っているかチェック（Array.some()を使用）
  const hasRequiredRole = requiredRoles.some(role => user.roles.includes(role));
  if (!hasRequiredRole) {
    console.log(`アクセス拒否: 必要なロールがありません。必要なロール: ${requiredRoles.join(', ')}`);
    return false;
  }

  // プレミアム会員である必要があるかチェック
  if (requiresPremium && !user.isPremium) {
    console.log("アクセス拒否: プレミアム会員である必要があります。");
    return false;
  }

  console.log("アクセス許可。");
  return true;
}

checkAccess(user, requiredRolesForEditorPage); // アクセス許可。
checkAccess(user, requiredRolesForAdminPage);  // アクセス拒否: 必要なロールがありません。
checkAccess(user, requiredRolesForEditorPage, true); // アクセス拒否: プレミアム会員である必要があります。

ここでは、早期リターンとArray.some()を組み合わせることで、複雑な権限チェックを簡潔に記述しています。

UIの状態管理

ユーザーインターフェースの表示を、複数の状態に基づいて動的に変更します。

function getButtonState(isLoading, hasError, dataExists) {
  // オブジェクトによるディスパッチテーブル的なアプローチ
  const stateLogic = {
    // 状態を組み合わせたキー
    "true_true_false": "disabled_error", // ローディング中かつエラーあり
    "true_false_false": "disabled_loading", // ローディング中（データなし）
    "true_false_true": "disabled_loading", // ローディング中（データあり）
    "false_true_false": "error_retry", // エラーあり、データなし
    "false_false_false": "disabled_initial", // 初期状態、データなし
    "false_false_true": "enabled_data", // 通常状態、データあり
  };

  const key = `${isLoading}_${hasError}_${dataExists}`;
  const state = stateLogic[key] || "disabled_initial"; // デフォルト値

  // switch文でそれぞれの状態に応じた具体的なUI設定を返す
  switch (state) {
    case "disabled_loading":
      return { text: "読み込み中...", disabled: true, class: "btn-loading" };
    case "disabled_error":
    case "error_retry":
      return { text: "エラーが発生しました", disabled: false, class: "btn-error" };
    case "disabled_initial":
      return { text: "データを読み込む", disabled: true, class: "btn-default" };
    case "enabled_data":
      return { text: "データを更新", disabled: false, class: "btn-primary" };
    default:
      return { text: "不明な状態", disabled: true, class: "btn-default" };
  }
}

console.log(getButtonState(true, false, false)); // { text: "読み込み中...", disabled: true, class: "btn-loading" }
console.log(getButtonState(false, true, false)); // { text: "エラーが発生しました", disabled: false, class: "btn-error" }
console.log(getButtonState(false, false, true)); // { text: "データを更新", disabled: false, class: "btn-primary" }

ここでは、複数の真偽値の組み合わせを文字列のキーとしてオブジェクトにマッピングし、その後switch文で具体的なUIプロパティを返しています。これにより、非常に多くの状態の組み合わせを効率的に管理できます。

5. パフォーマンスに関する考慮事項（短絡評価）

&&（AND）と||（OR）の論理演算子には「短絡評価（Short-circuit evaluation）」という特性があります。これはパフォーマンスに影響を与える可能性がありますが、一般的には可読性や保守性を優先すべきです。

• && (AND): 左側のオペランドがfalseと評価された場合、右側のオペランドは評価されません。なぜなら、左側がfalseであれば、右側の結果に関わらず全体の結果は必ずfalseになるからです。

  let result = false && someFunctionReturningTrue(); // someFunctionReturningTrue() は実行されない
  

• || (OR): 左側のオペランドがtrueと評価された場合、右側のオペランドは評価されません。なぜなら、左側がtrueであれば、右側の結果に関わらず全体の結果は必ずtrueになるからです。

  let result = true || someFunctionReturningFalse(); // someFunctionReturningFalse() は実行されない
  

この特性は、以下のような場面で活用されます。

• デフォルト値の設定:

  const userName = user.name || "ゲスト"; // user.nameがfalsy (null, undefined, "", 0など) の場合、"ゲスト"が使われる
  

• 安全なプロパティアクセス:

  // userが存在する場合のみ user.profile.name にアクセスする
  // userがnullやundefinedの場合、右側は評価されないためエラーにならない
  const profileName = user && user.profile && user.profile.name;
  

  現在では、Nullish coalescing operator (??) や Optional chaining (?.) を使う方がより意図を明確にできます。

  const userName = user.name ?? "ゲスト"; // nullish (nullまたはundefined) の場合のみ"ゲスト"
  const profileName = user?.profile?.name; // nullishの場合、undefinedを返す
  

短絡評価はJavaScriptの重要な機能ですが、これをパフォーマンスチューニングの主要な手段と考えるべきではありません。それよりも、可読性と意図の明確さを重視した上で、結果的にパフォーマンスの恩恵も得られる、というくらいの認識で十分です。現代のJavaScriptエンジンは非常に最適化されており、マイクロベンチマークで差が出るようなケースは稀です。

6. まとめ：複雑な条件分岐を乗りこなすプロの視点

この記事では、JavaScriptにおける複数条件のif-else文の基本から、コードを劇的に改善するための多様なテクニックまで、詳細に解説してきました。

私たちが学んだ主要なポイントを再確認しましょう。

1. 基本の理解: if-else、else if、そして&&、||といった論理演算子の使い方は、すべての土台です。
2. 課題の認識: 深いネスト（ピラミッド・オブ・ドゥーム）や複雑すぎる条件式は、可読性、保守性、バグのリスクを増大させます。
3. 解決策としてのテクニック:
   • 早期リターン (Guard Clause): ネストを解消し、コードを平坦に保つ最も強力な方法。
   • switch文: 単一の値に基づく多分岐に最適。if-else ifの代替として検討。
   • 三項演算子: 簡潔な2択の条件分岐に適しているが、過度な使用は避ける。
   • オブジェクト/Mapによるディスパッチテーブル: 多数の離散的な条件分岐をデータ駆動で管理し、高い拡張性と保守性を実現。
   • Array.some() / Array.every(): 配列内の要素の状態に基づく条件判断を簡潔に。
   • 関数への切り出しと変数による明確化: 複雑な条件式に意味を与え、可読性を劇的に向上させる。
   • デザインパターン: 非常に複雑なケースで、Strategyパターンなどが有効。

JavaScriptでプロとして開発を行う上で、ただコードが動くだけでなく、「いかに読みやすく、いかに保守しやすいコードを書くか」は極めて重要です。複雑な条件分岐は、コード品質を測る上での大きな試金石となります。

この記事で紹介したテクニックは、どれか一つだけを使えば良いというものではありません。それぞれの状況やコードの性質に合わせて、最も適切で、かつ将来の変更に強いアプローチを選択する判断力がプロには求められます。

コードを書くたびに、「このif文は本当にこれで良いのか？」「もっと良い書き方はないか？」と自問自答する習慣をつけましょう。それは、あなたのコードだけでなく、チーム全体の生産性とプロジェクトの成功に大きく貢献するはずです。

さあ、今日からあなたのJavaScriptコードをよりスマートで堅牢なものに変えていきましょう！