日経コンピューター２００６年７月１０日号Ｐ１８に
オフシェア開発、大型案件に浸透
”今欲しい”技術者確保に向け、発注量は前年度比２割増へ
っていう記事があります。
オフシェア開発に大手さんは、大々的には向かっているようですけど、
でも、ここで、オフシェアの比重を増やしてコストダウンなんてことで、
安穏としていたら、次のコーナー回ったところで、時代遅れ、業績急低下！
になっちゃいそーですよねー（＾＾）
なぜか、理由は２つ！
１つは、オフシェアの単価を、
国内の（北海道など）地方で経済がぼろぼろに崩壊してしまった地域の人件費と
比べると、そんなに差がなくなりつつある、
いや、将来的には逆転すらありえそうなこと。
上記の記事中にも、オフシェア開発の人件費が「単価４０万前後と」とあります。
でも、国内の技術者も、地方にいけば、その程度ってことは、たしか、
日経コンピューターでも書いていませんでしたっけ？
（ごめん、いつの日経コンピューターだかわすれた。価格崩壊の号）。
また、海外の場合は、残業代を払わなければいけないケースがありますけど、
日本の正社員の場合、事実上、残業代を払わないでいいケースがありますよねー
（詳しく書くと、労働なんとか法の問題になりそうなので書かないけどお）。
この場合、長時間拘束（事実上２４時間、数日拘束）などという場合、
費用は逆転しちゃいます。
オフシェアって、今後を考えると、必ずしも安くはなりません。
また、中国人を統制する上で、面子（めんつ）の問題は最悪ですよねー。
仕事のすべての信頼関係は崩壊し、仕事どころではなくなる危険がある
。。って、あんまり書くと、国際問題に発展しそうなので、このへんでカット！
しかし、そんな議論は、どーでもいいんすよ！
もう一つの理由の、オフショアの先の話が重要なのです。
オフシェア開発において、仕様書は
（以下の斜体は、日経コンピューターのＰ１８から引用）
詳細設計書における分岐条件に、日本語の「または」、「かつ」、「未満」などを
つかわず、「or」、「and」、「＜（不等号）」などで書くようにしている
と書いているように、プログラムに近くなり、さらに型にはまった
書き方になってくると思います。
プログラムに近づき、型にはまったとくれば。。。自動生成！！
これにより、人が必要なくなるというだけでメリットは大きいです。
さらにそれに加えて、そこが自動生成されることで、すぐに結果がでてきて、
開発のテンポが早くなるというメリットも、これまた大きいのです！！
なので、もし、オフショアに出しているところの自動生成に成功すれば、
他社をだしぬく、大きなアドバンテージになります。
ここで、昔のＣＡＳＥの歴史や、昨今のＭＤＡの話をもってきて、
そんなのできるわけ無いじゃんって反論してくる輩がいるのは、
百も承知の上でーす！！
しかし、そんな広範囲なことを、もともとやろうとしているんじゃないです。
さらに、必ずしもすべてを自動化しようなんてことも言ってるわけじゃないです。
→コスト大幅削減すればＯＫ
仕様上、ここはこうきたら、こうプログラミングするっていうパターン的なとこ
（って、デサインパターンのパターンじゃなくって、それよりも、もっと
大きな概念の”業務パターン”）たとえば帳票出力や画面表示、作業指示書作成
などなどを自動化してしまうってかんじです。
いや、自動生成まで行かなくても、この手順をマニュアル化し、この組み合わせで
システムを表現できれば、仕様の作成は簡単になってきます。
オフシェアでは無理でも、パートタイムの主婦、フリーターでも、にわかＳＥ化が
可能です。彼らは１人月２０万程度のバイト代でＯＫ！
４０万のオフシェアの半額です！！
そーいった、部分的、ゲリラ的な自動生成＆マニュアル化におよる効率アップと、
それを利用したオフショア部分の発注削減が、これからの鍵になると思います。
（フリーターを２０万程度で活用ってのも。大手が直接フリーターを雇うというのも
将来的にはおもしろいアプローチかもよ！？）
と、ここ数日前までは、こんなのんきなこと、ぶちかましていたわけですけど、
こんなもんは、平成のねむりをさます蒸気船じゃなかった、
ミサイルでぶっ飛んでしまいましたねー。
オフシェア開発は、中国、インドなんて、国際的に危ない国に発注しているわけ
じゃないですか！！。
そりゃー危険っすよおーー（＠＿＠！）。
中国とか、なんかがもとで、喧嘩となり、国交断絶！とまでは行かなくても
（むかしは「いくわけないじゃん（＾＾）」で済ましてたけど、きのうあたりから、
そうも言い切れなくなった）、どっかにDDos攻撃をかけて、インターネット回線が
混み合いすぎて不通とか。。ないとは、ありえそーですよね！
もちろん、現地にいる日本人は、危険です。
じゃあ、インドはっていうと。。。これまた危険だ。
インドに行ったら、テロに会ったなんていうのも、ありえないことじゃなさそうだし。
インドも（失敗ですか？）なんか、ミサイルぶっ放してたし。。
てなわけで、オフシェア開発の場合、カントリーリスクがあり、
そのリスクは最近、とみに、とみに！大きくなった気がします。
そのリスクに備えるという意味では、いまから
自動化システムの開発や、
地方の利用（とくに北海道や沖縄）
パートの主婦、フリーターを直接大手が（アルバイトとして）採用！
なーんていうことを見据えて、仕様書をパターン化（業務のパターン化）
を研究しておいたほうがいいのかもしれない。
具体的な業務のパターン化については、このブログの趣旨（オフシェア開発とカントリーリスク）に関係ないので、別の機会に（覚えていたら）
アクセス
トータル
ランキング
