Agonizing Days: 要求考古学

この間の要求開発アライアンス合宿勉強会のワークショップの中で出てきたキーワード「要求考古学」について考えています。

■要求考古学の定義

考古学は人類が残した痕跡(例えば、遺物、遺構など)の研究を通し、人類の活動とその変化を研究する学問である。
Wikipedia:考古学より

を参考とするならば、要求考古学の定義は次のようになるかと思います。

要求考古学は設計者が残した痕跡(例えば、現行システム、設計書、マニュアルなど)の分析を通し、本来のシステム要求とその変化を研究する学問である。

要求考古学が必要とされるシチュエーションは、次のようなケースをぼんやりと考えています。

現行のITシステムに新たな機能(要件)を追加する必要がある。
現行のITシステムが何らかの理由で維持困難となり、現行システムの要件を充足した新システムを構築しなければならない。
ITシステムのデータを再利用する目的で取得し、何らかの処理を行なう必要がある。

こういった作業の際に、システムの当初の要求(要件)が不明である場合(当初の関係者がいない場合を含む)には、作業者は要求考古学を用いて要求発掘を行う必要があります。

■古典的要求考古学

さて、最も簡単なアプローチは何でしょうか。それは「観察する」です。つまり、

現存するドキュメントを読む
動かしてみる
プログラムを追いかけてみる

ことにより、なぜそうなっているのかを類推するアプローチです。

実際にITシステムの保守フェーズでは、こういったアプローチは一般的に行われていると思います。ちょっとした機能の追加を小規模に行う場合には、適用可能な方法です。

しかし、このアプローチには、2つの問題があります。

■効率の問題

ITシステム開発では、「仕様の爆発」という現象が発生します。

真実26.仕様定義フェーズから設計フェーズに移るとき、膨大な数の「派生仕様(derived requirements:仕様を具体的な設計方式にブレイクダウンする場合、設計方式に対する要求仕様)」が生じる。これは、問題解決プロセスが複雑なために発生するもので、この設計設計の量は元の仕様の50倍になることもある。
ロバート・L・グラスソフトウェア開発55の真実と10のウソより

これはつまり、当初の要件が、最大で50倍の文書等に分散してしまうということを言っています。実際にはここまでの爆発はあまりないと思いますが、それでも、爆発した仕様の破片から、当初の要件を導き出すのは効率的ではないと言えます。

■正しさの問題

もう一つの問題は、現行システムを観察しても「正しい要求」を導き出せない事があるという点です。これには二つの理由があります。一つはソフトウェア開発特有の原因です。

真実27.ソフトウェアの開発において、ベストの解法が１つしかないことは、まずありえない。
真実28.ソフトウェアの設計は、複雑で反復が必要なプロセスである。従って、最初に考えついた設計方式が間違っている可能性は高く、最適解ではない。
ロバート・L・グラスソフトウェア開発55の真実と10のウソより

つまり、今見えている仕様が最適解であるとは限らないのです。その仕様を元に当初の要求を考察したとして、本当に正しい要求に立ち戻れるかは大きく疑問があります。

また、もう一つの問題点としては、現行システムが「当初の要求ではなく、要求の代替策を表象している」可能性があることです。現行システムを最初に開発した時には、何らかの理由で要件を満たすことができず(例えば、パフォーマンス等の問題により)、より望ましくない要件(例えば計算を簡略化するなど)が採用されている場合、観察によって当初の要件が得られることはまずありません。

というわけで、改めて書き下してみると、古典的要求考古学は問題点が山積みです。長くなってきたので、次回は別のアプローチを考察してみようと考えています。