オフショア開発をしていると、仕様書の正確性について考えさせられる。
日本人技術者は仕様書に対して甘く考えていると感じることが多い。
仕様書は少なければ少ない方が良い
かつ
正確でなければ意味が無い
複数の仕様書間の整合性が開発中に保てない
日本のWebシステム開発(私の関わっている開発)では、チーム内で頻繁に会話しながら仕様書を行き当たりばったりで中途半端に更新していくようなスタイルが多い。
その結果、仕様書間での整合性を保ったまま開発が進められることはほとんど無い。
「あぁ、その件に関してはこの仕様書に記載されている事が最新です」
みたいな事が頻繁に発生する。
開発中に、複数の仕様書を見るとそれぞれ矛盾したことが書いてあり、仕様書を読んだだけではどの仕様が正しい仕様なのか判断出来ないケースが多い。
なぜなら、各担当者が口頭もしくは会議で決定したことを、よしなに仕様書に更新しているだけなので、常に修正漏れや考慮漏れが存在し続けるのだと思う。
日本人技術者は、無意識的に「察し合う」ことにより仕様書に記載されていることが間違っていても、察して「その場で周りの人に聞く」事により仕様書が矛盾していてもだんだんと整合性が取れていくのである。
また、「直接的な表現で他人の非(ここでは仕様書の更新漏れなど)を指摘する」ことを避けるような雰囲気もある気がする。
「最終的に矛盾の無い正しいシステムが出来るなら何でも良いのでは？」
という人もいるかも知れない。
でも、それはオフショア開発には向かない。
ソースコードのコンパイルエラーは許せないけど、仕様書間の矛盾はなんで許せるのか。冷静に考えたほうが良いと思う。
仕様書の数が無駄に増えていく
また、開発が大規模になり、関係者が増えるに従い仕様書がどんどん増えていく傾向がある。しかも、無駄に増える。
無駄に中途半端な成果物が増えた結果、ますます仕様書間の整合性を保つのは難しくなる。
大規模になりマネージメント層にマネージメント専門の担当者がアサインされ、マネージメントする為にあらかじめタスクを整理し、その結果意味のない成果物が量産されていく事がよくある。
タスクを整理するのが良くない訳ではない。
タスクを実際にアサインされた技術者には、タスクが定義された経緯や背景がキチンと説明されない事が多い。
もしくは、タスクを実施する段階では、まだ未確定要素が多く、具体的には定義出来ないケースも多い。
その結果、担当者はアサインされたタスクをこなすために、意味がなくても成果物を作成し始めるのである。いや、意味があるかないかなんて、考えないのかもしれない。今できること、今決まっていることだけをベースに仕様書を作成し始める。
その結果、同じような事が複数の仕様書に記載されているような事が発生する。
ひどいものになると、結局誰が見るのかも分からない中途半端な仕様書が置かれていたりする。
「仕様書を作るのが仕事ではない、システムを作り上げるのが仕事である」
「誰も見ない仕様書なんて無いほうがまし、逆に邪魔になる」
ということをもっと考えたほうが良いと思う。
ひとりごと
「仕様書は少なければ少ないほうが良い」
かつ
「正確でなければ意味が無い」
