読者です 読者をやめる 読者になる 読者になる

勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

アジャイルとデータモデル、DB進化設計のこと

「データモデルなきアジャイル」の危うさ: 設計者の発言」を読んで考えたこと。業務ソフトウェアの開発において、データベースを進化設計するのは厳しいと思っている。確かに技術的にはDBをリファクタリングしていくアプローチは可能だけれども、今のところは現実的な選択肢としては考えにくい。それではどうするか。

データモデルなしでアジャイルを始めてはいけない。少なくとも、DB全体の設計妥当性に関する何らかの担保がないままでアジャイルを強行してはいけない。DB構造の劣悪さゆえに企業活動の変化や発展に追随できない業務システム――皮肉にもそういうアジリティに欠けたシロモノをまたぞろひり出すことになるからだ。
「データモデルなきアジャイル」の危うさ: 設計者の発言

データモデルは単なるDB構造の話ではない

扱うビジネスの内容や範囲によるけれども、データモデルやDB構造は単なる記憶装置では無く、企業の資産であると考える必要がある。雑なデータモデル上に構築されたシステムは、例えば以下のような問題を抱えてしまうことになる。

  • 他のシステムとの統合が困難となる。システムの枠を超えたビジネスの変化に対応できない
  • (独自性の高すぎるデータモデルが原因で)他のシステムへのデータ移行も選択できなくなってしまう
    • 例えば該当分野のコモディティ化した安価で優秀なパッケージソフトウェアやサービスが提供されるようになっても移行できず、現行のシステムに縛られ続けてしまう
    • もちろんコアビジネス(他社との差別化部分)についてはデータモデルの独自性があっても良い。なぜならその部分は汎用品や汎用サービスに移行する可能性が低いから。しかし、コアビジネス以外であれば、独自性の高いデータモデルは害だと思う(もちろん、過去のモデルからの連続性などもあり、一概に言えることではないけれど)。

このあたりはDAMBOKがおそらく詳しいのだけれども、残念ながら未勉強なので深くコメントできない。勉強不足を反省。
記者の眼 - 一生使える「SEの共通言語」:ITpro
DMBOK Guide入門 - [後編]「データアーキテクチャ」を作るには:ITpro

何が言いたいのかというと、データモデルに対する手を打たずにアジャイル開発を始めるのはやっぱり厳しいということ。

データモデルはアジャイルに開発できるのか

もちろん、世の中にはデータベースのリファクタリングや進化設計に関する方法論もある。
データベースの進化的設計
データベースもアジャイル開発に対応したい! (1/3) − @IT

データベース・リファクタリング

データベース・リファクタリング

  • 作者: スコット W アンブラー,ピラモド・サダラージ,梅澤真史,越智典子,小黒直樹
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2008/03/26
  • メディア: 単行本
  • 購入: 9人 クリック: 184回
  • この商品を含むブログ (44件) を見る

ただ、これらの方法論が扱っているのは「単なる記憶装置としてのデータベース」であって、情報資産を扱っているわけでは無いという印象。データベース・リファクタリングもレガシーデータベースを料理するテクニックといった趣きである。

少しずつ反復的に行うという性質を持つ発展型のアプローチは、今日のソフトウェア開発において事実上の業界標準となっている。プロジェクトチームが発展型の開発アプローチを採用することに決めたなら、データ専門家も含め、チーム全員が発展型で仕事をしなければならない。幸いにも、データ専門化が発展的に作業をするための発展型手法が存在する。たとえば、データベース・リファクタリング、発展型データモデリング、データベース回帰テスト、データ指向成果物の構成管理、開発者用サンドボックスの分離などである。
データベース・リファクタリング

少しずつ改善していくテクニックは重要なのだけれども、スタートラインにどう立てばベストなのかよくわからない。

要求開発、構想フェーズ、イテレーション・ゼロ、アーキテクチャ助走路

それではどうすれば良いか。やはり本格的にアプリケーションを開発する前に、しっかりとデータモデルの検討をするのが良いと思う。

イテレーション・ゼロのことを、プロジェクトの最初のイテレーションだと言う人もいれば、プロジェクトを始める前のイテレーションだと言う人もいる。どう呼ぶにせよ、とにかく開発作業の準備を整えるのがイテレーション・ゼロだ。
アジャイルサムライ−達人開発者への道−

アーキテクチャ助走路を持つシステムは、過剰なリファクタリングなしに現在および予想される要求を組み込むことができる、既存の、もしくは計画済みのインフラをもつ。(中略)複雑なシステムにおいては、十分なアーキテクチャ助走路を構築し維持することは全体的な生産性を確保するための鍵である。
アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)

ところで、じゃあ皆はどうやっているのだろう? 今度聞いてみようと思う。

2012/9/7 追記

平鍋さんのブログでも取り上げられているので参照推奨。

2012/9/10 追記

DMBOKのことをDABOKと誤って表記していた(恥ずかしい)。誤字を訂正。