日々の破片

_ しかし君らは本当にバカだなぁ

おれも含まれているのが残念なところだ。でも、それはここでは触れない。

さて、おれは、クールな人々のプログラマティックな闘争の物語が好きだ。それが事実に立脚していればなおさらだ。

したがって、プログラマーのジレンマを読むのは当たり前のことだ。

このジャンルの今までの最高傑作は、『ソフトウェアの限界』である。ロバート・ブリッチャーというエンジニアの著作で、まとまりには欠けるが情熱の込められた本である。ブリッチャーは大規模ソフトウェアの失敗を内部で経験した。（中略）AASは、航空交通管制システムを近代化する計画だった。1981年に始まり、数十億ドルを費やしたあげくにほとんど何の成果をあげることなもなく1994年に「打ち切られた」。

（中略）

AAS計画は、ピーク時には1日100万ドルの政府の資金を使い、IBMの従業員2000人をプロジェクトに投入し、プログラムのコード1行につき100ページのドキュメンテーションを作成した。しかし、ブリッチャーによれば、結局「ソフトウェアを書くことはできなかった。」（中略）ブリッチャーが記録に残したプログラミングの戦いの中で、オーバーワークというより、むしろ挫折による重圧を受けていた参加者たちは、自動車事故を起こし、精神に異常をきたし、自殺に追い込まれる。プロジェクトマネジャーは紙を食べることをやめられなくなり、遅れが拡大するにしたがい、会議中に口に詰め込む紙切れがどんどん大きくなっていった。もちろん著者も含め、傷を負わずにすんだ者はいなかった。

IBMのような企業が、もちろん鬼より賢い人々の企業で、そこから2000人のプロパー（やはりスマートな人たちだろう）と、航空関係の官僚たち（もちろんさらにスマートな人たちに違いない）、潤沢な資金、そういうのが死屍累々というのは、これまでさんざん語られてきた。ということは、何かが間違っているのだから、方法を考え直すのが当たり前の方法だ。

生産性が頭打ちになりキャパシティが不足すると何が起きるか？ 上部構造が反乱にあう、というのと同じではないか（追記：ここは混乱している記述だ。逆だとう思う）。

それを読んだ後に、Diary?(ここに書かれていることは主観的な事柄なので内容そのものについては何も判断はできないが、少なくとも、Antがどうしたというようなことは元請けが主導することはできるはずだし、それをするのが元請けのミッションではないのだろうか)を読み、本当に人間の進歩への歩みの遅さあるいは愚かさの繰り返しにうんざりする。間違った方法を繰り返しても正しい結果は得られない。何が本当に正しいのかは（まだ確実性をもっては）わかってはいないが、しかし、だめな方法はわかっているのではないか？

プログラマーのジレンマ 夢と現実の狭間(スコット・ローゼンバーグ)

さて、ということから、これも読みたいものだが。

The Limits of Software: People, Projects, and Perspectives(Britcher, Robert N.)

労働集約産業では、いくつもの歴史的な実験とその結果がある。NEPは成功し、コルホーズは失敗した。人民公社は収益を内部で留保できるようにしたときに最も効率的だった。私有が認められると生産性が上がり万元戸が生まれた。

大規模開発というのは、SIの事業で、それは労働集約的に行われる。そこでの農民はNEPや万元戸時代のように自発的な能力を発揮することでより高い収益を上げられる存在ではなく、コルホーズの赤い農奴のように扱われているのではないか。中央の管理により一滴の水の用途はもちろん天候を無視した時間決めの生産活動（農業活動ではなく生産活動と、意味もなく抽象化され標準化されている点に注意したい）、植物の成長ではなく、あらかじめ決定されたスケジュールにのみ依存する収穫作業、こういった方法論がまかり通っているように思う。

もちろん、コルホーズや人民公社には、ぐうたらで、無能で、自分の脳みその使い方を知らない、奴隷根性の連中がうじゃうじゃいるかも知れない。おそらくいるだろう。しかし、彼らは、いずれにしても、生産に寄与はできない。20:80法則は常に正しいと仮定してみよう。80の奴隷は、何をやっても80の奴隷だ。着目すべきは20に最大のパフォーマンスを発揮させることだ。NEPが成功したといっても、100人の農民のすべてが成功したわけではない。するわけもない。しかし、コルホーズに100人の農奴を押し込めたときよりも、高い生産性を上げていたというのが、歴史というものだ。