この投稿の筆者は、ネットベンチャーの企業の経営に携わっていたことがあり、インドのオフショア開発の経験があります。様々なことを学びましたが、そのなかでも、教訓と呼べるものをいくつかご紹介します。うまく行ったケースよりも、うまく行かなかったケースを記す方が、オフショア開発の現実をよくわかっていただけると思います。
手間ヒマのかかる開発は日本でもオフショアでも変わりない
手間ヒマのかかる開発とは、途中でどんどん仕様が追加されるタイプの開発を指します。
理想的な開発は、「仕様作成→詳細設計→開発→テスト→完成」という流れで完結するわけですが、現実的な開発は往々にして、「仕様作成→詳細設計→開発→テスト→追加仕様→詳細設計→開発テスト→追加仕様→詳細設計→開発→テスト…」 という具合に、テストをした後で仕様が追加されることがあります。
これは、仕様を書く人と、そのアプリケーションを使うことになるユーザーの立場の違いを考えてみれば当然の話です。仕様書を書く人の頭の中には、完成したアプリケーションのイメージがありますが、それはその時点ではこの世に実在していません。あくまでもアイディアの形で存在しているだけです。そのアイディアを仕様書に落とし込みます。そしてそれが詳細設計に落とし込まれ、開発に回ります（実はここにおいて、注意深く詳細設計を吟味すれば、後々追加仕様が必要になることを避けられる可能性もあります）。
しかし、ユーザーは、そうした仕様を書いた人の頭の中のことなど、まったく考慮しません。単に目の前にある出来上がったアプリケーションを操作して、「ここが使いにくい」、「この機能はこうあるべきだ」という感想を漏らします。両者の間には、ある意味で、深い溝があると言えるでしょう。
どちらの場合でも「割り切り」が肝心
このような、テストをしてみた後で出てきた追加の仕様を、どんどん開発に回していくと、開発費は当然のことながら肥大化します。これは日本で開発していても、オフショアで開発していても同じです。開発のバックログはどんどんたまり、納期は迫ってきて、追加の開発要員投入も必要になり…とやっていくと、開発費は当初の見積もりより3割増し、4割増し…ということになっていくでしょう。
オフショア開発をしたけれども、コスト削減にはさほど効果はなかったというケースでは、オフショア開発の人月単価が安いがために、こうした追加の開発の管理が甘くなり、結果としてコストがかさんだという場合もあります。
オフショア開発をしない場合においても、開発費用をある一定額に収めるためには、仕様を書く側、発注をする側における「仕様の割り切り」が必要になります。納期があり、予算が決まっているなかでは、途中で何らかの機能追加が必要だとわかったとしても、あえてそれには目をつぶる（それが重要な問題に至るものでない限りは）、といった割り切りが肝心です。
逆に、エンドユーザーから見た使い勝手、インターフェースのよさ、欲しい機能の実現など、そうした点を優先するのであれば、予算の増大や納期の延長などが可能な開発体制にしなければなりません。そちらを優先させるのであれば、こちらについては柔軟に対処するという、これもまた、割り切りが必要です。