この前、ＤＢにおけるデータの取得方法っていうところで、データの収集方法には、ボトムアップアプローチとトップダウンアプローチというのがあって、トップダウンアプローチについて、あんまり書いてこなかったけど、こっちのほうが実は重要で、それが、業務知識の重要性に関係し、さらに、現在のシステム開発の大きな問題に関連し、問題解決への重要な第一歩になるはずなんですと、かいた。
この理由について、何回かにわけて、話してみたいと思います。
まず、トップダウンアプローチによる分析を掘り下げてみましょう
■トップダウンアプローチによるヒアリングと帳票分析の位置づけ
トップダウンアプローチは、帳票分析を行う前（実際には予備調査の段階で作る場合もあるんだけど）にＥＲ図を作り、そこのエンティティに帳票分析の結果を埋め込み、必要があればエンティティを足していくという手法です。
つまり、ボトムアップアプローチにおいて、帳票分析は、エンティティを出す主要な方法論になりますが（たしかＥＲＤレッスンなんかも、この立場だと思った）、トップダウンアプローチでは、帳票分析は、すでにあるエンティティに対して、補足、追加、修正という形になります。
で、とくに、このトップダウンアプローチのときにおいて、業界で標準化された内容からエンティティを作成し、それを今回のシステムに合わせる場合は、帳票分析は、本システムに対するカスタマイズともいえます。
■トップダウンアプローチにおける、エンティティの出し方
トップダウンアプローチにおけるエンティティの出しかたには、２とおりあり、
●１つは、見たままをモデル化する。
つまり、エンティティは、モノ（リソース）やコト（イベント）であるので、
・モノを分析する
とりあえず、登場人物（＝ヒト）のエンティティは作ろう（仕入先、得意先など）
そこでやりとりされるモノのエンティティを作ろう（商品など）
（カネのエンティティっていうのは、あんまりない）
・コト（＝イベント：業務）を分析する
帳票をつくるような業務は、まず、エンティティになるので、とりあえず
発生させる
っていうことです。
●もうひとつは、業界標準のものとか、前やってきたものから、パチッってくる
前に似たような業界とか仕事でＥＲ図を作っていたら、そいつをパチッってくる
■業務知識が必要な方法、必要ない方法
後者の業界標準をパチッってくるっていうことは、業界の標準的なシステムの作り方を知っているということ（例えば在庫システムといった場合、どういう風に在庫を表現するかっていうことを知っている）になっている。
つまり、システム開発において、業務知識を持っている必要があるということだ。
ここで問題になるのは、ボトムアップアプローチでも、トップダウンアプローチでも前半の方法は、業務知識がなくても作れる手法なのだが、トップダウンの２つめの手法は、業務知識がないと、かなり作成は難しくなる。逆に業務知識（＝標準的な業界システムの作り方の知識）があれば、カスタマイズということになるので、かなり楽になる。
■最近は業務知識なしでも作れる手法に傾いている
最近のコンピューターの本屋さんに行くとＷｅｂのはなしやＪａｖａの話、ＤＢの話、ＵＭＬの話などが中心であり、業務知識の話は少ない（つーか、ほとんど、ない）。
というように、昔は（２０年位前、第三次オンのＳＥがいたころ）、業務知識の話も多かった気がするけど、最近は業務知識なしでも作れる、純粋にコンピューター技術の話に世の中が傾いていると思う。
じゃあ、業務知識は必要かどうか。。。について例をあげて、詳しい話をするのは、また次回にしよう。
アクセス
トータル
ランキング
