オフショア開発失敗の原因
オフショア開発のテストに投入されてえらい目にあわされたことがあったので、原因を考えてみる。
ちまたでは、やれ品質意識が違うだのなんだのと言われてるが、俺がえらい目に遭ったオフショア開発では、仕様書の作成からオフショア開発させていた。
そりゃデスマーチ化するって。だいたい、どんな品物が欲しいのかを詳細に言わずに、希望にぴったりの品物が得られるわけが無かろう。*1
極端なたとえ話だけど、形状のみが書かれていて、寸法が書かれていない本棚の設計図をもとに、「この図面のとおりに板を切ってくれ」って業者にたのんだらどうなると思う？
国内の業者なら、寸法の書かれていない本棚の設計図に、常識で考えられる範囲の寸法、例えば、文庫本が収まるサイズとかを当てはめて、それなりの寸法で板を切ってくれかもしれない。また、棚いっぱいに本を並べたときに壊れない程度の厚さの板をつかうかもしれない。
海外の業者ならどうだろう？組み立てられる寸法かもしれないが、家で使うには大きすぎる本棚かもしれないし、本を横一列に並べたら棚が壊れるような厚さの板を使うかもしれない。
え？そんなの考えて板を切るのが常識だって？
品質意識がなってない？寸法を問い合わせてくるのが常識だぁ？
あのな、常識なんてものが通用するのは日本国内だけなんだよ！
国内の開発でなんとかなっていたのは、従順で品質意識の高いビジネスパートナーが要件やら、仕様書やら、常識やら、空気やら、いろいろなものの行間を読んで開発していたからに他ならない。
仕様書にはプログラムの仕様が完全には記述されていない。だから、行間を読まないとプログラムが完成しないのだ。その差は現場のプログラマだったり、品質意識の高いビジネスパートナーがサービスで埋めている。
これがオフショア開発となると、仕様書に書かれている事をそれなりに解釈してプログラムが作られる。当然、仕様書の行間なんか読んでくれないので、仕様書とほぼ同等かそれ以下の情報を持った、つまり、動かないプログラムが製造されるというわけだ。
仕様書のメンテナンスが面倒だからといって、記述を曖昧にして紙面を圧縮することは仕様バグにつながる。その圧縮が情報の欠落や劣化を伴うからだ。
国内ではたまたまその欠落した情報の補完がうまくいくが、国外では補完アルゴリズムが違うか、補完のレベルが低いため、それがバグとして顕在化してしまうのではないか。
仕様書の行間を読むのが良いプログラマとか言われてたりするけど、そもそも行間を読ませるような仕様書を書くな。行間があるような仕様書は解釈の違い、認識の違いを生み、それはバグの発生源になる。
もしオフショア開発を成功させたいのなら、テスト仕様書レベルの具体的な仕様書が必要になる。逆に発注時にテスト仕様書が書けなければオフショア開発は失敗する。
「仕様書の行間率の測定方法」というおもしろいモノがあったので紹介しておきたい。
あなたは、自社が作成した仕様書にどれだけ曖昧さが残っているかを認識していますか。
これまで国内開発プロジェクトで通用した仕様書を見直すと、実に多くの曖昧さが残っていることに気づきます。単位規模あたりの曖昧さを仕様書の行間率といいます。●行間率の算出方法（案）
・仕様に関する質問数／ページ数
・口頭説明に要した時間／ページ数
・第三者からの指摘数／ページ数
