佐藤正美Tweet_20110716_31

佐藤正美 @satou_masami

私には「属人性」という buzz-word が「我物化」という俗語に術語的化粧を施したにすぎないように思えた。「SE めいめいの知識系を頼りにするのはしかたがない」と云われる。しかし、ロジックに従って形式化することもエンジニアの仕事では同じように しかたがない事である。

佐藤正美 @satou_masami

現実的事態は一つの事実であり いかようにも「解釈」できる豊富な事実である。この豊富性のために、めいめいの SE は、それぞれ自分の視点で観ることができる、ということは めいめいの SE が自分たちの「解釈」に頼って事実を抽象しても、依然として他の抽象化もできることを意味している。

佐藤正美 @satou_masami

事業プロセス（事業過程）に対して「『意味』の伝達」プロセス（管理過程・組織過程）を考えてみても不都合はない以上、われわれは、管理過程・組織過程が示す「事業の『意味』」を繊鋭に分析しなければならない。だが、SE の忘れがちな事実はその先にある──つまり、分析は科学である、と。

佐藤正美 @satou_masami

ロジックの魅力とは、事業を分析することが「概念」を演算することであると明らかに意識させてくれる点に存する。事業分析では、思考と作図（図式）は一つの事であって二つの事ではない、作図が演算であることを意識させてくれる。「関係（関数）」とは、そういう性質である。

佐藤正美 @satou_masami

分析は個性的である──ここでいう個性とは、SE の視点のことではない、分析の対象たる事業のことである。事業分析は例外なく個体を対象とする──個々の事実を出来る限り正確に写像しようと努める。アプリオリ的真（恒真）ではない限り、最良の分析は、常に最も個性的である。

佐藤正美 @satou_masami

モデルは、事業の「意味」を常に最も正確に記述した図式である。モデルを作るロジックは非個性的だが、作られたモデル図は最も個性的な構造となる。その造型が現実の「意味」を明らめるからこそ、ユーザはモデルを信用する。彼らを現実に導かない表象の構造は、押し並べて非個性的である。

佐藤正美 @satou_masami

システムで目的を持たぬ造型はない。目的がなければ要件を定義できない。目的は事業支援にあるから、目的は事業に立ち戻る。エンジニアにとって目的意識とは、事業の形式化に外ならない。事業の形式化とはエンジニアの使命以外の何物でもない。この外にもし目的意識があれば、見掛けであろう。

佐藤正美 @satou_masami

いかなる事業（および企業）も その事業（および企業）特有の文化を持っている。しかし、それはあくまでも印象であり雰囲気であって、われわれが確かに眺め得る風景ではない。われわれエンジニアの眼前に確かな影像は、事業の「（形式的）構造」のみである。しかし、それは企業の文化を語りはしない。

佐藤正美 @satou_masami

管理過程という構造が事業過程という構造と その構造を同じくするということは──あるいは、事業過程は管理過程に従うということは──確かである。ふたつの構造は、総体的な写像関係にある。それらが崩れたときに、「管理のための管理」や「インフォーマル・システム」が産まれる。

佐藤正美 @satou_masami

管理過程は事業過程から借りたものを事業過程に返すにすぎない。管理過程が事業過程を動かすことが多いが、管理過程が事業過程に動かされることもある。「管理のための管理」とは、管理過程が事業過程から乖離した形式であるが、それは、モデル上、情報網の錯綜として顕然と露れる。

佐藤正美 @satou_masami

私は、SE たちが 彼らの知識系を以て事業を抽象化できるというような事を ほとんど信用していない。そして、彼らの抽象化した概念図が事業の問題点を あばき出すという事も ほとんど信用してはいない。彼らがどんな知識系を持っていても、彼らの頭脳は事業と同じ速度で考えるしかないのである。

佐藤正美 @satou_masami

「言葉の公共性」に「論理の公共性」を足すことによって事業は形式化できる。これらの言語（自然言語と形式言語）の二重の公共性を認める事がモデルの前提となるのである。そして、この前提は、それぞれの企業（事業）の豊富な個性を尊敬するという事である。ロジックは「意味」を変形しない。

佐藤正美 @satou_masami

いくつもの事業をモデル化したエンジニアの眼に見える像は、それぞれの事業が個性をもって あるがままであるという事である。エンジニアには、あらゆる事業が個性的であるという事と、あらゆるモデルが明晰であるという事は二つの事ではないのである。世の中に一つとして同じ事業構造はない。

佐藤正美 @satou_masami

モデルを作るエンジニアにとってユーザ言語をさしおいて事業の中に何物かを探そうとする事は妄想であろう。ユーザが事業を いかに観ているかは、彼らの言葉の使いかたに存するではないか。言語の使いかたが「意味」を指すではないか、そして、合意された「意味」の地盤を指すではないか。

佐藤正美 @satou_masami

モデルは、ロジックを使って事業の「意味」を出来るだけ忠実に写し出す。モデルは、事業を図式化した有向グラフである。SE が有向グラフを読めないというのは、それからなにがしかの「意味」を探ろうとするがためである。モデル自身が「意味」を表している。図式の裡に「何も隠されていない」。

佐藤正美 @satou_masami

言葉の「意味」は、言葉の使用という実践の中で──文脈の中で──示されるのであって、形而上学的に単独で立っている実体ではないのである。抽象化されたクラスを作るが、クラスそのものは証明にならない、証明の可能性である。したがって、クラスは、かならず、演算の項とされるのである。

佐藤正美 @satou_masami

クラスが演算の項になるのは当然だって？　では、あなたの描いたクラス図を もう一度観ていただきたい。そのなかで立てられた「関係」が正しいことを証明してほしい。「関係」の一つも見逃していない証明をしてほしい。それができないなら、クラスが演算の項になるのは当然などと云わないでほしい。