オフショア

June 18, 2007

AsIs(現状)とToBe(あるべき)

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界 新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第183号 2007/6/18
▼ まえがき
▼ [慶2.0] (1)インドのERPコンサル会社
▼ [慶2.0] (2)日本からのオフショア開発はChage Requestが多い
▼ [慶2.0] (3)欧米のウォータフォール型開発プロセス
▼ [慶2.0] (4)日本人は「すり合わせ」が得意
▼ [慶2.0] (5)ソフトウェア請負開発での「あ・うんの呼吸」
▼ [慶2.0] (6)AsIs(現状)とToBe(あるべき)
▼ 次回以降の予告

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
まえがき
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

蒲生嘉達です。

今週号ではインドオフショアから始め、開発プロセスから経営方針に
至る広範囲な話をします。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[慶2.0] (1)インドのERPコンサル会社
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

先日、インド企業S社の日本法人のマネージャK氏と会談する機会が
ありました。

S社は某ERP製品のコンサルティングからアドイン開発までを得意と
する会社です。

次のようなビジネスを展開しています。

・インド人ERPコンサルタントが日本で要件定義を行う。
・要件定義に基づいて推奨セットアップをする。
(ERPなのでパラメタでかなりのことができる。)
・顧客に実機で使ってもらい、不足した部分をアドイン開発する。
・アドイン開発では製造からユニットテストまでをインドで行う。
(但し、案件が小さい場合は、全て日本でオンサイト開発する。)

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[慶2.0] (2)日本からのオフショア開発はChage Requestが多い
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

S社は、ワールドワイドで上記サービスを展開している企業ですが、
K氏も日本のソフトウェア請負開発は特殊だと言っていました。

日本からのオフショア開発は、Chage Request が非常に多いという
のです。

欧米では「Functional Spec → Technical Spec」というプロセスを
採りますが、日本では、「概要設計 → 詳細設計」です。
ところが、「概要設計とFunctional Specとはイコールではない」と
K氏は言います。

Functional Specでは、日本の概要設計よりもはるかに詳細まで
記述され、Functional Specが完成すれば、顧客がサインします。
サインオフ後の変更は全てChange Requestであり、追加費用の対象
となります。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[慶2.0] (3)欧米のウォータフォール型開発プロセス
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

次の点は「保存できないエディタ」シリーズで考察しました。

・日本の学者や技術系マスコミは「日本はウォータフォールだから
 ダメだ」と言うが、実際にはオフショア開発の増加によって、
 欧米ではウォータフォール型が逆に増えている面もある。

 第61号:米国ではウォータフォールは増えているという説
 http://kei-it.tea-nifty.com/sailing/2005/02/post_c0a7.html

・ウォータフォール型開発プロセスの基本形は、計画・設計・実装の
 峻別、そして、その間に契約行為を挟むことである。しかし、日本の
 一括請負は、設計と実装の間に契約行為を挟んでいない。
 したがって、欧米のウォータフォール型開発プロセスとは似て非なる
 ものである。

 第62号:米国のウォータフォールでは開発リスクの多くはユーザが負担する
 http://kei-it.tea-nifty.com/sailing/2005/02/post_f244.html

また、米国におけるインドオフショアの猛威は下記で解説しました。

 第157号:サービス業のオフショアリング
 http://kei-it.tea-nifty.com/sailing/2006/12/post_6f55.html

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[慶2.0] (4)日本人は「すり合わせ」が得意
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

私はK氏の話を聞きながら、「変われる国・日本へ」で坂村健氏が
書いていたことを思い出しました。

坂村健氏は、家電や自動車で日本が強い理由は、日本人は「すり合わせ」
が得意だからだと言っています。
家電や自動車では設計から製造に至るまで、多くの「すり合わせ」が
必要で、単一民族、単一言語、単一文化の日本人はそれが得意です。

一方、欧米人は、多民族、多言語、多文化なので、「すり合わせ」が
苦手です。

> 日本のように「あ・うんの呼吸」「紙に書かないで現場で調整」
> というわけにはいきません。
> 従って何かをやろうと思ったら、まず徹底的に制度をつくったり、
> 契約を結んでおかないと、トラブルの連続になってしまう。
> つまり、向こうは要素技術から最終のプロダクトまでの開発において
> 必要なすり合わせのコストが、日本などよりはるかに大きいという
> ことでしょう。
>             (坂村健著「変われる国・日本へ」)

日本人は「すり合わせ」が得意なだけに、逆に「どうすればよいか」
をシステム的に考えません。
そのため日本から要素技術型イノベーションは出てくるが、インフラ型
イノベーションは出てこないのです。

> “どうすればよいか”をシステム的に考えるのが欧米です。

> インフラ型のものは、個別のすり合わせを極力なくすように
> メカニズムとか、制度とか、方式とか、やり方を考えるからこそ
> インフラなわけです
>             (坂村健著「変われる国・日本へ」)

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[慶2.0] (5)ソフトウェア請負開発での「あ・うんの呼吸」
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

ソフトウェア請負開発でも、日本では「あ・うんの呼吸」「紙に書か
ないで現場で調整」が占める割合は大きいです。

開発プロセスがウォーターフォールであってもアジャイルであっても、
Chage Requestは当たり前なのです。

それ自体は、一概に悪いことではありません。

顧客からすれば、取引コストを下げるというメリットがあります。

 第145号:取引コスト
 http://kei-it.tea-nifty.com/sailing/2006/09/post_a811.html

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[慶2.0] (6)AsIs(現状)とToBe(あるべき)
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

K氏の言葉でもう一つ気づかされたことがあります。

要件定義をするということを、K氏は「AsIsとToBeをやります」と
表現しました。

ERPコンサルタントのK氏からすれば、AsIs(現状)やToBe(あるべき)
という用語は日常用語です。

しかし、日本のソフトウェア会社のSE、プログラマは、AsIsやToBe
という言葉は使いません。
システムはどうあるべきかということをとことん考えることはない
からです。

ソフトウェア会社の経営者や管理職ですら、AsIsやToBeという言葉に
なじみがありません。

先週号で私が言いたかったことは、下記の5点についてとことん
考えていこうということです。

(A)顧客や顧客が属している業界が抱える課題は何か
(B)その問題を解決するために自分たちが目指すことは何か
(C)自社のサービスや製品で実現できることは何か
(D)お客様の声を聞くこと
(E)お客様をサポートする体制をどうするか

また、第173号で、顧客の心の中でも社員の心の中でも慶のポジショ
ニングはコンサルタントであると述べました。

これらは「AsIsとToBeを考えていこう」ということなのです。

 第173号:慶ネクストの経営理念
 http://kei-it.tea-nifty.com/sailing/2007/04/post_fdf1.html

 第182号:事業計画はどのようにして生まれるのか
 http://www.gamou.jp/sailing/2007/06/post_ae08.html

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
次回以降の予告
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

次号は、6月25日発行予定です。

今回お休みした新会社法活用術シリーズでは、今後、「法人の不思議」
などの基本的な話、そして「社員持ち株制度の是非」「IPOの損得」
などの具体的な話をしていきます。

乞うご期待!!

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
本メルマガについて
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

本メルマガは2003年12月8日に創刊されました。
創刊号 http://www.kei-it.com/sailing/01-031208.html で述べたとおり、
本メルマガのコンセプトは「読みものとしても面白い慶の事業計画」であり、
目的は「事業計画の背後にある基本的な考え方を語ること」です。

したがって、第一の読者としては、慶の社員(正社員・契約社員)及び
慶と契約している個人事業主を想定しています。
彼らには慶社内のメーリングリストで配信しています。

また、多くのソフトウェア会社・技術者が直面している問題を扱っているので、
ソフトウェア会社の経営者、管理者、技術者にとっても参考になると思い、
第33号(2004年7月19日号)からは「まぐまぐ!」で一般の方々にも公開する
ことにしました。
「まぐまぐ!」での読者数は2007年6月17日現在、601名です。

本メルマガの内容に興味を持つであろう方をご存知なら、是非
本メルマガの存在を教えてあげてください。

(以下をそのまま転送するだけです。)
---------------------------------------------------
【お勧めメルマガ ソフトウェア業界 新航海術】
⇒ http://www.mag2.com/m/0000136030.htm または
 http://kei-it.tea-nifty.com/sailing/ または
 http://www.kei-it.com/sailing/ 
--------------------------------------------------

このメールマガジンは『まぐまぐ!』 http://www.mag2.com/ を利用して
発行しています。配信中止はこちら http://www.mag2.com/m/0000136030.htm
(但し、member@baisoku.co.jp knextall@kei-it.com には直接配信
しています。)

バックナンバーは、発行者サイトまたはブログで、体系として
見てもらいたいので、「まぐまぐ!」でのバックナンバー公開は
最新号のみとなっています。

バックナンバーブログ:http://kei-it.tea-nifty.com/sailing/
発行者Webサイト: http://www.kei-it.com/sailing/
(発行者Webサイトではバックナンバーの全文検索も可能です。)

☆筆者の趣味のブログ:身近にいる小動物の図鑑☆
 http://kei-it.tea-nifty.com/small/

--------------------------------------------------
発行:
株式会社 慶
 代表取締役 蒲生 嘉達

☆ コピーや配布をされる時はご一報ください ☆
☆ このメルマガに対するご感想・ご質問はこちらにお寄せください。 ☆
            kn-office@kei-it.com

|

December 11, 2006

サービス業のオフショアリング

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界 新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第157号 2006/12/11
▼ まえがき
▼ [慶2.0] (1)日本のオフショアリングは製造業が中心
▼ [慶2.0] (2)米国では会計業務までがオフショアリングされている
▼ [慶2.0] (3)米国人プログラマは5年間で14.1万人も減った
▼ [慶2.0] (4)もしも13億の中国人が完璧な日本語を使えたら
▼ [慶2.0] (5)サービス業労働者の世界競争時代
▼ 次回以降の予告


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
まえがき
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

今週号は、「慶2.0 本当の大変化はこれから始まる」シリーズです。

このシリーズでは、次の10年で慶(及び類似した中小ソフトウェア会社)
が目指すべき方向性について、組織、営業、企画、労務など多方面から
考察します。
題は「慶2.0」ですが、多くの中小ソフトウェア会社にとっても共通
の課題を扱います。


「慶2.0」シリーズを最初から読みたい方は、
「バックナンバー 慶2.0」
( http://www.kei-it.com/sailing/back_kei2.html )を参照して
ください。

または、ブログ( http://kei-it.tea-nifty.com/sailing/ )の
「カテゴリー 慶2.0」(↓)を参照してください。
http://kei-it.tea-nifty.com/sailing/cat6545629/index.html

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[慶2.0] (1)日本のオフショアリングは製造業が中心
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

週間東洋経済12月9日号に「落ちる中間層」という特集記事が載って
いました。
http://www.jbook.co.jp/p/p.aspx/1892352/s/

今後数十年にわたって続く大きな流れとして私が感じていたことと
一致する内容だったので、今回取り上げます。


我々は100円ショップに行って、モノが本当に安くなったことを実感
します。
100円ショップには、「こんなものまで100円で買えるの?」という
ような安い商品がいっぱい並んでいます。
そして、その安い商品のほとんどが中国製です。

「生産コストが安い中国が世界の工場となったために、低価格の製品
が怒涛のように押し寄せてくるようになった」というのが、多くの
日本人が感じている「グローバリゼーション」です。

要するに製造業のオフショアリングです。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[慶2.0] (2)米国では会計業務までがオフショアリングされている
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

しかし、米国では、製造業だけでなく、サービス業のオフショアリング
が急速に進んでいます。

そのために、ホワイトカラー、中間層が苦境に立たされている様子が
「落ちる中間層」の中の「これが日本の5年後?沈みゆく米国の中間層」
という章に生々しく描かれています。


米国企業のコールセンター業務がオフショアリングされていることは、
よく知られています。

> マイクロソフトは約数千人の顧客サポートセンターの仕事を
> インドに移転している。

> 過去5年間に、米国のテレホンマーケターの数は約13%も減少した。
>                  (「落ちる中間層」より)


会計業務までがインドなどにオフショアリングされています。

> 単純な税金還付処理はすでに米国の会計士が関与できない状況だ。

> 1990年代末にインドで設立された企業がインターネット上に設けた
> “受付窓口”を経由して、インドの会計士に直接手続きを依頼
> できるようになった。
>                  (「落ちる中間層」より)

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[慶2.0] (3)米国人プログラマは5年間で14.1万人も減った
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

そして、米国人プログラマは、インド人プログラマに職を奪われて
います。

> オラクルにはすでに数千人のインド人社員が在籍し、ソフトウェア
> 設計、経理、顧客サービスなどに従事している。

> インテル、テキサス・インスツルメンツ(TI)も、チップ回路設計に
> 従事するインド人・中国人技術者を多数雇用している。

> マイクロソフト、GE、JPモルガン・チェース、ベストバイなどを
> 顧客に持つインドのIT企業ウィブロでは、3ヶ月ごとにインド人
> 数千人を採用しないと、業務が回らない。
>                  (「落ちる中間層」より)


米国労働省統計局の資料によると、米国人プログラマは2000年には
53万人だったのに、2005年には38.9万人になっています。
5年で14.1万人も減っているのです。

 関連記事:第79号「(2)米国におけるインドオフショア開発の影響」
 [B] http://kei-it.tea-nifty.com/sailing/2005/06/post_a84f.html
 [H] http://www.kei-it.com/sailing/79-050613.html

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[慶2.0] (4)もしも13億の中国人が完璧な日本語を使えたら
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

一方、日本人プログラマは、日本語という障壁があるため、外国人
プログラマに職を奪われることはありません。
日本国内で働く外国人プログラマの数は増えていますが、そのために
日本人プログラマの数が減ったという話は聞きません。


確かに、中国オフショアの影響は出てきています。

> 中国を活用する企業が増えれば増えるほど、システム開発の単価の
> 相場は下がり、そのシワ寄せは下請けにやってくる。実際、空前の
> 人不足にもかかわらず、下請け企業の給与、単価は以前の好景気時の
> ようには上昇していない。
>                  (「落ちる中間層」より)


しかし、日本における中国オフショアの影響は、米国におけるインド
オフショアに比べれば、はるかに限定的です。

米国におけるインドオフショアのすさまじさ、恐ろしさは、「もしも
13億の中国人が日本語をネイティブレベルで使える人々だったら、
いったい何が起きるのか」ということを想像してみたら、ある程度
分かるのではないでしょうか?


 関連記事:第49号「(3)中国オフショア開発の成長」
 [B] http://kei-it.tea-nifty.com/sailing/2004/11/post_dd89.html
 [H] http://www.kei-it.com/sailing/49-041115.html

 関連記事:第119号「(2)IT技術者不足なのに単価は上がらない」
 [B] http://kei-it.tea-nifty.com/sailing/2006/03/post_68af.html
 [H] http://www.kei-it.com/sailing/119-060320.html

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[慶2.0] (5)サービス業労働者の世界競争時代
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

日本語の壁は、日本のプログラマーにとっては、当面はありがたい
ことです。しかし、長期的には日本のソフトウェア産業の競争力を
弱めていきます。

米国は自国のプログラマ14.1万人の首を切ってでも、コストパフォー
マンスを追及しています。
また、インド人プログラマとの競争にさらされた米国人プログラマは
必死になって自らの技術力を磨いています。

> 自らのスキルアップを怠れば、失業という底なし沼に落ちていく。
> それがアメリカ人技術者の現実だ。
>                  (「落ちる中間層」より)


一方、日本人プログラマは、日本語という壁に守られ、安くて優秀な
外国人プログラマと同じ土俵で戦う必要がなく、「スキルアップを
怠っても何かしら仕事はある」という状況にいます。
これは、米国企業と日本企業との生産性のギャップがさらに広がる
ことを意味します。

米国は中間層が没落し、超格差社会となったと言われます。
そのことの是非はともかくとして、我々は、オフショアリングによって
生産性が飛躍的に高まった彼らと競争していかなければならないのです。

本日お話ししたことは、日々の業務に直接関わることではありません。

しかし、サービス業のオフショアリングという巨大な潮流を理解
することは、10年単位で会社や個人の方向性について考える上で
非常に重要なことです。


> アラン・ブラインダー・プリンストン大学教授は、現在進行して
> いるサービス業のオフショアリングを“第3次産業革命”と呼んだ。
> ブラインダー氏によれば、オフショアリングという新たな形の貿易は、
> 今後数十年にわたり世界の産業に甚大なインパクトを与え、およそ
> 2800万人のサービス業労働者を世界競争に巻き込むことになるという。
>                  (「落ちる中間層」より)

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
次回以降の予告
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=


次号は、12月18日発行予定です。
「新営業マニュアル」シリーズを予定しています。

乞うご期待!!

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
本メルマガについて
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

本メルマガは2003年12月8日に創刊されました。
創刊号 http://www.kei-it.com/sailing/01-031208.html で述べたとおり、
本メルマガのコンセプトは「読みものとしても面白い慶の事業計画」であり、
目的は「事業計画の背後にある基本的な考え方を語ること」です。

したがって、第一の読者としては、慶の社員(正社員・契約社員)及び
慶と契約している個人事業主を想定しています。
彼らには慶社内のメーリングリストで配信しています。

また、多くのソフトウェア会社・技術者が直面している問題を扱っているので、
ソフトウェア会社の経営者、管理者、技術者にとっても参考になると思い、
第33号(2004年7月19日号)からは「まぐまぐ!」で一般の方々にも公開する
ことにしました。
「まぐまぐ!」での読者数は2006年12月9日現在、561名です。


本メルマガの内容に興味を持つであろう方をご存知なら、是非
本メルマガの存在を教えてあげてください。

(以下をそのまま転送するだけです。)
---------------------------------------------------
【お勧めメルマガ ソフトウェア業界 新航海術】
⇒ http://www.mag2.com/m/0000136030.htm または
 http://www.kei-it.com/sailing/ 
--------------------------------------------------

このメールマガジンは『まぐまぐ!』 http://www.mag2.com/ を利用して
発行しています。配信中止はこちら http://www.mag2.com/m/0000136030.htm
(但し、web@kei-ha.co.jp it@kei-it.com には直接配信しています。)


バックナンバーは、発行者サイトまたはブログで、体系として
見てもらいたいので、「まぐまぐ!」でのバックナンバー公開は
最新号のみとなっています。

バックナンバーブログ:http://kei-it.tea-nifty.com/sailing/
発行者Webサイト: http://www.kei-it.com/sailing/
(発行者Webサイトではバックナンバーの全文検索も可能です。)

|

June 13, 2005

インドオフショアの影響

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界 新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第79号 2005/06/13
▼ まえがき
▼ [保存できないエディタ] 米国でプログラマの仕事が減ってきた
▼ [保存できないエディタ] 米国におけるインドオフショア開発の影響
▼ [保存できないエディタ] 差別化できるサービスを提供するアウトソーサ
▼ 次回以降の予告


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
まえがき
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

こんにちは、蒲生嘉達(がもう よしさと)です。

「保存できないエディタ」シリーズをスタートした第57号から
「まぐまぐ!」での読者数が急に増えてきました。
シリーズ開始前は約200名だったのに、今では385名です。
読者も「日本のソフトウェア請負開発は何かおかしい!」という思いを
お持ちなのだと思います。

「保存できないエディタ」シリーズをまとめて読みたい方は下記URLを
参照してください。
http://www.kei-it.com/sailing/back_editor.html

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 米国でプログラマの仕事が減ってきた
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

先週、30代の米国人技術者が慶に応募して来ました。

 H2.4 ジョージア州 某カレッジ コンピュータサイエンス科卒業
 H2.4~H4.4 日本の某女子経済短期大学英語講師
 H5.8~H11.4 米国IT企業でネットワークエンジニア
 H11.4~H16.11 米国ソフト会社でWEBアプリケーション開発(Java)
 H17.5 再来日

という経歴です。5年前日本人女性と結婚しています。

「奥さんが日本に帰りたがったから、日本に来たのですか?」
と尋ねると、
「半分はそうです。残りの半分はアメリカでプログラマの仕事が
無くなってきたからです。それに、日本の食べ物が好きだから」
と答えました。

彼は、米国ではインドへのオフショアが進み、米国内のプログラマの
雇用が減っていると言います。

日本語会話は日常会話レベルなら可能ですが、ビジネスレベルでは
不十分です。日本語の読み書き能力はもっと不足しています。
彼の英語力、日本語会話力、コンピュータ技術力が生かせる仕事は、
慶内部には無いので、現在慶の人材コンサルティング部門
( http://k-bank.jp/ )で、他社に有料職業紹介する方向で営業開始
しています。

読者の中で、このような人材に興味をお持ちの方がいらっしゃいましたら、
ご一報ください。

また、他に「このような人材が欲しい」というニーズがあれば、
慶の人材コンサルティング部門に是非お声掛けください。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 米国におけるインドオフショア開発の影響
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

上記米国人技術者は、米国におけるインドオフショア開発の影響の
一例です。

第61号( http://www.kei-it.com/sailing/61-050207.html )で紹介した、
スコット・アンブラー氏のインタビュー記事
( http://www.ogis-ri.co.jp/otc/hiroba/specials/ScottAmbler/interview20Nov2003.html#offshore )
には、米国におけるインドオフショア開発の影響が書かれているので、
もう一度紹介します。

「最近、北米でのソフトウエア開発業務がインドや中国に移ってきており、
北米のソフトウエア開発者が失業するというようなことが報じられて
いますが、そのようなことは実際に起きているのでしょうか?」という
質問に、スコット・アンブラー氏は次のように答えています。

「(アジャイルではない)従来の方法で開発をしている開発者にとっては、
そのような状況はかなり深刻な問題だと思います。・・・中略・・・
インドの開発組織は、CMM (能力成熟度モデル:Capability Matuiry Model)
や6σのような高い成熟度で従来型の開発を行うことを得意としており、
単価も安いし、競合しうる能力を持っており、長期間に渡って開発経験を
積んできました。その結果、インドの開発組織は北米で従来型の開発を行う
開発組織に対抗しうるぐらい力をつけています。
・・・中略・・・
北米で従来型の開発を行ってきた開発者は自分の将来を真剣に考える
必要に迫られています。すなわち、プロジェクト管理者、業務分析者
などになるために新たなスキルを身に付け従来型の開発に留まるか、
自分自身の開発効率や力を上げてアジャイルな開発者になるかを迫られ
ています。」

(インド企業の実力については、IT Proの記事「恐るべしインドIT企業の台頭
競合にも協業先にもなる存在」
http://itpro.nikkeibp.co.jp/free/WAT/ITARTICLE/20050513/3/
を参照してください。)

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 差別化できるサービスを提供するアウトソーサ
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

スコット・アンブラー氏が言う「従来型の開発」とは、大規模開発、
契約形態は一括請負、開発プロセスはウォーターフォール型、
品質管理手法はCMM等、アウトソーシングの分類では「下請け型」です。
これは今後も重要な領域として存在し続けます。
しかし、この領域は今後一層オフショア化が進み、米国人技術者及び
日本人技術者がこの領域で生き延びるためには、プロジェクト管理者、
業務分析者を目指すしかないのです。

しかし、米国人技術者及び日本人技術者が生き延びるもう一つの方向
もあります。

「差別化できるサービスを提供するアウトソーサ」です。
スコット・アンブラー氏が推奨するアジャイルはその一つですが、
それはアジャイルだけではありません。

「どのサービスをどのように提供するかを明確にできるアウトソーサ」
あるいは「明確に得意分野を持った業務請負」と言ってもよいかもしれません。
(現在の日本で行われている「業務請負」は、労働者派遣と紙一重です。)

テストのアウトソーシング一つとっても、米国では実際に様々な
サービスが行われています。
サイクルテストも何度も根気強く実施するサービスもあれば、テストの
計画や設計などを指導するコンサルティングサービスもあります。

顧客は、「コスト削減のために派遣型アウトソーシングや下請け型
アウトソーシングを利用する」という意識ではなく、「外部で提供
されている各種サービスを新たに利用する」という意識を持つように
なるでしょう。

このシリーズの主要なテーマは契約形態ですが、それは我々がどのような
サービスをどのように提供するかを明確にすれば、自ずから決まってくる
ことかもしれません。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
 次回以降の予告
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

次回以降は引き続き下記の項目について書いていきます。

・保存できないエディタシリーズのまとめ
・横受け型アウトソーシング
・見積もりが難しいテスト工程をアウトソーシングする方法
・ソフトウェア工場よりもテストセンターの方が実現しやすい。
・テストのアウトソーシングと漸増型開発プロセス


次号は、6月20日発行予定です。

乞うご期待!!

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
本メルマガについて
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

本メルマガは2003年12月8日に創刊されました。
創刊号 http://www.kei-it.com/sailing/01-031208.html で述べたとおり、
本メルマガのコンセプトは「読みものとしても面白い慶の事業計画」であり、
目的は「事業計画の背後にある基本的な考え方を語ること」です。

したがって、第一の読者としては、慶の社員(正社員・契約社員)及び
慶と契約している個人事業主を想定しています。
彼らには慶社内のメーリングリストで配信しています。

また、多くのソフトウェア会社・技術者が直面している問題を扱っているので、
ソフトウェア会社の経営者、管理者、技術者にとっても参考になると思い、
第33号(2004年7月19日号)からは「まぐまぐ!」で一般の方々にも公開する
ことにしました。


本メルマガの内容に興味を持つであろう方をご存知なら、是非
本メルマガの存在を教えてあげてください。

(以下をそのまま転送するだけです。)
---------------------------------------------------
【お勧めメルマガ ソフトウェア業界 新航海術】
⇒ http://www.mag2.com/m/0000136030.htm または
 http://www.kei-it.com/sailing/ 
--------------------------------------------------

このメールマガジンは『まぐまぐ!』 http://www.mag2.com/ を利用して
発行しています。配信中止はこちら http://www.mag2.com/m/0000136030.htm
(但し、web@kei-ha.co.jp it@kei-it.com には直接配信しています。)

発行者Webサイト: http://www.kei-it.com/sailing/
(発行者Webサイトではバックナンバーの全文検索も可能です。)

--------------------------------------------------
発行:
株式会社 慶
 代表取締役 蒲生 嘉達
 y_gamou@kei-ha.co.jp
 Webシステム開発事業部 http://www.kei-ha.co.jp
 ITサービス事業部 http://www.kei-it.com
 人材コンサルティング事業部 http://www.k-bank.jp
 TEL:03-5951-8490

☆ コピーや配布をされる時はご一報ください ☆
☆ このメルマガに対するご感想・ご質問はこちらにお寄せください。 ☆
            office@kei-ha.co.jp

|

May 16, 2005

米国でのテストのアウトソース・ビジネス

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界 新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第75号 2005/05/16
▼ まえがき
▼ [保存できないエディタ] 米国でのテストのアウトソース・ビジネス
▼ [保存できないエディタ] テストのオフショア(米国→インド)
▼ [保存できないエディタ] 実は漸増型開発とも意外と相性がいい
▼ [保存できないエディタ] 付け足し:第三者検証(IV&V)
▼ 次回以降の予告


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
まえがき
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

こんにちは、蒲生嘉達(がもう よしさと)です。

「保存できないエディタ」シリーズをスタートした第57号から
「まぐまぐ!」での読者数が急に増えてきました。
シリーズ開始前は約200名だったのに、今では362名です。
読者も「日本のソフトウェア請負開発は何かおかしい!」という思いを
お持ちなのだと思います。

当初は3,4回のシリーズにするつもりでしたが、請負契約や開発プロセス
については話題が尽きず、今回でシリーズ19回目となります。

「保存できないエディタ」シリーズをまとめて読みたい方は下記URLを
参照してください。
http://www.kei-it.com/sailing/back_editor.html


第72号を書いているときには、「そろそろ本シリーズのまとめに入って、
第75号くらいで完結させよう」と思っていました。
しかし、第74号でテストのアウトソーシングにまで言及したので、
このシリーズはもうしばらく続きます。
テストのアウトソーシングについては、いくつか気になっていることが
あるからです。


尚、テストのアウトソーシングの話をするときの「テスト」とは、
通常はブラックボックステストのことです。
ホワイトボックステストとブラックボックステストについては第71号
http://www.kei-it.com/sailing/71-050418.htmlを参照してください。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 米国でのテストのアウトソース・ビジネス
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

日本では、昔も今も「テストのアウトソーシング」という発想はほとんど
ありません。
外注を使う場合にも、日本のメーカや元請SIは製造からホワイトボックス
テストまでを下請けに出し、ブラックボックステストは社内でやるのが
一般的です。
しかし、米国ではテストをアウトソーシングすることがよくあります。

本シリーズでよく引用している「基本から学ぶソフトウェアテスト」
(Cem Kaner,Jack Falk,Hung Quoc Nguyen著)でも、テストのアウトソーシング
について非常に具体的に説明されています。
いかに具体的で実務的な説明であるか理解していただくために、二つだけ
文章を引用します。

> アウトソーシングの契約を結ぶ前に、技術者の面接を躊躇せず徹底的に
> 行う必要がある。

> 技術の高い企業は、間接費や固定費の分を上乗せして契約を行うもの
> である。コンサルティング企業であれば3倍の請求をすることが多い。
> 例えば時間当たり3000円で契約していても、そのうち技術者に相当する
> コストは1000円である。

一方、日本の学者が書いたソフトウェアテストの本で、テストのアウト
ソーシングについて書かれているものは、私は見たことがありません。

「基本から学ぶソフトウェアテスト」ではテストのアウトソーシングの
具体的な説明の後で、次のように総括しています。

> 全体的に見ると、テストのアウトソーシングはそこそこ評価できる。
> デメリットよりもメリットの方がとても多い。アウトソーシングを
> 役立てることができる組織は多いだろう。

これが米国における標準的な考え方だと思います。
つまり、米国ではテストがアウトソース・ビジネスとして独立して存在
しているのです。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] テストのオフショア(米国→インド)
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

インドもテストを独立したアウトソース・ビジネスとして捉えています。

インドのメジャーなITサービス企業であるウィプロ(Wipro)には、
2,000名以上の品質保証(QA)の専門家がいるそうです。
http://www.mercury.com/jp/company/pr/press-releases/113004wipro.htmlには、次のように書かれています。

> Wiproは、現在、2,000名以上の品質保証(QA)の専門家が、金融・流通・
> 公共・製造・通信などのさまざまな業界、および組み込みシステム/
> アプリケーション分野で、100 社以上の顧客に対して、テストサービスと
> 品質保証サービス、ならびにテストプロセスのコンサルティングを提供
> しています。

日本での中国オフショアは、製造からホワイトボックステストまでを
中国で行い、ブラックボックステストは日本で行うのが通常のパターンです。
国内ソフトウェア会社への外注と同じパターンです。

しかし、米国からインドへのオフショアでは、米国で製造したシステムを
インドでテストするというパターンも多いようです。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 実は漸増型開発とも意外と相性がいい
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

開発コストの中でテストが占める割合はどの程度でしょうか。
製品の性格によって異なりますが、運用と保守を除く初期開発コストの
30%~50%を占めると言われています。
これをアウトソーシングできるなら、その意義は大きいはずです。

しかし、テストのスケジュールは上流の工程の進捗に依存してしまうため、
見積もりが難しいはずです。
また、実装が遅れたり、予想よりバグが多かったり、ユーザインタフェース
が確定しない場合には、テストの時間が膨らんでしまいます。
普通に考えると、テストのアウトソーシングは難しいと思ってしまいます。
これを米国ではどのようにやっているのか、次号以降で解説します。

また、普通に考えると、設計からテストまでを並行して進める漸増型開発
プロセスではテストのアウトソーシングはやりづらいと思ってしまいます。
しかし、本当は違います。
実は、漸増型開発プロセスとテストのアウトソーシングとは、意外と
相性がいいのです。
このあたりも次号以降で解説します。

もう一つあります。
製造業の製造工程と、ソフトウェアの製造工程とは全く異なっています。
しかし、製造業における品質管理とソフトウェアの品質管理とは
似ているのです。
これは、ソフトウェア工場よりもテスト工場の方が実現しやすいことを
意味しています。
このあたりも次号以降で解説します。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 付け足し:第三者検証(IV&V)
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

本シリーズで取り上げる「テストのアウトソーシング」は、いわゆる
「第三者検証」IV&V(Independent Verification and Validation)とは
違います。
第三者検証(IV&V)は、独立したテスト機関が実施する検証や評価
であり、通常の商用アプリケーションのテストではありません。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
 次回以降の予告
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

次回以降は下記の項目について書いていきます。

・米国でのテストのアウトソーシング。
・漸増型開発プロセスとテストのアウトソーシング。
・ソフトウェア工場かテスト工場か。


次号は、5月23日発行予定です。

乞うご期待!!

|

November 15, 2004

中国オフショア開発

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界 新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第49号 2004/11/15
▼ まえがき
▼ [5年後のシステム開発] 少なくなってきた一括の仕事
▼ [5年後のシステム開発] 地方での開発がうまくいかない理由
▼ [5年後のシステム開発] 中国オフショア開発の成長
▼ [5年後のシステム開発] 中国オフショア開発が成功する理由
▼ [5年後のシステム開発] 日本に残る仕事
▼ 次回以降の予告


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
まえがき
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
蒲生嘉達です。お疲れ様です。

本メルマガは2003年12月8日に創刊され、第32号(2004年7月12日号)
までは、慶の社員(正社員・契約社員)及び慶と契約している個人
事業主の方々のみに配信していましたが、第33号からは一般の方々
にも公開しております。
発行者Webサイト: http://www.kei-it.com/sailing/ で、
バックナンバーを見ることができますし、バックナンバーの全文検索も
できます。

ソフトウェア業界の情報発信基地へと発展させていき、業界に新しい
流れを作っていきたいと願っております。

本メルマガの内容に興味を持つであろう方をご存知なら、是非
本メルマガの存在を教えてあげてください。


第45号から「会社の規模」について書いていますが、今週号は
少し寄り道して、中国などでのオフショア開発について書きます。
中小ソフトウェア会社の社員は「自社は海外オフショア開発を行って
いないから、自分には関係ない」と思っているかもしれませんが、
海外オフショア開発は日本のソフトウェア業界に既に大きな影響を
与えているのです。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[5年後のシステム開発] 少なくなってきた一括の仕事
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

下記は11月10日に某中堅ソフトウェア会社のM社長から頂いたメール
からの引用です。
(その会社は一括しかやらないことを標榜している会社です。)

> 1)少なくなってきた一括の仕事
>    2部上場のSI会社・・・4月から極端に減ってきた
>    印刷会社の関連会社・・・同様なことを言っています
>    従ってわが社も大苦戦です

ここでいっている「一括」とは「一括請負」のことです。
「一括請負」とは何かについては、「ソフトウェア業界航海術」
第1章P.6~P.8を参照してください。
( http://kcode.jp/kcode/dl/k-base.pdf )

私も営業していて、M社長と同じことを感じています。
一括の仕事が少なくなってきた原因として、私は下記の二つを考えて
いました。

・一括の失敗・トラブルが続いているので、顧客もソフト会社も一括を
 嫌がるようになったから。

・スパイラル型開発では、作りながら仕様を固めていくので、
 ユーザの近くで作業する方が仕様確定・確認には有利だから。

しかし、最近、上記に加えて、中国オフショア開発が本格化してきた
ということも理由の一つであると考えるようになりました。


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[5年後のシステム開発] 地方での開発がうまくいかない理由
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

私はつい最近まで海外オフショア開発には否定的でした。

工業製品の場合、「需要は東京、工場は地方」ということはごく
一般的なことです。
しかし、ソフトウェアについては、これだけ情報通信技術が発達しても、
地方で開発するということは難しいことなのです。

(1)相手の目を見ること
システム開発の本質的な部分は仕様の決定であり、それについては
顧客の顔を直に見られる東京での開発の方が有利です。

> 何世代も開発の段階を経てきたテレビ電話やテレビ会議などの道具類、
> 居ながらにして離れた場所の臨場感を得られるテクノロジーなどは、
> いまだにお互いの固い握手や相手の目を見ることの本質を実現する
> 段階にはほど遠いところにある。
> (ジョン・シーリー・ブラウン、ポール・ドゥグッド著
> 「なぜITは社会を変えないのか」より)

(2)人材の質と量
確かに地方は事務所費用の面では有利です。
しかし、人件費については必ずしも地方が有利とは言えません。
地方には質量ともにSE・PGの数が不足しているからです。
また、SE・PGの育成は工場労働者の育成ほど容易ではありません。

(3)昨今の開発スタイル
「設計は東京、製造は地方」という方式は、納期が短く、仕様確定
が遅れがちで、作りながら仕様を考えるという昨今の開発スタイルに
なじみません。
設計と製造の現場が物理的に離れているため、かえって非効率に
なってしまうのです。


国内の地方ですらうまくいかないのに、外国に持っていってうまくいく
はずがないというのが従来の私の考えでした。

また、実際に中国オフショア開発の悲惨な失敗例は非常に多かったのです。


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[5年後のシステム開発] 中国オフショア開発の成長
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

しかし、中国と日本の地方とではパワーが違います。
中国には安くて優秀なSE・PGがいます。
中国は国策として技術者を育て、中国オフショア開発を成功させようと
しています。

また、日本の大手SIベンダー、大手メーカの目にも、中国人技術者の
優秀さと安さは魅力的に映ります。

様々な問題もあり、最初は失敗の連続でしたが、何度も失敗を重ねると
ノウハウも蓄積されてきます。成功例も増えてきています。

今や、中国オフショア開発は日本のソフトウェア業界に大きな影響を
与えるまでに成長してきています。

「2003年コンピュータソフトウェア分野における海外取引および
外国人就労等の実態(JISA,JEITA,JPSA)」をご覧下さい。
http://www.jisa.or.jp/activity/newsrelease/2003-1225-j.html
http://www.jisa.or.jp/static/iande/Findings2003.pdf

海外オフショア開発は、ここでは「カスタムソフトの輸入」と表記
されています。
顧客が直接海外企業から輸入したカスタムソフトは総額で104億円、
そのうち中国が43億円です。
また、顧客が国内企業を経由して海外企業から輸入したカスタムソフトは
これは総額で99億円、そのうち中国が55億円です。
合計総額203億円、そのうち中国が98億円です。

回答企業数が262社に過ぎないことを考えると、実際にはこの数倍
あるのかもしれません。
また、上記は2003年のデータです。
2004年に入ってさらに急増しているでしょう。


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[5年後のシステム開発] 中国オフショア開発が成功する理由
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

先に下記の指摘をしました。

・システム開発の本質的な部分は仕様の決定であり、それについては
 顧客の顔を直に見られる東京での開発の方が有利です。

・「設計は東京、製造は地方」という方式は、納期が短く、仕様確定
 が遅れがちで、作りながら仕様を考えるという昨今の開発スタイルに
 なじみません。


中国オフショア開発ではこの問題をどのようにして解決しているので
しょうか?

実は中国オフショア開発はウォーターフォール型でやっているのです。
たから上記問題を回避できるのです。

冒頭のM社長の言葉をもう一度読んでください。
「2部上場のSI会社」と「印刷会社の関連会社」からの一括が、
4月から極端に減ってきたと言っています。

大手のSI会社は似通った仕事を多数抱えています。
また大手ユーザの関連ソフト会社は、親会社や関連会社の似たような
仕事を多数抱えています。
このような仕事は今でもウォーターフォール型で開発されています。

私は第6号( http://www.kei-it.com/sailing/06-040112.html )で
「新規開発であっても担当SEにとっては漸増的再構築のようなもの
であるなら、漸増的開発の必要性はない、あるいは限定的な適用で
十分とも言えます」と述べました。
同じ技術者が似たような開発を連続して行うなら、プロジェクトの
初期の段階で仕様を確定することが可能です。
また、プロジェクトの初期の段階で、プロジェクト終了までに起きる
ことのほとんどを見通せます。
したがって、ウォーターフォール型でも、短納期でユーザ要件を
満たせる開発が可能なのです。

この種の開発は、国内のソフト会社に一括請負として発注しやすい
開発でもあるし、中国オフショア開発にも向いている開発でもある
のです。
この部分がどんどん中国に流出しているのです。

その結果として、国内では一括請負の仕事の総量が減りました。
さらに、中国オフショア開発との価格競争が単価引き下げの一因と
なっています。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[5年後のシステム開発] 日本に残る仕事
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

今や中国オフショア開発は「5年後のシステム開発」を考える上で
重要な存在となっています。

今後も、一括請負の仕事の総量は減り続けるでしょう。
しかし、全ての一括請負の仕事が減るわけではありません。

「上司に恵まれないSEのために-自分戦略策定マガジン」
( http://mentorpin.way-nifty.com/se/2004/04/no017.html )では、
次のように予測しています。
・顧客密着度の低い開発、主流IT系の開発は中国に流出していく。
・顧客密着度の高い開発、非主流IT系の開発は日本に残る。


上記予測に加筆すると、日本に残る仕事、逆に増えていく開発は
下記のようなものになるでしょう。

○顧客密着度の高い開発
・日本の消費者ニーズに密着した開発。
・顧客と密着しなければ、仕様が決められない開発。
・仕様がはっきりしない開発。
・きれいに切り出せない隙間の開発。
・中国オフショア開発の納品物の修正、障害対応、機能追加。
・技術的に新規性のある開発。

○非主流IT
・市場規模が小さい技術による開発。
・市場規模が縮小している技術による開発。

どれも一筋縄ではいかないものばかりですね!!

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
 次回以降の予告
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

次号は、11月22日発行予定です。乞うご期待!!
第48号の続きで「会社の規模」について書きます。


|