本記事は note で先行公開した記事を、加筆・再構成したものです。
はじめに：「ベテランしかできない」業務をどう書くか
業務改革の現場で、絶対に出てくる問いがあります。
「この判断、ベテランしかできないんです」
製造業の受注可否判断。介護のケアプラン作成判断。建設の工程変更判断。受託開発の要件追加判断。
——どの業界にも、「あの人がいないと回らない」業務があります。
新人に教えても3ヶ月かかる。マニュアルにしようとしても、ベテランから「ケースバイケースだから」と言われる。
——本当にケースバイケースなのか。
実は、99%のケースで、ベテランの判断は構造化できます。ただ、その「書き方」が間違っているから、できないように見えるだけです。
今日は、その正しい書き方——「ディシジョンテーブル」というツールについて書きます。
1. みんなが最初に使うのは「フローチャート」
「判断をマニュアル化したい」と思ったとき、ほぼ全員が最初に試すのは、フローチャート（またはディシジョンツリー）です。
たとえば、製造業の受注可否判断を、フローチャートで書いてみる。
[在庫はあるか？]
├── YES → [納期は間に合うか？]
│ ├── YES → [与信は大丈夫か？]
│ │ ├── YES → 受注OK
│ │ └── NO → 経理に確認
│ └── NO → 営業に確認
└── NO → [追加発注すれば間に合うか？]
├── YES → 営業に確認
└── NO → 受注NG
これ、最初の3条件くらいまでなら、綺麗に描けます。Visioでも、PowerPointでも、ホワイトボードでも。
でも、判断条件が5個、10個になると、絶対に破綻します。
なぜか。フローチャートは、条件が増えるたびに、構造を全部書き直さないといけないからです。
2. フローチャートの3つの致命傷
フローチャートで判断ロジックを書くと、こんな問題に必ずぶつかります。
致命傷①：ケース追加が「全部書き直し」
「VIP顧客の場合は、与信限度額を倍まで認める」みたいなルールを追加したい。
フローチャートだと、どこに「VIPかどうか」の分岐を入れるかで、構造が大きく変わります。
最上位に入れるなら、ツリーが2倍に膨らむ。途中に入れるなら、その下のツリーを全部複製する。
結果、ホワイトボードで描いた図を、全部消して書き直すことになります。
致命傷②：条件削除が「線のつなぎ直し」地獄
「在庫チェック」という条件を削除したい、というケース。
フローチャートで、真ん中の条件を削除すると、上の枝と下の枝を全部つなぎ直す必要があります。
これ、ホワイトボードでやると、矢印が交差して、何の図か分からなくなる。
PowerPointでやると、図形の整列が崩れて、見た目を整えるだけで30分かかります。
致命傷③：データベースで扱えない
これが一番大きい問題かもしれません。
フローチャートは「グラフ構造」です。ノードと矢印で表現される。
データベースに保存しようとすると、ノードとエッジを別テーブルで管理して、再構築のロジックを書く必要がある。
そして、フローチャートのままでは、CSVでもExcelでも、自由に扱えない。
専用ツール（Visio、bpmn.io、Lucidchart）が必須になります。
結果、「判断ロジックは、Visioで描いた図に閉じ込められたまま」になる。
Excelで管理している業務リストとも連携できない。AIに食わせて自動化を検討することもできない。
3. ディシジョンテーブル（DT）という解法
これらを全部解決するのが、ディシジョンテーブル（Decision Table、略してDT）です。
DTは、判断ロジックを表形式で書く方法です。
縦に条件を並べる。横にケース（パターン）を並べる。それぞれのセルにY（Yes）/N（No）を入れる。最後に、結論を書く。
たとえば、先ほどの受注可否判断をDTで書くと、こうなります。
| 条件 / ケース | C1 | C2 | C3 | C4 |
|---|---|---|---|---|
| 在庫あり | Y | Y | N | N |
| 納期OK | Y | N | Y | N |
| 与信OK | Y | - | - | - |
| 結論 | 受注OK | 営業確認 | 追加発注検討 | 受注NG |
これだけです。
判断条件3個に対して、4ケース（同じケースは1つにまとめる）が書けています。「-」は「どちらでも良い」を意味します。
「これ、フローチャートと何が違うの？」と思うかもしれません。違いは、変更コストです。
4. DTの強さ——変更コストの圧倒的な低さ
DTのすごさは、判断ロジックを変更するときに現れます。
ケース追加 → 列を1本足すだけ
「VIP顧客の場合は、与信限度額を倍まで認める」を追加したい。
DTなら、新しい列を1本追加します。「VIP顧客」という条件を縦軸に追加して、その列のセルに「Y」を入れて、結論を書く。それだけ。既存のケースの列は、一切触らなくていい。
条件追加 → 行を1本足すだけ
「天候による配送リスクも考慮したい」を追加したい。
DTなら、新しい行を1本追加します。「天候OK」という条件を行で追加して、各ケースに対してY/N/-を埋める。それだけ。既存の列は、関係する箇所だけ更新すればいい。
真ん中の条件を削除 → 行を消すだけ
「在庫チェックはもう自動化したから、人の判断から外す」を反映したい。
DTなら、「在庫あり」の行を削除するだけ。上下のつなぎ直しは一切不要。データ構造が完全に独立しているからです。
5. DTのもうひとつの強さ——データベースで扱える
DTは表形式なので、そのままCSVファイルにできる。
これは大きいです。判断ロジックをデータベースに保存できる、ということです。
CSVで管理できると、こんなことができるようになります。
- バージョン管理（GitやExcelで差分を追える）
- 一括変更（他のDTから条件をコピーできる）
- 集計・分析（「YESが多い条件は何か」みたいな分析ができる）
- AIへの食わせ込み（構造化された入出力を、LLMが読み取れる）
特に最後が大事です。DTで明示化された判断ロジックは、AIに引き継ぎやすいのです。
「ベテランの判断を、AIに代行させたい」という話、最近よく聞きます。でも、フローチャートで書かれた判断は、AIに渡すのが難しい。DTで構造化された判断なら、そのままLLMにプロンプトとして渡せる。
判断のAI化を考えるなら、まずDTで書く。これが王道です。
6. 比較表で整理する
ここまでの話を、1枚の表にまとめます。
| 観点 | フローチャート | DT（ディシジョンテーブル） |
|---|---|---|
| ケース追加 | 構造を書き直し | 列を1本追加 |
| 条件追加 | ツリー全体を再構築 | 行を1本追加 |
| 真ん中の条件削除 | 線のつなぎ直し（最も面倒） | 行を削除するだけ |
| データベース連携 | グラフ構造の中間処理が必要 | 表形式のまま扱える |
| 変更履歴の追跡 | ノード単位の変更が追いにくい | セル単位で追える |
| AIへの引き渡し | 構造変換が必要 | そのまま渡せる |
| 視覚的な分かりやすさ | 直感的（最初の3条件まで） | やや慣れが必要 |
最後の「視覚的な分かりやすさ」は、フローチャートに軍配が上がります。最初の3条件くらいまでなら、フローチャートのほうが直感的です。
でも、現実の業務判断は、5条件、10条件あります。そうなると、DTのほうが圧倒的に扱いやすい。
7. DTは「業務フローの菱形」を置き換える
ここで、業務フロー図に詳しい方は、こう思うかもしれません。
「業務フローの中で、判断は『菱形のゲートウェイ』で書くんじゃないの？」
その通りです。BPMNとかフローチャートの記法では、判断は菱形で表現します。
ところが、菱形だけでは、判断の中身が書けない。「在庫あり？」と書いて、YES/NOで分岐する、までしか書けないんです。
判断の中身——「在庫×納期×与信×VIPフラグの組み合わせで、結論が変わる」みたいな複雑なロジック——は、菱形の外側に、別途記述する必要がある。
そして、その「菱形の中身」を書くのが、DTの役割なのです。
つまり、業務フロー図とDTは、こういう関係になります。
- 業務フロー図：業務の「順序」を表現（誰が→何を→次に→次に）
- DT：業務フロー上の判断の「中身」を表現（条件×ケース→結論）
両方セットで、業務全体が表現されます。業務フローの菱形＝DTへのリンク、と捉えると分かりやすいです。
8. ベテランの判断は、表に書ける
最後に、もう一度この問いに戻ります。
「ベテランしかできない判断、どう書くか」
——答えは、DTです。表に書けます。
書けないように見える理由は、3つあります。
- 書き方を知らない（フローチャートで書こうとして失敗している）
- 条件を全部洗い出していない（ベテランは無意識に判断材料を使っている）
- ケースを全部考えていない（例外パターンを言語化していない）
DTを使うと、この3つを構造的に解消できます。
縦に条件を並べる作業を通じて、ベテランが何を見ているかが明確になる。
横にケースを並べる作業を通じて、判断の網羅性が確保される。
そして、書き終わったDTを見ると、ベテラン自身が「あ、自分はこういうロジックで判断していたんだ」と気づきます。これが、判断の言語化、判断の構造化、判断の継承の第一歩です。
9. JOARSなら、DTがすぐ書ける
JOARS（ジョアース）のフリープランで、DTがすぐ作れます。
業務棚卸表でFL5の判断点を見つけたら、その判断点に対してDTを紐づけて書く。条件追加・ケース追加が、ボタン1回でできます。
「ベテランの判断を、DTで書いてみる」——これだけで、現場のマニュアル化が一段階前に進みます。
まとめ
今日のまとめです。
- 業務改革の現場で、「ベテランしかできない判断」は必ず出てくる
- これをフローチャートで書こうとすると、必ず破綻する（3つの致命傷）
- ディシジョンテーブル（DT）なら、列・行の追加だけで済む
- DTは表形式なので、データベース、AI、バージョン管理と相性がいい
- 業務フローの菱形は、DTへのリンクとして捉えると整理できる
- ベテランの判断は、書けないように見えるだけ。DTで書ける
「FL階層」「Excel業務棚卸の限界」「ディシジョンテーブル」——同シリーズのこの3記事を押さえていただければ、業務改革の土台ができます。
あとは、実際に手を動かしてみてください。JOARSのフリープランで、自分の会社の業務を1本、棚卸してみる。
FL5の判断点を1個、DTで書いてみる。それが、業務改革の第一歩です。
JOAコンサルティングのご案内
株式会社ファインドルートでは、中小企業の業務改革・DX推進をご支援しています。「ベテランしかできない判断」をDTで構造化し、AI活用・継承・自動化に繋げる業務改革をご支援します。
- 業務棚卸を通じた判断ボトルネックの可視化
- 判断志向アーキテクチャ（JOA）に基づく業務フロー再設計
- DEM（判断進化マトリクス）による打ち手の優先順位付け
- 業務システム実装支援（生成AI・ノーコード・SaaS活用）
「うちの業務にも当てはまるか、相談してみたい」という経営者の方は、お気軽にお問い合わせください。
📩 お問い合わせフォーム
📺 YouTube「判断の進化チャンネル」（隔週更新）
本記事は、代表 佐野尚人のnote「判断の進化」マガジンで先行公開した記事を、HP用に加筆・再構成したものです。
note原典版はこちら：[ディシジョンテーブル vs ディシジョンツリー — なぜテーブルが勝つのか]