2004年元旦にGoogleを「2007年問題」で検索すると、私のページが第三位に出てきた。 間違ったことは書いているつもりはないし、さらには効果を事前検証可能な唯一の解決策を示唆しているわけだから決して恥ずかしい位置ではない。が、私の文章の独特のクセが問題となる。「2007年問題の解決」を考えてサーチエンジンを叩き、訪れてくれた人たちはいきなりこの文章を読むことになる。で、このような人たちは多分頭の中が仕事モードのままである。拒絶反応を起こされても仕方ない。2000年問題を笑い飛ばす、目次へ
しかし、筆者としてはそういう方も大歓迎である。ということで、笑い飛ばさないモードの「2007年問題の解決に向けた方策」を書くこととした。そもそも私が「2007年問題」というのを初めて聞いたのは、ご多分に漏れず日経ITProのページ。2003/4/09の「記者の目」というコラムである。書いている谷島さん、取り上げる問題はそんなに悪くない。（ただし問題のとらえ方と書き方をひねろうとするあまり、問題の本質を見誤ることで読者の批判を結構受けている。私も同感だ。しかし、そのような批判もそれなりに紹介しているところは評価していいと思う。）
コラムのタイトル「2007年問題の解決策を募集します」というのも、なんか言い訳っぽいけど悪くない。問題を提示するときはこんなもんだ。
でも、コラムを読むとこの問題は解決不可能とハナからあきらめているような気がする。主眼は問題をもたらした犯人探しであるととれなくもない。読んでいてその辺が鼻についたので、特に取り上げる気にもならなかった。
しかし年末になっても日経BPでは、まだ似たようなことをやっている。動かないコンピュータフォーラムというところで結構まじめに取り上げているにも拘わらずである。しかも全然進展していない。最初に日経コンピュータが提示した《既存システムを分析して仕様を文書化することと、引退するはずの熟年エンジニアの定年延長》という解決策から一歩も出ていない。11月に出された「以前のシステムを廃棄して作り直す」という意見に日経BP側はそれなりに感心しているようだが、こんなアイディアは初出の「記者の目」コラムへの読者からの意見にもあがっていたことである。
「2007年問題をチャンスに」とかけ声をかけても、別に問題点が解決したわけではない。おかげさまでふらふらふらとフラストレーションがたまってきた。かくしてフラストレーション解消のために「2007年問題を笑い飛ばす」を書き始めた。おまえらいったい何をやっておるんじゃ、というわけである。自分が当初読み飛ばしていたことはひとまず棚に上げる。単純に笑い飛ばすなら簡単である。「団塊の世代はリストラの対象とされてきたため、既に彼らの定年を待たずして2007年問題は発生している。それがUFJ銀行以降、多発するシステムトラブルだ。」などと主張すればそれなりに受けもよい。しかし何も解決していない。
ここでフラストレーションの原因がはっきりした。我々は2000年問題を「解決」した。それなのにそっちは2007年問題に反対しているだけだろう。解決策を出してはいるがそれも気にくわない。熟年エンジニアの定年延長は単なる問題の先送りだし（まあ年金の受給年齢が引き上げられている昨今、定年延長は別の理由で重要な問題であるが）、ドキュメンテーションやシステムのリプレースは2000年問題を解決した我々が既におこなってきたことである。
2000年問題を解決した我々の業績を無視して、2007年問題に反対を唱える人たちがいる。これは容認できませんよ。
だから明示的に2000年問題を笑い飛ばしてきた人間として、2007年問題を真剣に笑い飛ばすのはやらなきゃならないことだと思った。主張したかったのは次の点
内容については、前回の文章の通りです。
- 2000年問題を解決してきた過程で2007年問題は既に解決されているはず。されてないとすれば、その理由を分析しないと2007年問題の解決策は作れない。
- ドキュメント化とよく言われるが何故。ドキュメントはあるじゃないか。
また、じゃあ昔のSEはシステムの全体像をとらえていたのか？というのも疑問であった。昔はシステムが小さかったから全体像をとらえていただけではないかという気がする。例えば、最初は○○という帳票をこのシステムから直接出していた。確かにそのころは全体像をとらえることが出来たろう。しかし、システムが巨大化して帳票出力を別のサブシステムに切り出すようになると怪しくなり、さらに複数のシステムの帳票出力サブシステムを一元化して、帳票の電子化などを行うともう分からなくなってくるはずだ。確かに○○という帳票をどっかで作っていて連携があったことは記憶している。でもこれを全体像をとらえていると見るべきかどうかは意見の分かれるところであろう。
ただしここで最大の副産物が生じた、システムのトレース可能性を保証すれば、2007年問題、何とかなるのではないかということである。イメージとしてはラジオアイソトープによるトレースなのだ。データがどこでどのように集計・加工しているか確認できる仕組みがあれば、システムの全体像は都度とらえ直すことができる。さすがにデータに放射能を当てることはできないが、各データがどのプログラムでどう加工されているかを記録する仕組みがあれば何とかなるなということである。
最初はその記録を手作業でドキュメントという形で残すしかないだろう。しかし手作業では将来的なメンテナンスが保証できない。そうなると、システム自身が記録を残すようにしないといけないなあということだ。イメージとしては、インターネットメールがサーバーを通るたびに経由サーバーの記録をヘッダーに追加するようなものだ。
将来的にはシステム構築時にこのような記録を残すようする。既存システムもその方向で再構築してゆく。確かに大変だからこれをOSがサポートしてくれればその方が即効性があるだろう。（ただし、OSでサポートした場合、加工の記録はファイル単位にするのがせいぜいである。アプリケーションレベルで作り込めばデータ項目ごとに記録できる可能性はある。ファイルを全てデータベースにしてメタデータの持ち方を工夫するといいかなと思ったりするが、今度はバックアップが大変になる。）
このデータを中心とて、その加工状況をドキュメント化するという手法は、従来のドキュメント化が対象とし損ねてきたところじゃなかろうか。（CASEツールによるドキュメント化は、プログラム内部のドキュメント生成が主である。）ならば、2007年問題の解決策として提示する価値がある。かくして単に問題認識をあげつらい、再考を迫ろうとした当初の意図とは別に、具体的な解決策を提示するものができてしまった。
しかも、効果を予測でき、永続的に同種の問題を起こさないことを保証できる解決策である。もちろんシステムでは解決できない問題というものもある。業務処理をシステム化してきたが故に人手で処理することが出来なくなったということもあるだろう。これについては解決策を示さなかった（問題の存在に気が付いていることは暗示した）。解決責任がシステムにはないと思っているからである。
なぜならこの問題は「電卓が普及したので、子どもに計算力が無くなってきた」とか「ワープロが普及して、子どもの漢字力が落ちてきた」というのと同質のものと考えているからである。無くなってきた計算力をどうするかという問題の責任を負わされたのでは電卓メーカーもたまらない。漢字を読む能力は逆に上がっているんじゃないかと思うのだが、その功績でワープロメーカーが称えられるわけでもない。ただし会計処理システムで構築当初は既存の仕分け処理を写し取っただけのロジックであったが、やがて新しく生じた仕分けパターンを加えて修正してゆくうちに、仕分け処理全体を手動でやれる人がいなくなり、知っているのはシステムだけ、という問題は生ずるかもしれないなあ。でもこれだってシステム側に解決責任はないでしょ。
だが、この問題はソフトウェア業界で言われる2007年問題と本質的に同じである。会計処理が肥大化していくうちに、会計処理の構造を全体的に見ることが出来る人がいなくなってしまった。ベテランがいてくれれば、一つ一つ洗い出すことにより何とかなる気がするが、そのベテランがいなくなるとどうするか。システムをトレースして会計マニュアルを作るか、ベテランの定年を延長して問題を先送りするか、さあどうしよう。（やはりここでも、伝票の数字をラジオアイソトープみたいな形でトレースできたらなあと考える人は出てくるだろうね。）
2010年問題として提示されたものを2007年問題として言い換えることをしなければ、このような他業態の問題を解決しようとしている人たちとも情報交換が図りやすかったのになあ。