わが社のコスト削減

「開発コスト数分の1」という幻想ネットベンチャーでもできるオフショア開発(2/3 ページ)

» 2009年08月19日 08時00分 公開
[今泉大輔,ITmedia]

相手の文化を許容するということ

 以下は、開発が進んでいく過程で起こったさまざまな経験からまとめた委託先とのコミュニケーションに関するポイントである。

1. Web2.0文化の受容の差

 オフショア開発のコミュニケーション面で一番大変なのは、「文化の差」を誰かが埋めなければいけない点だ。すなわち、自分たちでは当然と考え、説明不要だと思っていることが、相手にとっては普通ではないということが多々あるのだ。

 F社は優れた開発会社であり、ISOなどの認証も取ってプロジェクト管理をしっかりやっている。とはいえメインは業務システムの開発。コンシューマー向けのWebサービスの経験はあまりない。

 また、優秀な開発者たちも、公私にわたってWeb2.0系ツールを使いこなすというところにはなく、ブログもSNSも聞いたことはあるが触ることはまずないという環境で生活している。日本で開発を手掛けるわれわれのWebリテラシーと彼らのWebリテラシーにはかなりの差がある。

 従って、pepozにブログ的な機能を組み込んだ時も、「ブログの機能を間引いてこのように……」という説明では伝わらなかった。まずブログそのものの概念を客観的に記述するとともにPowerPointで図示し、電話会議などで機能の要件を補足する。その上でpepozに実装したい機能を伝えた。

 日本のインターネットユーザーであれば常識として分かっていることを、ゼロから英語で記述して伝達するという作業は、非常に手間が掛かる。特に、“カラダ”で覚えているユーザーインタフェースを論理的に解きほぐして仕様として書く作業は、とても難しい。

 ブログ関連機能に限らず、カード決済やWebのデザインなどで、あちらとこちらの文化的な差や生活習慣の差が、膨大なコミュニケーションを必要とするギャップとなって表れる場面が多々あった。これが時間と手間がかかるもっとも大変な作業だった。

2. バグの記述にかかる多大な手間

 システム開発にバグはつきもの。バグ取りをどう効率的に進めるかがコストにも大きくかかわってくる。

 バグは、開発者がまったく想定していなかったシステムの挙動として現れてくる。従って、新しいバグについて第一報を伝えると、「え? そんなはずが!」といった反応が返ってくる。しかし現にそのバグは変な挙動を示している。この段階で双方の認識には大きなギャップがあり、そこを埋めていくコミュニケーションが実は大きな手間になる。

 通常の開発環境であれば、自分が日本人の開発者にバグを再現して見せて、「ここがこういう風におかしい」と伝えれば済む。しかしオフショアの 場合は、何千キロも離れた場所にいる相手に、システムの妙な振る舞いを英語で伝えなければならない。相手に誤解の余地を与えないように客観的にバグを記述 し、場合によってはキャプチャー画面を添えて送らなければならなくなる。それでも不足となれば、Skypeで臨時の電話会議を開く。

 主要な開発フェーズが終わった後にバグが30〜40件発生するということも少なくない。これらを1件ずつ上記のような手間を掛けて相手に伝える。これは長時間労働がまったく苦にならないわたしとはいえ、なかなかしんどかった。一度の伝達で直らないケースもあるので、なかなか気が抜けない。

3. 外部決済サービスの日本語仕様書の翻訳

 pepozでは会員同士で対価のやり取りができるようにしている。最近始めたブログパーツ「メルPEPO」は、ブロガーが500円刻みで謝礼を受け取れるサービスだ。それぞれ外部の決済サービス会社経由でクレジット、プリペイドを使えるようにしている。どちらの会社も日本にあり、日本企業向けのサービスを提供しているので、APIなどを記した仕様書は当然日本語だ。これをそのままF社に渡しても読み解けない。ということで、わたしが英語に直す必要が出てきた。

 C社のリサーチの仕事では、日英・英日いずれの翻訳業務もしばしば発生するので、翻訳そのものに抵抗感はない。だが、期日が迫ってくる中で技術系の文書を日英翻訳するのはかなり骨の折れる作業だ。この種の文書は100ページを超えるのが普通だ。とにもかくにもやるしかなかった。

 オフショア開発では、このように日本語で書かれた技術文書を誰かが翻訳しなければならない場面が生じる。多少のコストと時間を投入すれば現地で対応できるのだが、現実的にはコミュニケーションを担当するブリッジSEの負担になるケースもあると思っていい。

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ