これは、MIT SloanのCusumano先生が本でも授業でもよく言ってる話。
面白いから忘れないうちに書き記しておく。
Cusumano先生は、Microsoft SecretやPlatform Leadershipで有名なソフトウェアビジネスの研究者。
日本の企業研究も色々されているし、一橋大学のビジネススクールで何年か教えてらしたりした日本通でもある。
そのCusumano先生が、ソフトウェア産業への取り組み方を比較して、こんなことを言っていた。
Europe: Software as a science −ヨーロッパにとってソフトウェアは「科学」
Japan: Software as production −日本のソフトウェアは「製造業」
India: Software as a service −インドのソフトウェア産業は「（プロフェッショナル）サービス」
U.S.: Software as a business −アメリカのソフトウェア産業は「ビジネス」
順に解説。
まずヨーロッパ人っていうのは、ソフトウェアをサイエンスの延長だと思っていて、
やたら要求仕様（Requirements）を数学的に構造化したり、数学的に検証できるのを重視するのだそうだ。
オブジェクト指向なプログラムデザインにもやたらこだわるし、
しかもオブジェクトを再利用出来るよう構成することに神経を費やす。
その結果、確かにエレガントかもしれないけど、必要以上に構造に凝りすぎたアーキテクチャが出来上がるらしい。
利点・欠点を考察してみよう。
ヨーロッパ式の利点は、一度しっかりしたアーキテクチャを作ったら、慣れれば理解しやすく開発効率が良いということか。
欠点は、作るまでに時間がかかるというのと、不必要に構造がしっかりしすぎて無駄が多いこと。
例えば、CERNで生まれたwwwなんて（ソフトウェアではないが）、ドメインのアドレスの構造が不必要にしっかりしてアドレスが長くなりすぎる典型じゃないかと、私は思う。
一方、日本のソフトウェア産業っていうのは、まるで製造業の発想なのだそうだ。
Zero-defectsにこだわる姿勢−バグはギリギリまで取り除く圧倒的な品質管理。
完成度の低いソフトウェアを勢いで市場に投入するとか絶対にしない。
技術者のスキルの高さはまるで職人芸。
要求仕様を定め終わってから、開発に入り、全部終わったらテストと、まるで車の生産のように順序立てられた開発プロセス（註1）。
これにも利点と欠点があるよね。
強みは、リテールの銀行のシステムとか、リアルタイムの社内財務管理システムとか、
バグがあってはまずいシステムではやはり品質は世界一ってことなんじゃないだろうか。
欠点は、不必要な品質の高さを目指してTime to marketが遅れること。
消費者向けとか、ベータバージョンをさっさと出してシェア取った方が良いのに出来ないとか。
慎重で、石橋を叩いて渡るようなソフトウェア開発は、面白い機能をリアルタイムでどんどん付けていくのには不向きだよね。
インドのソフトウェアがプロフェッショナルサービスだって言うのは、まあそうかな、って感じ。
新しいものを生み出すのではなく、顧客の要求に応じて必要なものをDeliverする発想だ。
Infosysとかインドの有名ソフトウェア企業は皆そうだよね。
最後にアメリカだけど、アメリカ人は最初からソフトウェア産業をビジネスとしか捉えてないということ。
だから、品質も構造も「売れる最低限」しか達成しないし、
早期に業界標準を形成して、とにかく金が稼げるビジネスモデルの形成に力を入れる。
ヨーロッパみたいにエレガントなシステムとか、日本みたいに完璧なシステムとかはどうでも良く、
「使いやすい」→「売れる」がモットー。
結果として、約1兆ドル（100兆円）と言われるソフトウェア市場の5割を、アメリカ企業が占める結果となっているそうな。
というわけで、お国の違いが色々あるわけだけど、日本のソフトウェア産業はこのまま製造業を続けるのか、アメリカ的なビジネスなソフトウェアにしたいのか、というのは考える余地がありそうだ。
（註1）こういう順序だてられた開発プロセスをを英語ではWaterfall processというらしいが、
日本では未だに6割の企業がこのプロセスでソフトウェアの開発を行っているらしい。
一方で、世界のソフトウェア開発の主流はAgileと呼ばれる、機能ごとに切って別々に開発する方法。
一般的な製造業の開発プロセスとはかなり違う、ソフトウェアならではの開発方法だ。
Waterfallだと、仕様に変更が加わったときに、最初から戻ってやり直さないとならないが、
Agileだと次々に仕様変更があっても、Add-onしていけばよいので、今までのプロセスが余り無駄にならない。
ソフトの種類にもよるので、一概には言えないが、世界全体ではAgileの採用率が64%なのに、
日本では44%に過ぎない、という統計もある。
それを考えるのに、Cusumano先生のこの本は参考になるかもしれないと思う。
面白いから忘れないうちに書き記しておく。
Cusumano先生は、Microsoft SecretやPlatform Leadershipで有名なソフトウェアビジネスの研究者。
日本の企業研究も色々されているし、一橋大学のビジネススクールで何年か教えてらしたりした日本通でもある。
そのCusumano先生が、ソフトウェア産業への取り組み方を比較して、こんなことを言っていた。
Europe: Software as a science −ヨーロッパにとってソフトウェアは「科学」
Japan: Software as production −日本のソフトウェアは「製造業」
India: Software as a service −インドのソフトウェア産業は「（プロフェッショナル）サービス」
U.S.: Software as a business −アメリカのソフトウェア産業は「ビジネス」
順に解説。
まずヨーロッパ人っていうのは、ソフトウェアをサイエンスの延長だと思っていて、
やたら要求仕様（Requirements）を数学的に構造化したり、数学的に検証できるのを重視するのだそうだ。
オブジェクト指向なプログラムデザインにもやたらこだわるし、
しかもオブジェクトを再利用出来るよう構成することに神経を費やす。
その結果、確かにエレガントかもしれないけど、必要以上に構造に凝りすぎたアーキテクチャが出来上がるらしい。
利点・欠点を考察してみよう。
ヨーロッパ式の利点は、一度しっかりしたアーキテクチャを作ったら、慣れれば理解しやすく開発効率が良いということか。
欠点は、作るまでに時間がかかるというのと、不必要に構造がしっかりしすぎて無駄が多いこと。
例えば、CERNで生まれたwwwなんて（ソフトウェアではないが）、ドメインのアドレスの構造が不必要にしっかりしてアドレスが長くなりすぎる典型じゃないかと、私は思う。
一方、日本のソフトウェア産業っていうのは、まるで製造業の発想なのだそうだ。
Zero-defectsにこだわる姿勢−バグはギリギリまで取り除く圧倒的な品質管理。
完成度の低いソフトウェアを勢いで市場に投入するとか絶対にしない。
技術者のスキルの高さはまるで職人芸。
要求仕様を定め終わってから、開発に入り、全部終わったらテストと、まるで車の生産のように順序立てられた開発プロセス（註1）。
これにも利点と欠点があるよね。
強みは、リテールの銀行のシステムとか、リアルタイムの社内財務管理システムとか、
バグがあってはまずいシステムではやはり品質は世界一ってことなんじゃないだろうか。
欠点は、不必要な品質の高さを目指してTime to marketが遅れること。
消費者向けとか、ベータバージョンをさっさと出してシェア取った方が良いのに出来ないとか。
慎重で、石橋を叩いて渡るようなソフトウェア開発は、面白い機能をリアルタイムでどんどん付けていくのには不向きだよね。
インドのソフトウェアがプロフェッショナルサービスだって言うのは、まあそうかな、って感じ。
新しいものを生み出すのではなく、顧客の要求に応じて必要なものをDeliverする発想だ。
Infosysとかインドの有名ソフトウェア企業は皆そうだよね。
最後にアメリカだけど、アメリカ人は最初からソフトウェア産業をビジネスとしか捉えてないということ。
だから、品質も構造も「売れる最低限」しか達成しないし、
早期に業界標準を形成して、とにかく金が稼げるビジネスモデルの形成に力を入れる。
ヨーロッパみたいにエレガントなシステムとか、日本みたいに完璧なシステムとかはどうでも良く、
「使いやすい」→「売れる」がモットー。
結果として、約1兆ドル（100兆円）と言われるソフトウェア市場の5割を、アメリカ企業が占める結果となっているそうな。
というわけで、お国の違いが色々あるわけだけど、日本のソフトウェア産業はこのまま製造業を続けるのか、アメリカ的なビジネスなソフトウェアにしたいのか、というのは考える余地がありそうだ。
（註1）こういう順序だてられた開発プロセスをを英語ではWaterfall processというらしいが、
日本では未だに6割の企業がこのプロセスでソフトウェアの開発を行っているらしい。
一方で、世界のソフトウェア開発の主流はAgileと呼ばれる、機能ごとに切って別々に開発する方法。
一般的な製造業の開発プロセスとはかなり違う、ソフトウェアならではの開発方法だ。
Waterfallだと、仕様に変更が加わったときに、最初から戻ってやり直さないとならないが、
Agileだと次々に仕様変更があっても、Add-onしていけばよいので、今までのプロセスが余り無駄にならない。
ソフトの種類にもよるので、一概には言えないが、世界全体ではAgileの採用率が64%なのに、
日本では44%に過ぎない、という統計もある。
それを考えるのに、Cusumano先生のこの本は参考になるかもしれないと思う。
日本語訳はこちら。
ソフトウエア企業の競争戦略
マイケル・A. クスマノ
ダイヤモンド社
（註1）こういう順序だてられた開発プロセスをを英語ではWaterfall processというらしいが、
日本では未だに6割の企業がこのプロセスでソフトウェアの開発を行っているらしい。
一方で、世界のソフトウェア開発の主流はAgileと呼ばれる、機能ごとに切って別々に開発する方法。
一般的な製造業の開発プロセスとはかなり違う、ソフトウェアならではの開発方法だ。
Waterfallだと、仕様に変更が加わったときに、最初から戻ってやり直さないとならないが、
Agileだと次々に仕様変更があっても、Add-onしていけばよいので、今までのプロセスが余り無駄にならない。
ソフトの種類にもよるので、一概には言えないが、
世界全体ではAgileを含むIterativeなプロセスの採用率が64%なのに、日本では44%に過ぎない、という統計もある。
(2003 IEEE Software "Software Development World Wide")
（追記: Agileの使用率自体はまだ米国含む各国でも低いようです。最近のAgileの日本VS世界比知ってる方いたら教えてください
