« データ中心アプローチと「業務モデル」 | トップページ | 業務システム向けのデザインパターン »

2012.08.22

「データモデルなきアジャイル」の危うさ

 例によってこれは「業務システム」に関する議論である。ゲームソフトでも組込み系でもB2Cサイトでもサービス系でもなく、販売管理システムや生産管理システムといった基幹系業務支援システム(DB構造が複雑なシステムといってもいい)に限った話だ。その種のシステムをアジャイル開発しようと考えるのであれば、それまでにシステム全体の「あるべきデータモデル」が確立されていなければならない。

 業務システムを「身体」に喩えるなら、データモデルは「骨格の設計図」に相当する。いっぽうアジャイル開発で導き出せるのは身体の表面上の諸問題、すなわち「皮膚のぐあい」とか「顔つき」のようなものだ。そういった特徴についていかに緻密に決定できても、それらから「あるべき骨格の姿」は導けない。

 DB構造のそういった特性を公知させたのが、前回記事で説明した「DOA(データ中心アプローチ)」だった。機能のあり方を確立したうえでデータのあり方を導くやり方(POA)をとったゆえに、保守性が最悪なシステムが山ほど出来上がってしまった。その反省からDOAは「データのあり方を確立したうえで機能のあり方を導くべきだ」と提唱したのだった(前回記事で指摘したように、この考え方にも議論の余地がある)。

 もしアジャイルをデータモデルなしで始めるとすれば、POA的にならざるを得ない。なぜならアジャイルは「仕様の確立は『動くソフトウエア』によって主導されるべし」という「設計方法論」だからだ。ユーザが納得できる「動くソフトウエア」をまずプログラミングして自動テストまでやって、その機能単位の入出力を支える形でDB構造を逐次補完してゆくという手順を踏むことになる。DB構造の継続的リファクタリング手法の一種などと説明すれば聞こえはいいが、ようするに危ういPOAである。

 POAであるだけでなく、システム刷新時に旧システムのDB構造を是認しやすいという問題もある。仕様検証を担当するユーザが「旧システム(問題含みであるはずのシステム)に馴染んだユーザ」だからだ。「プロダクトオーナー」なんてご都合主義的役回りを導入しても事情は変わらない。システム仕様の妥当性を判断するための材料が、UIという「上っ面」であることに違いはないからだ。トップによって決断された全面刷新プロジェクトさえも「言語とUIの置換プロジェクト」と化して、諸悪の根源である劣悪なDB構造が無批判に継承されてしまうかもしれない。「それがプロダクトオーナーの判断結果なのだからしかたない」などと言い抜けられる問題ではない。

 データモデルなしでアジャイルを始めてはいけない。少なくとも、DB全体の設計妥当性に関する何らかの担保がないままでアジャイルを強行してはいけない。DB構造の劣悪さゆえに企業活動の変化や発展に追随できない業務システム――皮肉にもそういうアジリティに欠けたシロモノをまたぞろひり出すことになるからだ。かつてDOAによってさんざん批判されたPOAが一世代の雌伏を経てよみがえったものが「アジャイル」であるなら、そんなものには関わらないほうがいい。

 ただし私はアジャイルを全否定する気は毛頭ない。データモデルが確立されたうえで開始されるアジャイルであれば、それこそ最強であろう。

 ところが前回記事でも説明したように、データモデルを確立するためには、業務モデルや機能モデルと摺り合わせる必要がある。もしアジャイル開始時点でまともなデータモデルが手元にあるとすれば、機能モデルも業務モデルもすでに手にしているということだ。そこまで周到に図面化したうえで始める開発作業は、果たして「アジャイル」と呼べるものなのだろうか。

本ブログでの参考記事
あんまりプログラミングしないけどアジャイル
「DB構造を見直さない」というアンチパターン

|

« データ中心アプローチと「業務モデル」 | トップページ | 業務システム向けのデザインパターン »

コメント

 こんにちは。
 アジャイル開発と言っても色々で、最近流行りのScrumという手法は、開発の中身に関しては何も言及していません。ですが、私の知っているある人達は、データモデルは書いています。また、FDDという手法では、ドメインモデリングから始めると有る様に、データモデルが出発点です。
 ブログの最後の部分に関して言えば、次の様に考えます。私は、渡辺さんの言う「3要素」を一緒に考えないで、まずビジネスが有り、そこで使われる情報を解明したデータモデルが有る。ここまでは、ある種の前提です。
 企業が自社の「情報」を管理するならデータモデルが有るべきだと考えているからです。
 ビジネスが有り、そこでの情報を解明したデータモデルが有る。そこに、それをどう扱いたいか、ここで初めて「機能」が登場します。
 その、場合によっては実現のしかたが漠然とした状態で、それが作成された時の価値(効果)を設定し、それを迅速に開発し、価値を手に入れるための開発がアジャイル開発だと考えています。
 そして前提にしたデータモデルができていない場合は、できるだけ先にデータモデルを作ること。そのデータモデルを作るということ自体が、思ったほど時間がかからない(ただし、ビジネス側に疑問をかかえていない場合)ので、データモデルを作って、或いはそれを成長させながらのアジャイル開発は有りだと思いますよ。

投稿: 稲見浩一 | 2012.08.24 09:21

稲見さん

なるほど。つまり、事前にビジネスプロセス(業務モデル)が明らかになっていて、それにもとづくデータモデルがまとまっていれば、アジャイル開発を開始して機能のあり方(機能モデル)を探る、と考えれば納得感はありますね。

ただ、業務モデルとデータモデルが明らかになっているのに、それらをいったん持ち帰って作業(アジャイル開発)するってのがどうにも鈍臭い。それだけの材料があるなら、その場で機能モデルまでをガリッと描き広げてしまったうえでアジャイル開発に取り掛かったほうが、よほど効率がいい。

ですから私には、事前に確立された業務モデルとデータモデルと機能モデルをさらに効率的に洗練させるための「高等テクニック」としてアジャイル開発があるように思えます。

いずれにせよ、事前にデータモデルが確立されていない状態で開始されるアジャイルはクワセモノですよね。「このプロジェクトではデータモデルをまとめる時間的余裕がない」なんて言い訳もダメ。データモデリングは専門技術ですが、言われるように作業時間はたいしてかからないですからね。

投稿: わたなべ | 2012.08.24 14:59

渡辺さん、
「持ち帰って」とか「その場で」は、物理的な位置の話ですか?
効率的に洗練させるっていうのは、「動くプログラム」でってことかな。データモデルにも影響有るけど、データモデルの洗練という点では、別な場面の方が影響有るかも知れません。
いずれにせよ以降は、本当にそう思います。ま、新しいWebサービスなんか作る場合で、数人のプログラマで一緒にクラスを考えている場合とかは、そのままコードとしてのクラスでも良いでしょうけど。
逆に、過去の経験では、データモデルを書いて行く内に、業務の課題が浮き彫りになり、それ自体がなかなか解決できなくて開発は先送りなんてことも有りましたけどね。

投稿: いなみ | 2012.09.04 16:28

「その場」は物理的な「ユーザとの打ち合わせのその場」です。アジャイル以前にそもそも、その場でできるだけ仕様を確立することが徹底されているべきです。

だから、「動くプログラム」を持ち帰りで作れることよりも、ユーザに納得感をもたらす絵を打ち合わせのその場で描けることのほうがよほど大事です。それこそ、業務上の課題を浮き彫りにしてしまうようなシャープな絵を描けるくらいでなきゃいけませんよね。

投稿: わたなべ | 2012.09.04 19:12

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 「データモデルなきアジャイル」の危うさ:

« データ中心アプローチと「業務モデル」 | トップページ | 業務システム向けのデザインパターン »