アジャイル開発におけるDB設計の現実〜その１〜

XPのプラクティスのうち、シンプルな設計と言うものが
あります。
これはYAGNI(You Aren't Going to Need It)の原則にの
とって、「今必要のあることだけをやれ」ということです。
そうすることで、過大な設計を防ぎ、変更に強いシステム
を作ることを目指すのです。
その為には、常にアプリが変更しやすい状態を維持する
必要があり、それは、アプリ変更時、つまりは機能変更
や機能追加時に変更に強い状態を維持(リファクタリング)
することで可能になります。
そして、頻繁なリファクタリングを可能にするためには
リファクタリング前と後でアプリケーションの動作に
影響がないことを保障するメカニズムが必要になります。
それがJUnitなどに代表されるUnitTestです。
テストの結果グリーンバーが表示されることでリファク
タリングの結果システムに影響がないことを確認できる
わけです。
ところが、現実には変更に関しては非アジャイルラーな
方々には中々理解してもらえないのが現実です。
フォーターフォールに代表される開発プロセスに慣れ親
しんでいる方はイテレーションつまり、イテレーティブ
でインクリメンタルな開発を中々理解できないみたいです。
フォーターフォールと違い、工程を要件定義、基本設計、
詳細設計、実装、テストなどのフェーズに分けないため、
要求から実装、テストまでの距離が近い、つまりは、
要求変更があった場合でも、変更のコストが低いのです。
特にイテレーティブでインクリメンタルな開発のインクリ
メンタルの部分が理解できない人が多く見受けられます。
イテレーティブの部分に関してはフォーターフォールで
言うところの各工程を細かく(機能単位で)開発して、
回していく(厳密には違うのだけど)感覚で、
理解してもらえるのだけど、インクリメンタルの部分が中々
理解してもらえません。
そもそも、何故にインクリメンタルで開発する必要があるか
です。
それを考えるとわかってもらえる場合があるかな？
インクリメンタルに開発するとは、1回転つまり、
1発で100%のできのシステムを開発できないからです。
アジャイル開発が得意とする分野、例えば新規ビジネス
の立上げや新商品の開発などは、間違いなく1発で正解に
たどり着くのが難しい分野です。
ユーザとの開発中の対話が重要ですし、競合他社の動き
に合わせて、システム要求を柔軟に変化する必要もあり
ます。また、初めてのものを作るため、ユーザも正確な
答えを知りません。実際には動くシステムを見ながら、
修正変更する必要があるのです。
なので、1回転で100%のものを作ってしまってはやり過ぎ
なのです。戻りもその分多くなり、効率もよくありません。
それは、1回で成功にたどり着けないからです。
実際には60%や70%のできでシステムを開発し、ユーザ
からのフィードバックで最終の形態に持っていく必要が
あります。当然後の仕様でシステムの変更を余儀なくさ
れる場合もあるのです。
こう説明すると不安に感じるエンジニアも多いと思いま
す。特にDB設計を担当するエンジニアは、「そんなアプ
リの都合ばかりに合わせていて本当に理想的なDB設計が
実現できるのか？」という方が殆どです。
DB設計に関してはアジャイルの場合は正直、力関係が
変わります。フォーターフォールなどの開発プロセス
では、たいていDB設計は上流工程で確りとしたモデリ
ングを行い、全体最適の中、そのシステムにあったDB
設計を行うのが常です。
アジャイルの場合はYAGNIが基本ですし、そもそも全体の
要求などはあがって来ませんので、全体最適といっても
無理な話です。
ではどうすればいいのかって？ここからが私の実践の話
になるのですが、夜も遅いのでその話はまた明日。