ＩＴ維新研究所

◆データセンターにもエコ対策が不可欠

◆データセンターもエコ対策が必要◆

【はじめに】

ＣＯ２増加の影響でしょうか、台風までもが凶暴化してきているようです。

日米とも、民主党政権の成立により、従来の考え方からの大きな「変革」の
コンセプトが胎動しつつあります。

自動車産業は、電気自動車化の方向に向かっています。
この電気自動車化が進行すれば、エンジン技術をベースとしてきた従来の製造業
の産業構造に大きなインパクトとなり、自動車産業を支えていた下請け企業に
大きな変革を迫ってきます。
日本の景気にも大きな影響を与える問題へと発展していきます。

電力も太陽熱発電の普及、それ以外にも自然エネルギーの利用とCO2削減対策が
進行しています。省エネ分野の新規の技術分野も続々と開発されています。

各業界で、各種の省エネ施策が大きな注目を浴びています。
省エネを起爆剤として、新たな産業革命が着実に進捗してきている実感があります。
地球環境にやさしい産業政策が求められているのです。

ところで、

ＩＴの世界でもユニークな省エネ思想のコンセプトが実現していることをご存知ですか。

それは、サンマイクロシステムが発表している「Sun Modular Datacenter」です。

新たなＩＴの省エネシステムとして注目されています。

今回は、この「Sun Modular Datacenter」についてコメントしてみたいと思います。

【コンテナ型のデータセンターの概要】

コンピュータセンターを構築するとなると各種の周辺の環境設備が必要となります。

これらを輸送用の通常のコンテナーに組み込んだものが、このシステムのコンセプトです。

輸送用のコンテナーですから、データセンターをトラックでどこへでも運ぶことが
できます。
データセンターごと移動できるシステムです。

応用範囲としては、急激なコンピューターパワーの増強対策としての活用、
災害時の非常用対策システムとしての活用等々といろいろです。

【このシステムの特徴】

このシステムの特徴を要約すると、

１）【時間短縮】従来型のデータセンターに比べ、10分の1の時間で展開が可能
２）【コスト削減】拡張に際するコストの削減に貢献
３）【柔軟性】ニーズに応じて様々な場所へ柔軟に実装が可能
４）【高度な実装密度】従来型のデータセンターに比べ、4倍も高い実装密度を実現
５）【省スペース】従来の8分の1のスペースで設置可能
６）【省冷却コスト】40％も冷却コストを削減
７）【耐震性】マグニチュード6.7の地震にも耐えられる

輸送用のコンテナーにデーターセンターを詰め込むという発想自体は、
ジョークからの発想のようにも思えますが、これらの特徴を実現するための背景には、
高度な実装技術を装備する必要があったようです。

【実装のための技術】

「Sun Modular Datacenter」はわずかなスペースで高密度な演算環境を提供しています。

14.86平方メートルの床面積を持つ「Sun Modular Datacenter」には、ネットワークと
システムの管理用のラック1台（12.5KW給電）と、
サーバ／ストレージ／その他の機材を搭載するためにラックが7台（各最大25KW給電）
搭載されています。

各ラックのこれらの値は、従来型のデータセンターの約4倍の密度です。

また効率的な冷却環境を備えているため、新世代のブレード型サーバにも最適な
プラットフォームが提供されています。

高密度のＣＰＵパワーの実装のためには、発生する熱の冷却技術が不可欠です。
冷却技術にも各種の工夫が実装されています。

エネルギー効率と冷却効率に優れたSun Modular Datacenterは、
理想的な統合化／仮想化プラットフォームを提供することで、
データセンターの複雑性削減に貢献しています。

【地球環境への配慮】

「Sun Modular Datacenter」は、卓越した経済性を提供するだけでなく、
地球環境へも配慮した製品です。

プラットフォーム毎にCO2の排出量を5年で1459MT（メートルトン）削減可能なため、
新たな環境規制への対応も支援しています。

循環式の水冷システムを搭載している「Sun Modular Datacenter」は、
一般的なデータセンターに比べ40％以上もエネルギー効率に優れた冷却方法を
実現しています。

限られた空間で高効率な水冷システムを利用することで、空調装置を利用している
データセンターに比べてサーバ1台あたりのエネルギー消費量を抑えることに
成功しています。

また、電力代金の安価な場所へ設置することで、更に電気代を削減することも可能です。

環境への配慮とeWasteの削減に取り組んでいるSunは、
不要になった「Sun Modular Datacenter」とその搭載機材の回収も予定されています。

世界中のあらゆる場所から「Sun Modular Datacenter」と搭載機材の全てを回収し、
環境に配慮した方法で再生／再利用されます。

【まとめ】

ＩＴの世界の技術進歩の歴史は、いろいろとありました。

この中で、実務担当者の中で問題になるのが、
ＩＴシステムを取り巻く設置環境の問題です。

データセンターを正常に稼動させるための設備環境対策が大きな問題なのです。

耐震設備は勿論のこと、電源設備、空調設備等々とＩＴシステムを稼動させる
ためには、周辺設備のノンストップ化のためのバックアップ対策が重要課題なのです。

これらの問題点を輸送用のコンテナーに詰め込んだものが、
今回紹介した「Sun Modular Datacenter」です。

トラブルが発生した場合には、このコンテナーごとでバックアップが可能ということです。

不要になった、コンテナ型のデータセンターの回収までも対応する。
ＩＴメーカーもここまできたのかと思います。

地球環境をこれ以上悪化させることなく、ＣＯ２削減のための諸施策が
あらゆる分野で不可欠な時代になってきています。

ＩＴ業界においても、各種の省エネ対策システムが必要ということです。

◆可視化と仮想化について

可視化と仮想化について

【はじめに】

最近気になる言葉に、可視化と仮想化という言葉があります。

可視化と仮想化は、別次元の用語ですが、可視化は、抽象的なもの、
曖昧なものを可視化することにより、イメージを具体化するということです。
最近は「見える化」という言葉も使われています。

一方、仮想化は、物理的、固定的なものを、柔軟に、自由に利用し、
物理的な制約を排除するという意味です。

今回は、この仮想化という言葉をとりあげてみました。

【仮想化について】

ＩＴ分野において、プロセッサやメモリ、ディスク、通信回線など、
コンピュータシステムを構成する資源、および、それらの組み合わせを、
物理的構成に拠らず柔軟に分割したり統合したりすることと定義されています。

具体的には、1台のサーバコンピュータをあたかも複数台のコンピュータで
あるかのように論理的に分割し、それぞれに別のOSやアプリケーションソフトを
動作させる「サーバとＯＳの仮想化」や、複数のディスクをあたかも1台のディスク
であるかのように扱い、大容量のデータを一括して保存したり、障害発生時の対応力
を強化する「ストレージ仮想化」などの技術があります。

【サーバーとＯＳの仮想化】

サーバとＯＳの仮想化とは、1台の物理的サーバを複数の論理的サーバに
分割することであり、パーティショニングと仮想マシンの2つの方法が存在しています。

パーティショニングとは、複数CPUを実装しているサーバ内を区切って、
複数のOSを起動させ、あたかも複数のサーバが動作しているように見せる技術です。

一方のＯＳの仮想化とは、ＯＳのシミュレーターを通して、仮想化を実現する方法です。

【ストレージの仮想化】

ストレージの仮想化は、種類の異なるストレージやメーカーや仕様の異なる
ストレージを仕様や機能の違いを吸収するためのインターフェイスソフトを
導入して「仮想ストレージ・プール」として一元化します。

この仮想化のメリットは、既存のバラバラのストレージ資産を一元管理する
ことにより、無駄な余剰スペースを有効活用することです。

また、デバイスごとの管理コンソールも一元化することができるため、
運用オペレーターの管理も容易になり、オペレーターの管理コストを
削減することも可能になります。

【ITインフラの統合化と仮想化】

サーバーやＯＳの仮想化を更に統合化して、複数の物理的に分散独立して
稼動している情報システムのサブシステム群のインフラを統合的に管理する
方法の事例が報告されています。

ITインフラを統合する目的は、システムの複雑性を改善し、投資の最適化を行い、
さらには変化への対応力を向上させ、セキュアで安定的な稼働によって
コンプライアンス要求に応えることにあります。

【ITベンダーと仮想化技術による統合化システムの提供事例】

仮想化技術を統合した、「次世代ITインフラのコンセプト」が各ベンダより
発表されています。

各社の次世代ITインフラはネットワーク、ストレージ、サーバなどのシステム資源を
仮想的に共有する「リソース・プール」という概念です。

リソース・プールはアプリケーションからITリソースを分離させ、
必要な時に必要な資源を割り振るというもので、ビジネス変化に対する
ITシステムの対応力を向上させ、システムごとに処理のピークに耐えられる
能力のバランスとることにより、投資の最適化が期待されます。

【仮想化技術によりＩＴシステムを最適化し、コストを削減を実現】

ビジネス環境への変化に対応するための業務アプリケーションの効率的な
開発努力の一方で、IT関連の運用コストを削減しながら、
複雑化したITインフラの最適化を進める必要があります。

複雑化してしまったITインフラは、コストの増加や管理性の低下を生むと同時に、
企業のダイナミズムと競争力を支える基盤とはなりえません。

ITインフラの統合を行う場合は、サブシステムごとの部分最適化に陥ることなく、
ITインフラ全体の最適化を推進することが重要です。

「情報インフラストラクチャの全体最適化」という概念があることを知りました。

情報システム全体のＩＴインフラを仮想化技術を利用することにより、
全体的に最適化していくアプローチが必要ということです。

【注】具体的には、参考資料として、EMC2のホームページをご参照ください。

　http://japan.emc.com/services/information-infrastructure-consulting.htm

【まとめ】

ＩＴシステムは、企業活動の必須の要件となってきていますが、ニーズに応じて、
個別の情報システムが開発・メンテナンスされています。

この結果として、複数のサブシステムが存在し、各々のサブシステムは、
常に部分最適化のための投資を繰り返してきています。

部分最適化は、全体的な視点で分析すると、
無駄の多いシステム構成になってしまっています。

そこで、この部分最適化を繰り返すサブシステムのインフラを全体的な視点から
見直し、仮想化技術の導入により統合化していきます。

そして、統合化されたシステムの全体最適化を追求していくことにより、
現在のＩＴ投資コストの大幅節減が可能となります。

先行きが不透明な時期こそ、「情報インフラストラクチャの全体最適化」
の概念のもとに、情報システムを見直すと同時に、
ＩＴ投資削減に取り組む絶好のチャンスと思いますが・・・。

◆年金管理システムの不備に関して

社会保険庁の年金管理システムの不備に関して

◆はじめに

平成１９年の参議院選挙で与党が大敗しました。

原因はいろいろあると思います。

しかし、敗因のひとつに「年金の問題」があったことだけは確かのようです。

年金管理システムの不備が原因のひとつのようです。

事務処理の不備、システム管理の不備が国政を左右するとは・・・・？。

今回はこの「社会保険庁の年金管理システム」について考えてみました。

◆「社会保険庁のシステム管理不備」とは？

社会保険庁の年金管理システムが不完全で、年金記録が正確に把握されて
いないために、もらえる年金がもらえない。

年金を収納したものの誰の年金かが不明で宙に浮いている積立金が存在する。

紙ベースのままで、コンピュータに入力されていないデータ移行未済の年金
が存在する。

等々と「年金の事務管理システム」の不備が指摘されています。

いろんな意味で、現行の年金管理システムは、欠陥を抱えながら運用されて
おり、年金受給対象者にとっての不信感を招く結果となっているのです。

この不備の多いシステムを放置していたことの責任が参議院選挙にも反映
したのです。

与党にとって、システム不備の露呈は、「人災」ということです。

「年金管理システムの欠損」に学ぶという観点から考察してみます。

◆なぜ、システムの不備が糾弾されているのか？

「年金管理システムの不備」が指摘されていますが、成人した日本国民
の全員を対象とした大規模システムの恐ろしさを露呈した事例として捉える
ことができます。

もともと、年金管理システムは、手作業で管理していたものをコンピュータ
システムに移行する過程で起こる、コンピュータ化のトラブル事例のひとつ
という捉え方もできます。

バンキングオンラインで預金元帳をオンライン元帳に移行する過程で生じた
体験や、マル優の管理の問題、カナ元帳から漢字元帳への移行、印鑑イメージ
の登録移行とバンキングシステムの新システム導入に伴う移行上で発生する
事象から類推できる事象と極似しています。

この視点から、年金管理システムの欠陥の発生事由を類推してみました。

そもそも、制度発足時の手作業で管理しているシステムは、当然のことながら
コンピュータ化を前提としているわけではありません。

手作業で処理するのに都合のよい管理システムとなっていたはずです。

しかし、手作業プロセスには、プロセスの段階段階で必ず事務ミスの発生の
可能性が存在します。

まず、この手作業での事務管理システムが正確に運用されていたのかが問題
となります。

十分な事務ミス防止のための事務手続きがどれほど厳格に管理されていたか
に疑問が残ります。

お役所仕事の事務品質管理思想がどの程度浸透していたかです。

手作業管理システムでの事務ミス防止策には限界があります。

そこで、この手作業事務作業の事務ミスを減少させ、大量の事務処理に対応
するために出現してきたのがコンピュータです。

コンピュータ化により、大量事務処理の事務合理化が推進されてきました。

しかし、手作業事務処理体制から、コンピュータシステムへの移行は簡単
ではありません。

大量の移行事務負担を伴います。

手作業で利用されていた台帳をコンピュータの台帳に正確に移行することが
必要ですが、この移行過程の事務精度が問題になります。

この過程で移行事務ミスの発生の可能性が増大します。

社会保険の場合には、社会保険番号、氏名、生年月日、住所、その他属性、
年金収納金額記録等が基本データベースになります。

それ以外に、所属保険事務所、厚生年金収納企業、収納遅延データと収納結果、
過去にさかのぼっての収納記録等々と管理すべきデータ項目は多く、
データボリュームも半端なものではありません。

処理するためには、相当のコンピュータパワーを必要とします。

現在のコンピュータパワーと比較して、移行当初のコンピューターパワーは
弱小であり、システムの運用には相当の苦労があったものと推察されます。

年金管理システムは、制度変更や例外管理等のシステムの複雑さとデータ
ボリュームの規模から推定して、システムの運用は決して簡単なものではない
ものとと思われます。

そして、この年金管理システムに含まれる問題点のひとつに、
「氏名」、「生年月日」、「住所」という基本項目が管理の対象となって
いることが元凶となっているのです。

第一項目の「氏名」ですが、このデータ項目は扱いにくいデータのひとつです。

氏名の読み方は様々です。利用されている漢字も当用漢字以外の漢字が利用
されています。

この氏名データのカナ変換入力時に読み違い入力ミスの問題が発生します。

記入者の書いた文字が略字となっていたり、文字が達筆すぎて読み取れなか
ったり、逆に、みみずの這うような文字というか、下手で誤解を招くような
筆跡の文字であったりで入力ミスの可能性が増すことになります。

「氏名」は、姓と名に分かれるわけですが、この「姓」は、養子縁組や結婚
等で同一人物でも「改姓」という事象が発生します。

離婚により、元の「姓」に戻る場合も、戻らない場合も存在します。

「名前」も、戸籍上の名前と通称の名前を使っていたり、当初戸籍上に登録
した名前でも法的手続きにより変更される場合もあります。

「同姓同名」、「類似名」等と姓名を扱う事務では、事務ミス発生要因は
数多く存在します。

次に、第二項目の「生年月日」ですが、西暦４桁、誕生日の年月の４桁数字
の計８桁の数字ですが、３６６通りの数字しかありませんので、重複の
可能性は多くなります。

移行過程で、明治・大正・昭和・平成の年号を西暦に読み替える場合に
和暦と西暦の変換ミスを生じる場合もあります。

「生年月日」の８桁の数字すら正確に入力されているとは限りません。

「生年月日」をキーとして検索しても、重複対象が多すぎて単独での
検索キーにはなりえないのです。

第三の項目の「住所」ですが、このデータもコンピュータ処理には厄介な
データ項目です。

「住所」には、郵便番号が入力されていると思いますが、この郵便番号体系も
当初の体系から桁数が増えました。
また、時々変更になります。

住所表示に関しては、旧戸籍の表示と新住所表示の二通りの表示形式で
新旧の方式が存在します。
住所記述の仕方も必ずしも統一されていません。

更に、住所表示は、行政区分の変更等で住所変更が度々行われます。

これらの変更を正確にフォローするということは、コンピュータシステムの
データベースを管理する上でも容易なことではないのです。

年金積み立て者側でもこの住所変更をきめ細かに申告登録しているわけでも
なく、社会保険庁側のシステムでも正確にフォローするためのシステムが
整備されているとも思えないのです。

銀行の場合には、住所コードという外部購入のデータベースのコードを利用
していたのですが、このコードのメンテナンスも相応の負荷がかかっていま
した。

この対象が全国ベースの年金対象者全員に関わってくるとなるとデータ更新
にも相当なコンピュータパワーが必要となるのです。

以上のたった３項目の「姓名」「生年月日」「住所」というデータだけでも
コンピュータにインプットする段階でのミス発生の要素が多いのです。

この三項目の正確なインプットを年金対象者全員のデータベースとして管理
することがいかに難しいことであるかは、コンピュータシステムの開発運営に
関与した読者にはご理解いただけると思います。

決して、「社会保険庁のシステム不備」を擁護する積もりはありませんが、
システム運用上では、相当に困難なシステムであるということは確かです。

【編集後記】

本件は、コンピュータ入力と事務運用システムの基礎の基礎の問題なのです。

コンピュータにいかに正確にデータを入力するかは重要なことです。

「ＧＩＧＯ」という言葉があります。

「ガベッジ・イン・カベッジ・アウト」の略称です。

如何に立派なコンピュータシステムであろうと、データの入力管理がズサン
であれば、システムの価値が低減するのは当然のことです。

コンピュータ化に携わる人間は、この「インプットの重要性」を再認識
すべきです。

■システム開発バブルの再燃か？

■システム開発バブルの再燃か？

【はじめに】

２００６年新年の最初のトピックスは、三菱東京ＵＦＪ銀行のシステム統合の第一次段階が終了したことです。

これにより、三菱東京ＵＦＪ銀行の約９千台の現金自動出入機（ＡＴＭ）や窓口で、通帳記入や預け入れが相互にできるようになりました。

今回のシステム統合に関しては、金融庁の指導等もあり、システム統合のリスク懸念から当初計画を延長してのスタートでした。

今回のシステム統合は、旧東京三菱銀行と旧ＵＦＪ銀行のコンピュータを相互接続し、相互乗り入れを可能にするだけのシステムです。

しかしこの単純とも思えるシステムでも「みずほ銀行」のスタート時には、大トラブルに発展してしまったわけで、今回は慎重を期したということです。

オンライン接続上では、大きなトラブルはなかったものの細かい点ではいくつかのミスが発生したようです。

総合振込の入金口座変更依頼書の内容で５８５社３４９５明細の出力ミス、非居住者向けカストディ業務の事務処理遅延等が公表されたトラブルです。

内部の管理資料等でのトラブルについては銀行内部の問題であり公表はされていないので不詳ですが、ともかくも無事に難局を突破したことだけは確かのようです。

【三菱東京ＵＦＪ銀行について】

今回合併した新銀行の「三菱東京ＵＦＪ銀行」は、「三菱ＵＦフィナンシャルグループ」の中で、社名に「東京」の文字が残っています。
旧東京銀行との残存の名前ということです。

同じ三菱ＵＦフィナンシャルグループの信託、証券、投信には「東京」の文字がないのは従来の合併の経緯によるものです。

この東京の二文字にはいろんな思いがあるものと推察されます。

しかしながら、合併後の三菱東京ＵＦＪ銀行は、ライバル他行である
「みずほ銀行」、「三井住友銀行」を圧倒する規模です。

国内の有人店舗数は、６７２店、取引先企業が約３８万３千社。

海外の４０カ国以上に支店や出張所など８９拠点を持つというグローバルバンクとなります。

資産規模も１６０兆円、グループの口座数４千万と世界最大規模の銀行が誕生したことになります。

さて、この三菱東京ＵＦＪ銀行は、当初は２００５年１０月に合併予定であったのが、金融庁の指導もあり、三菱東京とＵＦＪ両行のシステムの結合テストを完璧にするとの理由で年明けの合併に延期したことはご存知のとおりです。

この延期の期間に、５回の全店テストも順調に行われ、２００５年１１月８日にテスト完了の宣言をしています。

そして、１２月からは両行のＡＴＭの相互乗り入れが開始され、オンラインの結合システムを予定より一ヶ月早めに稼動させています。

しかしながら、三菱東京ＵＦＪ銀行のシステム統合はこれからが大変ということになります。

システム統合は次のＡ．Ｂ．Ｃ．の３段階に分かれています。

Ａ．合併時の相互乗り入れ（Day１）、２００６年１月４日完了。

Ｂ．約２年後の旧東京三菱のシステムへの旧ＵＦＪのシステムの移行
（Day２）、

Ｃ．それから新システム開発(Day３)です。

システム開発部門は休む暇はありません。

行員は勿論のこと、コンピューターメーカー、システム開発会社は当分の間は、仕事探しに苦労することはなさそうです。

営業店端末などは、Ｂ段階で更改されることになるのでしょうからハードメーカーも合併特需が発生します。

ホストコンピュータは、ＩＢＭに統一され、端末は富士通ということになるのでしょう。

ＵＦＪ銀行のシステムメーカーであった日立は大きなシェアを失うことになるという構図になります。

【その他の新システム開発】

一方、「みずほフィナンシャルグループ」も、リテール分野のシステムを１インフラ、２アプリで新規開発の予定だそうです。

２００６年秋から本格開発に入り３年程度で稼動させる計画のようです。

メガ・バンクの新システム開発規模は、オンラインのアプリ・ステップ数で３千万ステップ以上、バッチ処理システムでは、５千万ステップ以上あります。
仮に８千万ステップを開発するとすれば、少なく見積もっても８万人月の開発パワーが必要となる計算になります。

更には、各種システム間のインタフェースやデータベースの移行システム等が必要となり、指数関数的に開発量が増えるのが通例ですので、少なく見積もっても、１５万人月以上の開発パワーが必要となります。

三菱東京ＵＦＪ銀行の新システムの開発、みずほ銀行の新システム開発、郵政公社の民営化対応システムの開発、それに、三井住友銀行の新システムの開発も加わるかもしれません。

日本の巨大金融機関が四つ巴で新システムを開発することになれば、システム開発バブルが発生することだけは確かです。

１９９０年代の第三次オンラインの開発時に、都銀各行が一斉に開発に着手したために、開発マンパワーが不足して、ソフト要員の調達コストが上昇し、要員の質も低下の現象が生じました。

銀行に限らず、その他の業界でもシステム開発要員のニーズは高まっています。東証オンライン等の大規模なシステム開発の計画等も発表されています。

開発マンパワー市場の需給バランスが崩れることは確実です。

開発要員不足を中国やインド等に依存するという方法もありますが、
金融分野においては困難を伴います。

巨大規模の金融関連プロジェクトが何本も並行して走るわけですが、金融業務関連のスキルを持ったＳＥ数が何人存在するのでしょうか？

金融機関のシステムの開発言語は、コボルかＰＬ１を利用していますが、これらの言語を得意とする要員の調達は大変困難になっています。

既存のコボルやＰＬ１の開発言語を残しながら、新世代の開発言語であるＪａｖａ言語等を活用しようとすれば、開発言語の統一性の問題も発生します。

今回の新システムの開発には、規模の大きさだけでなく、新旧開発要員の世代ギャップの問題、開発インフラ・開発言語等の統合化の問題等の数多くの問題が発生します。

新規開発の分野の業務開発言語は、Javaで開発することが考えられますが、金融業務を理解していてJavaを使いこなす優秀なＳＥ要員の調達は決して簡単ではありません。

バンキングオンラインは、日々新たな機能追加を要求されます。

現行システムの機能拡張を行いながら、新システムを開発していくということが、いかに大変なことであるということを経営者は理解する必要があります。

【まとめ】

金融システム開発分野における「新システム開発バブル」が再燃してくることは確かです。

システム規模が大きくなると、システム要員の調達が困難、システム要員の質が低下、大規模システムのプロジェクトマネジメントの困難さの拡大、システム障害テストの範囲の拡大、信頼性に関する要求水準の高さ等々と今後の金融システム開発分野は各種の問題を抱えています。

２００６年から２０１０年までの５年間はシステム業界にとって大きな
転換期を迎える時代の到来を予感させます。

システムバブルが再燃し、バブルである以上いつか必ずはじけてしまうという現象を再び繰り返すことになりそうです。

■みずほ証券のミスインプットの教訓

　今年も残り１０日余りとなってしまいました。

　不動産の耐震計算のプログラムに不正なデータを入力して、構造上の問題点を偽装した事件が大きな社会問題となっています。

　コンピュータの出力を信頼してしまう風潮から入力の不正を見過ごしたとのことです。

　また、みずほ証券の株式売買取引の誤入力に関しも大きな損失が発生するという事件が発生しました。

この両事件とも、コンピュータ処理の入力段階の誤操作（耐震設計に関しては意図的な不正入力）により、大きな損失を発生する事件となってしまいました。

コンピュータ社会が進展する中で、コンピュータシステムが社会に与える影響の大きさを再認識する事件であると思います。

大規模なオンラインシステムの障害は、時々マスコミを賑わすニュースになる場合が多いのですが、マスコミの話題とならないシステムトラブルは日常茶飯事に発生しているのです。

システム開発を担当している人間にとっては、今回の事件は、「対岸の火事」として傍観していられる問題ではありません。

コンピュータシステムに対する基本的な問題として、再考すべき問題といえます。

ところで、われわれが若い頃に言われたことがあります。

それは、「コンピュータ利用の三原則」という基本ルールです。

１）インプットがなければ、アウトプットもない。
２）論理が組めないものはプログラム化できない。
３）最終的には、人間の管理能力を組み込むこと。

以上の三原則です。

　システムの規模やシステムの内容により、解釈は様々ですが、今回のみずほ証券事件に関して、当てはめて考えてみたいと思います。

■１）インプットがなければ、アウトプットもない。

　これは、言うまでもないことですが、みすほ証券の端末入力で、新規上場のジェイコムの株式の売り注文をインプットすることが事件の発端となっています。

みずほ証券の担当者が、午前の取引開始直後、コンピューター端末で「６１万円で１株」の売り注文を出すべきところを、誤って「１円で６１万株」と誤入力してしまったことです。

この操作が異常であるということをシステムでも認識していたようで、警告メッセージが出ていたようです。しかし、この警告メッセージを無視して、売り注文がコンピュータにインプットされてしまったようです。

ここから、問題が発生することになったわけです。

　コンピュータシステムの設計で最も重要なことは、インプットシステムの設計であると考えています。

　いかに、誤ったインプットデータを排除するかが、システム設計上の【重要】な課題となります。

　異常なインプットデータにより、システムの異常やデータベースの異常処理が発生するからです。

　いかに、クリーンで正当なデータのみをインプットさせるかが【重要】なのです。

　今回の場合には、ジェイコムの発行済み株式１４５００株の約４０倍の取引ということで、取引自体が成立しないインプットであることは自明なのです。取引株数の限度や存在可否チェックを行えば異常であることは明白であったはずです。

　また、株価の１円も、上場の初値予定が６０万円前後の水準であり、この値段よりの乖離度から判断して異常であることも自明なのです。

　上記の二条件から判断しても、インプット拒否すべき処理であることは自明であり、警告メッセージで済ませるべきインプットではないはずです。

　どうしても、例外的なデータをインプットする必要があれば、例外インプット処理用の端末インプット画面を設定し、厳重な承認処理手続きを経てインプットすべきなのです。

　全くの初歩的な部分のミスを排除すべきシステムが組み込まれていないことが根本的な原因ということになります。

■２）論理が組めないものはプログラム化できない。

　この原則は、コンピュータは万能と考えている人がおり、コンピュータに過大な期待を寄せすぎる人に対して説得するときに利用する原則です。

　設計する人間が論理的に考えて、ロジックとして組み込むことができないものは、コンピュータ処理不能であり、システム化できない部分であり、人的な対応が必要であるという意味です。

　また、論理的に組み込むことが可能でも、コンピュータの処理能力の限界を超える処理はシステム化できない場合も多いということです。

　今回の誤インプットは、論理的に組み込むことが可能なものであり、当然システム設計の段階で組み込んでおくべきロジックと言えます。

　この点では、東証側のシステムの欠点を露呈したことになります。

■３）最終的には、人間の管理能力を組み込むこと。

　コンピュータシステムも所詮は人間が作り上げたシステムに過ぎません。

　配慮不足や機能不足は数多く内包するシステムであるということです。

　いわゆる、明確にバグといわれる異常な動作以外にも、今回のような機能設計上の漏れが存在するということです。

　通常は起こりえない「想定外」のトラブルが発生することは、システム開発に関与した人間ならば実感できる現実です。

　異常事態が発生した場合を想定して、システム上は、強制取引処理というものを組み込みます。

　取引処理を人為的に強制的に停止する機能を組み込みます。

　停止には、全面的にシステムを停止するケース、部分的な限定した取引を停止するケース、異常な取引のみを停止するケースといろいろあります。

　今回のケースでは、みすほ証券の取引のみを取り消す処理が当然組み込まれていたはずですが、これが正常に機能しなかったということが、損害を大きくした要因となっています。

　損失を東証にも負担させるということになる根拠になっているようです。

　誤入力に気がついた場合には、端末インプット側から取消処理するケース、コンピュータセンターの管理者による強制取消処理が当然組み込まれているはずです。

　これが、今回のケースでは、取消処理が正常に作動しなかったということで、被害が拡大することになったようです。

　しかし、コンピュータシステムが正常に稼動しなかった場合でも、システム運営者から全端末に異常取引の停止メッセージを発信することも機能としては組み込まれているはずで、このメッセージを発信すべきであったとも思われます。

　マスコミを利用しての広報の方法もあったはずです。

　残念ながら、システムの異常動作は、よくあることであり、異常が発生した場合には瞬時の状況判断を要求されます。

　コンピュータ管理者には、迅速な対応処理が求められることになるのです。

　即ち、どんなに精緻に作られたシステムでも最終的には、「運用・管理する人間の能力」に依存することが大ということになります。

　人間の管理能力とコンピュータの処理能力の両者の能力を組み合わせた「マンマシンシステム」の設計が【重要】という教訓となります。

　以上、「コンピュータ利用の三原則」をみすほ証券事件に当てはめ、簡単に考察してみました。

■それにしても、みずほ証券の誤発注問題では、わずか１６分間の間に「結局は４００億円」の損失が発生したわけですから、コンピュータ社会の脆弱性を再認識する契機となります。

　最近では、個人でも、ホームページの画面を１回押すだけで、株の取引や買い物が瞬時に成立する時代になっています。

　われわれの身近な問題として、単純なインプットミスの怖さを再認識すべき事件であったといえます。

　みずほ証券と同様の株式取引の発注ミスは、２００１年の電通の株式上場の際にも起ていました。外資系証券が「６１万円で１６株の売り」とするところを、「１６円で６１万株の売り」と誤って発注したケースだったようです。

　株数と株価の入り繰インプットミスは発生しやすいということです。端末のインプット画面の設計に問題があるのか、インプット指図書の設計に問題があるかの原因を追究し、再発防止対策を厳重化すべきであるのは当然のことです。

　同じ２００１年、別の外資系証券もいすゞ自動車株の９万株の売りを９０００万株の売りと誤発注した事例もあったようです。

　急増している個人投資家のネットでの株取引も、コンピューターに株数、売買価格を書き込んで売り買いするという意味ではみずほ証券とまったく変わりません。

　個人取引の場合には、個々人の預かり株数や個人の信用限度により取引の異常を発見する仕組みが組み込まれているはずですから、今回のような大事件にはならないとは思われますが、大なり小なりのリスクが発生することは事実です。

　株取引以外でも、一昨年には総合商社丸紅のネット直販サイトでＮＥＣ製パソコンの販売価格１９８０００円を１９８００円とゼロを一桁ミスインプットし、買い注文が殺到した事件を思い出します。結局、丸紅は１９８００円で販売せざるを得なくなり、約二億円の損害を出したとされ、直販サイトは閉鎖されてしまいました。

　システム設計に係る人間にとっては、システム設計上で、いかに誤操作や誤入力を発見し、排除するシステムを組み込むか。

　誤操作や誤入力が発生した場合でも、システムの被害が拡大する前にシステムの機能を取り消す方法を組み込みか。

　異常事態が発生した場合に、組織として異常事態に対応するための人材の教育と訓練を心がける必要があります。

　また、個人的にネット取引の利用者立場としても、単純なインプットミスから大損害を発生させるネットワーク社会にわれわれは生活している訳であり、最後のインプット確認には細心の注意が必要あるということを肝に銘じておきたいものです。

【編集後記】

　みずほ証券の決着は、みずほ証券の４００億円の実損発生、東証トップの退任と減俸、富士通の経営幹部の減俸処理ということと、誤入力と気付きながら、大量の株取引により利益をあげた大手証券会社の利益処分の問題へと決着に向かいつつあります。

　しかし、この問題は、各方面に大きな後遺症を残すことになるものと思います。

　システムに係る者として、大きな教訓としたいものです。

　今回のメールは、今年最後のメールになるものと思います。

読者の皆様には、今年もこのメールをお読みいただきありがとうございます。

来年も、その時々のトピックスを捉えて、コメントしていきたいと思います。

来年もよろしくお願いいたします。