続：設計はUMLだけで済む

オフショア開発

http://d.hatena.ne.jp/atsushifx/20041011#1097511501 より

成功の秘訣はコミュニケーションや詳細化におけるロスやミスをなくすことにあるわけで、

  • 間違いようのない仕様書が書ける
  • 途中で仕様変更がない

なら、オフショアで全く問題がないわけです。

おっしゃる通りなのですが、私があまりに美しく書いているので失敗談も交えておきます(笑)

まず仕様書にも間違いがあります。仕様書間の不整合が一番多いです。仕様書に書いてあるDTOの項目がUMLに無い、仕様書のI/O定義に書いてある項目名が、DBのテーブル定義書と異なる等。不整合と呼ばれるものですね。仕様の抜けはあまり無いように思えます。仕様変更もきっちりと分析・設計されているせいか大きなものはありません。しかも、開発コストがかさむ仕様変更は理由を説明すれば落とし所をゆるくしてくれたり、無かった事にしてもらえます。大きなシステムですからね…。

それで仕様書に間違いがあるのになぜうまく進んでいるか？それは円滑で迅速なコミュニケーションが成功の秘訣です。コミュニケーションについてはたぶん↓あたりに書いてあります。

完璧な仕様書はほぼ無いと言っていいでしょう。ではその間違いによる作業効率の低下をいかに低減させるか。遠隔地の開発者達とそれを行うには円滑で迅速なコミュニケーションを心がけるしか無いでしょう。できるだけ正確な仕様書、開発に適した要員、コミュニケーションを促進させるための仕組み、後はプロジェクトを遂行するために一般的に必要なものがあれば、オフショア開発は失敗しないでしょう。さらりと項目を挙げてますが、ひとつひとつにはたくさんの条件が入っています。例えばプロジェクトに適した要員とは何か。これを定義するだけでも大変なので、ここはあえて曖昧にしておきます。誰かにノックされたらひとつずつ洗い出していこうかな…と少しだけ…すこーしだけ思います(笑)

一つだけ言えるのは、コミュニケーションには相互に通じる「言葉と文字」と「信頼関係」が必要って事です。飲み屋で意気投合したインターナショナルな酔っ払いじゃないんだからボディーランゲージじゃ無理です！！(爆)