アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
双方が納得できる線引き (スコア:1)
結局落としどころがそこになってしまうことが現状の問題点だと思います。発注側は受注側が信用できないから全てをコントロールしようとし、受注側も発注側が信用できないから確実に利益が見込める派遣契約を求める。でなかったら、受注側がとんでもないものを作り出したり、発注側が無茶な要求をして作れそうにないものを求めてくるからでしょう。
ですからここで誰かが言っているように、仕様をはっきりさせるというか、双方が納得できるはっきりした線引きを確定させること、いや双方が納得するための新しい考え方のようなものが求められるのだと私は思います。
Re:双方が納得できる線引き (スコア:1)
細部まで考慮されていない、明らかにすり合わせされていない仕様書(と主張するメモ)を見せられて、リスクを全く取れない金額を強要されちゃ、請負なんてできないですよ。
[実際に、去年そんな案件の請負下請 PM をやっちゃった私。周りから見たら死ななかったのが奇跡に見えたらしい。その上、次の仕事は元記事の SK から強(ry]
fj.jokes出身:
Re:双方が納得できる線引き (スコア:1)
> 主な理由は、上流工程とのつながりを密接にするため、常駐にして発注側の開発体制に組み込むためです。
これは同感。
結論はとっくに出ています。余分なリスクは取らない。
たとえば、経産省のプロジェクトマネジメント研究会 [meti.go.jp]の報告書たたき台 [meti.go.jp]なんかでも言及されています。
サブシステム、できれば設計工程(仕様書作成)と製造工程(コーディング・テスト)まで分割し、
細かい単位で受注すれば、大幅な見積もりミスはなくなり、損益がブレるリスクを減らせます。
ただし、受注側、発注側の双方にデメリットがあります。
・失注リスクが存在する
後半の製造工程は受注金額を稼げるので、失注のダメージが大きくなります。
特に製造工程の受注を前提として、設計工程を値引きした場合はなおさら。
・発注側に高いPM能力が要求される
設計と製造が別企業になると、PMを発注側が担当することになります。
発注側企業にPM能力まで持ったSEは少ないので、プロジェクトの成功率は低くなります。
・見積もりミスを受注側に押し付けられない
会社は予算で動くので、一番最初に予算を請求をします。
しかし、設計が完了した時点で、製造費用の概算が予算を超過していたらどうしようもありません。
というわけで、解決策を知りながら営業的な理由から、今までどおりに仕事をしてます。