日経SYSTEMS 2012年4月号の特集１が「システムを育てるカイゼン型開発のススメ」ということで、Part4に私も寄稿させて頂きました。ソニックガーデンが今のビジネスモデルを採用した理由について書きました。
「カイゼン型開発」という言葉は、2006年に私がブログで書いたのですが、ようやく時代が追いついてきたのかと感慨深いものがあります。そして、2012年の私たちは既にそこからさらに先に進んでいて、その答えとなる「納品のない受託開発」というビジネスモデルに辿り着いています。
実際に掲載された寄稿記事の方では割とコンパクトにまとめてもらいましたが、こちらではディレクターズカットということで元々に書いた原稿の方を公開します。もし、このブログよりもさっと読みたい場合は日経SYSTEMSを読んで頂くのが良いかと思います。
SonicGardenでカイゼン型開発を行う理由
ソニックガーデンでは「納品のない受託開発」という少し変わったスタイルでの受託開発を行っています。図１の左上の領域です。
ソフトウェアの受託開発と言えば、これまでは図１左下の一括請負による納品型のビジネスモデルが主流ですが、実はそのビジネスモデルはお客様にとってもベンダーにとっても、そして開発者にとっても不幸になる問題をはらんでいると考えているからです。
「一括納品モデル」がもたらす問題
一括請負による契約の納品型のビジネスモデル（以降、一括納品モデル）では、発注者とベンダーはあらかじめ決められた金額と要件の中で納品と検収を目指して開発を行います。
そのために発注者は発注前にすべての要件を決める必要があり、発注後は当初に決めた要件を途中で変えることは基本的に不可能となります。
このビジネスモデルの中では「仕様変更」とは追加費用が発生するものであり、初期の想定違いや技術的なリスクによって発生する仕様変更にかかる費用を、プロジェクトの途中で発注者とベンダーでどちらが負担するのかで揉めることも多くあります。
「要件定義」で解決するのか？
そうした問題を解決するためにベンダーが考えたことは、いわゆる「要件定義」と呼ばれる工程でしっかりと、要件を洗い出して計画を立てることが重要だということでした。
事前にすべての要件を並べだし、問題点やリスクを洗い出すことで、計画通りに開発が進められるようにしようということです。
しかし、果たしてそれは発注者であるお客様にとって、本当にメリットのあることなのでしょうか。システム開発の初期の時点で考えた「計画通りに」システムが「完成」したとして、本当にお客様にとって役に立つのかというと、はたして疑問です。
