投稿元：
レビューを見る
「ソフトウェアの完成」を目指すのではなく継続的に（ユーザ企業の）「ビジネスの成長」を求める。これこそがこれからのSIerの生きる道だ。
この「納品のない受託開発」は一人もしくは少人数のエンジニアで行うので、小規模との制限は付くものの、属人性の問題はサポートエンジニアやコードレビューそしてワークレビュー（KPT）で担保され実に見事に考え抜かれている。一人で営業、コンサル、開発エンジニアを兼任するのは難しいだろうが、それを乗り越えて顧客と喜びを分かち合ったときの達成感、充実感も一入だ。
また、社員（エンジニア）の将来をしっかり描いているのも良い、元々城代のような仕事をしていれば、城主になっても十分やって行けるであろうことは自明だ。
著者である倉貫氏の講演を来る6/24に拝聴する予定だが、増々楽しみになってきた。
投稿元：
レビューを見る
体現したアジャイル。アジャイルの具体例。といってしまえる気がする。発注者にも読んで欲しいし、受注者にも読んで欲しいし、最後方の章になるとエンジニアにも読んで欲しい。
あわせてアジャイルサムライを読んでおくのもよいかもしれない。
それと著者の倉貫さんの人の良さというのも感じられるとてもよい一冊でした。
投稿元：
レビューを見る
「納品をなくせばうまくいく」の感想part1～ソフトウェア業界のビジネスモデルが抱える問題: プログラマの思索 http://forza.cocolog-nifty.com/blog/2014/06/part1-5631.html
「納品をなくせばうまくいく」の感想part2～「納品のない受託開発」のビジネスモデル分析: プログラマの思索 http://forza.cocolog-nifty.com/blog/2014/07/part2-c02b.html
投稿元：
レビューを見る
「顧問エンジニア」というのがとてもしっくりくる呼び名だと感じた。「顧客に対して価値のあるモノ（サービス）を作りたい」、「エンジニアとして生涯生きていきたい」といったことを考える人には良くマッチした仕組みだと思う。
投稿元：
レビューを見る
著者のブログを以前から読んでいたので、記載されている内容については「そうだったそうだった」と思い返しながら読んでいた。
IT業界の問題の根源を「一括請負」と「納品」にあると説き、その理由と「納品のない受託開発」がどんなものかを丁寧に解説している。
この「納品のない受託開発」の考え方は、SI業界に身をおいて苦労を経験したことがある人たちの間では既に広まっており、業務としてアジャイル開発を既に実践している人や、工数精算前提のビジネスモデルではなく、ITをモノではなくサービスとして提供しているビジネスを行っている人たちにとっては素直に受け入れることができ、当たり前の考え方、と感じるだろうけれども、そうではない、以前大多数を占める工数精算前提のビジネスモデルの企業に従事し、日々デスマーチや過酷なプロジェクト、生産性や高いスキルとは真逆の工数ビジネスに幻滅している技術者や、ITを単なる金食い虫と考えている経営者にとっては新しい概念と感じると思う。
むしろそういう層の人たちに1人でも多く届いて欲しいし、それが広まることがSI業界に従事する人や、ユーザー企業やIT部門を幸せにする唯一の道だと個人的には感じている。この本に書いてあることが、書籍としての形で世に出て広まることが一番大きいことだと思う。
「納品のない受託開発」に関しては、スケーラビリティや適用領域（ミッションクリティカルな領域、大規模システム、金融、公共、人命など）に関して疑問を呈する意見が一方で出てきているのも認識している。が、この本の中でははっきりと、銀の弾丸ではない、それらにはそれらの適した作り方、開発方法があると記述しており、誠実だと感じた。それどころか、世の大規模システムの多くは本当は多くの機能が必要、ということに対して疑問を感じると書いていて、個人の感覚としても頷ける。
必要以上に大きくしない、という考え方を、ソニックガーデンという企業自体にも適用されていて、小さいほうが技術者としても幸せではないかと感じていると記されている。
技術者が幸福に働くには、ナレッジワーカーという働き方、社員の幸せを大事にする、といった考え方が記されており、この辺りも大きな企業で改革や改善をしようと行動し、理不尽な制約やしがらみで潰されたり挫折した経験がある人なら、同意出来る部分ではないだろうか。
昨今、社員を単なる固定費・コスト扱いし使い倒すことで利益を上げてきた企業の不調が浮かび上がってきており、企業の持続的な成長や繁栄には、社員個人個人の幸せや成長を大事にすることが不可欠、ということが認知されてきたと感じるが、そういう意味でもソニックガーデンはそれを体現している企業だと感じた。
投稿元：
レビューを見る
SIの構造的欠陥、ユーザとSIerの利益相反に対する１つの答えと言える。ユーザとシステム会社が同じ方向を見て仕事を進められる一つの形。
これまで人月の枠で均質・画一的に捉えられていたエンジニアをナレッジワーカーとして再定義した点も新しい。今後の課題はこの「俗人化」によるサービスがメリットでもあり、リスクでもある点だろうか。
投稿元：
レビューを見る
顧客がプログラマーに直接発注する形態で、誰がユーザーエクスペリエンスやユーザビリティを担保するのか。プログラマー一人で何でも出来るという考え方なのだろうか。前述のポイントを専門家がケアしなければビジネスとしての成功確率は低いと思うのだが。 それについては語られていないようだった。あるいは顧客の役割と位置付けられているのかもしれない。ほとんどの顧客はそのような能力を持たないと思うのだが。
顧問と例えられる契約形態は、請負契約ではなく準委任契約だろうか。私のところでも顧問型のサービス割合が増えつつある。納品のない受託開発というコンセプトは素晴らしい。機会があれば引用したいと思う。
投稿元：
レビューを見る
パッケージで売るのではなくエンジニアを外注してその中で開発を行おうという話。ネットベンチャーのサービス開発には向いていると思う。
投稿元：
レビューを見る
創業にあたり、事業展望をきっちりと見据えることは難しい。打ち出した新機軸への思いがあってもいきなりの成果は確約できず、かといって当然に発展は目指している。事業の成長とともにシステムも成長させていけばいいのだが、創業時点で導入すべきシステムの規模と、運用・保守の規模をどの程度に設定したものか。要件定義が固まらずして仕様が書けない。よって、無駄なバッファが乗るのを否めない。現在抱えている課題が、ある側面から浮き彫りになった。ただ、受注者であるベンダーの質と意識も大いに問われる。
投稿元：
レビューを見る
納品に追われ、終わったら別の顧客（案件）という流れにいる身としては、全く対極で刺激的な内容。お客さんと、月額に対する成果の価値観に差がでないか？など気になる点もあるけど、うまくできれば顧客との関係や働き方、やりがいなどプラスの面も多そう。
投稿元：
レビューを見る
こんな具合にソフト開発できれば本当に楽しいだろうなと思う。本書では納品のない=>クラウドで顧客カスタマイズされたサービスを提供という風に方向付けがなされているが、可能であれば同様な形のビジネスが、組み込みソフト開発だとか、一般的には納品•検収がつきまとうものについても適用可能であって欲しい。
納品のない•••といった形式よりもむしろ商習慣や契約形態が問題だと思うのでその辺りの意識が業界で変わると皆ハッピーになれるのではと思う。
投稿元：
レビューを見る
株式会社ソニックガーデンで実際に行われている
「納品のない受託開発」という新たな開発スタイルに関して、
・どんなものか説明
・どのような利点があるか
・既存の受託開発の問題点
・自社の枠に留まらない「納品のない受託開発」の展望
などについてまとめてあります。
従来のウォーターフォール・人月見積もりなど問題点の多くある
業界では、未だにそういった状況を抜けだせていない現場が多い。
アジャイルな手法を導入してみるものの失敗したりしている現場もあるが、
非効率な商慣習の縛りをそのままにアジャイルの手法を導入しているため、
うまくいかなかったり・・・。
そんなケースが多い中、「納品のない受託開発」では顧客との取引方法を
根本的に変え・取引相手も開発スタイルに適した相手に絞ることで、
アジャイル・スクラムなど有効とされる開発手法を徹底的に導入して
システム開発会社・エンジニア・顧客全てがWin✕Winになります。
紹介されている各トピックは、勉強熱心なエンジニアの方ならどこかで
聞いたことのある内容が多いと思います。
しかし、色々と既存の制約に縛られがちな日本の受託システム開発において、
これらのトピックを有効活用し、実運用に活かせるように適用する方法を考え、
実際に事業を回していることにこそ、この手法の価値があるのだと思います。
システム開発に関わるものであれば、
読んで何かしらを得られる良書だと思います。
投稿元：
レビューを見る
（納品のない受託開発とは？）……本当に必要な機能を本当に必要な順番に、少しずつ開発をしていくことが大事になります。一度に「作りきる」のではなく、少しずつ作っていくために、私たちは月額定額制で「納品をしない受託開発」をすることにしました。
（格安航空会社はなぜ成立するのか？）……・使用する飛行機の機種を統一することで整備費やパイロットの訓練費を削減したこと。・搭乗手続きのオンライン化などITを活用した自動化・乗務員が機内の清掃などを行い一人何役もこなすことによる人件費の削減です。
（「バグはゼロ」ではなく、すぐに直せること？）……「納品のない受託開発」では顧問のエンジニアがずっと担当で付くことや、チーム内での情報共有をしっかりすること、誰が読んでもわかりやすい見通しのよいプログラムを書くことで何があってもすぐに直せることに重点をおくのです。
投稿元：
レビューを見る
業務内容としては、別に珍しくもなんともない、技術的にそれほど凄くもない、規模的にも非常に小規模を想像させるな。。。と7割ほど読み進んでから、ようやくビジネスの話がされて、おぉぉ！と唸った
基本的に顧客は自分達の条件に合う企業のみに絞っているという点がある。
・システムは資産化しない、解約＝システム利用不可
・技術はこちら選定（それ以外は受け付けない）
・打ち合わせはWEB or 自社訪問限定
これに見合うとしたら、顧客は小規模、かつ起業間もない起業となる。実際にSierには高額＆ハイスペックすぎて頼めない企業が顧客となるようだ。
現在、日本の起業率の低さをこのビジネスモデルが少しでも解決、また地方でアイディアは持ちながらも実現できない人々を支援できるならば、それは凄いなぁと感じた
これ以外にも今の社員たちを、のれん分けで独立させるなど、まだまだ色々とありそうだ。
投稿元：
レビューを見る
DevOps の実践の一つでしょうか。
瑕疵担保責任はないため、善管注意義務でユーザ側がリスクをテイクできるかがポイントでしょう。
あとはユーザ側に使用を決める設計者がいることも必要。
