「2000年問題を笑い飛ばす」は、その渦中にある人（私も渦中にいた）に多少の不快感を与えたかもしれないが、内容としては結構いいところをついていたと思う。「日本とドイツが遅れている理由」なんか、自分でも感心している。（今や死語と化した感のある「国際感覚」だが、こういうことに気がつくことを言う。）2000年問題を笑い飛ばす、目次へ
だが、今当方が書いているこの文章に関しては、嫌う人が多かろう。ひたすらあげつらうだけだからである。でも、あげつらうことに意味がある。これを不快に感じる人があるとすれば、不快にしか感じられないところに問題があると思うからである。不思議である。団塊の世代が定年を迎える際に生ずる問題は、ゴーンさんの場合は2010年問題と言っていたはずなのだが、CSKの誰かが2007年問題といい、日経ＢＰが追従したが故に、コンピュータ業界では2007年問題といわれることになってしまった。
どこがよくないか？他の業種の同様な問題と名前を変えてしまったために、他の業種とアイディアの交流が阻害されるのがよくない。それは、2010年問題は、労働力が減るという問題。2007年問題は団塊の世代の持つノウハウが消失するという問題、と違いはあるといえばあるのだが、極力変えない方が問題解決のためには優れていると思うのだ。まあ業界最大の出版社、日経ＢＰがそう言ってしまったのだ。しかたないから2007年問題という用語を使おう。おかげで他の業種に遠慮することなく笑い飛ばせる。（ホテルの部屋があまるという2007年問題と混同する危険は、無責任にも無視する。問題の種類が全然違うので混同することはなかろうし。）
さて、2007年問題というのは「中小企業IT110番」によるとこういうものらしい。
西暦２００７年問題とは、長年企業において大型汎用機などの基幹系システムを開発・保守してきたベテランが引退してしまい、今まで培ってきた技術やノウハウなどが継承されず、基幹系システムの維持が困難になる現象を指しています。不思議である。コンピュータ業界は技術やノウハウの継承というのが最も問題とならない業界の筈である。システムのライフサイクル、技術革新が早く、つぎつぎとリプレースされているため、すべての世代にわたって技術力やノウハウが蓄積されているはずだからだ。それに何より、2000年問題をクリアしたという実績が大きい。
2000年問題の解決のために、我々はすべてのシステムについて、ソースコードレベルの検証を行ってきたのだ。従って、入社数年という世代は除いて、現役世代にすべてのシステムについての経験者が存在する。これ以上何がいるというのだろう。2007年問題を騒ぐ人は、2000年問題を知らないようなキャリアの浅い人間に違いない。困った人たちである。
ちょっと言い過ぎだって？そうかなあ。どこか間違ってますでしょうか。もし、私が間違っているのだとすれば、2007年問題の解決策として、システムのドキュメント化とか、システムのリプレースとかを提唱している人たちも同様に間違っている。彼らの提唱する解決策は、2000年問題の対策として既に行っているはずだから。ソースレベルで修正するために、プログラム毎に入出力ファイルのデータ構造を徹底的に吟味してドキュメント化し、動作確認テストのために、システム間の連携状況をドキュメント化し、それでも駄目なものはリプレースした。
何か足りないのか？多分足りないのだろう。そうでなければ、2007年問題を訴える人々に対し、我々は感情的に怒ってもかまわない。というのは、彼らは2000年問題を克服してきた人間を侮辱していることになるからだ。システムのドキュメント化やシステムのリプレースをやっていなかった、と言っているわけだから。
もし、足りないのであれば、気分は悪いが怒るほどのことでもない。やったことはドキュメント化やシステムのリプレースという言い方で共通するとしても、目的が違うから2007年問題解決の観点から見て足りないとしても当然のことだからである。だから問いたい。「何が足りなかったのですか？」（おお、わずかながら解決に向けて前進した。）
空港業務については素人なのであるが、これが「航空管制の2007年問題」というなら想像がつく。ベテランの管制官が引退した結果、システムがダウンしたときに航空管制の出来るものがいないのはいざというとき問題であるから、ノウハウのドキュメント化を、という解決策は妥当かもしれない。（ちなみに2000年問題の時は、ベテランを管制室に張り付けてその場をしのげたため、ドキュメント化は不要であったとする。）
同じような問題をソフトウェア業界に当てはめると、CASEツールでシステムを作っている人間しかいないため、CASEツールとひもついていない昔のシステムを保守できる人間がいない、ということになろうか。2000年問題の時は、ともかく日付ロジックだけを直したからその問題は残ってしまったという事でどうだろう。しかしCASEツールって、そんなに普及していたっけ？
ただし、妙に標準化が進んだため、みなさんSORTといえばQuickSortをライブラリから引っぱり出してくるだけになってしまい、場合によっては遙かに有効な単純挿入法を使えなくなり、保守もできない、という事はあるかもしれないなあ。でもこの場合、有効な解決策はドキュメント化でもリプレースでもなくリファクタリングであろう。（ドキュメント化をするなら「なぜ、こうしたか」を記述しておくという方向であろう。今後はこういうドキュメントの作成に工賃を支出する、という教訓を忘れないように。）これに限らずシステムの分野でドキュメント化とやたら言われるのが気になっているんだわ。これほど言われるということはソフトウエア業界というのはドキュメント化が遅れている分野でなければならない。でもそうか？極めて進んだ分野じゃないのか？
「ノウハウ」というとらえどころのないものでさえ、設計技法からはじまってデザインパターンとかMS-OFFICEの使い方に至るまで丁寧に解説した本が、少なくとも本屋の棚を占拠しているぞ。また個々のシステムについても組織だってきちんと開発されたものであれば、コンパイルリストに迫る分量の設計書が出来ている。いや、コンパイルリストそのものがドキュメントだ。プログラムにが何をやっているか一つ残らず書いている。おい、これ以上何が必要なんだ？
予測できる唯一許容できる答えは「すみません、全然見当はずれのことをやっていました」。じゃあなぜ、見当はずれなのか。見当はずれでないことをやれるという確証があるのか。いまからでもきちんとやれば2007年問題を乗り切れるのか。おお、さらに解決に向けて前進した。
この辺で仮説を出す。今回言いたいのはこの仮説である。
なぜソフトウェアではドキュメンテーションがされないかというと、それは、プログラム言語で完璧なドキュメンテーションがされているからである。
そしてなぜプログラム言語以上の詳細なドキュメンテーションが必要になるかというと、現在のコンピュータがノイマン型（プログラム内蔵型）コンピュータだからである。
従ってシステムのリプレースでは本質的な解決にはならない。オープンソースに設計書はない（あったら教えて）。ソースで十分（みたいだ）。ソースが読める人間にとって、設計書は不要である（のかもしれない）。なのになぜ設計書なんか書く必要がある、人工言語で記述されたのと同じものをあいまいな自然言語で記述することは、同じものを二重管理する不経済をもたらすのみならず、退歩ですらあると主張する人間がいても「それは違う」と反駁することは出来ない。
せいぜい言えるのは、でもPOSIX仕様書は欲しいとLinusも言ったでしょ、くらいだ。これがないと既存のシェルが呼ぶシステムコールをカーネルに実装できないから。つまり外部インターフェースに関するドキュメントは必要なのだ。で、ノイマン型コンピュータの場合、この必要性は激増する。というのは、ノイマン型はプログラム内蔵型と言われるように、システムの関連が外からは見えない。従ってパーツを取り付けるとき、やり方を一から十まで教えなければならない。これが機械部品だったら「端っこを合わせたらネジを締めて」で意味が通じるし、たとえ間違った取り付け方をしてもネジ穴が合わないものだから「なんか変だぞ」とすぐに分かる。
昔のシンセサイザーは、VCAとかVCOとかVCFとかが物理的にモジュール化されていて、その間をシールド線で繋ぎ替えて音づくりをしていた（もちろんつまみもひねっているが）。で、シールド線で繋ぐというのが目で見えているうちは、音の作り方はなんとなく分かる（ハイスクールララバイで山口君は、シールドを演奏中に抜き差しする真似をしていた）。これがYAMAHA GX-1以降は一体化されてしまい音が出るまでの過程が見えずらい。だから自分で音を作るというのが極めて難しくなり、専門家がプリセットした音を使うしかなくなる。（ちなみにYAMAHAのシンセの音がいいのは、CPUのオーバークロックが電圧を上げるとやりやすいのと同じ理由だと思っている。同じ周波数を出すときにかかる電圧がKORGの４倍。）確かに信頼性や柔軟度はGX-1以降の方が上かもしれないが、何をやっているのかわかりやすいのは初期のモジュール式。ノイマン型コンピュータはGX-1以降のシンセと同じように、コンピュータの中にプログラムを入れてしまい、外から見えなくなっているのだな。（ミニムーグは一体型でも、パネルを見るとモジュール化されているのが分かるのだな。）
なわけで、コンピュータは内部モジュールの繋がり方が全く外から分からない分、ドキュメンテーションが必要になるのである。ケーブルで繋がれているのが分かる場合でも、プロトコルは分からないし、ネットワーク定義もはっきりしないから事情はあまり変わらない。ましてやDBMSや監視プログラムなどが独自にデータを流しているとすると、何がどのタイミングで流れているのか全く分からない。
2000年問題の時はプログラム単位には、これは詳しく見たし、外部仕様も「動かなかったらどうするか」という観点でよーく見た。が、プログラム間の結合やハードの結合なんかはそんなに見てはないのだな。
で、この繋がり方、2007年に引退する方々もあまり知らないはずなのだ。知っているとすると「このデータ、ずっと下流で○○の業務に使っていたはずなんだよな」くらいである。しかし、それが手がかりになって影響調査の精度があがることは確か。それでどんなに助かってきたことか。でも「どこかで・・・だったような」というのはドキュメント化しにくいなあ。逆にこのレベルの途中のシステムをすっ飛ばしたようなことをドキュメント化すると悪影響すらある。途中を考えなくてよいと言っているようなものだからね。たとえドキュメント化したとしても公式なものと認められないでしょ。(2004.1.3加筆) 元旦にGoogleを「2007年問題」で叩いたら、このページが第三位にあがりました。だから検索エンジン経由で2007年問題を解決策を探そうと仕事モードでここにやってきてくれた人がいるかもしれません。そんな人のために解説ページを用意しました。この後の文章、私のクセが出まくっているのでいきなり読むのは危険です。よし、ドキュメント化はあきらめた。徹底したリファクタリングをやろう。非ノイマン型のシステムに切り替えるのがベストだがそんな製品はない。で、いくつか案を考えた。 まず隣り合うシステムは別のベンダーのものを使い、切り分けを容易にする。ケーブルの色はプロトコル別に変える。（みんなTCP/IPなら名前解決の手段や管理サーバ毎に色を変えるなどと言うことも出来るぞ。）
更にはやりとりされるデータのヘッダーに経由してきたサーバーやプログラムのIDを付け加えることが出来ればいいんだがなあ、、、プログラムが何をやっているかの１行コメントもつくといい。ならデータを見ればだいたいのことは分かってしまう。しかも洩れはなくなる。よし新しいプロトコルを作ろう。
セキュリティも高まるぞ。内部ネットワークでインターネットプロトコル（TCP/IPとは限らない）と互換性のないものを使っておけば、外部クラッキングやウィルスへの体制も高まるはずだ。どうして誰も気がつかなかったのだろう。恐ろしいことに「2007年問題の解決策（しかも検証可能な解決策）」にはなっている。実効性が予め計算できる解決策を私は他に知らない。
データ量が莫大になる？団塊の世代の人々ははるかに少ないCPUパワーとディスク容量とネットワーク速度でなんとかしてきたんだよ。それを考えればたいしたことないでしょ。よし、これをmoriyama-protocolと名付けて名称の使用を強制しよう。今日本で爆発的に普及しているTRON+JAVAを日本で初めて思いついたときに自己主張が足りなかったので、生ける伝説になりそこなった分巻き返しをはかるのだわ。（まあ、クラスライブラリを予めインストールしておくというアイディアまではなかったのだが、ネットワーク対応の軽いＯＳを使い、データに再生アプリをくっつけて送るというところまでは正確に予言している。Javaが発表される１年前なのでこの程度でよしとして。またIBMユーザー研究会に出したのでTRONという固有名詞使えなかったという事情もあるのだわ。でも、最後の１文、これは読んだらITRONだと分かるでしょ。）
よし、これで私もネグロポンテ（こいつは自己主張が強すぎる）のように生ける伝説に・・・と思ったところで、このアイディアMicrosoftに持っていかれそうな気がしてきた。Longhornというやつは、ファイルシステムをデータベースで管理していて、そこにいろいろな情報を盛り込めるそうな。
このデータベース部分にデータが経由してきたプログラムIDや処理についての１行コメント、入れられなくはないわ、そういった情報はアプリケーションで管理するよりもＯＳレベルでサポートしてくれた方が絶対によい（メモリ使用量とセキュリティの問題は措いておく）。だからMicrosoftはしゃあしゃあと「そういう使い方も当然想定していました」と言うに違いないわ。く、くやしい。かくして2007年問題の解決策は
「次のバージョンのMS-Windowsを全システムで使用する」ということになりました。Microsoftの広報でさえ考えつかないような結論になったわ。
アイディアも含めて転載する時には連絡ください＞Microsoft様。代わりと言ってはなんですが、家族でシアトルに旅行する時があったら費用持ってくれるくらいのことはしてちょーだい。（相手がMicrosoftだと、こっちまでせこくなってしまった。でも不景気だしなあ、ああ旅行ぐらいしたいなあ。）