日々の破片

_ 詳細設計書は死んだ。とっくの昔に死んでいる。でも生き返る必要はある

流儀や呼び名はいろいろあるだろうが、ここでは3種類あることにする。

・要件定義書

要件を定義したもので、ユースケースについて記述したものだ。

・機能設計書

要件を機能として記述したものだ

・詳細設計書

機能を実装に落とし込むものだ

で、詳細設計書って何それおいしいの？ ということだが、もちろん不味い。むしろ毒だと言うべきで、そんなものを記述するよりさっさとプログラムを書けば良いし、その時間を使ってテストプログラムを書けばさらに良い。

特に、1990年以降、オブジェクト（あるいはクラス）ライブラリが拡充され、APIがほとんどなんでもやってくれて、コンポーネントがそこら中に転がり始めてからは、単にそれらをグルーでつないでいくのがほとんどなのだから、そんなものを書いてもまったく意味がない。

しかし、実はそう単純でもない。

問題は詳細なビジネスルールにある。本来ビジネスルールは要件なのだが、ユースケースで考えると、詳細なビジネスルールはユースケースレベルとして記述するのが難しい。

例として、ある商店では、以下のように買い物客からの買い上げ額を計算するとする。

・商品は総額表示されていたとしても、消費税を抜いた額とする。

このとき、式として総額表示*100/(100+消費税%)を利用する

・ただし、同一商品を複数購入した場合は、（総額表示×個数)*100/(100+消費税%)を利用する

・もし割引販売した場合は、総額に対して割引、その結果の額から……

・もし買物券を出されたら、合計金額（税込）に対して一度消費税を抜いた額を求めて……

・3個で幾らという売り方をした場合は、3で割り切れない場合に、どう消費税を割り当てるか。同様に割引した額をどう割り当てるか。

こういったことは要件としては実は明らかにならず、いざ機能を定義する時にわかることがあり、しかも、機能を定義した後に、実際にコード化する時に相互に矛盾を発見することがある。

粒度の問題なのだ。そして、機能の定義にすらあてはまらないほど細粒度となることがある。

いや、それはプログラムするからいいじゃん。

というのは、一面の真実でしかない。

上のような計算を行うメインフレーム上のCOBOLのプログラムが1980年代に造られて（消費税は無いけれど、代わりに物品税のようなものはあったりする）、案の定、あまりに細かいビジネスルールは要件にも機能にも出ていないとする。というか、出ていない。

それを21世紀になって、Javaで書き直すとする。

30年経過したのだから、ゼロベースで考えるか？ というと、そうはいかない。会計上のビジネスルールには基準としての継続性があるからだ。

そこで、COBOLを……読めない。

COBOLならばまだ良い。PL/Iで書かれていたら？ 当時の流行の4GLで書かれていたら？

会計は長く、プログラミング言語の流行（生存期間）は遥かに短い。会計の長さとためを張れる寿命を持つのは自然言語だ。

今、Javaで記述したシステムが20年後に動いていることをおれは想像できない。

しかし、細粒度のビジネスルールが20年後でも同じことは想像がつく。

そして20年後（希望としてはもっと早いほうがSIビジネスには良いわけだが）システムは更新されるだろう。

そのとき、Javaを解読できる開発者が生き残っているだろうか？ それが問題だ。Javaならだれでも読める？ 20年後のプログラミングパラダイムに慣れきった開発者に解読できるのか？

（粒度の問題ともうひとつある。システム更改というときに、既存のシステムの要件と機能については、基本的におざなりとなることが多いことだ。これは予算と時間の問題だろう。システムを更改する場合、現在を100とすると、40を捨てて、60を残し、80が追加となるということが行われる（100→100なら余程のことがなければ更改は行う意味がない）。40の選別と80の設計に比重がかかり、60は今ある資料が出てきて終わってしまいかねない）

詳細設計書は不要だが、機能の定義よりは1段低レベルな仕様書はやはりあったほうが良い。

まとめると、要件定義はユースケースベースとなるため、アルゴリズムのレベルでの記述を入れる余地がない。

機能定義はアーキテクチャとモジュールの定義が主眼となり、詳細レベルの記述まで落とし込むことは難しい（難しいのは、記述方法が確立していないからとも言えるし、機能定義に、計算順序のような詳細レベルの記述が混ざるとスコープが失われることが問題となる）。

プログラミング言語の寿命は短い。

そのくらいスコープを取って考えないと意味ないよ。