PR

 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)までお知らせいただけますと幸いです(メールの件名は「拡張性・保守性を高める」でお願いします)。

(安保 秀雄=日経コンピュータ)