本棚登録 : 
感想 : 
- Amazon.co.jp ・本 (445ページ)
- / ISBN・EAN: 9784478374818
作品紹介・あらすじ
NEC、富士通、日立など品質重視の日本型モデルがもつ致命的弱点、対極にあるマイクロソフトの「同期安定化モデル」の導入法、オラクルやシーベル、12テクノロジーズなどの優良企業が陥った罠、IBMが転身し窮地を脱した「ハイブリッド・ソリューション企業」の強み、SAPやピープルソフトの競争優位、ハイテク・ベンチャーの"キャズム"克服策…市場の徹底分析に基づき、斯界の権威が構築したソフトウエア企業のための初めての競争戦略論。
感想・レビュー・書評
-
コメント0件をすべて表示
-
ちょうど自分がビジネスに関わっていた時代の流れが時系列で捉えられていて、非常によく分かった。
パッケージかSIか含め業態が多岐にわたることもあるが、やはりソフトウェアという特殊性が高いということを再認識した。
しかし、ある時期一世を風靡した日本企業も既に世界に取り残されているのであろうか。
0
-
ソフトウエアに関する企業は
・製品を売る企業
・サービスを提供する企業
・前述の２つを組み合わせた企業
に分けられる。
確かに、サービスで売っていく、と言っていたうちの会社は
転換期をまさに迎えようとしていた訳か、
というのが思い起こされる。
0
-
多くのソフトウェア企業で役員を歴任した著者の経験をもとに、ソフトウェア事業及びサービス事業を分類整理して、その成功のための条件を提示している。
ソフトウェア製品とサービスのミックスの割合はどのようにすべきなのか？ターゲットの設定を考えるうえで想定すべきポイントはなにか？など、学究的な観点と、現場からみた課題を織り交ぜながら詳しく解説する。
やや文章が冗長に感じられるが、さらっと読んでメモを作ってみると、議論の深さがよくわかる。
ただし、
0
-
マイクロソフトの戦略を中心に書かれた本です。
テストについてももちろん書かれています。
基本的な考え方は、「テストをしすぎることはない」ということだ。これは特に、マス・マーケットを対象にソフトウェア製品をつくっている企業に当てはまる。マイクロソフトでさえ、不満をもつ顧客から毎日数百万もの問い合わせがくることには耐えられない。ビル・ゲイツは、九〇年にウィンドウス3.0が数千万本も売れるようになり、あまりにも多くのユーザーが問い合わせてくるようになって、この問題を認識するようになった。マイクロソフトはもっと売上高が小さかった八〇年代に、不良品のリコールで何百万ドルも費やしたことがあった。ゲイツはまた、ワードパーフェクトのように、社員の半分が電話への解答に費やされるようになってしまうことを恐れるようになった。しかしそうはならなかった。この時点からマイクロソフトは、顧客ごとの苦情を解析し、その情報を毎週開発グループに伝達するためのテスト担当者や製品技術者を雇うだけでなく、開発者によるユーザビリティ・テストに多大な努力を払うようになった。唯一の目的は、信頼性、使い勝手、インストールのしやすさ、その他の製品品質にかかわるさまざまな問題を改善することで、膨大な製品サポートに必要なコストを避けることだった。
ここでは、作るときの手戻コストよりも市場導入後のサポートコストに着目していますね。
作るときの問題については、こんなことを書いています。
我々は何十年も前に自動車や他の産業で、開発や生産サイクルの最後になってからテストを行って修正するよりも、品質を継続して製品に「組み込む」ほうが結局は安く済むことを日本企業から学んだ。これは、ウォーターフォール型のプロジェクトで特に当てはまる。
-- snip --
八九年の段階では、マイクロソフトの人々は自分たちの技術によって品質を連続的に組み込んでいると考えていた。品質テストは、ウォーターフォール・プロセスの最後に、技術者にバグを探させて修復させるようなものだ。確かに日本のソフトウェア・ファクトリーではこの方式を実践し、プロジェクト要員のわずか一〇％をテストに割り当てただけで、あの驚異的な品質を達成できたことを認めなければならない。しかし日本では、開発者に対して、自身のテストに多くの時間を割くことと、さらに品質保証スタッフと一緒に設計とコードの検討に参加することを求めていた。同期安定型アプローチでは、設計やコードのレビュー、開発者の相棒であるテスターの利用、デイリー・ビルド、節目ごとに中間目標を置いて安定化を図るといった従来型のベスト・プラクティスを簡単に導入できる。プロジェクトの最後だけでなく全体にわたってバグを探し、修正する機会が与えられる。このアイデアは、プログラマーがペアとなってコードを書き、テスト・ケースを書き続けながら、互いの成果を検討する「エクストリーム・プログラミング」の手法と実に類似している。
筆者がプロセス調査によって得たデータからも、この点が明確に示された。つまり、プロジェクト・チームが統合化テストを早い時期に徹底して行えば行うほど、品質は向上し、プロジェクトは、予定していたスケジュールと予算内に収まるようになる。
日本人って、自分がやっているプロセスを定義したりましてやそれの良い点を論理的に説明することに躊躇するので善い行いが継続されず次々と乗り換えて失敗しているのかなと思いました。
でも、そうして一周してまたTDDのように開発者が自身のテストに多くの時間を割くことが見直されて流行ってくる。
テストに工数の五〇％を掛けているマイクロソフをすごいと思うか、それは開発者がちゃんとテストしていないからしかたなく五〇％も掛けざるを得ない状況なのか？
結果としてマイクロソフトの市場品質は一〇％しかテストに工数を掛けていない日本のソフトウェアプロダクトと比較してどうなのか？？ また、開発スピードや製品のユニークさを比較するとどうなのか？？？
本当は「開発＋テスト」のインプットに対してアウトプットされた機能＋非機能の品質を測る必要があるのでしょうね。
おもしろいなぁ。
0
-
ソフトウェア企業の競争戦略
・米国人はソフトウェア技術を、ソフトウェア企業設立のための手段だと思っている。「まあまあ良質」の製品をつくり、業界標準を打ち立て、その過程で大儲けしようと試みる
・最も健全なソフトウェア企業とは、好況時に利益を生みながら急速に成長する一方で、不況時にも生き残るだけの収益を確保できるように、製品とサービスのバランスがとれた企業
・製品企業が市場ですぐ手に入る果実をあらかた採り終えると、新しい顧客を見つけるのが困難になり、サービス＆メンテナンスを既存顧客に売る方が簡単でコストもかからなくなる
・市場を水平型と垂直型に分けて考えることにより、自社のコアとなる専門性から離れずに、多様化と拡大を図るための青写真を描ける
・製品企業でもアップグレード等により、予想可能な売上げを作ることができる
・プラットフォーム・リーダーは、自社が確立しようとするプラットフォームの周辺で、業界全体を巻き込むようなイノベーションを起こすことに全力を投じるべき
・製品企業はベストセラーによる販売コスト削減を目指すべき。サービス企業は既存顧客基盤を生かした業務を目指すべき
・技術がビジネスに優先しないようにし、顧客ニーズとビジネス戦略を最優先すること
・ソフトウェア工学研究所(SEI)では、プロジェクト組織を五段階の能力成熟度モデル(CMM)に分類している
レベル1[初期段階]：正式なプロジェクト管理が存在しない
レベル2[反復できる段階]：コストや進捗度の計画的レビュー
レベル3[定義された段階]：改善専門の担当を置く
レベル4[管理された段階]：コスト・品質の定量データ分析
レベル5[最適化段階]：分析結果からプロセスを継続的に改善
・定期的に同期化・安定化する開発スタイルがテンポの速い競争市場におけるベスト・プラクティス
・創造的な人材に対して、創造性を方向付けることこそがマネージャの重要な役割。顧客がどんな機能に対価を払うかを考えさせ、人材配置やスケジュールなどのリソースを制限してプレッシャーをかける
・ウォーターフォール型のプロジェクト管理では、競争に適応していくには無理がある
・繰り返しのプロセスを生み出すSEIの概念や、マイクロソフトの哲学である頻繁な同期と周期的な安定化はますます重要になっている。新旧のテクニックを組み合わせることにより、技術や市場の変化に迅速に対応できる
・新しい技術が、どのようにして相当まとまった単位の顧客が対価を払いたいと思うような製品・サービスに変換されうるのかを考える必要がある
・ソフトウェア企業が越えなければならないもう一つのキャズムとは、全く未経験のユーザである。コンピュータを持っていない人々が世界には５０億人以上存在している
0
-
どうやら、うちの会社の社長が会話した方らしい。どんな持論をお持ちなのか、一度読んでみた。内容としては、懐かしいソフトウェア企業の名前がいくつも出てくる。その歴史を振り返りながら、考察して行く形。興味深いのは、ベンチャー企業についても考察をしているのだが、ほとんど知らない企業だけど、とても面白そうなソフトウェアやサービスを提供していたこと。結論自体にはあまり新鮮味を感じなかったけれど、振り返りは重要だな〜と感じる。結局、サービス提供を考えざるを得ないのかな、我が社は。(^^;;
0
-
SaaSをはじめとするクラウドサービスが市場にじわじわと浸透する中、その根幹をなすソフトウェアで事業を展開してきた企業が、今後どのような戦略で利益を確保していくかという点は、非常に興味深いテーマである。クラウドの台頭により、ソフトビジネスが企業の業績にいっそう直結するようになった今だからこそ、同ビジネスの歴史を振り返る必要があると思い、本書を手に取った。
日本企業は、ソフトを技術とビジネスの両面からとらえる意識を高めないといけない。ちょ者のマイケル・A・クスマノ氏はこう提言する、これまでは技術に磨きをかけ、新たな機能を追加した新版のソフトを提供すれば、保守サービスで利益を確保できた。だがソフトが日用品化する中、技術面での差別化が難しくなっている。今後はソフトでどう稼ぐかという戦略、マーケティング施策が今まで以上に大切になる。
ソフトウェア企業の生命線は「製品とサービスを同時に販売し、収益の柱を複数持つこと」にほかならない。プロダクトアウトで製品を出せば儲かる時代は終わり、顧客企業と密に関係を築きながら、サービスで継続的に利益を出すモデルが求められる。最近のOracle・IBM間のDBMSの乗り換えキャンペーン合戦を見ると、サービスで長くもうけたいとする両者の思惑を感じ取れる。かつて一世を風靡したソフト・ハード企業は今、サービスを軸とした企業への路線変更に活路を見いだしている。
「経営者、プログラマー、起業家は技術製品をどう構築し、パッケージとして価格付けをすると人々に購入意欲を抱かせ、結果として利益を得られるかを知る必要がある」（クスマノ氏）。「パッケージ」を「クラウドサービス」に置き換えても、この原則は廃れない。単なるソフトを作る企業、ではだめ。技術と市場のニーズの変化を予期しながら、矢継ぎ早にサービスを出し、顧客との関係を深めながらサービスを継続的に利用してもらう――。これこそがソフトウェア企業の成功モデルなのだと強く感じた。
「重要なのは、技術がいかに高度であるかでも、市場の先駆者であるかでもなく、自社が市場リーダーになれるポジションにいるかどうか。自社製品はユーザーにもっとも普通に使用される製品たり得るかということである」（クスマノ氏）
Microsoftのソフトウェア戦略はこの原則を如実に示している。同社は技術や製品へのこだわりもさることながら、戦略や利益の出し方、市場の支配の仕方に注力していた。もちろん独占禁止法などの観点から考えてすべてが正しいとはいえないものの、ソフトウェア企業の戦略や位置付けにおいては、Microsoftから学べることは多いのではないか。
主力事業をハードからサービスに変えたIBMの戦略も理解しておいて損はない。メインフレームを中心としたハード一辺倒の戦略をかなぐり捨て、ソフトとサービスを併せることで、収益力の高い企業として復活を遂げた。2010年4月、日本IBMはIBM ビジネスコンサルティングサービスと統合する。屋台骨であるサービスの強化が狙いであり、ソフトウェアの歴史が示す成功の方程式をきちんと踏襲していることが興味深い。
MicrosoftとIBMに共通するのは、製品の更新と機能拡張のためのサービス・メンテナンス契約が売り上げに直結するという、ソフトウェア企業のゴールを追求する姿勢だ。
クラウド元年と評される2010年。ソフトウェアのクラウド化は、あらゆるIT企業にとって避けられないシフトである。ソフトウェア事業での成功を夢見るあらゆる企業にとって、過去の歴史を学び、企業の特性や対象とする市場を認識し、明確な成長戦略を描くことが求められる。こうした姿勢は、競合がひしめき、コモディティー化の波が押し寄せるソフトウェア市場で生き残るための最良の作法なのである。
0
マイケル・A.クスマノの作品
この本を読んでいる人は、こんな本も本棚に登録しています。
