› 田舎のITコンサル社長ブログ › ハマリ案件

2006年02月23日

ハマリ案件

物作りをする方なら、誰でも1度は経験するであろうハマリ案件。

・依頼(クライアント)
  ↓
・見積(弊社)
  ↓
・発注(クライアント)
  ↓
・受注(弊社)
・作業(弊社)
  ↓

この後に"納品"・"検収"・"請求"などと続く訳ですが、ハマリ案件とは"見積"と"作業"のマイナスギャップが大きい場合を指して、私が勝手に呼んでます。

例えば100万円で受注している案件に対して、実際は200万円の経費が掛かってしまうなどです。
こんなことになると、当然ですが儲かりませんしむしろマイナスですね。

当然、見積の際に経験によって想定した見積を出す訳ですが、たまに想定外なことが発生します。
この業界、毎回のごとく新しいことへの挑戦も多いので、ハマリ案件の発生率も若干高いかもしれません。
(どの業界でも一緒かな?)

年末ぐらいにお話しを頂戴し、某中古車販売サイトを構築しているのですが、デモサーバと実働サーバの差によって、今回上記のようなことが発生しています。
実働サーバが何でもできるものなら良いのですが、予め某レンタルサーバとの指定があり移設後になって"○○は出来ません"などの連絡を受け、その都度にプログラムを修正している状態です。

末端のエンジニアが可愛そうですが、それと同時に実働サーバでの検証を事前にしっかりとやるべきだったと、今になって当然のごとく思います。
某レンタルサーバは大手企業が運営しており、信頼性も高いものの制限もきつい。
自分達がサーバを立てるなら、それこそやりやすいように出来るのですが、そんなのは言い訳にしかなりません。

検証担当のエンジニアに確認したら、予めサーバ仕様は確認しておるものの、確認した部分では判らない問題として今回表面化したとのこと。
確かに、ホームページに開示されているようなスペック表では、とても対応しきれない情報ではあります。
結果的に、ほぼ2つのシステムを作っているような形になっており、開発エンジニアにとって、これはかなり大変なことです。

ある意味、組織統制がしっかりしていない恥ずかしい面です。
より完成度が高くなるよう、常に見つめていかなければならないと同時に、担当エンジニアに対して、しっかりフォローしないと。


Posted by 大樹直人 (naohito ooki) at 19:23│Comments(1)
上の画像に書かれている文字を入力して下さい
 
<ご注意>
書き込まれた内容は公開され、ブログの持ち主だけが削除できます。