サイト内検索

詳細検索

送料無料(~12/31)

1,000円以上の注文で3%OFFクーポン(1202-06)

hontoレビュー

予約購入について
  • 「予約購入する」をクリックすると予約が完了します。
  • ご予約いただいた商品は発売日にダウンロード可能となります。
  • ご購入金額は、発売日にお客様のクレジットカードにご請求されます。
  • 商品の発売日は変更となる可能性がございますので、予めご了承ください。

みんなのレビュー30件

みんなの評価4.2

評価内訳

30 件中 1 件~ 15 件を表示

2015/01/02 07:53

投稿元:ブクログ

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

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

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

2015/02/14 15:01

投稿元:ブクログ

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

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

2016/03/16 00:18

投稿元:ブクログ

http://hinbeee.blog31.fc2.com/blog-entry-2399.html

2014/08/10 12:17

投稿元:ブクログ

顧客がプログラマーに直接発注する形態で、誰がユーザーエクスペリエンスやユーザビリティを担保するのか。プログラマー一人で何でも出来るという考え方なのだろうか。前述のポイントを専門家がケアしなければビジネスとしての成功確率は低いと思うのだが。 それについては語られていないようだった。あるいは顧客の役割と位置付けられているのかもしれない。ほとんどの顧客はそのような能力を持たないと思うのだが。

顧問と例えられる契約形態は、請負契約ではなく準委任契約だろうか。私のところでも顧問型のサービス割合が増えつつある。納品のない受託開発というコンセプトは素晴らしい。機会があれば引用したいと思う。

2014/11/05 12:57

投稿元:ブクログ

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

2014/08/15 14:50

投稿元:ブクログ

「納品をなくせばうまくいく」の感想part1~ソフトウェア業界のビジネスモデルが抱える問題: プログラマの思索 http://forza.cocolog-nifty.com/blog/2014/06/part1-5631.html

「納品をなくせばうまくいく」の感想part2~「納品のない受託開発」のビジネスモデル分析: プログラマの思索 http://forza.cocolog-nifty.com/blog/2014/07/part2-c02b.html

2014/09/26 02:25

投稿元:ブクログ

納品に追われ、終わったら別の顧客(案件)という流れにいる身としては、全く対極で刺激的な内容。お客さんと、月額に対する成果の価値観に差がでないか?など気になる点もあるけど、うまくできれば顧客との関係や働き方、やりがいなどプラスの面も多そう。

2014/06/20 15:45

投稿元:ブクログ

体現したアジャイル。アジャイルの具体例。といってしまえる気がする。発注者にも読んで欲しいし、受注者にも読んで欲しいし、最後方の章になるとエンジニアにも読んで欲しい。

あわせてアジャイルサムライを読んでおくのもよいかもしれない。

それと著者の倉貫さんの人の良さというのも感じられるとてもよい一冊でした。

2014/06/15 16:44

投稿元:ブクログ

「ソフトウェアの完成」を目指すのではなく継続的に(ユーザ企業の)「ビジネスの成長」を求める。これこそがこれからのSIerの生きる道だ。
この「納品のない受託開発」は一人もしくは少人数のエンジニアで行うので、小規模との制限は付くものの、属人性の問題はサポートエンジニアやコードレビューそしてワークレビュー(KPT)で担保され実に見事に考え抜かれている。一人で営業、コンサル、開発エンジニアを兼任するのは難しいだろうが、それを乗り越えて顧客と喜びを分かち合ったときの達成感、充実感も一入だ。
また、社員(エンジニア)の将来をしっかり描いているのも良い、元々城代のような仕事をしていれば、城主になっても十分やって行けるであろうことは自明だ。
著者である倉貫氏の講演を来る6/24に拝聴する予定だが、増々楽しみになってきた。

2015/02/08 20:46

投稿元:ブクログ

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

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

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

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

2016/08/21 17:20

投稿元:ブクログ

製品ではなく、サービスを提供する点、またコンサルもできるエンジニアであること。顧客満足度・エンジニアの達成感ともに非常に強く感じられ、ベストなビジネスモデルであると感じた。

また一般的な開発であっても、顧客が真に必要としていることを読み解き、システム化していく点については、共通して重要であり、難しい要素が多いと感じた。

2015/05/27 13:30

投稿元:ブクログ

資料ID:98150066
請求記号:007.35||K
配置場所:工枚普通図書

2015年ITエンジニア本ビジネス書部門大賞受賞

2014/08/03 22:42

投稿元:ブクログ

SIの構造的欠陥、ユーザとSIerの利益相反に対する1つの答えと言える。ユーザとシステム会社が同じ方向を見て仕事を進められる一つの形。
これまで人月の枠で均質・画一的に捉えられていたエンジニアをナレッジワーカーとして再定義した点も新しい。今後の課題はこの「俗人化」によるサービスがメリットでもあり、リスクでもある点だろうか。

2014/12/14 20:21

投稿元:ブクログ

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

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

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

2014/08/17 21:02

投稿元:ブクログ

著者のブログを以前から読んでいたので、記載されている内容については「そうだったそうだった」と思い返しながら読んでいた。

IT業界の問題の根源を「一括請負」と「納品」にあると説き、その理由と「納品のない受託開発」がどんなものかを丁寧に解説している。

この「納品のない受託開発」の考え方は、SI業界に身をおいて苦労を経験したことがある人たちの間では既に広まっており、業務としてアジャイル開発を既に実践している人や、工数精算前提のビジネスモデルではなく、ITをモノではなくサービスとして提供しているビジネスを行っている人たちにとっては素直に受け入れることができ、当たり前の考え方、と感じるだろうけれども、そうではない、以前大多数を占める工数精算前提のビジネスモデルの企業に従事し、日々デスマーチや過酷なプロジェクト、生産性や高いスキルとは真逆の工数ビジネスに幻滅している技術者や、ITを単なる金食い虫と考えている経営者にとっては新しい概念と感じると思う。

むしろそういう層の人たちに1人でも多く届いて欲しいし、それが広まることがSI業界に従事する人や、ユーザー企業やIT部門を幸せにする唯一の道だと個人的には感じている。この本に書いてあることが、書籍としての形で世に出て広まることが一番大きいことだと思う。

「納品のない受託開発」に関しては、スケーラビリティや適用領域(ミッションクリティカルな領域、大規模システム、金融、公共、人命など)に関して疑問を呈する意見が一方で出てきているのも認識している。が、この本の中でははっきりと、銀の弾丸ではない、それらにはそれらの適した作り方、開発方法があると記述しており、誠実だと感じた。それどころか、世の大規模システムの多くは本当は多くの機能が必要、ということに対して疑問を感じると書いていて、個人の感覚としても頷ける。

必要以上に大きくしない、という考え方を、ソニックガーデンという企業自体にも適用されていて、小さいほうが技術者としても幸せではないかと感じていると記されている。

技術者が幸福に働くには、ナレッジワーカーという働き方、社員の幸せを大事にする、といった考え方が記されており、この辺りも大きな企業で改革や改善をしようと行動し、理不尽な制約やしがらみで潰されたり挫折した経験がある人なら、同意出来る部分ではないだろうか。

昨今、社員を単なる固定費・コスト扱いし使い倒すことで利益を上げてきた企業の不調が浮かび上がってきており、企業の持続的な成長や繁栄には、社員個人個人の幸せや成長を大事にすることが不可欠、ということが認知されてきたと感じるが、そういう意味でもソニックガーデンはそれを体現している企業だと感じた。

30 件中 1 件~ 15 件を表示