日々の破片

_ 4/4

「わかった、わかった、どうせオレの名前はロシア系で、ここじゃあイカしてないよ。で、そういうお前さんの名前は？」

「……」

「で、そういうお前さんの名前は？」

「……」

「もったいつけるなよ」

「……ヨ」

「ヨ？」

「……ヨーヨー」

「……（激笑）……ヨー……ヨー！（激笑）」

「……そーだよ、ヨーヨーだよ。文句あんかよ」

――記憶の中のナイトオンザプラネットから引用

_ 歴史と権限委譲

歴史が進むと権限委譲も進む。本当か？

かって権力は王にあった。今では民にある。

複雑化した権力を1人がさばくのは、建武の親政（だよな、意味的に）の時代ですら無理だったことは歴史が証明している。絶対的に1人では処理できないからだ。それは国家が肥大化したからだ。10人の村落なら1人の村長がすべての政務をさばけるだろう。100万規模になったら1人でさばくことは不可能だ。それは、後醍醐の夢想（たった一人の権力者がすべてを支配しようという下劣な妄想だ）とは無関係な現実的な必要性の問題だ。

かって設計は設計者にあり、今ではプログラマにある。

設計→実装→検証 というサイクルを分散したほうが効率が良いからだ。

その頃（分業の時代）は、プログラマとコーダは別物と考えるとわかりやすい。言葉の違いは役割の違いだ。

コーダは、設計をコードに落とす人で、プログラマはプログラムを作る人だ。コーダは多少気の利いたプログラム言語と仕様書の翻訳機に過ぎない。プログラマは自分で考え作らなければならない。

大まかに言ってしまえば、企業情報システムのプログラミング言語エキスパートはコーダでそれはユーザーではなく、ワークステーション分野のプログラミング言語エキスパートは大抵ユーザーを兼ねているからプログラマだった。

設計者を排除するには、コーダもコーダのままでいることはできない。プログラマになる必要がある。

民主主義を成立させるには、民主的組織の構成員にリテラシーが必要となることと規を一にしている。

歴史に反省点を求めればダウンサイジング戦略に失敗したと考えるべきだろう。もちろん国家運営と同様に、規模の拡大も忘れてはならないが、それは結果論であって、むしろダウンサイジングに由来すると考えるべきだ。理由：規模の拡大というのはいつでも発生し得る。ダウンサイジングは歴史的事象であり、それによりエンタープライズコンピューティングへのUnix、C、オブジェクト指向言語、それにPC（Wintel)の進出が始まった。

ダウンサイジングの結果、プログラマが必要な分野に、コーダがコーダなまま進出してしまい（同様にプログラミング言語の非エキスパートの設計者も設計者として進出してしまい）、しかもツールだけはプログラマを必要とするワークステーション由来のプログラミング言語が勝ち残ってしまいつつあるからだ。

流れには棹を差せ！ 嘘から出たマコトしやか。

ダウンサイジングの結果もたらされたエンタープライズコンピューティング分野へのワークステーション分野の流入を止めることは不可能だと決め付けろ。

言語を知らない設計者や設計を知らない言語エキスパートは不要だ。

メモ）

ここを出発点から始め、第1の通過ポイントと想定する。ここでは要件定義＝機能定義と設計＝実装の2段階が必要。（その後の検証過程はここではスコープ外と規定）

第2の通過ポイントで、要件定義＝機能定義＝実装/検証の1段階にする。この段階で、コミュニケーション能力、洞察力、業務知識（以上、要件定義に必須）、インターフェイス定義能力（機能定義は核に収斂）も、必要となるだろう。右端については可能な限りの自動化が必要となるか、あるいは不要化（エンドユーザーにお任せ可能ならばそういう方法もあるだろう）していなければならない、あるいは、しなければならない。

現在は、木構造（階層型分業）からネットワーク型（機能型分業あるいはサービス単位分業）への移行過程だと見なした場合、このネットワークを太陽系に喩えられることができる。要件＝機能と実装はまだ分離しているからだ。この分離を太陽と惑星にたとえてみる。1つの要件／機能を実現するために複数の実装が周囲を回転している。エンタープライズシステム全体は銀河系に喩えることができるだろう。

・サービスの疎結合、サービスを構成する個々のモジュールの疎結合

このネットワーク型の分業体制であっても、期限がある以上、全体の進行管理は相変わらず必要になる。

木構造型分業においては、情報伝達はツリー構造に従って上にも下にもまんべんなく行い得る。管理しやすい構造だ。

ネットワーク型では話が異なる。本来管理できない構造だ（各系の求心力によって位置関係が均衡しているんじゃないかな？）。そのため、新たな方法論がここにも要求される。

具体論：

固定レイアウトの帳票：HIPOで記述可能な領域→設計からコード化可能

これをネットワーク型で開発するメリットは？ ――本質的には無い。

構造化では例外処理の記述が現実的には不可能（正確には無意味）。大域脱出はGOTOと等しくなるためそれを回避するには、エラーフラグのような大域状態変数の導入が必要（残りの工程では状態を判定してスルーする条件判断がすべてに必要となる）。かと言って、その帳票が固定レイアウトであり変化を求められないのであれば、モジュール分割も意味を持たない。レイアウトテンプレートへのデータ変換ライブラリがあれば、他は不要。→自動化へ。

_ 突然大人買い

1〜6まで全部まとめて買っちまえなのだが、なんでだろう？