残業１５０時間予算２倍の謎

ほえほえ＠スプシマン @hoehoe1234

お金と契約と体制の問題でC/Oが長引くと受託系ならアホみたいにお金がでていくし、テスト要員、運用要員、そのた諸々あって製造完了まで無理にもっていくほうが出費が少ないです。そして現場は死ぬのですがｗ。エンドユーザが自社開発しない限りいまのままかな？と。 twitter.com/yutachinthe1st…

ゆたちん＠運がないと実力はつきません @yutachinthe1st

私もIT業界の「納期」は昔から疑問だった。 残業100超えようが超えまいが、できないものはできない。 ソフトウェアのインテグレーションを行った結果「動かない」は起き得る。 無理矢理納期に間に合わせても人員脱落or穴ぼこだらけのシステムが出来上がる。 t.co/XOKpw5Gq0L

2021-05-28 12:32:25

ほえほえ＠スプシマン @hoehoe1234

だからこそ、現場は残業をしないで、自己投資の時間をつくるのが重要なのです。間に合わないのは現場のせいではなくて、多くは経営（構造）の問題なのですから。なぜ残業をするかを考えればその答えがでます。

ほえほえ＠スプシマン @hoehoe1234

１５０時間を超える残業をして作れるものがもとの狙ったものかと言えばそうではないのです。１５０時間が限界で費用的にも人的にもこれ以上むりなので「要件」をけずるからそこで収束するのです。もしも馬鹿正直に当初の要件をやっていたら３倍とかもっと行きますがリソースがないのでそこで打ち切りと

ほえほえ＠スプシマン @hoehoe1234

なり、予算の倍ぐらいで収まるのです。これだと請け負ったほうはだいたい赤字なんですが、これ以上の赤字は出せないので客と交渉するのです。最初から要件が双方わかってないのも大きいですね。わかっている気はするのですが進むにつれて詳細が明らかになるということですね。発見みたいな感じです。

ほえほえ＠スプシマン @hoehoe1234

昨今はだいぶテストの自動化がされてきているとおもいますが（詳細は知らない）、DB項目追加とかフロー変更でドキュメント～再テストまでの工数はしんどいですね。結局、システムは３倍かかるというのがかつての実態で、それは人的、資金的、体制的にもたないからだいたい残業１５０、予算２倍に

ほえほえ＠スプシマン @hoehoe1234

収まるように要件、機能を削るんですね。だからどこでもちょっとひどい案件になると残業が１００～１５０ぐらいになります。単に人的、資金的な限界であり別にそれでこなせているわけでもなんでもないんですね。

ほえほえ＠スプシマン @hoehoe1234

これは構造の問題なので今後も改善しないでしょう。唯一の解決策はたぶん、エンドユーザが開発チームを自社にかかえて継続的な開発をしていくこと。みたいな感じになるかと。ITサービス系なんかですね。あとはずっと同じ会社と取引するとか。要件の出戻りがなくなりますし、要素技術にもくわしくなり

ほえほえ＠スプシマン @hoehoe1234

ますからね。逆にいうと要素技術はしならい、要員はよせあつめ、業務はしならい、要件は双方不明。とかいう感じのプロジェクトがうまくいくわけありません。だからこれは経営の問題なんですね。２次開発以降と１次開発は状況がまったくことなります。