« PMBOK3とPMBOK2000の違い | トップページ | 委譲できるのは権限までであり、責任は分担できない »

「ソフトウェア企業の競争戦略」読書感想文1

この企業の社畜として、自己の立ち位置を再確認するために読んだのだが、結局のところ、ど真ん中の一冊になった。「ソフトウェア企業の競争戦略」を紹介していただいたこの記事に感謝。好川さん、ありがとうございます。ソフトウェアでメシを食べている人は必読だろうなぁ…。理由は次の通り。

ソフトウェア・ビジネスが一般のビジネスと違いが無いのであれば、本など書く必要がない。この本は「ビジネス」としてみた場合の「ソフトウェア企業」を冷徹な視線で語っている。ソフトウェア・ビジネスとして成立させるために必要なことは「製品とサービスのハイブリット形態」なり。製品は市場に参入し、シェアを確保するため、サービスは恒常的な収入を得て、好不況の波を越えていくために必要。マイクロソフト、IBM、オラクル、SAP、シーベル、i2テクノロジーズの例を挙げて、その必要性を詳細に語っている。

世界と比較して、日本のプログラマは優秀か? 答えはYes[注1]。日本のプログラマの品質は、世界最高の水準か、それ以上だという。プログラマは優秀なのに、日本のソフトウェアビジネスがパっとしない理由も書いてある。それは品質重視の工場型モデルを(相も変わらず)採用しているからにほかならない。「良いものを作れば売れる」主義を信奉するあまり、ビジネスの本質から離れてしまっているらしい。

例えば欧州企業にとってソフトウェアは「科学」として扱われる。コンピュータサイエンスとしての「ソフトウェア・ビジネス」であるがゆえに、形式的手法やオブジェクト指向分析・設計手法が重視される。また、米国企業にとってソフトウェアは「ビジネス」そのものとして扱われる。会社をつくって「まぁまぁ良質」の製品を作り、業界標準を打ち立て、その過程で大儲けしようとたくらむ。

しかし、日本企業にとってソフトウェアとは「工場出荷製品」そのもの。文字通り「ソフトウェア・ファクトリー」を目指している。標準化された設計開発工程に則り、仕様からほとんどブレない製品を粛々と出荷することを随一としている。「良いものを作れば必ず売れる」信者の松下イズムが蔓延しているため、ソフトウェア・ビジネスの最もメジャーな課題「何が欲しいのか分かっていない顧客に売る」ビジネス視点が抜けている。

「ソフトウェア企業を創って世界のルールを変えてやろう、その過程で大儲けしてやろう」ことがヤれるのは、米国だけなり。でも、沸騰しまくっている米国でヤっていけるのかも、やっぱり書いてある(つづく)

--

[注1]なにを根拠に「世界」というか? 筆者の研究(っつーかフィールドワーク)は以下の企業を対象としたらしい。日本、米国、欧州、インドの主なソフトウェア企業だろう(もちろん漏れているのも多々ある)。


 マイクロソフト
 IBM
 NEC
 富士通
 日立
 オラクル
 SAP
 シーベル
 i2テクノロジーズ
 ビジネスオブジェクツ
 タタ


このエントリーをはてなブックマークに追加

|

« PMBOK3とPMBOK2000の違い | トップページ | 委譲できるのは権限までであり、責任は分担できない »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 「ソフトウェア企業の競争戦略」読書感想文1:

» [book][biz]ソフトウェア企業の競争戦略 via プログラマの思索 [PM見習いの読書日記]
http://forza.cocolog-nifty.com/blog/2005/01/post_4.html 上記で面白そうな本が紹介されていた。あきぴーさん... [続きを読む]

受信: 2005.01.17 16:15

» [メモ]ソフトウェア企業の競争戦略 [この道はいつか来た道... REBOOTED]
「ソフトウェア企業の競争戦略」読書感想文1 〜via marsのメモ〜... [続きを読む]

受信: 2005.01.20 15:09

» ソフトウェア産業 [未来のいつか/hyoshiokの日記]
「満足せる豚。眠たげなポチ。」さんhttp://blog.livedoor.jp/zep716/archives/12716635.html経由で「わたしが知ら... [続きを読む]

受信: 2005.03.21 23:07

» 正しいものを作ることと正しくものを作ること [未来のいつか/hyoshiokの日記]
プログラムを作ることはそれほど難しいことではない。それを製品にしてビジネスとすることは非常に難しい。「正しくものを作ること」より「正しいものを作ること」のほうがはるかに難しいのである。 いわゆるウォーターフォールモデルでは開発プロセスの初期に仕様を固定してそれを「正しく作る」事に注力する。1千行あたりのバグ数とか月当たりの生産コード行数などが、いかに「正しくものを作ったか」の生産性の指標になる。ソフトウェアファクトリとか日本のソフトウェア産業の得意とするところである。開発プロセスの初期段階で仕様を固... [続きを読む]

受信: 2005.05.10 21:12

« PMBOK3とPMBOK2000の違い | トップページ | 委譲できるのは権限までであり、責任は分担できない »