多段階IFをルール検索として設計する

LWP | 多段階IFをルール検索として設計する

LWP TECHNICAL ARTICLE | 191

多段階IFをルール検索として設計する

本資料は、出典を明記いただければ、商用・非商用を問わず、ご自由に複製・改変・再配布していただけます。なお、著作権表示は改変せず、そのまま記載してご利用くださいますようお願いいたします。

記事要約

多段階IFが読みにくい原因は、IF関数そのものではなく、対応表として管理すべき値まで数式の中へ埋め込んでいることにあります。本記事では、本当の条件分岐とルール検索を分け、XLOOKUP、直接配列、名前付き配列、シート上の決定表を、可視性、変更主体、変更頻度、規模から選ぶ考え方を説明します。

本記事の対象とゴール

長いIF、IFS、SWITCHを保守しているExcel利用者や、業務ルールを読みやすく管理したい設計者を対象とします。数式を短くするだけでなく、複雑さを意味のある場所へ移し、レビューと変更に強い構造を選べることをゴールとします。

このテーマで一番重要な観点

このテーマは、単純な「IFをXLOOKUPに置き換える方法」の話ではない。

本質的には、

**そのロジックは、本当に条件分岐として書くべきものなのか。

それとも、ルールや対応関係を検索する問題なのか。**

という設計上の問いである。

多段階IFが読みにくくなる理由は、IF関数そのものが悪いからではない。

本来は「条件によって異なる計算をする」ためのIFに対して、

Aなら100
Bなら200
Cなら300
Dなら400

のような、実質的には「対応表」である情報まで条件式として書き込んでしまうことで、数式の中にデータとロジックが混在する。

ここを切り分けて考えることが、このテーマの出発点になる。

1. 「条件分岐」と「ルール検索」は別物

まず最初に整理したいのは、IFとXLOOKUPは単純な競合関係ではないということ。

両者は本来、担当する問題が異なる。

IFが向いているもの

IFは、条件によって処理や計算そのものを切り替える場合に向いている。

例：

=IF(

    売上>1000000,

    売上*0.05+特別加算,

    MAX(売上-経費,0)*0.02

これは、

条件Aなら計算式A
条件Bなら計算式B

という「処理の分岐」である。

このようなものを無理にマスター化する必要はない。

XLOOKUPが向いているもの

一方、

A → 100

B → 200

C → 300

D → 400

というものは、実質的には条件分岐ではない。

これは、

あるキーに対して、どの値が対応するか

という検索問題である。

この場合、

=IF(A2="A",100,

 IF(A2="B",200,

 IF(A2="C",300,

 IF(A2="D",400,""))))

と書くことはできる。

しかし、この数式の実態は、

A | 100

B | 200

C | 300

D | 400

という表を、IFの構文で表現しているだけとも言える。

ここが重要な観点になる。

データをプログラムとして書いていないか。

2. 「IFを短くする」のではなく、「複雑さの置き場所」を考える

多段階IFに対してよく行われる改善は、

LETを使う
IFSを使う
SWITCHを使う

といった方法である。

もちろん、これらには意味がある。

しかし、問題によっては根本的な解決にはならない。

IF

=IF(A2="A",100,

 IF(A2="B",200,

 IF(A2="C",300,"")))

ルールも処理も一つの数式に入っている。

IFS

=IFS(

    A2="A",100,

    A2="B",200,

    A2="C",300

構文は読みやすくなる。

しかし、

A → 100

B → 200

C → 300

という対応関係そのものは依然として数式内部に存在している。

SWITCH

=SWITCH(

A2,

    "A",100,

    "B",200,

    "C",300

完全一致の分岐ならかなり読みやすい。

ただし、これもルールを数式の中に記述している点では同じ。

LET

=LET(

    x,A2,

    IF(x="A",100,

        IF(x="B",200,

            IF(x="C",300,0)

LETは非常に重要な関数であり、複雑な数式を整理する力がある。

しかしこの問題については、

複雑な式を読みやすくする

ことはできても、

複雑さそのものを数式の外へ出す

ことはしていない。

ここは実務上でも重要な比較軸になる。

3. XLOOKUPを使うと「条件分岐」が「データ検索」に変わる

同じルールをXLOOKUPで書くと、

=XLOOKUP(

A2,

    {"A","B","C"},

    {100,200,300}

となる。

この変化は単に数式が短くなったという話ではない。

構造そのものが変わっている。

IFでは、

Aなら100

Bなら200

Cなら300

という「命令」として記述していた。

XLOOKUPでは、

検索キー    戻り値

A           100

B           200

C           300

という「データ」として表現している。

この違いを、

制御構造からデータ構造への変換

として捉えることができる。

これはここが中心的な考え方になる。

4. 決定表という考え方

条件が増えたとき、最も分かりやすい形の一つが決定表である。

例えば、

顧客区分	地域	金額条件	掛率
A	東京	100000	0.80
A	大阪	100000	0.82
A	東京	0	0.90
B	東京	100000	0.85

この形式の大きな特徴は、

ルールそのものを見ることができる

ということである。

多段階IFではロジックを読み解かなければならない。

決定表では、条件と結果が並んでいる。

つまり表そのものが、

設計
データ
仕様書
テスト対象

を兼ねることができる。

5. XLOOKUP＋シート上の決定表

典型的には、別シートやマスターシートに表を置く。

例：

区分	単価
A	100
B	200
C	300

そして、

=XLOOKUP(A2,マスター[区分],マスター[単価])

とする。

この方式の利点は非常に明確である。

長所

ルールが目で見える
数式とルールを分離できる
非開発者でも変更しやすい
マスターとして管理しやすい
レビューしやすい
テストしやすい
行を追加するだけでルールを増やせる
数式を大量に編集しなくてよい

特に業務ルールでは強い。

例えば、

商品区分
手数料率
顧客ランク
部門コード
配送料
割引率
税区分
社内分類

などは、シート上の表として存在している方が管理しやすい場合が多い。

6. ただし「決定表のためだけのシート」が増える問題がある

ここで次の疑問が出てくる。

数個、あるいは数十個程度の固定ルールのために、

わざわざマスターシートを作る必要があるのか。

例えば、

A → 100

B → 200

C → 300

がほとんど変化しない内部ルールなら、

マスター

設定

コード表

内部設定

といったシートを増やすこと自体が、逆にノイズになる可能性がある。

ここで、

名前定義された配列を検索対象にする

という考え方が出てくる。

7. XLOOKUP＋名前定義された配列

Excelでは名前定義の対象はセル範囲だけではない。

配列や数式も名前として定義できる。

例えば、

区分一覧

を、

={"A","B","C"}

と定義する。

さらに、

区分単価

を、

={100,200,300}

と定義する。

シート上では、

=XLOOKUP(A2,区分一覧,区分単価)

と書ける。

この形式の面白いところは、

**XLOOKUPによる検索という分かりやすさを維持したまま、

検索用の表をワークシートから消せる**

点にある。

8. XLOOKUPの良さを残すことが重要

ここではXLOOKUP自体をLAMBDAの中へ隠しすぎない方がよい場合がある。

例えば、

=MASTER.GET(A2)

のような関数を作ることもできる。

しかし、この場合、

何を検索しているのか
どこから値を返しているのか
XLOOKUPの検索方法
戻り値配列を変更する自由

などが見えにくくなる。

XLOOKUPには、

=XLOOKUP(

    検索値,

    検索範囲,

    戻り範囲

という非常に明快な構造がある。

したがって、

XLOOKUPを隠すのではなく、XLOOKUPが参照する検索配列を抽象化する

方が美しい可能性がある。

例えば、

=XLOOKUP(A2,商品コード,商品区分)

であれば、

式を読むだけで、

商品コードから商品区分を調べている

と理解できる。

これはかなり大きな利点である。

9. Excel Labsを使う意味

ここでExcel LabsのAdvanced Formula Environmentが関係してくる。

重要なのは、

Excel Labsでなければ名前付き配列を作れない

わけではないこと。

名前定義自体はExcelの標準機能である。

Excel Labsの価値は、

多数の名前付き数式、配列、LAMBDAなどを、よりコードに近い感覚で整理・編集できること

にある。

したがって役割としては、

XLOOKUP

↓

名前付き配列

↓

Excel Labsで整理・管理

と考える方がよい。

10. 「シートの決定表」と「名前付き配列」は競合ではない

どちらが優れているかを一律に決めるべきではない。

両者はルールの性質によって使い分けることができる。

ここで非常に重要な軸になるのが、

そのルールは「設定」なのか、「実装」なのか。

業務上の設定である場合

例えば、

商品別掛率
顧客ランク
キャンペーン割引率
支店別手数料
年度別単価

など。

これらは利用者が変更する可能性がある。

この場合は、

シート上の決定表

が適している。

実装上の固定ルールである場合

例えば、

内部コードの分類
固定されたステータス変換
システム上の内部区分
原則変更しない小規模マッピング

など。

この場合は、

名前付き配列

として保持した方が、ワークブック全体をすっきりさせられる可能性がある。

11. 一つの判断基準

非常に短くまとめると、

**業務ルールならシート。

実装ルールなら名前付き配列。**

という考え方が一つの基準になる。

もちろん絶対的なルールではない。

ただ、記事全体を通す判断軸として非常に分かりやすい。

12. 「見えること」と「隠せること」のトレードオフ

シート上の決定表には、

見える

という圧倒的な利点がある。

誰かがブックを開けば、

A | 100

B | 200

C | 300

と確認できる。

一方、名前付き配列では、

=XLOOKUP(A2,区分一覧,区分単価)

と書かれていても、

区分一覧や区分単価の中身は、その場では見えない。

つまり名前付き配列には、

カプセル化できる

という長所と、

中身が見えない

という短所が同時に存在する。

13. 可視性を取るか、カプセル化を取るか

これはExcelだけの問題ではなく、設計全般の問題として考えられる。

シート

ルールを公開する

名前付き配列

ルールを内部実装として隠す

という違いである。

したがって、

「余計なシートを消せるから名前付き配列の方が優れている」

と単純化するべきではない。

むしろ、

**誰がルールを見る必要があるか。

誰が変更する必要があるか。**

で判断するべきである。

14. 比較対象

ここでは少なくとも次の方法を比較するとよい。

ネストしたIF
IFS
SWITCH
XLOOKUP＋直接配列
XLOOKUP＋シート上の決定表
XLOOKUP＋名前付き配列
必要に応じてLAMBDA / Excel Labsによるモジュール化

15. 比較表

方法	数式の読みやすさ	ルールの見やすさ	変更容易性	大規模化	再利用性	主な用途
ネストIF	△～×	×	×	×	×	本来の条件分岐
IFS	○	△	△	△～×	×	少数の条件列挙
SWITCH	○	△	△	△～×	×	少数の完全一致
XLOOKUP＋直接配列	○	○	△	×	△	小規模な固定対応
XLOOKUP＋シート決定表	◎	◎	◎	◎	○	業務ルール
XLOOKUP＋名前付き配列	◎	△	○	○	◎	固定された内部ルール
LAMBDA等で完全抽象化	◎	×～△	○	◎	◎	再利用可能な処理

この表では「数式が短いか」だけを評価しないことが重要。

少なくとも、

読みやすさ
ルールの可視性
保守性
変更者
規模
再利用性

を別々に評価した方がよい。

16. 「多段階IF」という言葉も分類した方がよい

多段階IFと一口に言っても、中身は違う。

種類A：計算処理の分岐

条件A → 計算式A

条件B → 計算式B

これはIFが自然。

種類B：値の対応

A → 100

B → 200

C → 300

これはXLOOKUPが自然。

種類C：複数条件から結果を決定

顧客=A

地域=東京

金額>=100000

↓

掛率=0.8

これは決定表として表現できる可能性が高い。

この分類を記事の早い段階で提示すると、

「多段階IFは全部XLOOKUPにすればよい」

という誤解を避けられる。

17. 多条件になるほど「決定表」の意味が大きくなる

例えば、

顧客区分
地域
商品区分
売上金額

で結果が決まる場合。

IFでは、

=IF(顧客区分="A",

    IF(地域="東京",

        IF(金額>=100000,

...

),

...

のようになりやすい。

これは書ける。

しかし、

書けることと、設計として適切であることは別

である。

同じ内容を表にすれば、

顧客	地域	金額下限	結果
A	東京	100000	0.80
A	東京	0	0.90
A	大阪	100000	0.82
B	東京	100000	0.85

となる。

この瞬間、ルール全体を人間が俯瞰できる。

これは数式を短くすること以上の利点である。

18. 決定表は「仕様書」にもなる

この観点はかなり重要。

IFの中に埋め込まれたルールは、式を解析しなければ仕様が分からない。

決定表なら、表そのものが仕様になる。

例えば、

顧客=A

地域=東京

金額>=100000

→ 0.80

が1行で表現される。

すると、

本当にこのルールでよいか
重複ルールがないか
抜けている条件がないか
優先順位がおかしくないか

といったレビューもしやすい。

つまり、

決定表化は、数式改善だけではなく、仕様の可視化でもある。

19. 数式コピーの問題

多段階IFでは、同じ式を大量の行にコピーすることが多い。

数式そのものが長い場合、

コピー範囲
修正漏れ
一部のセルだけ異なる
絶対参照・相対参照
手作業による改変

などの問題も起こりやすい。

XLOOKUP化して、

=XLOOKUP(A2,区分,単価)

のようにできれば、各セル側のロジックは単純になる。

重要なのは、

変更点を「数式」から「マスター」に移せる

ことである。

20. 「変更箇所が1か所になる」という価値

例えば単価Bを、

200 → 220

に変更するとする。

IFなら、数式そのものを編集する必要がある。

場合によっては大量のセルにコピーされた式の状態も確認する必要がある。

決定表なら、

B | 200

を、

B | 220

に変更するだけでよい。

名前付き配列の場合でも、定義元の配列を1か所変更すればよい。

したがって重要なのは、

ロジックの変更点を集約する

という発想である。

21. 名前付き配列は「小さなマスター」と考えられる

名前付き配列は、単なるテクニックではなく、

ワークブック内部に持つ小さなマスター

と考えると理解しやすい。

例えば、

StatusCode = {"NEW","RUN","END"}

StatusName = {"未着手","進行中","完了"}

のようなもの。

これをわざわざシートにするほどではない。

しかし数式の中へ直接、

{"NEW","RUN","END"}

と毎回書くのも避けたい。

その中間として名前付き配列がある。

22. 直接配列も比較対象として重要

例えば、

=XLOOKUP(

A2,

    {"A","B","C"},

    {100,200,300}

は、小さなルールなら非常に合理的。

名前定義を作るほどでもなく、シートも不要。

したがって実際には、

直接配列

↓

名前付き配列

↓

シート上の決定表

という連続した選択肢として捉えることもできる。

23. ルールの規模による選択

一つの目安として、

ごく小さい

3～5個程度

なら直接配列でも十分。

小～中規模で固定的

数個～数十個

なら名前付き配列が有力。

大規模、頻繁に変更、業務担当者が編集

数十～数百以上

ならシート上のマスターが自然。

ただし件数だけで判断せず、

誰が変更するか
変更頻度
可視性
監査性

を優先する。

24. 判断軸

ここでは、各方式を次の軸で比較するとよい。

ルールは誰が変更するか

Excel作成者のみ
一般利用者
管理部門
システム管理者

どれくらい変更されるか

ほぼ固定
年1回
月1回
日常的

ルールを見る必要があるか

誰でも確認できるべき
一部担当者のみ
普段は見る必要がない

ルールはいくつあるか

数個
数十
数百
数千

複数の式から利用するか

一つの式だけなら直接配列でもよい。

多数の式から使うなら、

名前付き配列
マスター表

に切り出す価値が高くなる。

Excel外部の人も確認するか

仕様確認やレビューが必要なら、シート上の表の方が強い。

25. 「見栄え」の問題だけではない

多段階IFが避けられる理由を、

数式が長くて見栄えが悪いから

だけにしない方がよい。

本質的には、

ロジックとデータが混ざる
仕様が見えなくなる
変更箇所が分散する
テストしにくい
差分を確認しにくい
再利用しにくい
意味を読み解く必要がある

ことが問題。

つまり、

可読性の問題というより、保守性と設計の問題

である。

26. 「式を読む」から「名前を読む」へ

名前付き配列を上手に使うと、

=XLOOKUP(A2,区分一覧,区分単価)

という式になる。

この式では数式を解読する必要がほとんどない。

自然言語に近く、

A2を区分一覧から探して、区分単価を返す

と読める。

ここでは、

計算式の可読性を、関数の短さではなく、名前によって上げる

という別の観点も出てくる。

27. 良い名前定義が重要

名前付き配列を使えば必ず読みやすくなるわけではない。

例えば、

=XLOOKUP(A2,a1,b1)

では意味がない。

一方、

=XLOOKUP(A2,商品コード一覧,商品区分一覧)

なら意味が明確。

したがって名前定義を使う場合は、

命名そのものが設計の一部になる。

28. XLOOKUPを使う価値

XLOOKUPを単なるVLOOKUPの新しい版として扱わない。

このテーマでは、

条件列挙を検索問題へ変換するための関数

として見る。

特に、

=XLOOKUP(

    検索値,

    検索配列,

    戻り値配列

という構造は、

入力 → ルール → 結果

をそのまま表現できる。

29. XLOOKUPの「戻り値配列」を活かす

XLOOKUPは単一値だけでなく、複数列を返すこともできる。

例えば、

=XLOOKUP(

A2,

    Master[ID],

    Master[[名称]:[単価]]

とすれば、一つの検索から複数列を返せる。

これは、

一項目ごとにIFを書く

という設計から大きく離れることができる。

そのため、XLOOKUP自体をLAMBDAの中へ完全に隠してしまうと、この柔軟性を失う場合がある。

30. モジュール化しすぎることにも注意する

例えば、

=MASTER.GET(A2,"単価")

は短くてきれい。

しかし、

=XLOOKUP(A2,商品コード,単価)

の方がExcel利用者には直感的な場合もある。

したがって、

抽象化すればするほど良いわけではない。

という視点も必要。

31. Excel Labsは「管理のための道具」と考える

Excel Labsは、

IFをXLOOKUPに変換するためのもの

ではない。

この記事の文脈では、

名前定義された配列やLAMBDAが増えたときに、それらを管理しやすくする環境

として扱う。

つまり、

ロジックを決定表化

↓

必要なら名前付き配列化

↓

名前定義が増えたらExcel Labsで整理

という順序で考える。

32. Excel Labsを前提にしすぎない

ここではここも注意したい。

本質は、

Excelの名前定義に配列を持たせる

ことである。

Excel Labsは、それを高度に管理するための補助環境。

したがって、

Excel Labsがなくても考え方そのものは成立する。

この整理をしておくと、記事が特定機能の紹介だけで終わらない。

33. 最終的には「ルールをどこに置くか」という設計問題

ここまで整理すると、この問題の中心は、

IFかXLOOKUPか

ではなく、

ルールをどこに置くか

という問題になる。

候補は、

1. 数式の中

2. 数式内の直接配列

3. 名前定義された配列

4. ワークシート上の決定表

である。

34. 4つの「ルールの置き場所」

数式の中

=IF(...)

特徴

ロジックとルールが同居する。

直接配列

=XLOOKUP(A2,{"A","B","C"},{100,200,300})

特徴

ルールをデータとして記述するが、式内部に存在する。

名前付き配列

=XLOOKUP(A2,区分一覧,区分単価)

特徴

ルールをシートから切り離し、内部データとして管理する。

シート上の決定表

=XLOOKUP(A2,マスター[区分],マスター[単価])

特徴

ルールをワークブック利用者へ公開する。

35. この4段階は抽象度の違いとも言える

数式に埋め込む

↓

直接配列として分離

↓

名前付き配列として分離

↓

シート上のデータとして公開

必ずしも下に行くほど優れているわけではない。

必要な可視性と管理方法によって選択する。

36. 実務で使える判断フロー

多段階IFを見つけたら、まずこう考える。

これは条件によって計算処理そのものが変わるか？

        ↓ YES

IF

        ↓ NO

これは「入力 → 結果」の対応表ではないか？

        ↓ YES

ルールは利用者が見たり変更したりするか？

        ↓ YES

XLOOKUP ＋ シート決定表

        ↓ NO

ルールは小～中規模で固定的か？

        ↓ YES

XLOOKUP ＋ 名前付き配列

↓

名前定義やLAMBDAが増えてきたか？

        ↓ YES

Excel Labs等で管理

この判断フローが、記事の実用的な結論になる。

37. 最終的な考え方

このテーマの価値は、関数の比較ではない。

本当に伝えたいのは、

**複雑なExcelを作らないためには、数式を書く技術だけではなく、

何を数式として持ち、何をデータとして持つかを考える必要がある。**

ということ。

多段階IFは、その境界が崩れていることを示す一つのサインでもある。

条件分岐なのか。

ルール検索なのか。

業務設定なのか。

内部実装なのか。

この分類ができれば、

IF
IFS
SWITCH
XLOOKUP
決定表
名前付き配列
LAMBDA
Excel Labs

を競合する機能ではなく、それぞれ異なる役割を持つ道具として整理できる。

そして最終的には、

数式を短くすることではなく、意味のある場所に複雑さを置くこと

が、Excel設計としての本質的な目標になる。

出典メモ

本記事は、ほえほえ作成の多段階IFとルール検索に関する整理原稿をもとに再構成しました。XLOOKUPや動的配列、名前定義、Excel Labsの利用可否はExcelの版と更新チャネルによって異なります。利用環境で機能の有無を確認してください。

参考: Microsoft Excel Labs（https://github.com/microsoft/Excel-Labs）