本記事は note で先行公開した記事を、加筆・再構成したものです。
はじめに：業務フロー図を整備しても、現場は変わらない
業務改革・DXのプロジェクトで、よくある光景があります。
業務フロー図を整備して、ITコンサルが入って、何百ページもの「現状フロー」と「あるべきフロー」のドキュメントが作られる。
経営者も「うちの業務がやっと見える化された」と満足する。
——でも、半年経っても、現場の苦しさは変わっていない。
なぜか。
実は、業務改革の本当の問題は、業務フロー図の中には映っていないことが多いのです。
問題は、フロー図の「箱と矢印」ではなく、箱と箱の間に挟まっている「判断点の中身」にあります。
今日は、その「フロー図に映らない地形」を読み解くための、二つの概念の接続を紹介します。
ひとつは、IT業界で20年以上使われてきた「SoR / SoE / SoI」という分類。
もうひとつは、私たちが開発しているJOAの中核概念「ICOM（アイコム）」。
この二つが、実は同じ地形を別の角度から見ていただけだった——という話です。
そしてその発見が、大企業でよくある「SAPを入れたのに業務が苦しくなる問題」の本当の正体を、論理的に説明してくれます。
1. SoR / SoE / SoI——エンタープライズシステムの3層
まず、IT業界の用語を整理します。
2011年、業界の重鎮ジェフリー・ムーアが、「Systems of Engagement（SoE）」という概念を提唱しました。
それ以前、エンタープライズシステムは「Systems of Record（SoR）」と呼ばれていました。
その後、データから洞察を導く「Systems of Insight（SoI）」も加わり、現在は3層構造で語られます。
| 種類 | 役割 | 具体例 |
|---|---|---|
| SoR（Systems of Record） | 事実の正確な記録、整合性最優先 | SAP、Oracle ERP、会計システム、人事台帳 |
| SoE（Systems of Engagement） | 人との対話・関与、文脈重視 | Slack、Teams、コラボツール、CRM |
| SoI（Systems of Insight） | データから洞察、予測、推論 | BIツール、AIアシスタント、予測分析 |
ここまでが業界の常識です。
2. ありがちな誤解——「これは入力UIの違いでしょ？」
私自身、ずっと、この3層分類を「入力UIの違い」程度に理解していました。
- SoR：プルダウンとかラジオボタンで、決まった値を選んで登録する
- SoE：自由記入のテキストボックスにベタ打ちで書く
- SoI：データを集計してグラフで見る
確かにそういう側面はあります。
でも、それだと「業務フロー（仕事の流れ）には影響しないんじゃないか？」と感じていました。
同じ「与信判断」業務をSoR的に作ろうがSoE的に作ろうが、フロー図の形は同じになるはず、と。
実は、ここに大きな落とし穴がありました。
3. 本当の影響先は「業務フロー」ではなく「判断点の中身」
ここで、JOAの中核概念「ICOM」を導入します。
ICOMは、業務の中の「判断点」を分析するための4要素です。
- I（Input）：判断の入力——何を見て判断するか
- C（Control）：判断の制約——どんな基準・ルール・経験で判断するか
- O（Output）：判断の出力——何が決まるか
- M（Mechanism）：判断の実行手段——誰が、どんな道具で判断するか
JOAでは、業務の中の判断点を一つ一つ、このICOMで解剖していきます。
そして——SoR/SoE/SoIの違いは、業務フローの形ではなく、このICOMの中身の性質に現れます。
| ICOM要素 | SoR的判断点 | SoE的判断点 | SoI的判断点 |
|---|---|---|---|
| Input（入力） | 構造化データ（コード値） | 文脈情報、相手の反応 | データセット、予測スコア |
| Control（制約） | 明文化された規程・閾値 | 暗黙知、経験則、関係性 | 仮説、分析フレーム |
| Output（出力） | 確定値 | 合意、共有理解、次アクション | 洞察、推奨、確率値 |
| Mechanism（実行手段） | システム・自動化 | 人、会議 | アナリスト、AI、BIツール |
ICOMという同じ枠を埋めても、中身の性質が根本的に違う——これが、SoR/SoE/SoIが業務に与える本当の影響です。
4. 具体例——「与信判断」を3パターンで書いてみる
抽象的なままだとピンと来ないので、「与信判断」というありふれた業務で見てみます。
SoR型の与信判断
信用情報照会 → スコア取得 → 閾値判定 → 可否確定
直線的、ゲートウェイ1個、自動化可能。フローはきれいに描けます。
SoE型の与信判断
顧客ヒアリング → 過去取引履歴の解釈 → 営業判断 → 上長相談 → 可否判定
往復ループが多発、並走、人の関与が中心。同じインプットでも担当者・文脈で結果が変わる。
SoI型の与信判断
AI予測スコア取得 → 外れ値検知 → 人による説明性レビュー → 可否
分析タスクと人の解釈が交互、モデルへの問い合わせが内在。
同じ「与信判断」という業務でも、SoR/SoE/SoIで業務フローの形状はまったく違う。
そして、これらの違いは、業務フロー図（BPMNと呼ばれる業界標準のフロー記法）を描いてみても、見た目には差が出にくいのです。
なぜなら、SoE型業務の「往復」「並走」「滞留」「認識合わせ」といった暗黙の動きは、フロー図には描かれないからです。
5. SAP入力地獄の正体——判断性質とシステム性質のミスマッチ
ここからが、この記事の核心です。
業務改革の世界で20年以上聞かれ続けている話があります。
「SAPを入れたのに、現場が入力地獄で苦しんでいる」
何百億円もかけてSAPを導入したのに、試作部門・営業部門・カスタマーサポート部門が「無理やり入力させられている」と悲鳴を上げている。
これは、私の師匠的存在の業務改革コンサルが、ある製造業大手の現場で実際に出会った光景です。
ICOM × SoR/SoE/SoI の枠組みで分析すると、何が起きているかが論理的に見えてきます。
| 観点 | 内容 |
|---|---|
| SAPの性質 | SoR前提（マスタ厳格、伝票確定、整合性最優先） |
| 試作業務の性質 | SoE寄り（試行錯誤、仕様可変、暗黙知多い、往復多発） |
| 発生している問題 | SoE的性質の判断点を、SoR型システムで処理しようとしている |
つまり、ツール選定の善し悪しではなく、判断性質とシステム性質のミスマッチが起きている。
JOAで分析する流れはこうです。
- 試作判断点をICOMで解剖する
- Control（基準）が「暗黙知」、Input（入力）が「文脈情報」、Output（出力）が「次アクションの合意」と判明
- これはSoE型判断点だと特定できる
- なのにSoR型システム（SAP）で処理している → ミスマッチ
- 処方箋：SAPから該当業務を分離し、SoE型ツール（Excel・Notion・自社内製ツール等）に切り出す。必要箇所のみSAPと連携
「SAPがダメ」「現場が悪い」という話ではなく、「SoE的判断点をSoR型システムに無理やり入れているのが原因」だと、論理的に説明できる。これがJOAの分析の価値です。
6. なぜ業務フロー図では見えないのか
ここで、冒頭の問いに戻ります。なぜ、業務フロー図を整備しても、現場の苦しさが変わらないのか。
答えはシンプルです。
SoR/SoE/SoIの違いは、業務フロー図の「箱と矢印」には現れないから。
| 影響レイヤー | SoR/SoE/SoIによる差 |
|---|---|
| フロー図の形（箱と矢印） | 大きく変わらないことが多い |
| フローに紐づく判断点の中身（ICOM） | 性質が根本的に違う |
| 判断点のロジック（DT：ディシジョンテーブル） | DTは書ける（JOAの基本ルール：1判断点・1DT）。違いは条件判定者（システム／人／LLM／AI分析）が誰か |
| フローの実行時挙動（ループ・並走・滞留） | 見えない部分で大きく違う |
業務フロー図は、フローの「形」しか描けません。フローに紐づく判断点の中身、判断のロジック、暗黙の往復・並走・滞留——これらは、フロー図の外側にあります。
だから、業務フロー図だけ整備して終わる業務改革は、本当の問題に近づいていないまま、半年が過ぎてしまうのです。
7. JOAがICOMまで降りる理由
ここまで来ると、JOAというフレームワークが「なぜわざわざ判断点をICOMで解剖するのか」が見えてきます。
業務フロー図の上から眺めているだけでは、SoR/SoE/SoIの違いは見えません。フロー図を一段降りて、判断点ICOMの中身まで解剖することで、初めて「この業務に合うシステムは何か」「どんな打ち手を当てるべきか」が見えてきます。
そして、これは私たちのもう一つの中核概念DEM（Decision Evolution Map）とも結びついています。
- ICOMで判断点を解剖
- DEMで判断点を「環境変動性 × 価値創出源泉」の4象限にマッピング
- 判断性質に応じた設計成果物（DT・観点表・事例集・実験条件）を選ぶ
- 必要なシステム性質（SoR/SoE/SoI）を判定する
業務改革は、業務フロー図で終わるのではなく、判断点ICOMの解剖まで降りることで、ようやく本当の地形が見えてくるのです。
8. 知の合流——独立に発展した二つの概念が出会った
最後に、もう一つ書いておきたいことがあります。
「ICOM」と「SoR/SoE/SoI」は、もともと独立に発展した概念です。
- SoR/SoE/SoI：2011年のジェフリー・ムーアから始まる、IT業界の蓄積
- ICOM：私たちがJOAの中で、業務改革の現場経験から組み立てたもの
それぞれ別の地平で発展してきたのに、両者をテーブルに並べてみると、見事につながりました。ICOMの中身を見れば、その判断点がSoR/SoE/SoIのどれにあたるかが判別できる。逆に、SoR/SoE/SoIで分類された業務は、ICOMで解剖してみないと本当の中身がわからない。
独立に発展した知の合流点を見つけられると、自分たちのフレームワークが業界の地平とつながっていることが確認できて、研究者上がりの私としては、なんとも嬉しい瞬間でした。
まとめ
今日のまとめです。
- 業務フロー図を整備しても、業務改革の本当の問題は見えないことが多い
- 業務フロー図の「箱と矢印」の外側、判断点の中身（ICOM）に、本当の地形がある
- SoR/SoE/SoIの違いは、業務フローではなく、ICOMの4要素の中身に現れる
- 「SAP入力地獄」は、SoE的判断点をSoR型システムで処理するミスマッチ
- JOAが判断点をICOMまで降りて解剖するのは、この見えない地形を可視化するため
- 独立に発展した「ICOM」と「SoR/SoE/SoI」は、見事に補完しあう関係だった
業務改革で行き詰まっている方、業務フロー図は整備したのに何も変わらないと悩んでいる方、ぜひお話を聞かせてください。
問題は、たぶん、業務フロー図の中ではなく、フロー図の中に挟まれている判断点の中にあります。
JOAコンサルティングのご案内
株式会社ファインドルートでは、中小企業の業務改革・DX推進をご支援しています。業務フロー図の整備で終わらせず、ICOMによる判断点解剖まで降りた業務改革をご支援します。「SAP入力地獄」のような判断性質とシステム性質のミスマッチ診断もご相談ください。
- 業務棚卸を通じた判断ボトルネックの可視化
- 判断志向アーキテクチャ（JOA）に基づく業務フロー再設計
- DEM（判断進化マトリクス）による打ち手の優先順位付け
- 業務システム実装支援（生成AI・ノーコード・SaaS活用）
「うちの業務にも当てはまるか、相談してみたい」という経営者の方は、お気軽にお問い合わせください。
📩 お問い合わせフォーム
📺 YouTube「判断の進化チャンネル」（隔週更新）
本記事は、代表 佐野尚人のnote「判断の進化」マガジンで先行公開した記事を、HP用に加筆・再構成したものです。
note原典版はこちら：[業務フローを見ても見えない問題の正体 — ICOMとSoR/SoE/SoIの接続点]