プロジェクトの失敗は要件定義に甘さが原因か？

それで気づかれない(誰も気にしない)ってことは、もともとあってないような要件ってことだ

>>107
ない。俺はソフトウェアは本業じゃないし、もちろんB2Bもやってない。
だがモバイルアプリではよくモックを作る話を聞く。
最終的にはモック+画面遷移図含めた仕様書じゃないの？

>>47
だから違うってば、それは要件はそれなりにまとまった上での仕様変更の話。
それが要件定義レベルだと基本設計からやり直しとか、最悪修正不可能って話になってくる。
速く修正しましょとかのんびりした事言ってられないから。要件定義はやっぱり大事だよ。

>>191
客でもなければプログラムも組めないのが、他スレから逃げ込んで来てるだけ

偽装請負は違法性があるかもしれんが
一般派遣や特定派遣はまっとうな雇用形態だろ

>>67
要件定義も重要という事を認めるのなら
プロジェクトの失敗が要件定義の甘さが原因という事を言うは愚かな事ではないし
同様に認めなければお前が矛盾してる事になるんだが？

たぶん要件定義が甘いと会社から怒られたんじゃないかなw

試験させろよｗてか登録されている人材を選ばせろよｗ

>>17
自分の読解力を疑えｗｗｗｗ

スレ主が言ってるのは微々たる修正の事なんだな。
「プロジェクトの失敗」とは大げさなw

あとさ、「内製すれば解決する」って言っている人いるけど、無理だと思うぜ。
要望を出す(整理して表現する)能力と、要望を実現する能力って別物だから。

>>91
　募集期間が半年でも１年でもあるんならともかく、普通はない。
いい人はよそが囲っているので中々市場にでない。

これを特殊なんて思っちゃうから要件定義が甘くてプロジェクト失敗しちゃうんだよ。

無能実態派遣残業して時間報酬相場下げるな！
【知的財産と契約料金の搾取助長者ばかり】
［受注系SI生涯損害促進者を追放すべき］
偽装請負従犯SEの動機
コミ障
趣味
文系大卒
低偏差値大卒
情報処理資格非保有者

偽装請負従犯SEの迷惑
不当指示遵守
強要期限遵守
裁判無関心
学習不足
労働違反
残業見積
無料追加
利益提供
対人障害
健康障害
孤独死

偽装請負従犯SEの代償
デスマ
技術低下
収入低下
貧困
非婚
離婚
鬱病
早死

客はそもそも費用対効果に見合わない注文はしないからね
概算コストや契約を曖昧に始められる方が客も困る

>>60
> こんな時に要件定義のせいにされたくないって事なの？
要件定義のせいにしても、プロジェクトは成功しないってこと。

どうも君、プロジェクト（客の立場）になって考えてないんだよね。
プロジェクトを成功させるかどうかではなく、
プロジェクトが失敗しても契約をちゃんとしていれば
開発会社だけは大丈夫って話をしている。

客に問題がある時に、客に問題があるから悪いんです。以上。
という開発会社本位の意見。

プロジェクト（客）を成功させるためにする
開発会社がやるべきことの話になってない。

>>49
微々たる修正でも、その修正に時間がかかるのであれば
プロジェクトは失敗するよ。

結論、IT業界は糞。

原因だよ
言い訳ばかり考えていないで、仕事しろ

>>57
なんかしっくりこないんだよなあ、お前の言ってる事。
要件定義はきちんとやりました。でもプロジェクトは瀕死の状態です。
なぜなら仕様変更がやたらと多いからです。

こんな時に要件定義のせいにされたくないって事なの？

>>190
自分たちが使うシステムを発注したらわけではない人達は偽物

>>140
元請けの開発者も居るでしょう
そこでいう下請けとは二次請け以降の請負のことね

>>58
契約の話をプロジェクトの話を分けて考えよう。

プロジェクトは客が金を出す、客のものだ。
プロジェクトの失敗とは、時間と予算の超過のことだ。

契約は開発会社が自分を守るための話だ
仕様変更が起きた時に、その原因が客にある条件を明確にし
その時間と予算を客に押し付けるためのものだ。

確かに客に原因がある問題もあるだろう。
だが客に原因があったとしても、想定内の範囲内に
抑えることができればプロジェクトは失敗しない。

その想定の範囲内（つまり時間＝予算）で、どれだけのことができるか？
より多くのことができれば、プロジェクトが成功する可能性は高くなる。
客に問題があってもプロジェクトを成功させる確率が高くなるんだよ。

君が言ってるのは、プロジェクトが失敗した時、契約によって客の問題だって
明らかになってるから、何の責任もありません（それは事実）と言ってるだけ。
プロジェクトを成功させるための話をしているのではなく、
単に責任問題の話をしているだけだ。

第１フェーズ
要求があいまい、受注する側の理解もあいまい
伝達そのものがうまくいかない
第２フェーズ
要望は常に発生するし常に変化する
変化に迅速に対応することが外注方式ではできない
１回の小さな変更でも莫大な金額を要求される
第３フェーズ
外注すると発注側の人材が業務知識の衰退を起こしてさらに要求があいまいになる

etc………..etc………..etc………
だから、某スレでは内製でしか結局達成できない。
という結論でまともな人は基本的に反論はなかったろうに。
ただ、問題として内製を行う情報システム部門の連中の劣化・鈍化問題
をどうにかしないとね。
というところまで来たけど、バカが長いこといつもどおり暴れてスレがアホ化した。

要件定義が甘いとかそういうレベルでなく見る人が見れば間違ってるってすぐわかるレベルで
間違いってわかる属性の人が商流の下過ぎて要件定義にダメ出しする権利がない

>>14
結局、要件定義が原因なんじゃないか。なんだそれ。

へー、要件定義って顧客もやるんだ
勉強になるわ

>>151
すべてのプロジェクトが失敗してるなんて話はないだろ。
俺は自分で要求定義をやり直すか、その権限がないなら徹底的に理詰めで
権限がある奴に公衆の面前で問い詰めるなぁ。客が相手なら全部議事録を取って
口頭指示は受けない。電話だったらメールで必ず残す。
１回デスマを経験しているので、開発者に死ぬ思いの生活をさせて自分はぬるぬる
過ごしますなんて奴は叩きまくる。

やっぱり、それでも開発せざるを得ない状況になるのは、開発に話が来る前に
客に約束してきたり、要求が甘すぎて指摘した場合に従順な奴に話がいくから。

>>134
派遣の声が普通の人間まで届くわけも無し・・・・

>>109
まともな仕事をさせてもらえないんですね、かわいそう

要件定義の糞さに困るのは上流だろ。
下請けが困るのは仕様がない場合。

なので要件定義のゴミっぷりで困るのは開発フェーズの最上流だろ。

>>198
ユーザ企業が開発自体をできるようになる必要はないと思うよ。状況の評価ができさえすれば良い。
後は早く決めることだな。追加精算の金額が大きくなるのは決めるのが遅くなるから。
漏れていた要件でも早く決めてしまえば、結構安く対応してもらえるだろう。

>>1がなんなのかは分からないけど
>>126は下請けと分かってしまう不思議な文章

>>180
私たちのユーザー企業で会社としても技術知識は必要とされてないので、フレームワークとかそういうのは全部ベンダーの提案任せです。その時点で方向性が違うのでしょうか？

自分プロジェクトであれば要件定義が甘くなることはない。
なぜなら自分自身が考えたものを自分自身が作るから。

もしこれが正しいと仮定するならば、
自分プロジェクトは失敗することはないんだよね。

でも実際は失敗することはありうる。作っているうちに
何かしらの問題が発生して予定よりも遅れたりする。

ここから導き出される答えは、要件定義を完璧にすることは
自分プロジェクトであっても不可能ということ。

では上澄みだけで続きをどうぞ

>>87
まっとうな雇用契約の派遣や、請負契約(偽装なし)なら何の問題があるの？
個人的な好みで断ったらサボり扱いにしかならんだろ

炎上ばっかしてんのはお前んとこだけだろ

>>212
そういうマスゴミ脳って、未だに居るね。

いろいろとあるようですが、要件定義（要求定義）はどうちがうのですか
また、どうすればつくれるのですか
甘いとかおっしゃるのでしたら、正しいつくりかたを書いてください

>>89
>>87に聞いたんだ。違法性のない派遣がダメな理由が書いてないため
違法性のない請負についてもどう考えてるかわからないので

要するに派遣はリスクや非効率な部分があるのが問題ってわけだね
そんなの当たり前だと思うぞ

人が足りないから雇わざるを得ない
人月単価を下げるために雇わざるを得ないなどなど
派遣の使うのも自社の仕事の責任範囲でしょう
理由があって雇ってるんだから雇うなといっても無理

要件A+要件A’+要件Bに対して、要件Aだけで立てた計画のまま進めていれば、
・実態の要件：A+A’+B
・計画に組み込んだ要件：A

プロジェクト計画と実態があっていないのだから”要件定義が甘い”から失敗する。
変更や追加があった時点で計画に組み込めばその時点で実態とプロジェクト計画が
あっているのだから”要件定義が甘い”状態ではなくなってるし、失敗もしない。

自分で作れば失敗しないというのは、自分で要件を把握してるし、追加や変更があっても
自分で影響範囲を正しく把握できるのと、自分の意志で期間や費用を調整できるから。
または期間と費用を現状で吸収できるような変更しかしないから。

どこかで切らないと。
ずるずるになるのは営業が悪いのか？w

モック作れば済む話じゃないの？

・当初の要件：要件A
・変更要件：要件A’
・追加要件：要件B
・要件Aに対する開発費・開発期間：開発A
・変更要件に対する開発費・開発期間：開発A’
・要件Bに対する開発費・開発期間：開発B

として、要件A+要件A’+要件Bを開発Aでやろうとするからプロジェクトは失敗する。
ちゃんと要件A+要件A’+要件Bに対して、開発A+開発A’+開発Bで進めれば失敗
なんてしない。
馬鹿なユーザや商品企画が最初から完璧にできなかった要件定義、つまり自分のミスを
隠ぺいしようとするからプロジェクトは失敗するんだよ。

疲れたのでまた後日なｗ

起点がおかしいなら立て直しだろ流石に

例えば俺に要件定義にダメ出しする権利があったとして
その権利を行使するに値する完全なる誤謬を孕んだ要件定義を生みだした
プロジェクトに俺は何を期待出来るというのだろうかラノベ世代

俺の要件定義は完璧だから、プロジェクトで失敗したことなんてない。
作りながら直すなんてのは、まあ甘えだな。作り直しなんて無駄でしかないのに、手を動かしてさえいれば
それが後戻りだとしても仕事してるつもりになってしまうのがコーダーの特徴。

客の注文に応える為に要求をきちんと詰めましょう。