仕様書とは?

From 雑種路線でいこう 情報サービス産業に明日がなくても構わない
http://d.hatena.ne.jp/mkusunok/20070513/spec


仕様書が受託開発に於いて重要なのは,仕様書に基づいた実装を完了することが検収の条件となるからだ.他人のためにつくるから何をつくるかの約束事が必要なのであって,自分のためにつくるとか,自分のつくったものを不特定多数のひとに使ってもらう分には,厳密な仕様書などいらない訳だ.

そして往々にして仕様書の出来が悪いのは,プログラムを書けない奴が仕様書を起こすからである.どうつくるかという想像力に欠けていることもあるし,本当に必要とされていることを精製されていないこともある.プログラマにとって苛立たしいのは,自分よりも馬鹿の書いた仕様書に振り回されて,クールでも本質的でもないことに工数を割くことである.

優秀なエンジニアは面白い仕事を探す.だからプログラムを書けない奴が長々とした会議や仕様書を通じてプログラマに足枷をはめるような職場からは,優秀なエンジニアは段々と逃げ出していくだろう.


もはや大企業に於ける業務のITによる作業の自動化といった領域は概ね開拓され尽くされていて,そこには大きな市場があるし価格破壊による新規参入の余地もあるが,基本的に煮詰まった成熟市場だ.だから,これまで充分にIT投資を行っていない中小企業とか,これまでと全く違った商流をつくるC2C的なサービスの方が面白そうだ.

確かに、「大企業に於ける業務のITによる作業の自動化といった領域」は「基本的に煮詰まった成熟市場」だと思う。
とはいえ、依然としてそこにプログラマの需要があるのは確かな訳で、その中で「クールで本質的なこと」をするためにはどうしたらよいのかを考えてみたい。


上記のエントリによれば、
「大企業に於ける業務のITによる作業の自動化といった領域」においては、
「仕様書に基づいた実装を完了することが検収の条件となる」ために「仕様書」が必要になる。
そして、
「プログラムを書けない奴が仕様書を起こす」ので
「仕様書の出来」が「悪く」
結果として、
プログラマが「クールでも本質的でもないことに工数を割く」ことになる。
ということだ。


では、検収のために「仕様書」が必要なのだとしたら、それは何故か?
まず、検収とは何か?
(http://itpro.nikkeibp.co.jp/a/biz/keyword/key0427/key_07.shtml)


納入品が要求仕様に合っているかの検査のこと。システム開発においては、納品されたシステムの動作を検証し、仕様を満たしているかどうかを判定する作業を指す。
では、「要求仕様」とはなにかというと、乱暴に言うと「欲しい物」ということだと思う。
ということは、「検収のために必要な仕様書」とは「欲しい物が何かを記述した書類」となる。


一方の「出来の悪い仕様書」とは何かというと、
「書いてある通りに実装すると動作しない物が出来る仕様書」ではないか?
なぜそんな仕様書が出来るのかというと、「プログラムを書けない奴が仕様書を起こす」からだろう。


であれば、「プログラムを書けない奴でもかける出来の良い仕様書」というものが存在するのなら、プログラマはもっと「クールで本質的なこと」に注力できるだろう。
「プログラムを書けない奴」の仕様書が何故使えないかというと、仕様書に「How」が記述されているからではないか?
その結果、「非効率なロジック」「想定されている条件の漏れ」等が発生して、「使えない仕様書」が出来上がってしまう。
そして、「Howで記述されている仕様書の通りに実装されているかどうか」は、「ソースコードレビュー」でしか確認できないが、
「プログラムを書けない奴」はソースコードを読めないので、「ソースコードレビュー」ができず、結果として完成したソフトウェアの出来は悪い。


では、「プログラムを書けない奴」は何をすればよいのか?
それは、「仕様書にはWhatを書く」ということではないだろうか。
つまり、「どういうInput」に対して「どのようなOutput」が欲しいのかを漏れなく記述するのである。
この分野については、プログラマよりも「業務に精通しているプログラムを書けない奴」の方が向いているだろう。
そして、プログラマは、提示されたWhatをどのように効率のよいHowに実装していくかということに注力すれば、より「クールで本質的なこと」が出来るようになるのではないか。
また、仕様書の内容がWhatで記述されていれば、テストケースを作って確認することが容易になり、品質も向上するのではないかと思う。