第3回:DOAを進めるためのミニマムセット (3/3)

データ指向アプローチ
DOAとは何か!〜開発現場から見るDOA〜

第3回:DOAを進めるためのミニマムセット

著者:システムズ・デザイン  DOA推進ワークショップ   2007/5/23
前のページ  1  2  3
データモデル

   業務システムは、基本的に「台帳システム」といいかえることができます。このため、台帳に相当するデータ部分の構造を明確に示すためのデータモデルの作成は、必須といえるでしょう。また、データモデルが描かれていれば、システム設計の「良し悪し」をだいたい把握できます。

   データモデルは、システム開発のフェーズに応じて、「概念モデル」から「論理モデル」「物理モデル」の順で描いていくのが一般的なアプローチです。ここでは特に「概念モデル」と「論理モデル」を取り上げて、その役割とあり方について説明します。

概念モデル

   筆者の現場では、概念モデルは描いていません。客先が採用している開発手法に則っているためですが、少し残念に感じています。

   概念モデルの役割としては「システム開発の概略イメージの共有」や「プロジェクト範囲の決定のための材料」などがあげられます。通常、論理モデルが完成するのは論理設計段階の後半であるため、概念モデルができあがるまでは関係者の間でイメージを共有することができません。

   また、論理モデルが完成しても、エンティティ数が数百もあるような規模のシステムでは、それを見て視覚的にイメージを捉えるのは困難といわざるを得ません。

   小規模システムで、業務であつかう画面や帳票が明確になっている場合は概念モデルを省略することも可能です。しかし、そうでない場合にはプロジェクトの企画段階あるいは分析の初期段階で、概略イメージを共有するための概念モデルが描かれているべきだと考えます。


論理モデル

   筆者が以前携わっていたプロジェクトで、DAが作成したモデルに対して客先のIT部員がもらした言葉が「こんなの見る気しないですよね」というものでした。

   開発の現場では畳2〜3畳分はあろうかという巨大な用紙に数百ものエンティティが描かれた図面をよく目にします。読者の方々は、このような図面をどのように思うでしょうか。またシステム開発をするための道具として有効なのだと考えているでしょうか。

   以下は、データモデルの一部分を抜粋したイメージです。

線が入り組んで分かりにくいデータモデル
図3:線が入り組んで分かりにくいデータモデル

   このような図面はリレーションシップをあらわす線が幾重にも入り組んでおり、たどることすら困難です。IT部員がこのような感想をもらすのですから、ドキュメントとして適切とはいえません。

   このことから筆者は、論理モデルは多くて40〜50個程度のエンティティが無理なく収まる程度に分割して描くことが望ましいと感じています。もっともER手法では「パッケージ」の概念がないため、サブシステム分割を表現することができません。この点はER手法の課題といえるでしょう。


CRUDマトリックス

   CRUDマトリックスは、エンティティの発生から消滅までのライフサイクルを分析するためのものです。


CRUD分析の役割

   CRUD分析の役割は、主に以下のような2点があります。

  • サブシステム分割の妥当性の検証
  • データ分析とプロセス分析の整合性の検証

表5:CRUD分析の役割

   前者のサブシステム分割の妥当性の検証は、概念モデルレベルで実施されます。ここでは「モジュール結合度」や「モジュール強度」の観点からサブシステム分割の妥当性を確認することができます。特定の機能グループが、特定のエンティティの発生から消滅に関与することにより、「モジュール結合度が低く」、かつ「モジュール強度の高い」サブシステム分割が実現できます。

  エンティティ
サブシステム 機能 E1 E2 E3 E4 E5 E6
A 機能1 C          
機能2 D C        
機能3   D        
B 機能4     C C    
機能5       C    
機能6       C/D    
C 機能7         C C
機能8           C
機能9         D D
C:Create、D:Delete

表6:CRUDによるサブシステム分割

   後者のデータ分析とプロセス分析の整合性の検証は論理設計の終盤で実施し、機能とエンティティの整合性を確認することができます。例えば、複数の機能が1つのエンティティの更新に関与している場合は、エンティティ分割の検討対象となります。これをデータ項目レベルでも行えば、さらにきめ細かい分析を行うことができます。


CRUDマトリクスは必要か?

   筆者の現場では、CRUDマトリクスは必須ではありません。このため、CRUDマトリクスを作成しても、前述のような役割で使用されることはないといってもいいかもしれません。また、このような分析を丁寧に行っている時間的余裕がないというのも現実です。その状況でも開発が可能なため、筆者も必須のものだとは感じていません。

   たいていの場合 このような分析は経験を積んだ設計者であれば設計過程で頭の中で自然に消化できているのだと思います。また、キー項目に対する従属関係だけを考慮したデータモデルよりも、意味論を適用したデータモデルが主流となってきており、エンティティと機能の不整合は自然と取り除かれているのではないでしょうか。

   もっとも、工学的見地に立てば、特に超大型プロジェクトのサブシステム分割においては上述のような分析が必要になるのかもしれません。


まとめ

   すべてのシステム開発において、一律に適用するミニマムセットを定義することは現実的ではありません。

   100名規模のプロジェクトと数名程度のプロジェクトでは、必要な文書量も性質も異なります。また、ドキュメントの種類は定まっていても、表現する詳細化のレベル、粒度があいまいなケースが多いのではないでしょうか。

   筆者も、「どこまで書けばこのドキュメントは完了としていいのだろうか」と作成しながら悩むことがあります。肝要なのは、以下の3点だと考えます。

  • ドキュメントの種類や形式が標準化されていること
  • 標準化されたドキュメント体系の中から、プロジェクトの性質、規模、そして開発期間などを勘案して最適なものを選択すること
  • 関係者間でコンセンサスの得られる適切な詳細化のレベルを決定しておくこと

表8:ドキュメントについて考慮されているべきこと

   最近「要求のトリアージ」という言葉をよく目にしますが、これをドキュメントにも当てはめて考えてみてはいかがでしょうか。

   次回は、さらに開発現場の視点からみたDOAを考えます。

前のページ  1  2  3


システムズ・デザイン株式会社 DOA推進ワークショップ
著者プロフィール
システムズ・デザイン株式会社  DOA推進ワークショップ
ビジネス解析方法論であるDOAと、開発プロセス方法論であるRAD、ウォーターフォール、UPなどを現場の最前線で適用している技術者を中心に開設した、sdc独自のワークショップ。PDCAサイクルを回して、さらなる進化と「確かなモデリング∧確かな開発プロセス→いい仕事」の可能性を追求する。


INDEX
第3回:DOAを進めるためのミニマムセット
  システム開発におけるドキュメントのあり方
  業務フロー
データモデル
DOAとは何か!〜開発現場から見るDOA〜
第1回 データ連携の必要性を再確認
第2回 正規化されたRDBとJavaによるデータアクセス
第3回 DOAを進めるためのミニマムセット
第4回 届いてないよ、聴かせてよDOA

人気記事トップ10

人気記事ランキングをもっと見る