こんにちは。
株式会社フルーデンスの小巻です。
今回は、タイトルの通り、ソニックガーデンさんの有名な本『「納品」をなくせばうまくいく』を読んだので、感じたことや考えたことを書きたいと思います。
少し長いですが、以下のようなことがきっかけで、この本と出会いました。
ーーーーーーーーーー
今まで、様々なプロジェクトでFileMakerの開発をしてきましたが、以下のような困るケースに出会うことがありました。
- 仕様が分からない状態にも関わらず、お客様から見積りを求められる。
- 要望を確認し、要件定義をし、開発を進めていると、途中で新しい担当者がプロジェクトに参加することになり、そのことがきっかけで仕様が変更される。
- 要件定義をし、ドキュメントやモックを作り、お客様と開発者で同意ができており、開発を進めていたが、途中で動くソフトウェアのデモをすると、認識が間違っていたことに気づき、仕様が変更される。
上記のようなケースは一例ですが、想定通りに、スムーズに進むことの方が珍しいと思います。
プロジェクトの途中で仕様変更は必ず発生するものですが、タイミングによっては、
- 再見積りをして、費用や納期など、対応方法を検討する。
- 限られた予算の中で、機能の削減や優先順位を検討する。
などの調整をすることになります。
また、納期が迫っている状態で、仕様変更などが発生する場合、より良い実装方法に変更する時間や、設計について考える時間が十分に取れずに実装することも起こるかもしれません。
開発会社としては、本来あるべき姿ではないことは分かってはいるものの、納品をしなければ売り上げになりませんので、何かを犠牲にすることもあると思います。
一括請負の受託開発への疑問
今までの一括請負の受託開発は、お客様にとって本当に良いことなのだろうか？と長いこと疑問に感じていました。
一括請負の受託開発で感じた様々な課題は、どのようにすれば解決できるのだろうか？と考えた結果、私は「見積り」の伝え方や対応方法を見直すことで解消できるのではないか？と仮説を立ててみました。
というのも、課題の原因は、費用部分にあると考えたためです。
では、具体的に「見積り」の伝え方や対応方法を、どのようにすれば良いのか考えました。
- 仕様が分からない状態では、見積りは提出しない。
- 仮に提出するにしても「不確実性のコーン」を考慮し、プロジェクトの初期の見積りでは金額や納期に大きな幅(16倍の差)があることを伝える。
- 精度の高い見積りを提出するためには、時間もコストもかかることを伝える。
- 仕様変更があることを前提にし、最低でもN回は、再見積りを提出することを伝える。
- 見積りの幅が大きい場合、金額や納期など、計算して提出する。
※上記の内容は「ソフトウェア見積り 人月の暗黙知を解き明かす」という本に詳細に記載されています。
「ソフトウェア見積り 人月の暗黙知を解き明かす」を読んで考えたことは、別途書きたいと思います。