【ツール活用｜初心者向け】【初心者向け】if-else地獄からの脱却！決定表でロジックを整理する設計術

こんにちは！DevOps・インフラエンジニアの皆さん、そしてこれからエンジニアを目指す皆さん。システム開発の現場では、日々様々な「条件分岐」と格闘していますよね。

1. 導入: 複雑な条件分岐と決定表の力

「もし〇〇で、かつ△△なら、◇◇の処理をする。でも、もし✕✕だったら、別の処理をする…」
こんな風に、たくさんの条件が絡み合うビジネスロジックを設計する際、頭の中だけで整理するのは至難の業です。コードを書き始めたら「あれ？このパターン漏れてた！」「この条件だと矛盾するぞ？」なんて経験はありませんか？

このような複雑な条件分岐は、コードが長くなりがちで、思わぬバグや実装漏れの原因になります。リリース後に発覚するバグは、修正に時間もコストもかかり、お客様からの信頼も損ねてしまいますよね。

そこで役立つのが、今回ご紹介する「決定表 (Decision Table)」です。決定表は、複雑な条件とそれに対応する処理（アクション）を「表」形式で整理する強力なドキュメント・設計手法です。これにより、実装漏れや条件の矛盾（エッジケース）を、実際にコードを書く前に視覚的に発見できるようになります。手戻りを減らし、高品質なシステムを開発するための、まさに必殺技と言えるでしょう。

2. 基礎知識: 決定表って何？

決定表について、まずは基本的な用語から見ていきましょう。

決定表 (Decision Table):

複数の条件と、その条件の組み合わせによって実行されるべきアクションを、表形式で整理したものです。条件とアクションの関係が明確になり、ロジック全体を俯瞰しやすくなります。

条件網羅:

考えられる「すべての入力パターン（条件の組み合わせ）」を漏れなく洗い出すことです。決定表を使うことで、この条件網羅が視覚的に確認しやすくなります。

エッジケース (Edge Case):

通常の利用ではあまり発生しない、極端な条件や例外的な状況のことです。例えば「年齢が0歳」や「購入金額がマイナス」といった、滅多に起こらないけれど考慮すべきパターンを指します。決定表は、これらの見落としがちなエッジケースを発見するのに非常に有効です。

普段書いているif-else文やswitch文のロジックを、コードとしていきなり書くのではなく、一度この決定表に落とし込むことで、より堅牢な設計を目指せる、とイメージしてください。

3. 実装/解決策: 決定表の作り方

では、実際に決定表をどのように作成するのか、簡単な例を交えて説明します。
ここでは「ECサイトの会員ランクと購入金額に応じた割引率の決定」というシナリオを考えてみましょう。

決定表は、大きく分けて以下の3つの要素で構成されます。

1. 条件部 (Condition Stubs): 意思決定に影響を与える条件を記述します。
2. アクション部 (Action Stubs): 条件が満たされたときに実行されるアクションを記述します。
3. ルール部 (Rules): 各条件の組み合わせ（Yes/No、真/偽）と、それに対応するアクションを示します。

決定表の作成手順

条件の洗い出し: ロジックに影響を与える条件を全てリストアップします。
- 例: 「会員ランクがゴールドか？」「購入金額が5000円以上か？」
アクションの洗い出し: 各条件の組み合わせで実行されるアクションを全てリストアップします。
- 例: 「割引率10%」「割引率5%」「割引なし」
ルール（条件の組み合わせ）の作成:
各条件が「はい (Y)」または「いいえ (N)」のどちらになるかを組み合わせ、考えられるすべてのパターンを列挙します。条件がN個ある場合、2^N個のルールが基本となります。
また、「関係なし (-)」という記号を使うこともあります。これは、その条件が「Y」でも「N」でも結果に影響しない場合に使います。
アクションのマッピング: 各ルール（条件の組み合わせ）に対して、どのアクションが実行されるべきかを指定します。

割引率決定の決定表例

条件 / アクション	ルール1	ルール2	ルール3	ルール4
条件:
会員ランクがゴールドか？	Y	Y	N	N
購入金額が5000円以上か？	Y	N	Y	N
アクション:
割引率10%	X
割引率5%		X	X
割引なし				X

（「Y」はYes、「N」はNo、「X」はそのアクションを実行することを示します）

この表を見ると、どの条件の組み合わせでどのアクションが実行されるかが一目瞭然です。例えば「ルール1」は「会員ランクがゴールドで、購入金額が5000円以上なら、割引率10%」というロジックを表しています。

4. サンプルプログラム: Markdownとコードへの橋渡し

決定表はドキュメントとして作成しますが、それをMarkdown形式で記述すると、GitHubなどのバージョン管理システムでも管理しやすく、開発チーム内での共有もスムーズになります。

上記の割引率決定の決定表をMarkdownで表現すると以下のようになります。


| 条件 / アクション           | ルール1 | ルール2 | ルール3 | ルール4 |
| :-------------------------- | :------ | :------ | :------ | :------ |
| 条件:                   |         |         |         |         |
| 会員ランクがゴールドか？    | Y       | Y       | N       | N       |
| 購入金額が5000円以上か？    | Y       | N       | Y       | N       |
| アクション:             |         |         |         |         |
| 割引率10%                   | X       |         |         |         |
| 割引率5%                    |         | X       | X       |         |
| 割引なし                    |         |         |         | X       |

この決定表を元に、Pythonで簡易的なコードを書くと、以下のようになります。
決定表が、どのようにコードの設計に繋がるかイメージしてみてください。


def calculate_discount(is_gold_member: bool, purchase_amount: int) -> float:
    """
    会員ランクと購入金額に基づいて割引率を計算する関数

    Args:
        is_gold_member (bool): ゴールド会員であればTrue、そうでなければFalse
        purchase_amount (int): 購入金額

    Returns:
        float: 割引率 (例: 0.10 は10%割引)
    """
    discount_rate = 0.0  # 初期割引率は0%

    # 決定表のルール1: 会員ランクがゴールド AND 購入金額が5000円以上
    if is_gold_member and purchase_amount >= 5000:
        discount_rate = 0.10  # 10%割引
    # 決定表のルール2: 会員ランクがゴールド AND 購入金額が5000円未満
    elif is_gold_member and purchase_amount < 5000:
        discount_rate = 0.05  # 5%割引
    # 決定表のルール3: 会員ランクがゴールドではない AND 購入金額が5000円以上
    elif not is_gold_member and purchase_amount >= 5000:
        discount_rate = 0.05  # 5%割引
    # 決定表のルール4: 会員ランクがゴールドではない AND 購入金額が5000円未満
    elif not is_gold_member and purchase_amount < 5000:
        discount_rate = 0.00  # 割引なし
    
    return discount_rate

動作確認
print(f"ゴールド会員、8000円購入: {calculate_discount(True, 8000)100:.0f}%割引")   # 期待値: 10%
print(f"ゴールド会員、3000円購入: {calculate_discount(True, 3000)100:.0f}%割引")   # 期待値: 5%
print(f"一般会員、7000円購入: {calculate_discount(False, 7000)100:.0f}%割引")   # 期待値: 5%
print(f"一般会員、2000円購入: {calculate_discount(False, 2000)100:.0f}%割引")   # 期待値: 0%

5. 応用・注意点: 現場で役立つ活用法と落とし穴

応用編

スプレッドシートでの活用: ExcelやGoogle Sheetsなどのスプレッドシートツールを使えば、視覚的に決定表を作成・共有しやすくなります。条件やアクションの追加・修正も簡単です。
テストケースの自動生成: 決定表の各ルールは、そのままテストケースとして利用できます。これにより、網羅性の高いテストコードを作成しやすくなり、品質保証に大きく貢献します。
要件定義・レビュー時のコミュニケーション: 開発者だけでなく、企画担当者や業務担当者も決定表を見ることで、共通認識を深めることができます。「この場合どうなるの？」といった疑問も、表を見ながら具体的に話し合えるため、認識齟齬を防ぎます。

注意点

複雑になりすぎない: 条件が多すぎると、決定表自体が巨大になり、かえって読みにくくなることがあります。その場合は、複数の決定表に分割したり、一部の条件を抽象化したりすることを検討しましょう。
常に最新の状態を保つ: システムの要件やロジックが変更された場合、決定表も忘れずに更新しましょう。ドキュメントと実際のコードに乖離があると、その決定表は無意味になってしまいます。
「関係なし (-)」の適切な利用: 「関係なし」記号は表を簡潔にするのに役立ちますが、多用しすぎると特定の条件が本当に影響しないのか見落としやすくなることもあります。バランスを考えて使いましょう。

決定表は、特に複雑なビジネスロジックを扱うシステム開発において、その真価を発揮します。設計段階でしっかりとロジックを整理し、チームで共有することで、手戻りの少ない、高品質なシステム開発を目指しましょう！