投稿元:
レビューを見る
読みやすいです。同僚にも読んでもらいたい。
WEBシステムは最初からやりたいことが決めらられなんだから、だったら最初から「納品」をなくした方がいいんじゃない?という話。
最初にやることを決めない替わりに、1週間単位でやることを決めて実装していくというスタイル。
こんな会社で働きたいと思った。
気になったのは、以下の二つ。
* 人の単価をどうやって決めるのか?「この人は何年目だからこの単価です」とかで、客は納得してくれる?
*「来週ここまでやります」という、何を説得材料として説明するのだろうか?
投稿元:
レビューを見る
「納品のない受託開発」というソニックガーデンのビジネスモデルについて、効果・仕組み・向き不向き・事例などについて、従来型の一括請負の問題点の指摘とともに説明されている。
「納品のない受託開発」は合理的で素晴らしい仕組みだと思うが、本書でも注意喚起されているとおり万能ではなく、また、実現のための前提が難しいものになっている。
たとえば、エンジニアや会社のスキルやモチベーションの要求水準が高いこと、顧客側の作業や体制への要求も比較的高いこと、システムの会社や規模に制約があること、など。
つまり、ソニックガーデンやそれに類するレベルの高さが要求されるため、誰でも容易に真似できるわけではないという点は留意したい。
本書は昔買ってから時々つまみ食いのように読むだけで積んだままになっていたが、唐突に読みたい気持ちが高まってきたので読んだ。
スピードを重視して4章と7章は流し読みした。
35ページ
納品があるから見積りが必要で、逆算して人月を使わなくてはいけないし、バッファが入って高くなる。さらに、現実的でない要件定義をしなければいけないし、開発と運用の切れ目ができて担当者が変わると、その引き継ぎコストがかかるなど、一つもよいことがありません。
→わかる。そういうものだと割り切っている。
37ページ
毎月の決まった金額の中で、「できる範囲」で精一杯の「開発と運用」を行います。ソフトウェアの開発と運用を分けることなく一体的に担い、その他にもソフトウェアに関わるあらゆる問題について対応します。
→よい答えではあるけど、担当者のハードルが高い。高いスキルとモチベーションが必要になる。
52ページ
エンジニアを採用してインソーシング(内製)することの難しさと、一括請負でアウトソーシングする要件定義の難しさの両方に困った会社が、要件定義をしなくてもよい「納品のない受託開発」を求めているというわけです。
→たしかにこのシチュエーションなら非常にマッチすると思う。実際問題としてエンジニアの採用は採用側がエンジニアであったとしても難しいし、要件定義をするにもエンジニアリングのノウハウがなければ成功率は低いだろう(まぐれで成功することもあるとは思う)。
71ページ
実際にこのビジネスモデルには、それを遂行する上での課題や注意点が多くあります。その中で時間をかけて経験を積み、ノウハウを得ていくことでしか、うまく進める方法はないと思います。
→これもわかる。容易ではないし、これを実行できているソニックガーデンはすごい。
99ページ
事業の設計段階はもとより、開発段階での毎週の打合せの際に必ずお願いするのは、打合せの場に顧客の事業責任者に同席してもらうことです。
→ハードルが高い。巷でアジャイルのマネごとをしてもうまくいかないときにありがちな原因のひとつ。開発会社だけががんばって取り組んでも、同じタイミングに顧客側が同じくらいがんばって取り組めなければうまくいかない。開発会社は顧客の理解を得て誘導しなければいけないし、顧客は理解した上でついていかなければいけ��い。
102ページ
たとえば、毎週の打合せや動作確認も、顧客からすればそれなりの時間と手間を取られることになります。
→99ページの件と同じくハードルが高い。
147ページ
これに対して、「納品のない受託開発」では顧問のエンジニアがずっと担当で付くことや、チーム内での情報共有をしっかりすること、誰が読んでもわかりやすい見通しの良いプログラムを書くようにすることで、何かあってもすぐに治せることに重点を置くのです。
→素晴らしい。この考え方は納品のない受託開発に限らず、通常の開発であっても適用するべきだと思う。
158ページ
それだけの幅広いスキルを備えたエンジニアはなかなかいないのでは、と思われるでしょう。たしかに誰にでもできる仕事ではないと思いますが、私はそもそもソフトウェア開発とは、誰にでもできるものではないと思っています。
→ハードルが高い。しかし書いていることはごもっともである。
170ページ
日本語の資料を残さない代わりに、プログラムの読みやすさには徹底的にこだわっています。
→素晴らしい。巷のシステム開発では、ドキュメントは書かず、プログラムも難解で読みづらい状態になっているというケースが少なくない。ドキュメントを書かないこと自体は問題ではないが、その分、保守性を担保できるような手立てを用意して責任を取るのがプロの仕事である。
180ページ
私の言うプログラマーとは、「納品のない受託開発」で求められるような、企画の段階から考えて、画面のデザインや仕組みの設計ができて、それを自らプログラミングし、クラウドでの運用まで、ソフトウェア・エンジニアリングに関わるすべての工程をこなせる人のことを指しています。
→ハードルが高い。必要な仕事であってもそこは自分のスコープ外だからやりません・知りません、という態度をとって見向きもしないような人間ではいけない。
189ページ
これは、テクニック(T)、インテリジェンス(I)、パーソナリティ(P)、スピード(S)の4つの頭文字を合わせたもので、この4つの視点は、私たちが優れたエンジニアを選抜する際に考えていることにそのまま当てはまります。
→使えそう。マネしてみようと思った。
196ページ
進行としては、KPTのKとPを、レビューされる側(=レビューイ)がまず一人で出します。出揃った段階で、レビューする側(=レビューア)とともに内容の確認をします。
→KPT自体は元々知っていたしやったこともあったけど、ワークレビューとして使う点や、K・Pをレビューイだけで書き出す点は理解できていなかった。
199ページ
社内規則(ルール)を明文化して社員を縛るよりも、ワークレビューを通じて、良識(コモンセンス)を共有することで社員を育てるという感覚を大切にしています。
→素晴らしい。実現性・有効性のあるオンボーディングの方法に悩んだことがあったので、今後はマネしようと思った。
200ページ
「ワークレビュー」は採用の際にも使えます。
→素晴らしい。目から鱗でした。これもマネしたい。
210ページ
90年代に登場したJavaは、最初はおもちゃのようだと思われていました。
→このエピソードは例え話なので本題ではないのだけど、この事実を知らなくて驚きがあった。たしかに冗長で過小評価されるのも理解できるし、その後のWindows・GUIの普及とJavaの躍進はむしろ過大評価かもしれないけど。
215ページ
もちろん、セルフマネジメントができているということが前提であって、真面目な性格であることも重要でしょう。そして、そういう社員だけを採用しているからこそできるのです。
→何回書いたかわからないけどハードルが高い。
229ページ
よく講演などでは「心はプログラマー、仕事は経営者」と自己紹介をしたりしています。
→よい。これも参考にしたい。心はユーザー、体はエンジニア、仕事はマネージャー。
投稿元:
レビューを見る
かなり良本。
私個人も現代のSIer業界に違和感を感じて悩めるエンジニアに対してキャリアコンサルを提示しているが、本来エンジニアのあるべき姿。
特にフリーランスSEという働き方はあるが、本来フリーランスはプロ(個人事業主)。ようは1人社長だ。
なのにも関わらず、某エージェントの「簡単に稼げる」という煽り文句の広告のせいで、ナレッジワーカーな姿勢が見えない、中途半端なフリーランスSEが増えて来た。
最終的にはスキルもないのに「楽して高収入」目的で、フリーランスに入る。
エージェントにはワガママを、現場にはできないタスクを押し付ける微妙なエンジニアも増えていく。
ぜひ、エンジニア、そして全てのSIer業界の役職ある方達は読んで欲しい良本。
むしろ2014年に発刊して、未だに変わらないこの状態であることが不思議。
だからこそ、我々から見ると穴だらけなのだが多くの人は気づいていない。
投稿元:
レビューを見る
ソフトウェア業界の"常識"を変えるビジネスモデル「納品のない受託開発」を紹介するビジネス書。
職場の知り合いから、長い間借りたまま積読になっていたので、そろそろ返さないと、と半ば強制的に読みました(^-^;
タイトルを見たときから「アジャイル」と何が違うのかが気になってましたが、要は広義のアジャイル開発手法というか、「手を動かすコンサル契約」のようなイメージのビジネスモデルです。
実際、開発手法を「スクラム」のようなアジャイルで進めようとしても、顧客との契約が旧来の契約である限り、また社内開発であっても、プロジェクトの評価方法が旧来の方法である限り、アジャイルは絵に描いた餅になります。
おそらくSIerで働く誰しもが、契約面から見直さないとアジャイルの適用は難しいと感じていたと思いますが、この書籍は、その契約面からのアプローチを実際に実践した形だと思います。
今後は、こういったビジネスの形が主流になっていくような気がしていますが、多くのユーザー企業は欧米のように自社でエンジニアを抱えて、アジャイルで開発していくようになるんじゃないかなー。。
なので、こういったビジネスモデルは、自社でエンジニアを抱えられない、中小規模の会社をターゲットにやっていくのでしょう。結局は、多くのITコンサルと同じですね。
それにしても、SIerの未来が心配です。ホントに世の中に置いてかれるぞ・・・。
投稿元:
レビューを見る
ソフトウェアを所有すると利用するの区別は大事
その区別なくソフトウェアは所有するものだという考え方が染み付いてる業界はまだまだ多く存在する
投稿元:
レビューを見る
顧客のビジネス成功をゴールとするシステム構築をする場合、派遣やSESなどの客先常駐をすることが多いのだが、本書ではそれをせず、月ごとに定額の費用を払うビジネスモデルの解説をしている。
実際にこのようなビジネスモデルに理解をしてくれる顧客が多い企業だとできそう。従来の企業、大企業などは理解を得られにくいかも?でも実現できればお客様・働く側双方にとって良いビジネスモデルとなるから広まって欲しいと思った。
投稿元:
レビューを見る
これまでのソフトウェア開発の狭間を埋める、納品のない開発。所有ではなく、利用に焦点を絞って、毎月定額で、ソフトウェア開発サービスを提供するという感じか?成果に焦点を当てるという非常に意欲的な取り組み。取り回しの良い小規模企業でないとなかなか上手く行かなそうだが、ギルドという仕組みで、フリーランスやそれ以外の共感する人々を取り込んで行こうという発想は素晴らしいと思う。
以下注目点
・本当に必要な機能を本当に必要な順番に少しずつ開発していく
・デフェンシブな開発からアグレッシブな開発へ。
・オーダメイド、納品しない、派遣しない。
・開発と運用を担当
・完成責任は請け負わない代わりに、圧倒的な費用対効果を提供する
・専門性の高い職種に対して、他の社員と同じ扱いはできない。
・プロフェッショナルサービス
・新規事業と要件定義の相性は最悪
・一ヶ月から3ヶ月程度で開発できる機能で、はやめに運用に入る。
・作らない提案。思いつき程度の機能は、すぐには作らない。
・納品ではないので、瑕疵担保責任は負わない。
・ドキュメント読み終わった、訪問読み終わった、納期や完成品の約束読み終わった。
・要件を定義するのではなく、事業の目的を共有する。
・顧客が動作確認できるレベルで作業を切り出す。
・なぜその機能が必要なのか
・所有から利用へ、完成から持続へ
・本当に必要になるまで、予想で作ったりするのはやめよう。
・資料を残さない代わりに、コードを読みやすくすることにこだわっている。
・KPT keep, problem, try
・そもそもを考え、何をやらないかを決める。
投稿元:
レビューを見る
5年ほど前の本なので知っている内容がほとんどだったが、ビジネスモデルとして実践しているという点でとても参考になった。
投稿元:
レビューを見る
2019年1月30日読了。ITにおける「納品のない受託開発」を行う会社・ソニックガーデンを創業した著者によるこの新しい形の働き方の解説。「顧問弁護士などに近い関わり方」という表現はわかりやすい。確かに、営業が完璧な見積もり・提案をする必要があり、開発者にも変更を許さない厳密なスコープ管理が求められ、また発注側にも数年先のビジネス環境を正確に見通しての発注が求められる現在の大型SI開発の仕組みって、誰も幸せにならない仕組み・大企業にとって数字が立ちやすい、というくらいしかいいところがないものなのかもしれない…。「誰でもこの働き方ができるわけではない」と断られておりそれはその通り、「PM」という職種も所詮細かく分業された大型SI開発の隙間に生まれたものであり、「納品のない受託開発」においては不要とみなされるものなのだろうか…。
投稿元:
レビューを見る
スタートアップの会社には
・新規事業の要件が煮詰まり切っていなくても明確な事業方針があれば開発に着手でき、
・進めながら変わっていかれる
・スタートアップの会社がこだわりたい見せ方は、顧客側で作る(一緒に作り上げる)
・月額設定なので事業計画も立てやすい
といった面で魅力的。
投稿元:
レビューを見る
”ソニックガーデン 倉貫義人さんが「納品のない受託開発」というモデルを開拓していったいきさつが語られている一冊。
「人は基本的に一所懸命に働くことが好きなんだ」という性善説にたち、顧客と社員の両方の幸せをめざす経営。すばらしい。
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に関わるのもこれなんだよね。
「コミュマネの心折れ問題をなんとかしたい」とはちがい、「コミュマネという楽しい仕事を広めたい」ということなんだよな。
<きっかけ>
?”
投稿元:
レビューを見る
ソフト開発を月額定額制料金にして、納品なし顧客のパートナーになるというソフトウェア開発会社。
ソフト開発者の理想の形かと。
投稿元:
レビューを見る
「納品のない受諾開発」という新しいソフトウェア開発のビジネスモデルについての本。
この本にも書いてあるように、どんなソフトウェア開発でもできることではないだろうけど、顧客にとっても従業員にとってもある程度のメリットがある開発手法なのだろうなと思った。
ようは、人月単価で考えるではなく、ある意味、サブスクリプション型の受諾開発なのだろうなと思った。この本によると、顧問弁護士や顧問税理士のようなもの、ようは、顧問エンジニアという考え方の開発だそう。こう書かれるとなるほどと思った。顧客との信頼関係が重要になってくるのだろうなと思う。
まあ、人月の考え方っておかしいことあるからね。同じ品質のものを作ったのに、優秀で速くできる人のほうが給料が安いとなる可能性があるわけだし(さすがに最近は、残業するほうがえらいという考えの人は減ってると思うけど)。
そういうこともあって、この「納品のない受諾開発」で仕事を行うエンジニアは、顧客からなんでも気軽に相談できると重宝されてるらしい。それだけ、親身になる存在ということか。4章には顧客企業側の話もあって、こういう開発が普及してきたら、お互いWin-Winになれそうだなと思えた。
ちなみに、納品をしないというのは、ソースコード、はたまたソフトすら納品しないということかと思ったら、ドキュメント類まで納品しないと書いてあって驚いた。さすがにそれは作るようお願いされそうな気もするけど、それだけ分かりやすく使いやすいシステムを心がけているということなのだろうか。動いているソフトウェアは仕様だとのこと。
この本によると、「納品のない受諾開発」が業界で当たり前になるまでに、10年以上はかかると思うとのこと。この本が発売されたのが2014年らしいので、すでに7年たってるわけだけど、この著者の会社(ソニックガーデン)以外にも、納品のない受諾開発で事業をしている会社は増えているのだろうか。