前回の冒頭で描いたちょっとしたミスコミュニケーションの例を思い出して欲しい。もしかしたら、あの会話は以下のように続くかもしれない。

中国側PL:伝票登録機能はまだ作り込みが終わっていません。それなのになぜこの段階で不具合の原因調査を指示するのですか?
日本側担当:まだ言ってなかったと思うが、実は伝票登録機能を呼び出す別の機能を、日本国内の協力会社が作ることになった。彼らは伝票登録機能ができていないと先に進めないと言っているんだ。
中国側PL:エッー!? そんな話、聞いていませんよ(汗)。ドキュメントも後回しでと指示されたから、その協力会社は伝票登録機能の情報はぜんぜんない状態ですよね? どうやって実装を進めるんですか?
日本側担当:この協力会社からは情報提供や細かなインタフェース変更の要望が出ている。すまんが、前向きに対応してほしい。

「外国はAなのに、なぜ日本はBなんだ」といった議論はあまり好きではないが、それでも日本のソフトウェア開発の取引構造は複雑怪奇だと言わざるを得ない(※)。取引の鎖は非常に長くて、ユーザ企業 → ユーザ企業の情報システム会社 → ベンダー(複数) → ベンダー子会社 → 協力会社(複数) → 協力会社(人材派遣)といった具合だ。これが欧米や中国であれば取引構造はよりフラットで、ユーザ企業 → ベンダー → 協力会社(複数) もしくは、ユーザ企業 → 中堅/中小ソフトウェア企業(複数)という場合も多いだろう。

※このような構造になったことには戦後の産業政策との関連があると筆者は思っているし、過去のある局面ではこのような構造がうまく機能していたのだから、それが悪であると紋切り型に切り捨てるつもりはないが。

複雑な日本のソフトウェア開発取引構造

オフショア企業の担当範囲は明確にすること

このように複雑なソフトウェア開発取引構造の中ではコミュニケーションや取引先との間で分割した作業の刷り合わせのオーバーヘッドは非常に高くなるし、会社間の関係では高度な駆け引きや予測不可能な状況変化への対処が求められるようになる。言ってみれば調整重視型の取引である。中国ソフトウェア企業は、こうした複雑な取引には慣れていないし、これに関して日本企業並みの立ち居振る舞いを期待することはまずもってできないだろう。

何か物事を進めるとき、そのリスクが高ければ事前にできるかぎり不確定要素(リスク要因)を取り除いておくことがプロマネ上の原則である。上記のような取引構造の複雑性を回避する措置を取らずにオフショア側の企業をこの構造に組み込もうとすると、刷り合わせがうまく行かずに開発プロジェクトは停滞してしまう。オフショア開発で日本側現場に発生するいわゆる「オーバーヘッド」の中には、実は複雑な取引構造の中で現場がオフショア企業との板ばさみにあって、ひたすら情報整理と調整に明け暮れる、そのコストも含まれているのだ。

従って、オフショア開発に当たっては、オフショア企業の担当範囲を至極明確にし、その範囲を最後までいじらず、発注者側の現場以外の第三者とオフショア側の間の直接・間接の刷り合わせ作業は極限まで排除することが肝要である。もちろん、これが言うは易しであることは筆者も承知している。が、発注者側の現場が、複雑取引で生じる高波がオフショア側を襲わないようにするための防波堤となることで、結果的にオーバーヘッドコストは減るのだから、それをすることのメリットは大きい。

オフショア先が提供できる価値を見直す

ところで、足掛け7年ほどオフショア開発に関わった筆者の経験からすると、オフショア開発の立ち上がりの過程では三つのことが起こるようである。

   I. 日本にあって、オフショアにもあるもの探し求める。
   II. 日本にあって、オフショアにないものが目に付く。
   III. 日本になくて、オフショアにあるものを見直す。

「中国にもJavaプログラマーがいるのだろうか。我々と同じように、請負開発をやっている会社はあるのだろうか。」こう考えて中国でパートナーを探すのが段階Iである。めでたくパートナーが見つかり、いざオフショア開発を始めてみると、今度は日本側の現場からオフショア開発に対してネガティブな意見が出始める。「なんで中国人はこんな当たり前のことさえできないんだ!」これは段階IIである。

IIで留まっているケースが実に多い。しかし、中国側に、日本でやられるような高度で微妙な刷り合わせを求めることは現実的ではない。その先に進まないことには、オフショア開発の活用は進まないだろう。

最終的には、段階IIIに到達しなければならない。そもそもオフショア開発を始めた目的はなんだっただろうか? それはコスト削減と人材確保だったはずだ。それこそ我々になくて中国(あるいはその他のオフショア先)こそが提供できる価値だ。IIに留まりながらIIIの高みに上ることはできない。オフショアにないものはないものとして進むしかない。そのために開発のやり方のどこを変えればよいか、何を捨てて何を残せばよいか。経営者から現場まで戦略的観点に立った判断が求められている。

著者プロフィール

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