投稿元:
レビューを見る
従来の一括請負ではなく、月額定額でソフトウェア開発の対価をもらうビジネスモデル。
エンジニアは基本1人で対応するため、ビジネスを理解し、かつ技術的にもフルスタックエンジニアが求められるので大変そう。
また、著者も言っているが、今のところ大規模開発には対応できない、と。
ただ、この業界にいる身としては、契約形態のパラダイムシフトの第一歩、って感じで良いな、と思った。
投稿元:
レビューを見る
システムの受託開発を長くやっていると、顧客と開発者との間に意識のギャップを感じることが時々あります。システムの完成させるという目標は一致しているはずなのに、その先の最終ゴールの捉え方が致命的に異なるのです。
こうしたギャップは、システムを使ってビジネスを拡大したり作業を改善することをゴールと捉える側(顧客)と、システムを完成させること自体をゴールとする側(開発者)の立ち位置の違いから考えると、当然なのかも知れません。
このようなジレンマを抱えながらシステムの受託開発をやってきた私のモヤモヤを、本書は多少なりとも晴らしてくれたような気がします。
システム開発側(特にエンジニア)はとかくシステムを作ることだけに目が向きがちですが、「ソフトウェアは使い続けることではじめて価値が出る」「なぜそのソフトウェアが必要なのか」等々を常に念頭に置いて顧客と接することで、顧客からの信頼を勝ち取ることにも繋がるのではないでしょうか。
特にソフトウェアは出来上がるまで目に見えない分、使ってみることで顧客が本当に必要とするものが分かることが多々あります。そういった意味でも「納品のないソフトウェア開発」のスタイルは、本当に必要なものだけ作ることが実現できる分、余計なコストがかからず顧客にとっても嬉しいはずです。
一方エンジニアにとっても、顧客からのフィードバックを受けやすく、やりがいのあるやり方であると言えるでしょう。
本書にも書かれているとおり、「納品のないソフトウェア開発」はサービスを提供する会社やスタートアップ企業と相性が良いようです。一方で、少数精鋭のエンジニアで臨む分、大規模な基幹システムには向かないような気がします。
ただ、たとえ大規模システムであっても、顧客と開発者の連携やワークレビューなど「納品のないソフトウェア開発」のやり方を応用することで、従来のプロセスを見直すヒントになるのではないかと感じています。
投稿元:
レビューを見る
アジャイル開発を前提とした、ソフトウェアビジネスモデルの話。
市場の反応を見ながら仕様を変えていくwebサービスにぴったりというか、いわゆるITベンダーならどこもやっていそうな話。
非IT企業に同じような開発プロセスを提供できるビジネスモデルというところが新しい。
1番の問題は、受け入れ側に、今まであった要件定義という明確な仕様がない状態での発注ができる仕組みがあるかどうか、というところだったりする気が。
製造系の会社って、なぜなぜ的な問いの立て方は得意だけど、そもそも系の問いの立て方は苦手なイメージというかステロタイプがあるので、文化の違いで衝突しそうな…。
そもそも、そんなアタマの硬い製造業の会社はもう淘汰されているか。
投稿元:
レビューを見る
自分はシステム開発など、全く門外漢ですが、とても、共感できる内容。
自分が働きたいのはこんな仕組みの会社だなと感じました。
スッキリとして読みやすいのに、とても整理された文章も印象的。会社の内容と同時に、こちらもスッキリしてムダがない。そして、芯がしっかりしています。
この理念というか考え方は、今後、日本の中小企業が皆見習うべき部分だと思います。
投稿元:
レビューを見る
業界の問題を解決する為に自分でビジネスモデルを作る
ことは凄いと思う。作者の思想がよく描かれていて理解もできるけど、会社経営の視点でみると最低限の利益を得なければ長期的な経営が難しいのではないかと思う。
印象としては気の合うエンジニアの集まりに近い感じが
する。若手を育てる感じはあまりなさそう。
投稿元:
レビューを見る
受託開発(会社)の観点から、顧客のみならずその先のエンドユーザーそして社員を幸せにする仕組みとしての会社ないしはビジネスのあり方を提唱している素晴らしい一冊。
製造業からサービス業へ、工場から工房へ。サービス開発やソフトウェア開発そのものが目的ではなく、ビジネスを成長を望み、目的と手段が混同せず、正しいを追求する姿勢を保ってくれる素晴らしい発想だと思う。
投稿元:
レビューを見る
ソフトウェアの「成長」をエンジニアが正しく導くことができるのであれば、とても有効な開発方法だと思う。
ユーザー側も実現したい事や業務の問題点がはっきり見えていないこともあるので、じっくりと対話を行って方向性を決めていけるのはメリットが大きい。
問題は、エンジニアの引き継ぎが難しくなる点。
投稿元:
レビューを見る
事業会社でエンジニアをしている自分にとってはある程度当たり前だと思っていることが、受託会社にとっては画期的なことなんだなぁという感じ。
投稿元:
レビューを見る
デスマーチを経験して、受託開発のデメリットを実感した中でこの本を読んだ。
受託開発自体は魅力的な仕事であると思うので、この本に書いてある事が理想的な受託開発だと感じた。
投稿元:
レビューを見る
必ずしも全てのSIに適用できる訳ではないものの、適用できるケースであれば、方法論としてはアリだよな。やはりそもそも、事前に机上で全ての業務、データパターン、イレギュラー処理まで設計するのは容易ではないし、その時は出来たとしてもビジネスが進んでいくと実際の業務との差異も生まれてくる。なので、定額請負の中で、少しずつシステムを成長させていくことは、本来理にかなっているはず。ただ、お客様にもベンダーにも高い意識が求められるので、その理解が得られるかが鍵になるのかな。
投稿元:
レビューを見る
読み終わったー\(^o^)/
「納品のない受託開発」の提唱本。顧客に付き、段階的にソフトウェア開発を進める受託開発手法でした。
投稿元:
レビューを見る
ソフトウェア受託開発の人月ビジネスに疑問を抱いた筆者が、「納品の無い受託開発」という新しい形に挑戦している姿を書いた本。
理念と行動は悪く無いと思う一方で、ビジネスとしては限定的になってしまうかなとも感じた。
さくっと読める一冊。
メモ
自分達のポリシーに合わない仕事をしない、会社とお付き合いしない。
一部参考になる部分はある。
確かに人月ビジネスは違和感と変な部分は多々ある。その常識に真っ向勝負するのは素直にカッコいいと思う。
がしかし、まだまだ理解はされないし、スケールは難しいだろうから、中々業界を変えるまでは時間が掛かるだろう。
納品が無い分、チームになりやすく、最終的に良いプロダクトになる確率は高まるかとも思う。
ソフトウェアを「所有」から「利用」への考え方のパラダイムシフトという考えはとても良い
ワークレビューは面白い考え方。
投稿元:
レビューを見る
http://hinbeee.blog31.fc2.com/blog-entry-2399.html
投稿元:
レビューを見る
製品ではなく、サービスを提供する点、またコンサルもできるエンジニアであること。顧客満足度・エンジニアの達成感ともに非常に強く感じられ、ベストなビジネスモデルであると感じた。
また一般的な開発であっても、顧客が真に必要としていることを読み解き、システム化していく点については、共通して重要であり、難しい要素が多いと感じた。
投稿元:
レビューを見る
以前勤めていた職場のつながりもあって読んでみた一冊。今の仕事でもそうだし、この形での働き方は求められているだろうなと思いました。これまでのやり方を踏襲してうまいことまわそうとすると、技術の進歩のスピードやお客さんの要望の変化するスピードとのギャップが大きくなりがち。割と地方の中小企業のIT相談役のような役回りをしている企業はこういう問題を多く抱えていると思うし、ベストエフォートで定額で一緒に頑張っていきましょう、の方がお互いに無理なく前に進んでいけると思いました。いいヒントをもらったな、という印象です。