« May 2005 | Main | July 2005 »

June 2005

June 27, 2005

借入れ依存体質の危険性

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界 新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第81号 2005/06/27
▼ まえがき
▼ [金持ちソフト会社、貧乏ソフト会社] 借入れ金利が10%を超えていた時代
▼ [金持ちソフト会社、貧乏ソフト会社] 借入れ依存体質の危険性
▼ [金持ちソフト会社、貧乏ソフト会社] インフレ目標のスイッチが押される日
▼ [金持ちソフト会社、貧乏ソフト会社] もう一つの問題
▼ 次回以降の予告


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

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

今回は久々に「金持ちソフト会社、貧乏ソフト会社」シリーズです。

小売業なら売上は売った瞬間に現金になり、仕入れは請求書ベースなので、
「売掛金<買掛金」となります。
一方、システム受託開発会社では通常「売掛金>買掛金」となります。
入りより出の方が早いのです。
したがって、多くのソフトウェア会社では、売上が拡大するにつれて
銀行からの借入れも増えていきます。

今回は、この銀行からの借入れが以前よりも危険なものになりつつ
あるという話しをします。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[金持ちソフト会社、貧乏ソフト会社]
 借入れ金利が10%を超えていた時代
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

私が慶を立ち上げたのは1998年9月、初めて銀行から借入れをしたのは、
2000年9月です。その時の金利は年3.3%でした。
つまり、私は金利が低くなってからの融資しか経験がないのです。

そこで、先日、国民生活金融公庫の営業マンに次のような質問をしました。

「例えば、今は銀行の住宅ローンの金利は1%台のものもある位低い
ですよね。
でも、バブルの頃は住宅金融公庫でも6%、銀行なら8%位でしたよね。
バブルの頃って企業への融資金利もすごく高かったんですか?
そもそも銀行の融資金利は何によって決まるのですか?」


国民生活金融公庫の営業マンの回答は次のようなものでした。

・銀行の融資金利が決まる仕組みは、その融資商品によって異なります。
 長期プライムレートをベースにするものも、短期プライムレートを
 ベースにするものもあります。また、銀行の融資政策にも左右されます。

・国民生活金融公庫の企業融資の金利は長期プライムレートに若干
 上乗せしたものです。上乗せ率はその企業の業績や担保によって
 決まります。

・長期プライムレートは今は1%台前半ですが、バブルの頃は6%~7%でした。
 したがって、バブルの頃は国民生活金融公庫の企業融資の金利は10%を
 超えることも珍しくありませんでした。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[金持ちソフト会社、貧乏ソフト会社] 借入れ依存体質の危険性
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

銀行の営業マンも国民生活金融公庫の営業マンも、私が将来の金利
上昇の話をすると、必ず次のように言います。

・今のところ金利が上昇する気配はありません。
・また、融資金利は変動ではなく固定なので、例えば3年間の融資期間
 中に長期プライムレートが上昇しても融資金利は変わりませんので、
 安心してください。


しかし、借入れ依存体質が染み付いてしまったら、完済後に、また
借入れを起こさなければなりません。
そのときには、後述のように、借入れ金利が大幅に上昇している
可能性が高いのです。

借入れ金利が上昇しても、それ以上に営業利益が増えればよいのですが、
もしも営業利益が増えなければ経常利益が減ります。
また、最悪の場合、金利を払うために、さらに借入れが必要となります。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[金持ちソフト会社、貧乏ソフト会社]
 インフレ目標のスイッチが押される日
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

銀行マンは「金利が上昇する気配はありません」と言いますが、私は
ここ1、2年で金利が急上昇する気配を感じています。


森永卓郎氏が「年収300万円時代を生き抜く経済学」などで展開している
下記の主張には説得力があります。
・現在のデフレ不況は政府と日銀の暗黙の共謀によって演出されたもの。
・小泉改革の正体は「金持ちをますます金持ちにする」こと。

森永卓郎氏によれば「金持ちをますます金持ちにする」仕掛けは次の
とおりです。

> (1)ITバブルを引き起こして「頭金」を作る。
> (2)金融引き締めによるデフレを仕掛けて、資産価格を急落させ、不動産を
>  借金で購入した企業を追い込む。
> (3)不良債権処理を強行して、放出された不動産を二束三文で買い占める。
> (4)デフレを終わらせて、買い占めた不動産価格でキャピタルゲインを得る。
> (5)一度たたき落とした旧来型の企業や一般市民が、這い上がってこない
>  ように弱肉強食社会へと転換する。
>       (森永卓郎著「年収300万円時代を生き抜く経済学」より)

そして、現在は(3)の後半の段階です。

> そう遠くない将来、日銀が事実上のインフレ誘導に打って出ることは
> 確実と言っていい情勢なのです。・・・(中略)・・・
> もう一段の不良債権処理を待って、外資のハゲタカファンドや日本の
> 投資ファンド、「勝ち組」企業が土地や株を買い漁ったあと、ついに
> インフレターゲティングへのスイッチが押されるはずです。
>       (森永卓郎著「「家計破綻」に負けない経済学」より)


6月19日の日経新聞の「インフレ目標論争二幕へ」という記事でも
「インフレ目標の有効性は最近の経済学では広く共有されている」という
竹中経済財政相の言葉を紹介しています。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[金持ちソフト会社、貧乏ソフト会社] もう一つの問題
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

借入れが大きくなり過ぎると、もう一つ問題が発生します。

多くの中小企業では、社長個人が会社の借金の連帯保証人になっています。
これは会社の借金にたいして社長個人が自分の資産を担保に差し出して
いることを意味します。

したがって、借入れが大きくなり過ぎるということは、社長個人に
とってもつらいことですが、会社にとってもデメリットがあります。
社長の交代が難しくなるのです。

たとえ社長が業績を上げられなくとも、年をとっても、交替しづらく
なるのです。
あるいは社長職を後輩に譲って、自分は新しい事業を立ち上げるような
ことができなくなります。


まえがきで次のように書きました。

> 一方、システム受託開発会社では通常「売掛金>買掛金」となります。
> したがって、多くのソフトウェア会社では、売上が拡大するにつれて
> 銀行からの借入れも増えていきます。

しかし、本当に利益が出ていれば、「売掛金>買掛金」による運転資金の
増加も内部留保で補えるはずです。たとえ全額でなくとも・・・。


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

「保存できないエディタ」シリーズはしばらくお休みし、次のような
テーマを取り上げたいと思っています。

・本当の成果主義賃金体系とは何か?
・最近強まっている業務請負から労働者派遣への流れ

次号は、7月4日発行予定です。

乞うご期待!!

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

本メルマガは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

|

June 20, 2005

瑕疵担保責任

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界 新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第80号 2005/06/20
▼ まえがき
▼ [保存できないエディタ] 日経コンピュータ6/13号の問題記事
▼ [保存できないエディタ] 過失がなくても損害賠償や契約解除?
▼ [保存できないエディタ] 無過失責任とそれを限定する特約
▼ [保存できないエディタ] 乙の責に帰すべきものでない瑕疵
▼ [保存できないエディタ] 救済手段は「瑕疵の無償補修」が原則
▼ [保存できないエディタ] 問題の記事のその他の問題点
▼ 次回以降の予告

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

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

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

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

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 日経コンピュータ6/13号の問題記事
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

日経コンピュータ6月13日号に、「【困ったときの法律相談室】
請負か準委任契約か、条項ごと“寄せ”を意識」という記事が載って
いました。( http://store.nikkeibp.co.jp/mokuji/nc628.html 参照)

内田・鮫島法律事務所に所属している弁護士がお書きになった記事です。
後述のとおり問題の多い記事ですが、ソフトウェア請負開発での
瑕疵担保責任について考える材料となるので、今回取り上げます。

下は日経コンピュータの上記記事からの引用です。

> 請負契約では原則、ベンダーに瑕疵担保責任がある。
> ユーザは瑕疵を見つけたら、民法634条以下の規定によって、ベンダー
> に対して責任を追及し、損害賠償や契約の解除を求めることができる。
> ベンダーに過失がなくても、である。

これを読んで読者は違和感を感じないでしょうか?

顧客とソフトウェア会社との間で締結される請負開発基本契約書では、
瑕疵担保責任は通常、下記のように記述されます。
「甲」は顧客、「乙」はソフトウェア会社です。

> 個別契約で定める保証期間内に乙の責めに帰すべき理由により生じた
> 隠れたる瑕疵が発見されて、同期間内に乙に対して通知があった場合、
> 乙は無償で補修を行います。
> この場合の甲に対する救済手段は瑕疵の無償補修に限られます。
> (山崎 陽久著「ソフトウェア開発・利用契約と契約文例事例集」より)
>  http://www.5291soft.com/7-2-1.htm より)

> プログラムの検収後、瑕疵が発見された場合、甲及び乙はその原因に
> ついて協議・調査を行うものとする。協議・調査の結果、当該瑕疵が
> 乙の責に帰すべきものであると認められた場合、乙は無償で補修・
> 追完を行うものとし、乙の責に帰すべきものでないと認められた場合
> には、甲は協議・調査によって乙に生じた費用を乙に支払うものとする。
> (「JISAソフトウェア開発委託モデル契約書」
>    「ソフトウェア開発委託契約の契約と実務」より)

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 過失がなくても損害賠償や契約解除?
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

上記の基本契約書の規定と日経コンピュータの記事とでは、下記の点で
大きな違いがあります。

(1)乙の責に帰すべきでない瑕疵の扱い

「ソフトウェア開発・利用契約と契約文例事例集」や
「JISAソフトウェア開発委託モデル契約書」では、瑕疵担保責任は
「乙の責に帰すべきものであると認められた場合」に限定されています。

それに対し、日経コンピュータの記事では、「ベンダーに過失がなくとも
瑕疵担保責任を追求できる」と主張しています。

(2)救済手段
「ソフトウェア開発・利用契約と契約文例事例集」や
「JISAソフトウェア開発委託モデル契約書」では、瑕疵担保責任の
救済手段は「瑕疵の無償補修」です。

それに対し、日経コンピュータの記事では、「損害賠償や契約の解除」
です。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 無過失責任とそれを限定する特約
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

私はもう一度「ソフトウェア開発・利用契約と契約文例事例集」や
「ソフトウェア開発委託契約の契約と実務」で瑕疵担保責任について
書かれている部分を読み直してみました。
その結果分かったことを記します。

まず、乙の責に帰すべきでない瑕疵の扱いについてです。

請負契約における瑕疵担保責任の一般論としては、日経コンピュータの
記事は正しいです。

> 取引の目的物に瑕疵があった場合、その目的物の提供者は無過失責任
> を負う。すなわち、過失の有無にかかわらず瑕疵が存在したということ
> だけで責任を負わなければならない。
>      (「ソフトウェア開発・利用契約と契約文例事例集」より)

「ソフトウェア開発・利用契約と契約文例事例集」や
「JISAソフトウェア開発委託モデル契約書」で、瑕疵担保責任を
乙の責に帰すべきものであると認められた場合のみに限定しているのは
顧客とソフトウェア会社間で決めた特約なのです。

それでは、何故そのような特約を付けているのでしょうか?

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 乙の責に帰すべきものでない瑕疵
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

その前に、「乙の責に帰すべきものでない瑕疵」とはどのような
ものでしょうか?
例えば下記のようなものが考えられます。

・使用したOS、ミドルウェア、パッケージソフトにバグがあった。
 バグと言えないまでも相性が悪かった。
 そして製品選定時点では、それを予見できなかった。

・顧客が提供した情報に誤りがあったことが原因で発生した瑕疵。

・顧客が必要な情報を提供しなかったことが原因で発生した瑕疵。

・顧客の指図が誤っていたために発生した瑕疵。

ソフトウェア請負開発では、他の製造物の請負開発よりも上記のような
ことが発生しやすく、無過失責任の原則をそのまま適用すると、
受託側にとってあまりにも過酷なものになります。
そのため、基本契約で、瑕疵担保責任を「乙の責に帰すべきもので
あると認められた場合」に限定する特約を入れているのです。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 救済手段は「瑕疵の無償補修」が原則
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

次に救済手段について見てみましょう。

> 請負人であるソフトウエア会社は、まず瑕疵修補責任と損害賠償責任
> を負う。
> すなわち注文者であるユーザーは、瑕疵について相当の修補期間を
> 定めて修補請求ができる(民法634条1項)。ただし、瑕疵が重要
> でない場合で、その修補に過分の費用がかかる場合は修補請求ができず、
> 損害賠償請求しかできない(民法634条1項但書)。

> また、ユーザーは修補請求に代えて損害賠償の請求をすることもできるし、
> 修補請求と共に損害賠償請求も合わせてできる(民法634条2項)。
>
> また、瑕疵によって契約をなした目的を達することができないときは、
> ユーザーは契約の解除をすることができ、合わせて損害賠償の請求も
> できる(民法635条)。
>
>   (「ソフトウェア開発・利用契約と契約文例事例集」より)

救済手段として、修補、損害賠償、契約解除の3つが認められています。

しかし、日経コンピュータの記事では、損害賠償、契約解除のみ
示されています。
修補が十分に可能な場合でも、ユーザーは損害賠償請求または契約解除が
できるかのように読み取れます。

しかし、これはソフトウェア業界の常識からはかけ離れています。
ソフトウェア業界の常識では、救済手段は「瑕疵の無償補修」が原則です。

プログラムは他の物理的な製造物よりもはるかに隠れたる瑕疵が発生
しやすいのです。
したがって、基本契約で救済手段を「瑕疵の無償補修」を原則とする
特約を入れるのです。

日経コンピュータの記事は、プログラムが他の物理的な製造物よりも
はるかに隠れたる瑕疵が発生しやすいという認識がない法律家が書いた
記事です。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 問題の記事のその他の問題点
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

この記事には他にも多くの問題点があります。

例えば、「準委任契約では、ベンダーに瑕疵担保責任はない」と
断定しています。
一方、「ソフトウェア開発・利用契約と契約文例事例集」では
準委任契約でも瑕疵担保責任はあると書かれています。

また、「派遣契約で来た人材に対して成果物の責任を負わせる
『偽装請負』という行為」という記述もあります。
通常は、実態は派遣なのに契約は請負であることを「偽装請負」と
言うはずです。
(第53号 http://www.kei-it.com/sailing/53-041213.html 参照)

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

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

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

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

乞うご期待!!

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

本メルマガは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

|

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

|

June 06, 2005

横受け型アウトソーシング

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界 新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第78号 2005/06/06
▼ まえがき
▼ [保存できないエディタ] 日本での外部人材活用の2形態(派遣と請負)
▼ [保存できないエディタ] 米国でのアウトソーシングの3分類
▼ [保存できないエディタ] 下請け型・派遣型アウトソーシング
▼ [保存できないエディタ] 意識としては「横受け型アウトソーシング」
▼ 次回以降の予告


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

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

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

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

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 日本での外部人材活用の2形態(派遣と請負)
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

日本では、外部人材活用の形態は、「派遣」と「請負」しかありません。
そして、「派遣」と「請負」の違いは次のように説明されます。

・労働者が派遣会社と雇用契約を結び、指揮命令は客先で受ける形態が
 「派遣」である。

・客先常駐自体は、「派遣」か「請負」を決定付けるものでない。
 「自由裁量の余地のない作業指示」を直接受けているか否かが問題である。

・客先常駐でも雇用されている会社から(例えば雇用されている会社の
 リーダから)作業指示を受けているなら請負である。

・また、技術者が客先に常駐して直接作業指示を受けても、自由裁量の
 余地のある専門的な仕事なら請負(準委任)である。


これらについての詳細は下記を参照してください。

派遣については、第52号「人材派遣業は指揮命令権のレンタル業」
http://www.kei-it.com/sailing/52-041206.html

偽装請負については、第53号「大手業務請負会社の業務請負」
http://www.kei-it.com/sailing/53-041213.html

準委任については第54号「準委任と人材派遣を分かつもの」
http://www.kei-it.com/sailing/54-041220.html

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 米国でのアウトソーシングの3分類
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

> 米国では「請負」「派遣」という区分けよりもむしろ、外部人材活用を
> アウトソーシングと位置づけ、1)下請け型アウトソーシング、
> 2)派遣型アウトソーシング、3)横受け型アウトソーシング(特定の機能を
> 一括して外部に委託する方式)――と区分けする方が一般的なようだ。
>
> 独立行政法人 労働政策研究・研修機構「米国:人材ビジネス最前線」より
> http://www.jil.go.jp/foreign/labor_system/2005_1/america_01.htm


米国では労働者派遣法もなく、「派遣」の正式な定義も存在しません。
「労働市場や労働契約に国が介入すべきではない」という考え方なの
かもしれません。

余談になりますが、米国での人材ビジネスの約30%を占めると言われている
PEO:Professional Employer Organization(簡単に言うと、派遣会社と
クライアントの両方が労働者と雇用契約を結ぶ形態)は、日本では共同雇用
が法律で禁止されているので、成り立ちません。
日本の規制の多さの一例です。


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 下請け型・派遣型アウトソーシング
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

さて、アウトソーシングの3分類について考えていきましょう。
1)下請け型アウトソーシング
2)派遣型アウトソーシング
3)横受け型アウトソーシング(特定の機能を一括して外部に委託する方式)

ソフトウェア業界での「下請け型アウトソーシング」は、いわゆる
一括請負です。
そして米国での一括請負はウォータフォール型であることは既に述べました。
この点については下記を参照してください。
・第73号「ファウラー氏の請負契約観」
 http://www.kei-it.com/sailing/73-050502.html 
・第61号「米国ではウォータフォールは増えている(?)」
 http://www.kei-it.com/sailing/61-050207.html


また、一般の労働者が客先に常駐して作業をした場合は、「派遣型
アウトソーシング」です。
たとえリーダが常駐して、そのリーダの下で作業をしても、やはり
「派遣型アウトソーシング」と扱われるようです。

> 一つの企業や工場に大量の派遣労働者を就労させている派遣元事業者の
> ほとんどが、現場に自社の管理者を置いて労働者の管理を行っており、
> 日本では「請負」の範疇に属するものが、「派遣」の扱いになっている
> 場合も多い。
>
> 独立行政法人 労働政策研究・研修機構「米国:人材ビジネス最前線」より
> http://www.jil.go.jp/foreign/labor_system/2005_1/america_01.htm

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ] 意識としては「横受け型アウトソーシング」
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

では、プログラマが客先に常駐して作業をした場合は、「派遣型アウト
ソーシング」なのでしょうか?

ピート・マクブリーン著「ソフトウェア職人気質」には、客先常駐を
奨励するような記述があります。

> ユーザのすぐ隣で開発を行うことで、要件に関するコミュニケーション
> の質、量ともに向上させることができます。従って、要件が複雑な
> アプリケーションではこういったことを真剣に考えるべきでしょう。
>
> (ピート・マクブリーン著「ソフトウェア職人気質」より)


果たして、ピート・マクブリーンは「派遣型アウトソーシング」を
奨励しているのでしょうか?

答えは否です。

今週号では、結論だけ言います。

・「大規模開発・一括請負・ウォータフォール型開発プロセス」の中で
 元請会社が派遣会社やソフトウェア会社から人を集めた場合は、
 「派遣型アウトソーシング」です。

・「小規模開発・アジャイル開発」で客先常駐してプログラミングした
 場合には、プログラマの意識としては「横受け型アウトソーシング」です。
 契約的にはおそらく、時給ベースの工数見積による請負契約、または
 実績時給清算でしょう。

・テストのアウトソーシングも「横受け型アウトソーシング」です。

これらについて、次号以降で詳しく解説します。

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

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

・横受け型アウトソーシング

・見積もりが難しいテスト工程をアウトソーシングする方法
・ソフトウェア工場よりもテストセンターの方が実現しやすい。
・テストのアウトソーシングと漸増型開発プロセス


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

乞うご期待!!

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

本メルマガは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サイトではバックナンバーの全文検索も可能です。)

|

« May 2005 | Main | July 2005 »