» 【125号】情報システムのサイエンス(3)

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【125号】情報システムのサイエンス(3)

■部品展開のエンジニアリング
124号で述べましたように、情報システムの部品展開に関して個人差の出な
い−「決まる」−結果を得るための、7つの基準を提案したわけですが、やはり
決着までには担当者が都度判断して「決める」べき課題が残されます。

主なものとして
①概念DBの大きさ/スコープ
②エンティティタイプの大きさ
③画面・帳票に含まれる属性
などが挙げられます。
概念DBは、n個のアプリケーションプログラムがコミュニケーションする通
信場ですから、ストアするデータの形式や値の標準を規定するリポジトリとリ
ソースDBが存在します。標準化には関係者の同意が必要、これを有限の時間
内に決着するために、DBは有限の大きさになりますが、その大きさは関係者
の標準化への意欲や力量、それまでの文化、納期や予算などによって決めざる
をえません。拙速も時として選択しなければなりませんが、原則として高度の
エンジニアリング的判断が必要になります。
エンティティタイプの大きさにも、個人差の出ない自明なエンティティタイプ
もありますが、逆にエンティティタイプを「顧客」レベルにすべきか、協力会
社を含む「取引先」レベルにすべきか、さらに物流などの便宜も考えて、自社
組織も含む「社内外組織」とすべきか、など悩ましい問題があります。「もの」
を「商品」「製品」「部品」のどのレベルに設定するかも同様です。筆者は大
多数のユーザが共通認識できるレベルでエンティティタイプを設定し、詳細分
類はサブタイプ扱いとすべきと考えますが、人により意見が異なりやすくデー
タモデリングにおける難問のひとつといえます。
以上は概念DBやエンティティタイプの大きさ/粒度に関するものですが、画
面・帳票に含まれるべき属性は、情報システムの目的、業務フローなどをベー
スに担当者が意思決定すべき、製品に関するまさに「決める」べき設計変数で
す。本質的にサイエンスではなく、エンジニアリングの領域の課題になります。
このように、サイエンスとエンジニアリングを動員して情報システムの部品が
決まり、これをドキュメンテーションすることになります。先に(124号参照)述べ
ましたように、この部品のドキュメント形式はエンジニアリング的に規定されます。
■手順のサイエンス
次に問題になるのは、これをどのような手順で作るべきかです。手順はWHAT
ではなくHOWであり、与えられた人や時間などのリソースの制約のもとに、
目的を達成するための最適化により決まりますので、本質的にエンジニアリン
グの領域と考えられますが、筆者は手順設計においてほぼ普遍的に適用できる
原理原則があると考えます。
それは「1対nの対応関係のある部品は、1の方を先行して決める−1の方が
十分決着してからnの方に着手する−べき」というものです。これをあえて手
順におけるサイエンスということにします。たとえば、
①ニーズ先行(シーズは後から)
②概念先行(実装は後から)
③データ先行(生成プロセスは後から)
④リソースデータ先行(イベントデータは後から)
⑤AsIs把握先行(ToBe決定は後から)
を列挙することができます。

①は「システムは動いたけれど、経営目的は達成しなかった」などとして、プ
ロジェクト管理の失敗例としてよく紹介されるものです。また「把握されたニー
ズが、関係者間で異なりプロジェクトがダッチロールする」なども少なくあり
ません。
②はユーザ参画やIT変化への対応力強化のために必要ですが、ビジネスニー
ズは本質的に実装独立ですから、?と重複する部分があります。
③はDOAの根拠であり、ビジネスニーズはビジネス目的を達成するための画
面・帳票に帰着しますので、やはり?との重複があります。
④は画面・帳票に登場する用語−顧客番号、品番、品種コードなど−を事前に
標準化しておこう、これによってデータの重複・不整合を事前に解消し、孤島
システムの発生を防止しようということです。
⑤は関係者のAsIsに関する認識が、予想以上に各人異なっていること、そ
のために無駄な議論が多発することを防止する狙いです。AsIs把握が不十分
なため1時間で終わる会議が、1日かかっても収束しないなど、よく経験す
ることではないでしょうか。一般に大多数のメンバーが業務モデル図やデータ
モデル図に関して習熟しておらず、トレーニングが必要というプロジェクトが
多いのですが、その題材としてはAsIsが最も取り組みやすく、かつToBe
のプロトタイプにもなるため有効と考えます。また?における標準化の前提と
して、AsIsの用語に何があり、どのような重複や不整合があるかの把握は
必須です。
■手順のエンジニアリング
以上を手順のサイエンスとして述べましたが、これらをベースに手順がエンジ
ニアリング的に設計されます。対象とするシステムの設計・開発の目的や制約
によって、手順は微妙に変更するわけですが、次のような考慮が必要かと思わ
れます。
・スキル不十分のメンバーがたくさんいる場合。ビジネスユーザが要件定義ド
キュメントを十分理解し、システム設計者と十分なコミュニケーションができ
る場合は、まれでしょうから、多くの場合がこれに該当するかと思われます。
「プロジェクト遂行と人材育成は分離せよ」との指摘もあるようですが、現実
には座学で習得できるスキルは初歩的なものであり、OJTによってスキルが
身につき、成果に結びつきます。また次世代のシステムマンを育成する貴重な
チャンスでもあります。したがって、いかに効率的に教育しつつ成果物を作る
かが課題といえます。筆者の経験では、前倒しに教育しその成果をそのプロジ
ェクトで回収する方式をねらうべきと考えます。
・間口は狭くスタートせよ。試行錯誤を減らし、繰り返し作業を減らすために、
いろいろなケースがあるならば、最も分かりやすいひとつ−たとえば品種A、
B、Cによって業務ルールが異なる場合、一番皆の知っているA−に絞り、こ
れをパイロットとし、人数もできれば10人以下に絞って、上流から下流まで
設計を進める。この中で共用性の高いリソースDBの構造が見えてきますが、
同時に成果物の雛形ができ、またコミュニケーションのトラブルの出にくい手
順など、各種知見が見つかりますので、これを整理して方法論をカスタマイズ
します。大規模で人数が多い場合は、ここで教育したメンバーを核に、いくつ
かのチームを作り、設計・開発パワーを拡大しながら間口を広げることができ
るでしょう。
・基本はボトムアップ。現状の単なる移行、若干の手直し、パッケージ導入な
どの場合は別ですが、一般的にはニーズ積み上げのボトムアップ手法、すなわ
ち「画面・帳票対応の概念DB構造部分図を作成し、これを統合する」手順が
最も健全な方法と考えます。ただし、なんらかの雛形があるとか、経験がある
場合、時間を節約するためにトップダウン・アプローチを組み合わせることが
できます。しかし効率優先にはリスクが伴います。画面・帳票(製品)と概念
DBの属性(部品)との対応が十分検証されず、後工程で属性の抜け・漏れ・
不整合などが発見され、混乱を招くことのないよう、対処しなければなりませ
ん。
■個人差の出にくい前提・公理系がベース
以上、筆者が30年にわたって情報システム設計・開発・運用・保守に対して
サイエンスを導入したいと心掛けてきた要約かと考えます。本質的にエンジニ
アリング課題ですから、すべてをサイエンスの「決まる」問題として解決でき
るものではありませんが、妥当な前提・公理系を設定することによって、個人
差の出る局面/意思決定変数を最小限に絞込み、品質・作業効率・コミュニケー
ション効率の向上をねらいました。妥当な前提・公理系として、オブジェクト
指向はもちろんDOAにおいても種々の提案があり、これによって方法論体系
が作られます。何が最も妥当であるか難問ですが、皆様のご批判をいただき、
さらに向上できればと考えます。