**************************************************************
_/_/_/_/_/_/_/  ソフトウェア業界　新航海術  _/_/_/_/_/_/_/_/_/
**************************************************************
第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コンサル会社
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

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

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

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

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



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

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

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

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

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)日本人は「すり合わせ」が得意
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

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

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

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

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


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

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

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



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

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

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

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

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

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



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

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

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

ERPコンサルタントのＫ氏からすれば、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://kei-it.tea-nifty.com/sailing/



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

次号は、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