ようやくヴェトナムオフショア開発の体験談の核心に入る。
正直な話、最初のプロジェクトは難局を乗り切って工事は完了したものの、失敗ばかりの連続だった。それを踏まえてその後のプロジェクトでは予めリスクを回避しながら進めることができたと思う。やはり失敗から学ぶことは多いと感じたので、できるだけ率直に書いていこうと思う。
３ 失敗から学ぶ
単価と間接コスト
オフショア開発を検討するにあたって、安価なエンジニア単価というのは大きな魅力である。
現在、国内のエンジニア単価に比較して中国で単価約１／２、ヴェトナムで約１／３という相場になっているが、価格のみに注目すればどうすべきかは考えるまでもない。
コミュニケーションが鍵となるこの開発形態において、コミュニケーションの行き来で取引コストというものが発生する。
この取引コストの存在を考慮に入れなければその見積の工数と実際の工数とは大きな隔たりができてしまうことに注意を向ける必要がある。
情報を正しく伝える
プログラマが書く１行１行のプログラムコードはすべて正確な情報に基づいている必要がある。
少なくとも間違った情報に基づいて書かれたコードは影響の大小を問わずユーザの利益を損なうことになるので、それらは修正されなければならない。ここでいう正しい情報とはもちろん仕様のことだ。
手法がウォーターフォールであろうがアジャイルであろうがそれは同じことであって、この仕様はただ一つの拠り所とならなければならない。
そこで、遠隔地にいて元々文化的背景の違う相手との協業であるオフショア開発では、設計者から作成者に情報を正しく伝えるという負担が指数的に増加する落とし穴がある。場合によってはコストメリットを吹き飛ばして大きな損失をもたらすケースもある。
意図せぬ改竄
かつて私が担当したプロジェクトでは、通常の開発と同じく基本設計書をまず作成しそれから詳細設計書を作成し実装作業に渡すというプロセスをとった。
ひとつ誰もが心配していたクリティカルな問題があった。ある通信プロトコルを実装する必要があったが、そのノウハウは元々私たちの手元になかった。以前から付き合いのあった或るハードウェアベンダの支援を受けて通信プロトコルのインタフェースの設計をこなした。この設計書は旧来からあった設計書のコンテンツを流用しながら作成し、１０００ページ以上の量にのぼる今回のシステム用の設計書とした。
内部レビューを重ねいよいよ設計書の翻訳にまわし、翻訳ができた部分から現地のベンダに送られることになっていた。しばらく経ったが、翻訳を請け負う会社からリリースした設計書の内容に対して何も反応がなかった。正直少しくらいは誤字脱字くらいはあるはずだし何か訊かれるかなと思っていたので、正直意外だった。翻訳は順調なのだと安堵するようにしたが、実は状況は私の想像とは違っていた。
1000ページ以上にもわたる設計書の翻訳はテキパキと進んでいた。この点は問題なかった。
しかし、その内容は意図せずとはいえ改竄されてしまっていたのであった。
というのは、元からあった設計書および新規に作成した部分で用語の統一ができていなかった。
そのため、本来同義である単語が別の単語として翻訳されてしまっていたのだ。
たとえば、仕様書などで多用されるこういった語の例がある。
| 元の語句 | 翻訳された語句 |
| 応答 | Response、Answer |
| 終了 | Quit、Close、End、Terminate |
| 発信 | Send、Transmit |
また、誤訳の類いだが、すべて終了するという意味の文が「Extinct」（絶滅）と訳されていた例もある。
こうなると、まったく読めない文書になってしまう。
これは、突き詰めれば当初日本語版で作成したときの語句の使いまわしの違いに無頓着だったため起こった私たちのミスだった。
語句の曖昧さを回避すべく専門用語、多用するキーワードの用語辞書が必要だったのだ。だが、我々はそのようなことを全く知らない素人だった。
そして地獄のスパイラルへ
やがて私たちは翻訳された設計書をみたエンジニアとのQ&Aで忙殺されるようになった。
設計書原本の修正・リリース->差分設計書の翻訳版への反映->翻訳版のリリースこのサイクルが日常化することになったのだ。
さらには開発現場への設計者の張り付きという事態にまで進行していった。
これは異なる言語を使う人々と仕事をすることによって発生する特有の取引コストであり、この作業は設計メンバー全体に膨大な負担を強いた。
設計のコストだけで捉えればオフショア開発にしたことが却って仇になった例といえる。
これは、すぐ近くにいる国内のベンダとの協業ならまったく考慮しなくていい負担である。設計書の確認・修正にかかるコスト、そして翻訳にかかるコストと時間はプロジェクトを進める上で大きな向かい風として作用した。
基本設計から詳細設計での一見して普通の設計手法にどんな問題が潜んでいたのか、設計書の翻訳が不可避な内容であったのか、そのポイントについては別途考察するが、このように単価だけでは見えてこない間接的な取引コストの増大を未然にどれだけ防ぎ得るかがプロジェクトの成否の重要なポイントになる。
