零細企業の受託開発あるある5連発

\ あなたにピッタリの銘柄がみつかる /

みんかぶプレミアムを無料体験!

プランをみる

お知らせ

読み込みに失敗しました。

しばらくしてからもう一度お試しください。

重要なお知らせ すべて見る

kenixiさんのブログ

最新一覧へ

« 前へ9件目 / 全20件次へ »
ブログ

零細企業の受託開発あるある5連発

この記事の所要時間: 約 4分57秒

photo credit: Catalyst Academy Drupal team (1) via photopin (license)
受託開発クソ食らえ。
僕はかねてより「自社案件をやりたい」と公言しているんですが、未だに受託開発しかやったことがありません。そんな受託マニアな僕が、受託開発あるあるを言いたいと思います。受託開発あるあるをぉぉーーーいいーーたいーーー。
工数外の仕様が次々に増える
本来であればバシッと固まった仕様をもって工数を出して、ウォーターフロー的に開発を進めたいところですが、現実問題こんな美しい流れはお目にかかれません。業務系であればウォーターフローが基本だとは思うのですが、残念ながら僕がいる業界は業務系ではない。
なのでざっくりとした仕様の中で、要件詰めながら設計開発をしていくわけですが、当初含まれていなかった機能がいつの間にかリリース対応項目になっているなんてのはよくあること。突然仕様が増えてるんですよ。仕様書更新したからーって言われて見てみたら、「新規」の文字が。えっ、これもリリースまでにやるんですか?みたいな。
もちろんその分工数出して開発期間くれるなら文句のつけようもないんですが、基本的に工数がないのはわかってるのに無理やりねじ込んできます。自社サービスとしてやっていて、担当者に対価という名の残業代を与えているなら別に構いませんが、外注しといて同じ工数でやれって、頭おかしいんじゃないですか?
僕に仮に経営権があったら、こういう対応してくる企業とは二度とお仕事したくないです。むしろ、今までの開発費だけもらって、早急にサヨウナラしたい。
仕様変更による修正が頻発する
これも上記と似たようなケース。
既に詰めて、コンセンサスを得た内容であるにも関わらず、「やっぱりこっちで、、、」みたいな。えっ、決めたよね?あの時間なんだったんですか?と。エンジニアを殺すには仕様を3度変えればいいと言いますが、僕は基本的に1回で死ねます笑。
というかですね、こちとら決めていった仕様をもとに設計して実装してるわけですよ。んで、修正ってなると、その前提が崩れるわけで。言い訳気味になりますが、変更変更と続くと、ツギハギな設計、ツギハギな実装になっちゃうんですよね。
変更工数をきちんと与えてくれれば修正内容をもとに組み直すんですが、当然ながらそんな工数が取れるわけもないので、見えないところにフタをするみたいな感じになり、スパゲティがよく絡んでいくわけです。
納品したドキュメントが読まれない
初めに、要件詰めながら設計開発をしていくと言いました。
なので、基本的にお客さんも「どういう処理をするものを作って欲しいのか」というところが曖昧なままスタートします。このままだとさすがにお互いに認識の差異が発生するので、インターフェースと共に、こちらの処理内容を記載したドキュメントを渡すわけですね。
これが、まぁ、読まれない。
「ここの処理どうなってるんですか?」「あの処理どうなってるんですか?」。そんなの設計書みればわかるから!ちゃんと見てくれよ。んで想定と違う部分があるんだったら、出した時点でちゃんと見て欲しい。
こちらが算出した工数を無理やり押さえ込んでくる
例えば、こっちが3日かかりますね、と言っても、2日で出来ないですか?と。
出来ませんから。
簡単にできると思ってるなら、御社内でやってくださいよ。御社にないスキルがあるから、外注しているんですよね?自分が持っていないスキルなのに、それを買い叩くって、どういう神経してんでしょ?いや、もちろん、3日分の費用は出すから2日でやってよって話だったら、社内でアサイン計画を変えれば、まぁ対応できなくはないんですけど、こういう輩ってお金は出さないのね。
友達同士で、「うーんしょうがないなぁーー」ってノリだったらいいんだけど、はっきり言って、少なくとも僕は、客先と仲良くするつもりなんてない。全くない。
そもそも工数を出す意味がない
受託開発って、ケツは既に決まってるんですよね、基本的に。
だから、一応形式上は工数を出して、人員をアサインするんだけど、そもそもアサインできるだけの予算がないってことがある。嘘みたいな本当の話。例えば、12人月で3人4ヶ月って見積もっても、結局お金が出なくて、2人4ヶ月とかね。こんな案件蹴っちゃえばいいのに、零細企業はお金がないから、こういう案件でも受けざるをえない。つまり、そもそも無理な状態で開発がスタートしちゃうんですよね。
そのうえ、上記で挙げたような追加やら変更やらが入ってくるので、既に残業前提の業務になってしまいます。んで、現場エンジニアに残業代を出すわけでもないというクソっぷり。どんどんどんどん疲弊して、なんの未練もなく、エンジニアは辞めてしまいます。
炎上する
結局行き着く先はここ。
そもそも無理なスケジュール、大量の仕様追加、仕様変更を出しておいて、開発期間は変わらないんだから当然の結果です。まぁさすがにこのご時世、デスマは死語になりつつありますけど、終電帰り、休日出勤は当然のように見受けられます。
ぶっちゃけ、炎上するっていうのは、PMが全て悪いと思ってます。全体のハンドリングをするのが仕事なのに、ハンドリングできてないんだから当然ですね。リカバリ案(というかリリース延ばせ)があれば全てが解決するのに、スケジュールに収めることしか考えてないやつ多すぎ。
どうぜゴミみたいなソーシャルアプリなんだから、最低限ユーザーが快適に遊べる品質を担保できるまで、ゆっくり開発すればいいじゃない。
おわりに
まぁ全般的にあるあるというか、悪口しか書いてませんが、まぁ受託開発って、こんなもんです。受託の方がスキル伸びる、とか血迷ったこという人もいますが、受託は工数少ないので、新しい技術とかは試してる余裕ありませんので。あしからず。
そいぎんた!
コメントを書く
コメントを投稿するには、ログイン(無料会員登録)が必要です。

ネット証券比較

みんかぶおすすめ