第三次EUCブーム

　ほとんど10年ぶりに、システム開発技法の勉強をする羽目になった。
　ずいぶんと様変わりしている。
　なるほど、最近はEUCの開発技法がホットなテーマになっているのか。

　オフコンの時代にEUCブームがあったらしい。
　これはファイル容量の限界と、担当者の異動によって終焉を迎えた。
　パソコンLANの導入時期にもEUCがもてはやされた。
　4GLなんてあったなあ。
　最近のEUCは少々毛色が違う。システム専門部署の伝統的な開発技法自体がEUCにすり寄ってきたのだ。

　ここんとこ、（知識として）普及してきた技法にeXtreme Programmingなんてのがある。ここで提唱されている「オンサイトのユーザ」とか「機能テストをユーザーに書いてもらう」なんぞの主張を実現するためには、むしろ「ユーザーサイドにシステム部門が出て行った方が効率的なんじゃないのかな」と思う。で、会議室を一つ借りて、小さな開発環境を作ってしまう。端末の数はプログラマー数の半分でいいから（ペアプログラミング）何とかなるんじゃないかな。
　と考えて、eXtreme Programmingを「EUC」の技法、として読むと実に納得できることが分かった。eXtreme Programmingは設計書書かないしね。設計書を作らないのは誤解だ、という主張を聞くけども、じゃあどのフェーズで設計書書くの？と調べても特に何もない。
　そりゃそうだ。とりあえず分割して、あとでリファクタリングするのだから、安定した設計なんぞ無くてもかまわないのだろう。
　一瞬納得するが、システム開発をきちんと勉強させられた（体感させられた？）人は次の疑問を抱く。手戻りによるコスト増はどうするのだろう？ここで原典をひもとくと。何々、ソフトウェアの修正コストは時間が経過しても増加しないというのがeXtreme Programmingの技術的前提であるだって。
　普通はこのくだりを読んだとたん、「eXtreme Programmingは非現実的な前提に立脚しており、検討に値しない」と判断されるのが普通であろう（悪いことに原典の序盤に書かれている）。私のように「EUCなら使えるんじゃないか」と助け船を出す方が珍しいのではないかな。

　ここでもう一歩踏み出して「EUCの開発技法から見て、システム専業部門の開発技法を批判する」という流れ、結構有効なのでは、と考えてみる。他にEUCだからこそ成功している開発技法はないだろうか。

　実はあるのだ。「オープンソース」運動である。これは典型的なEUCだ。だってLinusさんは自分で使うためにLinuxを作ったんだから。Eric S Raymondも「伽藍とバザール」にも教訓の１として書いてある。「良いソフトはすべて、開発者の個人的な悩み解決から始まる」。Linuxに仕様書が無い理由が分かった（強いていえばPOSIX標準の仕様書で良かった）。自分の悩み解決のためなんだから、仕様はよく分かっている。

　ここで、当方が1999年末に気がついた疑問に答えが出る。「2000年問題を孕んでいたロシアの原発の制御プログラムのソースコード、オープンソースにすれば、世界中のハッカーがよってたかって修正してくれるはずだが、違うような気もする」というやつだ。
　修正してくれない。個人的悩みに基づいて開発されたものではないから、仕様が分からないというのがその理由。

　そんな目で見てゆくと、オープンソースがその名の示すとおり「ソース」に偏重していることがよく分かる。GNUで公開が求められているのも「ソース」だけで「ドキュメント」ではない。

　Linusは設計の天才だろうとは思う（正確には設計の評価の天才）。しかしプロジェクト管理では凡人のようだ。Trancemeta社ではLinuxと同じようにプロジェクト管理をやって失敗していると本人が告白しているから。

　Linuxが設計書なしでもうまくいくというのは、要するにソースレベルで不自由しないほどのスキルを持ち、かつ要求仕様を熟知している開発者が無料で雇えるからである。なあんか、eXtreme Programmingの様態を呈してきたなあ。多少こじつけるとまったくeXtreme Programmingの要件を満たしていることがわかる。

計画ゲーム

これは不要。開発者と使用者の対立がないから。

短期リリース

早めのリリース、しょっちゅうリリース、Linusの最も得意とするところである。

メタファ

これも不要。開発者と使用者の対立がないから。

シンプルな設計

OSのコード一般についてよく分からないけども、私はLinuxの設計（特にモジュール分割）すさまじく優れていると勝手に思っている。

テスト

テストコードを先に書くわけではないけど、ポスト直後にテストされまくっているから同じこと、とこじつけてしまおう。

リファクタリング

x86ぺったりで書かれていたソースが、リファクタリングの結果、CPU依存のモジュールがわずか２つにまとめられたわけだから、少なくとも結果としてリファクタリングは成功している。

ペアプログラミング

ペアプログラミングではないが、ソースコードレビューは徹底してなされている。

共同所有

オープンソースそのもの！

継続した結合

これも、はやめのリリース、しょっちゅうリリースで実現されている。

40時間労働

40時間以下かも。

オンサイトのユーザ

ユーザー自身が作っているわけだから、これは完璧。

コーディング規約

これは、GNUのしっかりとした規約がある。なお、感動したのはLinusさんがインテンドを8文字にしようと主張した理由。「それで読みにくくなるのなら、設計が間違っている」という発想。

　従って、最新の開発技法を導入し、生産性を上げるためには
プログラマが実際に使うモノを作らせる。
おもしろいと思うモノを作らせる。
催促しない。
給料をただにする。（成果物を投入コストで割ったのが生産性。従って給料をただにすれば生産性は、いやでも高まる。）
ということになる。

　企業で上のことが出来ないとすれば、やはりオープンソースの開発モデルは使えないということだ。

　でも、IBMは作っているなあ。実は何かのはずみで（オープンソースだからと）、IBMが自社が使っているLinuxの仕様書、設計書を公開してくれないだろうかと期待しているのだ。もし公開しているようだったらおせーてください。