sakaharaのブログ

アプリ開発に関する話や日々の出来事など

書籍「納品をなくせばうまくいく」を読んでより良い開発手法について考えてみた

この書籍自体は昨年出版された当時に一度読んだのですが、最近は受託の仕事が多く今後に活かすために改めて読み直しました。

「納品」をなくせばうまくいく ソフトウェア業界の“常識

「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル

ちなみに納品のない受託開発と勘違いしそうになりますが、人材派遣とは違い、顧客企業のオフィスで働いたり、時間単価での契約ではなく、顧客の得る成果と満足度による契約をするという前提にしています。

今回この書籍を読み直すことで新たな発見があったので理解を深めるため整理してみました。

従来通りの納品する受託開発のデメリット

  • 要件定義で事前に全てを決めることは難しい(要件定義後に様々な事情で要件が変わることは多々ある)
  • 人月の問題 - 工数の精度にもよるが、下手をするとだめなエンジニアほど時間がかかって儲かるという変な仕組みがうまれる
  • 開発と運用で業者や担当者が別になることで、ドキュメントが欠かせなくなり価格がその分上がる
  • 上記のように開発と運用で別の人間が担当すると自分達が開発したわけではないため、リスク回避のため少しの修正でも高く見積もってしまう
  • 最大時を想定したハードウェアの購入になってしまい、あとからの変更が難しい

とデメリットをいくつか挙げましたが仕様変更が難しかったり、価格が高くなりがちだったりと問題は多々あります。 また構造的に発注した顧客にとってはビジネスの成功が目的だとしても、開発会社にとっては完成したソフトウェアに自体に価値があると勘違いしやすくなるため、気をつけないといけないと思います。

納品のない受託開発のメリット

  • 月額定額の料金体系にできる
  • 要件定義をしなくてよい - 最小限の機能を決めて、なるべく早い段階でユーザーへ提供できる
  • どれだけ仕様変更してもよい
  • 例えば打ち合わせは全てリモートで行うことで、無駄な経費を削減できる
  • 仕様決めから、開発、テストまで1人のエンジニアが担当することで、ドキュメント等の作成を簡略化できコスト削減につながる。

他にもメリットはありそうですが、次にデメリットをあげてみます。

納品のない受託開発のデメリット

  • エンジニアに幅広いスキルが必要
  • そもそも大規模で要件定義がしっかりできている案件には向かない
  • 顧客との信頼関係が構築できないと難しい

ここにあげたものはデメリットというより、エンジニアに交渉のスキルやフロンドエンド、バックエンド含め広い範囲の技術が必要になるということが、実現するためのハードルの高さになっているかもしれません。

まとめ

本来クリエイティブなはずのプログラミングという仕事が日本、特にSI事業に関しては最下層に位置づけられるような残念な会社がたくあります。 ですが著者が考えるコンセプトはプログラマーを非常に大事にしており、どうすればお客さんと実際に仕事するプログラマーがお互いに幸せになれるかということを突き詰めた結果がこの書籍の内容になっているのだと思います。 私もプログラミングを生業として10年以上生きてきた身としては、現状の環境を少しでも改善するためのヒントがたくさん詰まっている本で、大変参考になりました。

プログラマー以外の人がこの本を読むことで、より良い成果を上げるための議論ができるきっかけになればよいと思いました。