前回は少々説教臭くなってしまったようだ。しかし筆者に中国企業をことさら擁護する意図はない。実際、オフショア開発では発注者である日本側、それもその現場はかなり血を流している(※)。

※だからといって中国側にも同じくらい血を流せと要求できるわけではないよ、と筆者は言いたいだけだ。

オフショア開発プロジェクトのコスト構造(発注者側)

その流した血が、右図にあるようないわゆる「オーバーヘッドコスト」と呼ばれるものだ。三つの要素がある。

一つは、現場から離れたオフショアでも作業が滞らないよう、仕事を切り出してなおかつ国内よりも詳細に仕様等を記述するといった準備のために増加するコストだ(図では発注用ドキュメント作成)。その次には、この詳細な仕様書を携えて現場の担当者がオフショアへ出張して現地で知識・情報をトランスファーするためのコストが発生する(同出張費用)。そして、オフショア側での開発作業が立ち上がるにつれて、仕様書等に関する質問が山のように寄せられ、いちいちそれに対して発注側が答えを文書で準備するなどのコストが増大する(同Q&A対応等)。こうしたコストは日本国内の発注でも発生しうるものだが、オフショア開発の場合は特に大きくなりやすい。図で、「オーバーヘッドコスト」として囲ってある部分が、国内発注の場合と比べて増加する一種の取引コストを表している。

コスト削減と現場の負荷軽減は両立するか

欧米流のアウトソーシングには、業務活動を外部化することで自社のリソースを削減する意味合いが強い。だから、アウトソーシングの決断が下ると「おまえの部門の仕事は来年からインドに移すから、マニュアルをまとめ終えたら転職してくれ」などという話になる。それに対し、日本のいわゆる「外注」は自社の人減らしではない。むしろ、正社員では不足するマンパワーや能力を外部の会社から買うことで補充する意味合いがある。外注をやるからには発注側の現場の助けにならなければ意味がないと考えられる。

オフショア開発を外注の一種だと考えると、痛い目に合う。何せオフショアに仕事を出すだけでただでさえ負荷の高い現場がさらに輪をかけて忙しくなってしまう。「こんなはずじゃなかった」と思ってももう遅い。

さて、それでもなんとかオフショア開発をやり遂げて、コスト削減効果を計ったとしよう。その見込みと実際を表したのが下図で表した総務省による調査結果だ。

オフショア開発のコスト削減効果(総務省「平成19年情報通信白書」を元に作成)

この調査に基づくと場合、見込んだほどではないものの過半数のケースで20%～40%の削減効果を実現していることがわかる。程度の差はあれど、オフショア開発に回した案件についてはハードなコスト削減効果は得られるということだ。

しかし、別の角度から見ていくと、現場にかかるオーバーヘッドコストがもたらす問題点が浮かび上がる。それは第3、4回「オフショア開発活用力を拡大せよ!(1)(2)」で取り上げたオフショア開発発注規模を拡大するスケーラビリティの問題である。この中で実際にオフショア開発を行っている中小ソフトウェア企業では、総外部発注額の26.2%がオフショア開発の費用であることを明らかにした(※)。今後、これをどれだけ引き上げられるかが問題になるが、そう簡単な話ではない。現場にかかるオーバーヘッドを軽減しない限り、現場が新たなオフショア開発を回す余力はすぐに枯渇するからだ。このオーバーヘッドにメスを入れない限り、一つの開発部門におけるオフショア開発の総発注量拡大は2、3年でサチる(頭打ちになる)。

※独立行政法人中小企業基盤整備機構「オフショア開発の潮流と業界構造の変化～グローバル化における中小ソフトウェア開発企業の動向～」

では、このオーバーヘッドコストをいかにカットすべきか。統一的な処方箋はないし、逆に言えばそこがオフショア開発を軸としたソフトウェア開発能力競争の差別化要素になる。以下いくつかのアイデアを紹介する。

• ドキュメント作成過程を合理化する

  • これは仕様のコントロールとセットでやると効果的。仕様の変わりにくい部分と変わりやすい部分をきちんと区別し、前者は詳細に書くが後者はあえてアバウトにしておく。仕様書をメンテナンスしたり、内容を追うこと自体がオーバーヘッドになっている場合、発想を転換して、仕様書はあまり書かずにオフショア側に積極的にどう作るかを提案させたり、プロトタイピングをさせたりして刷り合わせる方式にするのもいいだろう。

• 出張をだんだんと減らしていく

  • フェース・ツー・フェースの会議を電話会議で代替する
  • ブリッジSE(日本とオフショアとの橋渡しをするSE)を活用する
  • 一部の作業をオンサイト化し、オフショアから来た技術者に現場の中で作業してもらう(トータルで見てそのほうがコスト安ならそれでよい)

• 通信技術を活用する

  • IP電話や類似の技術を使い、担当者レベルで低コストでいつでも日本-オフショア間の電話がかけられるようにする
    • ただし言語能力の問題で会話がスムーズに行かない場合、日本側に通訳その他オフショア側が気軽に話せる相手を置いておく。
  • 開発サーバーを日本とオフショアの間で共有し、成果物の状態をいつでも双方から確認できるようにする(セキュリティなどの問題からある程度の取引量に達したら専用線を引いたほうがいいだろう)。

• (UMLなどの)モデリング技術を活用する

  • 文章だけで仕様を伝えようとすると、エンティティとエンティティの間の関係などのディテールがうまく伝えられない。UMLなどのモデリング技術を使い、形式的な表現によってこのディテールを補うと、オフショアからの質問を減らしたり、誤解の余地を減らしたりできる。

• ソースコード・インスペクション・ツールを使う

  • ソースコードに隠された(コンパイラが拾えない)コーディングミスや、コーディング規約の逸脱などの多くの低レベルの問題は、ソースコード・インスペクション・ツールを使って検出できる。これによって低レベルのソースコードレビューや修正の時間を節約でき、また、コーディングミスと設計ミスの切り分けがしやすくなる。

以上は全体的に現場の負荷の総量を減らすとともに、まとめてやってくる負荷を小出しにして分散する作用を持ち、効果的だ。ただし、こうした措置も関係者がその意義を理解し、目的意識を持って運用しないと効果を失うどころか、かえって混乱をもたらすだけであることは言うまでもない。中国の場合は、正直に言って何かにつけて物事の運用面が弱く(その結果場当たり的な対応をしがち)、せっかくのインフラや制度、システムが活かされないことが多々あると思う。日本側は「いかに運用すべきか」については大先輩だから、このノウハウと意識はぜひ相手に伝えてほしい。

著者プロフィール

細谷竜一。1995年、Temple University(米国)卒業。1997年、University of Illinois at Urbana-Champaign(米国)コンピュータ科学科修士課程修了。1998年～2007年総合電機メーカーを経て大連ソフトウェアパークにある某大手ソフトウェア企業で3年間勤務。2008年からユーザ企業系IT会社の社員として上海のオフショア開発拠点に赴任。学生時代はオブジェクト指向やデザインパターンなどの研究に従事。GoFの一人、Ralph E.Johnson氏の講義を受けた経験も。卒業後も、パターンワーキンググループの幹事を務めるなど、研究活動に積極的に取り組んでいる。