EarOwlの日記: こんなプロジェクトもう嫌だ 3
今やっているプロジェクトがそれはもう酷すぎてちょっと愚痴る。
受託開発の案件なんだけれど、そもそも要求仕様があまりにも不明瞭。
重要な部分の処理が『これまで使っていたソースコード/ツールがあるのでそれを流用してください。仕様書はありません』という。何か質問しても大抵『元のソースコード/ツールを見て下さい』と返される。
そのソースコード/ツールがちゃんと設計されて流用性も良いものなら良かったのだけれども、実際は元々ソフトウェア開発は専門外の人が片手間に作ったようなものらしく、設計もムチャクチャだしちょっと手を入れようものなら却ってバグが出てしまうような代物。
で、私がこのプロジェクトを引き継ぐ前の前任者は、そんな状況に加えて、開発中から仕様追加・変更等の要求がこちらのスケジュールを考えずに上がってくるのに辟易して、やっつけでとりあえず動くところまで作ったような状況でこのプロジェクトから離脱。
この時点でもう手を引いたほうが良かったのだけれども、追加開発を見込んで初期開発分を大安売りしちゃったせいで、営業的にはやめるにやめられない。
ちなみに肝心の追加開発は、こちらのスケジュールの都合がつかず (費用面の問題もあったか?) 結局一部 (というか大部分?) 他社に流れてしまったりしている。そもそも社内にソフトウェア開発者の手が不足しているのである。
で、私がその後を引き継いで (どう考えてもちゃんとした引き継ぎは行えていないけれど) 追加開発となったのですが、まずスタートが別プロジェクトの作業遅れに押されて遅れた上に、前任者のやっつけ仕事っぷりが想像以上で見積もり時の想定作業量を大幅にオーバー。追加要員も期待できず、残業と休日出勤でなんとか出来るところまでやろう、それでも納期に間に合うかどうかという状態。
一応私からは『このままじゃ無理!』というアラートは上げたのだけど、どうも対外的な立場もあってか営業から先へ上手く伝わらない感が。
このことから得られる教訓は、たくさんあると思うけどとりあえず…
- 何を作ればいいかはまず明確にする。そのために必要な作業時間や資料すら与えられないなら、そのプロジェクトには手を出さないか、早めに手を引く。
- 開発の規模が大きい場合やスケジュールがタイトな場合は社内のリソースをちゃんと考慮する。
- 追加開発を見込んで初期費用を値引きしない。
- 見積もり時点での想定作業量は切り詰めすぎず、何かあったときのためのバッファを確保しておく。
- ソースコード・資料は問題なく引き継ぎが行えるレベルまでちゃんと作る。
参考:『おごちゃんの雑文』より『ダメな仕事を受けないためのNGワード』。『今回は予算があまりないので小額になりますが、次回はしっかり払いますので』に、まさに嵌ってしまったという感じ。
ちょっと追記 (スコア:1)
見積基準 (スコア:1)
自分の勤め先の見積基準では、
「《既存のアプリケーションと同一の動作をすること》という要件のリスクは「100%」」
となっていました。(見積金額を2倍にしろということ)
ドキッ (スコア:0)
>『今回は予算があまりないので小額になりますが、次回はしっかり払いますので』
。。。。今の案件大丈夫かな。
なんかクライアントから同じセリフを聞いたような。