現在地 HOME > 掲示板
> ＩＴ5 > 236.html
★阿修羅♪
|
現在地 HOME > 掲示板
> ＩＴ5 > 236.html
★阿修羅♪
|
|
| Tweet |
ユーザーからもベンダーからも大切な技術が失われている【IT_Pro記事】
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20040318/141592/
[2004/03/19]
15年ぐらい前に，あるメインフレーム・メーカーのハードウエア設計者がこぼしたことがあった。「お恥ずかしい話だが，メインフレームの開発中にデジタル回路が正常に動作せず発振してしまった。原因究明にはアナログ技術が必要なんだけど，アナログのスキルが現場に継承されておらず，分析が進まなかった。しびれを切らした部長が『アナログのわかるやつを連れてこい』と部下に探させたら，なんと取締役が来ちゃったんだよ（笑）」。
話を聞いた瞬間は笑えたが，実は根が深い問題だった。デジタル回路は人間が勝手に「1」「0」で論理を定義して作る世界の話であり，回路基板の上の信号は物理法則に従いアナログ信号として伝搬する。しかし当時，アナログは“古い”技術，“お金にならない”技術として若手から見放され，そのスキルは現場から消えつつあった。
いつのまにか論理の世界と自然（物理法則）の世界の狭間を埋めるスキルが失われ，その結果トラブルの発生原因を解明できず，問題も解決できなくなっていたのである。技術力を誇っていた大メーカーでも，こういうことがあるんだと，当時は意外に思ったものである。
情報システムの世界でも抜け穴が・・・
このようにバックボーンになるような技術が，なにげなく失われてしまうことに，最近はそれほど驚かなくなった。とりわけ情報システムの取材をすると似たような話をよく聞く。
例えば，開発・保守・運用の一貫した体制とそれを支える技術がオープン化で崩れ，まだ立ち直っていないというシステム担当者は多い。マルチベンダー化によってユーザーはシステムを管理できなくなり，ベンダーも全体を把握できずメインフレーム時代のように1社で責任をとれなくなった。これが，企業内システムはもちろん，金融や交通といった社会インフラのようなシステムでも，大きなトラブルが後を絶たない原因の一つになっている。障害の未然防止策が不十分になり，障害発生時の原因追求や早急な対応も困難になってしまった。
開発技術の基本が揺らいでいるという話もある。昨年の夏から秋に日経コンピュータの読者から同じ内容の投書が編集部に多数寄せられた。
「業務設計技術や基盤システムの構築技術およびノウハウを，日経コンピュータで詳しく解説してほしい。これらの技術を解説した書籍が世の中には存在しない。各企業の経験者が後継者に伝授するといった形式でのみ技術継承されている。システムの基本となる重要なことなのに，信頼できる技術の習得機会が非常に少ない」。基盤システムとは，例えば銀行の勘定系のような特定の業種・業務における，共通機能や固定的・普遍的な機能，大量のトランザクションを高速に処理する制御系モジュールといったものだ。
この投書は昨年4月から1年間続いた日経コンピュータの連載「プロジェクト・マネジャ，意思決定の瞬間」に寄せられたものだった。著者は，長年，日本IBMでプロジェクト・マネジャを務め，数多くの大型プロジェクトを成功させてきた現役プロジェクト・マネジャの岡村正司氏である。同氏が業務設計や基盤システムの記事を書いたときに，このような投書が次々と舞い込んだ。
これらの設計技術や手法はとりわけ大型システムでは必須の構築技術なのに，「業界全体で技術が枯渇しつつある。ユーザー側とシステムを作るベンダー側の双方で，技術を知る人がいなくなりつつある」と岡村氏は警鐘を鳴らす。
なぜ“枯渇”しつつあるのか。おそらくユーザー側にシステムの技術に深い知識を持つ人が少なくなり，ユーザーは要件だけ決めればよいという姿勢になっているからだろう。ベンダー側にしてみれば，基盤システムのようにユーザーが関知せず開発に費用もかかるものはとても作っていられない，というスタンスなのだろう。
本当は基盤システムを作っておけば保守も含めて費用を安くできるが，ユーザー側が基盤システムを求めず，目先の「要求した機能を速く実現してくれ。価格も下げてくれ」とだけ言い続ければ，ベンダーが手間のかかる基盤システム構築作業をやめるのは必至だ。
すなわちユーザーもベンダーも，全体をマネジメントできず，お互いの担当範囲を勝手に決めた結果，ぽっかりと穴が開いてしまったところができた。それが家やビルに例えれば，「基礎」に相当する大切なものだった，という構図になっている。冒頭のエピソードで，アナログが“古い”，“金にならない”技術とみなされ，廃れていったのと似た形になっている可能性がある。
日経コンピュータの宣伝になってしまうが，上記の枯渇しつつある技術を含め，プロジェクト・マネジャが知っておくべき技術の全容を，今年4月からの新連載「プロジェクト・マネジャのためのシステム構築技術 25のセオリー」で岡村氏に書いてもらうことになった。同氏は今年設立したばかりのPMリサーチという新会社の代表取締役としてプロジェクト・マネジャ育成にも力を注ぐ予定で，これを機に熟練スキルを惜しみなく執筆してもらう。また，連載開始にあたって全体概要や大型プロジェクト事例をセミナーで講演する。ご興味がある方はぜひご覧いただきたい（連載とセミナーの概要のページへ）。
2007年問題の対策ともいえる
話を戻す。実は，このような基盤となるシステムの設計のノウハウがなくなりつつある，という話は他の人からもしばしば聞く。詳しくは別の機会に紹介したいと思うが，こういった指摘をされる方はたいてい団塊の世代かそれ以前に生まれた年長者である。
このため情報システム業界から熟練スキルが失われつつあるという2007年問題（注1）の主要な課題の一つは，「基盤システムの設計・実装ノウハウの継承」ではないかと思える。つまり基盤システムとそれに密接にからむ業務設計・概念データモデル設計などの手法が世の中に行き渡っておらず，むしろ失われつつあるのではないか。
注1：「西暦2007年問題」とは，企業の情報システムを支えてきたベテランSEが続々と引退し，熟練スキルが失われていること。CSKの有賀貞一取締役副会長が「2007年には，1947年生まれが60歳になる。団塊の世代でもっとも人数の多いのは1947年生まれと言われている。このため日本の情報化を担ってきた人材は1947年生まれとその前後に集中している。彼らがほぼ完全に引退する時期が2007年だ」と指摘し，これを2007年問題と呼んだ。詳しい経緯は，本格的な議論のキッカケとなった1年前の記事を参照してほしい。
業務設計や基盤システムは拡張性・保守性の向上につながることが多い。しばしば「開発側は開発しっぱなしで，保守・運用のことをあまり考えない」という問題が指摘されるが，基盤システムや業務設計・概念データモデル設計などは，こういう問題への対策にもなるだろう。
ここで読者の皆様にお願いをしてしまう。日経コンピュータでは，「拡張性・保守性を高めるための開発手法・保守プロセスと事例」について，今後取材し報道する計画である。ただ地道な作業のせいか表に出ないことが多いので，優れた事例や手法を皆さんにお尋ねしたい。そういった事例や手法をご存じで紹介可能なら，次のメール・アドレス（ncreader@nikkeibp.co.jp）までお知らせいただけますと幸いです（メールの件名は「拡張性・保守性を高める」でお願いします）。
（安保 秀雄＝日経コンピュータ）
[2003/04/09]
「西暦2007年問題」の解決策を募集します
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20030408/1/
今回は非常に難しい問題を提起してみたい。残念ながら解決策を筆者は持ち合わせていない。ぜひ多くの読者の方々が意見を持ち寄って，対策を考えていただければと思う。「いや，そんな問題は当社にはない」という反論も大歓迎である。
話は比較的単純である。「企業の情報システムを支えてきたベテランSEが続々と引退している。このため，情報システムがブラックボックスになりつつある」ということだ。
CSKの有賀貞一副社長は，情報システムにおけるベテラン引退問題を，「西暦2007年問題」と呼んでいる。「2007年には，1947年生まれが60歳になる。団塊の世代でもっとも人数の多いのは1947年生まれと言われている。このため日本の情報化を担ってきた人材は1947年生まれとその前後に集中している。彼らがほぼ完全に引退する時期が2007年だ」
もちろん，2007年問題は2007年にだけ起きるわけではない。問題はすでに発生している。昨年から今年にかけて相次いで起きている基幹系システムのトラブルの背景には，基幹系の中身を熟知したベテランの不在があるとみてよい。
典型例が昨年起きた都市銀行のシステム障害である。筆者は昨年5月に発刊した「システム障害はなぜ起きたか みずほの教訓」という本で次のように書いた。
「（基幹系システムの）老朽化と肥大化がここへ来て，深刻になった原因は，企業情報システムの規模と複雑さと範囲が，その企業が自分で管理できる限界を超えつつあることだ。しかも，複雑なシステムの全体像を見渡せる人材が減少しつつある。これが一連のシステム障害の底流にある大問題である」
「（複数の都市銀行が）口座振替プログラムという，基本の中の基本でつまづいたのは，ブラックボックスとまではいわないまでも，口座振替の基本的な仕組みを分かっている技術者が現場に少なくなっていることが遠因である」
実際，都銀のシステム統合のさいに，口座振替プログラム部分を担当していたメンバーは若手だったり，さほど詳しくないSEであった。障害が起きて初めて，「すでに退職していたり，関連会社に移籍していた分かるSEを動員した」（関係者）。
OBに聞かないと分からない
これも昨年の話である。ある会合で，ベテランSEの引退問題について説明したところ，会場にいた若いSEから話かけられた。彼は日本を代表する大手製造業の社員で，基幹系システムの再構築プロジェクトにかかわっている。
彼の話はこうである。「過去のシステムに関するドキュメントは残っていますが，実際に作ったわけではない我々が読んでも完全には理解できません。この間，システム部門OBの懇親会がありました。私はこれだ！と思って若手の部下を引き連れ，ドキュメントを抱えて懇親会に押し掛け，その場で大先輩をつかまえて，解説してもらいました。これで，ようやくプロジェクト・メンバーの理解が進みました」
マスターの保守ができない
数年前，サプライチェーン・プラニング・ソフトを販売している企業の社長に聞いた話である。同氏によるとサプライチェーン・マネジメントが進まない大きな理由として，「顧客企業が自分の基幹系システムを修整できない」ことを挙げた。
「サプライチェーン・マネジメントをするときに肝となるのは，製造業でいえば部品表。ところが，多くの企業で部品表は20年以上も前に作られている。このため，だれもさわれない。したがって新しい試みができない」（サプライチェーン・ソフト会社社長）
ある顧客企業は，担当の大手コンピュータ・メーカーに部品表の修整を依頼した。ところが，メーカーも協力ソフト会社に仕事を丸投げしてきており，メーカーの中にも分かる人がいない。ようやくその部品表を開発したソフト会社を探し当てたが，忙しいという理由で協力を断られた。結局，サプライチェーン・マネジメントのプロジェクトは頓挫したという。
ベテランSEには力があった
ここで我が国のコンピュータ導入史を振り返ってみよう。企業の多くがコンピュータ導入に踏み切ったのは，1960年代の後半からである。そのとき第一線でコンピュータ導入を担った若手は今，60歳に近づきつつあるか，すでに引退している。
30年近く経ったとはいえ，彼らが作った基幹系システムはまだまだ動いている。たとえシステム自体は作り直されたとしても，業務の流れや処理の仕組みそのものはあまり変わっていない。このため最初に設計したベテランが基幹系システムの中身について一番詳しいことが多い。また口座振替プログラムや部品表といった重要だが地味な部分は，ずっと同じベテランが保守を担当していることが多く，後継者を育成できていない。
引退しつつある第一世代は強力であった。「初めてコンピュータを入れたとき，たいていの企業は現場の業務に詳しく，論理的な思考ができる若手を集めた。彼らに無理やりコンピュータの基礎と開発言語，そして事務処理の流れをえがく手法を教え込んだ。つまり業務知識，IT，分析手法，そしてプロジェクト経験のすべてを兼ね備えた人材が創られた」（有賀副社長）
これに対し，彼らに次ぐ世代は最初から情報システム部門の要員として配属された。一概には言えないものの，どちらかといえば，システムの専門家が多い。しかもゼロからシステムを作るというよりは，先輩が作った基幹系システムを改良したり，追加のシステムを作る仕事が多かった。
それでも高度成長の時代は次々にシステムを作るプロジェクトが生まれ，経験は積めた。しかしバブル崩壊後，情報システム部門の予算と人員は縮小される一方で，プロジェクトの件数も減った。
にもかかわらず，企業には長年にわたって拡張と保守を続けてきた巨大な基幹系システムが現存している。パッケージ・ソフトへ完全に移行できた顧客企業はほとんどない。必ずなんらかの旧システムは残っている。そしてその中にだれも分からないブラックボックスができつつある。
この西暦2007年問題については，日経コンピュータ誌，日経ビジネスEXPRESS，BizTechでも取り上げた。ビジネスパーソンやITの専門家の方々から意見をいただくためである。
だが解決策を考えられるのは，やはりIT Proの読者であろう。ぜひともご意見をお寄せください。
(ご意見は，下の「Feed Back!」欄をご利用いただくか，電子メールでiteditor@nikkeibp.co.jpあてにお送りください。メールの場合には題名に「2007年問題係あて」とお書きいただければ幸いです)
（谷島 宣之＝ビズテック局編集委員）
■筆者のコンテンツを集めたページ「谷島 宣之の情識」もぜひご覧ください。
＜“谷島の『読者との対話』”＞
■読者の批判に応える――マスコミを徹底して嫌ったIBM会長について (2003/03/10)
■再取材！「絵を描くコンサルタント」は実話 (2003/02/10)
■読者96人の意見に答える――「動かないコンピュータとコンサルタント」問題について(1) (2003/01/27)
■エンジニアの皆さん，もっと経営者に意見しませんか (2003/01/09)
■「動かないコンピュータ」は無くならない (2002/12/12)
■「動かないコンピュータ」とコンサルタントの関係 (2002/10/31)
■「『情識』に還れ」について (2002/10/28)
■【投票結果発表】続・投票をお願いします！「保守/運用」の代替名 (2002/10/09)
■続・みずほ銀行システム障害に見る「動かないコンピュータ」の根本原因 (2002/05/30)
題名には必ず「阿修羅さんへ」と記述してください。