■ ファウラーたんからメールの返事がきた。

Domain Logic and SQL 翻訳してもええでーと。おし。がむばる。で、今度、妻と日本に行くんやけど（数週間滞在するんやけど）、妻は庭が好っきゃねん。庭見たいなあ。日本の庭。と。見たらええがな。

で、内Pよろしく、bliki_jaの題字を手書きで書いてもらうなり。その前に、どうやったら会えるかっちゅう話ではあるのだが。どこかがカンファレンス開くでしょう。きっと。どこだ？

■ Communitas ex Machina 〜創作の場を創出する〜

あとから

■ ＤＯＡ＋コンソーシアム設立記念講演開催

全体的に年寄りが多かった。40,50,60代って感じ。なんなんだこの年齢層。不気味だ。実際に開発してる人間たちじゃないじゃないか！ そいつらが「どもども」言いながら名刺交換している。ひとり私服で、居心地がヒジョーに悪かったことよ。

今回の話は、まず、essaさんによる「コンピュータの4つの文化」を読むといいと思う。それから読みつづけてくだされ。

偏見に満ち溢れた俺的歴史観

RDB 出現以前の1970年代、基幹システムのデータベースといえば、階層型やネットワーク型であった。これはつまり、データの物理的な構造をプログラマが知っておく必要があったということを意味する。言い換えれば、「大量の兵隊」による「力技」で何とかなった時代だ。essaさんの言葉を使えば、「メインフレーム文化」である。「兵隊は高度なノウハウは不要」で、「何か失敗しても影響が局所的ですむようになっている」。

ここに、今回のオッサンたちの考え方の源がある。

• どの兵隊を使っても、まったく同じことが出来る
• 何か失敗しても影響が局所的ですむようになっている

1980年、RDB の出現により、設計は「論理設計」と「物理設計」に分けて考えることが出来るようになる。そしてそれまで「兵隊」だった人間たちは、「勝ち組SE」と「兵隊プログラマ」に分かれていき、それぞれの役割を担うようになる*1。

ここでSEとなった人間たちは DOA という武器を携え、妙な象牙の塔に篭るようになる。コンピュータから離れ、エンジニアとしての心意気を忘れ、スーツと戯れるわけだ。

一方、兵隊プログラマたちは、より人間に優しい開発環境を求めるようになっていく。オブジェクトやコンポーネント、パターンやアジャイルだ。

それぞれ独自の文化を形成し始めるというわけ。

アーキテクチャとしての RDB は、その後も現在に至るまで、その形、設計方法、運用方法、なにひとつ変わらずに続いてきている。企業アプリケーションが RDB 中心だというのは、今から覆すわけにはいかない紛れも無い事実だ。

だが一方で、企業のビジネスモデルは変化を余儀なくされ、そのドメインをデータのみで定義するのは難しくなっている。1990年代以降、インターネットの普及により、それまでのデータの活用形では対応できない場面も徐々に増えてきた。おまけに市場ニーズは複雑化し、納期は短期化してきている。開発技術においても、設計技術においても、「オブジェクト指向」という技術が（以前からあったものだけれど）そういった時勢の流れに合わせて注目されるようになってきた。

しかも、かつて「兵隊プログラマ」だった者たちからだッ！ なんなんだッ！

それまで「勝ち組SE」だった者たちは面白くない。よーやく会社での地位を築いたのに、データ指向ではなく、オブジェクト指向だと？ オブジェクト指向なんて、「やる人によって違う結果が出るじゃないか」。そんな技術のどこがいいんだ。まあよい。そんなにオブジェクト指向言語が好きなら、よかろう。ワシらがこの「名刀：データ指向アプローチ」で設計する。お前らはそのわけ分からんオブジェクト指向とやらでで開発すればいいさ。

つまり、

DOA + OOP でいいじゃないか。

ということになるそうだ。

ええと……

バカめと言ってやれ*2。RDBの存在を否定はしないが、だとしても、どうしてそういう結論が出るのか。人間というのは、自分の立ち位置を離れたがらないものだよな。苦笑の連続であったことよ。

(株)データ総研 椿正明 代表取締役会長 による「OOへの質問」「OOの課題」が大変面白かったので、ここに全文を載せておこう。氏は読み上げるだけ読み上げて、詳しい意図をまったく説明されていなかったが、是非お聞きしたいものである。

OOへの質問

• ユーザーの情報要求（要件定義ではない）を個人差なくどう規定するか
  • 「IOが情報システムの製品である」としてよいか
  • 振る舞いまでもビジネスユーザは見るべきなのか
• オブジェクトを個人差なく規定する基準はどう規定するか
• 粒度の基準
• リポジトリ（概念メタ）のコンポーネントは何か
  • その構造は

OOの課題

• 概念データの発想が無い
  • 物理データしか考えないのでカプセル化して流通させる
• リソースデータの発想がない
• データベース通信場の発想がない
  • 通信はメッセージのみ？
• データ標準化の発想がない
• オープンにデータ流通範囲が広がることへの対策がない
  • 孤島システムを作る
  • 大規模業務アプリケーションシステムと取り組んでください
• IT/プラットフォームが変化することへの対策がない
  • 当該実装環境での実装を課題とするから？
• アートでサイエンスでない、名人芸を要求する
  • 概念でなくいきなりソフトを考えるから？

もうね。

■ ソフトウェアパターン第1回 勉強会

パターンという言葉に惹かれてやって来たが、どうにも思っていたものと違っていた。いかにも情報処理学会って感じ（って偏見だけど）。あ、おれはもういいです。