» 【第112号】欠陥システム構築を防止するには

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第112号】欠陥システム構築を防止するには

暖冬改め寒冬のお正月はいかがでしたでしょうか。鳥でなくてもインフルエン
ザに気をつけて、元気にこの冬を乗り切りましょう。
■他山の石
姉歯建築士の問題が騒がれています。建設コストを下げるために、ごまかして
鉄骨・鉄筋を抜いて震度5で倒壊する欠陥建築を作ったと言う話です。ポイン
トは
(1) 誰しも巻き込まれる可能性のある、命にかかわる身近な問題である
(2) 信じられないごまかし、モラルの低下
(3) 責任者が直ちに特定できない体制の不備
(4) 虎の子の大金が無駄になる、そして時間がとられる
などにあるかと思われますが、これを欠陥システム問題と対比してみるとどう
なるか、他山の石として考えてみました。


(1)は、情報システムの欠陥によって命の危険が直接発生することはない、と
考えられるので除外することができます。それゆえに、また多くの人にとって
身近でないと考えられるため、なかなか手が打たれず、毎年多大の保守費を投
入して使い続ける、といった結果を招いています。
(2)はn千年の歴史を持つ建築とn十年の歴史しかない情報システムを比較す
ることに若干無理があるかとも思われますが、方法論が未熟で、建築基準法相
当のものがないだけに、何が違法なのかすらはっきりせず、ごまかしの定義が
はっきりしないという意味において、除外せざるを得ないようです。
(3)もRFPや要求仕様があいまいなため、日経コンピュータ「動かないコン
ピュータ」で報じられているように、同じ問題が、よりあいまいな形で存在し
ます。CF0、CIO、経営企画、システム企画、ビジネスユーザ、エンドユ
ーザ、データ管理者、システム部長、PM、SIer、SE、プログラマ、
などケースバイケース多様であり、ここでは省略することにします。
■情報システムへの負荷
そこでここでは、(4)について考えるものとします。姉歯問題の中心は、「震
度5で倒壊する」ということですから、「所定の負荷に耐えられない」という
こととして考えます。したがって、情報システムも、その負荷に耐えられない
という面から考えて見ます。
負荷は、かつては「データ量・処理速度・レスポンス」などが中心でした。イ
ンターネットでは「アクセスが集中して動かない」ことが時折あると聞きます
が、IT技術の進歩によって、これらは大幅に解決されてきたといえるでしょ
う。次に「誤使用対策」があります。みずほのジェイコム株1円売却はこの対
策不備によって発生したとも考えられます。データ項目の取るべき値の範囲が
適切に規定されていれば、処理が進まないようにできるからです。しかし商品
Aを商品Bと取り違えて発注しても、これをチェックする仕掛けはできません
から、部分的対策にとどまります。
したがって、情報システムへの負荷として今最も重要なものは、「ニーズの変
化や、これに対応して発生するITの変化に即応できる」ということではない
でしょうか。競争優位のために、RFIDやWeb化に取り組まなければなら
ない。また、全体最適のために、A2A(Application to Application)やB
2B(Business to Business)のデータ流通・データ標準化をすばやく実現し
なければならない。この負荷が震度5のように迫ってきている、と目覚めたC
IOや情報システムマンは気づいているのではないでしょうか。
■情報システムは個別でない
建物は個別に扱うことができますし、それが個別であることが、建物はハード
ウエアであるため一目瞭然です。しかし情報システムは、開発担当者が独自の
ものと考えていても、実は同じ、あるいは関連性のあるデータが他システムに
あって、勝手に登録・変更・削除すると不整合・大トラブルを招くことがあり
えます。1社に何十、何百というシステムがあり、開発時期、担当者が違うと
なれば、システム間にどのような関連があるか、これを抑えることは至難の業
と言うことになります。
そこで本格的な開発の時は、徹底的なテスト−といっても完全であることを証
明することはできない−を行いカットオーバーすることになります。その後の
小規模な保守時はそれほどのテストはできませんし、引き継いだ若手保守要員
ともなればかなりミス発生の確率が増えると言うことになります。
経営にとって、本来同じであるべき数字が、システムAからのものとシステム
Bのものからとが食い違っていると、欧米では「私はSVOT(Single
Version of Truth)がほしいのだ」と要求されるとのことです。オペレーショ
ナル業務の機械化による省力化を目的として、ユーザ部門の要求対応に個別に
システム化してくると、このような不整合は、ごく自然に発生します。これを
防げるのは、システム横断の意思決定ができるCIOレベルのマネジャーです
が、日本の多くの企業において、このようなCIOはいないか、いても有名無
実、理解していない、と言うことになります。
■技術的対策
この問題に対する技術的対策は、「上記のCIOがいる」と言う条件付ですが、
・ 極力独立性の高い単位にシステムを分割定義する
・ システム間でやりとりするデータ(メッセージ/イベントデータ)を識別
する
・ システム間で共用するデータを標準化する
・ データ項目の意味が共有できるドキュメンテーションを行う
などとなります。システム間の関連はデータのやり取りで発生しますから、シ
ステムを構成する一番細かい、従って数の多いデータ項目に−ただし数に負け
ないために共用性の高いデータ項目に重点を置いて−取り組む必要があります。
上記の「データ項目のドキュメンテーション」については、システム開発経験
者においても、ツーカーで話しの通じる単一アプリケーション内開発が多かっ
たためか、経験者は少なく、補足する必要があるかと思います。意味の共有が
前提になりますから、単にデータ項目名を統一するとかデータ型や桁数を統一
するといった話ではすまない場合が一般です。取引先といっても顧客、業者の
ほか、銀行・官庁・病院を含むか否か、また海外は?などの「範囲」や、法人
レベルか営業所レベルかなどの「粒度」はいつも問題になります。この取引先
が、受注、出荷、請求、入金などのイベントデータに使われ、情報システムの
骨組みを形成していくのです。これがうまく設計されていないと、建物で言え
ば、柱にあけた穴に梁がはまらないとか、大き過ぎてがたがた動くとか、梁が
短くて柱に届かない、とかいう状態になります。
精度良く、また人間のパターン認識能力を活用して効率的に、データ項目の意
味・仕様を共有するために、われわれはデータモデル図を活用します。図上で、
たとえば製品原価がどの元データからどのように算出されるかなど、加工デー
タと加工元データの関係をトレースすることによって、データモデル図の精度
を格段に上げることができます。したがってこの可視化は建築の平面図や立面
図、あるいは内装前の3D図に相当するものと言えるかもしれません。このデ
ータモデル図の情報はリポジトリと呼ばれるDBに反映して、機械処理可能と
し、以後の保守合理化に活用することになります。
データモデル図が建築の柱や梁からなる骨格図の相当するものとすると、プロ
グラムなどの処理は壁や内装に相当するものと思われます。ここは骨格に比較
するとニーズの変化に対応し変化させなければならない部分と考えます。植物
は、幹は夏冬あまり変わらないが、枝葉は夏は茂り、冬は枯れることによって
温度変化に対応しています。システムも「変化しないのはデータモデル、変化
するのは使い捨てプログラム」などといったように、不変部分と変化対応部分
に分けて考えるべきでしょう。そのためには変化の少ないデータを先に固め、
その後で変化する処理を考えるのが正解なはずと考えます。その意味では、O
O手法では、一見データと処理を同時に考えるかに見え、またそのように誤解
している人が多いので注意しておきたいと思います。
■震度8に耐える情報システムを
自分の住んでいるマンションが震度5で倒壊する恐れがある、ということを知
ったら、おちおち住んでいられませんが、情報システムに相当のガタが来ても、
「今月の給与がもらえれば」、「再来年の退職金がもらえれば」として日々過
ごしてしまいがち、かと思われます。情報システムにおける震度5の負荷とは
何か、人によって解釈は違うと思います。私は孤島システム乱立で、スパゲッ
ティインターフェースと格闘している生産性の悪い情報システムは震度5で倒
れかかっている、と感じています。これはSIerでは手が出せない問題、ユ
ーザ企業のCIOとシステム企画がガバナンスを持たなければ解決できない問
題と考えます。日本版SOX法がスケジュールされているようですが、この対
策を先取りすることにもなります。是非情報システムを震度8に耐えるよう対
策を考えていただきたいと思います。