オフショア開発の教訓1 – 大切な「割り切り」

この投稿の筆者は、実は、ネットベンチャーの企業の経営に携わっていたことがあり、インドのオフショア開発の経験があります。様々なことを学びましたが、そのなかでも、教訓と呼べるものをいくつか記してみましょう。うまく行ったケースよりも、うまく行かなかったケースを記す方が、オフショア開発の実際をよくわかっていただけると思います。

日本で手間ヒマのかかる開発はオフショアでも手間ヒマがかかる

手間ヒマのかかる開発とは、途中でどんどん仕様が追加になるタイプの開発を指します。

理想的な開発は、「仕様作成→詳細設計→開発→テスト→完成」という流れで完結するわけですが、現実的な開発は往々にして、「仕様作成→詳細設計→開発→テスト→追加仕様→詳細設計→開発テスト→追加仕様→詳細設計→開発→テスト…」 という具合に、テストをした後で追加の仕様が加わることがあります。

これは、仕様を書く人と、そのアプリケーションを使うことになるユーザーの立場の違いを考えてみれば当然の話です。仕様書を書く人の頭の中には、完成したアプリケーションのイメージがありますが、それはこの世には実在していません。あくまでもアイディアの形で存在しているだけです。それを仕様書に落とし込みます。そしてそれが詳細設計に落とし込まれ、開発に回ります(実はここにおいて、注意深く詳細設計を吟味すれば、後々追加仕様が必要になることを避けられる可能性もあります)。

しかし、ユーザーは、そうした仕様を書いた人の頭の中のことなど、まったく考慮しません。単に目の前にあるできあがったアプリケーションを操作して、「ここが使いにくい」、「この機能はこうあるべきだ」という感想を漏らします。両者の間には、ある意味で、深い溝があると言えるでしょう。

いずれの場合も「割り切り」が肝要

このような、テストをして初めてわかる追加の仕様を、どんどん開発に回していくと、開発費は当然のことながら肥大化します。これは日本で開発していても、オフショアで開発していても同じです。開発のバックログはどんどんたまり、納期は迫ってきて、追加の開発要員投入も必要になる場合もあり…とやっていくと、開発費は当初見積の3割増し、4割増しということになっていくでしょう。

オフショア開発をしたけれども、さほどコスト削減の効果はなかったというケースでは、オフショア開発の人月単価が安いがために、こうした追加の開発の管理が甘くなり、結果としてコストがかさんだというケースもありそうです。

たとえオフショア開発をしない場合においても、開発費用をある一定の枠内に収めるためには、仕様を書く側、発注をする側における「仕様の割り切り」が必要になります。納期があり、予算が決まっているなかでは、途中で何らかの機能追加が必要だとわかったとしても、あえてそれには目をつぶる(それがクリティカルな問題に至るものでない限りは)。そのような割り切りが肝心です。

逆に、エンドユーザーから見た使い勝手、インターフェースのよさ、欲しい機能の実現など、そうした点を優先するのであれば、予算の増大や納期の延長などもOKという開発体制にしなければなりません。そちらを優先させるのであれば、こちらについては柔軟に対処するという、これもまた、割り切りが必要です。

For inquiries, Please Call or Email