XMLデータベース開発方法論(3) Page 3/4

変化は抱擁せざるを得ない、しかも禁欲的に


川俣 晶
株式会社ピーデー
2005/8/19

リファクタリングになじむDB、なじまないDB

 エクストリーム・プログラミングでは、仕様変更のコストを下げるために、リファクタリング、自動化された単体テストなどの手法を含んでいる。ここでは、リファクタリングという手法に注目してみよう。リファクタリングとは、ソースコードをよりよくするための書き換えの手法である。といっても、ソースが汚くなったのできれいに書き直しましょう……というよくある話とは違う。リファクタリングは、ソースコードに新しい機能を付け加えない。機能を維持したまま、ソースコードの意味ではなく、形を見て、カタログと照らし合わせながら、重複のないシンプルな形に置き換えていく。より具体的にいえば、リファクタリングとは小さなソースコードの書き換えの集合体である。個々の小さな書き換えは、プログラムの機能を変えない。それ故に、リファクタリングはいつでも打ち切ることができ、どこで打ち切ってもプログラムは正常に動作する。

 さて、この手法をそのままデータベースに適用することは無理であるが、同じような趣旨の作業を行うことはできる。つまり、小さな変更を積み重ねることにより、最終的にデータベースをあるべき姿に仕上げていく作業は可能だということである。

 しかし、その難度は、データベースの種類によって異なっている。例えば、RDBの場合は、全体的な整合性を取るために正規化の手順が必要とされるが、それによってテーブルの数や分割方法が変化してしまうことがある。このような変更が引き起こす影響は大きい。データベースを変更する場合、それにアクセスするソースコードもすべて変更する必要があるが、その範囲が膨大になってしまうということである。つまり、小さな変更と、場合によっては大きな変更を合わせて行うことになるが、大きな変更の途中で作業を打ち切った場合、それは機能しない。つまり、リファクタリングと同様の作業を行うのは難しい。

 これに対して、XMLデータベースは正規化という手順が存在しないので、小さな変更を積み上げていくという手法を問題なく適用できる。つまり、XMLデータベースは、エクストリーム・プログラミングのような変化を積極的に受け入れる開発手法との相性が良いということが考えられる。

 さて、変化を積極的に受け入れる開発手法との相性が良いということは、裏を返せば、変化への適応をより少ない手間、より少ないコストで実行可能ということである。そのことから考えると、RDBを採用したシステムと、XMLデータベースを採用したシステムでは、変更に対するコストの構造が違うことが考えられる。つまり、RDBではなくXMLデータベースを採用することにより、変更に対するコストが下がり、前ページの図7のような開発スタイルを取ることも、無理ではなくなる可能性が出てくる。

 これは、XMLデータベースを採用すべき強い理由となるかもしれない。

変化への要求は、禁欲的に受けよ

 エクストリーム・プログラミングは、プラクティスと呼ばれるいくつかの作業手順の集合体として構成されている。個々のプラクティスはさほど複雑ではなく、これをよりよく変更したいという誘惑に駆られる者は多い。プラクティスを増やしたり減らしたり、あるいは、ほかの開発方法論と組み合わせて1つの体系に仕上げるといった大きな修正を行う者もいる。しかし、このような変更は大抵の場合、破たんすると思ってよいだろう。エクストリーム・プログラミングのプラクティスは、互いの弱点を補強するように組み上げられている。そして、最大限の効率を達成すべく、不必要な要素を排除している。このような状況に対して、たとえよいものであっても付け加えることはバランスの崩壊を招く。例えていえば、細いロープの上を歩く綱渡りのようなシビアさを持つのがエクストリーム・プログラミングではないか、という印象を筆者は持つ。つまり、エクストリーム・プログラミングを実践し、変化を積極的に受け入れることは、1つの極めて困難でストイックなチャレンジということができるだろう。

 とはいえ、このようなエクストリーム・プログラミングの持つストイックさが正しく理解されているかというと、かなり怪しい面があると感じる。おそらく、エクストリーム・プログラミングについて説明していると称する書籍や雑誌記事やWebサイトの9割は、適切な内容を含んでいないという印象がある(もっとも、それは驚くに当たらない。なぜなら「SFの90%はクズである。しかし、世のあらゆるものの90%もまたクズである」というスタージョンの法則に対して、エクストリーム・プログラミングもまた例外ではなかったというだけの話にすぎない)。

 重ねて強調しよう。変化を積極的に受け入れるというのは、ストイック=禁欲的な行為でなければならない。変更の要求を何でもすぐに受け入れるのは、ストイックな態度とはいえない。その変更が本当に必要なのか。その変更のために必要なコストはどれぐらいで、そのコストを払うに値するのか。それよりも優先順位の高い作業がほかにはないのか。それらの問題をきちんと検討したうえで、本当に変更すべきであると分かったものは、積極的に受け入れるべきだと考える。

 このような考え方は、おそらく一部の読者には分かりにくく、受け入れにくいだろう。変化を積極的に受け入れるということは、ある意味で秩序を放棄することになり、混沌を目指すことを意味する。プログラムやデータベースが混沌に落ちるということは、つまりは秩序だった仕事をこなす能力を持ち得ないことを意味する。何となく仕事をしているかのように見えるプログラムやデータベースは得られるかもしれないが、それがどれほど正しく仕事をこなすかは誰も保証できない。従って、変化を積極的に受け入れることなど、自滅行為であり、受け入れるべきではないという考えはあり得るだろう。

 しかし、一方で秩序がシステムを破たんさせるというのもまた事実である。原則、規則、設計などでがんじがらめになったシステムは、ユーザーが要求する実用性に適応することができなかったり、できるとしても非現実的な時間とコストを要する場合がある。また、完ぺきな秩序への指向は、官僚主義への指向といい換えることもでき、所定の書式の文書や手順を要求したり、作業手順に含まれないというただそれだけの理由で、正当な変更要求を拒絶するような事態も起こり得るだろう。実際、あるソフトウェアの開発プロジェクトで、目の前のささいなバグを1つ取るのに書類を回さなければならないというプログラマのぼやきを聞いたことがあるが、結局そのソフトウェアはライバル製品に圧倒的に敗北し、いまは名を聞くことすらない。秩序を強く指向するだけではうまくいかない事例であるように筆者には思える。

 このように考えると、混沌も秩序も、いずれも破局への入り口でしかないように思える。しかし、世の中は、混沌と秩序だけからできているわけではないらしい。そのアイデアは、『適応型ソフトウェア開発 ―― 変化とスピードに挑むプロジェクトマネージメント』(ジム・ハイスミス著)に見られる。この書籍では、秩序と混沌の間に、「カオスの縁」と呼ばれる領域があり、秩序にも混沌にも落ち込まず、この領域にとどまり続けることが開発を成功させる要因になる、と述べている。そして、「カオスの縁」とは不安定な領域であり、そこにとどまり続けるには多くの努力とストイックさが必要とされる。つまり、安定した秩序を求める「欲」や、もっと楽をするために安易に仕事を進めたいという混沌に堕する「欲」を断ち切る禁欲が必要とされるということである。

 ちなみに、単なるテキストファイルは何の秩序もなく「混沌」、RDBは規則正しくデータを格納しなければ受け付けてくれない「秩序」、そしてXMLデータベースは「カオスの縁」を代表する技術であると考えることができるかもしれない。

 もちろん、「カオスの縁」という考え方は1つのアイデアであって、それが正しいか否かは分からない。しかし、いまのわれわれが、混沌と秩序以外の第3の道を必要としていることだけは間違いないだろう。そして、その道は、ストイック=禁欲的な態度でのみ、通り抜け可能ではないかと感じている。(次ページへ続く)

3/4

 Index
XMLデータベース開発方法論(3)
変化は抱擁せざるを得ない、しかも禁欲的に
  Page 1
・前回のおさらいと今回のテーマ
・変化に弱いRDB
・対象を厳密に定義できない問題
・対象の定義を厳密に表現できない問題
  Page 2
・観測が観測対象に影響を及ぼす問題
・人や社会が変化し続ける問題
・実用十分圏に追従する
・仕様変更ができるだけ発生しないような設計とは何か
・変化を肯定することによる使い勝手の向上
Page 3
・リファクタリングになじむDB、なじまないDB
・変化への要求は、禁欲的に受けよ
  Page 4
・XMLデータベースを使うべき条件
・終わりに


XMLデータベース開発論


Database Expert フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Database Expert 記事ランキング

本日月間