佐藤正美Tweet_20110801_15

佐藤正美 @satou_masami

事業の「意味」とは事業の実践に関して起こる問題であって SE の「解釈」において感知される問題ではないのである。事業上の問題は、常に先ずその実践の中で起こるが、われわれがもしモデルを構成するならば、この問題が実践の中のどの事態で起こっているかを「見て取る」ことができるのである。

佐藤正美 @satou_masami

エンジニアの仕事はあくまでも事態のアルゴリズムを構成する事であろう。エンジニアは、モデルを構成しながら現実的事態を把握するしかないのである。モデルを構成するという行為と そのアウトプットであるモデルの構造は切っても切れぬ。ロジックは最も厳正なる「現実」の把握法なのである。

佐藤正美 @satou_masami

概念図は問題の証明ではない、証明の可能性である。確かに「概念」が豊富であればあるほど、この可能性は豊富になる。しかし、概念図は、この可能性の一つにすぎない。しかし、私には、厳正に──かつ、生々しさで──構成されたモデルを観るだけで充分だ。証明式の中では矛盾・過不足が露れる。

佐藤正美 @satou_masami

言語使用を資料にしたモデル制作は、「概念」と「意味」とを隔てた言語上の技術的療治であるのか？　言語の使用法をもって証明可能性を実現できるのか？　恐らくここに最も本質的な意味で「理論」の問題が現れる。自然言語への論理適用という問題ではない、「『意味』の構成法」（理論）の論点である。

佐藤正美 @satou_masami

頭脳から「概念」を産み出す概念設計も、様々な事象からパターンを採掘したマイニング分析も認めないモデルにおける「項」とは、実体的概念ではないし、法則的関係のリストでもない。だが、言語の中へのロジックの正確な導入によるモデルは、SE の創造性がないという口実で回避されている。

佐藤正美 @satou_masami

言語の中への「論理」の正確な導入は、概念設計・論理設計を同時に実現する。モデルは、概念設計であると論理設計であるとを問わず、ユーザの日々の仕事のなかで通用している「意味」を記述する事に他ならないのである。形而上学的概念など一切ない。ユーザが使っている「意味」の写像である。

佐藤正美 @satou_masami

言語が「意味」を表す。このことを納得する時、言語の形態がユーザのあいだで通用している意味の根本的形式である。事業過程を支配するものは「事業の『法則』」ではない、ユーザが合意して規定した「意味」である。だが、このことを納得する事は、SE にとっては最も不便な事に違いないのである。

佐藤正美 @satou_masami

概念設計を好む SE は、言語分析を現実的事態の分析ではないとして嗤うかもしれないが、そういう SE の頭のなかにおいて、事業の「解釈」は、理論に貫かれた実践でもなければ、実践で験証された理論でもなくなっているのではないか。事態の「解釈」とは、「真とされる」値の充足の事である。

佐藤正美 @satou_masami

ユーザが合意した「意味」を写さんとして、私が前提として、眼前に生き生きとした言語以後には何物も欲しなかったという事を「コード至上主義」だと非難した SE がいたが、言語とは記号であって、これを意味論から眺めたら、記号の外側に立って記号の「意味」を験証する事は当然の事であろう。

佐藤正美 @satou_masami

ユーザが使う言語は合意された「意味」を伝えるが、言語が使われる生活様式の中に関与していない SE にとって、それは意味のわからぬ記号である。そして、この認識のズレは、ユーザ言語は事業の「意味」を伝えているという平凡な事実を忘れさせる、「事業を直に観ればいい」と SE は思い込む。

佐藤正美 @satou_masami

「形式と意味」を論ずるなら、少なくとも、（言語学で論じられてきた）オノマシオロジーとセマシオロジーを知っていてほしい。「事業を直に観ればいい」と云うなら、「観察参与（participant observation）」とは如何なる手続きであるかも知ってから論じてほしい。

佐藤正美 @satou_masami

「抽象データ型モデル」は、事態の翻訳可能性を扱う技術である。したがって、事業の「意味」を把握することを狙うのであれば、言い替えれば、事業をアルゴリズムにしようと考えるのであれば、事業の中で伝達されている情報（言語）を文字列とみなして形式化する事は当然のことではないか。

佐藤正美 @satou_masami

私は、「抽象データ型モデル」を重視するが故に概念設計を軽蔑しようとしたのでは決してない。ただ、エンジニアの職責として、事態の翻訳可能性を考えるなら、現実的事態の中に勝手な「意味」を持ち込むなと警告したいのである。現実の錯覚を起こす概念を SE が分析に持ち込むのは愚昧である。

佐藤正美 @satou_masami

「概念設計」というシステム設計の最初の段階で、要件を定義できるということを私は信用していない。要件が具体的に意識されるのは論理設計（と製造段階）である。「腹が痛い」という症状に対して、「それは胃潰瘍です、手術しましょう」と速断するような医者はヤブ医者であることは間違いない。

佐藤正美 @satou_masami

E.F. コッド氏──関係データベースの生みの親は、論理設計の理論・技術を評価されただけで、既に役の畢（おわ）った数学者として見做されている。私は、彼の不運を同情する寄り道はしないが、私には、彼のことを思い浮かべる事なく、「事業分析」（意味論）の科学性を考えることができない。

佐藤正美 @satou_masami

コッド氏の説（そして、ファギン氏・ウルマン氏による補強）の完備された構文論は、今もなお、シューベルトのロ短調の響きのように私には追憶される。彼は「設計を科学にした」。そのうえで、われわれエンジニアにとって、最も困難な・最も重大な点は、モデルの「解釈」（意味論）に存したのである。

佐藤正美 @satou_masami

モデルの意味論を考えるのであれば、数学では、スコーレム氏・レーヴェンハイム氏・ゲーデル氏・タルスキー氏を、哲学では、フレーゲ氏・ラッセル氏・ウィトゲンシュタイン氏・カルナップ氏・クリプキ氏を避けて通る訳にはいかない。それらの流れの中で、「意味」と「真」の相克が明らかになる。

佐藤正美 @satou_masami

紙の上に構成されたモデルという稠密な静物に対して、遙かに細緻な事業という活物が対峙する。この両者の写像を構成するのがロジックの翻訳可能性である。翻訳可能性を、或る尺度──そのあたりに落ちている物指し──で以て象嵌することは、事業（の意味）を正確に計算できない。

佐藤正美 @satou_masami

「概念」（文字列）の計算において、私は、パターンを借用しない、あらゆる先入観は無用（否、有害）である。事業の全体像（文脈）は、パターンの積み重ねではない、一つの命題は先の命題の反応として現れる。「意味」のこういう連鎖を前にして、「法則」という凡常な語は意味をなさない。

佐藤正美 @satou_masami

私は、ベスト・プラクティスを信じない、信じないためには私の頭脳は充分に言語的にできている。私は、ロジックを重視するが、事業の「法則」を信用するほど向こう見ずではない。事業の「個性」をいかなる場合にも軽視することができない。モデルは、個人の痕跡を持っていないが、「法則」ではない。

佐藤正美 @satou_masami

私が四十歳代で「Ｔ字形 ER法」を作った時には、私はモデル観を疎んじていた、だから「Ｔ字形 ER法」もモデルとしては御粗末であった。それ以来、今に至るまで私の学習した技術はロジック（数学基礎論）であった。ＴＭは、私が学習したロジックを底辺にしたモデル観の上に立っている。

佐藤正美 @satou_masami

モデル観としてロジックを意識するに至った私の眼には、「情報科学」は「モデルの存在性」を故郷にしている事実が写ったが、それを知るにはひどく回り道をした。が、「数学基礎論」のモデル論を信ずるには私の頭脳は余りに言語的であって、「概念設計」を信ずるにも、やっぱり言語的すぎるのだ。

佐藤正美 @satou_masami

私が五十歳半ばでＴＭを整えたとき、私のモデル観は確乎になった。それ以来、今に至るまで私のモデル観は「合意された語彙→導出的なＬ-真の構成→事実的なＦ-真の験証」の手続きの上に立っている。図式の前半は言語哲学的論点（合意→Ｌ-真）で、後半は数学基礎論的論点（Ｌ-真→Ｆ-真）である。

佐藤正美 @satou_masami

こういうモデル観を持ったエンジニアの思考は、常に二重であった──モデル規則の非個性を謳いつつ、事業の個性を謳う。私の狙いは、「法則」（あるいは、パターン）の獲得ではない、モデル（図式）を静物画の如く自足させつつ、その中に事業の「意味」を忠実に写す（組み立てる）事にあった。

佐藤正美 @satou_masami

私のモデル論は、言わば一種の「言語の形態論」の問題なのであり、このモデル論の主眼は、最も個体的な事業の最も個体的な「意味」を明らかにする点にある。私に重要なのは事業に対して適用する寸足らずな「法則」を発明することではない、事業の「意味」を正確に記述することだ。