「納品」をなくせばうまくいく の商品レビュー

倉貫義人(著者)

2015/04/29

業界の問題を解決する為に自分でビジネスモデルを作る
ことは凄いと思う。作者の思想がよく描かれていて理解もできるけど、会社経営の視点でみると最低限の利益を得なければ長期的な経営が難しいのではないかと思う。
印象としては気の合うエンジニアの集まりに近い感じが
する。若手を育てる感じはあまりなさそう。

2015/04/19

ソフトウェアの「成長」をエンジニアが正しく導くことができるのであれば、とても有効な開発方法だと思う。
ユーザー側も実現したい事や業務の問題点がはっきり見えていないこともあるので、じっくりと対話を行って方向性を決めていけるのはメリットが大きい。
問題は、エンジニアの引き継ぎが難しくなる点。

2015/02/23

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

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

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

2015/03/18

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

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

2015/02/08

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

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

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

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

2015/01/02

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

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

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

2014/12/14

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

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

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

2014/12/06

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

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

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

2014/11/21

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

2014/11/05

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