ときどきブログ

ヴェトナムオフショア開発のツボ（７）

３．失敗に学ぶ

チームプレー

難しい距離感

プロジェクトチームの管理はプロジェクトの状況により様々だと思うが、いくつかのヴェトナム・オフショア開発プロジェクトで共通の経験としてはヴェトナム人のチームは個人プ レーの集合体といった傾向が強いように思う。普段の関わりとしては互いに緊密な関係を保っているが、皆それぞれが自分の仕事のスタイルを持っていて隣人の様子 にはあまり干渉しないというようなクールな側面もある。

こうしたチームを現場で管理する時、ヴェトナム人のマネージャは管理と放任の両刀を使い分けながらチームのパフォーマンスを向上させることに苦心しているようだ。その管理術も我々が知るものとは以って異なるものにみえる。日本人のビジネス感覚でいうと互いの精神的距離はかなり近いが、絶妙の 距離感を保ちながら上下関係はちゃんとしている。それゆえ一見個人プレーの集まりに見えて命令系統は意外に迅速かつ的確と組織的にしっかりしたところもある。

時折仕事中にテラスなどで彼らがのんびり談笑しているときがあり、一瞬「おいおい、みんなしてサボってるのか？」と思った。しかし基本的に彼らが何を言ってるのかわからないので、しばし静観することにした。しばらくすると、中の一人がささっと席を立ってどこからかホワイトボードを持ってくる。そこから激しい技術論戦に突入した。いつの間にか全員が立ち上がってホワイトボードを囲んでワァワァと議論しているのだ。どうやら最初から談笑しているように見えて彼らはまじめに仕事のことを話していたらしいのだ。このあたりはどうも我々には読みにくいところだが、現場ならではの雰囲気として経験していくしかない例といえる。

たとえばドイツのオーケストラとフランスのオーケストラが同じ曲でも異なる響きのアンサンブルを奏でるように、ソフトウェアプロジェクトにも国民性とか、民族気質とかそういうものが反映されて然るべきである。

自分の国のやり方にあわないことがあったとしても当然なので、それに戸惑ったりすることはあっても基本的にはそういうものだ、とまず受け入れてみることが大事だ。

オフショア開発を始めていきなりプロジェクト管理は外国人には重荷になりがちなので、ヴェトナム人のプロジェクトリーダの管理の仕方を観察するのもいいかもしれない。

 

あるリーダーの失敗

とあるオフショア開発プロジェクトで現場のリーダーを努めていたヴェトナム人のDさんは、とても真面目な人で、可能性が彼なりに100%でなければ決して「はい」といわないような律儀な人物であった。

彼は毎週進捗の状況をプリントアウトして持ってくる。そして、何が起きていて、何がネックになるかなど的確に説明をしていく。慎重で正確で推測を嫌う、非常に日本の会社員的な人物像であり、逆にヴェトナム人らしくないという評判も耳にすることがあった。

しかし、ある時から彼は報告にやってこなくなってしまった。きくと頭痛がするのだという、翌週も欠席、理由は頭痛だった。どうやら毎週報告に来る頃になると頭痛に見舞われてしまうらしく、プロジェクト内で何かが起きていると思わざるを得なかった。

メンバーと直接話をすると、驚いたことに実際は我々が知っているそのリーダーの人物像とは違った人物であった。彼はプロジェクト管理においては独裁的な方法をとっており「一切口答えは許さん」的な態度を貫いていたようなのだ。いったん渡したスケジュールはとにかく守れと。

ところが、絶対的なリーダーと従属的なメンバーという一定の距離をとることが難しくなってくる事情が発生した。我々発注元の人間が近くにいて毎週状況を報告しろというので、律儀な彼はメンバーに直接状況をきいて回ることになったからである。普段の彼に態度に対して多くのメンバーはネガティブな反応で迎えることが多く、進捗の状況をヒヤリングするのはやがて困難な作業になってしまった。毎週、毎週の繰り返しにとうとう参ってしまったというのが真相のようであった。

そうしたプロジェクト内での立場の変化を経験してか、このDさんは後には幾分か態度は軟化したようだったが一度できた評判はなかなか変わらない。その会社のメンバー達の活発な交流の輪から常に彼は外側にいて、表情のない目に時折人懐こさを垣間見せることがあっても決してスタンスを変えることはなかった。後日プロジェクトが終わって１年くらいした頃、彼は別の会社に移って行ってしまった。

このDさんの失速とともにプロジェクト内ではリーダーはリーダーで、俺達は俺達だ　という雰囲気が起こって、プロジェクトがバラバラになってしまうんじゃないかと懸念された。しかし、結局は悪い事態にはならずなんとか乗り切ることができた。うれしい誤算はメンバーの中から別に技術、ヒューマンな面をサポートするキーマンがそれぞれ現れたことである。彼らは自分達もポジションとしては同じメンバーなので気持ちの面では多くを共有できており、また皆でよく話もしていた。彼らを中心にまとまるべきところはまとまる機能的なチームに変わっていった。その頃から私もメンバーと一緒に食事に出かけたりする機会が増え各メンバーとの距離が縮まったように思う。これも彼らの計算であったかもしれない。

ともかくヴェトナム人のチームでの人と人の距離感というのは重要なポイントであるように思う。これを読み間違えれば互いの気質をよく知る仲のはずのヴェトナム人同士でもうまくいかないということだ。

 

若い業界のダイナミズム

ヴェトナム人の人口構成を見ると、若い世代が圧倒的に多く、これは日本の1960年代高度成長期と非常によく似ている。この中でも国が力を入れて推進してきたIT技術養成の産業としての受け皿であるソフトウェア企業は平均年齢が低いといえると思う。この中にリーダーとしての資質と経験を持った人材がどれだけいるかを考えると、まだまだ割合的には少ない。大きな企業では一人のリーダーが数十人のチームを管理したりする状況を目の当りにすると、毎年多くの参入者が増えて裾野が広がるこの産業に中堅以上のスキルを持ったリーダーが潤沢に育つ環境が醸成されるにはいましばらく時間がかかるだろうという思いはぬぐえない。

しかし、業界自体が若いことを逆に武器にしているヴェトナムのIT産業であるともいえるわけなので、この点をデメリットとして切り捨てるのはどうにも惜しい。間違った方向へ進んでも強引に舵を切り直してしまうダイナミズムも十分にある。マネジメントのリスクを気にするあまり動きが鈍くなるよりは、多少の失敗はしてもアクティブに動いていく方が正解だ。

オフショア開発を推進する立場の人には多少の失敗を恐れずぜひともいろんな挑戦をしてみることをお勧めしたい。

ヴェトナムオフショア開発のツボ（６）

３ 失敗から学ぶ（３）

「まだできてない。」　．．．期日までに「できる」といったのに．．．どうして？という局面を何度も経験している。どうしてそういうことになったのか、我々はどうすればよいか　その辺りについて書いてみよう。

 

「できる」の意味するところ

不可解な返事

オフショア開発プロジェクトを開始して定例、あるいは必要に応じ何度も請負先のチームリーダとミーティングをするようになった。ヴェトナムのエンジニアはミーティングを頻繁に行うのは問題なさそうだが、長くなるのは極めて苦手のように見える。進捗を確認するミーティングでは、このコンポーネントはいま達成率はどれくらいか？とか期日までに間に合うか？という質問に彼らは決まって「できる」と答える。その表情に動揺を認めないのでとりあえずは信用する。
ところが、実際にはこの「できる」には何度となく裏切られた。期日になると、あっさり「できていない」と言ってくるのだ。「どうして？『できる』といったでしょう？」というと、「『できる』と言ったができなかった。」と返ってくる。しかもこの間逼迫した状況を改善すべく残業などしたかというと、そういうこともない。毎日夕方になれば皆帰ってしまうし、それで期日を守れないという状況とは？考えるだけで私は頭がクラクラした。

２つの壁

この状況を理解する上で、２つの壁があると考える。一つは言葉の意味の問題。「できる」という言葉は物事を確約するまでの意味は込められていない。では、何が「できる」のか？「可能である」あるいは「可能性はある」ということだ。英語の「can」と「able to」の違いにも例えられようか。（「we can do that」といわれると、「やろうと思えばできるかもしれない（が、できるかどうかは別問題）」というニュアンス。「we are able to do that」なら、「大丈夫。スケジュールも守れる。」というところ。）
つまり可能か否かというレベルの認識であって、我々が通常認識する日本語の助動詞「できる」の意味する範囲の一部をカバーするに過ぎないというわけだ。

もう一つの違い。それは一種の彼等流サービス精神のようなもので、国民性にも深くコミットする点だと私は思う。彼らの口から第一声の拒否拒絶は滅多にきかれない。つまり、相手を失望させない返事をすることが彼らにとっては礼儀・美徳なのである。それはいざとなった時に大きな失望になるのではないかと私達は勘ぐりをしてしまうが、彼らは彼らでうまくやっているようではある。それを一種の嘘・ごまかしのように感じてしまうのは人に失望させるかどうかより正直にあれといわれてきた我々の美徳がそのように出来ていない、その違いによる。だからこういうことがいきなり目の前で起きたとき、我々は肩透かしをくらったような、騙されたような衝撃を味わうことになる。オフショア開発に携わった多くの方が同様の体験をお持ちだと思う。

言語の違い、国民性．．．、だからといってハイそうですかと毎回ビハインドに倒れてくる進捗を静観するわけにもいかない。これはビジネスなのだ。そこでなんとかしてスピードアップするように求める。しかし、労働時間は相変わらずで特に変わりはない。そしてリーダが話があるといってやって来る。そして、こう言う。「スケジュールが厳しいので、増員した。」こうして状況が厳しくなるたびにプロジェクトは肥大した。すべてのプロジェクトがそうであるというわけではないが、私が開発の現場にいたその時はそういう傾向が当たり前のようにあった。

仕事に対するスタンスの違い

日本もかつてそうだったように、ヴェトナムという国は今なお儒教の強い影響下にある。目上の人を敬い家族の絆を第一に考える。また、これは長い歴史の中で醸成されたもので、村という小さなコミュニティが彼らの社会の基本構成として機能しており、個人の存在は独立した個人というよりは家族という最小単位の一部としての意味あいが大きい。かつての対仏・対米戦争の時代、ホーチミンの軍はこの村をうまく利用してゲリラ戦をしぶとく戦い抜いた。映画「天と地」ではこうした戦乱に揺れる村社会での生き方が描写されているが、経済社会が発展し都会に住むようになった人たちにも基本的に受け継がれている。若い世代ではそういった傾向は薄くなってきているとはいえ、われわれと比較すると彼らは家族と過ごす時間を非常に大切にする。仕事はあくまで仕事、時間になれば切り上げて家族と過ごすために帰宅する、それは仕事をおろそかにしているわけではなく、彼らの生き方の一部分である。

納期が近いから、バグが解決しないから、といって日本のSEやプログラマのように家庭を投げ打ってでも長時間の残業をすることの是非を説いても基本的に通じない。もし、しぶしぶでも同意して遅くまで作業をしてくれるという場合は、それは彼らにとってよほどの譲歩であり、しかも一時的なものだと考える方が間違いない。それが常態には決してならないことを認識しよう。

スケジューリングする

中国と同じで旧正月（テト）にかかるプロジェクトはこの時期に１週間程度は不労の期間が入ることを想定しなくてはいけない。もし納期が迫っているとしても、この時期に無理に仕事させるのは非常に厳しい状況を生みやすい。先に述べた仕事に対するスタンスとも共通するが、旧正月もヴェトナム人は非常に大事にするので、ここは極力アンタッチャブルな時期とするべきだ。また旧正月は大体１月終わりから２月上旬くらいだが毎年日は異なるので、該当の年はいつか、事前に調べておく必要がある。

また、非常に初歩的な話になるが、場合によりスケジュール作成のときに互いの規模感を出し合い調整する局面があるかもしれない。このときの規模感の基準が違うということも十分にありえる。わたしが経験した最初のプロジェクトではプログラムの行数＝ステップ数とはカウントしなかった。ステップ数とはおそらく実行行数だけを数えるとか空の実行行はどうなるのかという問題だったと思うが、実は詳細は今でもよくわからないままだ。ともかく実行行数によるLOC（Lines of Code）で規模の基準を統一した。実に単純な話ではあるが、こうしたことも相互理解を邪魔する要因になるので、早期に確認するにこしたことはない。

プロジェクトのスケジュールを検討する時には、このような状況に留意する。残業時間や旧正月の間の出勤を考慮に入れた工数の割り当てなどは基本的にし てはいけないことは改めていうまでもない。プロジェクトによってはざっくりとした工程・工期のみをまず決めて走り出すことも多いと思う。しかしアバウトに引かれた長い工期の線表ではいつの間にか予定が現実と乖離してしまいリカバリ策を打つ契機を見逃しやすい。なるべく短期間のタスクに分けるなど目標と達成度 をこまめに確認できて本人たちがスケジュールを身近に意識できるような工夫が必要だ。

ヴェトナムオフショア開発のツボ（５）

３ 失敗から学ぶ（２）

論理の共有

オフショア開発の現場に限らないが、システムの仕事は論理的思考を常に相棒にしていなければならない。
私も含めてだけれども、状況によって、あるいはしばしば論理的な思考ができなくなる傾向があるという場合は注意が必要である。もしもシステムを構成するピースの１つまたは幾つかが論理的思考から外れてしまえば、それはシステムの中にがん細胞が巣食ってしまうのと同じだ。それが致命的であるかどうかはまた別の問題で、ともかく進んでがん細胞を抱え込むようなことは避けるべきだ。

妥協するか、しないか

システムの論理設計でよくあることだが、とあるコンポーネント内にとある論理的なチャネルが複数必要だとする。通常は１つしか必要でないが、これを仮に４つ定義するとする。余っている３つは一見無駄に見えるが、設計上さまざまな理由で論理的キャパシティを保証するためにそうすることがある。
しかし経緯を知らない人には出来上がった設計の内容だけを見ても、なぜそうなっているのかわからない。
前にも書いたとおり、ヴェトナムへのオフショア開発プロジェクトが始まり設計書を翻訳して現地に送ったまではよかったが、設計の質の低さがブレーキとなり設計をしていた我々も請負先の現地企業もクリンチになってしまった。そうして開発が始まった後、設計者である私は現地のベンダにスペースをもらってほぼ常駐していた。
ある時、疑問をもったプログラマが私のところへ来た。そのエンジニアが翻訳された設計書のコピーを手に質問する。
「通常１つしか使われないこのチャネルをなぜ４つ確保して空けておく必要があるのか？」
論理的な上限があって、それをシステムが保証しなければいけないということを時間をかけて説明する。こういう場合は通訳を間にいれる。
しかし、どうにも彼の納得する答えには到達できなかった。
疲れ果ててしまった私は、そのチャネルは今のところ実際には１つしか使われないので４つでも１つでも同じなのだと言った。
通訳がその内容を伝えると、それを聞いてようやくエンジニアは納得して戻っていった。
さて、結果はどうなったか？

もちろん、４つあるはずの論理的なチャネルは１つになった。少なくとも実装上はそうなった。まさにがん細胞の移植である。
コードレビューをしていて気づいたが後の祭りである。これは違うじゃないかといっても、「１つでも同じだと言いましたね」とそのエンジニアは頑として引き下がらない。
結局ゴリ押ししても設計どおりに修正させることはできなかった。私の負けである。意図しないこととはいえ、相手は譲歩を勝ち取り私はあってはならない妥協をしたことになる。言葉の通じない相手であるからこそ、なおさら論理の土俵上でコミュニケーションを成立させる必要があるし、論理的思考を休ませてはいけない。

まずいとわかっていても頑固に固執しようといっているわけではない。論理的に破綻していると気付いたら、固執せずに潔くよりよい方向に舵を切る勇気も必要だ。

でも、美学的に論理を追求するあまり設計コンセプトや意見などコロコロと変えるようなことも慎みたい。信頼を失いそっぽを向かれてしまうようなことになると、うまくいくものもうまくいかなくなる。この点は注意が必要だ。

後日談になるけれど、このときの”がん細胞”は製品完成後約２年経ってからエンハンス作業の中で私自身が除去した。機能的にその修正が必要になるまで誰も触ることができなかったからである。

理由の如何に関わらず妥協をすればツケは必ず返ってくる。

小石に躓くリスク

上記の話のような、設計したのが自分自身であり内容がよくわかっていながら妥協してしまう上記のような場合は例としては少ないかもしれない。一般的にはブリッジなどで関わったときにまったくの他人の設計した内容について思い込みで判断を誤ったりすることの方がむしろ多いと思う。

人の書いたドキュメントというのはその人なりの思考が反映されており、そこで展開されている論理は基本的に別世界だ。そこを丹念に読み解いていく努力がまず必要だ。そして努力して読み進めていくうち運悪く何かで躓いてしまうと先に進めないことがある。路上に置かれた巨石のようにどうしても先に進めなければ立ち止まることも容易にできる。疑問点をクリアにして先に進むこともできるわけだが、一見立ち止まるほどでない、路上の小石レベルの問題が実はクリティカルな問題だったりすることもある。見逃しやすい分こちらの方が脅威だ。

これを見通すにはかなりの熟練が必要だと思うが、オフショア開発で仕様の取りまとめをする立場になる人やブリッジSEには必要な能力である反面、大抵は経験的に身につくものなので、どうしても時間がかかる。設計者、製造者と直接のコミュニケーションを取るなどして極力こうした齟齬を埋めるべく努力するしかない。

これは人から聞いた話。

あるプロジェクトでオフショア開発先に設計書が送られてきた。

その設計書の中にある外部コンポーネントらしきものが書かれてあり、しかもその説明がどこにもない。しかし至るところでデータを送りつけ、データを刈り取り、処理結果を評価する記述があった。この設計を見たベンダ側のエンジニアは困惑し、そのコンポーネントはどういうものか、インターフェースは何か、概要の資料でもないかとさっそく設計者に確認した。しかしどういうわけか設計者は「説明できないし、その部分に関しての資料はない」の一点張り。離れたところで交わされるコミュニケーションがうまくいかず確認は難航した。

状況が芳しくないため、仕方なく設計者は現地に飛んだ。そして待ち構えていたエンジニアがこのコンポーネントは何だと直接設計者に問い詰めた。

なんと正体はコンポーネントではなくオペレータ（ユーザ）のことだった。

こういう悲喜劇がいとも簡単に起こるのがこの開発形態の特色だ。

「何かを伝える」ということを再認識する

 このようなトラブルは設計手法やツールによって大きく緩和される可能性はある。しかし最も重要なのは何のためにコミュニケーションをするかということをもう一度確認することだ。開発プロジェクトで成果物として作成されるものは対象の多寡に関わらず読まれることを想定する限り、全て人に「何かを伝える」という目的を持っている。残念なことにそれがうまく伝わらないという事自体、当事者のどちらか一方が責任を負うものではないと認識し、常にどうすればコミュニケーションをより円滑にするかを工夫する姿勢がまず必要だ。設計手法やツールといった具体化の手段を考えるのはその後だろう。

ヴェトナムオフショア開発のツボ（４）

ようやくヴェトナムオフショア開発の体験談の核心に入る。

正直な話、最初のプロジェクトは難局を乗り切って工事は完了したものの、失敗ばかりの連続だった。それを踏まえてその後のプロジェクトでは予めリスクを回避しながら進めることができたと思う。やはり失敗から学ぶことは多いと感じたので、できるだけ率直に書いていこうと思う。

 

３ 失敗から学ぶ

単価と間接コスト

オフショア開発を検討するにあたって、安価なエンジニア単価というのは大きな魅力である。
現在、国内のエンジニア単価に比較して中国で単価約１／２、ヴェトナムで約１／３という相場になっているが、価格のみに注目すればどうすべきかは考えるまでもない。
コミュニケーションが鍵となるこの開発形態において、コミュニケーションの行き来で取引コストというものが発生する。

この取引コストの存在を考慮に入れなければその見積の工数と実際の工数とは大きな隔たりができてしまうことに注意を向ける必要がある。

情報を正しく伝える

プログラマが書く１行１行のプログラムコードはすべて正確な情報に基づいている必要がある。
少なくとも間違った情報に基づいて書かれたコードは影響の大小を問わずユーザの利益を損なうことになるので、それらは修正されなければならない。ここでいう正しい情報とはもちろん仕様のことだ。
手法がウォーターフォールであろうがアジャイルであろうがそれは同じことであって、この仕様はただ一つの拠り所とならなければならない。
そこで、遠隔地にいて元々文化的背景の違う相手との協業であるオフショア開発では、設計者から作成者に情報を正しく伝えるという負担が指数的に増加する落とし穴がある。場合によってはコストメリットを吹き飛ばして大きな損失をもたらすケースもある。

 

意図せぬ改竄

かつて私が担当したプロジェクトでは、通常の開発と同じく基本設計書をまず作成しそれから詳細設計書を作成し実装作業に渡すというプロセスをとった。
ひとつ誰もが心配していたクリティカルな問題があった。ある通信プロトコルを実装する必要があったが、そのノウハウは元々私たちの手元になかった。以前から付き合いのあった或るハードウェアベンダの支援を受けて通信プロトコルのインタフェースの設計をこなした。この設計書は旧来からあった設計書のコンテンツを流用しながら作成し、１０００ページ以上の量にのぼる今回のシステム用の設計書とした。
内部レビューを重ねいよいよ設計書の翻訳にまわし、翻訳ができた部分から現地のベンダに送られることになっていた。しばらく経ったが、翻訳を請け負う会社からリリースした設計書の内容に対して何も反応がなかった。正直少しくらいは誤字脱字くらいはあるはずだし何か訊かれるかなと思っていたので、正直意外だった。翻訳は順調なのだと安堵するようにしたが、実は状況は私の想像とは違っていた。

1000ページ以上にもわたる設計書の翻訳はテキパキと進んでいた。この点は問題なかった。
しかし、その内容は意図せずとはいえ改竄されてしまっていたのであった。
というのは、元からあった設計書および新規に作成した部分で用語の統一ができていなかった。
そのため、本来同義である単語が別の単語として翻訳されてしまっていたのだ。
たとえば、仕様書などで多用されるこういった語の例がある。

元の語句	翻訳された語句
応答	Response、Answer
終了	Quit、Close、End、Terminate
発信	Send、Transmit

また、誤訳の類いだが、すべて終了するという意味の文が「Extinct」（絶滅）と訳されていた例もある。
こうなると、まったく読めない文書になってしまう。
これは、突き詰めれば当初日本語版で作成したときの語句の使いまわしの違いに無頓着だったため起こった私たちのミスだった。
語句の曖昧さを回避すべく専門用語、多用するキーワードの用語辞書が必要だったのだ。だが、我々はそのようなことを全く知らない素人だった。

そして地獄のスパイラルへ

やがて私たちは翻訳された設計書をみたエンジニアとのQ&Aで忙殺されるようになった。
設計書原本の修正・リリース->差分設計書の翻訳版への反映->翻訳版のリリースこのサイクルが日常化することになったのだ。
さらには開発現場への設計者の張り付きという事態にまで進行していった。
これは異なる言語を使う人々と仕事をすることによって発生する特有の取引コストであり、この作業は設計メンバー全体に膨大な負担を強いた。
設計のコストだけで捉えればオフショア開発にしたことが却って仇になった例といえる。

これは、すぐ近くにいる国内のベンダとの協業ならまったく考慮しなくていい負担である。設計書の確認・修正にかかるコスト、そして翻訳にかかるコストと時間はプロジェクトを進める上で大きな向かい風として作用した。

基本設計から詳細設計での一見して普通の設計手法にどんな問題が潜んでいたのか、設計書の翻訳が不可避な内容であったのか、そのポイントについては別途考察するが、このように単価だけでは見えてこない間接的な取引コストの増大を未然にどれだけ防ぎ得るかがプロジェクトの成否の重要なポイントになる。

 

ヴェトナムオフショア開発のツボ（３）

前回の「オフショア開発の意味・効果とは」の続き。

２ オフショア開発の意味・効果とは（その２）

リソース

日本国内に目を向けると、エンジニアの絶対数は少なくとも増加傾向にはなく、必須となるテクノロジーをキーにエンジニアを探す場合など結構苦労するという話を よく耳にするようになった。
増してや一まとまりの開発チームともなると、これを組織的に調達するのは現在では難しくなった。
請負う側の企業にも事情はある。昔のオンラインシステムのような超巨大開発案件がなくなった今、数十人以上の規模でプロジェクトを組織することなど珍しくなった。中小ソフトウェア企業は小規模案件体制にシフトしている企業も多いと思われる。大規模プロジェクトを組む時代は既に終わっているのだ。
とはいえ、ソフトウェアプロジェクトが開発のピークに多くのリソースを必要とする特性は昔と同じなので、しばしばまとまった規模のリソースが必要になるわけだ。
また、国内エンジニア単価のデフレ現象の影響もある。できるだけコストをかけずに案件を受注しこなしていこうとすれば経験のない人材も躊躇わず投入して使っていかなくてはならず、下がり続ける相場は品質面のリスクを増大させる。発注する側からいえば、良質なエンジニアをアサインすることが難しくなっているといえる。

そうした人材調達難に対する回答として途上国へのオフショア開発があるといえる。

先駆となった中国やインドは人口数億～十数億の規模を持つ国であり、エンジニアになる人材の割合がたとえ低かったとしても分母が大きい分、相当な規模の人材調達市場が広がっている。
さらに、インドの例でこの業界が手っ取り早く稼ぐ道であるということで国がIT技術の振興に力を入れている。
技術系の学校・大学を整備し、外資の企業を産学に直結させ毎年大量のエンジニアを社会に送り出している。
日本や米国などITの先進国ではIT技術者の数はほぼ横ばいである。日本では50万人、米国では160万人を超えるといわれているが上記の国々は日本の十数倍の規模の学生が毎年業界に参入し200%を超える成長率を誇る。
このようにして、人口規模で圧倒的な国では国内では困難な10人、20人といった規模のプロジェクトチームが比較的簡単に組織できるわけである。
ヴェトナムはインド、中国には人口規模では遥かに及ばないが、人口構成比でみた場合生産年齢人口が60%超と、豊富な労働供給力があることには変わりない。
もちろん、他の新興国にも同様のチャンスがある。今後はオフショア委託先の候補は世界に拡大すると考えるべきだ。
また、インド・オフショア開発ビジネスの発展の鍵は主要クライアントである米国との時差である。米国が夜の時間帯にインドは昼の時間となるために ２４時間ノンストップで仕事ができたことがインド企業に多くの恩恵をもたらした。
たとえば日本にとっての昼夜逆の地域となると南米かアフリカ西岸あたりになるだろうか、そうした国とのパートナーシップが将来実現する可能性はある。

だが、いいことばかりではない。そこには落とし穴がある。どんな局面も人海戦術で何とかなるという間違った「銀の弾丸」を信じるマネージャがいる とマイナス効果をもたらしてしまう。状況が悪化に伴いリソースの数で対処しようとすることで状況は改善しないばかりかコストも大幅にアップしオフ ショア開発の利点がまるで生かされない。諸刃の剣であることを肝に銘じなければならない。
ともあれ、ソフトウェア開発における健全な流動的人的リソースの投入を実現する上で、オフショア開発は今後マストな仕組みになるはずである。

 

上流と下流の分離

ウォーターフォール的発想に基づき、一般的に開発工程の設計にかかる工程は上流と呼ばれ、製造工程以降は下流と呼ばれる。

上流工程	基本設計、詳細設計
下流工程	製造、試験

上流工程にはシステムの基本部分の検討が含まれており、プロジェクト全体を左右する事柄を決定するためコンサルティング会社が参画したりすること はあっても外注というのは基本的に行わない。
上流工程を経てほぼ全体の機能から各コンポーネントの詳細へと設計が行われる。
この成果物を受けて実際にモノを作るのが下流工程ということになる。
オフショア開発で外部企業に委託する場合、いきなり上流工程に参加させたりすることは通常ない。
まずは是非なく下流の製造工程ということになる。
理想的なサイクルを想定すると、上流工程で設計した内容を下流工程に渡す、つまりオフショア委託先に渡すと、手を離れた設計者たちは別の製品やサービスの検討を始める。
オフショア委託先での製造が終わったらまた設計の終わった次のシステムが製造される。
設計者はずっと設計の現場におり、製造は外部でフレキシブルな体制で行われる。
設計者サイドはより高度で付加価値のある次代の製品やサービスを構築するための頭脳として稼動し続けることができる。
企業にとって、これは大きなアドバンテージになり得る。

通常エンジニアは最初のプロジェクトを終える頃には「こうしたらいいんじゃないか」という改善・発展のアイデアを少なくとも２つや３つは持ってい る。
下流工程を分離することで、そのアイデアを次のプロジェクトに生かされる仕組みを作ることが可能だ。

ただし、このような分業は時間の経過とともに変化するものだ。
最近では従来開発のみオフショアで請け負っていたベンダが設計工程に参加することも珍しくない。
スキルと知識のレベルが上がれば自然な流れといえる。
今後設計という上流工程作業さえオフショアに流れていく可能性は否定できない。

企業のグローバル化

数々の日本企業が世界に出て活躍するようになったし、野球やサッカーなどプロスポーツ界でも海外での活躍が報じられるようになって久しい。
だが、社会全体を見るとどうだろう。まだまだ世界を相手にするという意識にはなっていないように見受けられる。
携帯電話業界がまさにそうだという印象を持っているのだが、優れた技術を持ちながら日本固有のビジネスに固執してしまったがために世界市場での競争力を未だ得られない　これが今の日本の状況そのものではないだろうか。
海外に多く拠点を持つ企業では積極的に外国人を採用し企業の幹部になるケースも出てきているし、社内公用語を英語にする企業が出てくるなど日本の企業にも徐々に世界へ出て行く動きが出てきている。
ソフトウェアの世界では日本はガラパゴス化しているといわれる。
技術力で米国との間でさほど差はないのに世界を席巻し新しいビジネスモデルをもたらすソフトウェアの大半が米国発なのはどうしてだろう？
日本ではソフトウェアは基本的に国内のシステム向けにプラットフォーム、ソフトウェアが整備され、国内で通用する品質基準が支配的であった。日本国産のソフトウェアでそのまま海外へ戦略的に展開して成功しているのは一部のゲームくらいのもので、他にはあまり目にすることがない。
対して米国では初めから世界を相手にしたビジネスのツールとしてのソフトウェアを作り出していた。Microsoft然り、Apple然り、 Google然りである。
両国の状況の違いはそこにある。
それでも徐々に変わり始めるのは必然で、ラインもマーケットも国内でクローズしていた企業も多くが世界に出てゆかざるを得ない時代はもう来てい る。
「百聞は一見にしかず」でこうした意識を変えるのにもオフショア開発は一役買うはずである。

 

ヴェトナムオフショア開発のツボ（２）

前回でオフショアに関わったきっかけについて紹介したが、プロジェクトを通じて経験したことなどあれこれ書いてみるというのが今回の目的。

ちょっと本題に入る前にいろいろ能書きをしてみたいと思う。長くなったので、２回に分けて書いてみる。

 

２ オフショア開発の意味・効果とは（１）

ソフトウェアのオフショア開発という形態が注目されるに至った経緯、その意味や期待される効果について触れたい。

ビジネスの発展形態の中の位置づけ

もともと欧米など先進国の企業が海外進出するにあたり途上国現地に法人を作り、そこを拠点としてビジネスを展開するというのは昔からある。
最初の段階は鉱物、農産物、その他一次生産品などモノと金が流れるだけのビジネスの形態である。
この段階では主体はあくまで先進国から出向いている企業側であり、ギブアンドテイクとは言い切れない状況があった。

次に生産拠点を途上国側に展開するという段階。
この数十年間製造業などの業界で行われてきたもので、工場を現地に作り現地の人材を雇いモノを生産する。
ここでは作った製品を実際に輸送するコストが発生するため低い製造原価が前提である。
このステップで重要なのはそれまでのモノを動かすというだけでなく、生み出すプロセスが移転するという点である。
ここで労働需要が生まれ単にモノを売り買いする経済行動だけでなくノウハウという見えない価値の移転が発生する。

そしてサービスを海外拠点に移転する段階。
製品を作るというのは経済活動の中の一部でしかなく、作られたその製品が実際に人の手に渡りサービスが提供されることによって価値を生む。そしてさらなる製品の需要が喚起されるわけで、主要なソフトウェアベンダの多くも製品販売からサービス提供事業に転換するなどの歩みをみせている。
製造拠点として機能していた途上国ベンダがサービス提供の段階までをもビジネスに取り込むことが可能になると、先進国も途上国もないビジネス上対等な関係が生じることになる。このビジネス展開にはモノ作りを段階を経て得たノウハウが大いに活躍する。
21世紀の現在はこの段階が加速度的に進行している。

こうした流れの中で、ソフトウェアのビジネスは独自のポジションをとっているといえる。
ポイントは製造業が行ってきた労働拠点移転の段階からサービス拠点移転の段階に容易に移行可能な性質を持っているためだと私は考える。
生産効率、工程管理の考え方、品質管理上の特性など製造業の範疇で捉えられる特徴が多々あるものの、製造業とは異なる点がいくつかある。

• 製造に大規模な設備が不要な点
• 製品の在庫管理が不要な点
• 製品出荷に流通手段を必要としない点

また、原価はほぼ人件費であり、ラインを持たない製造工程は簡単に仕様変更に対応できる。
このような製品の性質ゆえに、製造者が自社製品を持ちサービス提供者に転身するなど事業の範囲を拡げることが比較的容易だ。
ソフトウェアのオフショア開発も例外でなく同じプロセスを歩んでいるといえる。

費用効果

エンジニア単価の引力

ソフトウェアの製造コストはほぼソフトウェアエンジニアの人件費が原価の殆どといってもよく、この製造にかかる人／月を以って開発規模が決定する。
ここでエンジニアに対する人件費が安く上がれば即ちプロジェクト全体でコスト削減の恩恵が受けられるのだろうか。
これは開発プロジェクトを管理する人にとっては重要な問題だ。

まず単純な例をあげよう。

「同じ生産性を持つエンジニアが２人いて、１ヶ月稼動する単価が片や50万、片や40万という違いがあるとする。どちらのエンジニアを雇うか？」

当然、40万円のエンジニアだろう。
単価が10万円安い雇えば企業側は月に10万円ずつのコスト削減が可能になる。
現実にこの方式が単純に適用できれば話は速い。
今やオフショア大国となったインド、中国で最初IT産業が立ち上がった頃は単価1/5とか1/3とかいうレベルから始まっている。
「国内エンジニア１人分のコストで○人が雇える」とかいう文句がよく聞かれた。
このように給与水準の低い国、地域のエンジニアを雇えば単価の面では、圧倒的にメリットが得られるのは事実だ。

費用に関していうと、これは経済の成長に伴い変動するもので、単価の上昇は遅かれ早かれやってくる。
現にオフショアの先発組ともいうべきインド・中国はすでに実績を積むに従いエンジニア１人あたりのコストは上がっている。日本国内のエンジニアと比べると、インドでほぼ同等、中国で１／２くらいにまで上昇している。後発となるヴェトナムでほぼ１／３というくらいが相場である。この点、インドでは既にメリットは単価でなくそのサービス内容・付加価値に移っていると考えるべきである。
日本ではオフショアは中国相手の方がメインで、物理的に近いことと漢字でのコミュニケーションが可能なことなどがメリットといわれている。反面、通貨である人民元の安定性に不安があり、日本という国に対しては一部に嫌悪感もあることから事業を展開する上でのリスクも懸念される。
この点、経済面の安定性には疑問が残るが、単価もまだ安く比較的親日的であるということ点がオフショア委託先としてヴェトナムが注目される所以である。

生産性の尺度

次にコストの前提となっている生産性の尺度について触れなければならない。
ここで先の質問に戻る。

「同じ生産性を持つエンジニアが２人いて、１ヶ月稼動する単価が片や50万、片や40万という違いがあるとする。どちらのエンジニアを雇うか？」

実はこの質問には問題がある。最初の前提である「同じ生産性を持つ」というところである。
質問をちょっと変えてみる。

「同じ単価のエンジニアが２人いて、１ヶ月の生産性が片や2.0ｋｓ、片や1.6ｋｓという違いがあるとする。どちらのエンジニアを雇うか？」

私はこの質問には簡単に答えられないと考える。
なぜなら、その生産性を測る基準が一様でないために、エンジニアの価値を単純に比較ができないからである。
生産性を決めるときに重要になる経験値はその人物がそれまでこなしてきた仕事の性格、状況などに大きく影響され、奇しくも同じプロジェクトでずっと働いてきたエンジニアといえどもアウトプットが同じということも有り得ない。
また、生産性の意味するゴールは何だろうか？
ソフトウェアの世界では一定時間で生み出されるコードの量に等しいのだろうか？
部品を作って自動車など作るときには部品を大量に使用するが、使えない部品は生産した内容にはカウントされない。
同じように、ユーザの求めるソフトウェア品質をクリアできないコードはいくらあっても無意味だ。
品質を考慮した製品生産性がこの場合問題であって、単に速く沢山のコードが書けることは必要条件であっても生産性が高いことと同義にはならない点に注意すべきだ。

数々のソフトウェアの歴史が示すように、優秀なエンジニアとそうでないエンジニアとでは数倍から数十倍の生産性の開きが生じる場合がある。
しかも、その比較は単純な計算で求められない。
たとえば組み込み系システムの生産性を業務系システムにそのまま適用することはできない。
再利用可能な部品がある場合とない場合でも異なってくるし
そもそも同じ１人のエンジニアでも常に同じ生産性が保たれるわけではなく、結果だけをみてもその結果を出すまでのプロセスは人によって大きく異なる。
このように非常に捉えにくい生産性というパラメータを常に把握することは至難の技だ。
生産性を定量的に即座に提示できる企業は実際は少ないはずだというのが私の考えである。
生産性は？の疑問にすぐに答えが提示される企業は却って疑ってみる必要がある。
生産性はあくまでも条件として提示する目安としての値であって、実績としてエンジニアあるいはチームの能力を表すものではないと考えるべきだ。

それでは、オフショア開発は一か八かの大博打なのかというと現実には否定できない側面もあると認めざるをえない。
最初のトライアルで思うように成果が得られずに諦めたというケースも数多いのが現実だ。
しかし、生産性を把握する方法がないわけではない。
一例として、プロジェクトのパイロットシステムでもいいし、ほんの一部品でもいいが、小規模かつリスクの少ないコンポーネントを「ハドソン湾スタート方式」で委託してリサーチをするという方法などがある。
生産性の目安が得られるほかに、互いに手の内が分りコミュニケーションがしやすくなるという副次的効果もあるかもしれない。
また逆に、この段階であまりに不本意な結果になるなら、そのベンダとは相性が悪いのかもしれない。その時点で考えることは可能だと思う。
あらかじめ依頼する内容は、この時点で話を「なかったこと」にして振り出しに戻ったとしてもリスクのない範囲にとどめておけばよい。

このように、生産性というパラメータは費用効果を考える場合には切っても切れない関係にある。
単価だけに注目するのはおおいに危険を伴うということだ。

 

 

ヴェトナムオフショア開発のツボ（１）

過去に経験したことなどを整理する上で、ブログという場を利用することにした。

この数年で最も考え方を変えてくれたのは生業であるソフトウェア開発の海外発注＝オフショア開発である。

その中でも初めて接したヴェトナムでの経験をまず取り上げていこうと思う。最初は嫌々関わった世界ではあったけれど、徐々に感じ方も変わって後には楽しい経験となった。その全てを語ることは不可能だし、ましてや共有することなどできないことは承知している。

誤った記述はできるだけ排除するよう心がけるけれど、内容は基本的に私見なので勘違いが放置されている可能性が多分にある。そこはご覧になられた方々にぜひご指摘いただければと考える。

 

ヴェトナムオフショア開発のツボ

１ はじめの一歩

それは、あるオファーから

それは2001年の夏も終わる頃、某通信系子会社でSEをしていた私のところにきたオファーから始まった。プロジェクト単位の契約ではないので、ひとつプロジェクトを終えるとこうした形で次の仕事のオファーをもらうわけだ。きくと、内容はこんな感じ

 

• 従来販売しているパッケージの新バージョンの設計と製造のプロジェクトを開始する。
• 設計は我々がやるが、製造は外注する。

そして外注先は、ヴェトナムという。
まだオフショア開発という言葉も耳慣れぬ頃のこと、我々の心にどんよりと雲がたちこめた。
ヴェトナムといえば四十路過ぎの我々の世代にはアメリカとの戦争でメチャクチャになった頃のイメージが強い。アメリカに続くカンボジア、中国との戦争を経ての世界的孤立の時期も記憶に新しかっただけに、それは生命の危険をも連想させるものでさえあったの だ。
映画「地獄の黙示録」、「プラトーン」あるいは開高健の小説「夏の闇」などで見られる混沌とした世界
それとリアルなソフトウェアの世界とのギャップがどうにも有りすぎて何がどうなっているのか想像さえままならない。これを告げた職場のマネージャ自体、全社的に製造コストを低減する取り組みとしての上層部の意向をきき、プロジェクトの稟議を通すためにその選択 をせねばならない立場であった。その後共に右往左往し苦しんだことから思えば彼自身も何がなされようとしているのかよくわかっていなかったと私は思う。

トップダウンでオフショア参入

当時、コンピュータ、ネットワークなど情報インフラがビジネスの現場で一般化しアプリケーションに対しても顧客からの要求が日に日に厳しくなっていた。顧客からの要求に追随し新しい機能を実装する、また既存機能の品質を向上する、そうした二次的な仕事が増えていくにつれ、それまで比較的大らかに捉えられていたソフトウェアの製造、維持管理にかかる人件費は軒並み膨張する一方となり、利益率の低下が経営的にも見逃せなくなってきていたの だ。
そうした中に、インドや中国でのオフショア開発の例がようやく世間にも聞こえてきており、エンジニアの単価が安いことが何よりも魅力であると俄然 注目を浴びたのである。そこそこの規模の企業になると、対応するかしないかは別として世間の動きには非常に敏い部分がある。さっそく、このような状況で製造原価を下げる取り組みとしてオフショア開発が取締役会で合意に達し全社的にトップダウンで「製造は途上国に外注せよ」となった。これ は当事者であるマネージャにとって、雇われている我々にとっても天の声に匹敵するものであった。

ハードルは高く．．．

  この時点でオフショア開発のポイントはなんといっても開発コストで、とにかく安くあがるというメリットが一人歩きしているかのようでもあった。実はこのプロジェクトが初めてではなく、製造コストを下げるための手段として途上国への外注が有効かどうかそれを試すためのプロジェクトはこれ以前にもあった。現場としてはリスクがあるので、比較的出来栄えの見えやすい小・中規模の業務系のアプリケーションばかりを外注し一応の実績は積んでいきつつあっ た。
しかし、今度は違う。
パッケージ製品の中核でユーザーインタフェースなど見えるものところのない制御システムの開発が私たちのミッションであって、なんとなく動けばい いという曖昧な部分が非常に少なく、またパフォーマンスも重視されるなど設計も製造もそれまでにない高いハードルとなってしまった。
もともとの計画では設計３ヶ月、製造６ヶ月で完成。さっそく我々は要求仕様を確認しざっと工数を積み重ねてみた。
結果、我々は設計の工数と実装規模を概算し、とても予定工期では終わらない、むしろまったく不可能なスケジュールであるという結果を得た。ここでのあるマネージャとのスケジュールに関するやり取りは今も忘れられない。

概算で我々が出したリアルな工数に対して、彼は直近の別のプロジェクトの資料を持ってきてこう言った。

「この実績と比べても計画通りでできるはずだが。」

その直近のプロジェクトには私自身も参加していたが、今回とはまったく内容も異なるプロジェクトであったし、そもそも比較対象にするという時点であまりに強引に思えた。

「そっちのプロジェクトではこれくらいの規模をこの工期で終わらせている。なぜそちらでできて、こちらでできないといいきれるのか。この工数は大 きすぎる。」

工数の根拠、想定しうるリスクなどを述べ反撃したが、彼はまったく引き下がる気配もない。それはそうだろう。最初から反対意見を封じ込めるために席についているのだ。我々もやったことのない性格のプロジェクトのことでリスクをどうしても推定でしか説明できない。そこが弱かった。結局、その提示された工期での完成は約束できないといいながらとにかく走り出そうと言い包められてしまった。

この時の懸念はもちろん後に現実となるわけだけれども、この時点では楽観的に考える人、悲観的に考える人それぞれ思いはあれども前に進む、という 点で一致してしまった。

「我々の知らない場所で言葉の通じない人が我々の製品を作る」

そういう不安の中でのろのろとプロジェクトは船出した。気分は異教の都バビロンに連れ去られるユダヤの民の如しであった。