第40回 生保を襲った時間の壁と2007年問題から考える
| 日経コンピュータを読む理由No.1 「動かないコンピュータ」連載が単行本になりました。全国の書店でお求めいただけます。 |
 |
10月初旬にかけて、明治生命や安田生命など複数の大手生保で、契約者に支払うべ配当金の一部に未払いがあったことが明らかになった。この問題は、11月3日号の日経コンピュータ本誌でも取り上げたので、ご記憶の方もいらっしゃるだろう。
今年に入って、「西暦2007年問題」という言葉が、世間を騒がせつつある。これまで長年にわたって日本のシステム開発の現場で奮闘してきたベテラン・エンジニアが、2007年には60歳を迎えて、完全に現場から引退してしまうことを指す。日本企業が情報化に取り組み始めたのは、1960年代からである。若手技術者として、この時代からシステム開発にずっとかかわってきたエンジニアがいなくなってしまう影響は確実にある。
実は、この2007年問題と「動かないコンピュータ」とも2007年問題は密接に関係していると記者は考える。そして今回、生保が経験したトラブルは、2007年問題が、今後システム開発の現場に大きな影響を与えかねないことを示唆している面がある。そこで、今回の動かないコンピュータ・フォーラムでは、この問題について考えることにした。
いつものように皆さんからのご意見をお待ちしています。ご意見を書き込まれる方は、この画面の一番下の方にある「Feed Back!」を使ってお書き込み下さい。「コメントを書く」という文字の部分をクリックしていただければ、ご意見の記入欄が別画面で現れます。
開発から10年、20年が経過して問題が顕在化
まず、生保で起きた配当金の未払いの問題について、簡単に説明した。今回、配当金の一部で未払いがあったことを明らかにしたのは、明治生命、安田生命、朝日生命、富国生命の4社である。
若干の事情の違いはあるが、基本的には各社とも、一定期間を超えて同じ生命保険会社の保険契約が何らかの形で終了したときに、いわば「利息」のような形で保険の被契約者に支払う特別配当に、未払いの部分があった。同じ人間が、同じ保険会社のなかで既存の保険契約を別の商品に切り替えた場合に、特別配当の金額を少なく計算しているケースが起きていた。
未払いが生じた原因はプログラムにあった。特別配当の金額を計算するプログラムに潜在的な不具合があったり、新たな保険商品の登場や計算方法の変更に伴ってプログラムの設定を変えたり、追加開発を実施すべきだったのに、これを怠ったりしていた。
いずれの生保も、問題が起きたプログラムを開発したのは10年以上も前のことである。なかには、四半世紀前に開発したプログラムもある。プログラムを開発したりした当時は、不具合が顕在化する条件が極めて希なものだったために、ほとんど問題は発生しなかった。
だが、バブル崩壊以降、生保の資金運用益が減る中で、プログラムの開発当初には、ほとんど発生しないと想定していた支払い条件が一般化。これによって一気に不具合の影響が広まった。事態を認識した時には、すでに億円単位の特別配当の未払いが発生していた会社が多かったのである。
立ちはだかる時間の壁
今回の生保の問題が発生した背景にあるのは、単に時間が経過して社会状況が変化して、不具合が顕在化したということだけではない。時間が経過していく中で、システムをどのように設計していたかという情報を、利用部門や管理部門が把握できなくなっていたことも、トラブルが発生した原因ということができる。
今となっては当時の状況は不明だが、未払いが起きた生保の中には、プログラムを開発した段階では、特別配当の未払いが生じることを担当者が把握していた可能性があったという。その当時は、極めて珍しい条件だったために、プログラムに追加の開発を施すのではなく、その都度例外処理として手作業で処理すればよいと考えていたのかもしれない、ということだ。
こうした開発時の経緯を担当部門で把握していれば、時間の経過と共にシステムに修正を施す必要が出てきたことを認識することもできただろう。だが現実には、システムの運用が始まって長い年月が経過する間に、当初どのような仕様でシステムを開発し、時間の経過と共にどのようなことが起こり得るかを、システム部門や利用部門が把握できなくなってしまった。担当者が異動、あるいは退職するなどした後に、必要な情報を引き継ぐことができなかったのである。
生保は、時間の壁に屈したと言えるのかもしれない。
2007年問題で類似例が続出の可能性も
だが、これまでこの種の問題が発生することは、それほど多くはなかった。確かに開発から長期間が経過して顕在化するバグによってシステムが大きなトラブルに見舞われることはあったが、それは開発した時点から全く想定していなかったものだった。
こういった問題が起きなかったのは、同じシステムの開発に長年かかわり、隅々まで理解していたベテランエンジニアの存在が大きい。たとえドキュメントの類が残っていなかったとしても、担当者本人の経験と知識がドキュメントと同等あるいはそれ以上の力を発揮したからである。
だが、2007年問題によって状況は変化する。頼りになるベテランは、いよいよいなくなっていく。そして、ベテランが引退するとなると、人に頼っていた問題が浮き上がる。OJT偏重といわれてきた日本のIT業界が直面する最大の問題かもしれない。
人材の流動性の高い中堅・中小企業においては、昔から担当者の異動や退職が「動かないコンピュータ」のきっかけとなることが珍しくなかった。2007年問題が本格化することで、従来はこういった問題が起きることの少なかった大企業での、類似した問題が起きる可能性がある。
こうしたベテランエンジニアの引退に伴う問題をどう乗り切るべきか。生保で起きた未払いの問題は、2007年問題がもたらす一つの可能性を示しているように思えてならない。
2007年問題を乗り切るため特効薬を考えるのは難しい。この問題について触れた最も早い記事の一つである、「「西暦2007年問題」の解決策を募集します」でも、そのタイトルの通り、解決策は提示されていない。この記事の姉妹記事が日経コンピュータ4月7日号「すでに発生した「西暦2007年問題」であるが、ここでも解決策については、長年利用してきた既存システムの内容を可能な限り分析して文書化して残すようにするか、本来なら引退するはずのエンジニアに、定年を延長してでも続けて働いてもらう、ことが挙げてあるだけである。
さて、ここからが本題です。はるか以前に開発したシステムの仕様を、確実に把握してシステム・トラブルを起こさないためには、どうすればよいのでしょうか。また、2007年問題によって、ベテラン・エンジニアが次々と引退していく中で、この問題をこれ以上深刻なものにしないためには、どのような対策が有効なのでしょうか。みなさんのご意見をお待ちしています。
今回のテーマへの投稿は11月28日（金曜）午後6時で締め切らせて頂きました。ありがとうございました。みなさまのご意見を基にした総括記事は、12月4日木曜に当サイトで公開する予定です。
