» 【116号】システム設計2つのアプローチ

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【116号】システム設計2つのアプローチ

■システム設計アプローチ
システム設計アプローチは、次のA、B、2つの大別できるように思われます。
 A:テンプレート修正アプローチ
 B:要件統合アプローチ

Aは基本的に、すでに実装されたお手本をベースに、若干の修正を施してシステ
ムを作るものです。修正項目の整理は行われますが、要件定義は一般に省略
されます。DBを新設し、全プログラムを書き換えるとしても、作業は保守に近く、
既存の実装イメージをベースに進めることになります。「コストセーブ、短期開発」
が利点ですが、一般に「ユーザ要件の満足度が低い、ユーザ要件が可視化され
ず共有されにくい、人が育たない、運用時の修正改善要望への対応に制約があ
る」といった欠点がありえます。1990年代のダウンサイジング、ERP導入の多く
は、このAのアプローチだったと思われます。
Bは、ユーザの要件を収集整理統合してから実装するものです。「ユーザ要件が
満たされやすく、要件定義ドキュメントによりシステムが可視化され、人が育つ」
などの利点がありますが、「時間がかかりやすい」という欠点があります。実装
独立にユーザの情報要求を端的に表すIOを分析し、IO間相互の調整・標準化を
行うボトムアップ手法が典型ですが、時間短縮のため、種々の工夫を持つトップ
ダウン手法が行われています。
A、Bの評価においては、適用局面を次の2つの分けて行うべきかと思われます。
 P2P:個別アプリケーションの開発運用(Program to Program)
 A2A:個別アプリケーション横断の開発運用(Application to Application)
■P2Pの場合
P2Pにおいては、購買、生産、販売、物流、回収、保守などの基幹系、また人事、
設備管理、顧客管理、商品開発、資金管理といった経営資源管理系のなかに、
かなり定型的なアプリケーションがあります。これらについては、Aのアプローチ、
それもパッケージ適用の可能性が高くなります。これは、建物で言えば、建売物
件の購入に近いと言えます。日本人の4,5人家族の家屋に対するニーズなどさ
ほど変わりない、これを想定した建売ならそのまま使える。これと同様に、独自の
文化を持つ古い大会社を除けば、Aの適用できるアプリケーションは少なくないと
思われます。建物の場合は、建築申請のため図面は作られますから、ドキュメント
による可視化はできています。しかしこれは、商品がハードウエアであり、現物を
見ることができますので、参考資料的な位置づけになります。
もちろんP2Pにおいても、競争優位を実現している独特のアプリケーションがあり
ます。競争優位を保ち続けるためには、ビジネス環境や、ITの変化に対応して、
常に変革し続けなければなりませんから、現状を可視化し続けるBのアプローチ
が正解となります。
しかし実際には、時間の制約、要員−特に正しい要件定義技術を持った要員−
の制約から、Bでも可視化の品質を犠牲にしたトップダウンのアプローチを採るこ
とがあります。この場合は、現状分析は最小限にし、トップダウンをリードする特定
の個人の経験やスキルに依存することになります。一般にスピードと品質のトレー
ドオフが発生します。しかもその経験やスキルは、実装レベルのものであることが
多く、高品質の可視化を継続すると言う点では難点を抱えることになります。この
点ではAにかなり近い特徴をもつアプローチとも言えます。
■A2Aの場合
全社をスコープに入れたA2Aにおいては、Aのアプローチは非常に難しくなります。
個々のアプリケーションが定型に近くても、これらの集合からなる全社システムは、
重電、家電、半導体、電子部品、あるいは医薬、食品、繊維、など各種事業がか
らみ、かつ国内、欧米、中国などと展開されるため、このレベルでの定型は例外的
となるからです。
ERPパッケージはこれに挑戦するために、パートナーによるカスタマイズを持ち込
んでいますが、現状は、会計ほかいくつかの定型的アプリケーションの連携に限っ
た、いわば大型のアプリケーションパッケージとして成功しているように見えます。
したがって、A2AではBのアプローチ、それもトップダウンは難しいので、ボトムアッ
プアプローチが本命かと考えます。この場合の素材は、P2Pの場合の画面・帳票
に代わって、個別アプリケーション間でやり取りされるメッセージデータ(トランザク
ションデータ)です。
(注)これを筆者は個別アプリケーション内でやりとりされるロウ(低)レベルメッセー
ジに対してハイ(高)レベルメッセージと呼び、hMSGなどと書いています。
事例としては、
 hMSG:製品生産計画データ、製品完成データ、出荷実績データ
 lMSG:中間品生産計画データ、中間品完成データ、出荷指図データ
などが挙げられます。なおhMSGはlMSGでもあります。
このメッセージデータを収集するには、まず個別アプリケーションの大きさを規定しな
ければなりません。従来も業務領域対応に個別アプリケーションが作られていたの
ですが、スポンサーの資金や納期などによって規定され、適切なものではなかった
可能性がありますので、多くの場合見直す必要があるでしょう。筆者はDBアーキテ
クチャの観点からこれを決めたいと考えています(DRI通信115号参照)。これは
EA(Enterprise Architecture)におけるDA(Data Architecture)の中核となります。
これを決めればhMSGは収集できるはずですが、現状電子的にやり取りされている
データだけでは不十分、紙や電話で入手している情報も加える必要があるかと思わ
れます。またあるhMSGを必要とするアプリケーションは、現状は1個にしか渡して
いないとしても、ほかにないとは限りません。従ってピアツーピアの通信では間に合
わなくなる惧れが大です。アプリケーション間にもDB通信場を用意し、これにより各
アプリケーションが自由に参照できる仕掛けが正解なはずです。またここにはhMSG
から作られる、在庫や要約の加工データがストアされるべきです。
当然、hMSGに含まれる、組織や製品などのリソースデータは全社標準の「形式と
値」を持つものでなければなりません。しかし、lMSGがパッケージやレガシーシス
テムである場合、この全社標準と異なるため、変換が必要になるのが一般的かと
思われます。ERPについてはこれをアプリケーションパッケージとして使っているか
ぎり、可視化の必要がないわけですが、全社に位置づけ他のアプリケーションとの
コミュニケーションを考えるに当たっては、ERPから、あるいはERPへのhMSGを
識別・可視化しなければなりません。
最近、ITアーキテクト、SOA、BPM、CPMなどが話題になっています。これらは全社
レベルでのシステム化・最適化を指向して、A2Aのコミュニケーションが問題になって
いるからです。この問題は、個別アプリケーション開発を課題とするSIerでは解決でき
ない、ユーザ企業で取り組むべき課題です。ITというより、ユーザ企業の業務モデル
をどうすべきかという、まさにIT独立のビジネスの問題です。90年代情報部門はコスト
センターとしてリストラされ、弱体化した会社が多くありますが、いまはこれを復活すべ
き時と考えます。情報部門はITのトレンドをわきまえつつも、業務モデル、特にその骨
格を作る業務横断のデータ構造を可視化し共有しなければならない時代に入ったと考
えます。