「納品」をなくせばうまくいく

ソフトウェア業界の“常識”を変えるビジネスモデル
未読
「納品」をなくせばうまくいく
「納品」をなくせばうまくいく
ソフトウェア業界の“常識”を変えるビジネスモデル
未読
「納品」をなくせばうまくいく
出版社
日本実業出版社
出版日
2014年06月20日
評点
総合
3.8
明瞭性
3.5
革新性
4.5
応用性
3.5
要約全文を読むには会員登録ログインが必要です
ログイン
本の購入はこちら
書籍情報を見る
本の購入はこちら
おすすめポイント

あなたは「納品のない受託開発」という言葉をご存知だろうか。少しでもシステム開発の受託に関わったことがある人であれば、「納品」が「ない」という言葉の繋がりに驚かれることだろう。多くのシステムインテグレーターは、要件定義という事前の取り決めに則って、その完成(納品)を目指してエンジニアたちが猛烈に努力するものなのである。

しかし、「納品のない受託開発」ではそもそも要件定義すら行わないのだという。特に新規事業に伴うシステム開発の場合、ビジネスの状況変化を受け、日々要件は変わっていくものであり、初期段階での要件定義自体が困難なものだからだ。エリック・リース著の「リーン・スタートアップ」が発刊されて以降、ベンチャー企業の新規事業のアプローチとしてMVP(minimum viable product)、すなわち「検証に必要な最低限の機能を持った製品」を市場に出した上で、迅速に市場からフィードバックを得るべし、という考え方が主流になっている。「納品のない受託開発」を行う受託者は、正にそのようなアプローチに適した存在であると言えるだろう。

著者の倉貫氏は、TISに勤める傍ら、アジャイル開発を日本に広める活動を行った後、社内ベンチャーを立ち上げ、MBOを行い独立した、経験豊富なエンジニアである。その著者が薦める、スタートアップを下支えする新しいシステム開発受託の方法論は、今後新たな潮流になる可能性を秘めている。本書はインターネットを活用した新規事業に関わる方にとって、参考になる考え方が豊富に掲載されており、特に新規事業担当という花形ポストを務めるビジネスパーソンやシステム開発の受託を行うエンジニアにこそ一読を薦めたい書である。

ライター画像
大賀康史

著者

倉貫 義人(くらぬき よしひと)
1974年京都生まれ。1999年立命館大学大学院を卒業、TIS(旧東洋情報システム)に入社。エンジニアとしてキャリアを積みつつ、「アジャイル開発」を日本に広める活動を続ける。2005年に社内SNS「SKIP」の開発と社内展開、その後オープンソース化を行う。2011年自ら立ち上げた社内ベンチャーをMBOによって買収、株式会社ソニックガーデンを創業する。「納品のない受託開発」というITサービスの新しいビジネスモデルを確立し、注目を集める。ビジネスとソフトウェア開発に関するブログ「Social Change!」を執筆。

本書の要点

  • 要点
    1
    「納品のない受託開発」により、本当に必要な機能を、本当に必要な順番に、少しずつ開発をしていくことが可能になる。
  • 要点
    2
    「納品のない受託開発」では、顧問弁護士や顧問税理士のような「顧問」の形態に近い、顧問エンジニアとも言える立場で、システムの企画から運用まで一貫した関与形態をとる。
  • 要点
    3
    開発会社のエンジニアでは、「完成する」ことから「持続する」ことに、パラダイムシフトが必要となる。それに伴い次のように考え方が変わることになる。(1)バグをなるべく出さないようにする → バグが出てもすぐに直せるようにする、(2)サーバーは停止しないようにする → 停止してもすぐに復旧できるようにする、(3)機能追加をやりやすいように作っておく → 今どうしても必要なものだけに集中する

要約

【必読ポイント!】常識をくつがえす「納品のない受託開発」とは

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

「受託開発」は、最初に作るものを決め、コストを見積もり、開発後納品を行うプロセスが一般的である。このビジネスモデルはいわゆる「一括請負」と言われ、「ソフトウェアを納める」ことをゴールに据えている。一方で、納品後にソフトウェアを使い始めることから、発注者(顧客)と受託者の間ですれ違いが多く発生するのが難点となる。

そこで著者は、受託開発であっても「納品はしない」という方法論を実践している。その方法論では、「納めて終わり」ではなく、顧客のビジネスに合わせて、一緒にソフトウェアを成長させていく関係を構築しようという方針をとる。「納品のない受託開発」は、これまでのソフトウェア業界にある古い商慣習を一新する新しいモデルになる可能性を秘めている。

この新しいモデルを追求することにより、本当に必要な機能を、本当に必要な順番に、少しずつ開発をしていくことが可能になるのである。

要件定義に対する疑問
FuseThinkstock

そもそも要件定義とは誰のためにあるのだろうか。顧客が実現したいのは、そのソフトウェアを使ってビジネスで成果を上げることであるはず。コスト削減や売上の向上、あるいは新たな価値の創造を志向するものだ。そのため、要件定義時点では顧客にとっての価値は一切生じていないのである。

それでも要件定義が必要なのは、実は開発会社の都合によるところが大きいという。受託者の発想から、「事前に何を作るかをしっかり決めておく」ことが見積もりや納品というプロセス上、必要になっていたのだ。

更に見積もりの単位となる「人月」という考え方にも問題がある。それは、何人のエンジニアがどれだけの期間働けば完成するか、という指標を基準にソフトウェアの開発費用を「見える化」しようというものだ。

本当に優秀なエンジニアにより3人で3か月かかる場合と、ダメなエンジニアにより10人で10か月かかる場合と、顧客にとってどちらが良いかは自明である。しかし開発会社にとって、売上が大きいのは後者になってしまうということに構造的な問題があるのだ。

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

ソフトウェアの開発コストが高すぎるのではないか、と考える方も多いだろう。特にでき上がったソフトウェアに対して改修を依頼した際に、想像以上の金額の見積りが返ってきて驚いた、という話をよく耳にする。例えば、画面の文章を一部直すのに十数万円という見積もりが出てくるケースもあるという。

ではどうしてそのような見積りがなされるのだろうか。その答えは各所で積み上げられるバッファにある。

もっと見る
この続きを見るには...
残り2975/4063文字
会員登録(7日間無料)

3,400冊以上の要約が楽しめる

要約公開日 2014.07.22
Copyright © 2024 Flier Inc. All rights reserved.
一緒に読まれている要約
見抜く経済学
見抜く経済学
渡邉哲也
未読
ヒットの正体
ヒットの正体
山本康博
未読
独裁力
独裁力
木谷哲夫
未読
「フォロワー」のための競争戦略
「フォロワー」のための競争戦略
手塚貞治
未読
そして、奇跡は起こった!
そして、奇跡は起こった!
ジェニファー・アームストロング灰島かり(訳)
未読
フラクタリスト ―マンデルブロ自伝―
フラクタリスト ―マンデルブロ自伝―
ベノワ・B・マンデルブロ田沢恭子(訳)
未読
振り切る勇気
振り切る勇気
田中仁
未読
カラスの教科書
カラスの教科書
松原始
未読
法人導入をお考えのお客様