仕様書についての一考察

伝統的に、人工物を新たに生み出すうえでは、要望、要求、要件、仕様、設計、の順番で考えていくとよい、と、言われてきた。

どのドキュメントを書くのも難しい。なにをどこまで書けば良いのか、その判断が難しい。

そのなかで、仕様書を一例に考えてみる。

仕様書とはなにか、辞書的にいえば、その成果物の満たすべき性能を表すためのものである。

ITプロジェクトでときどきやりがちなのが、「コーディング指示書」みたいになってしまったり「UIの詳細な指示書」「機能やアルゴリズムの詳細な指示書」になってしまう、といった話である。

確かに、開発する時点では、それを満たせば、非言語的に、文脈的に要求されている仕様は満たせるのかもしれないから、開発時点では、厳密にいって、それが誤りとは言い切れない。

しかし、明らかに、これは未来の保守、メンテナンスを想定すると、非常にまずい。

本来、仕様というのは、どんなビジネス要件があり、どんかユースケースがあるから、どんな性能を満たすべきなのか、を、書くべきなのだ。

(つまり、その人工物に、どのような状況で、どのように挙動して欲しいか)

先述したような、「人工物の内部構造における詳細指示」は、設計書の方で担うべきものである。

そういうふうにドキュメントが残って初めて、未来のまったく関係ない第三者が見てもわかるものになる。

ウォーターフォールがダメだとか、COBOLがダメだとか言われるが、それは皮相の見解というやつである。

ウォーターフォールの悪しきイメージは「IT部門の対応が遅い」という一点にあったわけだが、その根本的な理由は、ドキュメントの質が低いことにある。

ただまぁ、ドキュメントの質の低さも、時として、直ちに誤りとは言い切れない。その人工物を、将来的に、いつまで、どのように活用していくのかが不明なときは、作れれば良い、ということもあるだろう。開発にかかるコストや時間の圧縮のために、ドキュメントを犠牲にすることを、契約として握られてしまったら、作業実施側として、それに従わざるを得ないかもしれない。

もちろんそれらは、意思決定者側こそが、己の不明を恥じるべき領域である。一方で、作業実施側にそうした見識を持った人がいるのかというと、そう多くないのもまた事実で、まぁ、社会全体がこうした開発プロセスに対して未熟なのである。

それを認識せずに、やれウォーターフォールはダメだとか、アジャイルこそ救世主だとかいうのは、なんの反省もしていない証拠である。

そもそも仕様書とはなにか。その案件において、仕様書はいかに書かれるべきか。

それは、「エンジニアに丸投げ」してよい話では、全くない。むしろ、その開発プロジェクトのビジネス要件に対する究極の応答である。

つまり、その開発成果物が、どのようにして生まれ、誰によって育てられ、支えられ、どのようにして役目を終えるのか、そのライフサイクルを考えてこそ、なにが、どう書かれるべきかが、分かる。