オフショア開発活用力を拡大せよ! (2)

前回はオフショア開発発注成長曲線を見た。なぜこの曲線のように、オフショア開発発注は踊り場を迎えてしまうのだろうか。それは、発注側担当者一人が動かせるオフショア人材の数(工数)に限界があり、この数を引き上げるような開発プロセス改革がなされていないからだ。どのような改革が必要かを考える前に、ここでは、その限界のメカニズムをウォーターフォール型開発プロセスの視点から見てみよう。

オフショア開発の"ビッグバン"を最小限に

よく知られているように、ウォーターフォール型開発プロセスでは、後工程になるほど一つの修正・変更にかかるコスト(工数)は急激に大きくなる(※)。プロセスの前半はひたすら紙の上で設計しており、動くコードが出てくる後半で様々な問題が一気に露になる傾向がある。言ってみれば助走期間が長くて、最後に一気にモノが出てくるようなものだから、これをソフトウェア開発におけるビッグバン・アプローチと呼んでもいいだろう。だからこそ助走期間におけるチーム間の緊密なコミュニケーションと刷り合わせによる調整が重要だ。プロセスの前半でできるだけエラーの芽を摘み取って、後半の修正・変更を最小限に抑える必要があるからだ。こうしてビッグバンを「そこそこビッグ」な範囲にコントロールしようとする(これが難しいのだが……)。

※Barry Boehmは著書「Software Engineering Economics」の中で、コーディング工程における修正・変更のコストは、開発プロセス最初期の約10倍になるというデータを示している。受け入れテスト時には20～50倍程度になる。古いデータではあるが感覚はつかめるだろう。

オフショア開発でも、発注者はオフショアの受注者との間で刷り合わせをやろうとする。しかし、この刷り合わせで鍵となる「緊密なコミュニケーション」というのがクセ者だ。まずオフショア開発では、国内開発と比べコミュニケーションの密度や質は想像以上に落ちる。言語やコミュニケーションの流儀の違いという文化面の原因もあるし、距離が離れていることからメールによるやり取りに極端に依存してしまうという原因もある。ともかく、刷り合わせをしているつもりでも実際にはほとんど出来ておらず、開発者は納品されたコードを見て初めて見えてくる問題の多さに圧倒されることになる。ビッグバンがあまりに大きな爆発となって襲ってくるのだ。

「下りのビッグバン」と「上りのビッグバン」

それだけではない。下の図はオフショア開発の委託範囲の日米比較調査の結果だが、日本のオフショア開発の場合、基本設計から発注しているケースが極めて少なく、ほとんどが詳細設計から突然オフショアが関与する形になっている(工程の名称は元の資料のまま)。他の調査結果からも、米国では上流工程からオフショアの関与があるのに対し、日本の場合は詳細設計から突然オフショアが関与するという違いがあることが裏付けられている。このことは、オフショア開発には、二度のビッグバンがあることを示している。最初は詳細設計直前に大量の発注仕様を準備する発注者側と、そしてそれを必死に咀嚼するオフショア側を襲う「下りのビッグバン」。そしてもう一つがオフショアからのアウトプットを発注側が一気に受け取って対処する「上りのビッグバン」である。

オフショア開発では、ウォーターフォール型開発プロセスの「ビッグバン効果」がストレートに出やすい。特に短納期の発注の場合、下りのビッグバンで生み出されたカオスを取り払えないまま、上りのビッグバンを迎えることになり、発注者側としても何が出てくるのか(どういう品質か)まったく予測できない危険な取引となりやすい。何も対策を採らない場合、発注者側の担当者一人に対応するオフショア側技術者が10人を超えるあたりからビッグバンはコントロール不能なものになっていく。

今までのオフショア開発では、発注者側の担当者の負荷を増やす、あるいは増員する、またオフショアへの出張を増やしてコントロールしてきたのだが、これだと現場の負担増が著しく、いずれ息切れする。オフショア開発立ち上げ期はこれでも仕方ないとしても、取引規模を拡大する中では、この場当たり的なやり方から、よりスケーラビリティを伴ったプロセスへと移行しなければならない。

下りのビッグバンの抑え込みにはブリッジSEの活用やオフショア側キーパーソンの派遣などによる上流工程へのオフショア企業の巻き込みなどが有効となる。そして上りのビッグバンの軽減のためには、関係者一人ひとりの意識向上、開発プロセスの見直し、といった地道な改善運動の積み重ねの重要性もさることながら、テクノロジーの力を借りながら、大胆な発想で新しい工夫をする必要がある。例えばコミュニケーションインフラを強化してテレビ会議、電話会議を随時できるようにする、UMLなどのモデリング技術を積極導入し、日本語文章に表しきれない設計情報をモデルとして提供する、サーバーを共有して日中双方から随時・同時に成果物のチェック&フィックスを安全にできるようにする、などが考えられる。テクノロジーの力を借りることで、ブラックボックスとなりがちなオフショア側のプロジェクト状況を可視化し、問題点をいち早く共有すれば、問題が大きくなる前に手を打ちやすくなる。納品時に一気にやってくる上りのビッグバンを、オフショア開発プロセス全般にわたり小出しにした複数の「リトルバン」で置き換えるのである。このリトルバンを、全てコストのかかる関係者の出張で起こすのではなく、テクノロジーの力を借りて低コストでしかも臨機応変に起こすようにすることがミソだ。

オフショア開発の効果を経営に反映する30%の壁

オフショア開発は実現可能か。これを問うたのが1990年代である。そしてその答えは"yes"だった。2000年代の現在、そのオフショア開発の規模を拡大してコスト削減効果と人材不足解消を企業の競争力に結びつけることが求められている。

中小企業基盤整備機構が2006年に行った中小企業を対象とした調査によると、オフショア開発を行っている企業に関しては、総外部発注額のうち平均で26.2%がオフショア開発に回されていた。オフショア開発の効果が経営にインパクトを与えるには、この数字が理想的には50%、最低でも30%を超えなければならない。30%の壁を越え、50%に向かうための答えを今後探っていくのがこれからのオフショア開発である。

そのためには、従来の延長線上でのプロセス改善だけでは不十分だ。いままでのやり方に縛られず、大胆に、自由な発想でプロセス改革に臨めばよい。

著者プロフィール

細谷竜一。1995年、Temple University(米国)卒業。1997年、University of Illinois at Urbana-Champaign(米国)コンピュータ科学科修士課程修了し、1998年、東芝入社。東芝ソリューション SI技術開発センターを経て、現在、大連ソフトウェアパークにある某大手ソフトウェア企業で勤務する。学生時代はオブジェクト指向やデザインパターンなどの研究に従事。GoFの一人、Ralph E.Johnson氏の講義を受けた経験も。卒業後も、パターンワーキンググループの幹事を務めるなど、研究活動に積極的に取り組んでいる。