I've got to admit it's getting better.
　　　　It's a little better all the time.

　　　　John Lennon (1940-80) British rock musician.
　　　　Getting Better,　(with Paul McCartney)

　
　　　　It is a stupidity second to none, to busy
　　　　oneself with the correction of the world.

　　　　Moliere (Jean Baptiste Poquelin: 1622-73) French dramatist.
　　　　Le Misanthrope,　�T:1

　
　Improve の語義は make or become better、日本語訳は 「改良」「改善」。「改良」「改善」 は、現状の悪いところを改めて良くすること （「大辞泉」）。「改良」「改善」 という ことば から私がうける印象は、「徐々に」「次第に」 変わってゆく進歩です──私の仕事 （システム・エンジニア 職） のなかで使う ことば で云えば、upgrade とか enhance とか version up ですが、（引用文の一番目が述べているように） 現状 [ 現状の設計思想 ] を様変わりするほどの急激な変更ではないというのが improve についての私の印象です。もし、現状から様変わりするような大幅な変更であれば、reform （改革） という ことば が ふさわしいでしょう。

　私は、25年以上にわたって モデル 技術 [ 事業分析・データ 設計のための モデル 技術 ] を作ることに専念してきました──40歳の頃に その仕事に取り組みはじめて現在も その仕事を継続して モデル 技術を改良し続けています。その仕事 （モデル 技術の改良） は上手くいったこともあれば しくじったこともあります。成功と失敗を いくども くり返して、少しずつ前進してきました。40歳から取り組んだ モデル 技術を 「T字形 ER法」 と名付けましたが、それを徐々に改良して──転換点になったのは 「論理 データベース 論考」 を出版した後ですが──、50歳の頃に モデル 「TM」 と名称を変更しました。名称を変更した理由は、「T字形 ER法」 を改革したのではなくて──実際、モデル 技術は ほとんど変更していない──、数学 (数学基礎論） の技術と見比べて TM の健全性・完全性を確かめたからです。そして、モデル TM は、「現時点で」 技術的に齟齬はない （健全性・完全性を実現している） という確信をもった。ちなみに、TM は、Theory of Models の頭文字を流用しました。

　数学の技術であれば、健全性・完全性を実現した時点で、ひとつの公理系として完成するのですが、事業分析・データ 設計のための モデル 技術は その対象が事業過程・管理過程なので事業環境の変化に呼応して つねに変転してゆくのが宿命のように SE の多くは思っているようです。確かに、事業環境の変化に対応して事業構造は変化してゆきます。しかし、事業過程を管理している管理過程は、そこで扱われている 「情報」 を記号列として扱えば、そして モデル が対象としているのは この記号列であるという前提に立てば、モデル は数学的技術と同様に構文論的健全性を実現した公理として規則 （文法） を整えることができる──論点になるのは、そういう構文論で生成された構造が実際の事業構造と一致するかどうかという点です。たとえ、モデル が健全性を実現していたとしても、生成された構造が実際の事業構造と完全に一致しないのであれば、モデル の構文論 （文法） を改良しなければならない。モデル 技術を作る システム・エンジニア は、この点を つねに注視して、生成された構造と実際の事業構造との一致を験証しなければならない──モデル 規則を実地に逐一確かめるのだから、存外 多大な時間を要する。モデル 規則が 「現時点で」 健全性・完全性を実現しているとしても、将来の事業環境の変化に因って、ひょっとしたら、現在の モデル 規則が表現し切れない構造が出現するかもしれない。

　モデル の対象として事業過程 （購買過程・生産過程・販売過程・労務過程・財務過程） についての管理過程 （購買管理・生産管理・販売管理・労務管理・財務管理） を前件 [ input ] にするのではなくて、事業過程そのものを対象とするのであれば、それは もう モデル ではない、なにか べつのもの （事業設計） でしょう。しかも、ひとり （あるいは、複数・多数でも） SE が事業の全工程を設計できる訳がない──その設計は現場で実際に作業している人々の仕事です。現場では作業するために様々な工夫がされている、この工夫は実際に作業している人々でなければ わからない知恵です。そういう工夫を SE が頭のなかで すべて 考え出すことができると思うのは （SE が そういうことを言うのであれば） SE の自惚れでしょう。

　我々は自分自身が関与していない仕事について、あたかも 簡単に改良・改善ができるように思いがちですが、ひとつの仕事は他の数々の仕事と関係をもっていて、しかも それらの仕事には他の仕事との関係のなかで種々の制約束縛のもとに今まで様々な工夫が凝られている。頭のなかで考え出した工夫には、これらの関係・制約束縛が考慮されていないことが多い──実地に仕事をやっていなければ わからない [ 気づかない ] ことが多い。そういう関係・制約束縛を無視 （あるいは軽視） した変更を導入すれば現場には混乱が生じて、現場の制度・手続きが破綻する。

　モデル 技術について言えば、ひとつの技術を新たに導入したり あるいは変更するために、数年を要することもある。数年を要する理由は、新しく加えた技術 （あるいは、変更した技術） が （今まで実現していた） 健全性・完全性を崩さないという理論的検証・実地の験証をしなければならないから。だから、見た目には牛歩のように遅々として進んでいないのですが、そうとうな努力が注がれている──しかも、それが失敗だったとわかったときには [ 健全性・完全性が崩れたと わかったときには ]、数年の努力が泡と化す。私は そういうことも幾度か体験しています。そして、成功しても、その後には保守 （改良） が いつまでも続く。モデル 技術を作ることは、それはそれで すばらしいことなのですが、作ることに較べて地味な保守 （適確な改良） は なかなか注目を浴びないけれど、私の体験から言えば、作ることに引けを取らないほど大切な （そして、しんどい） 仕事です。

　「改良」「改善」 されて落ち着くまでは 存外 時間がかかる。私の若い頃を 振り返ってみて、若い頃には、「改良」「改善」 を性急にやろうとする (あるいは、直ぐに できると思う） 傾向があるけれど、「改良」「改善」 のための段取り時間や それらの ききめ が現れる待ち時間を考慮していないことが多い。頭のなかで考えたものは具体性に乏しいので、細々 （こまごま） としたことは考慮外になってしまう。早出来 （はやでか） すという心が発 （おこ） る。頭のなかで考えただけの 「改良」 は、そんな所が そんなものにや。それが こじれると、社会を改良することが容易 （たやす） くできると考えてしまう。そして、改良のために費やす労力を いつのまにか 忘れてしまう。引用文の二番目は、そのことを戒めているのでしょう。仕事をしながら考えるのはいい、それは労働に工夫を与える。しかし、考えることを仕事にしないほうがいい、うっかりすると なにも生産していないのに なにか すばらしいことをやらかしているように誇大妄想するので。

　
　（2019年10月15日）