「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル

倉貫義人(著者)

• 販売会社／発売会社: 日本実業出版社
• 発売年月日: 2014/06/13
• JAN: 9784534051943

商品レビュー

2021/03/05

「納品のない受諾開発」という新しいソフトウェア開発のビジネスモデルについての本。
この本にも書いてあるように、どんなソフトウェア開発でもできることではないだろうけど、顧客にとっても従業員にとってもある程度のメリットがある開発手法なのだろうなと思った。
ようは、人月単価で考えるではなく、ある意味、サブスクリプション型の受諾開発なのだろうなと思った。この本によると、顧問弁護士や顧問税理士のようなもの、ようは、顧問エンジニアという考え方の開発だそう。こう書かれるとなるほどと思った。顧客との信頼関係が重要になってくるのだろうなと思う。

まあ、人月の考え方っておかしいことあるからね。同じ品質のものを作ったのに、優秀で速くできる人のほうが給料が安いとなる可能性があるわけだし(さすがに最近は、残業するほうがえらいという考えの人は減ってると思うけど)。
そういうこともあって、この「納品のない受諾開発」で仕事を行うエンジニアは、顧客からなんでも気軽に相談できると重宝されてるらしい。それだけ、親身になる存在ということか。4章には顧客企業側の話もあって、こういう開発が普及してきたら、お互いWin-Winになれそうだなと思えた。
ちなみに、納品をしないというのは、ソースコード、はたまたソフトすら納品しないということかと思ったら、ドキュメント類まで納品しないと書いてあって驚いた。さすがにそれは作るようお願いされそうな気もするけど、それだけ分かりやすく使いやすいシステムを心がけているということなのだろうか。動いているソフトウェアは仕様だとのこと。
この本によると、「納品のない受諾開発」が業界で当たり前になるまでに、10年以上はかかると思うとのこと。この本が発売されたのが2014年らしいので、すでに7年たってるわけだけど、この著者の会社(ソニックガーデン)以外にも、納品のない受諾開発で事業をしている会社は増えているのだろうか。

2019/09/06

ソフト開発を月額定額制料金にして、納品なし顧客のパートナーになるというソフトウェア開発会社。
ソフト開発者の理想の形かと。

2019/08/15

”ソニックガーデン 倉貫義人さんが「納品のない受託開発」というモデルを開拓していったいきさつが語られている一冊。

「人は基本的に一所懸命に働くことが好きなんだ」という性善説にたち、顧客と社員の両方の幸せをめざす経営。すばらしい。

2017/9/15 eLVイベントに向けて積読棚からひっぱりだした。

＜キーフレーズ＞
・納品のない受託開発
・顧問エンジニア
・「所有」から「利用」 ＆ 「完成」から「持続」
・「なぜなぜ」でなく「そもそも」
・社員の幸せ

＜抜き書き＞
・月額定額の受託開発
　月額定額でできる範囲で何でもするというスタイルは、他の業界で言えば顧問弁護士や顧問税理士のような「顧問」の形態に近いと思ってください。顧問エンジニアです。（p.37）
　※顧問コミュマネも！？
・思いついたことを言っても、すぐに見積もりとか提案書になるのではなく、それが本当に必要化どうかを問い直してもらえるので、逆に何でも気軽に言えるようになった（p.64）
　※顧客の声。ここに価値あり！
・「所有する」から「利用する」という考え方に変える（p.144）
・「完成する」から「持続する」ことへの考え方の転換（p.145）
・「YAGNI（ヤグニ）でいこう」（p.149）
　You Aren’t Gonna to Need It.（そんなの必要ないよ）　※to いる？
・人を信頼し、中心におく経営（p.166）
　※マネジメントしない会社＝自分のことは自分でマネジメントする
★顧客と、働く社員の両方を幸せにするための仕組みが会社だ（p.185）
　※「受託開発の時間」と「新規事業や新しいことに取り組む時間」
　　受託で稼ぐ部署、新規事業に取り組む部署 で分ける＝お互いやりにくい気持ちが働く（！）
　→部署（あるいは人）で分けずに、働く人のそれぞれの時間のなかで分けることにした

・毎週の打合せも、先方に来社してもらうか、インターネットのテレビ会議を使って行います（p.185）
　※この話、TXで聞いてもらったら、どんなことがおきるだろう？
・「ナレッジワーカー（知識労働者）」とは、一言で言えば「マニュアル化できない仕事をする人」のことです。（p.194）
　※いい定義！
・ワークレビューの進め方（p.196）
　進行としては、KPTのKとPを、レビューされる側（＝レビューイ）がまず一人で出します。出揃った段階で、レビューする側（＝レビューア）とともに内容の確認をします。（略）
　レビューイとレビューアの考え方のズレを確認し、改善点を探り、一緒に「Try」を考えます。
　※これぞ、KPT！
★「なぜなぜ」を追求するのでなく「そもそも」から考えることが大事です。（略）
　知識労働において圧倒的な効果を出すためには、「何をやらないか」を決めることが大切です。そのためには、課題に対して「なぜなぜ」を繰り返しても答えは出ません。「そもそも」の目的を考えることが大事で、そこから問題をショートカットで解決できるアイデアが出てくることがあります。（P.198）
・「ベストエフォート経営」で社員の幸せを大事にする（P.218）
　※目的は重要。目標は不要。
★人は基本的に一所懸命に働くことが好きなんだと思います。（p.221）
・目指すはオーナーシェフ
　（略）
　私たちの会社では「35歳定年制度」を作ろうかと考えています。エンジニアは、35歳で定年してサラリーマンを卒業し、のれん分けで独立して自らの会社を持つ、というものです。
　※高齢化への対策、普及への道筋
・ギルド＝「納品のない受託開発」をオープン化（p.225）
★「納品のない受託開発」を広めたいという背景には、ソフトウェアやプログラミングの仕事は本来楽しいもので、それをもっと多くの人に知ってもらいたいし、そのためにできる現実的な解決としてのビジネスモデルを提供したい、という想いがあるからです。（p.229）
　※これ、すばらしいな。
　　そして、俺がCMCHUBに関わるのもこれなんだよね。
　　「コミュマネの心折れ問題をなんとかしたい」とはちがい、「コミュマネという楽しい仕事を広めたい」ということなんだよな。

＜きっかけ＞
　？”