佐藤正美Tweet_20160101_15

佐藤正美 @satou_masami

書斎のなかで、一日中、考え事をしていると疲労困憊しますし、机に向かう気力の起こらない日々もあります。そういう状態になった時、もし、机に向かう事を止めたら、私の頭のなかで朧気に蠢いているけれど、はっきりとした形になっていない「怪物」は消え去ってしまい、再び現れないでしょう。

佐藤正美 @satou_masami

精神の疲労を癒すためには、いったん、集中している対象から離れて、ほかのことをやって気分転換すれば良いというふうに云われていますが、機械的な・単調な仕事のなかで感じる疲れに対しては、そういう気分転換は役立つでしょうが、頭を使った仕事では、そうはいかない。

佐藤正美 @satou_masami

「着想」という「怪物」を相手にしているので、「怪物」が生まれる感触を得ているならば、気分転換しないほうが良い。そうかと言って、「怪物」が直ちに生まれる訳でもない。やる気が起こらない時でも、机に向かうのが良いようです。そういう時には、以前に綴った文を読み返して推敲するのがいい。

佐藤正美 @satou_masami

「私は眠っていた。しかし。私の心は目覚めていた」（聖書）。疲れて、やる気の起こらないときでも、仕事の「渦中にいる」ということが大切でしょうね。やる気が起こらないときでも、つねに、対象と接していることが大切でしょうね。私は、みずからを戒めて、この文を綴りました（苦笑）。

佐藤正美 @satou_masami

「わたしは勿論失敗だつた。が、私を造り出したものは必ず又誰かを作り出すであらう。一本の木の枯れることは極めて區々たる問題に過ぎない。無數の種子を宿してゐる、大きい地面が存在する限りは」（芥川龍之介）。「物を創る」人たちは、この「悲しみ」を究極に宿しているのではないでしょうか。

佐藤正美 @satou_masami

読書も交際の一つでしょう。私は多数の書物を読んできましたが、様々な人たちから聞いた話を、なんとかして、自らの技術のなかに取り込もうなどという下衆（げす）い態度で、そういう人たちと会っている訳じゃないのであって、世の中には、数多くの考えかた・技術があることを知るのが愉しいのです。

佐藤正美 @satou_masami

セミナー講師は、音楽家に喩えれば、作曲家兼演奏家ですが、ほとんどすべての講師は、「或る主題による変奏曲」を作る編曲家です。「新たな主題」そのものを提示する講師は、ほとんど、いない。私がやりたい仕事は、「新たな主題」を作曲することです。

佐藤正美 @satou_masami

「新たな主題」を作る事が、どれほど「身の程知らず」かも、私は、重々、承知しています。しかし、私の性質が、それをやりたいと願い、そして、その仕事に対する力がないので、「意識と実力とのギャップ」は、セミナーが終わってから、虚無感として、私に復讐しているようです（苦笑）。

佐藤正美 @satou_masami

実力がないにもかかわらず、自惚れた意識を満たすためには、私は身を削って語るしかないのです。そして、虚無感に包まれて不眠に落ちる。

佐藤正美 @satou_masami

セミナーは、喩えれば、音楽会と同じで、演奏が終わって、聴衆が会場のドアを開けて帰路に着くとき、興奮さめやらないという状態にあるのが最良でしょうね。

佐藤正美 @satou_masami

私が読んだ「音楽家の伝記」によれば、モーツァルトのみが書き直しをしないでスコア（総譜）を書いた天才です。ベートーヴェンは、幾つかの断章（断片的な楽章を綴った物）を、しばらく、そのままにして、１つの構成を作るために、幾度も書き直しをしています。ベートーヴェンの天才にして然り。

佐藤正美 @satou_masami

着想というのは、一気に、形として、とどめるしかない。そして、頭から出てきて形にかった「怪物」を、そのあとで、次第に整える（推敲する）しかない。そして、最後には、一寸の狂いもない（自らの意識とズレのない）「作品」として整えるしかない。

佐藤正美 @satou_masami

「作品」には完成などなのであって、「完成」として見えるのは、実は、締切日があって、中断した状態にすぎないのではないか。

佐藤正美 @satou_masami

モデルとして現実的事態を記述する際には、少なくとも、以下の点を担保してほしい――（1）現実的事態を記述するシステム・エンジニアの認知力を前提にしない、（2）現実的事態をデータ構造に対応（写像）するための（システム・エンジニアの恣意性を排除した）関数。

佐藤正美 @satou_masami

TM（およびTM' ）は、正確に言えば、データ・モデルではない。データ・モデルとは、データ構造・データ演算・制約（integrity）の３つを備えた体系を云います。TM（およびTM'）は、データ演算を提示していないので、データ・モデルではない。

佐藤正美 @satou_masami

データ演算について、TM（およびTM'）は、現時点では、コッド関係モデルが提示した集合演算・リレーショナル代数演算を継承している。

佐藤正美 @satou_masami

技術力そのものが問われるエンジニアであっても、ユーザの反応を観て、技術の実現度（落とし所）を判断することが、はたして、良いのかどうか（エンジニアとして良心的なのかどうか）という点は、私には判断し難い。

佐藤正美 @satou_masami

エンジニアであるのならば、技術を非の打ち所のない状態で駆使することが使命であって、その技術を どのように納得するかという点は、ユーザの責任であって、エンジニアは、あくまで、現状の問題点に対して、技術を最大限に駆使してソリューションを示すのが職責であると考えることもできます。

佐藤正美 @satou_masami

同じ技術であっても、上手に使いこなすユーザもいれば、使いこなせないユーザもいます。技術の習熟度は、ユーザの責任であって、そして、技術を巧く使うように指導するのはコンサルタントであって、エンジニアの職責ではないと考えることもできます。

佐藤正美 @satou_masami

事業管理上の問題点は、そのソリューションを具現化する「技術」の観点からみれば、次の３点に集約できるでしょう――（1）「構造（管理過程）」のなかで起こっている矛盾点、（2）依頼者から提示された達成すべき目標、（3）ほかの事態（環境変化など）と対比した乖離点。

佐藤正美 @satou_masami

プロフェッショナルなDA（Data Analyst）であれば、モデル図を観て、管理過程の構造上の欠点を見て取ることや、依頼者から提示された目標を実現するために、構造を いかに変更すれば良いかを考えることは、そうそう難しいことじゃない。

佐藤正美 @satou_masami

ユーザにしてみれば、現場にいる「当事者」が、事の次第を一番に知っていうという自負を抱いているかもしれないのですが、「（管理過程の）構造上の欠点」を見て取ることは、なにも、現場にいることが必要条件になる訳じゃない。

佐藤正美 @satou_masami

「構造上の矛盾点」を改善することや、目標と実現するために「構造」を改良することは、いちいち、ユーザを説得しなくても、エンジニアが実現できる点です。とすれば、エンジニアが、（ユーザを度外視して、）みずからの技術を駆使して、管理の「構造」を改善することができます。

佐藤正美 @satou_masami

もし、そういう やりかた（エンジニア主導）に対して、ユーザが反感を抱いたとすれば、プロジェクトの進めかた（プロジェクトに関与している人たちが「同意」しながら、プロジェクトを進めるという やりかた）の論点であって、エンジニアの力量が問題視される訳じゃない。

佐藤正美 @satou_masami

どれほど すばらしい技術であっても、ユーザが反感を抱いたら、使ってもらえないと判断して、ユーザの反応を観ながら、ユーザが納得する同意点を妥協するか、それとも、ユーザが そういう技術を使わないというのは、組織管理の論点であって、エンジニアリングとは無縁であると考えるか、、、。