「たび重なる仕様変更で残業。友人は死んだ」元SEが語る、働き方改革への疑念

コメント

注目のコメント

• 片上 貴紀

  外資系IT Manager

  ・2017年09月23日

  仕様変更を安易に受けずに重要度と緊急度から適切に判断して時には断ることが求められる。
  例えば重要度は高くともリリース直後に必要な機能ではないなら、リリース後に改修するとか。
  本当に必要なら追加費用もらって増員したり、リリースを遅らせたりして、QCDとスコープを適切にコントロールできるか。
  プロジェクトマネージャの力量が最も求められる部分であり、そういうことができないPMの下で働くのはマジで悲惨。
• Miyama Shuusaku

  一般社団法人Pnika / 株式会社Publink 理事 / 新規事業担当

  ・2017年09月23日

  「そのプロジェクトは見積もりが甘く、仕様変更が相次いで発生していました」
  
  これは日本のIT業界の最悪な因習ですね。
  プロジェクト失敗のトップ原因でもある設計の見通しの甘さ。
  これは
  ・顧客側の要求定義の甘さ
  ・PMの設計の甘さと交渉力の低さ
  ・営業の見積の甘さと交渉力の低さ
  がケース毎に織り混ざって招いています。
  
  そして、仕様変更が伴うとほぼ100%無償でやろうとする慣習。営業だったとき何回お客さんと喧嘩したことか。
• Takemoto Tadao

  中小企業診断士

  ・2017年09月23日

  IT業界では、残念ながら普通にあるあるですね。
  ただ、これは働き方の問題でなく、契約の問題でしょう。
  現場では、契約の時点で炎上プロジェクトになるかどうか、だいたい分かります。