日々の破片

_ アマゾンが重いよ

複合機を買うことにした。ビックで買おうと思ったけど型落ち以外は意外と高いし、アマゾンかなぁと。

ギャンブルは1点、Macから両面印刷できるかどうかだけど。

追記：どうもギャンブルには負けたような気がするのは、○がどこにもないからだが。

_ 赤のつく言葉

以前、何か（多分スーパーがつく高田馬場のほうの出版社の雑誌とか、ろくでもないやつだろうけど）を読んでたら、多分（それにしても曖昧モコモコ）赤瀬川源平（字を調べるの面倒なんでこのままだったり）と南辛抱（仮名漢字変換しなおすのが面倒なんでこのままだったり）か村松（知らない）だかの対談があって、そんなかで、「昔取った赤柄」という言葉で全員が大爆笑してるクダリがあった。確か、よど号の柴田が捕まったころじゃなかったかな。

まあ、そういうツカもあるのを思い出したのでちょっと考えてみた。

たとえば、「赤気の至り」なんてどうだろうか？ 結構好きかも。

「君、以前、三里塚のあたりをうろついていたよね？」

「ええ、赤気の至りというやつですね」

とか。

で、この赤気だがツールとしては結構今でも使えなくもない。

赤気は本質的には2つの考え方からできている。

1つは、自然は矛盾を嫌うという考え方だ。したがって、矛盾があればそれを止揚するための方法が見つかるか、あるいは矛盾と見えるものがそもそも見方自体が間違っていることが原因なので見方を変えるか、のいずれかを採用するということ。

もう1つは、ある局面を下部構造と上部構造の2つに分離して考えることだ。上部構造は目立つし矛盾が明示されるのでつい本質的な解法を上部構造から見つけ出そうと考えてしまうが、そうではなく、上部構造の原因となった下部構造に本質的な問題を見つけようとすることだ。

これはツールだから赤いか黒いかは関係ない。

たとえばあるソフトウェアを開発しなければならないとする。しかも客は正しく動作するソフトウェアだけならいざ知らず詳細設計書と呼ばれる書類も欲しがっていると仮定しよう。矛盾は次の点だ。

・プログラムの実装詳細はプログラミングによって決定する。またプログラムの設計は実装によって明らかにされる。

・客はプログラムの実装前に詳細設計書と呼ばれる書類の提出を求めている。

これは正しく矛盾している。

まず考え付く正しい解決方法は、詳細設計書と呼ばれる書類がソースコードであることを客に納得させることである。しかし、多くの場合その試みは失敗するか、あるいはそれを説得させる工数を見積もるとやめておいたほうが良さそうだという結論となってしまう。したがって、これは矛盾を止揚する方法としては正しくない。

次に考えつくのは、どこかからコピペした空疎な書類を取り合えず出すことである。しかしこれは単に問題を先送りしているに過ぎず、止揚とはいえない。

ここで、構造分析に入る必要があるのは明らかである。止揚の試みがうまくいかないのは実は上部構造を見ているのが問題なのだ。

ではこの場合の下部構造とは何か？ それはソフトウェアのあり方そのものである。すなわち真の矛盾は実装設計と呼ばれるものとホンモノのプログラムが異なるという点にある。

したがって、正しい止揚は、詳細設計が実装となることである。つまりコード（直接バイナリーが吐けるのであればソフトウェアそのもの）の設計からの生成。

という点からは、MDAはまさに赤い赤い考え方だということが良くわかる。

そして、歴史が証明しているように、赤いものは結構うまくいかないもので（おそらーくキューバを例外として、と思われる反面、やっぱりキューバもという説もあるが）より古い問題としての独裁というものに転化してしまうのである。そうなると最後、みんなお腹を空かせることになってしまう。これはとってもまずい結果だ。

なんでこういうまずい結果になるかと言えば、それは構造分析が間違っているからで下部構造の規定に失敗しているからだ。

では、真の矛盾は何か？

それは、ソースコードも読めない人間が実装を知りたがることにあるのだ。読めもしないのに実装を知りたがるから自分でも読めそうな自然言語で記述された妙な書類を欲しがる点にある。

これは、製造業とは異なる。車を買う人間は一部の好事家を除き車の実装詳細なんて別に知ろうとはしない。テレビを買うとき回路図がついてきても大抵は捨ててしまう。

ところが、ものがソフトウェアになると突然、首を突っ込みたくなるのである。

これは産業としてまだ消費者が未成熟だということを意味する。

というと反論が来る。といってもシステムのお守りをするのはシステム部ですから。

おいおい、車が故障したら車屋に持っていくだろ？ 保守契約というビジネスをこちらはやっているのだから、ちゃんと金を払えばいいのだよ。そうすればお守りなんてしなくてもいいんだからさ。君らはユーザーの要望を吸い上げて、期待されるシステムのありようを計画立案するのが本来のミッションなんだ。

そう、今求められているのは、システム部の自己変革であり、単なるシステムのお守りから企業の情報戦略中枢への脱皮なのだ。革命なくして止揚なし。

#思いつきでヨタを飛ばすのもたいがいにしないと苦しいな。なんでこういう結論になるんだか。