「納品」をなくせばうまくいく の商品レビュー
こんな具合にソフト開発できれば本当に楽しいだろうなと思う。本書では納品のない=>クラウドで顧客カスタマイズされたサービスを提供という風に方向付けがなされているが、可能であれば同様な形のビジネスが、組み込みソフト開発だとか、一般的には納品•検収がつきまとうものについても適用可...
こんな具合にソフト開発できれば本当に楽しいだろうなと思う。本書では納品のない=>クラウドで顧客カスタマイズされたサービスを提供という風に方向付けがなされているが、可能であれば同様な形のビジネスが、組み込みソフト開発だとか、一般的には納品•検収がつきまとうものについても適用可能であって欲しい。 納品のない•••といった形式よりもむしろ商習慣や契約形態が問題だと思うのでその辺りの意識が業界で変わると皆ハッピーになれるのではと思う。
Posted by
株式会社ソニックガーデンで実際に行われている 「納品のない受託開発」という新たな開発スタイルに関して、 ・どんなものか説明 ・どのような利点があるか ・既存の受託開発の問題点 ・自社の枠に留まらない「納品のない受託開発」の展望 などについてまとめてあります。 従来のウォーターフ...
株式会社ソニックガーデンで実際に行われている 「納品のない受託開発」という新たな開発スタイルに関して、 ・どんなものか説明 ・どのような利点があるか ・既存の受託開発の問題点 ・自社の枠に留まらない「納品のない受託開発」の展望 などについてまとめてあります。 従来のウォーターフォール・人月見積もりなど問題点の多くある 業界では、未だにそういった状況を抜けだせていない現場が多い。 アジャイルな手法を導入してみるものの失敗したりしている現場もあるが、 非効率な商慣習の縛りをそのままにアジャイルの手法を導入しているため、 うまくいかなかったり・・・。 そんなケースが多い中、「納品のない受託開発」では顧客との取引方法を 根本的に変え・取引相手も開発スタイルに適した相手に絞ることで、 アジャイル・スクラムなど有効とされる開発手法を徹底的に導入して システム開発会社・エンジニア・顧客全てがWin✕Winになります。 紹介されている各トピックは、勉強熱心なエンジニアの方ならどこかで 聞いたことのある内容が多いと思います。 しかし、色々と既存の制約に縛られがちな日本の受託システム開発において、 これらのトピックを有効活用し、実運用に活かせるように適用する方法を考え、 実際に事業を回していることにこそ、この手法の価値があるのだと思います。 システム開発に関わるものであれば、 読んで何かしらを得られる良書だと思います。
Posted by
納品に追われ、終わったら別の顧客(案件)という流れにいる身としては、全く対極で刺激的な内容。お客さんと、月額に対する成果の価値観に差がでないか?など気になる点もあるけど、うまくできれば顧客との関係や働き方、やりがいなどプラスの面も多そう。
Posted by
創業にあたり、事業展望をきっちりと見据えることは難しい。打ち出した新機軸への思いがあってもいきなりの成果は確約できず、かといって当然に発展は目指している。事業の成長とともにシステムも成長させていけばいいのだが、創業時点で導入すべきシステムの規模と、運用・保守の規模をどの程度に設定...
創業にあたり、事業展望をきっちりと見据えることは難しい。打ち出した新機軸への思いがあってもいきなりの成果は確約できず、かといって当然に発展は目指している。事業の成長とともにシステムも成長させていけばいいのだが、創業時点で導入すべきシステムの規模と、運用・保守の規模をどの程度に設定したものか。要件定義が固まらずして仕様が書けない。よって、無駄なバッファが乗るのを否めない。現在抱えている課題が、ある側面から浮き彫りになった。ただ、受注者であるベンダーの質と意識も大いに問われる。
Posted by
パッケージで売るのではなくエンジニアを外注してその中で開発を行おうという話。ネットベンチャーのサービス開発には向いていると思う。
Posted by
著者のブログを以前から読んでいたので、記載されている内容については「そうだったそうだった」と思い返しながら読んでいた。 IT業界の問題の根源を「一括請負」と「納品」にあると説き、その理由と「納品のない受託開発」がどんなものかを丁寧に解説している。 この「納品のない受託開発」の...
著者のブログを以前から読んでいたので、記載されている内容については「そうだったそうだった」と思い返しながら読んでいた。 IT業界の問題の根源を「一括請負」と「納品」にあると説き、その理由と「納品のない受託開発」がどんなものかを丁寧に解説している。 この「納品のない受託開発」の考え方は、SI業界に身をおいて苦労を経験したことがある人たちの間では既に広まっており、業務としてアジャイル開発を既に実践している人や、工数精算前提のビジネスモデルではなく、ITをモノではなくサービスとして提供しているビジネスを行っている人たちにとっては素直に受け入れることができ、当たり前の考え方、と感じるだろうけれども、そうではない、以前大多数を占める工数精算前提のビジネスモデルの企業に従事し、日々デスマーチや過酷なプロジェクト、生産性や高いスキルとは真逆の工数ビジネスに幻滅している技術者や、ITを単なる金食い虫と考えている経営者にとっては新しい概念と感じると思う。 むしろそういう層の人たちに1人でも多く届いて欲しいし、それが広まることがSI業界に従事する人や、ユーザー企業やIT部門を幸せにする唯一の道だと個人的には感じている。この本に書いてあることが、書籍としての形で世に出て広まることが一番大きいことだと思う。 「納品のない受託開発」に関しては、スケーラビリティや適用領域(ミッションクリティカルな領域、大規模システム、金融、公共、人命など)に関して疑問を呈する意見が一方で出てきているのも認識している。が、この本の中でははっきりと、銀の弾丸ではない、それらにはそれらの適した作り方、開発方法があると記述しており、誠実だと感じた。それどころか、世の大規模システムの多くは本当は多くの機能が必要、ということに対して疑問を感じると書いていて、個人の感覚としても頷ける。 必要以上に大きくしない、という考え方を、ソニックガーデンという企業自体にも適用されていて、小さいほうが技術者としても幸せではないかと感じていると記されている。 技術者が幸福に働くには、ナレッジワーカーという働き方、社員の幸せを大事にする、といった考え方が記されており、この辺りも大きな企業で改革や改善をしようと行動し、理不尽な制約やしがらみで潰されたり挫折した経験がある人なら、同意出来る部分ではないだろうか。 昨今、社員を単なる固定費・コスト扱いし使い倒すことで利益を上げてきた企業の不調が浮かび上がってきており、企業の持続的な成長や繁栄には、社員個人個人の幸せや成長を大事にすることが不可欠、ということが認知されてきたと感じるが、そういう意味でもソニックガーデンはそれを体現している企業だと感じた。
Posted by
「納品をなくせばうまくいく」の感想part1~ソフトウェア業界のビジネスモデルが抱える問題: プログラマの思索 http://forza.cocolog-nifty.com/blog/2014/06/part1-5631.html 「納品をなくせばうまくいく」の感想part2~...
「納品をなくせばうまくいく」の感想part1~ソフトウェア業界のビジネスモデルが抱える問題: プログラマの思索 http://forza.cocolog-nifty.com/blog/2014/06/part1-5631.html 「納品をなくせばうまくいく」の感想part2~「納品のない受託開発」のビジネスモデル分析: プログラマの思索 http://forza.cocolog-nifty.com/blog/2014/07/part2-c02b.html
Posted by
顧客がプログラマーに直接発注する形態で、誰がユーザーエクスペリエンスやユーザビリティを担保するのか。プログラマー一人で何でも出来るという考え方なのだろうか。前述のポイントを専門家がケアしなければビジネスとしての成功確率は低いと思うのだが。 それについては語られていないようだった。...
顧客がプログラマーに直接発注する形態で、誰がユーザーエクスペリエンスやユーザビリティを担保するのか。プログラマー一人で何でも出来るという考え方なのだろうか。前述のポイントを専門家がケアしなければビジネスとしての成功確率は低いと思うのだが。 それについては語られていないようだった。あるいは顧客の役割と位置付けられているのかもしれない。ほとんどの顧客はそのような能力を持たないと思うのだが。 顧問と例えられる契約形態は、請負契約ではなく準委任契約だろうか。私のところでも顧問型のサービス割合が増えつつある。納品のない受託開発というコンセプトは素晴らしい。機会があれば引用したいと思う。
Posted by
SIの構造的欠陥、ユーザとSIerの利益相反に対する1つの答えと言える。ユーザとシステム会社が同じ方向を見て仕事を進められる一つの形。 これまで人月の枠で均質・画一的に捉えられていたエンジニアをナレッジワーカーとして再定義した点も新しい。今後の課題はこの「俗人化」によるサービスが...
SIの構造的欠陥、ユーザとSIerの利益相反に対する1つの答えと言える。ユーザとシステム会社が同じ方向を見て仕事を進められる一つの形。 これまで人月の枠で均質・画一的に捉えられていたエンジニアをナレッジワーカーとして再定義した点も新しい。今後の課題はこの「俗人化」によるサービスがメリットでもあり、リスクでもある点だろうか。
Posted by
「顧問エンジニア」というのがとてもしっくりくる呼び名だと感じた。「顧客に対して価値のあるモノ(サービス)を作りたい」、「エンジニアとして生涯生きていきたい」といったことを考える人には良くマッチした仕組みだと思う。
Posted by