日々の破片

_ なぜなぜ仕様

要件定義−基本設計−詳細設計（または直接実装）というような、段階別のシステム設計を考える。

たとえば、数10年前にこんな要件があったとする。

・プリペイドカードの導入効果を知りたいのでプリペイドカードでの売上合計を簡単に知りたいね

というわけで、プリペイドカードを利用した売上を調べられるようにしたとしよう。

それから幾星霜、システムの更改時期がやって来る。

基本は単純移行＋最新鋭のいろいろ

と決まる。

その時に、現行のプログラムを眺めながら、当時の基本設計も参照しながら、移行プランを練ったり、移行プログラムの仕様を切ったり実装したりすることになる。

そこで誰かが気づく。この「プリペイドカード売上レポート」とか「プリペイド売上計上サブシステム」ってなんだ？

「はて？」

そこで相談することになる。「これ、使ってるのか？」

こういうとき、お客さんと相談するのはあまりうまくない。使っているかどうかに関係なく、あるものは移行しろということになるからだ。そりゃなるよな。

もし使っていないことが明らかなら、あるいは単に惰性で出力だけしているようなら、こちらから提案すべきだろう。

「〜という理由であったわけです。今は〜ですから、この機能は落としましょう」

こういった、どのような理由によってそのモジュールが必要で、どのようなユースケースを満たしているのか、といった情報は、要件定義にはあるはずなのだが、基本設計以降はわりとすっぱり消えてなくなっている。

10数年前のシステムであれば、それはわからなくはない。当事者だし。ユースケースはモジュールの設計には直接関係してこないからだ。というよりも、ユースケースという捉え方をしていなかったのだな。

しかし、経験を積んだおかげで、ユースケースは最初と最後に役に立つことがわかった。

いずれにしても、基本設計であろうが実装設計であろうが、とにかくここ数年のプログラミング言語の進歩というものは、「何をしているか」「いかに処理しているか」というような情報は、ほぼソースファイルで表現しきれているのだ。

つまり、もし、「要件定義」「基本設計」「実装仕様（あるいは実装そのもの」というような段階的な文書を後世のために残すのならば、経験的には、要件定義は残らず、設計と設計成果物しか残らないため、そこにこそ、ユースケース（とその前の段階としての、システムの目的）を記述すべきなのだ。

これは、ソースファイルのコメントにちょっと似ている。何を書くかではなくなぜを書く、というやつだ。とは言え、さすがにソースファイルにユースケースおよびそれの前段階を書くのは、やり過ぎのようには思う。

そこで、基本設計というものに、それを入れるべきだろう。

また、かって基本設計書というものに含まれていたものは、複数から抽出して1つのアーキテクチャ設計書に移動したほうが良い。というのは、そこに非機能要件を入れることで、後世の文書解析の分離がうまくいくからだ。というのは、非機能要件は、システムの進歩にしたがって、個々のプログラム実装からは排除できるようにこれまでなってきたし、今後もなると考えられるからだ。したがって、開発するモジュールを規定していく基本設計とは別にしておきたい。

という感じだが、ほかの同業者はどうやっているのかね？

_ 良いネガティブな書評

ネガティブな評価をする場合は、このくらいかっちりとどういう観点から読むとどのような理由からどういう点を評価できないのかを書いてほしいね。