見積と情シス
アウトソーシングしていますので、見積を確認する機会が多いのですが、プロジェクトが大きくなるほど見積って幅が出てきますよね。あとになってもめないように気を付けていることを書いてみます。
予算を確認しておく
こちらで記載した通り。
https://note.com/pyonnpyon/n/nedc108113463
で、予算と案件が大幅に乖離する場合は早めに「やめたほうがいいよ」って言ってます。
提案依頼書をしっかり書く
大きめのアプリの場合、複数ベンダーに相見積を取って提案依頼を求めるようなことをやりますが、私の場合は下記を参考にしています。
※日経システムズのこのシリーズは具体的で大好きです。
要件定義を分ける
要件定義フェーズで見積を分けるというのは本来開発のセオリーですが、弊社みたいにベンダーをずっと決め打ちでやってきたようなところだと、結構「年間全体の委託でおいくら」みたいな感覚でやってきたようなところがあって、3行くらいの案件をもらって見積を出して数人月の規模の案件を発注してしまうとか、以前は結構ありました。
そうなると当然、あとになってから、見積とのぶれが出てきます。そんなときも、ずっと以前はゆるかったので、「じゃあ追加にするか」みたいな感じでしたが、今はそんなことは許されないので、見積の精査を強化したり、レビューを強化したり、要件定義を分けるようなことをしています。
ここで当たり前なんですけど「要件定義の成果物として設計以降のプロセスの見積を出させる」というのを必ず記載させてます。以前要件定義も終わりになってからとあるベンダーから「そんなこと聞いてません。今の状態では見積もりが出せないです」って言われたことあったので。なんだよそれ！
注意したいポイント
設計以降のプロセスでもめやすい箇所というと、インフラ構築とテストフェーズ・運用支援があります。開発は誰がどこをやるかというのはわかりやすいですが、これらのプロセスは作業者が分かれるからです。最近は、要件定義でインフラ側の内容もある程度見越しておくこと、テストについては事前に支援範囲を決めておく、運用についてはマニュアルのあるなしなどを明確化しておくことでずれはなくなっています。
※基本マニュアルは、ユーザ側が作るべきだと思っているので、画面設計書だけで済ませるようにしています。
「あたりまえ」の境界線
見積でよくもめやすいのはここだと思います。「弊社と長くつきあっているのだからこれくらいわかるだろう！」みたいなやつですね。こういうのはベンダーロックインを生み出すことにしかなりませんので、やらないんですけど、弊社みたいなお付き合いしている先がある程度決まっている会社だと、ユーザ側もベンダー側も、このあたりの考えがまだまだだなあ、と思っています。。。