「「データモデルなきアジャイル」の危うさ: 設計者の発言」を読んで考えたこと。業務ソフトウェアの開発において、データベースを進化設計するのは厳しいと思っている。確かに技術的にはDBをリファクタリングしていくアプローチは可能だけれども、今のところは現実的な選択肢としては考えにくい。それではどうするか。
データモデルなしでアジャイルを始めてはいけない。少なくとも、DB全体の設計妥当性に関する何らかの担保がないままでアジャイルを強行してはいけない。DB構造の劣悪さゆえに企業活動の変化や発展に追随できない業務システム――皮肉にもそういうアジリティに欠けたシロモノをまたぞろひり出すことになるからだ。
「データモデルなきアジャイル」の危うさ: 設計者の発言
データモデルは単なるDB構造の話ではない
扱うビジネスの内容や範囲によるけれども、データモデルやDB構造は単なる記憶装置では無く、企業の資産であると考える必要がある。雑なデータモデル上に構築されたシステムは、例えば以下のような問題を抱えてしまうことになる。
- 他のシステムとの統合が困難となる。システムの枠を超えたビジネスの変化に対応できない
- (独自性の高すぎるデータモデルが原因で)他のシステムへのデータ移行も選択できなくなってしまう
このあたりはDAMBOKがおそらく詳しいのだけれども、残念ながら未勉強なので深くコメントできない。勉強不足を反省。
一生使える「SEの共通言語」 | 日経クロステック（xTECH）
［後編］「データアーキテクチャ」を作るには | 日経クロステック（xTECH）
何が言いたいのかというと、データモデルに対する手を打たずにアジャイル開発を始めるのはやっぱり厳しいということ。
データモデルはアジャイルに開発できるのか
もちろん、世の中にはデータベースのリファクタリングや進化設計に関する方法論もある。
データベースの進化的設計
データベースもアジャイル開発に対応したい！ （1/3） − ＠IT
少しずつ反復的に行うという性質を持つ発展型のアプローチは、今日のソフトウェア開発において事実上の業界標準となっている。プロジェクトチームが発展型の開発アプローチを採用することに決めたなら、データ専門家も含め、チーム全員が発展型で仕事をしなければならない。幸いにも、データ専門化が発展的に作業をするための発展型手法が存在する。たとえば、データベース・リファクタリング、発展型データモデリング、データベース回帰テスト、データ指向成果物の構成管理、開発者用サンドボックスの分離などである。
データベース・リファクタリング
少しずつ改善していくテクニックは重要なのだけれども、スタートラインにどう立てばベストなのかよくわからない。
要求開発、構想フェーズ、イテレーション・ゼロ、アーキテクチャ助走路
それではどうすれば良いか。やはり本格的にアプリケーションを開発する前に、しっかりとデータモデルの検討をするのが良いと思う。
- プロジェクト開始前の企画段階(構想フェーズ)でデータモデルに関して議論をしておく。例えば要求開発のようなアプローチが考えられる。もちろん、実際にソフトウェアの開発を始めると、いろいろと変化してしまう部分はある。しかしちゃんとした土台があるのであれば、まだやりようはある。
- プロジェクト内で対応するのであれば、RUPなどの反復開発手法を採用してしっかりとした「構想フェーズ」でデータモデルに向き合う。
- とにかくアジャイルに拘るのだったら、イテレーション・ゼロでデータモデルに関して検討をしたっておんなじ。アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)においては、アーキテクチャ助走路と言ってたっけ。
イテレーション・ゼロのことを、プロジェクトの最初のイテレーションだと言う人もいれば、プロジェクトを始める前のイテレーションだと言う人もいる。どう呼ぶにせよ、とにかく開発作業の準備を整えるのがイテレーション・ゼロだ。
アジャイルサムライ−達人開発者への道−
アーキテクチャ助走路を持つシステムは、過剰なリファクタリングなしに現在および予想される要求を組み込むことができる、既存の、もしくは計画済みのインフラをもつ。(中略)複雑なシステムにおいては、十分なアーキテクチャ助走路を構築し維持することは全体的な生産性を確保するための鍵である。
アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)
ところで、じゃあ皆はどうやっているのだろう？ 今度聞いてみようと思う。
2012/9/10 追記
DMBOKのことをDABOKと誤って表記していた(恥ずかしい)。誤字を訂正。
