XMLデータベース開発方法論（3）　Page 2/4

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

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

■観測が観測対象に影響を及ぼす問題

　絶対中立の観測者は存在しない、という発見は20世紀的な「知」の1つではないかと思う。例えば、排気ガスを測定するために自動車で走り回ると、少なくとも自動車1台分の排気ガスが増えることになる。もしかしたら、本来の排気ガスよりもやや濃度の高い測定結果になるかもしれない。つまり、排気ガスを「観測」するという行為が観測対象である「排気ガス」に影響を与えるということである。

　実は、これに類することがシステム開発においても発生しているのではないかと考えている。例えば、技術者が要件を定義するために実際に業務を行っている人たちにヒアリングするという行為が、業務のやり方を変えてしまう可能性がある。例えば、現場の当事者たちは十分うまくやっていると思い込んでいたものの、技術者から詳細を根掘り葉掘り聞かれているうちに、もっとうまいやり方があることに気付いてしまう、といったこともあり得るのではないか。また、テスト稼働中のシステムを見て、もっとうまい業務のやり方を思い付いてしまう発注主もいるだろう。

　つまり、システムを開発するという作業そのものが、そのシステムが対象とする業務を変化させてしまう場合があり得る。このような変化は開発途中の仕様変更という形で現れる。いつ、どこで、どのような要求が発生するかは、事前に予測することができない。

■人や社会が変化し続ける問題

　ここまで、さまざまな変更に対する要求を見てきた。それらが誤りであり、そのような要求は排除可能と仮定しても、まだほかに変更に対する要求があり得る。

　ごく普通にいまを生きる人たちは気付きにくいのだが、実は人間も社会も、日々わずかずつ変化している。小さな変化が続いていると、それにならされてしまい、何か変化があったとは気付きにくいのだが、数カ月、あるいは数年という単位で時間を切り取ると、劇的に何かが変わっていることがある。システムの開発中に、いつの間にか何か重要な前提が変化していたり、あるいは運用中に変化に直面することも珍しくない。

　例えば、分かりやすい変化の例としては、年号の変化（昭和から平成）であるとか、消費税率の変更がある。しかし、これらの変化は、比較的予測しやすい。今上天皇もいつかは崩御することは予測可能であり、その際年号は変わると推測することはできる。消費税率も、変わることがあり得るのは容易に予測できる。しかし、すべての変化が予測可能というわけではない。例えば、Webアプリケーションでユーザー登録を受け付けるシステムといえば、インターネット黎明期には単にユーザー情報の入力を受け付けるだけでよかった。しかし、スクリプトにより宣伝などのデータを大量に送りつけるような行為が行われるようになると、そう簡単にユーザー登録を受け付けることは好ましくないということになる。その結果、確認のための電子メールの返送を求めたり、最近ではコンピュータには読み取りにくい画像データで表現されたパスコードの入力を要求するということも行われるようになった。このような変化に、もちろんシステムは追従していかなくてはならない。しかし、このような変化は、事前に予測可能であったとはいいがたい。

　結局のところ、開発中、あるいは運用中に、事前に予測不可能な変更が発生することは避けられない。たまたま、そのような変更が発生しないという事態はあり得るが、あるプロジェクトで確実にそのような変更が発生しないという保証は不可能だろう。

■実用十分圏に追従する

　システムに発生する変化を別の表現で語り直してみよう。

　あるシステムが、実際に業務での使用に堪え得るかどうかの境界線は、実はあいまいではないかと思う。人間には高い柔軟性があり、少しぐらい業務に合わない部分があっても、人間がそれに合わせて使うことができる。その範囲を仮に「実用十分圏」と呼んでみよう。実用十分圏は、さまざまな要素が複合されて表現されるものになるが、ここでは単純な円として描いてみよう（図3、ただし、この実用十分圏という円は概念を説明するための便宜上のものであり、具体的に何かを指し示しているわけではないことをお断りしておく）。

図3　実用十分圏とシステムの関係

　実は、実用十分圏は常に微妙に動き続けている。開発中も、運用中もである（図4）。

図4　実用十分圏が動いてもシステムはその内部にある

　しかし、実用十分圏が動いていても、システムがその中に収まっている限り、システムは実用十分であり、変更要求にまでは至らない。

　ところが、実用十分圏が大きく動いて、システムがその外側に出てしまうと、すでにそのシステムは実用十分ではない（図5）。

図5　実用十分圏が大きく動いて、システムはその外に出てしまう

　この場合、システムには修正を行い、実用十分圏に追従しなければならない（図6）。

図6　実用十分圏に追従して、システムを修正する

■仕様変更ができるだけ発生しないような設計とは何か

　これらの図を基に、仕様変更ができるだけ発生しないような設計とは何かを考えてみよう。実用十分圏が移動することは避けられないが、大抵の移動は小さなずれにすぎないことが予想される。ということは、実用十分圏がどちらの方向にずれても、システムがその圏内にとどまるような場所を確保するように設計すればよいことになる。それを達成するための具体的な方策はいろいろあるが、例えば業務の根幹にかかわる本質的なルール（変化しにくい）を軸にシステムを構築し、さまつなルール（変化しやすい）への依存性を減らすと、実用十分圏がずれてもその中にとどまる可能性は高くなるだろう。つまり、そのような設計は行うことができ、おそらく真に有能なベテランSEは、意識的にか無意識的にかは分からないが、そのような設計を行うだろう。そのような設計は、修正の頻度を減らし、スケジュールと予算の超過を防止するものであり、有益である。

　しかし、実用十分圏がどの方向にどの程度移動するかは事前に予測することはできない。従って、変化に対する要求を一切認めないという方針は、おそらく大抵の場合には無理がある。無理があるのに強行している場合は、現場の努力で何とかつじつまを合わせているか、あるい合わせきれずに破たんしているだろう。つまり、無理なく開発を成功させようと思うなら、いかに変化に備えるかということを考える必要があると考える。

■変化を肯定することによる使い勝手の向上

　さて、ここでもう一度、図4を見てほしい。この図を見て思うところはないだろうか。確かに、システムは実用十分圏の中に収まっている。しかし、実用十分圏とは、それを使う人間の柔軟性に期待し、対処可能である円である。つまり、使えるというだけで、快適ではないかもしれない。最善の使い勝手を提供し続けることを目指すのであれば、実用十分圏の移動に追従して、システムを修正する価値がある。

図7　実用十分圏の移動に合わせて、システムも追従して移動する

　従来、このようなことは積極的に行われていない。なぜなら、仕様変更のコストは高くつき、誰もが避けられるものなら避けたいと思っているからだ。しかも単に高くつくだけではなく、繰り返される仕様変更はシステム全体の構造を見通しの悪いものにし、品質やメンテナンス性の低下など、悪い要素を団体で連れてくる。最悪のシチュエーションとしては、システムの破たんということもあり得る。これを避けようと考えることは、当然の感覚といえる。むしろ、何の準備もなく、仕様変更を受け入れるような態度は、知性や想像力や責任感の欠落を示すとすらいえるだろう。それはプロフェッショナルの名に値しないし、アマチュアのプログラマであっても、それなりに高い水準を目指すならば意識する必要がある。

　しかし、きめ細かい仕様変更の繰り返しを積極的に肯定する考え方もある。例えば、エクストリーム・プログラミング（XP）は、「変化ヲ抱擁セヨ（Embrace Change）」をスローガンに掲げていて、システム開発中の変化への要求を積極的に受け入れる。しかし、積極的に変化を受け入れることは可能なのだろうか？ システムが無秩序化してしまい、破たんしてしまうのではないだろうか？

　そうではない。この記事はエクストリーム・プログラミングの入門ではないので、詳細には触れないが、エクストリーム・プログラミングにはプロジェクトの破たんを回避するためのさまざまな方策が組み込まれているし、また、コストアップを防止するための効率の良いやり方も含まれる。これらの規則を厳格に守り、ストイックに取り組むことによってのみ、変化を積極的に受け入れることができる。（次ページへ続く）

2/4

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

XMLデータベース開発論

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）