これは、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割を、アメリカ企業が占める結果となっているそうな。
というわけで、お国の違いが色々あるわけだけど、
日本のソフトウェア産業はこのまま製造業を続けるのか、アメリカ的なビジネスなソフトウェアにしたいのか、
というのは考える余地がありそうだ。
それを考えるのに、Cusumano先生のこの本は参考になるかもしれないと思う。
![]() |
The Business of Software Michael A. Cusumano Free Press |
日本語訳はこちら。
![]() |
ソフトウエア企業の競争戦略 |
(註1)こういう順序だてられた開発プロセスをを英語ではWaterfall processというらしいが、
日本では未だに6割の企業がこのプロセスでソフトウェアの開発を行っているらしい。
一方で、世界のソフトウェア開発の主流はAgileと呼ばれる、機能ごとに切って別々に開発する方法。
一般的な製造業の開発プロセスとはかなり違う、ソフトウェアならではの開発方法だ。
Waterfallだと、仕様に変更が加わったときに、最初から戻ってやり直さないとならないが、
Agileだと次々に仕様変更があっても、Add-onしていけばよいので、今までのプロセスが余り無駄にならない。
ソフトの種類にもよるので、一概には言えないが、
世界全体ではAgileを含むIterativeなプロセスの採用率が64%なのに、日本では44%に過ぎない、という統計もある。
(2003 IEEE Software "Software Development World Wide")
(追記: Agileの使用率自体はまだ米国含む各国でも低いようです。最近のAgileの日本VS世界比知ってる方いたら教えてください)
>日本では44%に過ぎない、という統計もある。
この統計を見てみたいのですが、どこに載っているのでしょうか?
http://www.publickey1.jp/blog/10/post_82.html
こっちの調査結果は全世界が対象ですが、20~25%程度だそうです。
両者でかなり数字が違うのが気になったので・・・
ご指摘有難うございます。
ソースは授業で先生が見せてくれたグラフで、それを私がノートにメモっておいたんです。
もう一度見直したところ、64%と言う数字は、Agileを含むIterativeなプロセス全体でした。
訂正しておきますね。
ちなみにソースは
2003 IEEE Software, “Software Dev. Worldwide” article
らしいので結構古いですね。
恐らくここで(メッセージを伝えるのに)重要なのは、Agile導入率の世界VS日本比ですが、もしデータを持ってる方がいたら教えてください
ちなみに私はソフトウェアエンジニアではありませんが、色々な国のエンジニアとの付き合いがそこそこあります。
欧州全体という視点はありませんでした。
(実際本当の意味でのソフトウェア産業というものがメインライン度の欧州にあるという印象はあまないです。あくまで印象論)。
UKの場合を経験の範囲で言うと、とてもクリエイティブ。でも結構いきあたりばったりで、つぎはぎだらけでなんでも動かしてしまう。後で破たんすることが多い。
というのが私の理解なので、欧州とは違いますね(でもEUじゃないし欧州じゃないのですがw)
日本のソフトウェアに関する考え方は、ファクトリーオートメーションの様な「自動化」に重点がおかれ、手順の短縮化/効率化を目的とすることが多く、ソフトウェアのレバレッジによって利用者のクリエイティビティを発揮させるという発想が少ないと感じます。
開発の規模、品質、期間そして何より顧客によって
変わります。
中国、インド、ベトナム等で
オフショア開発してるのでハイブリッド型になってきてます。
今は何と言ってもクラウドです。
過渡期が数年続きますが5年、10年経つと
WaterfallかAgileかなんてのは顧客にとって
関係無い話になっている可能性があります。
waterfallだって機能ごとに開発して要求書通りかテストするわけです。
そこだけ読むと誤解を与えるような気もします。
>完成度の低いソフトウェアを勢いで市場に投入するとか絶対にしない。
>技術者のスキルの高さはまるで職人芸。
こんなこと、日本のソフトウェア業界の現実を知っている人は誰一人として信じません。悪い冗談だと思うでしょう。
日本のソフトウェア業界における売り上げの大部分を占めるのは受託開発です。そして顧客(発注者)は誰もが知っている大企業の多くも含めて
恐ろしく無知なので、ソフトの品質を、「わかりやすいバグ」(外面)だけで評価しようとします。
そのため、内面(デザイン・アーキテクチャ)に関しては非常に質が低いことが当たり前になっています。潜在的なバグも多いです。
そもそも、スキル不問で派遣会社から掻き集められた低学歴エンジニアたち「技術者のスキルの高さはまるで職人芸」なんて考えられないでしょう。
8割はアメリカではエンジニアとして採用されないレベルで、2割のまともなエンジニアが必死に残業して尻拭いすることで、「なんとか動く低品質ソフト」を作っているのが現状です。
Lilac様、お時間があったら参考までにお読みになって下さい。
日本のソフトウエア産業、衰退の真因 派遣ビジネスの問題
http://slashdot.jp/~argon/journal/420646
日本人情報技術者のレベルは世界最低?
http://slashdot.jp/askslashdot/03/07/17/0253205.shtml
ガラパゴス化する日本の開発環境
http://remote.seesaa.net/article/149509288.html
ソフトウェアの仕様書は料理のレシピに似ている
http://satoshi.blogs.com/life/2006/03/post_8.html
どうせ理系出身者なんていらねえんだよ。
http://anond.hatelabo.jp/20071105005919
IT業界を目指す若者へ
http://anond.hatelabo.jp/20081125213423
日本のソフトウエア産業、衰退の真因 派遣ビジネスの問題
http://itpro.nikkeibp.co.jp/article/COLUMN/20070306/264055/?ST=management&P=3
数年前のプログラミングカンファレンスでも日本のブログラマがバグの無い品質にこだわっていたのに対し、アメリカのプログラマの注目はスピードと「Agile」ばかりでした。
それぞれの長所を生かすことは良いと思いますが、問題は日本のソフトウェア産業が製造業やゼネコンの構造を受け継いでいることです。
そのため垂直統合なヒエラルキー構造で固まっておりコストが高くなりがちな受託開発、応用の利かないテーラーメイドなシステムを 作り続けています。
ソフトウェアの長所であるネットワーク効果や費用逓減産業の利点を生かすような業態がほとんど生まれていない。
また、多重な偽装請負、マネジメント層の知識のなさも相まって現場では酷い案件も珍しくありません。
現場ではどうしてこれだけの人がこんな仕事をやってるの?
と感じることも少なくなく、非常に勿体無い。
http://japan.cnet.com/blog/kenn/2007/11/09/entry_25001425/
問題点
・構造がソフトウェアに適していない。(非効率)
・マネジメント層がITを理解していない(真のCIOと呼べる人が少ない)
・優秀なエンジニアとビジネスが結びついていない(技術とビジネスを分けて考えている?)
・新しいビジネスモデルが生まれていない(ベンチャースピリットが低い?)
海外で爆発的に成功するIT企業はMicrosoftにしろGoogleにしろ水平レイヤーを抑えるんですよね。
日本では旧き良き伝統?がハイテク産業などから流れているのでなかなか脱却できないでいます。
http://itpro.nikkeibp.co.jp/article/Watcher/20100517/348064/
このまま負のスパイラルに陥り優秀なエンジニアが次々と消えていかないか心配です。