パスワードを忘れた? アカウント作成
877427 journal
プログラミング

EarOwlの日記: こんなプロジェクトもう嫌だ 3

日記 by EarOwl

今やっているプロジェクトがそれはもう酷すぎてちょっと愚痴る。

受託開発の案件なんだけれど、そもそも要求仕様があまりにも不明瞭。

重要な部分の処理が『これまで使っていたソースコード/ツールがあるのでそれを流用してください。仕様書はありません』という。何か質問しても大抵『元のソースコード/ツールを見て下さい』と返される。

そのソースコード/ツールがちゃんと設計されて流用性も良いものなら良かったのだけれども、実際は元々ソフトウェア開発は専門外の人が片手間に作ったようなものらしく、設計もムチャクチャだしちょっと手を入れようものなら却ってバグが出てしまうような代物。

で、私がこのプロジェクトを引き継ぐ前の前任者は、そんな状況に加えて、開発中から仕様追加・変更等の要求がこちらのスケジュールを考えずに上がってくるのに辟易して、やっつけでとりあえず動くところまで作ったような状況でこのプロジェクトから離脱。

この時点でもう手を引いたほうが良かったのだけれども、追加開発を見込んで初期開発分を大安売りしちゃったせいで、営業的にはやめるにやめられない。

ちなみに肝心の追加開発は、こちらのスケジュールの都合がつかず (費用面の問題もあったか?) 結局一部 (というか大部分?) 他社に流れてしまったりしている。そもそも社内にソフトウェア開発者の手が不足しているのである。

で、私がその後を引き継いで (どう考えてもちゃんとした引き継ぎは行えていないけれど) 追加開発となったのですが、まずスタートが別プロジェクトの作業遅れに押されて遅れた上に、前任者のやっつけ仕事っぷりが想像以上で見積もり時の想定作業量を大幅にオーバー。追加要員も期待できず、残業と休日出勤でなんとか出来るところまでやろう、それでも納期に間に合うかどうかという状態。

一応私からは『このままじゃ無理!』というアラートは上げたのだけど、どうも対外的な立場もあってか営業から先へ上手く伝わらない感が。

このことから得られる教訓は、たくさんあると思うけどとりあえず…

  • 何を作ればいいかはまず明確にする。そのために必要な作業時間や資料すら与えられないなら、そのプロジェクトには手を出さないか、早めに手を引く。
  • 開発の規模が大きい場合やスケジュールがタイトな場合は社内のリソースをちゃんと考慮する。
  • 追加開発を見込んで初期費用を値引きしない。
  • 見積もり時点での想定作業量は切り詰めすぎず、何かあったときのためのバッファを確保しておく。
  • ソースコード・資料は問題なく引き継ぎが行えるレベルまでちゃんと作る。

参考:『おごちゃんの雑文』より『ダメな仕事を受けないためのNGワード』。『今回は予算があまりないので小額になりますが、次回はしっかり払いますので』に、まさに嵌ってしまったという感じ。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by EarOwl (24188) on 2011年11月12日 0時31分 (#2049021) 日記
    追加開発のあたり、そもそも『追加開発分は初期開発で作成したものを流用できるから簡単になるよね』という前提もあったみたいだけど、前任者の成果物が結局『とりあえず初期開発での要求部分は動くように作った。後は知らん』ってな状況で、追加開発も思うほど簡単じゃなくなってしまっていたという。
  • by Anonymous Coward on 2011年11月12日 11時37分 (#2049146)

    自分の勤め先の見積基準では、
    「《既存のアプリケーションと同一の動作をすること》という要件のリスクは「100%」」
    となっていました。(見積金額を2倍にしろということ)

  • by Anonymous Coward on 2011年11月12日 2時35分 (#2049068)

    >『今回は予算があまりないので小額になりますが、次回はしっかり払いますので』
    。。。。今の案件大丈夫かな。

    なんかクライアントから同じセリフを聞いたような。

typodupeerror

犯人はmoriwaka -- Anonymous Coward

読み込み中...