佐藤正美Tweet_20110601_15

佐藤正美 @satou_masami

モデルがたとえ現実的事態に対して爪痕ひとつ付けることができなくても、エンジニアが作成する物である以上、エンジニアリングのアウトプットでなければならないという ごく当たり前の心掛けを持っているはずなのだが、こんな当たり前の心掛けすら私は今日のシステム作りに見つけることができない。

佐藤正美 @satou_masami

ロジックは覚め切って鋭い物である、こういう事を単なる文芸的言い回しと嗤い去るのが、世間の SE の常識のようだが、この常識という習慣的・機械的な「思考の省略」に身を任せるくらい やさしい事はない。ぼんやりと仕事をやって年をとっていけば充分である。それを経験豊富だと思い込んでいる。

佐藤正美 @satou_masami

SE の描いたポンチ絵を私は観ていて、SE がそれを描いて何の得になっているのかいないのかという事を考える、大まかなことは描いてあるが、本人一体何の得になっているのかと。当の本人は、エンジニアリングを忘れて いよいよ SE としての経験を積んでいるつもりになっている（苦笑）。

佐藤正美 @satou_masami

「表現法の新しさや或る芸術味などだけによって価値のあるものは、すべて速かに古臭くなる」（A. フランス）。この言は、モデルについても云える。続々とモデルの新型が現れるが、一年たてば古物である。記法の「様々なる意匠」は現れるが、エンドユーザがもとめている物は果たして記法であるのか。

佐藤正美 @satou_masami

私は この歳になってやっと次の事がわかってきたように思う。それは SE にとってはモデルが単に自分の仕事の口実に過ぎず、モデルは いかに SE にとって真に技術として使われ難いものであるか、ということである。なるほど記法は簡単だが、モデルは難しいのである、意識を変えないかぎり。

佐藤正美 @satou_masami

私の仕事を振り返ってみれば、私のかつて犯した間違いは決して思考の過剰にはなかった、「事実」を黙殺して顧みぬ「概念」の過剰にあった。事業の真形を見極めるのを阻むのは、「概念」でいっぱいになった頭であった。頭が目を騙すのである。「事実」を観ないで記法を論じることは、私は もう飽きた。

佐藤正美 @satou_masami

30年前、DB 設計が SE たちの間で論じられた。当時の私には その論は正しいように映ったが、今はもう化石に映る。当時、minimal cover のデータ量は stable な構造を作ると云われたが、実際にはそうならなかった。「制約・束縛」の多様性を度外視したからである。

佐藤正美 @satou_masami

「（取引上の）制約・束縛」（constraints）は、○ や → で記述できやしない。しかし、それは、制約関数なので、モデル上、記述されなければならない。この点は、コッド関係モデルを実務に適用する ひとつの工夫点となる。いつまでデータ重複排除に恋々としているのだろうか。

佐藤正美 @satou_masami

私は通説に信を置かないエンジニアである。しかし、そういうエンジニアなみの倫理感は持っている。私は SE たちの真面目さを毛頭嗤ってはいないが、SE たちを惑わす「概念の欺瞞」に苦笑している。コンピュータの事業貢献を唱えつつ事業解釈の我物化を説く、それを錯乱と非難しているのである。

佐藤正美 @satou_masami

私はエンジニアなので数学の門外漢だけれど、エンジニアとして数学を学習していて、「気になる」数学者たちがいる──ツェルメロ氏・ゲーデル氏・チューリング氏は勿論だが、他にスコーレム氏が とても気になる。彼の技術・思想は、エンジニアたちの間で もっと探究されてしかるべきではないか。

佐藤正美 @satou_masami

モデルを作るうえで、「事」だとか「物」だとか 随分と いい加減なことを云っているを聞いてウンザリする。「形式化」になりゃしない。モデルと称するのであれば、少なくとも、構造のなかに「矛盾がない」ことを証明してほしい。それは、事業のコンピュータ化において、最初の要件ではないか。

佐藤正美 @satou_masami

事業を形式化するはずの SE たちがロジックに顔をそむけている。迂闊だからではない、自分たちの実感した思いを そのまま土台とした図を捨てきれないからだ。私は他人の実感を否定しないが（否定できる訳がない）、個人の実感を土台にしたがゆえ無意味なほど入り組んだシステムを見るに堪えない。

佐藤正美 @satou_masami

われわれエンジニアは、事業をコンピュータ化するのが使命であるが、われわれが仕事をはじめる時、まさに その時に、われわれは事業を判然とは知っていない。われわれが努めるべきことは、ありのままの事業を活写するという一事である。ありのままの事業、私はもうこの平凡な言葉を疑ってはいない。

佐藤正美 @satou_masami

ありのままの事業──SE は、モデル技術を持たなければ、この言葉について思い患う。SE が事業を解析するために必要なものは自分の視点ではない。ただエンジニアが我見を持たないように語りかけてくれる「真とされる『情報』」（ユーザ言語）と、それらの「情報」を形式化するロジックである。

佐藤正美 @satou_masami

事業解析について、或る SE は確たる物指しとしてベスト・プラクティスを持っていると信じているかもしれない、或る SE は何ものにもとらわれない自由なクラス図を作成できると信じているかもしれない。だが、かれらにそっぽを向いているのは、かれらがどう思おうが、「事業」そのものである。

佐藤正美 @satou_masami

セット概念とクラス概念は、数学上、それぞれ、ZF の公理系と BG の公理系で使われる概念なので、厳正に云えば相違する。しかし、エンジニアが実地のモデル作りで使うには、それらは同じと考えていい。だが、クラス概念をワンワンニャンニャン（哺乳類、犬猫）で説明するのは明らかな嘘である。

佐藤正美 @satou_masami

私は皮肉を弄するつもりはない。私は問題をもう少し注意深く眺めてみたいのである。SE たちがモデルをしきりと口にするが、モデルという言葉によって 誰が何を知ろうとしているのか、現実に 誰がモデルを読んでいるのか。モデル技術の論ではない、現実のモデルの持つ現実のユーザを考えてほしい。

佐藤正美 @satou_masami

エンドユーザは、ほとんどの業務分析図の実益のない事を実感している。だが、実益のない業務分析図が有害である事を意識していない。なぜなら、実益のない事に較べて、有害である事のほうがソフトウェア（プログラム）上の問題点になるからである。これはフェーズ化の最大弱点を暗示している。

佐藤正美 @satou_masami

モデルの規則作りで私が躓いたのが「ツォルンの補題」だった。モデルを扱うからには、勿論、私は「ゲーデルの不完全性定理」の論文を読んでいた、しかし、その底辺にされた補題には気づかなかった。彼は「周知の」補題と綴っているが、数学者には「周知」でもエンジニアには そうでなかった（泣）。

佐藤正美 @satou_masami

「ツォルンの補題」を知らなかった私は「並び」を一般帰納的関数（あるいは、閉包、特性関数および外点）で説明しようと苦労した。その苦労の中でスコーレム関数を学んだことは思いの外の収穫であった。が、「ツォルンの補題」を知っていれば、もっと早く、もっと鋭く、「順序」を意識していたと思う。

佐藤正美 @satou_masami

コッド論文を実務に適用する場合、何を配慮すればいいかを考えれば、私が論点にしたのは、「並び」と「null」であった。しかし、そんな論点など 30年前の話題にすぎない。その後の論点は、それらを配慮したうえで、「抽象データ型モデル」を いかに「技術」として整えるかという点にあった。

佐藤正美 @satou_masami

ｆ（（倉庫, 棚）, 商品） と ｆ（（倉庫, 棚）, （棚, 商品）） では、当然、事業が違う。しかし、いずれも、演算すれば「在庫」を導出できると考えれば大間違いだ。データを一ヶ所に集めておけば、プログラムで演算できると思っているとしたら、「抽象データ型」のモデルにならない。

佐藤正美 @satou_masami

「並び」を どうして配慮しなければならないか、次の違いがわかるかしら──ｆ（（生地, サイズ）, カラー） と ｆ（（生地, カラー）, サイズ）。この２つは、事業プロセスが違うのである。すなわち、それぞれ、「裁断→洗い」というプロセスと「洗い→裁断」というプロセスを示している。

佐藤正美 @satou_masami

「（導出的な）L-真」は、いくつも構成することができるが、「（事実的な）F-真」は一つしかない。それが、事業を分析するモデルの絶対の制約・束縛である。SE が でっちあげた観念など入る隙間はない。単純化して遠くから見たほうが構造がわかるって？ それじゃ犬も猫も同じに見えるわね。

佐藤正美 @satou_masami

どんな立場から事業を眺めようが、立場を意識しなければ抽象化できないのであれば、眼前には抽象化という仮面だけがある。事業のどこに一体 DOA 的構成や OO 的構成が内在するのか。どのような立場で事業を観ようが、事業の現実的事態は変わらない。ほんの少し遠近法を変えてみてはどうか。