y_rの落書き帳 このページをアンテナに追加 RSSフィード

2007-05-21

[][]それがインド人にはできない理由(その2) 03:09 それがインド人にはできない理由(その2)を含むブックマーク それがインド人にはできない理由(その2)のブックマークコメント

id:ymScottさんのこのエントリやそのコメント欄を見る限り,議論が収束しそうですが,前回のエントリの続きを書きます.

今日は,そもそもインド人に投げるのって有利なの?というのを書きたいと思います.

開発場所が分散するだけでコストがあがるソフトウェア開発

企業システム開発に限らず,ソフトウェア開発では,分業で開発するとコミュニケーションコストが大きいと言われています.別にソフトウェア開発でなくとも分業体制でのコミュニケーションコストは発生すると思うんですが,ソフトウェア開発では特に強く意識されています.

このソフトウェア開発におけるコミュニケーションコストは,プログラマにとってはほとんど自明のものなのですが,改めて考えてみます.


Google先生に聞いてみても,"ソフトウェア開発にはコミュニケーションコストが多きい"とは書いてあるサイトはあっても,なぜそうなるのかを書いてあるサイトは出てこないのですが,どっかの会議の議事録*1とそこからたどれる("Next"ボタンで)ページや,Joel On Softwareの”やさしい仕様書”を参考にしつつ考えたいと思います.


僕が考えるところでは,ソフトウェア開発時のコミュニケーションコストは以下の理由で発生しています.粒度がばらばらでアレなんですが.

ソフトウェア開発の自由度が高い.

この理由が一番大きいと思います.自由度が高いために*2,各人が同じものを指しているつもりでも,実は別々のことを考えていたということがよくあります.そのために,コミュニケーションをしっかりとって,各人の考え方をそろえておかないと,各人があさっての方向に走り出してしまうことになります.

変更が容易なため,すぐに変更がかかる*3.

機械を製作するのに比べると,ソフトウェア上での変更は簡単にできます*4.そのために,仕様変更という名の変更がソフトウェア開発ではおきやすくなっています.ただし,その際に開発にかかわる人間内で,同じ考えが共有されていないと,上記のソフトウェア開発の自由度とあいまって,悲惨な目に合うことになります.

他人が書いたソースコードはすぐには読めない.

作業レベルに入ると,これはわりと重要かなと思います.特に運用に入ってしまうと開発者とはべつの人が修正するわけですから.

仕様書は完全ではない

これも作業レベルなのですけれども,完全な仕様書というのは書けません.*5そのために,仕様書を書く人と実装する人の間での意識の統一を図る必要があります.

厳密は仕様書は意味不明

Joel On Softwareの”やさしい仕様書-ヒント”の"ルール2: 仕様書を書くのは頭が実行するコードを書くようなもの"を参照してください.何もいうことはありません.


この分業するとコミュニケーションコストがかかるというソフトウェア開発の性質から,以下のような現象が生まれます.


一般に製造業においては

A地点で設計 -> B地点で製造

と設計と製造の拠点を別々にする際には,コストはほとんどかかりません.

しかし,ソフトウェア開発においては,

A地点で詳細設計 -> B地点で実装

と設計と実装を別地点にすると,A地点とB地点で実装能力に差がない場合でも,コストアップの要因になります.*6


アメリカではソフトウェア開発者は一番うまみのある職業らしい...インド人に職をとられるんじゃなかったの?(ただし1年前の状況)

どうもアメリカでは1番うまみのある職業はソフトウェア開発者らしいです.

1年前の記事になりますが,CNNの”50 Best Jobs in America - May 1, 2006”や,その翻訳(ITmedia News)には,Best Jobの1番目にSoftware Engineerがあげられています.それによるとソフトウェア開発者の平均給与は$80,500*7で,10年間で46%雇用が増加する見込みらしいです.

この記事に関する北カリフォルニ(非シリコンバレー)在住のソフトウェアエンジニアの人のエントリがありまして,そこでは,

開発を外注に出すと結局はミスコミュニケーションが多発して、期限ギリギリまで待って仕上がってきたものは出荷できるレベルからは程遠いものだったという話を最近良く聞く.

と書かれています.このエントリからたどれるエントリにもシリコンバレーソフトウェアエンジニアの景気のよさについて書いてあります.


1年前の話なんで,今の状況は変わっているかもしれませんが,5年ほど前からオフショアリングといわれていたアメリカでも,ずっとオフショアリングの道に邁進していたのではないというのは分かります.


中国オフショアで苦労している日本企業

日本の状況はといいますと,日本ではインドよりも中国へのオフショアリングが盛んなようです.ただし,考えもなしに中国オフショアしてしまうと,かなり苦労するようです.

これは両方とも中国側が日本企業に対して苦情を言っている例ですが,@IT中国人の日本型開発アプローチに対する本音は?という記事や,そんな指示じゃできません!中国企業の叫びという記事では,日本企業の仕事の進め方や,仕事の投げ方に対して中国側が苦労している姿が描かれています.

少し引用しますと,

多くの中国人技術者は、「出来上がってきたものを見てから修正する」という日本人のやり方に対して、以下のような否定的な見解を持つといいます。

* 日本人は、本来設計に掛けるべき時間と労力を省いている

* 日本人は、想像力や検討する力が欠けている

* 日本では、能力の低い技術者が設計している

中国に仕事を依頼する際には、平気で「出来上がったものを見てから気に入らない個所を修正する」といったやり方がまかり通ります。良くも悪くも、これが日本式開発アプローチの特徴です。

[日本的環境下でよくある発言]

* システム開発で修正が入るのは当たり前、やむを得ない

* 顧客が直したいと望んでいるのだから、直すべき

* 修正要望に臨機応変に対応するのも、ソフト会社の力量の1つ

from 中国人の日本型開発アプローチに対する本音は?(1)

対日オフショア開発では、変更対応についていろいろな考え方があります。

私が実際プロジェクトを携わってきた感覚としては、経営者またはプロジェクトマネージャ層は、「お客さま(特にエンドユーザー)からの要望は、もちろん神様からの指示なので、ある程度対応せざるを得ない覚悟が必要である」という考えがあります。

対照的に、現場からは「最初からそういう部分(仕様変更部分)をはっきりすればよかったのに、せっかく頑張って作り上げたものを、また変更するのは……」という意見がかなり多かったです。

受注側の立場だと、変更対応に当たった工数を加えて、お客さまが料金を払ってさえいただければ、特に問題がないと思いますが、実際問題として現場のモチベーションコントロールはかなり難しくなります。

場合によっては、作業効率が一気に下がるケースもありました。従って、変更対応の際には上記のバランスを考えることに結構気を使っています。

上海オフショア開発交流会の参加者)

from 中国人の日本型開発アプローチに対する本音は?(2)

「われわれは何を開発すればよいのか、仕様を説明されてもさっぱり分からない」

日本企業の担当者はシステムの全体像を知らないうえに、業務知識も乏しい」

from そんな指示じゃできません!中国企業の叫び(1)

これを日本側から見ると,"1から10まで指示しないと動かない"とか,"平気で品質の悪いプログラムを出してくる"とか,"仕様変更に応じようとしない"とかという話になるのです.


このように,中国(に限らないですが)オフショアでは,中国と日本で,仕事文化の違いによるコミュニケーションミスが発生するので,ブリッジSEと呼ばれる橋渡し役を立てるようなこともやっています.ブリッジSEについては日本最大のオフショア開発サイトのエントリ”ブリッジSEとは”を参照してください.

ただ,いくら中国人プログラマが安いといっても,ブリッジSEを立てて,中国人とのやり取りさせるとなると,それだけで余計なコストがかかるのではないでしょうか?日本語,中国語(英語でOK?)ができて,日中両文化にある程度詳しくて,システムのことも分かって...みたいな人材が安く雇えるわけじゃないですし.

さらに言えば,最近の円安と中国の給与水準高騰で,中国人が安いかどうかも怪しくなってきています.@IT円安と人件費高騰で35%の減益に苦しむ中国では,コストアップによる中国側の苦境が書かれていますが,これらはオフショア代の上昇になって必ず日本側に帰ってきます.


以上のことをまとめると,中国オフショアで日本のソフトウェア開発をやっても,コスト要因(ブリッジSEの存在,中国人の円建て給与水準の上昇)とリスク要因(コミュニケーションミス,仕事文化の違い)から,手放しでハッピーになるとまでは断言できません.





今日はここまでです.

続きの,

  • 日本の企業システム開発での実態

は明日以降にやります.

ただし,この範囲については他の人が詳しくやっているので,あまり詳しくはやらない予定です.

*1:これみるとコミュニケーションとは伝わらないものだという思いがします.

*2:一見なんでもできるように見えてしまう.

*3:そして仕様書のバージョン戦争勃発

*4:ほんとはそう簡単でもないんですけれども見た目上は簡単に思えます

*5:書けなくはないんですけれども,完全な仕様書を書くよりも自分で実装した方が早いです

*6:実はこの比較はあまり適切なものではありません.後日この点についてはエントリを書きます.

*7:僕の給料の2倍以上です.うらやましい...

y_ry_r 2007/06/03 16:06 タグがついていなかったのでつけときます.