佐藤正美Tweet_20110816_31

佐藤正美 @satou_masami

ユーザ言語を資料にして事業を観るというのは、事業を観るに、どんな視点から観るかという事を必要としない、エンジニアが自分の視点の自由度を選ぶ事ができない。モデルにとって対象は、SE の「概念」によって造型されるのではない。ユーザ言語が記述している諸風景が「意味」そのものなのである。

佐藤正美 @satou_masami

エンジニアの「概念」が最も重大な意味を持つ時は、現実的事態を変更するための（ソリューションの）手段となる時である。現状調査は「概念」による変形を許さない。形式化された事業構造は、正確に記述されて独立した対象となって、独立した表現（分析対象）となって姿を現す。

佐藤正美 @satou_masami

そこに表現されている物は、形式的構造だが非個性的ではない。一種の個性だが、ロジックが貫いている。エンジニアが形式化した事業の諸風景だが、エンジニアの象嵌した概念は一切ない。ロジックの文法がそこに最も簡明に結晶化されている。ロジックが汎用的性質を持つ所以である。

佐藤正美 @satou_masami

SE が「概念」の過剰による表現で、事業のあるがままを曇らせるという事は滑稽な事であろう。SE が「概念」を自由に作っても、「概念」の使用は、現実的事態に対して真実性（虚構・隠蔽・改竄の拒絶）を問われる。文「雪は白い」が真であるのは、雪が白いとき、そして、その時に限るのである。

佐藤正美 @satou_masami

エンジニアにとって形式化は自分の技術の具体化である。エンジニアにとって、事業を抽象化して眺める必要はないし、自分の才識の造型性に頼る必要もない。事業の現実を「解釈」して眺める必要はないし、自分の印象風景を描いてみる必要もないのである。モデルは事業と密度を同じくする。

佐藤正美 @satou_masami

エンジニアは、抽象データ型モデル（言語に依るモデル化）を読んで事業の「意味」を知るであろう。それはユーザの強固な言語が事業を記述しているからだ。読めない SE がいるとしたらそれは業務知識が欠落しているからではない。SE の頭脳の中に泥土のように堆積した観念が でしゃばるからだ。

佐藤正美 @satou_masami

観念的な SE を現実的に・具体的に事態を観るようにするのは難しい事なのである。「概念設計」を好むSE たちに「概念」がしばしば（事態の）本質と間違われる所以であり、「概念」は様々な事態を抽象化し、手に入れた一つの法則の如く錯覚される所以である。事業運営は自然法則に若かない。

佐藤正美 @satou_masami

専門家が専門的用語を発明してゆくのは当然の事であって専門的用語は常に「URL の短縮形」のような役割を演じている。だが、SE たちの間では、事業の構造表現を、その「意味」の伝達性をパターン化するために「概念」が使われているのではないか。類似的「概念」を以て事業に足枷をはめている。

佐藤正美 @satou_masami

関係主義では、「（存在の）指示」は、「文脈」を前提にした全体論的な「『解釈』の内部（from within）」からしか確定できない。すなわち、モデルの外側に形而上学的な（絶対的な）「真」が存在している訳じゃない。確たる「文脈」がわからないで「意味」をわかる訳がない。

佐藤正美 @satou_masami

一つの形式的構造の無矛盾を証明するには、公理系を前提にするしかない。「（導出的な）Ｌ-真」を先ず構成するしかない。いっぽうで、「個体」を定義しようとすれば、無限後退（切断の無限）に陥る。「（導出的な）Ｌ-真」を構成して「（事実的な）Ｆ-真」を験証するのがモデルの一般手続きである。

佐藤正美 @satou_masami

関係主義と実体主義、この二つは私を常に悩ましてきた。関係主義では、個体を変項として扱い、変項の値が一義に決まるアルゴリズムがあるという定義法に立つ。この定義法では、次の事態を説明するのが難しい──「商品」（という継続的存在）が「注文」（という生起的事態）に関与する（侵入する）。

佐藤正美 @satou_masami

「概念設計」において使われている「意味論」と称する様々な図法が「構文論」を前提にしていないのを観て私は大変遺憾に思う。われわれは、時空の或る状態のなかでのみ個体の存在を認識できるのだから、「内容（意味）」は「時空形式（文法）」に依存すると考えるべきであろう。

佐藤正美 @satou_masami

モデルを事業のプログラミングとして認める以上、実践的な手続きを除いてはモデルについて一言も語る事はできない。すなわち、モデルは、「一般手続き」なのである、種々様々な「概念」を羅列した図ではないのである。ユーザが言語で伝えている「（事業の）意味」の形式的構造がモデルである。

佐藤正美 @satou_masami

SE たちが事業を眼前にして、事業の総体（文脈）を掴みあぐんでいるという事は簡単に推測できる。「概念図」と称する、捉え所のない「概念」を使った表現と、それらを羅列した脆弱な論理仕掛けを観れば、顕わである。それはメモとしては立派だが、モデルと称するには子どもじみている。

佐藤正美 @satou_masami

「概念図」と称する図では、SE の象眼した「概念」がのさばって来るばかりだ。一体、何故に SE たちはユーザ言語を無視するのか。言語は文字列としてモデルの入力になると考えて決して障りがないではないか。言語を「形式」と考えようが「意味」と考えようが、言語は依然として文字列である。

佐藤正美 @satou_masami

事業を分析している時に、「（モデルの）文法」を云々されては堪らないなどという的外れな都合のいい考えは、自らの理屈だけを言い立てる仲間内でしか通用しない。事業をシステム的に分析しているのであれば、「文法」を前提にするのは当然であろう。中途な分析をシステム的とは云わない。

佐藤正美 @satou_masami

「意味論」を奉ずる SE たちにとって「構文論」は論点にならない。論点になったら、ああいう図は描けないであろう。論点に何故ならなかったかと云えば、概念図は事業の範疇であると信じたがためである。何故そう信じたか、「概念設計」とはコンピュータに対する戦略であると考えたからである。

佐藤正美 @satou_masami

では、コンピュータに対する戦略とはどういう中身であるのか。戦略を論ずるのであれば、事業の総体（文脈）を「正確に」知っていなければならないはずである。だが、まずい事には、コンピュータ化の最初の段階で、大雑把な概念図がトップダウン法であることを先ず信じるように要望されている。

佐藤正美 @satou_masami

私は、現実的事態を把握していないような戦略などに信用を置かないエンジニアである。先ず戦略──なるほど、現実を考慮していたら、事業の「本来的に中枢な」物を想像できないし、トップダウン法の有難味がないという訳だ。だが、事業の「本来的に中枢な」物を誰が知っているのかしら。

佐藤正美 @satou_masami

SE は、「数学基礎論」のモデル論を読んで論理の威力を意識するであろう（あるいは、皆目理解できないかも）。だが、SE は、モデル論を理論としては正しいが実際問題としては使えないと言い立てるだろう。しかるに、理論として正しくて、実際に使えないという「整合的な」理論などはない。

佐藤正美 @satou_masami

「理論としては正しいが、実際に使えない」という言いかたは、「私は、それを認めたくない」と言っているのと同じだ。しかし、エンジニアリングは、一人の才識を多数派にするなんていう無法な事ではないのである。モデルは、現実を写像する単純な技術であるが、理論に遵った周到な技術である。

佐藤正美 @satou_masami

モデルを作成する技術は単純な技術であると覚ることは大事だが、モデルを簡単に作成できると考えるのは単純すぎる。モデルの文法に遵えば、「L-真」構成を作ることはできるが、「F-真」構成を作るのは そう簡単な事ではない。モデルは事業に照応した座標を持っていることを忘れないでほしい。

佐藤正美 @satou_masami

事業を観察して得た幾つかの表象を並べれば事業構造を大まかに記述できる、というようなケチ臭い自意識ではモデルの文法なんか分かりゃしない。SE の造型力を云々していては駄目なのである。ユーザ言語という あるがままの記号（文字列）が SE の意識の機能にならなければ駄目なのである。

佐藤正美 @satou_masami

SE たちが DOA だとか OOA だとか云って睨みあっているのは実に依怙地な話であろう。自然法則でもないような手続きを握りしめているのは滑稽であろう。「放てば満つ」（道元禅師）──私は、ただエンジニアでロジックを持っているだけで事業を形式化するのに不足はしない。

佐藤正美 @satou_masami

紙上に記述されたモデルという離散的な静物に対して、遙かに稠密な事業という活物が対峙する。この両者の写像を構成するのがロジックに依る翻訳可能性である。翻訳可能性を、SE の「概念」造型力あるいは「法則的」パターンで以て象嵌することは、事業（の意味）を正確に構成できない。