「納品のない受託開発」ってどういうこと?新しいシステム開発の方法論

倉貫義人氏が唱えるのは「納品のない受託開発」という新しいビジネスモデル。インターネットを活用した新規事業に関わる人にとって、参考になる考え方が豊富に掲載された一冊を要約しました。ビジネスパーソンやシステム開発の受託を行うエンジニアにお勧めです。

「納品」をなくせばうまくいくソフトウェア業界の“常識”を変えるビジネスモデル

タイトル:「納品」をなくせばうまくいくソフトウェア業界の“常識”を変えるビジネスモデル

著者:倉貫義人著

ページ数:240ページ

出版社:日本実業出版社

定価:1,728円(税込)

出版日:2014年06月12日

Book Review

あなたは「納品のない受託開発」という言葉をご存知だろうか。少しでもシステム開発の受託に関わったことがある人であれば、「納品」が「ない」という言葉の繋がりに驚かれることだろう。多くのシステムインテグレーターは、要件定義という事前の取り決めに則って、その完成(納品)を目指してエンジニアたちが猛烈に努力するものなのである。
しかし、「納品のない受託開発」ではそもそも要件定義すら行わないのだという。特に新規事業に伴うシステム開発の場合、ビジネスの状況変化を受け、日々要件は変わっていくものであり、初期段階での要件定義自体が困難なものだからだ。エリック・リース著の「リーン・スタートアップ」が発刊されて以降、ベンチャー企業の新規事業のアプローチとしてMVP、すなわち「検証に必要な最低限の機能を持った製品」を市場に出した上で、迅速に市場からフィードバックを得るべし、という考え方が主流になっている。「納品のない受託開発」を行う受託者は、正にそのようなアプローチに適した存在であると言えるだろう。
著者の倉貫氏は、TISに勤める傍ら、アジャイル開発を日本に広める活動を行った後、社内ベンチャーを立ち上げ、MBOを行い独立した、経験豊富なエンジニアである。その著者が薦める、スタートアップを下支えする新しいシステム開発受託の方法論は、今後新たな潮流になる可能性を秘めている。本書はインターネットを活用した新規事業に関わる方にとって、参考になる考え方が豊富に掲載されており、特に新規事業担当という花形ポストを務めるビジネスパーソンやシステム開発の受託を行うエンジニアにこそ一読を薦めたい書である。

常識をくつがえす「納品のない受託開発」とは

「納めて終わり」からの脱却

「受託開発」は、最初に作るものを決め、コストを見積もり、開発後納品を行うプロセスが一般的である。このビジネスモデルはいわゆる「一括請負」と言われ、「ソフトウェアを納める」ことをゴールに据えている。一方で、納品後にソフトウェアを使い始めることから、発注者(顧客)と受託者の間ですれ違いが多く発生するのが難点となる。
そこで著者は、受託開発であっても「納品はしない」という方法論を実践している。その方法論では、「納めて終わり」ではなく、顧客のビジネスに合わせて、一緒にソフトウェアを成長させていく関係を構築しようという方針をとる。「納品のない受託開発」は、これまでのソフトウェア業界にある古い商慣習を一新する新しいモデルになる可能性を秘めている。
この新しいモデルを追求することにより、本当に必要な機能を、本当に必要な順番に、少しずつ開発をしていくことが可能になるのである。

要件定義に対する疑問

そもそも要件定義とは誰のためにあるのだろうか。顧客が実現したいのは、そのソフトウェアを使ってビジネスで成果を上げることであるはず。コスト削減や売上の向上、あるいは新たな価値の創造を志向するものだ。そのため、要件定義時点では顧客にとっての価値は一切生じていないのである。
それでも要件定義が必要なのは、実は開発会社の都合によるところが大きいという。受託者の発想から、「事前に何を作るかをしっかり決めておく」ことが見積もりや納品というプロセス上、必要になっていたのだ。
更に見積もりの単位となる「人月」という考え方にも問題がある。それは、何人のエンジニアがどれだけの期間働けば完成するか、という指標を基準にソフトウェアの開発費用を「見える化」しようというものだ。
本当に優秀なエンジニアにより3人で3ヶ月かかる場合と、ダメなエンジニアにより10人で10ヶ月かかる場合と、顧客にとってどちらが良いかは自明である。しかし開発会社にとって、売上が大きいのは後者になってしまうということに構造的な問題があるのだ。

ソフトウェアはなぜそんなに高いのか?

ソフトウェアの開発コストが高すぎるのではないか、と考える方も多いだろう。特にでき上がったソフトウェアに対して改修を依頼した際に、想像以上の金額の見積りが返ってきて驚いた、という話をよく耳にする。例えば、画面の文章を一部直すのに十数万円という見積もりが出てくるケースもあるという。
ではどうしてそのような見積りがなされるのだろうか。その答えは各所で積み上げられるバッファにある。これは開発者サイドで、期限内の完成をコミットするために、想定外のリスクへの懸念からバッファを積む、という行動を指している。
バッファが大きくなるのは特に開発者サイドが外注を使っている場合である。まず一次請けのマネージャーがバッファを積む。次に二次請け以下のエンジニアがその全ての階層でバッファを積み上げてしまうのである。念のため、念のためとそれぞれがリスクを勘案した結果、実態とかけ離れた見積りとなってしまうことになるのだ。

月額定額の受託開発

そこで辿り着いた考え方が、問題の根源は「納品にある」という仮説。納品があるから見積りが必要で、人月にはバッファが入り、無理にでも要件定義をしなければいけなくなる。更に開発と運用の担当者が分かれている際には、引き継ぎコストが乗せられていく。
それに対して、著者の会社では「月額定額」の料金体系をとり、その範囲内で精一杯の「開発と運用」を一貫して行うのだという。顧問弁護士や顧問税理士のような「顧問」の形態に近い、顧問エンジニアとも言える。
また、発注者側でエンジニアを自社で採用(内製化)することが理想的であるものの、エンジニアの目利きが難しく、採用後の評価も適切に行えないことが多いことから、IT企業を除き優秀なエンジニアを囲うのが難しいという問題もある。そこで、「納品のない受託開発」では、担当のエンジニアが顧客の内製部隊として、ソフトウェアのライフサイクル全てを受け持とうというのだ。
月額定額の「納品のない受託開発」には、見積りが存在せず、バッファも積まれず、そのため、ムダなコストを削減することが可能になるのである。

時代にマッチした「納品のない受託開発」

スタートアップに適したシステム開発とは

実際に「納品のない受託開発」に問い合わせがある企業のほとんどは、新しく起業して新規事業を行うスタートアップと呼ばれる会社だという。その共通の課題は、新規事業におけるインターネットのサービスを開発できる人材が社内にいない、ということだ。
そのようなスタートアップが一括請負形式の開発会社に話を持って行くと、まず要件定義を行うことになる。ここで新規事業と要件定義の相性の悪さが露呈する。これから手探りで事業を進めていくのに、将来において有効なシステム要件など作れるはずがないのである。
現在のIT業界の潮流として、スモールスタートで始め、徐々にスケールアウトする、リーン・スタートアップという概念が一般的になっている。つまり、事業初期はその事業の検証を行うため、なるべく少ないコストで始め、ユーザーの評価が得られた段階で一気に事業規模を拡大していくのである。「納品のない受託開発」は、要件定義も納品という区切りも存在しないため、そのようなスタートアップにもフィットするのだ。

「納品のない受託開発」で解決できること

「納品のない受託開発」では、要件定義をしなくてもよいというメリットが存在する。実際の動き方は、最初に1ヶ月~3ヶ月でできる最小限の機能を決めて開発を進め、できるだけ早く運用に入るのである。金額に関しても月額定額のため、どれだけ仕様変更しても構わない。もちろん当初予定していた機能の作成が、優先順位の変更で後回しになることはあるが。
著者が実際に経験した最も大きい仕様変更は、作ったソフトウェアをまるごと全部捨ててしまい、ゼロから作り直したという事例だそうだ。2ヶ月かけたソフトウェアを事業の見直しに合わせて、一度オシャカにして、新しい市場向けに作り直したのである。そのような場合でも要件定義というプロセスがないため、金銭的なダメージが発生しないのだ。
また、「作らない提案」をすることも構造上行いやすくなる。従来の一括請負であれば、作業量に応じて受注額が変わるため、顧客の思いつきの機能でも、喜んで提案書を作成する業者が多かった。一方で、「納品のない受託開発」では顧客との長期的関係が基盤になるため、あえて不必要な機能を作らない提案を行い、事業にとって真に価値あるものに開発をフォーカスするのである。

「納品のない受託開発」を支える技術とマネジメント

エンジニアに求められるパラダイムシフトへの対応

「納品のない受託開発」では、ソフトウェアを「所有する」という考え方から「利用する」という考え方に、顧客の考え方を変えてもらうことになる。その裏返しとして、開発会社のエンジニア側にも、「完成する」ことから「持続する」ことに、パラダイムシフトが必要となる。それに伴い次のように考え方が変わることになる。
・バグをなるべく出さないようにする → バグが出てもすぐに直せるようにする
ソフトウェアがうまく動かない不具合である「バグ」を出さないように、もちろん最善の努力が必要である。しかし、そもそもソフトウェアというものは100%バグがないということはありえない。納品がある場合は、納品までにバグをつぶさなくてはならず、開発現場は右往左往することになる。だが、「納品のない受託開発」では、もしバグが発覚したとしてもすぐに直せるようにしておくことが重要となる。
・サーバーは停止しないようにする → 停止してもすぐに復旧できるようにする
「納品のない受託開発」では、サーバー環境としてクラウドのサービスを利用している。それでも絶対大丈夫ということはありえない。仮に大きなコストをかけて、サーバーが停止しないように対策を施しても、「絶対」はないのである。そこで、いずれ壊れたり止まったりすることを前提に、停止から復旧までの時間をどれだけ短くするかを考えるのだ。
・機能追加をやりやすいように作っておく → 今どうしても必要なものだけに集中する
一般的に優秀なエンジニアほど、「汎用的に」作ることを心掛け、今後の追加要望に備えてその仕組みを事前に作っておく傾向がある。その後実際に予想通りの機能が求められたときに、待ってましたと迅速に対応できるからだ。しかし、それではその機能が求められなかった場合に、無駄な機能となってしまうだけでなく、ソフトウェア内部に余計な「複雑さ」を持ち込んだが故に、改修の妨げになる可能性もある。そのため、「必要になるまで作らない」という方針を徹底しているのだ。

扱う技術の統一化

「納品のない受託開発」を円滑に進めるために、使う技術を会社で統一しているのだという。具体的には、プログラミングは「Ruby」と「Ruby on Rails」、実行するクラウド環境は「AWS(Amazon Web Services)」か「Heroku」、オペレーティングシステムは「Linux」などといった形で、推奨技術を定めているのである。
ただし、この推奨技術は時代とともに変化していくのだという。
しかし、推奨技術を定めたとしても、「納品のない受託開発」では、一度契約が始まるとパートナーとしてずっとお付き合いするので、エンジニアにも多様なスキルが必要となる。それは技術的な面に留まらず、顧客満足を実現するための営業的な側面も担うことも含まれる。そしてサッカー選手でドリブルだけしかできないプロ選手はいないように、できるだけ多くのことを一人でカバーする。それでも残る得意不得意を補い合えるのが、会社という場所の価値になるのだと著者は述べている。

※当記事は株式会社フライヤーから提供されています。
copyright © 2024 flier Inc. All rights reserved.

著者紹介

倉貫義人(くらぬきよしひと)

1974年京都生まれ。1999年立命館大学大学院を卒業、TIS(旧東洋情報システム)に入社。エンジニアとしてキャリアを積みつつ、「アジャイル開発」を日本に広める活動を続ける。2005年に社内SNS「SKIP」の開発と社内展開、その後オープンソース化を行う。2011年自ら立ち上げた社内ベンチャーをMBOによって買収、株式会社ソニックガーデンを創業する。「納品のない受託開発」というITサービスの新しいビジネスモデルを確立し、注目を集める。ビジネスとソフトウェア開発に関するブログ「Social Change!」を執筆。
《本の要約サイトflier フライヤー》は、話題の書籍や名著を1冊10分にまとめた要約が読めるサービスです。経営者や大学教授などの著名人・専門家などが「ビジネスパーソンがいま読むべき本」を一冊一冊厳選し、経営コンサルタントなどのプロフェッショナルのライターが要約を作成しているので内容の信頼性も安心。無料ユーザー登録をすれば、20冊分の要約を読むことができます。