ソフトウェア業界 新航海術

株主

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第184号 2007/6/25
▼ まえがき
▼ [新会社法活用術]　(1)今週号のテーマは株主
▼ [新会社法活用術]　(2)ａ社長は毎月の目標達成に追われる日々
▼ [新会社法活用術]　(3)出資は貸し付けよりもリスクが大きい
▼ [新会社法活用術]　(4)今週号の関連記事
▼ 次回以降の予告

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

蒲生嘉達です。

今週号は4週間ぶりの新会社法活用術です。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[新会社法活用術]　(1)今週号のテーマは株主
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

本日は、株主について話します。

第29号「会社法の主要な登場人物」の中でも最初に出てきたのは、
株主でした。

　第29号：会社法の主要な登場人物
　http://kei-it.tea-nifty.com/sailing/2004/06/post_a2ec.html

さて、Ａ社は、売上約6億、資本金1億円のソフトウェア会社です。
元々資本金4,900万円の独立系の会社でしたが、数年前に大手外資
企業Ｂ社から5,100万円の出資を受けました。

※　Ａ社もＢ社も実在の会社ではありません。フィクションです。

Ａ社がＢ社の資本を導入した理由は、運転資金が不足したからです。

ソフトウェア開発請負業の場合、小売業などの現金商売と違い、
運転資金の調達は大きな問題となります。
たとえ事業が順調であったとしても、売上規模が拡大するにつれて、
重要な問題となってきます。

　第149号：売掛金と買掛金の差額はチープにならない
　http://kei-it.tea-nifty.com/sailing/2006/10/post_393d.html

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[新会社法活用術]　(2)ａ社長は毎月の目標達成に追われる日々
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

中小ソフトウェア会社の主な資金調達方法は下記の二つです。

・金融機関からの借入
・外部資本の導入

Ａ社は「外部資本の導入」を選択しました。

Ａ社にはＢ社から取締役が送り込まれ、それまでいたＡ社の役員は、
ａ社長を除き、全員退任しました。

Ａ社のａ社長は月次で業績をＢ社に報告しなければなりません。
しかし、Ａ社のような一般的な中小ソフトウェア会社の営業利益率は
けっして高くありません。
しかも、プロジェクトの失敗などのトラブルが発生すれば、すぐに
利益は吹き飛んでしまいます。

ａ社長は毎月の目標達成に追われる日々を送っています。
Ｂ社はドライな外資ですから、業績が悪ければ、いつ解任されるか
分かりません。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[新会社法活用術]　(3)出資は貸し付けよりもリスクが大きい
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

ここで、普通の人は、「ａ社長はかわいそう！Ｂ社は血も涙もない
金の亡者！」と感じるでしょう。

しかし、Ｂ社の立場に立って考えてみると、それは見当違いである
ということが分かります。

もしもＢ社が金儲けの安全性を考えたなら、5,100万円をＡ社に
（出資ではなく）貸し付けてもよかったはずです。
貸し付けの場合、契約時点で、返済も利益（利息）も確定します。
さらに、ａ社長を連帯保証人にすれば、Ａ社の事業が失敗し、倒産
したとしても、ある程度は回収できるでしょう。

一方、株主となった場合は、出資の時点で利益（配当）が確定される
ことはありません。毎年、決算まで確定されないのです。
また、Ａ社が事業に失敗し、倒産した場合には、出資金を失ってし
まいます。

つまり、出資は貸し付けよりもはるかにリスクが高いのです。

したがって、Ｂ社は、貸し付けをする銀行よりもはるかに事業に
口を出す必要があるのです。

別の言い方をすれば、Ｂ社は、日本市場とＡ社とａ社長を分析した
結果として、（自分が口を出せば）それだけのハイリスクに見合った
ハイリターンを得られると考えたからこそ出資したのです。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[新会社法活用術]　(4)今週号の関連記事
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

○運転資金、増資、借入

　第150号：増資問題は次期体制問題
　http://kei-it.tea-nifty.com/sailing/2006/10/post_9438.html

　第165号：ソフトウェア会社の資金計画
　http://kei-it.tea-nifty.com/sailing/2007/02/post_16cb.html

○連帯保証

　第113号：電車に飛び込む人が後をたたない理由
　http://kei-it.tea-nifty.com/sailing/2006/02/post_0b95.html

　第114号：連帯保証人制度が無ければ大半の中小企業は潰れる
　http://kei-it.tea-nifty.com/sailing/2006/02/post_2a29.html

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

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

乞うご期待！！

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

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

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

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

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

（以下をそのまま転送するだけです。）
---------------------------------------------------
【お勧めメルマガ　ソフトウェア業界　新航海術】
⇒ 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

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コンサル会社
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

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

Ｓ社は某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://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

事業計画はどのようにして生まれるのか

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第182号 2007/6/11
▼ まえがき
▼ [慶2.0]　(1)ColdFusion専門会社とJava専門会社
▼ [慶2.0]　(2)ユーザ企業は何に困っているのだろうか？
▼ [慶2.0]　(3)事業計画はどのようにして生まれるか
▼ [慶2.0]　(4)Java専門会社にも必要な非技術系差別化
▼ 次回以降の予告

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

蒲生嘉達です。

本日は、第180号の話を発展させて、「ユーザ企業は何に困っている
のだろうか？」という問いかけが、慶の事業計画の根底にあるという
お話をします。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[慶2.0]　(1)ColdFusion専門会社とJava専門会社
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

第175号では、需要と専門化の関係について考察しました。

　第175号：需要を見つけて専門化した結果が「食える」
　http://kei-it.tea-nifty.com/sailing/2007/04/post_e83b.html

その話を、ソフトウェア業界に即して、もう少し具体的に説明します。

例えば、ColdFusionが得意な技術者数名でＣ社を立ち上げたとしましょう。

ColdFusionはマイナーですが、一部で高い評価を受けている技術です。

　例：ColdFusionは実は優れた言語ではないかという考察 - 2
　　http://www.onflow.jp/blog/archives/2006/04/coldfusion_2.html

しかし、ColdFusionの仕事の絶対量が少ないため、Ｃ社はColdFusion
専門会社には成り得ないでしょう。

一方、Javaが得意な技術者数名でＪ社を立ち上げたとしましょう。
Ｊ社は、容易にJava専門会社になれます。
Javaによるシステム開発の需要が、安定的に存在するからです。

※今回は、ColdFusionを例にしましたが、PHP、Perl、RubyなどのLL言語
　(Lightweight Language )の場合も、事情はほぼ同じです。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[慶2.0]　(2)ユーザ企業は何に困っているのだろうか？
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

ColdFusionの仕事は安定的に存在しないので、Ｃ社は多言語の仕事も
引き受けざるを得ません。何でも屋あるいは雑食性になるのです。
今回はPHP、次はVBというように・・・。

そうすると、技術的専門化は中途半端なものになります。

しかし、それならＣ社には将来性がないのかというと、そうでは
ありません。
開発技術で専門化できないからこそ、Ｃ社は生き延びるために次の
5点を必死に考えるかもしれません。

(A)顧客や顧客が属している業界が抱える課題は何か

(B)その問題を解決するために自分たちが目指すことは何か

(C)自社のサービスや製品で実現できることは何か

(D)お客様の声を聞くこと

(E)お客様をサポートする体制をどうするか

第181号では、ソフトウェア会社の顧客には３種類あるという
話をしました。
上記(A)～(E)は、その３種類の顧客について、次のことを考え、
その解決策を生み出し、提示することなのです。

・ユーザ企業は何に困っているのだろうか？
・パッケージのユーザは何に困っているのだろうか？
・元請SIerは何に困っているのだろうか？

　第181号：顧客の課題を把握し、それに対する解決策を提供する
　http://kei-it.tea-nifty.com/sailing/2007/06/post_1996.html

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[慶2.0]　(3)事業計画はどのようにして生まれるか
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

これは、新営業マニュアルシリーズで考察した、リレーションシップ
販売やポジショニングとも関連しています。

　第167号：最大の関心事：Do you care about me?
　http://kei-it.tea-nifty.com/sailing/2007/02/do_you_care_abo_0732.html

　第170号：ポジショニング
　http://kei-it.tea-nifty.com/sailing/2007/03/post_b61c.html

しかし、全ての顧客のニーズに応えることは困難なので、限られた
リソース（資金と人材）をどこに割り振るか考えなければなりません。
そこから事業計画が生まれてきます。

また、その割り振りは「高い確率の見込み客( High probability )」
とも関連してきます。

　第166号：(1)高い確率の見込み客( High probability )
　http://kei-it.tea-nifty.com/sailing/2007/02/90_8748.html

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[慶2.0]　(4)Java専門会社の非技術系差別化
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

一方、Java専門会社のＪ社も決して楽ではありません。

オープンな主流派技術で、需要が安定的に存在するということは、
すぐに多数の競合者が現れ、熾烈な競争が発生するということを意味
するからです。
国内だけでなく、中国やインドのオフショア企業とも競争しなければ
なりません。

> ・顧客密着度の低い開発、主流IT系の開発は中国に流出していく。
> ・顧客密着度の高い開発、非主流IT系の開発は日本に残る。
>
> 　( 第49号：中国オフショア開発・日本に残る仕事
> 　http://kei-it.tea-nifty.com/sailing/2004/11/post_dd89.html )

何らかの付加価値を付けなければ、国内外の競合他社に負けてしまいます。

技術的に差別化することも重要ですが、上記(A)～(E)のように非技術面で
差別化することも重要なのです。

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

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

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

乞うご期待！！

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

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

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

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

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

（以下をそのまま転送するだけです。）
---------------------------------------------------
【お勧めメルマガ　ソフトウェア業界　新航海術】
⇒ 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

顧客の課題を把握し、それに対する解決策を提供する

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第181号 2007/6/4
▼ まえがき
▼ [慶2.0]　(1)ユーザ企業
▼ [慶2.0]　(2)パッケージのユーザ
▼ [慶2.0]　(3)顧客の課題を把握し、それに対する解決策を提供する
▼ [慶2.0]　(4)直接取引できるユーザ企業を1社ずつ増やしていく
▼ 次回以降の予告

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

蒲生嘉達です。

慶と慶ネクストの経営理念の第一に「顧客奉仕に最善を尽くす」を
挙げました。

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

本日は、新会社法活用術シリーズはお休みとし、「顧客奉仕に最善を
尽くす」をもう少し明確にイメージできるような話をします。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[慶2.0]　(1)ユーザ企業
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

ソフトウェア会社の顧客は大きく次の３つに分かれます。

・ユーザ企業
・パッケージのユーザ
・元請SIer

ユーザ企業とは、実際にそのシステムをインハウス（社内）で使用
する会社です。
そして、この社内ニーズに応えるためのソフト開発を外注する会社が、
ソフトウェア開発受託会社のお客様となります。

このインハウス開発の性格については、下記の号で詳述しました。

　第103号：請負開発の納品プログラムは「製品」ではない
　http://kei-it.tea-nifty.com/sailing/2005/11/post_5f75.html
　・「インハウス開発」とは
　・インハウス開発が多いのは、米国も同じ

　第106号：パッケージが請負を駆逐することはない
　http://kei-it.tea-nifty.com/sailing/2005/12/post_5362.html
　・パッケージがプログラマの職を奪うことはない
　・プログラマの労働時間のほとんどはインハウス開発

　第145号：取引コスト
　http://kei-it.tea-nifty.com/sailing/2006/09/post_a811.html
　・内製する米国、外注する日本

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[慶2.0]　(2)パッケージのユーザ
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

パッケージについては下記の号で詳述しました。

　第109号：ソフトウェアのコモディティ化が進むということ
　http://kei-it.tea-nifty.com/sailing/2006/01/post_3d3c.html
　・パッケージ・ソフトが置かれている状況
　・安くて気の利いたものしか売れなくなる

　第117号：「のこぎり入れ方パターン計算ソフト」のようなソフトを作るべき
　http://kei-it.tea-nifty.com/sailing/2006/03/post_4a26.html
　・開発コストとユーザの意識の乖離
　・オープンソースが苦手とするソフトを作るべき

　第148号：ウェブサービス時代のソフトウェア会社
　http://kei-it.tea-nifty.com/sailing/2006/10/post_8d27.html
　・ウェブサービス時代のパッケージソフト会社

これらの記事で述べたとおり、従来型のパッケージ開発は、世界的に厳しい
状況にあります。

> 世界のパッケージ・ソフト市場は、急激な低価格化やセキュリティ問題、
> 優れたオープン・ソースの登場など、深刻な問題に直面しつつある。
> 現在、パッケージ・ソフト収入の源泉は、インストール・ベースの
> ライセンス料金から、保守サービス料金へと移っている
> 　　　　（マイケル・クスマノ著「日本のソフトウェア産業の謎」より）

しかし、例えば「会計は会社の心臓」などの出版物も一種の製品です。

　会計は会社の心臓：
　http://kei-it.tea-nifty.com/sailing/2007/01/post_822e.html

常に顧客や顧客が属する業界の問題点を考え、それを解決するという
姿勢があれば、「製品」や「アイデア」は生まれてくるはずだし、
単独ではなく他のサービスと組み合わせていくことも考えられます。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[慶2.0]　(3)顧客の課題を把握し、それに対する解決策を提供する
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

ユーザ企業に対しては、信頼関係を築き、本当の必要性を把握し、
最適なサービスを提供しなければなりません。

　第170号：ポジショニング
　http://kei-it.tea-nifty.com/sailing/2007/03/post_b61c.html
　・ポジショニングは心に対して行うこと
　・顧客の頭の中にあるあなた
　・あなたの振る舞い全てが影響する

「信頼関係を築き、本当の必要性を把握し、最適なサービスを提供する」
ということが最も重要なことであり、請負か準委任か、あるいは、
常駐請負か持ち帰り開発かは、業務の性格や取引コストが決めることです。

顧客の課題を把握し、それに対する解決策を提供することが重要なのです。

　第145号：取引コスト
　http://kei-it.tea-nifty.com/sailing/2006/09/post_a811.html
　・取引コストとは市場を利用するためのコスト
　・ソフトウェア請負契約の取引コスト
　・労働者派遣契約・準委任契約と取引コスト

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[慶2.0]　(4)直接取引できるユーザ企業を1社ずつ増やしていく
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

中小ソフトウェア会社の実際の取引先の大半は、元請SIer、または
二次請け会社です。
しかし、大元はユーザ企業であり、顧客個別のニーズに応えるための
ソフト開発であるという点では、ユーザ企業直の仕事と同じです。

「信頼関係を築き、本当の必要性を把握し、最適なサービスを提供する」
「顧客の課題を把握し、それに対する解決策を提供する」という基本は、
同じなのです。

ソフトウェア業界の元請SIerや二次請け会社にもそれなりの存在意義があり、
簡単には否定できません。

しかし、当然のことながら、ユーザ直の仕事を増やすメリットは
極めて大きいので、慶は直接取引できるユーザ企業を1社ずつ増やして
いくことに真摯に取り組んでいきます。

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

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

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

乞うご期待！！

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

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

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

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

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

（以下をそのまま転送するだけです。）
---------------------------------------------------
【お勧めメルマガ　ソフトウェア業界　新航海術】
⇒ 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/

--------------------------------------------------
発行：
株式会社 慶
　代表取締役 蒲生 嘉達
　y_gamou@kei-ha.co.jp

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