« アジャイル手法は分野毎に違っていい | トップページ | 超高速開発ではなく「超少人数開発」を »

2013.08.09

CRUD図をわざわざ作る?

 システム設計資料のひとつに「CRUD図」と呼ばれるものがある。システムに含まれているそれぞれの機能(データ処理プログラム)が、それぞれのテーブルに対してどんな操作をしているか。それをマトリックス形式で俯瞰するためのものだ(次図)。操作として"CRUD"として示された場合には、Create,Read,Update,Deleteの全操作がされている、という意味になる。ちょっとした設計ミスもこの資料を使えば見つけやすい。

20130809a

 この表は「機能」と「データ」の関係を示したものであるが、CRUD関係を見るための切り口としては「業務」もはずせない。ここで言う「業務」とは「特定の役割を担う要員が、特定のイベントが起こったときに実施する一連の手続き」に名前を与えたもので、「業務単位」や「業務定義」とも呼ばれる。DFDで描かれた業務フローには、これらの業務単位がデータフロー図上のプロセス(楕円で示される)として置かれる(次図)。

20130809b

 ひとつの「業務」はいくつかの機能を利用する形で実施される。たとえば「受注登録」の業務は、「受注エントリー」や「受注データの保守」といった機能を用いて実施される。ゆえに、それぞれの業務でどの機能が利用されるか(業務×機能)をまとめたマトリックスも欲しくなる。さらに、それぞれの業務においてどのデータに対してどんな操作がなされているかのCRUD図(業務×データ)も欲しい。

 他にも、それぞれの業務フローにどの業務が載っているか(業務フロー×業務)や、それぞれの業務フローにどの機能が関わっているか(業務フロー×機能)といった切り口でも見たい。

 ようするにこれまでCRUD図と呼んでいたものは、さまざまな設計要素のマトリックス関係の特殊な例に過ぎない。狭義のCRUD図は「機能×データ」の関係表として理解されているが、その見方だけでは業務システムのあり方を俯瞰するには十分ではないのである。

 CRUD図をはじめとする各種設計要素の交差関係を表す図(マトリックスリストと呼んでおく)に関して、見逃せない論点がもうひとつある。それらの図表が設計情報から導出可能であるという点だ。

 多くの開発現場で設計資料は悪名高い「Excel方眼紙」を用いて作成されている。そのような現場では、マトリックスリストは現時点の設計情報を分析することによって手作りされなければいけない。規模の大きな案件ではそのコストは小さくないし、仕様変更に伴う作り変えのコストも無視できない。結果的に、設計情報とCRUD図は乖離しやすい。

 設計資料をExcel方眼紙で作ることはさまざまな見地から批判されているが、マトリックスリストを手作業で作成・保守する羽目になるという点でも問題がある。設計情報の専用の管理ツールを用いれば、マトリックスリストなど自動出力できるし、それを大事に保管する必要もない。仕様変更があるたびに出力し直して眺めれば済むからだ。システムを俯瞰的に把握するための多彩な図表が導出的に手に入る――それは設計情報の専用の管理ツールを使うことの山ほどある利点のひとつである。

 近日公開されるモデリングツールXEAD Modelerの最新リリースでは、上述した5種類のマトリックスリストを手軽に出力できるようになる(2013/8/14公開済)。活用してほしい。CRUD図をわざわざ作っている?そんな作業はやめよう。顧客にとってのシステム化予算の無駄遣いだし、なによりも人生の無駄遣いというものだ。

|

« アジャイル手法は分野毎に違っていい | トップページ | 超高速開発ではなく「超少人数開発」を »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: CRUD図をわざわざ作る?:

« アジャイル手法は分野毎に違っていい | トップページ | 超高速開発ではなく「超少人数開発」を »