第41回 分かれる2007年問題への評価
| 日経コンピュータを読む理由No.1 「動かないコンピュータ」連載が単行本になりました。全国の書店でお求めいただけます。 |
 |
今回も、皆さんから非常に参考になるご意見を頂きました。有り難うございます。多くのご意見をいただき、改めて「西暦2007年問題」とも呼ばれる熟練エンジニアの引退問題に対する関心の高さを感じました。
もう一つ驚かされたのは、2007年問題に対する評価についてです。ほとんどの方から、2007年問題は「動かないコンピュータ」生み出すものとして厳しい評価を下されるのかと思っていましたが、人材を育てたり、業務の流れを変えるチャンスとして前向きにとらえていらっしゃるご意見があったからです。
なお、今回は多くのご意見を頂いたため、一度で総括編をまとめるとあまりに長くなってしまうことが分かりました。そのため、総括編を前後編に分けて公開することにします。ご了承下さい。
システムを捨てるというアイデアもある
前回の動かないコンピュータ・フォーラム「第40回 生保を襲った時間の壁と2007年問題から考える」で提起した問題についての最初のご意見は、11月17日に頂きました。
大昔に開発し、ドキュメントも不十分だし、開発当時のメンバもいなくなるというのでは、あらゆるトラブルに迅速に対応出来るほうが不思議である。天才的なSEがいれば可能だろうが、そんな人材がゴロゴロいるとは思えない。残念ながら、まずこの状態が前提であり、ここから話を始めないといけないと思う。
古いシステムは使い込まれている分、バグは少なく、運用にもノウハウが蓄積されているはずだ。つまりおかしなトラブルが起こる可能性はかなり低いだろう。2007年問題が問題となるのは、せっかく動いている古いシステムを、中身もよく分からないSEたちが修正しようという場合ではないか。
古いシステムを解読・修正・テストし、移行するというのは、時間もコストも相当かかる。極論かも知れないが、「誰もサポート出来なくなったシステムは捨てる」というのも1つの解と思う。十分使ったシステムはすでに償却も終っていると割り切り、1から開発するほうが結果的にはトラブル対応も含め低コストになると思う。そして、今度こそきちんとドキュメント化を意識して開発すべきだろう。
このご意見は、そのものズバリ、2007年問題に対する一つのご回答を示されています。「廃棄」というアイデアです。
西暦2007年問題に対する対策として、前回の動かないコンピュータ・フォーラムでは、既存システムを分析して仕様を文書化することと、引退するはずの熟年エンジニアの定年延長の二つの点を挙げました。さしづめ、このご意見で指摘されている「廃棄」というのは3点目の対策になるでしょうか。
ご指摘のように、システムの廃棄も2007年問題に対する有効な対策だと思います。ただし、システムを廃棄するためには、廃棄するシステムに変わる新システムを作る必要があります。システム・コストの削減を強く要請される今の時代に、問題なく稼働しているシステムの全面再構築に踏み切るのは、簡単にはいかない側面があるのではないでしょうか。
また90年代以降に起きたシステム部門の弱体化という問題もあります。大規模なプロジェクトの減少によってプロジェクトの構築ノウハウを若手に伝える機会が減少したうえに、アウトソーシングの進展などによって人員の数そのものが減っています。こういった状況の中で、システムを廃棄することのリスクが増しているのも確かだと思います。
老朽化は避けられない運命
11月18日にも同様に、老朽化したシステムの見直しが求められている、という趣旨のご意見がありました。
おそらくここに提示された問題は全ての「インフラ」について同様に言える問題だと考える。一度作ったシステム（もの）はそのままでおいておけば陳腐化、形骸化といった問題が発生し、やがては現状と合わなくなってしまう。
これは、建設した道路や橋、ビルといったインフラがやがては古くなって損傷していく様子とよく似ている。これを防ぐためには、常にメンテナンスし良い状態で稼動させ、現状に合わせて改善していく。そして場合によっては、新しく構築しなおすことだ。今、日本の企業にはこういったメンテナンスされなくてはならない資産（システム、プログラム）が膨大な量残されているのだと思う。これをパッケージで一気に置き換えようなどとは考えてもいない。
ただ、本来、こういった資産をひとつひとつ棚卸し、新しくビジネスプロセスを見直していくことにより、本来のビジネスに力が戻ってくるのではないか？と思う。インターネットなどという流行ではない地道なIT環境を見直すことが実は大切なことだろう。2007年問題は日本のビジネスにとってひとつのチャンスだと私は考えたい。
老朽化したシステムを見直すことが、ビジネス・プロセスそのものにつながり、企業の再生に有用ではないかというご指摘はその通りだと思います。冒頭でも触れたように、2007年問題をあえて肯定的にとらえたご意見の一つといえるのではないでしょうか。
とはいえ、書き込んでいらっしゃるように、現実は「今、日本の企業にはこういったメンテナンスされなくてはならない資産（システム、プログラム）が膨大な量残されているのだと思う」というものです。
頂いたご意見では上記の部分に、「これをパッケージで一気に置き換えようなどとは考えてもいない」と続きます。ところが、現実にはこういった事態の打開を狙ってERPパッケージを導入し、それがむしろ「動かないコンピュータ」を生んでいるケースが少なくありません。
ご指摘のように、回り道に見えても既存のシステムを棚卸ししていき、正しく自社の業務プロセスを理解して、改革の方向を見つけることが、情報システムを通じた企業革新に通じる道なのかもしれません。
「システム資産に人が従属している」
11月19日には、少し違う角度から、2007年問題の全体像を構造化したご意見を頂きました。
まず、この問題の本質を整理します。
◆システムの表現方法と認識論の問題
◆知識情報（暗黙知）の表出・表現と知識継承の問題
◆既存システム資産の解析・評価（強度測定）の問題？問題状況・意識の表出・表現と管理・共有方法
つまり2007年問題はシステム資産が人に従属しているという現実を突きつけているだけであり、日本のような長期固定型の雇用システムが機能している場合にのみ時間により顕在化する、というだけのことです。問題は人とシステム資産の関係にあり、担当者を長期的にシステムの一部に組み込み一体化させることが最終的には問題を根深くさせる要因であると私は考えています。
「システム資産に人が従属している」というご指摘はその通りだと思います。ただ、人が従属することで何とか運用できてきたシステムを、支えてきた人間がいなくなって行く時代にどうするか。このことこそが、現在、システム部門がかかえている問題ではないでしょうか。
ドキュメントの整備から始まって、自社向けの開発基盤の作成やUMLなどのモデリング言語の活用、はてはEA（エンタープライズ・アーキテクチュア）の作成まで、今後システムを作るのであれば、システム資産を人に従属させないための方策はいくつも考えることはできます。
しかし、こういった方策を実行のあるものにするには長い時間がかかります。2007年まであと3年と少し、システム部門に残された時間はあまり多くありません。2007年問題に悩むシステム部門がまず優先すべきことは何なのでしょうか。この点については、2004年の記者の問題意識の一つとして取材を進めていきたいと思います。
若手エンジニアの飛躍のチャンスになりえる
11月19日には、システムアナリストの青島さんからのご意見がありました。
私の場合、20年前に入社した時にすでに開発者・ドキュメントが不在の古いシステム（アセンブラ言語）がありました。例え、開発者が見つかっても、「忘れた」と言われるのがオチでした。突然、潜在的バグでシステムが異常終了することもありました。それでも、そのシステムを安全に運用保守するのが、あなたの仕事だと教えられました。
結局、私が身に付けたのは、他人の尻拭いに対するストレスに打ち勝つ精神力と、トラブル時に、コードを速読し、バグを早く発見する嗅覚と、今で言うリファクタリングを地道に行うことと、ブラックBOX化したプログラムでも、影響が最小かつ、構造を破壊しないように手を入れるには、どうすればよいかという改修設計の知恵でした。
これらは、その後の貴重な財産になりました。結果的に、古い人の知識やドキュメントは、参考程度の情報でしかなくなり、必要ではなくなりました。今の若い技術者達も、同じように成長していくでしょう。2007年は、彼らの大きな飛躍の年になるのではないでしょうか？
青島さんもまた、2007年問題に対して、不安よりも期待を強調されています。カギとなるのは若手エンジニアのようです。2007年問題を考える上では、熟年エンジニアの引退を惜しむだけでなく、若手エンジニアの教育について深く考える必要があるのかもしれません。
実は本誌は、10月6日号で「2007年問題を乗り越えろ OJT偏重の見直し始まる」として、教育問題を取り上げました。読者のみなさんからの反響も大きなものでした。若手エンジニアの育成はいつの時代でも重要な問題ですが、2007年問題の足音が聞こえてきた今、さらにその重要性を増しているのかもしれません。
総括編の後半部分については、来週公開したいと思います。
