» 【第96号】気づかれにくい問題

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第96号】気づかれにくい問題

DRI通信96号「気づかれにくい問題」       2004.9.1
さすがの酷暑も9月の声とともに、過ごしやすくなってまいりました。夏休みもオリンピックも終わり、仕事に専念の体制が整ったと言うところかと思われます。
DOA+コンソーシアムでは、8/6(金)第1分科会(第4回)において、「上流設計工程における「『Xupper』のデータモデルとデータモデリング手法」をケン・システムコンサルティング株式会社の本村智之様より、また8/26(木)第2分科会において「QuiQpro-Java」を富士通システムソリューションズの川端功微様よりご紹介を頂きました。ここでもやはり、「上流はDOA、下流はOOP」とのことでした。
■劣化しないシステム
ソフトウエア業界では、ERP、EAなどと並んでプロジェクトマネジメント、RFP(Request For Proposal)、オブジェクト指向開発などが話題を集めています。そしてその多くが、単発アプリケーションを、ユーザが発注し、SIがこれを請けるという開発環境の中で語られています。そこでは案件のQCD(Quality, Cost, Delivery)が目標とされ、これが実現できれば、「めでたしめでたし」として、カットオーバーのセレモニーが行われることになります。
これは単発アプリケーションの発注・請負のビジネスの中では、極めて自然であり、問題があるようには思われません。しかしこの繰り返しの中から、属人的で見えにくい、スパゲッティインターフェースのため、トラブルの発生しやすい、保守コストのかかる、動脈硬化したシステムができていくことがあります。しかし、いま厄介もの扱いされているシステムも、カットオーバーしたばかりは、多くの課題を解決した、すばらしいシステムとして評価されていたのではないでしょうか。


「劣化しないシステム」。気づかれにくいが、これがQCDに劣らず重要な課題であると、私は考えます。属人的で見えないものは劣化が速い。処理はデータに比し、属人化しやすく見えにくい。したがって処理についてではなく、まずそのデータからなるインターフェースに関するドキュメンテーションによって、劣化しにくいシステムができるのではないか、と考えました。
■システム間インターフェース
インターフェースを考えるとき、2種類のインターフェース、すなわちアプリケーション間の、いわばハイレベルのインターフェースと、アプリケーション内での、プログラム間のロウレベルのインターフェースとは分けて考えましょう。ロウレベルの可視化は、かつてCOBOLプログラムをファイル経由バケツリレー方式でつないでいたものをデータベース化したとき、データモデリングを実施して解決した企業も少なくありません。ところがハイレベルの可視化は、これに比べ多くの企業においてかなり遅れています。
ハイレベルのインターフェースが未確定の場合は、発注したシステムが開発・検収されてから、これが確定され、それから他システムとの連携を検討することになります。連携のためには、一般には手直しや変換機構の追加が必要になります。アプリケーション間を繋ぐためには、双方を理解しなければなりませんから、高度の業務知識が要求されます。そして異質のIT環境であると、高度のIT知識も必要ということになります。
またこのようにシステム間インターフェースを事後に検討するということは、バケツリレー接続をシステムレベルで行うことになりますから、システムの数の2乗に比例した数のインターフェースを扱わなければならなくなります。開発時はそれでも腰を据えてやりますからよいとしても、保守時は人も時間も不十分なため、属人化し見えづらくなって、劣化を招きます。
したがって、これを避けるには、発注前に全システム間インターフェースを設計しておき、検収時、即連携して稼動するような方式をとらなければなりません。システムの数の2乗でなく1乗に比例したインターフェースの数にするためには、ハブ&スポークの形式にする、このためにハイレベルのインターフェースを素材にしたデータモデリングを行う必要があります。こうして、データベース通信場経由、各システムがコミュニケーションするアーキテクチャを作ることになります。これによって、各アプリケーションは他に影響されない独立性を獲得することができます。これはロウレベルでプログラム間のバケツリレーをDBMSで解決したと同じことを、ハイレベルでシステム間にも適用しようと言うだけのことです。
■担当者不在
今までどうしてこのようなアーキテクチャが取れなかったのでしょうか。第一にはこのニーズを感ずる人・見える人、および対応できる人が、いなかったからだと思われます。各ユーザは自分のアプリケーションが使いやすければそれでよい。それへの対応はシステム部長で対応できる。しかしシステムを繋ぐニーズを持つ戦略ユーザは最近までいなかった。予算を持った、全社的スコープでシステムを見る戦略ユーザの組織がなかったのではないか。またこれに対応したアクションがとれるのはCIO相当の経営トップですが、そのような人がいないか、いても理解できないか、そのニーズがユーザから上がってこなかった、というような事情があったのではないかと思われます。
またシステム担当者は、インターフェースを実装独立に考えることに慣れていない、そのためアプリケーションが出来上がって物理インターフェースが見えてからでないと、調整できないと思いこんでいたのかもしれません。
昔プラントエンジニアリング会社にいたとき聞かされたことですが、「土木工事は一番早く
手掛けなければならないが、レイアウト・装置サイズ・荷重など、その設計情報はプラント設計が終わらないと出てこない。詳細は確定しなくても土木への設計情報は早く出せ」とのことでした。ハイレベル・インターフェースはこの土木への設計情報に相当するものと見えます。インフラ設計のデータは、個別システムから出るので、これを早期に出して調整し、インフラを固めてから、個別システムを確定すると言う順序になるわけですが、この認識が、情報システムにおいては、まだ定着していないのだとも考えられます。歴史が浅いため、情報システム建設は、プラント建設に比べまだまだ遅れているということなのでしょうか。
■システム企画部門の役割
アウトソーシングの方針によって、企画機能に特化した小さい情報システム部門が増えてきました。空洞化しないために、RFPを強化しようという動きがありますが、同時に多くの場合、その発注単位が妥当なのか、視野を当該アプリケーションだけでなく、全社システムの中に位置づけることから始めなければなりません。ユーザ部門から寄せられた各アプリケーションのスコープが、単に今の組織の作られ方から出てきたものであるかもしれないからです。ハイレベル・インターフェースの設計/調整はこれにもとづいて始めることになります。多くの場合、戦略ユーザ部門が他にないため、情報企画部門がこれを担当することになるでしょう。
こうして作られたハイレベルのデータベース通信場は、安定しかつ可視化され、個別アプリケーションの独立性を高めますから、少ない工数で劣化をコントロールすることができるはずです。レガシーシステムやパッケージの場合は、変換機構を用意して繋ぐ必要があるでしょうが、安定したデータベース通信場との関係であれば、企画部門が十分コントロールできる範囲に入ってくるものかと思われます。
オブジェクト指向の方は処理が気になるでしょうが、処理についてはこの後で検討して十分と考えます。参照系は問題になりませんからこれを除き、更新系(CUD)だけを対象にします。データ系が見えていますから、これに対する更新処理を考えるならば、データとは原則として1対1対応ですから、これが最も容易な攻め方になるはずです。
関越道の練馬インターチェンジはいつも渋滞しています。後付インターフェースの宿命かと思われますが、見えないけれどこのようなネックがごろごろしているシステムを運用しておられないでしょうか。「こんなもんだ」と慣れてしまっては解決できません。アプリケーションを横断する共通の通信場、ハイレベルのインターフェースに着目して、スマートにこれを解決して行こうではありませんか。