今話題の納品のない受託開発の本です。

今までとこれからのビジネスモデルと、自分の生き残りを考える上で非常に参考になったので。

納期の問題点

一度決めた要件定義から抜け出せない。 仕様を満たすことがゴール。

完成した頃には陳腐化したり、思ってたのと違うことがしばしばある。 しかし、それの変更にはすごくコストがかかる。

そもそも変更をすることを想定していない設計になっているから。

受託開発というより技術顧問

対象となる会社は小さくて技術者を持っていない会社。

そこで使う業務システムは、要件を固めきれない流動的なものがほとんど。

納品型は、使えるならいいけどそうでなければ ツールなどのカスタマイズが必要。

エンジニアにとっての利点

フィードバックが早い

開発と保守の分離が少ないのでやる気が持続する

古臭い仕組みに乗っ取らなくて良くなる。 古い製品はむしろ負債になりうる。

周りに優秀なエンジニアがいる。

目的が、「何かをなすこと」というより、何かをなすための手伝いをITを使って行うこと、になる。

定職につけ、収入が安定する。

一気通貫で責任を持てる。

チームを作れる。

ユーザーに取っ手の利点

サービス化することで変化に強い。 気軽に始められる。

なぜ今までなかったのか

インフラ・環境が追いついた。 インフラasコード

実行環境の統一、 ブラウザがあればだいたいできる。

今後

チーム開発が流行る。

集団でフルスタックエンジニアになる。

デザイナーはエンジニアと密接になる。

モデルの広がり ギルドの浸透。