| Bottom | Home | Article | Bookshelf | Keyword | Author | Oxymoron |

The Business of Software

What every manager, programmer and entrepreneur
must know to thrive and survive in good times and bad.
Cat: ICT
Pub: 2004
#0625b
06715u/18125r

Michael A. Cusumano

Title
 The Business of Software ソフトウェアのビジネス
Subtitle
 What every manager, programmer and entrepreneur must know to thrive and survive in good times and bad. マネジャー・プログラマ・起業家が好不況にかかわらず成長し生き延びるために
Author
 Michael A. Cusumano

マイケル・Ａ・クスマノ
Published

2004

 2004年
Index
  1. Preface:
  2. Business of software:
  3. Strategy for SW companies:
  4. How SW became a business:
  5. Best pracitices in SW development:
  6. The essence of synch & stabilize:
  7. SW entrepreneurship:
  8. Start-up case studies:
  9. Ideal vs. realistic SW business:
  1. 序:
  2. ソフトウェアビジネス:
  3. ソフトウェア企業の戦略:
  4. ソフトウェアビジネスへの道:
  5. 開発のベストプラクティス:
  6. 同期･安定化のプロセス:
  7. ソフトウェア起業家精神:
  8. スタートアップ企業のケース:
  9. ソフトウェアビジネスの理想と現実:
Why?
  • This is a textbook of computer software industry written by Michael Cusumano, Prof. of MIT, which describes features of software, concept and challenges of software business.
  • Also this book describes not only the present themes of software industry, but covers its history and prospect of the future. Somehow this book looks like a puzzle-solver of of so many whys in the software industry using various data.
  • これはMichael Cusumano MIT教授によるコンピュータ・ソフトウェアの教科書で、ソフトウェアの特徴、ソフトウェア・ビジネスの概念と挑戦を描いている。
  • またソフトウェア産業の現在の課題だけでなく、その歴史と未来への展望を述べている。ともかく本書はソフトウェア業界の多くのなぜを種々のデータを用いて謎解きをしているように見える。
Tag

; Big niche; Customer segment; Divide & conquer; Extreme Programming (XP); Focus creativity; Lots of change w minimum impact; Industry 5 forces; NATO report; Next chasm; Novice user; Overlapping functions; R&D cost; SW companies segmentation; SW factory; The kiss of death; Three business models;

Summary
Remarks

>Top 0. Preface:

  • My primary concerns are with strategy and business models, a historical look at software entrepreneurship, best practices in managing software development, and the do's and don's of founding a software start-up.

0. 序:

  • 本書の主な関心事は、戦略とビジネス・モデル、ソフトウェアの起業の歴史、ソフトウェア開発の管理におけるベストプラクティス、ソフトウェアを起業をする上のすべきこととすべきでないことについてである。

>Top 1. Business of software:

  • Business of software:
    • If the software business were like other businesses, there would be no need for this book. But software is not like other businesses:
    • 99% gross profit margins from their product sales.
    • become services or hybrid companies (providing some customization of product features and technical services such as system integration and maintenance)
    • ten or twentyfold difference in productivity between best employee and worst one.
    • people consider themselves artists rather than scientists or engineers.
    • customers locked in to a particular vendor.
    • Software becomes whatever function or application it addresses.
    • Software business can be like having a license to print money.
    • Software companies need to sell both products and services to maintain a successful business.
    • The revenue of software companies increasingly consist of sales of services and maintenance upgrade to existing customers, rather than new product sales to new customers.
  • Technology vs. Management:
    • Managing software technology well should imply knowing how to go through the phases from design to delivery at a cost that is less than the revenues generated from selling the resulting product or service. Marketing and sale and financial discipline become as important as anything else in the software business.

1. ソフトウェアのビジネス:

  • ソフトウェア・ビジネス
    • ソフトウェア・ビジネスが他のビジネスと変わる所がなければ、それについてこの本を書く必要はない。しかし、ソフトウェア・ビジネスは他とは違う。
    • 製品売上に対する利益幅が99%に達する。
    • 製品企業がいつの間にかサービス企業やハイブリッド企業 (SIやメンテナンスといった製品のカスタマイズやサービスを提供する企業) に変貌してしまう。
    • 最良の社員と最悪の社員の生産性の各社は10-20倍もある。
    • 自分は科学者や擬樹種者というより芸術家と思っている。
    • 顧客は特定メーカにロックインされてしまう。
    • ソフトウェアでは、必要や機能やアプリケーションなどどんなものも開発できる。
    • ソフトウェア・ビジネスはあたかも紙幣を印刷する権利を得たかのようになり得る。
    • ソフトウェア企業にとっての事業成功のカギは、製品をサービスの両方を販売する必要がある。
    • ソフトウェア企業の収入は、新製品を新規顧客に販売するより、既存顧客のサービスはアップグレード版を販売する割合が増えていく。
  • 技術対マネジメント:
    • ソフトウェア技術の管理とは、製品とサービスが生み出す利益より設計から発送までのコストを低く抑えながら、いかに利益を実現するかを知ることである。マーケティング、販売、財務管理は、その他技術と同様に重要である。

>Top Japanese software industry:

    • Since 1969, the major Japanese compute manufacturers had been concentrating their people with software expertise in relatively large facilities and had been trying to apply the same disciplined approach to software production and quality management as they had done in hard manufacturing businesses.
    • The Japanese emphasized incremental innovation in feature design, standardized development techniques, common training programs, reusable component libraries, computer-aided support tools, rigorous quality assurance techniques, and statistical data to manage projects. The Japanese also tended to staff projects with a combination of experienced people and relative low-skilled programmers.
    • But there was no dominant global software player likely to come from Japan, except perhaps in niches such as the video game industry.
  • The Europeans:
    • Too many European companies tend to treat software as a science. The Europeans have excellent university-level education in computer science, especially programming languages and principles of design.
    • SAP (German), Business Objects (French), WWW (Tim Berners-Lee, Englishman)
    • European software producers place more attention on achieving elegance in software design than on shipping products for mass markets.
  • The Japanese:
    • The largest Japanese producers of software mainly write code to sell hardware and services, as IBM has done for decades. The country has also underinvested in basic research and higher education. Japan has had relatively weak university training in computers and information systems.
    • Accordingly, Fujitsu, Hitachi, NEC, Toshiba, and NTT have had to train most of their own people on the job and have ended up treating software development mainly as a problem in production.
    • >Top The software factories were and remain good at cranking out multiple versions of custom or semi-custom application that follow standardized design patterns and evolve little from their original parameters. But it doesn't change the world or make anybody a billionaire.　

日本のソフトウェア産業:

    • 1969年以来、日本の主要なコンピュータメーカはソフトウェアの専門家を大きな施設に集め、ハードウェア製造と同様に統制のとれたアプローチをソフトウェアの製造と品質管理に適用しようとしてきた
    • 日本人は機能設計、標準化された開発技術、共通訓練プログラム、再利用可能なコンポーネント・ライブラリ、支援ツール、厳格な品質管理手法、そしてプロジェクト管理のための統計データに関して、段階的なイノベーションを強調した。また日本人は熟練者と初心者を組み合わせてプロジェクトに配置する傾向がある。
    • しかし日本からグローバルな支配力をもつようなソフトウェア・プレーヤーが出現しそうなのは、唯一ビデオ・ゲーム産業のようなニッチ分野だけだった。
  • 欧州企業:
    • 欧州企業のあまりにも多くが、ソフトウェアを科学として扱う傾向にある。欧州にはコンピュータ科学の分野、特にプログラミング言語と設計原理の分野で非常に優れた大学教育を行っている。
    • SAP (独)、Business Objects (仏)、 WWW (Tim Berners-Lee, 英国人)
    • 欧州のソフトウェア起業は、マスマーケットに製品を出荷するより、ソフトウェア設計における美を追究することに注力している。
  • 日本企業:
    • 日本の大企業は、主にハードウェアやサービスを販売するためにソフトウェアを書いているのであり、これはIBMが数十年に亘り行ってきた道である。日本は、基礎研究や大学教育に対して十分な投資を行っていない。コンピュータや情報システムに対して比較的貧弱な大学教育しか行って来なかった。
    • 従って、富士通、日立、NEC、東芝、NTTなどは社員の大部分をOJTで教育しなければならず、その結果、ソフトウェア開発は主に製造過程での課題の一つとして扱うようになった。
    • ソフトウェア・ファクトリーという方式は、標準化された設計パターンに従い、元の条件からほとんど変更したカスタムまたはセミカスタム・アプリケーションの複数のバージョンを大量生産するのに向いており、今も機能している。しかしそれが世界を変えることはないし、誰も大富豪になることもない。

 

>Top US SW industry:

    • People in US are unmatched in treating software as a business. They see software technology as a vehicle for crating dedicated software companies that produce at least good-enough products and try to set industry standards as well as make lots of money in the process.
  • Business Objects:
    • Liautaud and Denis Payre had founded Business Objects in Aug. 1990.
    • >Top Big niche:
      Liautaud recalled that from the beginning, Business objects were after a big "horizontal niche" rather than a "vertical" market. It attempted to "cross the chasm" separately early adopters from mainstream users by riding on the backs of Oracle customers. ("Big niche")
    • From nothing in 1990 to more than $60M in revenues by 1995.
    • Business Objects did not do it all alone. The company reached an agreement in 1994 for IBM to resell its core product bundled with IBM's data-warehousing package as well as some industry-targeted vertical solutions.
  • i2 Technologies:
    • Sanjiv Sidhu and Ken Sharma founded i2 Technologies in 1988. The firm quickly became known worldwide for leading-edge software products that analyzed and solved problems in factory planning, logistics, and supply-chain management.
    • They positioned i2's product not as a stand-alone offering but primarily as a complement to existing MRP (Material Requirements Planning) and ERP (Enterprise Resource Planning) used by large manufacturing companies.
    • Then the market explosion happened. The Internet suddenly provided a means to link suppliers to produces over easy Web connections.
    • Because the year 2000 was also approaching, companies allocated additional Y2K budgets to buy new software to streamline planning and procurement.
    • And then the bubble burst. i2's stock price had gone from $20 in 1996, when the company first went public, to $110 in 2000, and then to 41 cents in Oct. 2002.
    • Companies facing once-in-a-century opportunities like the Internet and Y2K rarely have the time to confront the basic organizational, process, personnel, and product problems that inevitably emerge as a company passed beyond the start-up stage.
    • When times are good, it is easy for software products companies to grow revenues, perhaps to a billion dollars or more within a few short years. But when times are bad, revenues can collapse like a stone falling to earth because customers can simply stop buying new products.

米国のソフト企業:

    • 米国人ほどソフトウェアをビジネスとして捉えている国民はいない。米国人は、ソフトウェア技術をソフトウェア企業設立のために手段と考えている。会社を作ってまあ良質な製品を作り、業界標準を打ち立てて、その過程で大儲けしようというのである。
  • ビジネス・オブジェクツ社:
    • リオトーとデニス・パイルは1990年8月にビジネス・オブジェクツ社を設立した。
    • ビッグニッチ:
      リオトー曰く、ビジネス・オブジェクツ社は初めから垂直市場よりむしろ市場規模の大きな水平方向にニッチを狙っていた。それはオラクルの顧客に販売することで、先駆者と主流市場のユーザを隔てるキャズム (深い溝)を超えようとする試みであった。(ビッグ・ニッチ)
    • 1990年のゼロから95年には6000万ドルを売り上げた。
    • ビジネス・オブジェクトは自社だけでやり遂げたのではない。1994年にはIBMと提携し、IBMのデータウェアハウス用パッケージや、特定業界向けソリューションと一緒にでコア製品の再販を行った。
  • i2テクノロジーズ社:
    • サンジブ・シドゥとケン・シャーマは1988年にi2テクノロジーズ社を設立した。同社は工場設計、流通、サプライチェーン・マネジメントに係る課題を分析・解決する先進のソフトウェアで、いち早く世界に知られるようになった。
    • 二人は、i2を単独の製品ではなく、主に大手メーカですでに使用されているMRPとERPの補完的なソフトウェアと位置づけた。
    • そして、市場の爆発が起こった。インターネットは突然、Web接続を通じてサプライヤーとメーカをつなぐ簡便な手段を提供した。
    • また2000年問題(Y2K)が近づいていたので、企業は計画と調達の合理化の予算を追加した。
    • そしてバブルがはじけた。i2の株価は1996年公開当初の$20から2000年に$110に上昇した後、2002年10月に41セントに下落した。
    • インターネットやY2Kといった100年に一度の場面に遭遇した企業のほとんどは、起業の段階を過ぎると必然的に表面化する組織やプロセス、人事、製品に関する問題に対応する時間がほとんどないという状態だった。
    • 好況のときは、ソフトウェア製品企業は数年以内に売上$1B以上に成長するのは容易である。しかし不況のときは、顧客が単に新規製品の購入を控えるだけで、売上は落下する石のように崩れ落ちる。

>Top 2. Strategy for software companies:

  • Basic questions:
    • a products company or a services company?
    • to sell individuals or enterprises, or to mass or niche markets?
    • how horizontal (broad) or vertical (specialized) is your product or service?
    • recurring revenue stream to endure in good times and bad?
    • to be a leader, follower, or complementor?
    • to target mainstream customers, or have a plan to avoid the chasm?
    • character of your company?
  • >Top Three business models for software companies:
  • productservice
  • Software product sales are subject to buyers just saying no, it is now apparent that most healthy software companies need to have a balance of product and service revenues to survive in bad times and to grow rapidly in good times.

2. ソフトウェア企業の戦略:

  • 基本的な質問:
    • 製品企業かサービス企業か
    • ターゲットは個人か法人か、マス市場かニッチ市場か
    • 好不況に関わりなく継続的な収入源はあるか
    • 主流市場の顧客狙いかキャズムを回避するのか
    • 目指すのはリーダーか、フォロワーか、補完者か
    • 会社の特徴は何か
  • <左図> ソフトウェア企業の３つのビジネスモデル:
    • ソフトウェア製品の売上は買い手がノーと言うかにかっていることを考慮すると、健全なソフトウェア企業とは、好況時には一方で成長し、不況時にも生き残れるようなバランスのとれた企業である。
  • <左図> 法人向けソフト売上の内訳:
    • 企業向けソフトウェアがそのライフサイクルで得られる売上の70%以上はサービス＆メインテナンスである。
    • メンテナンスは銀行サービス的で、ソフトウェア・ライセンス販売は印刷業的
    • サービス収入は、結局、新製品売上の上下に遅行しながらそれに連動する。

>Top Revenue breakdown for an enterprise software product:

  • licensesermainteOver the lifetime of many enterprise software  products, 70% of the total cost to a customer may come from service and maintenance fees.
    • Maintenance: like a bank
    • Software license: like a printing press
    • Pipeline of potential service revenues will rise or fall in proportion to the rise or fall in new product sales, albeit with a lag of a couple of years.
  • What we see is a crisscross pattern for firms whose services revenues eventually pass product revenues.
    • As products companies capture most of the "low-hanging fruit" in a market, new customers become harder to find. It then becomes easier and cheaper to sell services nd maintenance.
    • Another reason is commoditization of the products market and dropping price points, forcing products companies to go back to tailoring at least 20-30% of features in their products.
  • CRM:
    • Siebel (founded in 1993):
      Product license revenues fell from 95% of total sales in 1995 to 43% in 2002. The company's growth and profit rates have sunk with a net loss in 2002 of nearly $36M, is facing difficult times.
    • Many firms jumped into the CRM market during the late 1990s and early 2000s, driving down prices and making CRM products into commodities. (Eg. Salesforce.com)
  • ERP:
    • ERP companies are generally more oriented toward services and hybrid solutions than products, even in their early days.
    • PeopleSoft (founded in 1987) introduced a low-priced HRM (Human Resource Management) product that ran on PC. Over time, it has moved to a broader ERP product line, added more industry-specific features to a growing  product set.

ソフトウェアの収入分類:

  • 左図は、サービス売上が製品売上を交差して上回るパターンである。 ライセンス料からサービス料への以降の理由は明確である。
    • 入手しやすい果実：
      製品が市場ですぐ手に入る果実を採り終えてしまうと、新しい顧客を見つけることは困難になり、維持サービスを既存顧客に売ることが簡単でコストもかからない。
    • コモディティ化：
      製品がコモディティ化するために価格が下落し、製品機能の20-30%をカスタマイズせざるをえなくなり、その分がサービス売上増となる。

  • CRM:
    • シーベル (1993年設立):
    • 総売上に占める製品ライセンスの売上は1995年の95%から、2002年には43%にまで減少した。2002年には$36Mの赤字を計上し、困難な時期に直面している。
    • 1990年代後半から2000年代前半にかけて多くの会社がCRC市場に参入し、価格破壊とコモディティ化を引き起こした。 (例: Salesforce.com)

  • ERP:
    • ERPメーカは当初から製品よりも、サービスとハイブリッドなソリューションの提供を志向している。
    • ピープルソフト (1987年設立)は、PC上で動く低価格の人事管理ソフトウェアを投入した。やがて製品ラインを拡大し、個別業界に対応した機能を付加した製品セットにした。

 

>Top Gross Profit Margins:

  • prodser_margin
  • Business Objects, 1993-2002):
  • Relative gross profit margins between product license and services.
    • Gross margin in 2002:
      Siebel 97%; Oracle about 100%; PeopleSoft 90%; Compuware 90%, i2 97%.
    • Gross margin in services in 2002:
      Compuware 30%; Adobe 36%; Siebel 42%; PeopleSoft 53%
    • >Top current R&D costs is about 16.5% of sales (Business Objects).
    • It does not seem easy to evolve from services to products, at least not without making major acquisitions and changes in the mental model of the business and in personnel.

粗利益率:

  • (Business Objects社, 1993-2002) 　
    • 製品ライセンスとサービスの売上利益率の差
    • 製品販売の利益率はサービスに比べて如何に高いか。
    • 利益率 (2002年):
      Siebel 97%; Oracle about 100%; PeopleSoft 90%; Compuware 90%, i2 97%.
    • サービスの利益率(2002年):
      Compuware 30%; Adobe 36%; Siebel 42%; PeopleSoft 53%
    • なおR&Dは売上の16.5% (Business Objects社)　
    • M&Aなど通じてビジネスのマインドセットや人材を変えない限り、サービス企業から製品企業へ進化するのは容易ではない。

>Top Global software industry:

  • The global software industry in 2001 generated approximately $600 billion in revenues - 1/3 from packaged software products and the other 2/3 from software services. (Standard & Poor)
    • North America accounted for about 50% of world revenues, followed by Europe 31% and Asia 15%.
    • The number of firms in software and information services around the world: about 35,000 companies with at least 5 employees each.
  • Niche or Mass market:
    • It is relatively easy to enter the IT services and consulting segment but very hard for a single firm to compete in OS.
    • To build an OS to compete Windows, Linux, Solaris would require at least several hundred software designers, programmers, and testers working fulltime for several years. ($100-200M or more)
    • Nokia, Ericsson, and Motorola have banded together to create 700-person Symbian J/V to make make OS for Web-enabled phones.
  • Differences between enterprises and consumers:
    • Enterprises may produce very high revenues per sale, but these revenues can be costly.
    • They can be more costly than consumer sales and generate little or no profit margin.
    • Medium-sized and large enterprise customers usually require a software vendor to have a large direct-sales force and support staff.
    • The software vendor might also have to give a large discount to close a sale.
    • Positive side in bad markets (2001-02):
      When a software company targets enterprises, it has more ways of succeeding, even if it fails to develop a best-seller product. It can tailor its products to meet the needs of a particular customer (vertical market)
    • Many enterprise software companies also sell "perpetual licenses," granting customers the right to receive upgrades as long as they pay annual maintenance fee (usually 15% of the initial license)
    • Without a best-selling standardized product - a killer app, can easily rack up enormous losses simply due to the cost of R&D, sales, marketing, and distribution.

世界のソフトウェア産業:

  • 世界のソフトウェア産業は、約6000億ドル (2001)、内パッケージソフト製品の売上が1/3、ソフトウェアサービスの売上が2/3を占めている。
    • 北米は世界の売上の約50%、次いで欧州31%、アジア15%
    • ソフトウェア企業数や、従業員５人以上で約35,000社
  • ニッチ／マス市場:
    • ITサービスやコンサルタント分野への参入は比較的容易であるが、OS分野で単独で参入するのは至難である。
    • OS分野でWindows, Linux, Solarisに対抗するには、少なくとも数百名のソフトウェアデザイナー、プログラマー、テスターをフルタイムで数年に亘って維持する必要がある。 ($1-2億)
    • ノキア、エリクソン、モトローラは700名規模のJ/Vを設立し、Web可能な携帯電話のSymbian OSを製造している。
  • 法人向けと個人向け:
    • 法人向けは、一度のセールスで非常に大きな売上を生み出すが、 同時もコストも大きくなる。
    • 法人営業は、消費者向け販売に比べて費用がかさむので、注意しないと利益がほとんど無くなる可能性がある。
    • 中規模以上の法人ユーザは、ソフトウェア企業に対し、大規模な直販部隊とサポート部隊とを要求する。
    • ソフトウェア企業は、契約受注するには大幅値引が必要なるかも知れない。
    • 不況の時の良い側面(2001-02):
      法人ユーザを目標とした場合、ベストセラー製品の開発に失敗したとしてもせいこうへの道が数多く存在する。それは自社製品を特定顧客ニーズに合わせてて販売できる (垂直型市場)
    • 多くの法人向けソフトウェア企業は、ユーザが年間保守料 (通常は初期ライセンス料の15%程度)を払い続ける限り、アップグレードの権利を認める永久ライセンスを販売している。
    • キラーアプリケーションがないと、R&D、販売費、マーケティング費、流通費で簡単に膨大な損失を被る可能性がある。

>Top Industry standards dynamics:

  • Standards dynamics: (Cf: Information Rules by Carl Shapiro & Hal Varian)
    • The need to control seven critical assets:
      1. an installed base
      2. intellectual property rights
      3. ability to innovate,
      4. first-mover advantage,
      5. manufacturing abilities
      6. complementary producers
      7. band/reputation
    • They also offer lessons:
      1. Assemble allies
      2. Preempt competition, such as through rapid design cycles, contracts, and penetration pricing.
      3. Manage consumer expectation with aggressive marketing, public road maps, and early product announcements.
      4. Don't become complacent - continue to improve your product and even cannibalize your earlier product versions.
      5. if you ar not the standard, avoid "survival pricing" and instead try to compete on other dimensions (price/performance, quality, service), and try to interconnect to the standard.
  • >Top Software companies segmentation: 
    • Mainstream enterprise customers generally require highly refined products complete with a full set of complementary products and services (whole product solution by Geoffrey Moore). They are  generally less interested in leading-edge technology.
    • Companies do not have to become mainstream players to be successful; in the software business there are plenty of vertical and horizontal niches to exploit.
    • It is possible for a firm that has established market credibility in one segment to leapfrog the chasm when entering another segment.
    • Setting the standard in a mainstream or niche market generally involves becoming a platform leader, which differs from being a technology leader. Platform leaders can generate new--product sales even in bad markets.
      • Cf: Ampex - Sony -Victor; Xerox -Canon; Xerox - Apple - MS; MicroPro - WordPerfect - MS Word; VisiCalc - Lotus123 - MS Excel; Netscape - MS Internet Explorer
    • Most of software firms are complementors.
      • Andrew Glove (Intel) viewed about the importance of complementors as a sixth industry force, adding one to Michael Porter's set of 5 forces that determine levels of industry structure.
    • Customers need to be able to trust their vendors. It is also hard to judge the quality o fa software product without using it.

業界標準のダイナミックス:

  • Information Rules: Carl Shapiro & Hal Varian著)
    • ７つの強みをコントロールする必要性:
      1. 顧客基盤
      2. 知的財産権
      3. 革新力
      4. 先行者優位性
      5. 製造能力
      6. 補完製品の提供者
      7. ブランド力
    • さらに次の教訓も提供:
      1. アライアンスを組む
      2. デザイン変更の急速なサイクル
      3. 迅速な契約締結
      4. 初期低価格戦略を通じた先制攻撃
      5. 積極果敢なマーケティング
      6. ロードマップの公開、新製品の事前通知による顧客期待感
      7. 自己満足に陥らない。製品の改善継続、自社の古いバージョンのシェアも奪う
      8. 自社製品が業界標準でない場合、低価格戦略ではなく、別次元 (価格性能比、品質、サービス) で競争し、業界標準に相互接続する
  • ソフトウェア企業分類:　
    • 主流市場の法人顧客は、高度に洗練された補完製品やサービスが完備した製品、つまり全製品ソリューションを要求する。但し、最先端技術にはさほど関心を示さない。
    • 企業が成功するには必ずしも主流市場のプレーヤになる必要はない。ソフトウェア事業には垂直・水平のニッチ市場が沢山ある。
    • 一つの分野で市場の信頼を獲得した企業がもう一つのセグメントに参入する際に蛙跳びのようにキャズムを跳び越えることが可能となる。
    • 主流市場やニッチ市場で業界標準を設定することは、プラットフォームリーダになることを意味するが、それは技術リーダとなるのとは異なる。プラットフォームリーダになれれば、不況時も新製品の販売を進めることができる。
      • 例: Ampex - Sony -Victor; Xerox -Canon; Xerox - Apple - MS; MicroPro - WordPerfect - MS Word; VisiCalc - Lotus123 - MS Excel; Netscape - MS Internet Explorer
    • ほとんどのソフトウェア企業は補完製品メーカである。
      • Andrew Glove (Intel)は、M. Porterの産業構造を決める５つの力に加えて、補完製品メーカの影響力を６番目の力とした。
    • 顧客は信頼できるベンダを必要としている。ソフトウェア製品の品質は使ってみないとわからない面があるからである。

>Top Software market segmentation:

softmarket_segment

ソフトウェア市場分類

Product & Service/Maintenance:

productservicepercent

>Top 3. How software became a business:

  • The past may not be an absolute guide to the future, but it can often point the way.
  • How the software business came about: Who were the first entrepreneurs? What were they selling? How particular companies have succeeded or failed?

3. ソフトウェアのビジネスへの道:

  • 過去は未来の絶対的なガイドではないか、多くの場合進むべき方向を示してくれる。
  • ソフトウェア・ビジネスがどのように出現してきたのか。最初の起業家は誰だったのか？何を売っていたのだろうか？ある会社などのように成功し、失敗したのか？

>Top 4. Best practices in software development:

  • Common problems and solution:
    Whether a software company primarily makes packaged products or offers services such as custom programming, it has to learn to manage process without becoming a slave to it. Process means everything from defining product requirements and system architecture to final testing and technical support.
    • >Top NATO report on software engineering (1968)
      1. Lack of understanding in system requirements
      2. Gaps between estimates of costs and time with actual.
      3. Programmers' productivity levels (26:1)
      4. Difficulty of dividing labor between design and coding
      5. Difficulty in monitoring progress
      6. Rapid growth in size of software system
      7. Poor communication among groups
      8. Large expenses of production control tools
      9. difficulty of measuring of programmer
      10. Combing R&D, development, and production in a single project.
      11. insufficient numbers of skilled programmers.
      12. Difficulty of achieving reliability in large systems
      13. Dependence of software on hardware
      14. Lack of inventories of reusable software
      15. Software maintenance cost.

4. 開発のベストプラクティス:

  • パッケージ製品を提供するにせよ、カスタム・プログラミングサービスを提供するにせよ、プロセス管理について学ぶことは肝要である、しかしその奴隷となるのもまた問題である。プロセスとは、製品の要件定義やシステム・アーキテクチャから、最終テストおよび技術サポートに至るまでの肯定を意味する。
    • ソフトウェア・エンジニアリングに関するNATOレポート (1968) :
      1. システム要件に関する理解の欠如
      2. 大きな予実差異
      3. プログラマの生産性ばらつき (26:1)
      4. コーディング作業分担の困難性
      5. ソフトウェア・プロジェクト監視の困難性
      6. システムの急激な規模拡大
      7. グループ間コミュニケーション不足
      8. 多額の管理ツール費用
      9. プログラマ能力測定の困難性
      10. 研究・開発・製造の渾然一体化
      11. 熟練プログラマ人材不足
      12. 大規模システムの信頼性確保の困難性
      13. ハードウェアへの依存性
      14. 再利用可能なソフトウェア資産の欠如
      15. ソフトウェア・メンテナンス費用

>Top Software factory solution:

  • Software factory solution:
    • Most fundamentally, software development i snot a manufacturing activity; it is more a form of product design.
    • Factory organizations have tried to separate the requirements generation and high-level design process from program construction (coding and debugging) and have outsourced to subsidiaries or overseas contractors.
    • Mainframe software development in 1970s-80s, creating of "me-too" versions of IBM OS was more suitable for this factory model approach.
    • The Japanese organized projects mostly by following a sequential "waterfall" process, moving in sequence from high-level design to detailed design, functional design, programming, and testing.
    • Software factory concepts still apply well to make multiple version s of similar systems or build hybrid solutions.

ソフトウェア工場のソリューション:

  • 最も基本的なことだが、ソフトウェア開発は生産活動ではなく、むしろ製品設計である。
  • 工場型組織では、要件定義や概要設計プロセスをプログラム構築 (コーディングやデバック) から分離し、子会社や海外にアウトソースしてきた。
  • 1970-80年代、メインフレーム系のソフトウェア開発では工場型アプローチの方がうまく機能していた。
  • 日本企業の組織的プロジェクトはウォーターフォール型の手順で、概念設計から詳細設計、機能設計、プログラム作成、テストといった一連のステップを順番に進めるもの。
  • ソフトウェア工場というコンセプトは、類似システムの複数バージョンやハイブリッド・ソリューション構築では、現在でもよく機能する。

>Top Capabilities Maturity Model (CMM):

  • The Software Engineering Institute (SEI): by Carnegie Mellon Univ., Watts Humphery, IBM manager. SEI process rank project organizations on a scale of 1 to 5 according to the Capabilities Maturity Model (CMM).
    1. CMM Level-1: The initial process - is chaos.
      There is little formal project management, no defined process.
    2. CMM Level-2: The repeatable process.
      Scheduled review of actual vs. budgeted costs and progress.
    3. CMM Level-3: The defined process.
      Engineering teams dedicated to specifying and improving the development process.
    4. CMM Level-4: The managed process.
      Projects gather quantitative data by using designated database and analyzing cost and quality.
    5. CMM Level-5: The optimizing process.
      quantitative measurement and feedback.
    • Moving to a high SEI level has a short-term cost that can prove daunting to small development teams.
    • One problem is that it cannot guarantee a specific return for investing heavily in process.
    • Companies with more mature process capabilities should be better at managing schedules, cost overruns, and change request, as well as overall quality.
  • Software design and development:
    • The main modules in the product suit are technically very tightly coupled and not really separate products.
    • The lack of an interface layer to isolate the product code to migrate to different platforms.
    • The product architecture does not adequately identify common or kernel components.
    • The common components need to be too large to contain the shared functionality, making difficult to design, stabilize, evolve, and migrate.
  • Testing and quality assurance:
    • Code file check-in and check-out procedures are not standardized.
    • The process from file check-in to acceptance and global compilation takes one to two days.
    • Developers need to recompile the entire product to validate changes made in any one module, often wasting time.
    • There is no set time on a given day for integration builds, resulting in having to work with outdated files.
    • The builds prior to alpha test are infrequent.
  • Knowledge and people management:
    • Unrealistic schedules and lack of communication have created stress and overwork, as well as low morale.
    • Developers feel that managers view them as the bad guys because they make bugs.
    • People are afraid of talking openly about problems because they might get fired.
    • New hires quickly get demoralized when they see how poorly the company have been managed.
    • People are frustrated management incompetence.
    • Demoralized people cannot work up to their capabilities.
    • Developers fell as though managers have treated them as children, and they have to consult heir managers on too many small issues.

能力成熟度モデル (CMM):

  • ソフトウェア工学研究所(SEI): カーネギーメロン大学、
  • Watts Humphery, IBMマネジャ。
  • プロジェクト組織を５段階の能力成熟度モデル (CMM) に分類する。
    1. CMMレベル1: 初期段階 (カオス段階)
      正式なプロジェクト管理ほとんどなし
    2. CMMレベル2: 反復段階 (特定リーダに依存)
      コストや進捗度の予実の差に関する計画的レビュー
    3. CMMレベル3: 定義段階 (首尾一貫プロセス有り)
      開発プロ説改善専門チーム有り
    4. CMMレベル4: 管理段階 (定量測定・洗練化)
      製品毎のコストや品質の定量DB有り
    5. CMMレベル5: 最適化段階 (標準プロセス最適化) 定量測定結果に基づくフィードバック採用
    • SEIのレベルを上げることは、小規模の開発チームには怖じ気づくほどの短期的コスト圧力を伴う。
    • 問題点の一つは、進行中の投資にタイする具体的なリターンを保証することができない。
    • 成熟したプロセス能力をもっている企業は、全体の品質のみならず、納期、費用、使用変更などを管理する能力が優れている。　
  • ソフトウェア開発と設計:
    • 製品パッケージの主要モジュールが個別に切り分けられない。
    • インターフェイス層の欠如によって異なるプラットフォームへの移行が困難
    • 製品アーキテクチャが共通のコンポーネントを適切に確定していない。
    • 共通コンポーネントは巨大となり、設計、安定化、進化、移植の作業が困難
  • テストと品質保証:
    • コードファイルのチェックインとチェックアウトの手続きが標準化されていない。
    • ファイルのチェックインから受入検査、全体のコンパイルに一両日はかかる。
    • 開発者は１つのモジュールの変更内容を評価するために、製品全体の再コンパイルをする必要があり、時間を無駄にする。
    • 統合ビルドをいつ行うのかの取り決めがない。それまで古いファイルで作業せざるを得ない。
    • アルファ・テスト前にビルドを頻繁に行わない
  • ナレッジと人材管理:
    • 非現実的なスケジュールとコミュニケーション不足、勤労モラル低下、ストレス、過労
    • 上司や他人からバグの根源と見なされる。
    • 解雇の恐怖感。問題の隠蔽
    • 新規採用者は、貧弱な管理方法によって勤労意欲が急速に萎える。
    • 無能な経営者に対するフラストレーション
    • 自分の能力の限界まで働かない。
    • 些細なことまで上司に相談しなければならず、まるで子供扱いされているように感じる。

>Top 5. The essence of synch-and-stabilize:

  • The synch-and-stabilize techniques as first introduced at microsoft in the late 1980s. Dave Maritz, of former tank commander in the Israeli Army who headed Microsoft's Windows 95 testing group. Divisions of MS programmers working in individual offices that resemble individual tanks. Everyone is marching forward to attach the enemy, but the coordination comes from e-mail rather than the radio. The comment about five o'clock refers to the deadline the group had for checking in code to the daily build. The daily build is one of those few rigid structure points that force everybody to come together and help the company build complex products. They tried to scale up a more informal small-team or hacker style of software development.
    • They feature teams are free to innovate within certain parameters, though individual programmers and teams must synchronize their design and coding changes frequently or the process will break down because many features interact with one another or are interdependent in some way.
    • Since the mid-1970s, "spiral model" fro sequencing the different project phases, and "concurrent development" of multiple phases and activities have been talked.
    • >Top Extreme Programming (XP):
      In more recent years, there has been a more radical form of incremental design and development in the Extreme Programming movement, which promotes the idea of writing minimal specs before coding and evolving architectures, designs, code and test cases concurrently as a project proceeds, with programmers working in pairs.
    • Users' needs for many types of software are so difficult to understand, and changes in hardware and software technologies as so continuous and rapid, that it is unwise to attempt to design a software product or complex information system completely in advance.
  • >Top Focus creativity: (Case of Microsoft)
    1. Divide large projects into multiple milestone cycles with buffer time (20-50% of total project time) and no separate product maintenance group.
    2. Use a vision statement and outline feature specs to guide projects.
    3. Base feature selection and prioritization on user activities and use data.
    4. Evolve a modular and horizontal design architecture, with the product structure mirrored in the project structure.
    5. Control by individual commitments to small tasks and fixed project resources.
  • >Top Work in parallel but synchronize continuously:
    1. Work in parallel teams but synch up and debug daily.
    2. Always have a product you can ship, with version for every major platform and market.
    3. Speak a common language on a single development site.
    4. Continuously test the product as you build it.
    5. Use metric data to determine milestone completion and product release.
  • No "one best process":
    • In some cases, speed to market and innovation are far more important than product quality, such as reliability.
    • On the other end, if you finally move to the mass market, quality in the sense of reliability, support, and maintenance generally becomes much more important that speed to market or innovation.

5. 同期･安定化プロセス:

  • 同期安定化プロセスは、1980年代後半にマイクロソフトで最初に導入された。デーブ・マリッツは元イスラエル陸軍の戦車部隊を指揮し、MSのWindows95の品質テストの責任者となった人物で、軍隊との類似性を指摘している。あたかも戦車のような密室にこもって作業するMSのプログラマー部門は、皆、敵を攻撃すべく前進している。但し連絡は、無線ではなく電子メールである。夕方５時とは、そのグループが成果日報を行う締切時間のことである。むしろ非公式な小さなチームやハッカー的なソフトウェア開発スタイルをそのまま大規模に展開しようとした。
    • 機能チームは、一定の条件の下で、自由にイノベーションすることが許されている。しかし個々のプログラマやチームは各々の設計内容やコード変更について頻繁に同期をとらないと、開発プロセスが破綻してしまう。それは多くの機能が他の機能と相互に作用し、いわば相互依存し合っているからである。
    • 1970年代中頃以降、異なるプロジェクト・フェーズを順番に処理していく「スパイラル・モデル」や、複数のフェーズを同時に行う「コンカレント開発」について議論されてきた。
    • 最近では、エクストリーム・プログラミング (XP) という、コーディーングする前の仕様を最小限に留め、プロジェクトの進捗に合わせてプログラマが二人一組のペアを組ながら、アーキテクチャ、設計、コード、テストなどを同時併行的に漸進的に進展させていく画期的な設計開発手法がある。
    • それは、ソフトウェア製品や複雑な情報システムを、前もって完全に設計しようなどと考えること自体浅はかであるというものである。
  • 機能進化とリソース固定による創造力の集中: (Microsoftのケース)
    1. 大プロジェクトを複数の中間目標に分割し、各々に予備期間 (全体の20-50%) を設ける。但しメインテナンスのグループは設けない。
    2. 開発目標書と概略機能仕様書を利用してプロジェクトがガイドする。
    3. ユーザ側の活動とデータに基づいて、基本機能を選択と優先順位をつける。
    4. モジュラー的で水平的なアーキテクチャを発展させ、製品構造をプロジェクト構造に反映させる。
    5. 小タスクに対する各人の責任および固定的なプロジェクト資源によって管理する。
  • 同時並行作業を進め、いつも同期をとる:
    1. いくつかの並行するチームに分かれて進め、毎日同期をとりデバッグを行う。
    2. 主要なプラットフォーム、市場に対応したバージョンに対応した製品を常に抱える。
    3. 開発は同じ場所で、共通言語を話す。
    4. ビルドの度に、テストを繰り返す。
    5. 数量データを用いて、中間目標と製品リリースを決める。
    6. ビルドを壊すようなコードを発見すると、直ちに不具合を修正しなければならない。
  • 唯一の最適のプロセスは存在しない:
    • ある場合は、製品の品質、即ち、信頼性よりも、市場への対応速度や革新性が重要な場合がある。
    • 一方では、最終的にはマスマーケットを狙うのであれば、一般的には市場への対応速度や革新性よりも信頼性という意味での品質や維持サポートの方がずっと重要になる。

 

>Top Risk management:

  • Risk management (Case of Netscape):
    • As Netscape moved beyond Ver.3 to Ver.4 of Navigator, the code base grew from a few tens of thousands of line to several million. Meanwhile, Netscape teams attempted to build two new versions of the browser and Communicator suite (5.0, an incremental upgrade, and 6.0, a new Java-based design) at once. This lapse was perhaps the major factor that proved fatal in its battle with Microsoft.
  • Late changes can be good:
    • Late changes produce more bugs and schedule delays. But proper countermeasures, such as frequent builds, design and code reviews, and integration testing with each change, can mitigate the level of bugs and lateness.
    • >Top A process that allows project to accommodate lots of change with a minimal impact on quality and productivity is a great competitive advantage.
  • Team management:
    • A small team of great people works much better than a large team of mediocre people and that talent is more important than experience.
    • The best programmer will probably be about 10 times better than the worst programmer and about 2.5 times better than the average programmer.
  • Effective teamwork principles:
    • >Top Overlapping functional responsibilities:
      • Product managers take charge of writing vision statements, but they are also responsible for consulting program managers.
      • Program managers write functional specs, but they have to consult developers, who generally have a de facto veto power because they have to estimate the time and people required to write the code.
      • Developers and testers are paired and are jointly responsible for testing code.
    • Good communications and overlapping responsibilities help an organization avoid become too functionally oriented and too compartmentalized.
  • >Top Divide and conquer:
    • It is much easier to manage several small groups that are doing a smaller amount of work and have a deadline that is only a few weeks or months away than to menage one large group.
    • Sometime in the future, near the end of the project, in one big bang, the team would try to integrate all the pieces It is a classic waterfall model.
  • Individual commitments and project discipline:
    • Another issue is how rigid to make the project rules. The goal should always be to ship a great product, not simply follow rules or a process.
  • Building in quality through continuous testing:
    • It is ultimately cheaper to build in quality continuously rather than to test and fix it in at the end of a development or production cycle.
    • Fixing a bug in the field at a customer site can cost a 100 times as much as finding and fixing it early in a project.
    • "Eat your own dog food"

リスク管理

  • リスク管理:（Netscapeのケース）
    • ネットスケープはNavigatorのVer.3 からVer.4に進む間に、基本コードは数万から数百万行に膨れあがっていた。その間で、ネットスケープの開発チームは、ブラウザとCommunicator suite について、２つの新バージョンを同時に作ろうとした。 (アップグレード版のVer.5とJavaで設計したVer.6) ひょっとするとこの過ちが、MSとの闘いで致命的な原因だったかも知れない。
  • 後変更が良い結果をもたらすことがある:
    • 後々の変更がさらに多くのバグやスケジュール遅延をもたらすことは確かにあるが、頻繁なビルド、設計やコードの見直し、変更の都度実施する統合テストなど対応によって、バグと遅延の程度を軽減できる。
    • 多数の変更を取り入れるプロセスは、品質と生産性への影響を最小限に留めれば、競争上大きな優位性をもたらすことがある。
  • チーム管理:
    • 有能な人からなる小さなチームは平凡な人が集まった大きなチームよりよい成果を出す。また才能は経験より重要である。
    • 最良のプログラマは最悪のプログラマの約10倍で、平均的なプログラマの2.5倍の能力がある。
  • 効果的なチームワークの原則:
    • 機能的責任の重複である。
      • 製品マネジャは開発目標書を書き、同時にプログラム・マネジャの意見を聞く責任もある。
      • プログラム・マネジャは機能仕様を書くが、同時に事実上の拒否権をもつ開発の意見も聞く。
      • 開発者とテスターはペアを組み、コードをテストする共同責任を負う。
    • コミュニケーションと責任の重複によって、組織が特別の機能を重視しすぎて極度に細分化され、多数のグループの寄せ集め集団となるのを避ける。
    • プロジェクト規則をどの程度厳格に作るか。MSでは規則は少なかったが、いくつかの規則は軍隊の規律のような印象を受けた。
  • 分割統治:
    • 締切が数週間か数ヶ月先に迫っているような、仕事量の少ない複数の小さなグループを管理する方が、大きなグループを管理するよりやさしい。
    • 一回のビッグバンで開発チームはすべての部品を統合化しようとするのが古いウォーターフォール・モデルである。
  • 責任分担とプロジェクトの規律:
    • 重要なことはプロジェクトの規律をどの程度厳格に作るかである。最終目標は常に素晴らしい商品を出荷することになり、単に規則やプロセスに従うことではない。
  • 連続したテストによる品質向上:
    • 開発や生産サイクルの最後になってからのテストで修正するより、高品質を継続して製品に組み込む方が、結局安くつく。
    • 顧客現場でのバグ修正は、プロジェクト初期のバグ修正の100倍も費用がかかる。
    • 「自分が作ったドッグフードは自分で食べろ」

>Top Programming performance:

  • Regional differences in performance:
    • Based on the preliminary data, the Japanese had the best quality levels (median of .020) in terms of defects report per 1,000 lines of code in the 12 months after implementation at customer sites.
    • The Indian projects (.263) and US project (.400) were more similar and very good by historical standards but still 13 to 20 times more buggy than the Japanese projects.
    • Project from Europe (.225) were similar to the Indian levels.
    • US programmers often have different objectives. They tend to emphasize shorter or more innovative programs and spend much more time thinking about what they are writing and optimizing code.
    • Japanese companies still seem preoccupied with producing close to zero-defect code, and one can only wonder how much this practice constraints their willingness to experiment and innovate in software development.
  • Caution on outsourcing software development:
    • Outsourcing software development to low-cost customer shops in India or in China or in Southeast Asia is a good idea and can save money.
    • Outsourcing program construction is not the best way to do innovative software development. It can force projects into a rigid waterfall model because it is easier to structure work sequentially and take more effort to do frequent builds and incorporate customer feedback quickly if the development team is dispersed or separated from the customer.

プログラミング･パフォーマンス:

  • パフォーマンスに関する地域差：
    • ハグ発生率：
      顧客へのシステム導入後12ヶ月で計測した1000行毎のバグ報告によれば、中央値で、日本 0.020 、インド0.263 、米国0.400で、これは日本の13-20倍である。
    • 人・月当たり生成コード行数は、 中央値で、日本469行であり、これはインドの２倍、米国の1.7倍、欧州はほぼインド並である。
    • 米国のプログラマは、なるべく簡潔なで革新的なプログラムの開発を重視する傾向にある。
    • 日本は、未だに欠陥ゼロに近いコードを生成することに心を奪われている。この姿勢によって、ソフトウェア開発中に試したり、工夫したりしようという意欲が、かなりの程度制約を受けているのではないだろうか
  • ソフトウェア開発のアウトソースの留意点：
    • ソフトウェア開発をインドや中国や東南アジアの会社にアウトソースするのは、費用削減のアイデアとしては悪くない。
    • アウトソースは、革新的なソフトウェアを開発する方法としては最良ではない。もし開発チームが分散しているか顧客から離れている場合には、頻繁なビルドや顧客からのフィードバックを迅速に反映していくのは困難となるので、ウォーター・フォールモデルを使わざる得なくなる。

>Top 6. Software entrepreneurship:

  • Good time and bad time:
    • Who knew that stock prices would rise so fast and fall so far? Who knew that the NASDAW would lose 80% of its value within a couple of years?
    • Between 19998 and early 2000, we experienced a once-in-a-century event, equivalent to and perhaps surpassing the introduction of the transcontinental railroad, commercial electricity, telephone, television, and computer.
    • But the principles that determine why businesses succeeded or fail over the long run remained in place.
  • Saratoga Venture Finance:
    • VCs finance only 6/1000 business plans each year.
    • Fewer than 20%, and more like 10% of funded stat-ups go public.
    • In normal time (excluding bubble periods), start-ups generally require about 5 years to go public.
    • About 60% of high-tech companies that get VC funding go bankrupt, and another 30% end up in mergers or liquidations.
    • VCs generally own about 60% of the equity in software start-ups by the time they go public.
    • Founders generally own less than 4% of their ventures after IPO, worth about $6.5M
  • A mental checklist of several elements that are necessary for a software start-up to succeed as a business and raise venture capital.
    1. A strong management team:
      A small group of strong founders with a solid business idea should be able to get commitments from other experienced, talented managers to join the team and cover the basic functions needed to get started and land some customers.
    2. An attractive market:
      The easiest businesses to start are customer services in specialized vertical segments, then gradually turn it into a horizontal business.
      • >Top Michael Porter: Industry 5 forces
        There should be relatively high entry barriers to keep out competitors; not so may rivals that competition is likely to devolve into cutthroat price wars; limited of buyers or suppliers to negotiate prices downward or the cost of input upward; and no good substitutes for the basic product or service. (plus internal forces)
        In addition, if complementary products or infrastructure element  (A. Grove called 6th industry force. )
    3. A compelling new product, service, or hybrid solution:
      Entrepreneurs should plan to provide quantitative and qualitative data showing how their offering would provide superior benefits to customers over what competitors (or substitutes) already offer or ar likely to offer in the future.
    4. Strong evidence of customer interest:
      • One good piece of evidence is letters of intent to purchase the new company's products or services.
      • Creating a prototype helps everyone visualize how easy or difficult it will be for a new company to market, sell, distribute, and support its product.
    5. A plan to overcome the credibility gap:
      • To get the first reference customer, even if almost for free.
      • Look for an established partner that can guarantee continued product support or services.
      • Lining up a network of small investors, advisers, and reference experts who can give potential customers some level of confidence
      • Focus, at least initially, on a niche business, perhaps a project-based customization or service, that does not require longevity. Then build up a list of customers.
    6. A business model showing early growth and profit potential:
    7. Flexibility in strategy and product offerings:
    8. The potential for a large pay of to investors.

6. ソフトウェア起業家精神:

  • 良い時と悪い時:
    • 株価があれほど急騰し、そして暴落するなど誰が予想できただろうか？NASDAQが数年以内に、その価値の80%を失うことを誰が知っていただろうか？
    • 1998-2000初めにかけて、大陸横断鉄道、電気、電話、TV、コンピュータの登場に匹敵する、それ以上の100年に一度の出来事を経験した。
    • しかし、ビジネスが長期的にはなぜ成功し、なぜ失敗するかの原則は何も変わらなかった。
  • サラトガ・ベンチャー・フィナンス：
    • VCは、ビジネスプランの内、6/1000に、毎年資金提供する
    • 企業公開できるのは20%未満、せいぜい10%
    • 正常な時期 (バブル期以外)は、株式交換までは約５年かかる。
    • ハイテク企業の60%は倒産、30%は合併または精算
    • VCはスタートアップから上場するまで約60%の資本を保有する。
    • 創業者がIPO後も保有する持ち株比率は4%以下、約$6.5M
  • 起業に向けての成功必要条件:
    1. 強力な経営陣:
      しっかりしたビジネス・アイデアをもつ強力な創業者による少数グループは、経験豊富な才能あるマネージャをチームに加え、業務の立ち上げと一定の顧客開拓を獲得するのに必要な基礎的機能を担当させるべきである。
    2. 魅力的な市場:
      最も攻めやすいビジネスは、専門家した垂直セグメントでのカスタム・サービスである。それから徐々にそれを水平型ビジネスに変えていく。市場規模だけが、事業計画を魅力的にするのではない！
    3. マイケル・ポーター的市場分析:
      競争企業が簡単に入れない比較的高い参入障壁があり、激烈な価格競争になりそうなライバルがそれほど存在せず、価格を下げたり上げたりの交渉をしなければならない買い手または売り手の力が限定的で、基本的な製品・サービスに対する優れた代替物が存在しないことである。(さらに組織内部の力）６番目の力として補完製品またはインフラ的要素が早く利用できること。
    4. 顧客を引きつける新しい製品、サービス、ハイブリッド・ソリューション:
      起業家は定量・定性データを駆使した計画を作り、自分の製品やサービスが、顧客に対して、競争相手 (あるいは代替製品) がすでにオファーしているか、将来オファーしそうなものより、優れた便益をいかに提供できるかを示さなければならない。
    5. 顧客が関心をもっている証拠:
      • 新会社の製品・サービスの購入意向を示す仮契約書。
      • プロトタイプを作ることで、新会社にとってその製品を市場に出すことがどれほど簡単か難しいかを誰にも見えるようにする。
    6. 信頼性ギャップを克服する計画:
      • ほとんど無償でも先行事例となる最初の顧客
      • しっかりしたパートナー
      • 顧客に信頼を与えるような小規模投資家、アドバイザ、専門家の人脈ネットワークを作る
      • すくなくとも初期はニッチ分野で、長期的でないプロジェクトに集中し、まず顧客リストを作る
    7. 初期の成長と利益を生む可能性のビジネスモデル:
      • 会社設立後1ー2年以内に、成長と利益の提案ができなければならない。
      • またスタートアップ企業が売上や利益を上げる前に、何千万ドルもの投資資本と数年の期間が必要であると訴えることは危険な行為に見える。
    8. 戦略と提供する商品の柔軟性:
      成功物語が予め正確に計画されていることはめったにない。ほとんどの企業が、時間と技術の変化とともに、戦略、製品、製品ライン、ビジネスモデルを進化し続ける必要がある。
    9. 投資家に対する大きな見返りの可能性:
      市場規模を頭に浮かべること。VCによってはある種の流動化イベントを必要とする。通常の出口戦略は、より大きな会社への売却あるいはIPOすることである。

>Top 7. Start-up case studies:

  • Success odds:
    • Of all the ventures, only one (NuMega) has been an unqualified success, and five had ended in bankruptcy.
    • In good times, more of these firms would probably have survived.
    • But in bad times for venture investments and public offerings, such as in 2001-03, only firms with a compelling product, distinctive service capabilities, and compelling but flexible technologies and business strategies seem to have a better-than-average chance of becoming viable businesses.
  • Software entrepreneurship:
    • The potential for economics of scale is probably greater than in any other area except for digital content businesses.
    • Because software is a technology with almost unlimited applications, entrepreneurs need to acquire a deep understanding of a particular end market in order to know what to build and how to sell it. This means they need to get firsthand knowledge or hire people with the knowledge they need.
    • >Top Venture funding can be the kiss of death for some start-ups. When companies raise a lot of outside money, the overwhelming tendency is to spend it. Sometimes it encourages a firm to expand its head count and overhead commitments or its marketing plans to levels it cannot sustain.

7. スタートアップ企業ケース:

  • 成功確率:
    • 10社のベンチャーの内、たった１社 (NuMega) だけが成功を収め、５社は破産した。
    • 景気がよければ、もっと多くの会社が生き残っていただろう。
    • 2001-2003のような、ベンチャー投資とIPOにとって最悪の時期には、よほど魅力的な製品をもった企業か、明確に差別化されたサービス能力の優れた企業か、魅力的と同時に柔軟性の高い技術やビジネス戦略をもった企業だけがビジネスを得る機会は平均以上に高くなる。
  • ソフトウェア起業家:
    • ソフトウェア製品起業の場合、規模の経済が働く可能性は、デジタル・コンテンツ・ビジネスを除きどの業界より高いのではないか。
    • ソフトウェアは用途がほぼ無限大の技術なので、起業家は何を作り、どう売るべきかを知るために、最終顧客が存在する特定市場を深く理解する必要がある。つまり、市場から直接的な知見を得るか、必要な知識をもった人間を雇う必要がある。
    • VCなどの資金援助が死のくちづけになり得る。企業が多くの外部調達資金を手にすると、圧倒的にそれを使いたがる。人員や諸経費を拡大したり、マーケティング計画を維持できない水準にまで拡大したりしてしまう。

>Top 8. Ideal vs. Realistic software business:

  • Different capabilities:
    • >Top Software product companies should organize not around compartmentalized functions, such as design, programming, testing, and marketing, but around product teams that target specific competitors or customer segments.
  • Hybrid solutions companies:
    • They must learn how to package software technology to meet the needs of more than one user.
    • But they must also learn to customize each product without spending too much money and cultivate a relationship with each customer.
    • They should manage software development systematically by emphasizing common principles of design, development, testing, and project management, as well as instituting some measures to promote reusability of designs and code.
    • Software projects of more than a handful of people always need some way to coordinate complex tasks and come to an end within a predicable window.
  • >Top The next chasm to cross:
    • We should always remember that bubbles are just that - bubbles. They expand and then burst. It follows that good times for technology-companies must return.
    • History provides some guidelines for thinking about the future.
    • Software applications appear to be limited mainly by human imagination, with some minor constraints imposed by real-world factors such as users' habits and costs.
    • The current buzzwords include mobile broadband, peer-to-peer functionality, and Web services, but other new software technologies will continue to appear every year or two.
    • >Top Novice user:
      There is another chasm for software companies to cross: the truly novice user (5B or so people in the world)

8. ソフトウェア・ビジネスの理想と現実:

  • 異なる能力:
    • ソフトウェア製品企業は、設計、プログラミング、テスト、マーケティングという区分された機能を体系化するのではなく、特定の競合や顧客セグメントを狙った製品チームを体系化すべきである。
  • ハイブリッド・ソリューション企業:
    • 複数ユーザのニーズに応えるようにパッケージ化する方法を学ばなければならない。
    • 同時にあまり多額の資金を使わずに個々の製品をカスタマイズし、顧客との関係を深めなければならない。
    • 設計、開発、テスト、プロジェクト管理の共通原理を重視し、設計やコードの再利用を促進する。
    • トップは、予期せぬ変化に対し、十分な技術的柔軟性をもたなければならない。
    • 開発者が一定人数を超えると、複雑な作業内容を調整し、予測の範囲内で完了させるための方法が必要になる。
  • 超えるべき深溝-キャズム:
    • バブルはバブルでしかない。バブルは膨張しやがて破裂する。しかし、技術系企業にとっての好況は必ず戻ってくる。
    • 過去は未来を考えるための指針を与えてくれる。
    • ソフトウェア・アプリケーションの制約があるとすれば人間の想像力が課す制約、ユーザの癖やコストといった現実世界の要因によるマイナーな制約条件である。
    • 現在のキーワードは、モバイル・ブロードバンド、P2P機能、Webサービス 。なお、新しいソフトウェア技術も１、２年おきに出現している。
    • ソフトウェア企業には超えなければならないもう一つのキャズムがある。未経験のユーザ (世界に50億人) である。
Comment
  • >Top This is an excellent and recommendable textbook to understand software industry from the very beginning.
  • But the industry is still rapidly changing; particularly in the fields of ubiquitous, wireless, traceability, security, various integrated application software, and even open-source is becoming much more practical.
  • Even Microsoft might be a temporal victor in the software industry, just like 5 strokes ahead as of the end of the first round of the golf tournament.
  • We expect the following-up version of this book would be published in near future, because this book published in 2004 has already become a classic book.
  • 本社はソフトウェア業界を最初から理解するのに素晴らしい教科書であり、推薦したい。
  • しかしこの業界はいまだに急激に発展している。特にユビキタス、ワイヤレス、トレーサビリティ、様々な統合アプリケーション、またオープンソースもずっと実用的になってきている。
  • マイクロソフトですらこのソフトウェア業界では一時的な勝者あって、ゴルフ・トーナメントの初日の終了時点で５ストロークリードしているようなものかも知れない。
  • 2004年に出版されたこの本はすでに古典になっているので、この続編が近い将来出版されることを期待している。

| Top | Home | Article | Bookshelf | Keyword | Author | Oxymoron |