無料マンガ・ラノベなど、豊富なラインナップで200万冊以上配信中！
無料マンガ・ラノベなど、豊富なラインナップで200万冊以上配信中！
ソフトウェア業界の“常識”をくつがえすビジネスモデルを大公開！
これまでの「一括請負」には、予算・人員・納期が限られるなかで、開発企業は疲弊していき、ユーザー企業も料金に見合う満足度を得られないという根深い問題がありました。
こうした通弊を解決するのが「納品のない受託開発」。これは、開発企業がユーザー企業と月額定額制の顧問契約を結ぶことで、納期を廃して、開発から運用までをトータルで継続的にサポートするもの。
従来とはまったく逆の発想をゆく新たなビジネスモデルを考案し、日々実践する経営者が業界の構造的な問題に鋭く切り込み、新たなソリューションを提示します。
ソフトウェアエンジニアをはじめ、システムインテグレーター・IT企業の営業担当者や経営幹部、ユーザー企業の担当者、就職学生、起業家などにもオススメです！
【目次】
1章 常識をくつがえす「納品のない受託開発」とは
受託開発なのに「納品」がない？
「納品」が引き起こしてきた問題とは
ソフトウェアはなぜそんなに高いのか？
「納品のない受託開発」が問題を解決する
弁護士や税理士のような“顧問”ビジネスとして
2章 時代が「納品のない受託開発」を求めている
スタートアップに適したシステム開発とは
「納品のない受託開発」で解決できること
「納品のない受託開発」の契約
この世界に「銀の弾丸」は存在しない
3章 顧客から見た「納品のない受託開発」の進め方
「何を作るか」よりも「なぜ作るのか」
開発と運用が同時並行で進んでいく
顧客が分担する作業もある
開発と運用を繰り返して改良し続ける
4章 事例に見る「納品のない受託開発」
まるで“子育て”のようなソフトウェア開発──株式会社AsMama
仕様変更に柔軟かつスピーディに対応──株式会社トライフ
5章 「納品のない受託開発」を支える技術とマネジメント
「完成」から「持続」への変化
「納品のない受託開発」を支える技術戦略
アジャイル開発によるマネジメント
人を信頼し、中心におく経営
6章 エンジニアがナレッジワーカーになる日
アジャイル開発を実践する新しいビジネスモデル
エンジニアにとっての幸福な働き方とは
優秀なエンジニアを採用するには
ナレッジワーカーとしてのエンジニアをどうやって育てるか
7章 「納品のない受託開発」をオープン化する
「納品のない受託開発」がもたらす未来
小さな会社の大きなビジョン
「ベストエフォート経営」で社員の幸せを大事にする
「納品のない受託開発」を拡大する「のれん分け」と「ギルド」
Social Change! 自分の変化を世界に広げていくこと
※アプリの閲覧環境は最新バージョンのものです。
Posted by ブクログ
かなり良本。
私個人も現代のSIer業界に違和感を感じて悩めるエンジニアに対してキャリアコンサルを提示しているが、本来エンジニアのあるべき姿。
特にフリーランスSEという働き方はあるが、本来フリーランスはプロ（個人事業主）。ようは1人社長だ。
なのにも関わらず、某エージェントの「簡単に稼げる」という煽り文句の広告のせいで、ナレッジワーカーな姿勢が見えない、中途半端なフリーランスSEが増えて来た。
最終的にはスキルもないのに「楽して高収入」目的で、フリーランスに入る。
エージェントにはワガママを、現場にはできないタスクを押し付ける微妙なエンジニアも増えていく。
ぜひ、エンジニア、そして全てのSIer業界の役職ある方達は読んで欲しい良本。
むしろ2014年に発刊して、未だに変わらないこの状態であることが不思議。
だからこそ、我々から見ると穴だらけなのだが多くの人は気づいていない。
Posted by ブクログ
システムの受託開発を長くやっていると、顧客と開発者との間に意識のギャップを感じることが時々あります。システムの完成させるという目標は一致しているはずなのに、その先の最終ゴールの捉え方が致命的に異なるのです。
こうしたギャップは、システムを使ってビジネスを拡大したり作業を改善することをゴールと捉える側（顧客）と、システムを完成させること自体をゴールとする側（開発者）の立ち位置の違いから考えると、当然なのかも知れません。
このようなジレンマを抱えながらシステムの受託開発をやってきた私のモヤモヤを、本書は多少なりとも晴らしてくれたような気がします。
システム開発側（特にエンジニア）はとかくシステムを作ることだけに目が向きがちですが、「ソフトウェアは使い続けることではじめて価値が出る」「なぜそのソフトウェアが必要なのか」等々を常に念頭に置いて顧客と接することで、顧客からの信頼を勝ち取ることにも繋がるのではないでしょうか。
特にソフトウェアは出来上がるまで目に見えない分、使ってみることで顧客が本当に必要とするものが分かることが多々あります。そういった意味でも「納品のないソフトウェア開発」のスタイルは、本当に必要なものだけ作ることが実現できる分、余計なコストがかからず顧客にとっても嬉しいはずです。
一方エンジニアにとっても、顧客からのフィードバックを受けやすく、やりがいのあるやり方であると言えるでしょう。
本書にも書かれているとおり、「納品のないソフトウェア開発」はサービスを提供する会社やスタートアップ企業と相性が良いようです。一方で、少数精鋭のエンジニアで臨む分、大規模な基幹システムには向かないような気がします。
ただ、たとえ大規模システムであっても、顧客と開発者の連携やワークレビューなど「納品のないソフトウェア開発」のやり方を応用することで、従来のプロセスを見直すヒントになるのではないかと感じています。
Posted by ブクログ
株式会社ソニックガーデンで実際に行われている
「納品のない受託開発」という新たな開発スタイルに関して、
・どんなものか説明
・どのような利点があるか
・既存の受託開発の問題点
・自社の枠に留まらない「納品のない受託開発」の展望
などについてまとめてあります。
従来のウォーターフォール・人月見積もりなど問題点の多くある
業界では、未だにそういった状況を抜けだせていない現場が多い。
アジャイルな手法を導入してみるものの失敗したりしている現場もあるが、
非効率な商慣習の縛りをそのままにアジャイルの手法を導入しているため、
うまくいかなかったり・・・。
そんなケースが多い中、「納品のない受託開発」では顧客との取引方法を
根本的に変え・取引相手も開発スタイルに適した相手に絞ることで、
アジャイル・スクラムなど有効とされる開発手法を徹底的に導入して
システム開発会社・エンジニア・顧客全てがWin✕Winになります。
紹介されている各トピックは、勉強熱心なエンジニアの方ならどこかで
聞いたことのある内容が多いと思います。
しかし、色々と既存の制約に縛られがちな日本の受託システム開発において、
これらのトピックを有効活用し、実運用に活かせるように適用する方法を考え、
実際に事業を回していることにこそ、この手法の価値があるのだと思います。
システム開発に関わるものであれば、
読んで何かしらを得られる良書だと思います。
Posted by ブクログ
「納品のない受託開発」というソニックガーデンのビジネスモデルについて、効果・仕組み・向き不向き・事例などについて、従来型の一括請負の問題点の指摘とともに説明されている。
「納品のない受託開発」は合理的で素晴らしい仕組みだと思うが、本書でも注意喚起されているとおり万能ではなく、また、実現のための前提が難しいものになっている。
たとえば、エンジニアや会社のスキルやモチベーションの要求水準が高いこと、顧客側の作業や体制への要求も比較的高いこと、システムの会社や規模に制約があること、など。
つまり、ソニックガーデンやそれに類するレベルの高さが要求されるため、誰でも容易に真似できるわけではないという点は留意したい。
本書は昔買ってから時々つまみ食いのように読むだけで積んだままになっていたが、唐突に読みたい気持ちが高まってきたので読んだ。
スピードを重視して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ページ
よく講演などでは「心はプログラマー、仕事は経営者」と自己紹介をしたりしています。
→よい。これも参考にしたい。心はユーザー、体はエンジニア、仕事はマネージャー。
※アプリの閲覧環境は最新バージョンのものです。
ビジネス・実用
ビジネス・実用
ビジネス・実用
ビジネス・実用
