Hotwired 第4回 「顧客がソフトウェア産業を育てる」 （2005年1月）
最も効率的なシステム構築方法
今回はまず、最も安上がりのシステム構築方法をお教えしよう。それは、外注しないで自社開発することでもないし、生産性の高いプログラマだけを集めて開発チームをつくることでもない。特別な仕組みも技能も必要としない、誰でもできる簡単な方法である。
それは、すでに誰かが開発したソフトウェアを利用（再利用）するという方法である。
IBM360のOS開発を指揮したフレデリック・Ｐ・ブルックスは、その著書『人月の神話』の中で「ソフトウェア構築について考えられるもっとも極端な解決策は、まったく自主開発しない、というものだ」と述べている(1)。つまり、既存のソフトウェアを再利用することこそが最も安上がりのシステム構築方法なのである。既存のソフトウェアは、同業他社が開発したものでもよいし、パッケージソフトウェアでもよい。
(1) フレデリック・P・ブルックス・Jr. 『人月の神話 ?狼人間を撃つ銀の銃弾はない』ピアソン・エデュケーション（2002）、p.183
たとえば、ある企業が商品の受発注のためのソフトウェア開発を外注し、10億円を支払ったとしよう。もし、同業種の企業が10社集まり、共同開発すれば1社あたりの負担額は1億円になる。もし、このソフトウェアが他業種でも利用可能で、1000社が導入するものであれば、1社あたりのコストは100万円ですむ計算になる。100万円の投資で10億円の価値のあるソフトウェアを入手できる。
これを開発する側から考えれば、別に1企業100万円で販売する必要はない。なにしろ個別に開発すれば10億円もかかるソフトウェアなのだ。500万円、いや1000万円でも売れるかもしれない。もし、500万円で1000社に販売でき、開発コストが10億円だと仮定すると、差し引き40億円の利益が出ることになる。これがパッケージソフトのビジネスである。
パソコンの世界ではパッケージソフトの利用が極めて一般的になっているので、当たり前だと思う読者も多いだろう。しかし、企業の情報システムにおけるパッケージソフトの利用は、パソコンの世界ほどに普及していない。特に日本の企業は、米国の企業に比べて、パッケージソフトの利用率が低い。図表-1は、日米の企業におけるパッケージソフトの利用状況を見たものである。米国では8割の企業がパッケージソフトを利用しているのに、日本では4割強である。なんと半分以上の企業が、ソフトウェアを独自に開発している。
日本企業と米国企業との間で、業務内容やビジネスの方法にそれほど差があるとは思えない。これはどうしたことなのだろうか。
日本でパッケージソフトが発達しなかった理由
日本においてパッケージソフトの利用が進まない原因については、過去から何度も議論されてきている。拙著『ソフトウェア最前線』でも、過去に指摘された４つの理由を取り上げた。
第１の理由は、日本企業は情報システムの細部にこだわり、他の企業の情報システムとは異なっているという独自性を好むからである。画面や帳票のフォーマットにこだわるケースもあるし、同業他社と同じシステムでは差別化ができないという理由で、独自仕様のシステムを構築しようとするという説である。
第２は、エンドユーザーのリテラシーや技術レベルが高くないためにパッケージソフトに業務を適合させることができないからという理由である。業務用パッケージソフトは、ある仕事の流れを仮定して開発されているため、仕事の進め方や組織の役割分担を見直す必要が出てくる。また、独自開発のソフトウェアと違って、細かなところまで作り込みがなされていないので、エンドユーザーの負担が重くなることがある。これがパッケージソフト導入の障害になっているという説である。
第３は、日本特有の歴史的背景に原因を求める説である。米国では、ある時期からIBMが市場の大半を握っていたのに対して、日本では数社が市場を分け合っており、各社のコンピュータ間に互換性がなかったため、パッケージソフトの市場が分断されて小さくなっており、ソフトベンダーからみて魅力的ではなかったからだという説である。現在ではオープン・システムが普及したため、この理由で現状を説明するのは難しくなっている。
第４は、ソフトウェアベンダー側に原因があったという説である。パッケージソフトのビジネスは成功すれば儲けは大きいが、失敗すると大赤字になる。たとえば、10億円で開発したパッケージソフトを500万円で販売し、1000社に販売できれば40億円の粗利が出るが、100社にしか売れなければ5億円の赤字になってしまう。つまりリスクが大きいパッケージソフトを開発するより、よりリスクの小さい受託開発ビジネスを選択するソフトベンダーが多かったのだという説である。
もう一つの仮説
以上が、拙著で取り上げた理由であるが、最近になって新しい原因の可能性に気付いた。
それは、日本ではソフトウェア開発が完全に破綻するケースが少なかったからという理由である。ソフトウェア開発に関連する文献を読んでいると、日本より米国の方がソフトウェア開発プロジェクトが破綻するケースが多いように思える。ここで言う「破綻」とは、最後までシステムが稼働しなかったという意味である。
日本でプロジェクトが破綻するケースが少ないのは、日本のソフトウェア・ベンダーが優秀な証拠だと考えることもできるが、契約方式の違いによるものの可能性が高い。日本では、ソフトウェア開発は、一括して定額契約（請負契約）で実施するケースが多いからである。この契約方式の場合、契約に定められた成果物を納入しないと対価が受け取れない。したがって、ベンダーは予算が超過しても、少しでもコストを回収しようと、システムが動くまで頑張ることになる。
一方、米国ではプロジェクトによって様々な契約が行われている。例えば、実際に要したコストに適正な利潤を加えるタイプのコスト保証型の契約の場合、プロジェクトの進捗に応じて経費が支払われる。この場合（もちろん契約内容にもよるのだが）、プロジェクトが泥沼化すると、開発費は際限なく膨らんでいくことになる。こうなると、発注者側がプロジェクトの中止を宣告しないと大変なことになる。かくして、システムが完成しなかったプロジェクトでは、発注者側は巨額の開発費をどぶに捨てることになってしまう。
こんな事情から、米国では個別開発が失敗する危険性が高かったために、使い勝手は悪いがリスクが小さいパッケージソフトの導入を選ぶ企業が多くなったのではないだろうか。言い換えれば、日本では、システム開発のリスクをソフトウェアベンダーがすべて負う形の契約でプロジェクトが進められており、トラブルが生じてスケジュールの遅延や予算超過が起きても、最後にはなんとかシステムが完成するケースが多い。このために、パッケージソフトを利用するインセンティブが小さくなり、パッケージソフトの利用が進まなかったのではないかと思っている。もちろん、これは今後、検証が必要な仮説である。
カスタマイズはできる限りしないほうがよい
さて、既存のソフトウェアを利用することが、最も安上がりのシステム構築方法ではあるが、ここに一つの落とし穴がある。それは、ソフトウェアのカスタマイズという問題である。
パッケージソフトは、そのソフトが対象とするすべての企業のニーズを満たすように設計されてはいない。したがって、部分的に修正したいという要求が出てくる。実際にパッケージソフトを利用しているユーザーのほとんどは、どこかをカスタマイズしている。そうした企業が、パッケージソフトをバージョンアップしようとすると、再度カスタマイズの作業が必要になる。問題はここで発生する。最初のカスタマイズの程度によるが、カスタマイズのコストなどの問題で事実上バージョンアップできなくなってしまう可能性があるのだ。これは大問題である。
多くのパッケージソフトは、ある程度のカスタマイズを想定して作られている。ソースコードレベルでの修正なしにカスタマイズ可能なものもあれば、ソースコードに影響を与えないように前もってプラグインのインタフェースが決まっているものもある。こうしたカスタマイズなら問題は少ないのだが、ソースコードレベルでカスタマイズを行うと、バージョンアップ時にも導入時と同様のカスタマイズ費用が発生することを覚悟しておく必要がある。
そもそも、ソースコードレベルで変更を加えると、導入時や運用時にトラブルが発生する可能性が高くなり、テストも大変になる。現実に、運用時のトラブルは、そもそものパッケージ本体部分より、カスタマイズされた部分が原因で発生することが多い。
ニューヨーク時代に、あるITコンサルタントから代表的なERPパッケージであるSAP R/3について話を聞いたが、R/3はベストプラクティスを集大成したものであるので、各企業の業務手順や組織にあわせてソフトウェアをカスタマイズするのではなく、このソフトウェアにあわせて導入する企業の業務手順や組織を変えるように指導していると語っていた。
余談であるが、パッケージソフトを利用したのでは、情報システムによって同業他社と差別化できなくなるという心配をする経営者がいるかもしれない。しかし、心配には及ばない。情報システムそれ自体によって競争優位を得られるというのは、一部の経営者とITベンダーの幻想だからである。古くはアメリカン航空のSabre、アメリカン・ホスピタル・サプライのASAPなどの情報システムが、それぞれの企業に持続的な競争優位をもたらしたと言われている(2)。80年代には戦略情報システム（SIS）とも呼ばれたシステムである。しかし、これらは極めて希な事例であると同時に、本当に持続的な競争優位をもたらしたのかも疑わしいと思っている。少なくとも現在では、ニコラス・カーが言うようにITは競争優位をもたらす源泉ではなくなっている(3)。競争優位をもたらすものは、企業のITケイパビリティ（ITを使いこなす能力）だと私は思っている。
(2) Sabreはアメリカン航空が開発した旅行代理店向けの座席予約システムであり、ASAPは病院が必要な医薬用品を発注するためのオンライン・システムであった。
(3) Nicholas G. Carr, "Does IT Matter?", Harvard Business School Publiching
理不尽な顧客の要求
独自システムを開発するのではなく、できる限りパッケージソフトを利用し、さらにパッケージソフトの利用効果を最大にするためにカスタマイズを最小限に留めることが重要である。しかし、それでもソフトウェアを個別に開発する必要性がなくなるわけではない。それは、パッケージソフトがカバーしきれない部分があるからである。
したがって、パッケージソフトの利用が増えたとしても、受託開発型ソフトウェアの生産性と質を向上させることは、依然として重要な課題である。
この連載の第２回と第３回では、ソフトウェアの生産性と品質の向上を阻害している問題を主にソフトウェアベンダー側から考えてきた。第２回では、多くのプロジェクトで利用されているウォーターフォール・モデルが、実はソフトウェア開発には適していないものであり、アジャイルソフトウェア開発というパラダイムシフトが起きつつあるという問題をとりあげた。第３回では、プログラマの生産性は個人によって大きな差があるにもかかわらず、日本のソフトウェア業界では年功序列型の賃金を採用しており、これが原因で恒常的な残業と優秀な人材不足という悪循環が生じているという問題を取り上げた。
これらは、すべて主としてソフトウェアを開発する側の問題であるが、ソフトウェアを発注する側、ユーザー側には何の問題もないのだろうか。とてもそうとは思えない。実際、開発側の人々を対象にしてヒアリング調査では、ユーザー側に対する不満を山ほど聞かされた。
「プロジェクト開始時点でまだ仕様書が固まっていなかった」「システム開発に影響を及ぼす重要な制約条件が仕様書に書いてなかった」「仕様の書き方が曖昧で工数の見積もりができない」「こちらが見積もった金額をまったく無視したような低額の開発費を提示された」「プロジェクトの途中で仕様変更を要求してくる」「無計画な機能拡張を強要された」「システム部門と他の部門とで言っていることが異なっている」
こうした不満の中には、ウォーターフォール・モデルによる開発ではなく、アジャイルソフトウェア開発を採用することによって、ある程度解消できるものもある。しかし、この多くは、発注側のソフトウェアに対する無理解から生じている不満でもある。
ソフトウェア開発を発注する側は、少なくとも次の２つの事実をよく考えていただきたい。
第１の事実は、ソフトウェアは目に見えないということである。必要な機能と性能を備えたソフトウェアが完成したかどうか納品されたドキュメントを見ても確認できないし、ましてやプログラムのコードを眺めても確認することはできない。もし、本気でよいシステムを構築する気があるなら、発注者側でテストデータを作成し、自ら受け入れテストをすべきである。
第２の事実は、完璧な仕様書を書くのは不可能だということである。誰にも誤解されない文章を書くのは容易なことではないし、言葉の多義性まで考えると、ソフトウェアの仕様を自然言語で表現するのは限界がある。どのような仕様書であっても、それはある種の仮説にすぎない。その仮説はプログラムによって検証される。
この２つの事実を考えると、発注側も開発チームの一員としてプロジェクトに参加する必要があるだろう。また、ソフトウェアの開発は、仮説と検証のサイクル、つまり要求定義から設計、コーディング、テストまでのサイクルを繰り返すスパイラル型で行うことが最も合理的なのである。
店が客を育て、客が店を育てる
美味しいレストランが集まっている地域には、味の違いがわかる人たち住んでいる。なぜなら、美味しいレストランは腕のよいコックがよい素材を使って料理を作っているので、それなりの価格になる。仮に、味の分からない人ばかりしかいなければ、美味しいレストランにやってくる客はいなくなるだろう。味の違いが分からないなら、あえて価格の高いレストランを選ばないからである。そうなれば、美味しいレストランは、食材の質を下げ、高給をとっている腕のよいコックを首にしてコストを削減するか、味のわかる人たちが住む地域に引っ越すしかなくなる。かくして、味の違いが分からない人たちばかりの地域には美味しいレストランはなくなってしまう。
ソフトウェア産業も同じである。味の違いのわかる客とは、ソフトウェアの価値をきちんと評価できるユーザーであり、美味しいレストランが技術力のあるよいソフトウェア企業である。ソフトウェアの本質をよく理解し、ソフトウェアの価値がわかるユーザーが集まらなければ、優れたソフトウェアをつくる企業は育たない。
とにかく安くシステム構築をすることしか考えていないユーザーばかりの国には、競争力のあるソフトウェア産業が育つわけがない。古くから「店が客を育て、客が店を育てる」という言葉があるが、これはソフトウェアの世界にも当てはまる。日本のソフトウェア産業を育てるのはユーザーなのである。
この記事が気に入ったらサポートをしてみませんか？