2008年2月23日土曜日

"Un homme et une femme"


(以下は某所に送ったモノの転記)

「わたしは、この花が見たいのよ」ケータイで蘭の展覧会HPを見せる女。
「へぇ、きれいだね」
「花なんて、興味ないんでしょう?」
「そんなことないよ。来週は、ソコに行こうよ」
「ホント?連れてってくれる?行こうね!約束よ」
…そんな風に始まる男と女もある。

---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*---

ゲノム研究により、現在の人類の先祖の家系はどれくらいの数だったのかについて判ったらしい。その値は、1000。これは、ある任意の動物種が絶滅するかどうかの境界線でもあるそうだ。おおよそ 7 万年前の氷河期、コーカサス地方に 2000人程度の男と女が生き残った。その子孫が、現在の 60 億人を超える人類なのだそうだ。
言ってみれば、人類は“生物種のリブート”を行ったことがある生き物ということになる。自分たち以外のすべての動物からは“容易くエサにできる軟弱な連中”でしかないと見なされた条件下で生き延びた男女の子孫、それが私たちなのだ。

この知見から、最古の文明で律令や戒律とされていた事柄は完全に敵対的な環境下で人類という動物が守ることができた最小限の「ルール・セット」だったのだろうという説が法律学者・社会学者から提出されはじめている。
「七つの大罪」であるとか「十戒」であるとか、どんな原始的な部族も共通に確立しているタブーなどは、「人類をリブートするには、これより多くても少なくても失敗に終わる」厳密な検証を加えられたルール・セットの形式を今に伝えているということらしい。

丸山真男という日本の思想家の言葉にもあるように「法はグッドネスではない」。法やルールは、自然も含めたすべての環境のデメリットに対処しその時々の状況で定まる適切なコストで得られるメリットのすべてを獲得する課題に対する“プラン・行動・結果評価そして利益配分を行うシステム”である社会を破綻させないための「コード」でしかない。

システム屋の実感としては、「コード」しかもシステム自体のリブートに関わるようなクリティカルなコードは「少なければ少ないほど正しい」。また、効率的で柔軟かつ頑健なシステムを構築する際にもっとも頼りになる指針は「KISS (Keep it simple, stupid!:バカみたいに簡単にしておく。ただし、バカになりすぎないように)」ということになる。

20世紀の終わりあたりから、私たちは、社会システム向けコードを無駄に増やしすぎてはいないだろうか?
「自然」と名がつけば人体にやさしいものだと勘違いしていたり、運用しきれないほどの監視・防衛装置を購入・設置できることが安全や治安を確保する能力の証明になるとか、同世代の子供より抜きん出て秀でた点がない子供にまで「一律な高水準の教育」を長期間にわたって与えることが国際競争力を育むであるとか…

生き物としての生存や繁栄には不要なほどの“極端な富豪”を自動的に産みだすことを可能にした「グローバル化された市場経済」というメカニズムを20世紀中に構築した私たち人類は、そろそろ、こんな質問に答えることを迫られているのだろう:
   『ところで、その極端な富を確保するワザを、いったいナニに使う気なんだい?』
多分、7万年前と同質でクリティカルな状況で、私たちは「最小限の必須コード」を見つけ出
さなければならなくなるだろう。しかも、私たちの生まれついての性向からして、その「コード 2.0」を KISS のココロで構築するのでなければ、運用も維持もできないだろう。

私たちの目の前で現実になってしまった、この21世紀が「人類2.0」構築工程の始まりであるのならば、上々な出来の成果を残せると期待したい。

---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*---*---


「一番、やわらかい肉はシャトゥーなんだね?…では、注文は以上だ!」
「…なんだか、あれだけじゃ悪いみたい」
「そうかい?じゃ、彼をもっとよろこばせよう!
 ギャルソン!……部屋を注文する」
……♪ダァバァダ ダバダバダ、ダバダバダ♪
(from “Un Homme et Une Femme”: a film by Claude Lelouch)

2007年11月4日日曜日

自死に至るまで…

仕事場で自殺者が出ました。氏の御冥福を祈ります。


…提供したソフトウェアを、それを使用することでユーザが被ったいかなる被害に対しも、
  “無保証 (NO WARRANTY)”
であることを提供側も使用者側も失念してしまう。それが、システム開発に携わるものが陥る“死にいたる錯誤”なのだ。

  ソフトウェア開発プロセスが創り出しているのは著作物なのであり、製造物ではない。

“自分が消えてしまう朝”を迎える前に、この原則を外れた“現場の上長の指示”だの“業界内や社内での商習慣と内規”など踏みにじれ!
そして、より優れた著作物を生み出す根拠を自分自身で見つけ出すのを楽しもう!
根拠が見つけられずに迂回や逃げを選んだとしても、それも“一つの解”だ。
“自死”という停止コードに対して、今の私が出せる対処方式はコレだけだ。

Happy Hacking!!


URL-s FYI:
  ・ITPro: 開発現場のメンタルヘルス~事例から考える傾向と対策~
  ・ITPro: メンタルヘルスの必須知識を身に付けよう
  ・ITPro: 部下の「心の病」への正しい対処法

2007年9月15日土曜日

人道的な市場経済

市場経済というのが今のままではヒトに厳しいものなんじゃないか?と、言われています。
そこで、こんなことを思いつきました。

  ハゲタカをもうちょっと賢くすると人道的な市場経済になる。

どういうことかというと、ハゲタカ・ファンドは買い付けた企業の価値を上げて高く売り抜けなければ生きていけない存在なので、彼ら企業価値をあげるための手段を付け加えてあげれば、ダメ企業を市場にいてもダイジョウブそうな健全な企業に変えることが労働者や消費者にとって利益になるんじゃないかということです。

どんな知恵をハゲタカにつけるとよさそうか?

  買収した企業で雇用している人間を洗脳することを合法化する。

これです。企業がダメになってしまうのは、上から下までの人間が市場に適応できない認識・判断をするからに決まっています。ですから、市場に適応できる人間に洗脳してしまえば、まともな企業に自律的に変化するわけです。

  自社は売り払い、すべての幹部と従業員は洗脳を受け、市場に適応する人間へと成長する。

市場経済から不適応人間を削減しダメ企業を淘汰する。有能で健康で市場価値のある人間が棲んでいる惑星“地球”を効率よく作り出せるならば、市場経済は人道的になったといえるでしょう。

scholar google 検索「brainwashing」

2007年8月25日土曜日

アプリケーション開発の末端で入り用なものと不要なもの。

仕事場ではシステム・アーキテクトやシステム・アナリストの真似ごとをしています。
実際にやっていることは開発担体の情報処理業者や人材派遣業者からやってきているエンジニアたちが
 「ど~すればいぃんですか?」
と、訊いてくるアレコレについてまとまりのよいコード・ライブラリとそれを利用し応用プログラム作成方針の準備と報知でしかないわけですが。

最近になって、ふと、気づいたことがあります。それは、
 アプリケーションを作成したり改修しているエンジニアというのは、もはや不必要な(すくなくともパートタイマで充分なことでしかない)業種なのではないか?
ということなのです。

なぜ、アプリケーション・エンジニアのすべてを素人のパートタイマで置き換えてしまうべきだと、かんがえるのか?

私が出くわしてきた業務用アプリケーションにまつわる業務知識というのは特定のチューリング・マシンのプログラム・コードと同等なロジック記述でしかありませんでしたし、アプリケーション・プログラムを何年も使いつづけるために必要な柔軟性や頑腱性というのは状態遷移機械の実装の善し悪しのことでしかなかったからです。

業務知識を実装につなげるとは、ユーザ側のシステム部門が主体となって書き下す要件定義と、それを受けてインテグレータが書き下す機能設計レベルあたりの“仕様書”に記載された箇条書きや図表を“どのように読み下せばいいのか”についての手順を愚直に実装した専用チューリング・マシンを複数(多分、コンポーネント数の2, 3倍でしょう)つくり、箇条書きと表形式に載っている事柄をチューリング・マシンそれぞれのプログラム・テープに相当するデータ構造の初期化処理に変換するだけです。
柔軟性と頑腱性を両立させるには、トランザクション内容、ユーザ権限、ジョブ周期の違いなどなどの文脈に相当する情報に依存して実行時に変化するべき事柄を単に状態遷移機械として表現して先のチューリング・マシンに埋め込んでしまえばよいわけです。

ということは、開発にかかる前に要件定義と精精のところが機能分割程度までの検討を済ませ、そして仕様のどこをチューリング・マシン式を適用し、どれについては状態遷移機械で表現しておくのかの方式選定にユーザとインテグレータが納得してしまえば、業務コンポーネントであるとかビジネス・ロジック・レイヤなどと呼ばれている従来システムのコード量にして5%~10%程度のコーディング(チューリング・マシンと状態遷移機械を実装する作業)と多数のデータ初期化列の記述(仕様文書から機械的に変換しうる作業)を行うことが、アプリケーション開発であるべき姿になるのではないかと思うのです。

ユーザは、体感的に10倍近い無駄な人件費をシステムの開発や改修のたびに支払わされているのだと思います。そろそろ、プログラミング演習やロジック構築訓練をユーザ先でやっている/やらせているようなベンダ、メーカそして下請けをシステム業界から淘汰しないとマズイでしょう?

※ See Also: On Lisp (Paul Graham著,野田 開 訳)

2007年8月23日木曜日

誰もがすなる…

今様は、誰もがすなるぶろぐを、吾れもしてみむとてするなり。

・・・あちこちの日記サービスには思いつきであるとか気分といったものを殴り書いてしまいがちなのを省みて、
ここでは、推敲なんてことをしていこうというのが、はじまりのココロもちです。
そうはいっても、雑な文章も載せてしまうでしょうが、それも推敲していけたらいいなぁ、と思っています。