アカウント名:
パスワード:
日本での事情に限定します（外国の状況には詳しくないので）が、記事の分析通り、要件定義を軽視しすぎていると感じます。要件は開発者側だけで決定できるものではありませんから、利用者側の都合で変更や追加が発生することはやむを得ないとしても、・十分なヒアリングや検討を行い、変更の可能性を最小限に抑える・それでも変更が発生してしまった場合は、工数を見直し、納期やコストが変動することに合意いただく・「なぜこの要件なのか（要件が変更されたのか）」を最前線の開発担当者にも伝え、利用イメージを共有するといったことが重要になると考えます。
私た
日本の企業がITに無知なことも要因かと思います。転職してIT企業に発注する側になりましたが、安く早く仕上げるのが当たり前と思ってる人が多すぎます。機械や建物といった製造物・建造物には全然うるさくないのに、ことシステム構築となるとクレーマー並の注文ばかりつけます。IT企業って低く見られてるのだと思います。
機械や建物といった製造物・建造物には全然うるさくないのに、ことシステム構築となるとクレーマー並の注文ばかりつけます。
ハード重視、ソフト軽視ですね。人件費軽視と考えてもいいかもしれません。（政治ではハコモノを重視したり、飲食店では原価がこれだけなのに高すぎると感じたりするのと同じかと。）
IT企業って低く見られてるのだと思います。
むしろそれは、私たちIT企業の請負開発のあり方に問題があったわけで、価格を適切な水準に引き上げるか品質悪化を顧客に受け入れさせるかの二択を突きつけるべきでしょう。IT企業側が自分たちの見積もりを明確な根拠をもって提示し、価格競争をしない心構えが必要だと思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
要件変更と工数見直し (スコア:2)
日本での事情に限定します（外国の状況には詳しくないので）が、記事の分析通り、要件定義を軽視しすぎていると感じます。
要件は開発者側だけで決定できるものではありませんから、利用者側の都合で変更や追加が発生することはやむを得ないとしても、
・十分なヒアリングや検討を行い、変更の可能性を最小限に抑える
・それでも変更が発生してしまった場合は、工数を見直し、納期やコストが変動することに合意いただく
・「なぜこの要件なのか（要件が変更されたのか）」を最前線の開発担当者にも伝え、利用イメージを共有する
といったことが重要になると考えます。
私た
Re:要件変更と工数見直し (スコア:1)
日本の企業がITに無知なことも要因かと思います。
転職してIT企業に発注する側になりましたが、安く早く仕上げるのが当たり前と思ってる人が多すぎます。
機械や建物といった製造物・建造物には全然うるさくないのに、ことシステム構築となるとクレーマー並の注文ばかりつけます。
IT企業って低く見られてるのだと思います。
Re:要件変更と工数見直し (スコア:2)
機械や建物といった製造物・建造物には全然うるさくないのに、ことシステム構築となるとクレーマー並の注文ばかりつけます。
ハード重視、ソフト軽視ですね。人件費軽視と考えてもいいかもしれません。
（政治ではハコモノを重視したり、飲食店では原価がこれだけなのに高すぎると感じたりするのと同じかと。）
IT企業って低く見られてるのだと思います。
むしろそれは、私たちIT企業の請負開発のあり方に問題があったわけで、価格を適切な水準に引き上げるか品質悪化を顧客に受け入れさせるかの二択を突きつけるべきでしょう。
IT企業側が自分たちの見積もりを明確な根拠をもって提示し、価格競争をしない心構えが必要だと思います。