仕様探求の旅に出かけよう（２）：仕様の定義について考えよう
仕様の定義について考えたい。
『ソースコードこそが最良の仕様書だ』と言う事を時折聞くことがある。
『最終的に出来上がったプログラムが仕様書である』と言う事なのだろうなあ。
確かに間違えてはいないが、僕が考えている仕様書とはちょっと違う。
仕様と言う言葉には「プログラムの機能」という意味が含まれる事が多く、こういう言われ方をするのだ。
当初の構想と、出来上がったプログラムは違う場合が多い（と言うよりも違っていない場合の方が少ない）。
納品物に『仕様書』が含まれる場合が多いが、作られる過程で出来上がった物ではない場合が多いのだ。
出来上がったあとでただのぶ厚いファイルを渡して終わりと言う事になる事が多い。
最終的にどういうプログラムが出来たかという事をドキュメントにするのは、非常にバカバカしい。
だから多くの場合ツールからの出力（テーブル、フィールドの定義、レイアウトの名前とハードコピーなど）を印刷して終わりにするのだ。
そうして、役に立たない資源の無駄が出来上がる。
僕の定義する「仕様書」はお客さんとの意思疎通の為のドキュメントなのだから「作り始める前に出来上がっていなれば」何の意味もない。
僕の考える仕様の定義は以下の様な物である。
１）お客様との間でのトラブルが起こらないドキュメント
２）分散開発が出来るドキュメント
３）テストを行う時に正解が書かれているドキュメント
この目的を果たすことができるドキュメントを仕様書と呼びたい。
そして、形式は問わない。
１）お客様との間でのトラブルが起こらないドキュメント
お客さんは素人である（無論プロもいるだろうが....）言い換えれば他人であると言った方が良いかもしれない。
人は孤独である。その皮膚の内側から出る事は出来ない。他人の考えを知る事は出来ない。
などと言っていてもしょうがないのである（笑）。つまり、この仕様書はSEがいかにお客さんを『見たか』と言う事を表している。
どんなプログラムが出来るのかというドキュメントである。
僕は多くの場合見積もりの時点で作り、金額と対になっている資料になる。『見積り仕様書』と呼んでいる。
これが育って行って、内部仕様となる。ファンクションポイント法などでは画面数から単純に金額を出して行くが、どちらにしてもどんな画面が存在するかを事前に定義しなければならない。まさにエンジニアの腕が試される。
それもお客さんを見てシステムを「洞察」する力が試されるのである。
このレベルでの具体的なドキュメントと言えば画面（印刷）を表現した物である。
表現と行っているが、『絵』と『意味／目的』と『動き』が表されなければならない。
２）分散開発が出来るドキュメント
これが難しい。
とは言っても、絶対に必要である。
一人で開発する場合でも必要である。なぜかと言うと、このドキュメントを作るためには『一回頭の中でプログラムを作ってみなければならない』からである。
昨今のRADツールは実に簡単に画面を作ることができる（モックモデルと呼ばれる）。
正直、お客さんと雑談程度の話しをしてパッと出来上がるのである。
それも、一人で雑談を思い出しながらドンドコ作ってしまうのだ。多くの場合、それを見せて、文句が無いようだったらそのまま作り始めるのである。
その時に、『これは暫定だから』と言う事が多い。
この言葉の意味は『実際に作ってみると出来ない場合、矛盾の有る場合があるので変わるよ』と言う物である。つまり、十分な検討も行わないで、お客さんが言うままに画面を作っているのである。
お客さんは、暫定だと言う事で、ほとんどまじめに見ない。
そして出来上がって行くとどんどん注文を変えてくる。納品まで終る事のない変更の嵐が続く。
アジャイル型の開発の苦悩である。
確かに。モックは必要である。
しかしながら、それは「絵」で作るべきだと思う。
そして、『決定ですよ』と言うべきなのだ（無論変わってもかまわない）。
お客さんに真剣に見てもらう為である。
モックの制作者が完全に処理の中身まで検討した上で作っていなければならないのだ。
多くの場合、お客さんの話のままにモックを作るので、内部構造的な問題から変えなければならない事も多い。
僕はウオーターフォール型の開発を行うのが好きである。
特に大きなプログラムの場合ほど必要だと思う。
一人でドンドコ「モック」を作るのは良いかもしれないが、それでは分散して開発を行えない。
３）テストを行う時に正解が書かれているドキュメント
テストと言うと、ボタンを押した時に画面が移動するかとか、プリントはちゃんと出るか、検索は思った通りの動きをするかと言う様な事をすると思っている人は多い。
確かにそのレベルのテストは存在する。
しかしながら重要なのは、その画面が、『お客さんの考えている様な物か？』と言う事を考える工程だと思う。
つまり、テストと言うのは『お客さんの要求を満足させているか＝プログラマの理解が正しいか』を別なエンジニアが確認する為の工程である。
その為には、画面、処理の仕様書の中に「目的、意味、目指すもの」が記述されていなければならない。
これが難しいのである。
お客さんの業務の理解があって始めて書ける物だからである。
アジャイル型の開発に恨みはないのです。
アジャイルだからダメという訳ではない事をご理解してね。
まずは動くのを見せないと駄目だと言う場合もあるだろうし、有効な場合も大かと思うのです。
ソフト開発をお客さんとのコミュニケーションの問題と考えた時に、議論すべき問題は「アジャイル」か「ウオーターフォール」の二者択一ではないですから。
192107
