【必読ポイント!】常識をくつがえす「納品のない受託開発」とは
「納めて終わり」からの脱却
「受託開発」は、最初に作るものを決め、コストを見積もり、開発後納品を行うプロセスが一般的である。このビジネスモデルはいわゆる「一括請負」と言われ、「ソフトウェアを納める」ことをゴールに据えている。一方で、納品後にソフトウェアを使い始めることから、発注者(顧客)と受託者の間ですれ違いが多く発生するのが難点となる。そこで著者は、受託開発であっても「納品はしない」という方法論を実践している。その方法論では、「納めて終わり」ではなく、顧客のビジネスに合わせて、一緒にソフトウェアを成長させていく関係を構築しようという方針をとる。「納品のない受託開発」は、これまでのソフトウェア業界にある古い商慣習を一新する新しいモデルになる可能性を秘めている。この新しいモデルを追求することにより、本当に必要な機能を、本当に必要な順番に、少しずつ開発をしていくことが可能になるのである。
要件定義に対する疑問
そもそも要件定義とは誰のためにあるのだろうか。顧客が実現したいのは、そのソフトウェアを使ってビジネスで成果を上げることであるはず。コスト削減や売上の向上、あるいは新たな価値の創造を志向するものだ。そのため、要件定義時点では顧客にとっての価値は一切生じていないのである。それでも要件定義が必要なのは、実は開発会社の都合によるところが大きいという。受託者の発想から、「事前に何を作るかをしっかり決めておく」ことが見積もりや納品というプロセス上、必要になっていたのだ。更に見積もりの単位となる「人月」という考え方にも問題がある。それは、何人のエンジニアがどれだけの期間働けば完成するか、という指標を基準にソフトウェアの開発費用を「見える化」しようというものだ。本当に優秀なエンジニアにより3人で3か月かかる場合と、ダメなエンジニアにより10人で10か月かかる場合と、顧客にとってどちらが良いかは自明である。しかし開発会社にとって、売上が大きいのは後者になってしまうということに構造的な問題があるのだ。
ソフトウェアはなぜそんなに高いのか?
ソフトウェアの開発コストが高すぎるのではないか、と考える方も多いだろう。特にでき上がったソフトウェアに対して改修を依頼した際に、想像以上の金額の見積りが返ってきて驚いた、という話をよく耳にする。例えば、画面の文章を一部直すのに十数万円という見積もりが出てくるケースもあるという。ではどうしてそのような見積りがなされるのだろうか。その答えは各所で積み上げられるバッファにある。
