お客様のニーズにお応えする総合情報サービス企業/システムズ・デザイン株式会社
個人情報保護方針
サイトマップ
ご利用にあたって
contacet

データ思考とデータ指向開発

はじめに

ビジネスにコンピュータが使われていなかった頃、さまざまなビジネスデータは帳簿に記されていました。 例えば、元帳にまとめられた売買のデータは、回収や支払の記録として厳格に管理されていました。
記帳の方法が技術として確立され、簿記として広く知られるようになると、商人の中には店舗を構え、 大規模な組織を経営する者が現われました。
この頃の商人は、顧客を一軒一軒覚えて取引していたので、新たな取引先を見つけたり、 取引の拡大を決断したりするには、商人同士での情報交換が唯一の方法でした。
悪い噂が商人コミュニティの中で充満すると、商売の致命的な痛手となったのです。
こうした噂話は人の記憶に残るものなので、払拭することは難しかったといえるでしょう。 『商人は信用が第一』というのも頷けます。

また、業界の知識、顧客と仕入先の情報、情報の入手先といった商いのノウハウを獲得するためには、 長い時間をかけて修得する必要がありました。
『仕事を覚える』ことの密度と重要性が今とは比べものにならないくらい濃く、容易でなかったと考えられます。

現代においては、前述の諸問題をコンピュータが解決しています。
具体的には、勘定元帳、取引の内容、顧客情報はデータベース化され、簿記の知識や技術に詳しくなくても コンピュータシステムを利用してデータをビジネスに活用することができます。
そのため昔に比べれば、商人一人を育てるために費やす時間が大幅に短縮され、かつ一人あたりの生産性が 飛躍的な向上を遂げたといえるでしょう。

さて、元帳や顧客情報、取引といったデータは、商いの事実を表す証拠として、見易さや取り出しやすさを 工夫する技術が発達し、標準化が図られました。
つまり、『業務が定まれば、使用するデータの顔ぶれと並べ方が一定の方式のもとに正規化され、取り扱うことができる』。
また、『データの集合とその配置には、潜在的なルールが介在していて、業務の事実と対照的な関係がある』。
このような視点で取扱いのできるデータを『構造化データ』と呼ぶようになりました。
他方、顧客の評判や噂話、法律や制度を定めた御触書などは、文章として残されました。 このようなデータは『非構造化データ』と呼ばれています。

コンピュータシステムが技術革新によってその能力を拡大してくると、構造化データと非構造化データの両方を 扱えるようになり、加えてネットワークの発達が情報の入手先を大きく広げ、人間関係の構築を支援するまでに 達しました。構造化データと非構造化データは、昔からビジネスを支えるうえで 分けて考えられるようなものではないため、コンピュータシステムの発達が、 ビジネス領域で使用するデータ全体をカバーするに至ったことは、歓迎すべき状況といえるでしょう。

嘗てのコンピュータシステムは、処理能力が非力だったため、ビジネスに活用する現実的な方法として、 扱うデータ量を制限することが必要でした。データモデルは非力なコンピュータに処理させるには 過剰な量のデータを、どうやって処理させるかが課題だった時期に生まれた技術です。 本来は、ビジネスの実行とデータとの関係を解析するために用いるべきところを、 非力なコンピュータの処理能力を最大化するためという理由で、データベースの物理設計を定義する手法として、 利用されるようになりました。

以来、データモデリングは、本来の目的から逸れた利用方法が主流となり、現在に至っています。 もちろん、データモデルが持つ情報の中には、データベース設計に利用できる要素も含まれています。
しかし、前に述べたとおりそれだけのためにデータモデリングを実施するのは正しい姿とは言いえません。

sdcとデータモデリング

ビジネスシステムの構築

ICTを駆使して構築されたビジネスシステム。私たちは日常から、様々なビジネスシステムとかかわっています。 モバイル性に優れたコンピュータ機器が私たちの生活に浸透するにつれて、 私たちは時間や場所の制約を受けることなくビジネスシステムを利用することができるようになりました。
しかし、こうしたビジネスシステムは例外なく『人手』によって組み上げられています。 つまり、ビジネスシステムは次の3点を宿命づけられていることになります。

■人間の創造力の可能性
■不完全性
■コスト・生産性

ビジネスの基本的なモデルの概念は『価値の交換』にあります。企業は生産活動によって得た価値を 貨幣に交換することで収益を得ることができるわけですが、 この『生産』『交換』『収益』のプロセスの中で 様々な情報が発生し、利用され、貯えられるのです。
これらの情報のうち、主要なものは『書類』や『台帳』の形で蓄積され、保管されます。 1970年代になると『書類』や『台帳』の形にまとめられた情報を『データ化』し、 コンピュータで効果的に管理するのが一般的になり、ビジネスシステムの構築が盛んに おこなわれるようになりました。
ちょうどこの頃、データベース技術の発展に伴い、ビジネスシステムのデータを管理するのに適した 『リレーショナル・モデル理論』が発表され、 データベースを基盤にしたビジネスシステムを 構築するための方法論が活発に研究されるようになりました。 こうした背景のもと、 データモデリングはDOA(Data Oriented Approach)とともに脚光を浴びたのです。
システムズ・デザインは、この頃から製造業の企業を中心に、データモデリングによる ビジネスシステムの構築を多数手掛けてまいりました。 当社のDOAの取り組みは、 Think’ITへの寄稿でも、ご確認いただけます。


当社のDOA開発の特徴

『人手』によって組み上げられるビジネスシステム。すなわちビジネスシステムの構築は、 その範疇全般にわたって人間による「可能性」と「限界」と「制約」の影響を受けるという前提が存在します。

可能性とは、人間の創造力による可能性のことで、システム開発に携わる人間の豊かな発想を ビジネスシステムの随所に盛り込めることを意味します。 この創造性をビジネスシステムに反映させることが、 すなわちアプリケーションを使って作業する人間が、正確に短時間のうちに大量に業務を処理することが、 ビジネスシステムの導入効果として評価されます。

限界とは、プログラムを製造する段階で生じる誤謬等、ビジネスシステムに どうしても紛れ込んでしまう『瑕疵』のことです。 こうしたミスは、

プログラム開発担当者が業務要件を理解していないケース、
経験や知識が不足しているケース、
要件定義段階での見落とし

等々、様々なケースを上げることができます。
ケアレスミスも含め、プログラム・バグと言われる瑕疵は、個人の能力に起因します。 プログラムは人間が作るものであるために生じる問題です。 こうしたミスを撲滅する取り組みとして、

@通論を利用した抜け・漏れチェック、
A知見の深い関係者による業務とアプリケーション機能のレビューおよびテスト、
B作業の工程スケジュールと成果物の見える化/見せる化 

の3点に積極的に取り組むことが有効です。

制約とは、一言でいえば『コスト』。 コストは

@金銭面、
A作業量(または必要な時間)、
Bリスク

の主に3つの要素で評価/分析を行います。
コストの適正化は、 これら3つの要素のバランスによって得られます。
たとえば、金銭面に余裕がある場合、金銭を投入することで作業量に対応する十分な要員態勢と 開発作業時間を確保することができるため、リスクを効果的に制御することが可能です。
あるいは作業量を調整することで金銭面をそのままにリスクの低減を図ることができる場合もあります。
また、リスクを受容することにより金銭面と作業量をそのままにするケースも考えられます。

「可能性」「限界」「制約」の三つは、旧来からプログラム作りの大きな課題でした。 小社はこれらの課題を解決するために、 ビジネスシステムの構築に有効な 『プロトタイプを自動生成するフレームワーク』の適用を強く支持します。 『プロトタイプを自動生成するフレームワーク』の一般的な特徴は、以下の事項が挙げられます。

■アイデアをすぐに具現化できるプロトタイプ機能を備えている。
■プロトタイプ機能により、主に画面の表示内容、挙動を確認できる。
■信頼性の高いプログラム部品で、アプリケーション機能を生成できる。
■一般的なスクラッチ開発に比べて、作業工数の削減が可能である。
■比較的多くの工数を要する設計書類の作成を自動化できる。
■稼働しているアプリケーション機能(画面、帳票など)のプログラムと仕様情報の乖離が起こりにくい。

小社は、前述に提示した条件に合致する『ビジネスシステム構築基盤』を活用し、 創業以来蓄積してきたデータモデリングをはじめとする技術ノウハウを組み合わせて、 ミッション・クリティカルなビジネスシステムの構築業務および保守運用業務を提供します。

<Fig-1 従来型ウォーターフォール開発との比較>
従来型ウォーターフォール開発との比較図


開発体制

『プロトタイプを自動生成するフレームワーク』の利用を前提としているため、 基本的にプログラマレベルの要員をプロジェクトに投入することはありません。 「プログラムはツールに作らせる」という原則のもと、ERモデルを洗練し、 設計伝達モデルを完成させます。 そのため、要求定義から基本設計までの設計工程では、 ERモデルの作成にあたる『データ管理者」、要件・要望仕様を担当する上流設計スペシャリスト、 利用するツールに仕様を適合させる製造設計スペシャリストを配置し、 プロトタイプの実施に向けた準備を行います。
設計伝達モデルの完成により、プロトタイプを開始。画面/帳票のデータ項目の不足/過剰を精査し、 画面遷移やカーソルの挙動といったユーザインタフェースの確認を行います。
データ・ドメインに対応したバリデーション仕様のチェック、ERモデルで表現できない機能、 たとえば、受注画面の与信チェック、出荷指示の在庫引き落としなどのロジックを組み入れた後、 画面/帳票のレビューを行います。
レビューのやり方は、5〜10程度の機能を描き著した設計伝達モデルを作成し、 プロトタイプを繰り返す「イテレーション型」で実施します。プロトタイプ・レビューには、 企業内情報システム部門の業務システム企画担当者を中心に、可能であればエンドユーザも 評価に加わっていただきます。


高速開発(RAD)の特徴

高速開発(RAD:Rapid Application Development)は、データモデリング抜きには実現できないといわれます。 実際に楽々Framework3* を使用するとプロトタイプによる開発になるので、製造段階、テスト段階の一部を プロトタイプで吸収することが可能です

楽々Framework3* は、内蔵のリポジトリからプログラム概要、使用テーブル一覧(CRUD図)、 項目の入出力一覧表、SQL等の設計情報を出力することができます。予めユーザが指定したExcelに 出力することもできます。これらのドキュメントは、実際に稼働している機能とまったく乖離がありません。

高速開発(RAD)/開発体制


開発手順

作業
ステップ
概説 INPUT
資料(例)
OUTPUT
資料(例)
プロトタイプの
レベル













エンティティ
+ID
ERD作成の初期段階として、対象業務の性格上重要と考えられるエンティティを抽出する作業を行います。 画面、帳票、ファイルレイアウト コード体系一覧(ドラフト)
エンティティ
ステップ-1
リソース系エンティティ、イベント系エンティティに大きく類別します。 ERダイアグラム
アトリビュート
ステップ-1
アトリビュートは、画面、帳票などに表示されている和名を分析し、意味、意義、必要によって条件や計算式をメモしておきます。 画面、帳票、ファイルレイアウト ERダイアグラム(属性定義項目)
アトリビュート
ステップ-2
アプリケーションの中で統一且つ唯一の名称にしてERモデルに反映します。この時点で、エンティティとデータ項目の論理名付与が完了となります。 エンティティ一覧
アトリビュート
ステップ-3
論理名を与えたデータ項目(データ属性)に桁数、データ型、Nullの可否、初期値、その他条件を設定します。 画面・帳票定義書、ファイルレイアウト アトリビュートリスト(論理属性一覧)
エンティティ
ステップ-2
ルールに従って対照表、対応表を作成します。 業務マニュアル、業務フロー、画面、帳票 ERダイアグラム
エンティティ
ステップ-3
サブセット、VEを切り出し、ERDを詳細化します。 業務マニュアル、業務フロー、画面、帳票 ERダイアグラム








エンティティ・
アトリビュート
ステップ-4
物理名を設定していきます。 命名定義書 ERダイアグラム(物理名項目) モックアップレベルの画面を生成





インスタンス
ステップ-1
区分・種別個別にインスタンスを洗い出し、その振る舞い(メソッド)を分析します。 振る舞いは、同一の区分・種別がインスタンスにより違う振る舞いをするケースと、 他の区分・種別のインスタンスの組み合わせで特徴ある振る舞いをするケースの両方を分けて分析します。 区分・種別一覧 ERダイアグラム(属性定義項目)
ブーリアン
ステップ-1
フラグの真偽による振る舞いを分析します。真偽の違いによる挙動を分析し、メソッドを明確にしていきます。 画面、帳票、顧客ヒアリング、プログラム仕様書、ソース解析 フラグ等一覧(ブーリアン仕様)
インスタンス・
ブーリアン
ステップ-2
重複を排除して、区分・種別一覧にまとめて仕様図書の一部とします。 フラグ等一覧(ブーリアン仕様) フラグ等一覧(精査版) 区分・種別・フラグによる挙動を仕様化し、カスタマイズやプラグインを設計・開発できるレベル。プロトタイプでほぼ業務の確認が可能
キー
ステップ-1
キーを設定します。独立したキー、複合キー、代理キーを設定し、ユニーク検証制の担保を図ります。 画面、帳票、顧客ヒアリング、プログラム仕様書、ソース解析 コード仕様書、コード体系一覧 コードの自動発番機能が実装可能なレベル
エンティティ
ステップ-5
リファクタリング。アプリケーション・プログラムがテーブルにアクセスする方法を検討し、同じまたは親和性が高く統合できる場合にエンティティをまとめる作業を行います。 ERダイアグラム、画面、帳票、顧客ヒアリング、ソース解析 ERダイアグラム ビジネスロジックがほぼ出揃った状態でプロトタイプが可能
DLCP
ステップ-1
アプリケーション利用者に対応したエンティティのアクセス権を分析・定義します。 セキュリティ規程、顧客ヒアリング(情シ) ERダイアグラム、データベース定義書
DLCP
ステップ-2
アプリケーション利用者に対応したエンティティ内のデータのアクセス権を分析・定義します。 セキュリティ規程、顧客ヒアリング(情シ) ERダイアグラム、データベース定義書 現実の過去データを使って、データアクセス制御を検証できる状態のプロトタイプが可能
DLCP
ステップ-3
参照整合性(カスケード)と履歴管理の条件を分析し、仕様化・検証します。 顧客ヒアリング(情シ) ERダイアグラム、データベース定義書 アプリケーションとして、機能の閉じた状態でプロトタイプが可能

■データモデルサービスメニューはこちら


ご用命・お問い合わせ
システムズ・デザイン株式会社 SYSTEMS DESIGN Co.,Ltd
E-Mail :prod-info@sdcj.co.jp
本  社:東京都杉並区和泉1-22-19 朝日生命代田橋ビル6F
     TEL.03-5300-7801(システム営業部)FAX.03-5300-7841
大阪支社:大阪府大阪市北区天満橋1-8-30 OAPタワー8階
     TEL.06-6355-5971(代表)
Copyright (c) 2005 SYSTEMS DESIGN Co.,Ltd. All Right Reserved.