（分岐と概念モデルの重要性を説明します）
１）樹枝状分岐
グリム童話のヘンゼルとグレーテルは道に迷います。
ここで、道に迷うことは、問題解決（出口への到達）に失敗することであると言い換えてみます。
こうした迷路には、色々な種類がありますが、迷路が樹枝状になっている場合には、ある分岐を間違えた場合、その先でどんなに努力しても、出口に到達することはありません。
出口に達するには、必ず間違えた分岐まで、戻って、正しい分岐に道をとりなおす必要があります。
カーナビで道を間違えても、間違えた地点まで戻らなければ、目的地に到達しない場合は、例外です。例外ですが、道が樹枝状になっていれば、必ず戻るしか方法はありません。
これは問題の解決方法は、問題の性質によって異なることを意味します。
学習をするときに、樹枝状分岐の学習モデルが当てはまる場合があります。
数学と物理学、特に、数学です。
語学や他の教科では、わからないところがあっても、とりあえず、そのままにして、先に進めば、そのうちに、わからなかった箇所が理解できるようになっていることがあります。
残念ながら、数学については、あるところで、躓くと、その先は全て理解できなくなります。
つまり、数学には、樹枝状分岐モデルが当てはまります。
コンピュータのソフトウェアとアルゴリズムも、数学の論理でできています。
ソフトウェアとアルゴリズムには、樹枝状分岐モデルが当てはまります。
ソフトウェアの分岐は、if文で表現されますが、if文を使う時には、分岐の条件を正確に設定しないと、バグが入ってトンデモないことになります。
問題の概略を説明して、説明していないことろは適当に判断して進めることは不可能です。
少なくとも、分岐の条件は正確に明示する必要があります。
これは、ソフトウェアの仕様書が厳密に書かれていないと、ソフトウェアがバグだらけで使い物にならなくなることを意味しています。
２）概念モデル
ソフトウェアの発注者が、ソフトウェアは、テーマを決めて、後は、よきにはからえといっても、受注者のプログラマは、仕様書に分岐の条件がかかれていないと、まともなソフトウェアはつくれません。
仕様書にはアルゴリズムを書く必要がありますので、数学的に厳密に書かれている必要があります。
つまり、発注者が数学的に厳密な思考ができないと、ＤＸは進めないことがわかります。
ここで、発注者が、数学的に曖昧（多くは数学的には間違っていて実現不可能）な表現をしている場合には、DXは永久に進まないことになります。
受注者は、ＤＸのソフトウェアは、アルゴリズムを数学的に厳密に再現する必要があると考えています。
発注者は、ＤＸのソフトウェアは、問題点を例示すれば、あとは適当につくってもらえると考えています。
つまり、受注者と発注者で、ＤＸのソフトウェアとは何かという概念モデルが異なっています。
ここでは、ＤＸの概念モデルにギャップがあります。
このギャップは、発注者が数学（アルゴリズム）を理解しない限り解消できません。
適当にソースコードを作れば、エラーだらけで、動かないソフトウェアになってしまいます。
このエラーはコンパイラやインタプリタが発生するもので、発注者のポストには関係しません。発注者が、総理大臣であろうと、誰でも、同じエラーが発生します。
数学の学習内容は、樹枝状分岐を形成していますので、俄か仕立てでは理解できません。
数学を習得した人が、リスキリングすれば、プログラマになれるかも知れませんが、数学を習得していない人が、リスキリングで、プログラマになることは非常に困難です。
1959年に、数学の学習を必須にしなければ、科学技術立国ができないといった人がいます。それが、スノーです。スノーは二つの文化という表現で、数学的に曖昧な文化と数学的に厳密な文化があること、数学のできない人は、科学技術が理解できないので、数学教育がコアになるエンジニア教育をすべきだと主張しました。
スノーは、数学ができないと、間違えた分岐に戻って、問題を解きなおすことができないので、問題解決は不可能であるといったとも解釈できます。
ＤＸを進めるには、まず、概念モデルのギャップの認識をスキップしては、先に進めません。
ここを曖昧にすると、数学的には、不可能な問題を時間をかけて検討することになります。
