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

著者 : 倉貫義人

• 日本実業出版社 (2014年6月12日発売)

感想・レビュー・書評

[おひるねさんの感想 · 2015年3月26日]

エンジニアという人々に、
僕はこの１年くらいで結構会うようになったのだけれど、
「技術」については関心が高い人は多いのだが
「技術の事業への活かし方」について熱意を持っている人はあまりいない。

これは批判や文句ではない。
世間がエンジニアという人々に対して持つイメージの中にも
当事者の中の職業観にも、それが含まれていない以上当然な気がする。

だが、本書で著者が語るのは、まさにその当然をひっくり返した
チャレンジの実体験と、幸せなエンジニアリングのキャリア論である。

このキャリアでは、エンジニアは「技術が大好き」「開発大好き」な
人ではない。
むしろ、ビジネスのビジョンを持っているけれど技術がないという
事業家に対しての継続的コンサルティングと、最適な方法提案・提供が
仕事である。
だから、時には最適だと思う解の出し方として、
開発しないことを勧めることさえする。
これは従来の「作って終わり」エンジニア像とは異質だ。

その従来像ではうまくいかないケースが増えているのは
確かだと思う。
とりわけ本書でも触れているスタートアップではそうで、
そもそも顧客の課題を探し出すことが重要なプロセスで、
初期のプロダクトはそのためにあるといってもいいのかもしれない。
という状況を考えると、納品ありきの悪しき「人月」思想に基づく
やり方では、どうやっても事業家のやりたいことに合致しない。

著者は、納品のない継続的コンサルとしてのエンジニア・スタイルを
独占するつもりはまったくなくて、むしろもっと広まって欲しいと思っている。
これには私も共感で、そういうエンジニアが力を注いで、
事業家とともに作り出すサービスが、世の中にインパクトを与えてほしいと
思うし、その確率を増やすには結局母数としての
事業家とエンジニアの望ましい協力体制そのものが増えないことには、と思う。

日本には起業家が少ないと言われるけれど、
実は起業したいけれどエンジニアの力を借りる段階でつまづく人が
多いのではないか？　という仮説というか、印象をふと持った。

[airybookさんの感想 · 2015年3月15日]

大手のシステム開発(受託開発)での経験を経て、受託開発の新しい形を会社として実現された、株式会社ソニックガーデンの倉貫さんの著作。この本は恐らく、非エンジニアで受託開発を頼む立場にある事業責任者やマネージャの方が読むと、実務的な部分がストレートに受け入れられるのではないかと思う。私自身自社サービス開発しかしたことがないエンジニアなので、また変わった視点から読んでしまった気がするが、受託開発そのものをどういった人が必要としており、その開発を担うエンジニアのモチベーションとは何なのか、また、従来型の受託開発と「納品のない受託開発」のメリットデメリットはそれぞれ何なのかと言ったことを体系的に勉強できる素晴らしい機会となった。文体も非常に読みやすいので、システム関係の業界の人間ならすぐに読めると思う。業界像、業種像を俯瞰して見直したい人は是非。

[yonezi123456さんの感想 · 2015年2月23日]

自分はシステム開発など、全く門外漢ですが、とても、共感できる内容。
自分が働きたいのはこんな仕組みの会社だなと感じました。

スッキリとして読みやすいのに、とても整理された文章も印象的。会社の内容と同時に、こちらもスッキリしてムダがない。そして、芯がしっかりしています。

この理念というか考え方は、今後、日本の中小企業が皆見習うべき部分だと思います。

[Kazuさんの感想 · 2015年2月14日]

受託開発（会社）の観点から、顧客のみならずその先のエンドユーザーそして社員を幸せにする仕組みとしての会社ないしはビジネスのあり方を提唱している素晴らしい一冊。

製造業からサービス業へ、工場から工房へ。サービス開発やソフトウェア開発そのものが目的ではなく、ビジネスを成長を望み、目的と手段が混同せず、正しいを追求する姿勢を保ってくれる素晴らしい発想だと思う。

[koichikitadaniさんの感想 · 2015年2月8日]

業務内容としては、別に珍しくもなんともない、技術的にそれほど凄くもない、規模的にも非常に小規模を想像させるな。。。と7割ほど読み進んでから、ようやくビジネスの話がされて、おぉぉ！と唸った

基本的に顧客は自分達の条件に合う企業のみに絞っているという点がある。

・システムは資産化しない、解約＝システム利用不可
・技術はこちら選定（それ以外は受け付けない）
・打ち合わせはWEB or 自社訪問限定

これに見合うとしたら、顧客は小規模、かつ起業間もない起業となる。実際にSierには高額＆ハイスペックすぎて頼めない企業が顧客となるようだ。
現在、日本の起業率の低さをこのビジネスモデルが少しでも解決、また地方でアイディアは持ちながらも実現できない人々を支援できるならば、それは凄いなぁと感じた
これ以外にも今の社員たちを、のれん分けで独立させるなど、まだまだ色々とありそうだ。

[konchanさんの感想 · 2015年1月2日]

アジャイル開発を前提とした、ソフトウェアビジネスモデルの話。
市場の反応を見ながら仕様を変えていくwebサービスにぴったりというか、いわゆるITベンダーならどこもやっていそうな話。
非IT企業に同じような開発プロセスを提供できるビジネスモデルというところが新しい。

1番の問題は、受け入れ側に、今まであった要件定義という明確な仕様がない状態での発注ができる仕組みがあるかどうか、というところだったりする気が。

製造系の会社って、なぜなぜ的な問いの立て方は得意だけど、そもそも系の問いの立て方は苦手なイメージというかステロタイプがあるので、文化の違いで衝突しそうな…。
そもそも、そんなアタマの硬い製造業の会社はもう淘汰されているか。

[ボンツトさんの感想 · 2014年12月14日]

システムの受託開発を長くやっていると、顧客と開発者との間に意識のギャップを感じることが時々あります。システムの完成させるという目標は一致しているはずなのに、その先の最終ゴールの捉え方が致命的に異なるのです。
こうしたギャップは、システムを使ってビジネスを拡大したり作業を改善することをゴールと捉える側（顧客）と、システムを完成させること自体をゴールとする側（開発者）の立ち位置の違いから考えると、当然なのかも知れません。
このようなジレンマを抱えながらシステムの受託開発をやってきた私のモヤモヤを、本書は多少なりとも晴らしてくれたような気がします。

システム開発側（特にエンジニア）はとかくシステムを作ることだけに目が向きがちですが、「ソフトウェアは使い続けることではじめて価値が出る」「なぜそのソフトウェアが必要なのか」等々を常に念頭に置いて顧客と接することで、顧客からの信頼を勝ち取ることにも繋がるのではないでしょうか。
特にソフトウェアは出来上がるまで目に見えない分、使ってみることで顧客が本当に必要とするものが分かることが多々あります。そういった意味でも「納品のないソフトウェア開発」のスタイルは、本当に必要なものだけ作ることが実現できる分、余計なコストがかからず顧客にとっても嬉しいはずです。
一方エンジニアにとっても、顧客からのフィードバックを受けやすく、やりがいのあるやり方であると言えるでしょう。

本書にも書かれているとおり、「納品のないソフトウェア開発」はサービスを提供する会社やスタートアップ企業と相性が良いようです。一方で、少数精鋭のエンジニアで臨む分、大規模な基幹システムには向かないような気がします。
ただ、たとえ大規模システムであっても、顧客と開発者の連携やワークレビューなど「納品のないソフトウェア開発」のやり方を応用することで、従来のプロセスを見直すヒントになるのではないかと感じています。

[sou (08thse)さんの感想 · 2014年12月6日]

従来の一括請負ではなく、月額定額でソフトウェア開発の対価をもらうビジネスモデル。

エンジニアは基本１人で対応するため、ビジネスを理解し、かつ技術的にもフルスタックエンジニアが求められるので大変そう。
また、著者も言っているが、今のところ大規模開発には対応できない、と。

ただ、この業界にいる身としては、契約形態のパラダイムシフトの第一歩、って感じで良いな、と思った。

[keisyunさんの感想 · 2014年11月21日]

DevOps の実践の一つでしょうか。
瑕疵担保責任はないため、善管注意義務でユーザ側がリスクをテイクできるかがポイントでしょう。
あとはユーザ側に使用を決める設計者がいることも必要。

[岡本大輔＠介護支援専門員さんの感想 · 2014年11月5日]

（納品のない受託開発とは？）……本当に必要な機能を本当に必要な順番に、少しずつ開発をしていくことが大事になります。一度に「作りきる」のではなく、少しずつ作っていくために、私たちは月額定額制で「納品をしない受託開発」をすることにしました。
（格安航空会社はなぜ成立するのか？）……・使用する飛行機の機種を統一することで整備費やパイロットの訓練費を削減したこと。・搭乗手続きのオンライン化などITを活用した自動化・乗務員が機内の清掃などを行い一人何役もこなすことによる人件費の削減です。
（「バグはゼロ」ではなく、すぐに直せること？）……「納品のない受託開発」では顧問のエンジニアがずっと担当で付くことや、チーム内での情報共有をしっかりすること、誰が読んでもわかりやすい見通しのよいプログラムを書くことで何があってもすぐに直せることに重点をおくのです。

著者プロフィール

株式会社ソニックガーデンの創業者で代表取締役社長。1974年生まれ。京都府出身。小学生からプログラミングを始め、天職と思える仕事に就こうと大手システム会社に入社するも、プログラマ軽視の風潮に挫折。転職も考えたが、会社を変えるためにアジャイル開発を日本に普及させる活動を個人的に開始。会社では、研究開発部門の立ち上げ、社内SNSの企画と開発、オープンソース化をおこない、自ら起業すべく社内ベンチャーを立ち上げるまでに至る。しかし、経営の経験などなかったために当初は大苦戦。徹底的に管理する方法で新規事業はうまくいかないと反省。徐々に管理をなくしていくことで成果をあげる。最終的には事業を軌道に乗せて、その社内ベンチャーをマネジメント・バイ・アウト（経営者による買収）することで独立を果たして、株式会社ソニックガーデンを設立。ソニックガーデンでは、月額定額＆成果契約の顧問サービス提供する新しい受託開発のビジネスモデル「納品のない受託開発」を展開。その斬新なビジネスモデルは、船井財団「グレートカンパニーアワード」にてユニークビジネスモデル賞を受賞。

「2023年 『人が増えても速くならない　～変化を抱擁せよ～』 で使われていた紹介文から引用しています。」