mhattaによる
2007年06月09日 15時30分の掲載
そういう問題なのかしら部門より。
そういう問題なのかしら部門より。
Sakkanen 曰く、
ITmediaの大迫正治 REPEDANT BLOGに 「中毒性」ある受託開発がソフトウェアベンチャーの躍進を阻むというエントリがある。 日本のソフトウェア産業では顧客ニーズに沿ったオーダーメイドのシステムを逐次的に開発することが主流と なっていて、製造業よりもサービス業に分類されることが多い、とはよく言われることだが、 大迫氏は、そうした受託開発では技術や人材、資金が蓄積しないということをそれぞれに理由を付けながら 主張している。
確かに受託開発だとノウハウ等は上層にどんどん吸い上げられがちになるし、 資金に関しても自転車操業に必要な分しか投下されてこないので、研究開発に投資するのは 難しくなる。目先のキャッシュに目を奪われて新しいモノを作りだすチャンスを逃したという 経験がある方も多いのではないだろうか。何となく考えさせられる記事である。
関連ストーリー
ベンチャー起業は若き天才だけのものではない? 68 コメント
この議論は賞味期限が過ぎたので、保存されている。
新たにコメントを書くことはできない。
その通り、それはみんな知っている。 (スコア:5, 興味深い)
今は逆に受託のチャネルで知ったニーズの自社商品化を進めています。
基幹となる技術やモノ (スコア:4, すばらしい洞察)
ただ、普通の受託に必要なのはパワーがベースですのでそれでは蓄積がありません。
大雑把に言うと受託先がどこに変わろうが大差無いのがパワーベースの受託。
ここ、という限定が発生するのが技術ベースの受託かな？
整理してみよう (スコア:2, 興味深い)
コメント読んでて気になった点が一つ。
ベンチャーには２種類あって、それがごっちゃになってる気がする。
わかりやすくする為にカテゴライズしてみます。
アメリカ型ベンチャーと日本型ベンチャー。
(先に断って起きますが、実際にアメリカにはアメリカ型しかないとか、
そういう意味ではなくて、イメージを元に便宜上分けただけです)
まずアメリカ型と言うのは、初めに製品なりサービスなりシステムなりの“商品”があって、
それを売るために会社をはじめるパターン。
それに対して日本型は、かたちある“商品”ではなくて技術を売るために、
もしくは、独自の技術なり知識を売るパターン。
アメリカ型って言うのは、“商品”を売る所から始めるから、
もし売れなきゃ終わり。その意味では誰かが書いてたように“博打”以外の何ものでもない。
しかも最初に上手く行ったからと言って、何時まで続くかわからない不安定さもある。
アメリカでベンチャーがどれくらいあるかわからないけど、
ほとんどは消えていったり、最初は上手くいっても大手に買収されたり(これはこれで成功かもしれないが)、
後から出てきたモノに敗北し消えていったり。
それに対して日本型は、そもそも商品がないから独自技術を売るとか、
自社開発とかってのとは、最初の創業時から発想が違うように思う。
あくまで、必要としている“人たち”から仕事を受けないと、仕事がないわけで。
ニーズを掴むにしろ、より良いものを作るにしろ、
発想は“発明家”ではなくて、“技術者”なんじゃなかろうか？
中には優秀なプログラマーを多数持ち、
どこにも負けない仕事を請け負う会社は有り得ても、
アメリカ型の会社とは、そもそもの生い立ちが違うからアメリカ型の会社と比べても意味ないような。
だからどちらが良い悪いじゃなくて、種類が違うと。
ただ、こうして考えてみると、
日本型って、町の工務店とか電気屋さんとかって感じかな？って思う。
大きくなればチェーン店に発展することも可能だけど、
そもそも日本型のベンチャーで技術に重きを置くような会社は、
自分の技術に自信がある人が、他人の下で働きたくないとか、
自分の得意とする分野に特化してより専門的な事をしたいとかって理由で
会社始めるんだろうし。
それに日本型のほうが仕事がある限り(受託している限り)、
金銭的には安定しているし。
もっとも、技術は二の次で、ただ単に会社起こしたかっただけって会社も多いけど・・・
親コメント
Re:整理してみよう (スコア:2, 興味深い)
経営方針の違いなんで、どっちが良いとか悪いとかはありません。また、スモールビジネスで始めて途中からベンチャーに切り替える会社もあります。ただ、ベンチャーを目標にしてるなら最初からベンチャーでスタートした方が良いと、起業経験者も投資家も言いますね。
参考：http://blog.japan.cnet.com/umeda/archives/001657.html
親コメント
受託開発以外の選択肢があるのか (スコア:3, すばらしい洞察)
ちゃんと売れるようにするには莫大な投資が必要で、
回収にも受託開発以上の時間がかかると思います。
資金の無いベンチャーが選択できる方法ではないでしょう。
ソフトウェアベンチャーが受託じゃない方法で成功するには、
一人か二人くらいのスーパープログラマだけで開発して
販売するような方法じゃないと難しいんじゃないでしょうかね。
Re:受託開発以外の選択肢があるのか (スコア:2)
あったわけだし、受託だからといってソフトウェアベンチャーが育たない
とは言えないだろう。
> 一人か二人くらいのスーパープログラマだけで開発
あと必要なのは、天才詐欺師的なマーケティングが
できる人物がいる（兼任でも構わないが）ことも
ポイントじゃないだろうか。
親コメント
Re:受託開発以外の選択肢があるのか (スコア:2, 参考になる)
実態としてはそのとおりなのですが、マイクロソフトが権利を有するままで IBM に DOS を提供する契約を結んだのですよね。
普通の受託なら買取でおわりだろうに、マイクロソフトは複製ごとに対価を受け取る契約に成功した。
> # IBMから話がなければMS-DOSは存在しないし、各社がMS-DOSを採用もしなかった。
マイクロソフトが権利を有する自社商品として主張できたから、IBM DOS互換の MS DOS を他社に販売することができたわけです。
契約は重要ですね。
親コメント
Re:受託開発以外の選択肢があるのか (スコア:2, 参考になる)
> ストックオプションが給与扱いで高い税金のかかる日本では、
> 極めてハイリスク=ローリターンの博打です。
ストックオプションでのゲインに対する課税は原則と税制適格とに分かれます。原則はゲインが総合課税され、最高税率は所得税40%、住民税等13%、合計53%。税制適格の方は分離課税で所得税7%、住民税等が3%で合計10%。「ストックオプションが給与扱いで高い税金のかかる」とは総合課税を考えて言っているんだと思うけど、ストックオプションのゲインが全て総合課税されると言うのは間違いですな。
大体、税金で９割９分持って行かれるならまだしも、総合課税の場合ですら約半分。ストックオプションがすべからくローリターンになってしまう程には、激烈に高い税率とも言えないんです。そして税金で半分持って行かれる場合とは、相当の所得がストックオプションによって発生した場合、つまりハイリターンである状態ですね。つまり、「ストックオプションが給与扱いで高い税金のかかる日本では、極めてハイリスク=ローリターンの博打です」はそれ自体が当初から矛盾している事になるでしょうね。
親コメント
開発じゃなくて (スコア:3, すばらしい洞察)
いや、正しくは受託サービスか?
開発と捉えるから、標題の様な文になってしまうのでは?
それはベンチャー企業なのか? (スコア:3, すばらしい洞察)
受託開発はリスクをとらない代わりに収益も低いって業態なんだから、ベンチャーとは正反対の方向だよね。そもそも受託開発してる時点でその企業はベンチャー企業ではなかったってことでしょう。
別にソフトウェアに限った話ではないよね
受託開発できるならまだマシでは (スコア:2, 参考になる)
ITサービス企業の実体が「派遣会社」だったりしますから、
・受託開発のリソースすらない
・派遣で社内に技術力が蓄積できない
・人出ししかやってないので社員にどんなスキルがあるか把握してない
・社員に人売り管理以外のキャリアパスを提示することもできない
というのが少なからずあって、受託よりもさらにチャリンカーな経営をしている企業も多いんじゃないでしょうか。
まぁ、受託でも人月を見積に載せてビジネスしてれば派遣ビジネスと大差ないんですけどね。
受託開発 (スコア:1)
十分、技術や人材、資金が蓄積出来ると思いますが。
なぜ受託開発が悪者に (スコア:1)
個人的には、参照記事が主張するように「受託開発」に問題があるのだとは思えません。
なんだか記事全体を通して、「受託開発」が、顧客から「言われたことだけを言われた通りに作る」モノとしか捉えないように誘導しているように読めます。
ただ、現状がそんなものになっているだろう、という意見であればそれに反対するものではありません…
「受託開発をうまくやって自社開発に弾みをつけるという構造になっていない」という主張については、現状の業界全般に当て嵌まる意見だと思うので異を唱えるものではありませんが、「それができる企業は自社開発を最初から行うはず」という意見には賛同できかねる、というか、多分、自社開発をやってもやっても失敗している企業が殆どなんだろうと思います。
これは、自社開発には、受託開発をすることとはまた別の難しさがあるからです。何しろ、市場が何を欲しがっているのかを見極めて、その要求を満たした上で、競合他社よりも更に魅力的なプロダクトをタイムリーにリリースしていかなければならない訳ですから。「いつまでにこれが欲しい」と言ってくれる受託開発とは全然違います。
（受託のときには、この「これが欲しい」を、実は顧客も良く判っていないので難しい訳ですが…）
だからと言って、受託開発が「凡庸なもの」な訳ではありません。受託した案件について、数多ある実現方法のうちの最適なソリューションをできるだけ効率的に提供するのは簡単なことではありませんし、汎用製品と同等かそれ以上に保守性や拡張、柔軟性なども考慮しなければ、後のサポートに大きく響いてしまいます。そのためには、標準的で将来性もあり、ときには先進的な技術基盤を適用しなければならないこともあります。
この辺りの根っこは、自社開発だろうと受託開発であろうと、多少の影響度の違いはあるものの、本質的には変わらないと思うのですが。
大迫氏の記事では、受託開発では「技術、人材、資金」が蓄積されないと、その理由まで書かれていますが、どれも受託開発が要因ではない様に思います。「受託開発」でなく「自社開発」だとしても、これらの問題は解決されないのではないでしょうか。
どちらかというと、記事でも再三書かれている「重層下請け構造」の問題ではないしょうか。それもその構造自体が問題だと言い切れるものなのではなく、その構造の運用に問題がある様に思います。
と言い切ることもできないと思っています。
「受託開発」だと挑戦が思う様にできず、イノベーションが生まれ難いという見方はあるかもしれません。しかしそれも構造次第、工夫次第だと思っています。まあ財務や経理の問題（費用配分とか）があるので、単純には行かないのかもしれません（この辺りはよく判りません。ごめんなさい）が、大抵の大手 SIer では、「受託開発」に自社開発のパッケージなどを絡めることで工夫しているのではないでしょうか。
こういう例を書いてしまうと、「じゃ、やっぱり受託開発じゃできないんじゃん」と言われてしまいそうですね。顧客からの資金調達であることについての問題が解決できれば他の方法でも構わないのですが、私にはちょっと思いつけなかったもので。
ちょっと異なる観点として、ソフトウェア産業でハイリターンを望むとき、法人顧客向けのビジネス展開を行うことが近道と考えられ、それにより、重厚なシステム開発を大手 SIer がソフトハウスを従えて作るという重層構造を生み出している、とか、自社開発製品が売れないので受託開発に頼った資金繰りになってしまい、それが悪循環を生んでいる、などという捉え方はあると思っていて、そこが問題だと言われているならその通りだと思うのですが。
Re:受託開発は使い捨て (スコア:2, すばらしい洞察)
更に、業務を刷新するような提案は「業務の現場」から徹底的な拒否に逢います。
つまるところ、同業他社の業務と今のプロジェクトでのソレとは大同小異で一度いずれかの業務知識を得てしまえばソレだけで充分で新しい発想など必要とされないのです。
むしろ、大同小異な各社業務実態の小さな違いがシステム化の困難と運用上の問題を大量に惹き起こすわけで、そのリスクを分散する手立てとして費用の持ち出しや残業代不払いなどが常態化しやすくなっているわけです。
技術やノウハウが蓄積しているとしても、それはシステム化による業務効率化を言いながらナニも変わらないことを望むユーザとべったりになることでしかないでしょう。
そして、開発リスクだけが下請けに廻され続ける以上、資本の蓄積もすすまないでしょう。
高い技術がある者と既に確立された業態という古いビジネスの実態への深い理解を持つ者が起業するのであれば、既存の商売とは異なるナニかを始めるべきでしょう。それこそ、ベンチャーなわけですし。
そのような幸せな邂逅からはじまらなかった場合は、“ほしがりユーザのシステム開発という無駄遣い”を淡々と介護してあげるといった姿勢で対処するほかはないのではないでしょうか？
技術の進歩、既存ビジネスの革新、資本の蓄積……システム開発という業態からはかけ離れたものなのだと、認識すべきなのかもしれません。
これからのシステム開発は、介護ビジネスや終末医療のような「業務の改善も効率化ももはややり尽くしたに等しい、古いビジネスを延命させてあげる」スタンスを執るのが順当のように、絶望半分な気持ちで思っています。
親コメント
お金の集め方を知らない人がおおいから (スコア:1)
Re:無理もない (スコア:1, おもしろおかしい)
親コメント