こういう仕事の受け方ありますか？

質問

某ベンダーからインフラの設計の仕事を請負いました。
私は、さらに派遣で請負った会社から仕事を受けました。
基本設計～構築・検証まで一人で任されたました。
ベンダーの方と面接の時に上流行程の仕事はした事がないとハッキリ
いいましたので、勉強しながらのスタンスで臨むと言う事で合意がとれていた
と思っておりました。
WBSも作成しましたが、とても契約した工数ではできない事を、派遣先の
責任にいいましたが、聞く耳をもってくれませんでした。
しかも、構築につかうOSやミドルはすべて評価版をダウンロードしてください。
との事でとてもお粗末なプロジェクトです。
しかし、乗りかかった船で、責任を全うしようと努力しましたが、案の定
計画は破綻しました。
私はハッキリ、この工数ではできないと申し入れしたのにも関わらず、
派遣先は聞く耳をもってくれませんでした。
こういう理不尽な事も承知で耐えて来ましたが、私の仕事の進めて方が
悪いのでしょうか？
ちなみに、基本設計をするにあたり、元なるINPUTは、ベンダーさんのエンジニア
の頭の中にあるものの、ドキュメントはありませんでした。
できるだけ、INPUTを引き出しましたが、やはり情報量が足りません。
※結局、PMをいれて頂き、ほかに二人増員をしましたが、期限は
守れていません。

質問

(1)基本設計をするにあたり、その根拠となるINPUTは、要件定義書となる
と思っていましたが、間違いでしょうか？
一般的に基本設計は何を元に執筆すべきでしょうか？

(2)検証環境を構築するにあたり、評価版を使用する事は妥当でしょうか？

(3)工数の見積もりは、どのようにすれば良いのでしょうか？
※１００ページ近いドキュメントを数時間でしあげる事になって
しまいましたが、こういう事は常識的にありでしょうか

長文になりもう少しわけありません。

ご教示お願い致します。

回答No.4

lv4u · ベストアンサー

>>(1)基本設計をするにあたり、その根拠となるINPUTは、要件定義書となる
と思っていましたが、間違いでしょうか？

いえ、要件定義書がベースになりますね。

>>(2)検証環境を構築するにあたり、評価版を使用する事は妥当でしょうか？

通常、ありえないでしょう。

>>(3)工数の見積もりは、どのようにすれば良いのでしょうか？

これは、いわゆるＫＫＤ法（経験、勘、度胸）となることが多いでしょう。

まあ、デタラメ・プロジェクトにアサインされたってことですね。下手に頑張る必要はないでしょう。
プロジェクト失敗しても、請け負った会社の責任です。そのとき出張って、頭を下げてもらうために、ピンハネするのが許されているのですからね。

回答No.3

ryo_ Deathscythe（@Deathscythe）

No.1です。

フリーランスのような立場と勘違いしてました。

要するに派遣作業員としてろくな説明もなくほおりこまれて無理難題吹っかけられ、
無理を訴えてもまともなバックアップがなかった　って話ですね?

であれば
2はメリットデメリットを伝えてあとは派遣側が判断すればいいと思います。
3については自ら考える必要ありません、言われたら自分の実力で無理のない工数を言えばいいです。

1は現場次第だからなんともいえないですが、
余裕があるなら聞いた情報である程度構想作って煮詰めていくのが通常でしょうね。
お客がそこまで専門的に詳しかったら設計を依頼する必要がありませんのでw

なんか、理不尽すぎてお気の毒です・・・

回答No.2

yokohamahope

１．契約を正しく理解していますか？
　　まずご質問から契約形態がよく見えません。
　　「某ベンダーからインフラの設計の仕事を請負いました」今回問題になっているのはこの請負業務のことですよね？
　　「私は、さらに派遣で請負った会社から仕事を受けました」これは上記とは別の業務を並行して派遣で契約したということですよね？
　　上記の２つの関わりがよく理解できません。

２．契約形態が良く分からないままで回答です

１）基本設計をするにあたり、その根拠となるINPUTは？
　　INPUTは要件定義書でも基本計画書でも概念設計書でも何でも良いです。受託者が見積りできる、OUTPUTの根拠となる情報が盛り込まれていれば良いわけです。

２）検証環境を構築するにあたり、評価版を使用する事は妥当でしょうか？
　　発注者がその範囲で検証を許可したなら、それで良いでしょう。それをベースに発注元が納品検証＆検収してくれれば良い。
　　もちろん本運用環境が評価版と異なる場合には、それによって生じた障害等は瑕疵に当たりません。

２）工数の見積もりは、どのようにすれば良いのでしょうか？
　　エンジニアの頭の中にしかない情報から設計業務を見積もるなんて出来る訳がありません。今回どのように見積したのか判りませんが、このような場合には「委任」で契約しないと設計書のOUTPUTなんて保証できません。（頭の中の情報が非現実的なものであったら、それでも設計は完了できるのですか？貴方はそんなリスクを受け入れたのですか？）

　ソフトウェア開発における契約の基本から勉強しないと、契約額全額を契約不履行で取り上げられるなんて危険が見え隠れしますね。

補足

契約形態は以下の通りです。
ベンダー
　↓
請負の会社
　↓
派遣会社

工数は期日ありきで発注されていたので、
私は一派遣エンジニアとして、WBSを作成しただけです。

派遣の実態は不透明なまま契約をされて、現場に投入される
だけです。
どのプロジェクトにいっても現状は変わりませんね。

リスクはあったので、アラームは派遣元、派遣先に
あげてましたけ。

まぁ、双方がお粗末という事ですけね。
恐らくお粗末なシステムが出来上がるとおもいます。
無責任なのはお互い様ですかね。

責任を負うとしたら、受託契約をした派遣先の会社
だと思います。

回答No.1

ryo_ Deathscythe（@Deathscythe）

(3)を見るあたり安請合いしたようにしか見えないんですけど・・・?

きっちり内容を確認し完遂可能な工数を算出した見積書と発注書を交わして請け負えば、
「契約時に話のない別作業」として断ることは出来るはずです。
聞く耳持たないとか関係ない。「見積もりにない作業ですのでこのままではお受けできません」と拒否。

妥当とか妥当じゃないとかあなたの能力で判断するんですよ。
情報が完全でなきゃ情報から判断できるものをつくって煮詰めてもらったっていいんだし、
しかも合意取れたと「思っていた」とか確認すらしてないんだ?
不透明なまま安易に受けるあなたの責任感に疑問を感じます。

お粗末なプロジェクトかもしれないけどそれ以上にお粗末なエンジニアですかな？

補足

請負内容は派遣先の会社が受けた話なので、私には
わかりません。

派遣は派遣先の指示に従うだけなので、Yes、Noは
私から言う立場にありません。

恐らく、PMも派遣先の営業もお得意のお客様なので
安請け合いをしたのだと思います。

もし、契約が不透明だと私がいった所で、誰かが同じ
目に遭う事だったでしょうね。

作業量の全量を把握しないで、契約をする事じたい
私も甚だ疑問です。

>きっちり内容を確認し完遂可能な工数を算出した見積書と発注書>を交わして請け負えば、
>「契約時に話のない別作業」として断ることは出来るはずです。
>聞く耳持たないとか関係ない。「見積もりにない作業ですのでこ>のままではお受けできません」と拒否。