プロジェクトの失敗は要件定義に甘さが原因か？ [転載禁止]©2ch.net

**仕様書無しさん** · 2015/05/16(土) 11:12:43.97

なぜプロジェクトが失敗したか？
要件定義が甘く作り直しが発生したから
というのがこの業界の常識だが、これは本当だろうか？
もしそれが問題であるのなら、とっくに解決できているはず。

なのに未だに解決できていないということは、
要件定義をきちんと行うというのは、
解決不可能な問題では無いのか？

1. 要件定義が完ぺきにできた所で納期は短くならない（納期が正確にわかるだけ）
2. もちろん機能を減らせば納期も減らせるが、必要な機能は減らせない。
3. そもそも要件定義が完璧にできることはない。
4. 要件をまとめるほうが完ぺきにできても、出すほうが完璧に出せないなら、まとめることは出来ない。
5. 要件を全て引き出せというが、相手が完璧に要件を理解しているわけじゃない。
5. プロジェクトの関係者すべてが完ぺきな要件を知らないのに、要件定義が完ぺきにできるわけがない。
6. 毎回違うものを作るのに、前回の結果が参考になるわけがない。
7. 開発期間が長いほど、要件は変化していく。

そりゃ、要件定義を完璧にすることは不可能だから、
要件定義が甘いという言葉は常に当てはまるだろうな。
そう言っていれば、思考停止できるから楽だねｗ

要件定義が甘いという言葉を、スケープゴートにして
本当の問題から逃げているようにしか思えない。

本当の問題とは何かって？要件定義は完ぺきにできるわけがなくて、
そして変わることを前提にした、開発ができないってことだよ。

いい加減要件定義が甘いという、在り来りな言葉をいうのはやめましょう。
開発技術を甘く見ているところほど、要件定義が～としたり顔で言うだけで
問題を解決できてない。そして解決不可能問題に力を注ぐ。

1 · 2015/05/16(土) 11:15:50.82

なお、アジャイルにしろと言っているようにみえるかもしれないが、
そうではない。別のウォーターフォール・モデルでもあてはまる。

ウォーターフォール・モデルでも手戻りで前の段階に戻ることがあるだろ？
前の段階に戻るのがコストがかかるから、そうならないようにしろというのが常識だが
前の段階に戻ってもコストがかからなければ、問題は大きくならないんだよ。

前の段階に戻らないようにするという解決不可能問題に取り組むのではなく、
前の段階に戻ったときのコストを減らすようにしたほうが現実的

**仕様書無しさん** · 2015/05/16(土) 13:22:56.98

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

**仕様書無しさん** · 2015/05/16(土) 14:05:25.43

>>3
ではなぜ解決できないのでしょうか？
いつまでたってもプロジェクトは炎上してばかりですよね。

**仕様書無しさん** · 2015/05/16(土) 15:13:26.01

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

**仕様書無しさん** · 2015/05/16(土) 15:51:19.82

>>5
それぐらい調べたほうがいいよ。
プロジェクトの○％は失敗という報告がある。

**仕様書無しさん** · 2015/05/16(土) 15:51:45.93

だって、顧客自体が本当に欲しい物の姿が見えて無いんだもの。
いつでも完成間際のだいたい動く時になってから、
あれもこれも無いじゃないか！ってなるんだよな。

**仕様書無しさん** · 2015/05/16(土) 16:06:30.71

いつもの木のブランコの画像が思い浮かんだ

**仕様書無しさん** · 2015/05/16(土) 17:07:03.10

なぜプロジェクトが失敗したかだと？

最初に要求仕様、見積金額、客、自社の状況を見た段階でわかってたわ

**仕様書無しさん** · 2015/05/16(土) 18:08:43.84

　アップルウォッチですら、HPと店で実物を見るのと実際着けて生活するのとでは
全然印象が違う。

**仕様書無しさん** · 2015/05/16(土) 21:00:53.63

自社のシステムは、、、
のマネしようとしてるのか？

でも、いきなり否定されているところが>>1の限界点

自社のシステムは、、、の>>1は基本的に否定されていなかったからな

では、なぜ、このスレの>>1は否定されているのか？
それは論点の提起の文から矛盾してるからだ

**仕様書無しさん** · 2015/05/16(土) 21:04:41.52

客側にも問題はあるが
業界の構造がさらに問題
これは木の絵だったり他の機会にも語られたが、多くの者が否定しない
にも関わらず1はこれに具体的なことを示すことなく否定
まさに愚か者の典型
こういう奴がいるから失敗する

**仕様書無しさん** · 2015/05/16(土) 21:30:56.56

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

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

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

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

**仕様書無しさん** · 2015/05/16(土) 21:44:21.07

>>7
> だって、顧客自体が本当に欲しい物の姿が見えて無いんだもの。

そりゃそうだろうね。

ブランコの絵を見せて、これを作りますと言っても、

「え？あなたブランコの絵を描くの？」って言われたらどうする？

「いえいえ、違います。ブランコの絵を元に実際のブランコを作ります」
「ブランコの絵と実際のブランコは何が違うの？」
「ブランコの絵は動きませんが、実際のブランコは動きます」
「それだけ？」
「他にも人が乗れるとか、重さはどれくらいまで耐え切れるとか、沢山の違いがありますよ」
「じゃあそんな絵じゃわからん。実際のブランコを持ってきてくれ。
それをみて検証しないと何もわからん。」

とこうなる。

そのブランコでいいかどうかは、実際にブランコを使ってみないとわからない。
それがない状態では、お互いが「想像」するしかない。

想像を回避するためには、実際に作るところもある。
Apple Watchとか多くの試作品を作っただろうね。

でもコストがかかるからという理由で、それをやらないのは多いだろう。

言い換えると、コストが掛かるという理由で要件定義が甘くなるのは
「失敗」ではなく「選択」した結果なんだよ。
だから要件定義が甘いという前提で開発をしないといけない。

**仕様書無しさん** · 2015/05/16(土) 21:44:46.01

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

**仕様書無しさん** · 2015/05/16(土) 21:59:21.33

もうね、>>1がこのスレで伝えたい要件を
自分で定義できなくて失敗してるね

**仕様書無しさん** · 2015/05/16(土) 22:02:04.00

>>15
ぜんぜん違うじゃん。

**仕様書無しさん** · 2015/05/16(土) 22:02:39.59

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

**仕様書無しさん** · 2015/05/16(土) 22:33:59.08

>>8
あれ描いた奴は天才だ

**仕様書無しさん** · 2015/05/16(土) 22:42:59.20

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

**仕様書無しさん** · 2015/05/16(土) 23:11:50.55

Smalltalkで有名な青木氏が以下の事を言うようにソフトなんて完成する事はないんだから。

(1)利用者の要求仕様は永遠に確定しない
(2)開発者の設計仕様も永遠に確定しない
(3)ソフトウエアは完成することがない

**仕様書無しさん** · 2015/05/16(土) 23:20:54.07

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

**仕様書無しさん** · 2015/05/16(土) 23:29:59.80

わざわざ追加要求探して追加料金貰い続けてっから給料が入るんだよ

**仕様書無しさん** · 2015/05/16(土) 23:42:30.65

>>20
モックは所詮モックだ。同じものではない。

モックの重要な点としてモックを作るのに時間をかけてはいけないということだ。
だが時間をかけないと、そのモックは本物とはかけはなれたものになる。

より効果があるモックを作ろうと思ったら、短期間で本物に近いもの作る必要がある。
だがそれって本物を短期間で作れるようになることと何が違うだろうって話。

本物を短期間で作れないから、本物とはぜんぜん違うものを作って
それで判断するから、誤りを犯すんだよ。
モックを作るよりもまず、本物を短期間で作れるようにするのが先ではないか？

**仕様書無しさん** · 2015/05/16(土) 23:46:18.94

本物を短期間で作れるようになれば、
たとえ要件定義が甘くてもあとからすぐに直すことが可能になる。

根本的な要件定義の間違いは大きなコスト損失につながるが
さすがにそんな間違いはやらない。

要件定義の誤りの殆どは、すぐに作れる程度のもの。
というか、すぐに作れる程度のものに抑えるよう開発することが重要。
そうすれば完璧な要件定義なんて必要なくなる。

**仕様書無しさん** · 2015/05/16(土) 23:50:01.27

>>21
そうなんだよね。有名な人もちゃんとわかってるか。

要件定義が甘いと言われれば反論はできない。
なぜならそれは常に当てはまるから。
理由は>>21の通り。

要件仕様が確定しないのだから、要件定義も確定しない。
結果論で、最初に要件仕様を確定しておけば・・・といっても
最初の段階から変わるものなのだからどうしようもない。

要件定義が甘いという解決不可能問題に対して
要件定義が甘いと言った所で何の意味もないんだよ。
完璧な要件定義は出来ないんだから。

だから甘い要件定義で十分で、もっとそれ以外の部分に力を注ぐべきだ。

**仕様書無しさん** · 2015/05/16(土) 23:50:34.50

>>25
そんな2週間かそこらで完成するものの話をしてるのか？

**仕様書無しさん** · 2015/05/16(土) 23:53:57.41

>>27
あんたの所はプロジェクト全てが一要件でできてんのか？

プロジェクト、大小の多くの要件なら成り立つ。
要件が甘いというのは、その全てが間違いってことじゃなくて
いくつかの要件が違っていたり足りなかったりするだけだ。

大きな要件であればそれを小さな要件に分けるし、
分けられない大きな要件であれば、さすがにそこは間違えないように注意する。

最終的に「要件が甘い」の内訳は小さな要件のズレのみになる。
その程度の修正に2週間もかけねーよｗ

**仕様書無しさん** · 2015/05/16(土) 23:56:42.93

>>28
そんな程度だったら、そもそも失敗じゃないじゃん。

**仕様書無しさん** · 2015/05/16(土) 23:57:02.76

完璧な要件定義をするのにも時間がかかるからな。

そして時間のかかり方は直線的ではない。90%の要件定義を
100%にするには、10%の時間ではなくその10倍ぐらい時間がかかるだろう。

だから完ぺきな要件定義をすることは時間の無駄でしか無い。
甘い要件定義が一番現実的。

だから要件定義が甘いなどと言ってもそれは時間＝コストがかかるだけ。
予定よりも時間＝コストがかかることが、プロジェクトの失敗であるので
完璧な要件定義はプロジェクトの失敗につながる。

**仕様書無しさん** · 2015/05/17(日) 00:01:54.21

>>29
俺だったらその程度の修正に2週間もかけねーよって言ってるだけ。

だがその程度の修正であっても時間がかかることがある。
初心者と上級者の開発速度が100倍とか言われることあるだろ？

「修正に時間が掛かる」ならば「修正に時間がかからない仕組みを作りましょう」・・・これが俺が言っていること。

だけど、間違った考えを持っている人は

「修正に時間が掛かる」ならば「修正が必要ないようにしましょう」・・・と考えてる。
これが「要件定義が甘い」という発言に繋がる。

→ なぜ修正が入るのか？
→ 要件定義が甘いから
→ 完璧な要件定義をしよう
→ 余計に時間とコストがかかる
→ プロジェクト失敗
→ 何故失敗したのか？
→ 修正が発生したから（完璧な要件定義はできないから当然発生する）
→ じゃあまだ要件定義が完璧じゃないからだ
→ 無限ループ

という流れに陥っている。

**仕様書無しさん** · 2015/05/17(日) 00:11:14.71

>>31
どんな仕組みだったら間違った要件でも修正が出来るようになるんだ？

**仕様書無しさん** · 2015/05/17(日) 00:17:33.89

>>30-31
自分のとこの問題ケースを一般論のように話されてもな
アドバイスとしては
・作るものは後で揉めないように客とちゃんと合意取っとけ
・プロジェクトの性格上流動的なものなら、段階的に分析する計画を入れとけ

**仕様書無しさん** · 2015/05/17(日) 00:18:23.40

>>32
？

仕組みがなくても、間違った要件は
あとから修正するだろ。金と時間がかかるだけで。

俺は修正を速くすることが重要って話をしているんだが。

修正の時間とコストをなくすために、修正が起きないような完ぺきな要件定義をする
その為に時間とコストを掛けるのが、矛盾してるって話。

どうせどれだけ時間とコストを掛けても、完璧な要件定義はできないし。

**仕様書無しさん** · 2015/05/17(日) 00:20:44.00

ずいぶんしっかりした要件が出てくるようだから、元請けじゃないんだろう。

**仕様書無しさん** · 2015/05/17(日) 00:21:00.26

>>33
> ・作るものは後で揉めないように客とちゃんと合意取っとけ

合意とっても揉めるし、たとえ揉めなかったとしても、
それは揉める問題を、力（契約書）で黙らせているだけで
問題が解決した事にはならん。

プロジェクト失敗という問題は、予定よりも時間とコストがかかるってことだぞ。
時間とコストがかかるという問題を、あいての問題にすり替えてるだけじゃないか。

**仕様書無しさん** · 2015/05/17(日) 00:23:14.31

>>34
おい待て、一個前のレスで自分が言った事も忘れてるのか？
> 「修正に時間が掛かる」ならば「修正に時間がかからない仕組みを作りましょう」・・・これが俺が言っていること。

何か良い案でも持ってるのかと思ったら、速く修正しましょうって。
それじゃ、そこらの無能PMと全く同じなんだが。

**仕様書無しさん** · 2015/05/17(日) 00:29:19.18

>>36
合意とっときゃおまえが責任被ることないだろ
契約通りに作ればプロジェクト完遂だ
仕事ってのは契約がすべて

> プロジェクト失敗という問題は、予定よりも時間とコストがかかるってことだぞ。

明確な契約を元に、妥当な金額交渉ができてないから
時間割れとコスト割れが出るんだ

**仕様書無しさん** · 2015/05/17(日) 00:29:28.23

>>37
いや？別に覚えてるが。

俺が言ってるのは、要件定義が甘いっていうのはプロジェクト失敗の原因ではなく、
要件定義が甘いのは解決不可能な問題でそれを原因としてしてはいけないと言うこと。

甘い要件定義のために客が望んだものと違うものができてしまうのは
避けられない話で、その避けられない問題を、避けようと努力するんじゃなくて、
違っていたら修正すればいいだけだって考えるようにすればいい。

修正に時間がかかるのであれば、修正に時間がかからない仕組みを
作ればいいって話をしているんだが。
それをどうやるか？って聞いてるの？それはこのスレの目的では無いんだけどな。

このスレの目的は、要件定義が甘いのは解決不可能であり、
完璧な要件定義をしましょうって考えは愚かだってことを伝えるだけ。

**仕様書無しさん** · 2015/05/17(日) 00:33:03.98

>>38
時間とコストオーバーしてもプロジェクト成功だと？
なぜなら、被害を被ったのは客であり、
契約によって、開発会社は儲かっているから？

ふーん。そういう考えなんだ。

やっている仕事が、プロジェクト（○○システム開発）ではなく、
金を出してくれる会社が、金を出してくれることを前提とした
時給換算の作業員のようになってますよｗ

○○システムがどうなろうと知ったことじゃない。
俺が食えればそれでいいんだってことでしょう？

**仕様書無しさん** · 2015/05/17(日) 00:33:59.02

>>39
他の業種で請負契約のプロセスがどんなものか知らんだろ？

**仕様書無しさん** · 2015/05/17(日) 00:37:17.11

>>41
俺は契約の話をしているのではなくて、
プロジェクトを成功させれるための話をしてるの。

時間とコストがオーバーして、客が倒産したとしても
契約書がきちんと出来てれば、開発会社は儲かると思うよ。

○○システムの開発を依頼した会社が、その開発コストのせいで倒産しました。
でも開発会社は儲かったのでプロジェクトは成功です。ということなんでしょう？

**仕様書無しさん** · 2015/05/17(日) 00:39:42.80

>>39
なんか分かってきた、要するにお前が言いたいのは仕様変更に強いコーディングしましょ？って事だろ。
要件定義レベルの修正の話じゃないぞそれ。

**仕様書無しさん** · 2015/05/17(日) 00:41:14.89

時間とコストがオーバーから客が倒産するなんて事は無いw
客はそんなもの発注してないからだw
世の中の仕組みを知らんのか？

**仕様書無しさん** · 2015/05/17(日) 00:42:24.21

>>40
> 時間とコストオーバーしてもプロジェクト成功だと？

アホか　時間とコストオーバーしたらプロジェクト失敗だ
そうならないよう明確な見積もり仕様を元に、
妥当な金額交渉できるようにしとけっての
そのための要求分析だ

客が望んだものと違うものができないように
最低コスト分析できる程度には、しっかり要求分析と価格見積もりをしとけ

**仕様書無しさん** · 2015/05/17(日) 00:43:29.33

>>43
だからそういうことだよ。最初から言ってる。
もちろんコーディングじゃなくて設計も含まれるが。

最初から要件定義レベルでどうこうしようとする考えが間違いだって話。
要件定義は甘いのはあたりまえで、その解決不可能な問題を解決しようと
努力するのは無駄でしか無い。

甘い要件定義で、修正することを受け入れればいいのに、
間違った考えを持っている人が、修正することは悪だ。
修正が入らないように完璧な要件定義をするべきだ。と
解決不可能な問題に時間とコストをさいてプロジェクトを
余計に失敗させるのが愚かだって話だ。

プロジェクトの失敗の原因を要件定義の甘さだと言ってる限り
プロジェクトは更に失敗の道をたどるよ。

**仕様書無しさん** · 2015/05/17(日) 00:44:53.54

>>45
> そのための要求分析だ
まったくするなとはいわんよ？
でも完ぺきな要件定義はできない。

プロジェクトの失敗した時に、もっと要件定義を
完璧にしていれば、成功したんだって考えが間違いだって話。

**仕様書無しさん** · 2015/05/17(日) 00:46:40.31

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

**仕様書無しさん** · 2015/05/17(日) 00:49:25.34

ある程度要件定義を行ったなら、
もう十分要件定義はできてるってこと。

それであっても仕様変更等は起きる。
それは受け入れないといけない。

仕様変更が起きて修正が入ったとしても
プロジェクトを成功させる確率を上げるために重要なのは
修正にかかる時間とコストを減らすことだよ。

これ以上要件定義を頑張っても解決できる問題じゃない。要件定義は十分出来てる。
要件定義をするのにも時間とコストは掛かるのだから、
プロジェクトを失敗させる確率をあげるだけ。

**仕様書無しさん** · 2015/05/17(日) 00:50:02.42

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

**仕様書無しさん** · 2015/05/17(日) 00:50:07.75

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

**仕様書無しさん** · 2015/05/17(日) 00:50:27.59

>>46
> 甘い要件定義で、修正することを受け入れればいいのに、
それはプロジェクト失敗の最も典型的な要因だ

客側の事情が切羽詰ってきたとき、
契約が曖昧なのを利用して投げてくる仕事を
際限なく受け入れるはめになる

**仕様書無しさん** · 2015/05/17(日) 00:53:42.42

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

勘違いしてるね。

要件定義を全くするななんて一言も言ってない。
言ってるのは、完璧な要件定義なんて出来ないって話。

ちゃんとやっていれば、そんな最悪修正不可能なレベルにはならない。
小さなミスだけだ。

だがその小さなミスでも、修正に時間がかかればプロジェクトは失敗する。
それがプロジェクト失敗の大きな原因なのに、

そこで修正が全く起きないように、もっと完ぺきな要求定義をしましょうって
考えが愚かだって言ってる。

**仕様書無しさん** · 2015/05/17(日) 00:55:49.38

>>52
それこそ契約で解決すればいいだけの話では？
際限なく受け入れなければいい。

だが同じ時間とコストであっても、修正の速度によって
できることは変わってくる。それはわかるよね？

契約によって際限なく変更を受け入れることはしない。
だがその同じ条件のもと、プロジェクトが成功するかどうかは
その修正の速度で変わるだろ。

**仕様書無しさん** · 2015/05/17(日) 00:57:33.10

いや、修正が全く起きない完璧な要件定義が可能なんて誰も思って無いから。
何を問題にしてるのかw

**仕様書無しさん** · 2015/05/17(日) 00:58:22.70

>>55
> 何を問題にしてるのかw

要件定義が甘いのが、プロジェクトの失敗だと考えることだよ。

どのプロジェクトだって、必要十分な要件定義はできてる。

**仕様書無しさん** · 2015/05/17(日) 01:03:00.00

>>53
要件定義に限らずなんでも完璧にできないのはあたりまえだ
だから見積もり要件を明確にし、契約しとかなきゃいけない

>>54
契約がなければ力関係が物をいうよ
赤字になろうが断ることはできない

むしろ修正効率なんて上げてもプロジェクト成功率なんてまず変わらないぞ
速いなら速いなりに短期間で見積もられてしまう
ちょっと想定外があっただけで大きくコスト割れしてしまうようになる
遅くても明確で安定性がある方がプロジェクトは失敗しにくい

**仕様書無しさん** · 2015/05/17(日) 01:06:05.96

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

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

**仕様書無しさん** · 2015/05/17(日) 01:11:25.10

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

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

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

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

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

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

**仕様書無しさん** · 2015/05/17(日) 01:15:37.49

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

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

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

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

**仕様書無しさん** · 2015/05/17(日) 01:19:33.72

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

**仕様書無しさん** · 2015/05/17(日) 01:21:43.37

>>59
> プロジェクトの失敗とは、時間と予算の超過のことだ。
あくまで自社のね
客の経営の都合まで自社の責任にするほど愚かではないでしょう？

> 契約は開発会社が自分を守るための話だ
そう　キミは自分の会社を守れてないから怒られるんでしょう？

>だが客に原因があったとしても、想定内の範囲内に
>抑えることができればプロジェクトは失敗しない。
そのために明確な計画と交渉が必要です
要件定義はその材料でもある

> プロジェクトを成功させるための話をしているのではなく、
おまえのいうプロジェクト成功って何なの？
自社が計画どおりの期間コストで完遂できたかどうかじゃなく
発注側の経営問題による赤字とか全部被るの？

**仕様書無しさん** · 2015/05/17(日) 01:27:50.75

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

**仕様書無しさん** · 2015/05/17(日) 01:32:02.26

>>60
> 要件定義のせいにしても、プロジェクトは成功しないってこと。
同様に、プログラミング技術だけのせいにしても、プロジェクトは成功しないぞ。

どうして、そんなに要件定義を原因にしたくないのか謎すぎるんだよお前。

**仕様書無しさん** · 2015/05/17(日) 01:35:22.68

>>64
誰もプログラミング技術だけのせいになんかしてないのですが？

要件定義も重要。でも完ぺきな要件定義は不可能。
ぜったいに要件の変更は発生する。
だから修正の速度を上げる（プログラミング技術以外も含まれる）

って言ってるのに、どうして
要件定義が要らないと勘違いしてるの？
なんでプログラミング技術だけのせいにしてるって勘違いしてるの？

要件定義の甘さが原因だっていうのが愚かだって話をしてるんだが。

**仕様書無しさん** · 2015/05/17(日) 01:39:16.60

疲れたのでまた後日なｗ

**仕様書無しさん** · 2015/05/17(日) 01:42:02.62

>>65
完ぺきな要件定義は不可能、完ぺきなプログラミングも不可能
失敗は要件定義の甘さが原因の事もあるし、その他が原因のこともある
どれもあたりまえじゃございません？

「要件定義の甘さが原因」
これだけ頑なに否定するのはおかしいと思いませんか？

**仕様書無しさん** · 2015/05/17(日) 01:42:51.16

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

**仕様書無しさん** · 2015/05/17(日) 01:50:57.92

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

**仕様書無しさん** · 2015/05/17(日) 02:29:09.44

荒れているがプログラミング言語の優劣？で罵倒しあうより良スレ。

**仕様書無しさん** · 2015/05/17(日) 03:35:46.48

要件定義なんて不完全なものは完璧にすることはできない
客自身も望んでいるものが見えていない
仕様変更、修正はあるものが当然としても
何処まで対応するかを契約して置くことが大事だよ
特にカットオーバ前はね

客にも責任を負わせることが重要

**仕様書無しさん** · 2015/05/17(日) 10:20:08.11

>>70自演ですか？無職winさん

**仕様書無しさん** · 2015/05/17(日) 10:23:52.08

>>16
それｗ>>1-2までで、自分が言いたい論点をまとめ切れていない
まさに無能
要求定義は無理とか語る前に、語ってることを先にまとめる能力実につけろとｗ

**仕様書無しさん** · 2015/05/17(日) 10:31:50.72

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

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

**仕様書無しさん** · 2015/05/17(日) 10:35:44.43

改善方法
　おまえらが特定派遣や一般派遣、偽装請負に手を染めない
以上。
プログラマは
　本来の意味での受・請負託開発
　自社開発自社販売のソフト開発
　自社システム開発
のいずれか以外の仕事は全部拒否する！
ということを徹底すれば、自然と多重丸投げ等々は消えて、客もプログラマもwinwinになる。

**仕様書無しさん** · 2015/05/17(日) 10:40:07.82

自分で作らないから失敗する

**仕様書無しさん** · 2015/05/17(日) 10:42:57.39

>>76まぁ結局はそうなんだよねww

**仕様書無しさん** · 2015/05/17(日) 11:16:52.96

業務系システムはよく知らないけど、今はよほどのシステムでない限り勉強すれば内製で作れ
るらしいね。

各有識者のブログを読むとシステムコンサル（兼PG）＋情シスの要員＋気の利いたツールだけ
で作れるだろうと。

あとは詳しい人フォロー頼む。

ちなみに俺の専門はモバイルアプリだけど、ガラケー時代に比べて関わる要員
が格段に減ったというか一人でやっている。理由はツールと情報収集手段がガラケー時代に比べ
て格段に向上したから。

**仕様書無しさん** · 2015/05/17(日) 12:01:53.99

>>78
基本的には
　基本的な算数（どこの会社にもあるような、累積、合計等の計算）
　業界特有の計算式（固定の式）
　業務フロー
　書式（業界書式・社内書式）
を
　固定の入力（不確定ではない）
　ＤＢへのＩＯ
　ネットワークからの読み出し
だけだからね。
センスあるやつならプログラミングだけなら１週間でいける。
センスないやつでも組んでいけば自然と組めるようになるレベル。

**仕様書無しさん** · 2015/05/17(日) 12:45:09.67

>>75
同意！
派遣や偽装請負のプログラマがいるから丸投げ構造が作れてしまう

**仕様書無しさん** · 2015/05/17(日) 13:00:43.93

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

**仕様書無しさん** · 2015/05/17(日) 13:31:25.75

>>79
DSL系ツール(楽々フレームワーク、GeneXus、Wagby等）はそんな感じでサクッと作れるみたいね。

**仕様書無しさん** · 2015/05/17(日) 15:32:27.96

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

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

**仕様書無しさん** · 2015/05/17(日) 15:52:06.65

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

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

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

**仕様書無しさん** · 2015/05/17(日) 16:32:25.12

>>81
違法性云々の問題ではないんでは？

**仕様書無しさん** · 2015/05/17(日) 17:02:47.59

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

**仕様書無しさん** · 2015/05/17(日) 17:39:52.20

>>86
>プログラマは
>　本来の意味での受・請負託開発
>　自社開発自社販売のソフト開発
>　自社システム開発
>のいずれか以外の仕事は全部拒否する！

請負契約は否定されてないように読めるケド、俺の読解力に難があるのかなぁ?

特定派遣や一般派遣は、その質に差がありすぎること。
そして、その差を契約決定権を持った連中には理解できないこと。
だから人海戦術で何とかなると上層部が思うこと。結果、人が増え連絡系統が複雑になる。
さらに本当に役に立っている人が人数に埋もれてしまい正当に評価されないこと。
あわせて本当に役に立っている人がバカや下手の尻拭いをさせられて無駄な作業をすることになること。
現状の派遣体勢は問題が多すぎる。
これが自社の社員なら自社の責任の範囲だが、
現行法では派遣社員に対して最低限の能力検査試験や契約試験をしたりできない

**仕様書無しさん** · 2015/05/17(日) 18:19:29.47

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

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

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

**仕様書無しさん** · 2015/05/17(日) 20:19:55.49

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

**仕様書無しさん** · 2015/05/17(日) 20:32:19.82

>>89
更なる問題として決定権のある奴が現場にいないことだな
だから使えない奴が入ってくれば作業が減るどころか増える
そこでまた増員
そいつも使えないとまた仕事と人が増える
こうして無駄だらけになりましたとさ・・・。

派遣プログラマは最低限でも
情報処理技術者試験の応用＋スペシャリスト３種類＋ストラテジスト＋監査
くらい受かっていなければ成れないとか条件つけろよ。
いや、この試験で能力を測る気はないけど、最低限の頭はあるという判断くらいにはなる

**仕様書無しさん** · 2015/05/17(日) 22:35:10.00

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

**仕様書無しさん** · 2015/05/17(日) 22:46:42.15

派遣を使わないといけない開発現場＝終わってる現場

**仕様書無しさん** · 2015/05/17(日) 23:03:34.65

結局さ>>1のやりたいことって内製じゃなきゃ無理だろ。
で終わりじゃね？
外に投げれば嫌でも責任問題・取引上の問題・法的問題が出てくる。
それを解決するために各種書類が作られる。
その書類作成工程を否定するならば内製じゃなきゃムリだわ。

**仕様書無しさん** · 2015/05/17(日) 23:06:10.08

途中まで素晴らしく良いスレだったのに、
誰かが途中で勝手に派遣の問題にすり替えてから
このスレもおかしくなったんだよね。

**仕様書無しさん** · 2015/05/17(日) 23:23:30.46

初っ端から否定されてるのに？

**仕様書無しさん** · 2015/05/17(日) 23:30:22.77

１がいいことを言ったスレが良スレということではないと思うが

**仕様書無しさん** · 2015/05/17(日) 23:39:08.22

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

**仕様書無しさん** · 2015/05/17(日) 23:42:16.31

>>94
見直すと>>74-75からだね
某スレがアホ化されたと嘆く本人が
このスレをアホ化させる原因になるという
皮肉な因果

**仕様書無しさん** · 2015/05/18(月) 06:29:25.25

自演だらけ

**仕様書無しさん** · 2015/05/18(月) 07:28:04.50

実際問題、派遣PGの質の悪さは手を入れないとアカン

**仕様書無しさん** · 2015/05/18(月) 08:13:54.75

要求定義が不可能と決めるなら
自分で作る以外の選択肢は無いよね。
それとも、一軒家注文して4000万支払って、日曜大工一日で出来る犬小屋を納品されても絶対文句言わないわけ？w

**仕様書無しさん** · 2015/05/18(月) 12:43:13.94

客が出す予算は事前に決まっている。
要求は無制限に増える。
請負契約で責任は請け負った側にある。

失敗しないほうがおかしい。
もちろん失敗しないノウハウはあるけど、客と対等以上に渡り合える経験が要る。

**仕様書無しさん** · 2015/05/18(月) 12:46:51.77

要は発注段階で合意したものと、納期時点での最新の要望とが違う場合に
発注段階の合意で納品しても検収をNGにできる現行の民法がおかしい。
判例で時間経過による要望の変更の吸収が請負契約の範囲内に含まれて
しまった。建築の判例をソフトウェアに拡大適用している。

**仕様書無しさん** · 2015/05/18(月) 13:08:43.49

要は発注者と受注者で完成品のイメージを共有できてるかどうかの問題。
この点建築は、CGの普及によりここ15年ほどで劇的に変化した。
IT業界が未だに文面のみでやってるとすれば、相当遅れた業界だ。

**仕様書無しさん** · 2015/05/18(月) 13:27:42.68

>>104
貴方の進んだシステム事例プリーズ。

**仕様書無しさん** · 2015/05/18(月) 13:43:29.41

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

**仕様書無しさん** · 2015/05/18(月) 15:39:55.34

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

**仕様書無しさん** · 2015/05/18(月) 16:00:53.45

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

**仕様書無しさん** · 2015/05/18(月) 17:34:30.93

要求定義から1日以内の納品にすれば良い
どんな巨大なシステムでも

**仕様書無しさん** · 2015/05/18(月) 17:37:48.42

>>107
「失敗したことはありません」って門前払いになる条件の筆頭じゃね？
そんな奴まったく信用できん。

**仕様書無しさん** · 2015/05/18(月) 18:48:15.07

>>1
だから１００万回の仕様変更を無料で受け入れろって言ってるだろ

**仕様書無しさん** · 2015/05/18(月) 19:30:44.61

プロジェクトの失敗経験をドヤ顔で語る末端の派遣労働者

**仕様書無しさん** · 2015/05/18(月) 21:45:05.34

>>112
末端派遣が話しに入ってこようとするからおかしくなるんだよなあ
末端派遣はお客様とお話しないでしょ
渡される仕様書を元にただ単純なプログラムを組んでいるだけ
まあそれも組めないんだけど

**仕様書無しさん** · 2015/05/18(月) 21:54:10.86

もうさ、末端のプログラマやテスターの話は他所でしろよ。
プロジェクトの失敗の根本的な原因にはなり得ないんだからさぁ

**仕様書無しさん** · 2015/05/18(月) 23:01:38.52

これの>>1って、要件定義をしなければならない顧客側の人間だろ。
ちゃんとした要件定義をしなければならないのに、手を抜いて下請けから突き上げくらったんだろうな。
言い訳しないで、「どうやったら要件定義をしっかりできるのか？」を考えた方が良いと思うぞ。

**仕様書無しさん** · 2015/05/18(月) 23:03:58.50

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

**仕様書無しさん** · 2015/05/18(月) 23:25:32.98

ユメをカタチにするチカラw図に乗んなハゲw

**仕様書無しさん** · 2015/05/18(月) 23:32:01.57

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

**仕様書無しさん** · 2015/05/18(月) 23:39:19.41

ヒント：元請けが顧客

**仕様書無しさん** · 2015/05/19(火) 00:07:41.85

まぁお客に依るだろうな。

**仕様書無しさん** · 2015/05/19(火) 06:21:16.22

>>116
どっちかというと内製のほうが歴史は長い

**仕様書無しさん** · 2015/05/19(火) 07:09:35.55

>>116
お前が内製しても無理なの？

**仕様書無しさん** · 2015/05/19(火) 08:00:54.39

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

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

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

**仕様書無しさん** · 2015/05/19(火) 23:48:09.16

結局、要件定義の甘さが原因ということで結論か。
そりゃそうだわな。

>>1は開発に怒られちゃった馬鹿な企画か元請か営業なのかは分からなかったが。

**仕様書無しさん** · 2015/05/20(水) 00:19:02.65

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

**仕様書無しさん** · 2015/05/20(水) 06:51:08.51

要求定義の甘さではなく>>1の主張を正しいとした場合、結論が一つ式ないのが問題かなと思う

**仕様書無しさん** · 2015/05/20(水) 07:47:02.11

それは具体的にどんな式でしょうか？

**仕様書無しさん** · 2015/05/20(水) 17:26:42.46

しかない

**仕様書無しさん** · 2015/05/20(水) 18:01:27.14

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

**仕様書無しさん** · 2015/05/20(水) 18:22:59.24

質疑が上に行かないのか？
そうなら構造的欠陥。

**仕様書無しさん** · 2015/05/20(水) 19:14:34.00

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

**仕様書無しさん** · 2015/05/20(水) 19:23:36.49

定義が甘いなら質疑出して確認すれば済む話。
バカバカしいw

**仕様書無しさん** · 2015/05/20(水) 20:05:33.84

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

**仕様書無しさん** · 2015/05/20(水) 20:23:17.66

質問すらできないのか超底辺コーダーはw

**仕様書無しさん** · 2015/05/20(水) 20:59:11.40

僕の声はあなたに届いてますか…
あなたには僕の姿が見えますか…
それでも僕は叫ぶ、僕は今ここに居る
叫びつづける事こそ僕が存在する証
そうだ、僕はオマンコが大好きだ

**仕様書無しさん** · 2015/05/20(水) 21:56:51.42

だから底辺には関係無いから、しゃしゃり出て来んなよ。

**仕様書無しさん** · 2015/05/20(水) 22:13:17.23

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

**仕様書無しさん** · 2015/05/20(水) 23:04:08.34

>>125
この板にいる限り開発側なんだから、
基本下請けだよね

**仕様書無しさん** · 2015/05/20(水) 23:12:53.01

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

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

**仕様書無しさん** · 2015/05/20(水) 23:13:52.49

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

**仕様書無しさん** · 2015/05/20(水) 23:14:02.67

手戻り当たり前だしその分の見積もりもして上がりも出てる
知らずに喚いてるのは下だけ
ガス抜き御苦労

**仕様書無しさん** · 2015/05/20(水) 23:22:34.64

>>141
それはそうかもしれないが、
今より甘くなるのは
まっぴらごめんじゃないの？

**仕様書無しさん** · 2015/05/20(水) 23:31:15.04

>>142
無給で働かされるの下だけだし
無駄の分経済も回るしな

**仕様書無しさん** · 2015/05/20(水) 23:33:59.44

>>141
だからそれがプロジェクト失敗の原因だっての、アホか。

**仕様書無しさん** · 2015/05/20(水) 23:34:26.68

てか、叩かれた>>1が毎日この時間に覗きにきてるだけか。

**仕様書無しさん** · 2015/05/21(木) 00:46:34.06

★　炭水化物(小麦、米)＝砂糖　★

・「いつものパン」があなたを殺す: 脳を一生、老化させない食事　(デイビッドパールマター　2015/1/16)

・ダダモ博士のNEW血液型健康ダイエット　(集英社文庫)
　Ｏ型とＢ型は小麦、とうもろこし、蕎麦を食べると体調が悪くなり太ります

・炭水化物が人類を滅ぼす糖質制限からみた生命の科学　 (夏井睦　光文社新書　2013/10/17)

・統合失調症、うつ病、パニック障害は糖を抜くと３日で治った。

・チョコレートは超危険食品　強い依存性、糖尿病の恐れ…妊婦や子供は摂取要注意
http://wc2014.2ch.net/test/read.cgi/shapeup/1430052776/823

・すべての不調は首が原因だった！

・長引く痛みの原因は、血管が9割　　(奥野祐次　ワニブックスPLUS新書　2015/2/7)　

・あなたの不調、実は「脳脊髄液減少症」かも!?

・その不調は遅延型フードアレルギーです！
http://wc2014.2ch.net/test/read.cgi/shapeup/1425713834/73

**仕様書無しさん** · 2015/05/21(木) 02:26:01.16

>>144
プロジェクト失敗したり責任取った事あるんだ
ふーん
そんな甘いモンじゃないよカネの世界は

**仕様書無しさん** · 2015/05/21(木) 08:09:41.31

カネの世界wwwアホやでこいつw

**仕様書無しさん** · 2015/05/21(木) 12:22:43.10

>>139
要件定義が糞で上流がちゃんと困ってくれればスレタイみたいにはならないんじゃないの
そんな体制になったことないからわかんないけど

>>141
上のほうはそうかもしれないけど下のほうは
手戻りが発生しても納期は変わらない＋人月契約

**仕様書無しさん** · 2015/05/21(木) 15:29:12.26

結論、IT業界は糞。

**仕様書無しさん** · 2015/05/21(木) 19:06:23.10

要求定義というより
人から話を聞いて、書類にするという工程すら経験がないやつ多そう

**仕様書無しさん** · 2015/05/21(木) 19:19:01.90

まあ、モデリングできる人はごく限られているからな。

**仕様書無しさん** · 2015/05/21(木) 19:48:09.19

ぶっちゃけ俺はデスマとか嫌だから、仕様書は無視して作る。
長いことプログラマーやってるけど、それで失敗した事はないし、むしろ救ってるかもしれん。

**仕様書無しさん** · 2015/05/21(木) 21:09:55.62

なんでそれでデスマ回避できるんだよ？
あれか、言うこと聞かないアピールして
立て直し要員に選ばれるのを回避するという技か？

**仕様書無しさん** · 2015/05/21(木) 22:26:05.71

ボヤけた要件定義のせいでとっちらかった仕様に、それとなくユーザーに必要な方向付けをしてやるだけだよ。

**仕様書無しさん** · 2015/05/21(木) 22:59:58.76

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

**仕様書無しさん** · 2015/05/22(金) 00:32:12.60

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

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

**仕様書無しさん** · 2015/05/22(金) 00:36:37.99

>>157
へたくそｗｗ

**仕様書無しさん** · 2015/05/22(金) 06:24:19.96

>>157
口だけならなんとでもできるわ
行動しろ

**仕様書無しさん** · 2015/05/23(土) 02:41:22.53

丸投げ案件がいいよ。

うちは開発型なんで、開発費は発生しない、商品のリピートを待つ。
まぁ、下受けでなくメーカだな

**仕様書無しさん** · 2015/05/23(土) 08:32:50.35

そうそう
カスタマイズ禁止のソフトにすべきだな
いずれにせよ、派遣はいらない

**仕様書無しさん** · 2015/05/23(土) 19:04:02.12

会話の成り立ってないスレでワロタｗｗｗ

**仕様書無しさん** · 2015/05/23(土) 21:11:34.13

高学力の派遣ってめったにいないやん
つまり派遣ってそういうことやね

**仕様書無しさん** · 2015/05/23(土) 22:36:55.02

派遣の話なんて誰もしてなくね？ｗ

**仕様書無しさん** · 2015/05/24(日) 21:20:55.05

要求仕様をまとめないということは、会話を成立させる気がない
と、そのような事を暗に示しているのではないでしょうか？

**仕様書無しさん** · 2015/05/24(日) 23:13:26.29

なるほどｗ
確かに要件定義できない奴は会話が成立しない奴ばかりだな。

**仕様書無しさん** · 2015/05/25(月) 12:50:28.66

明確なプロトコルに基づかん好き勝手な発言のシーケンスなど信用出来ん

**仕様書無しさん** · 2015/05/25(月) 19:19:30.57

一見無秩序に見える発言の数々は、1000に達したとき全体として結論に至るために欠かすことことの出来ない毅然とした論理的要素だということに気づくだろう。
プロジェクトが失敗する原因とはつまりそういうことなのだ。

**仕様書無しさん** · 2015/05/25(月) 21:04:13.01

>>538
少なくとも俺は可愛いと思うよ、お前の事。

**仕様書無しさん** · 2015/05/30(土) 07:07:23.90

ユーザー企業だがベンダーが作った品質が悪くての納品できず10億の損失なった
プロマネを強化しようってなったけどユーザー企業側で努力して直るものなの？

**仕様書無しさん** · 2015/05/30(土) 07:47:14.58

>>170
>>ベンダーが作った品質が悪くて
もうちょい具体的に書くと、どういうことがあったの？
少しは直せることもあるかも知れない

**仕様書無しさん** · 2015/05/30(土) 08:24:03.43

>>170
その規模の損失が、単にプロマネの資質だけで影響されてるような会社なら、問題の根本原因はもっと上層にある。

**仕様書無しさん** · 2015/05/30(土) 09:47:42.82

>>170
ぶっちゃけ
発注するならどれだけ、開発に必要な要件を伝えられるか。
これには結局、開発能力が必要。
その能力があるなら、自分で直接指揮をとって開発ができる。

でも現実には外に出すと多重ぶん投げで、言ったことが伝わらない

**仕様書無しさん** · 2015/05/30(土) 10:12:38.24

つまり、自分に能力がないってことですね。
しょーもな

**仕様書無しさん** · 2015/05/30(土) 16:32:38.49

>>170
だから自分で作れと

**仕様書無しさん** · 2015/05/30(土) 19:33:13.84

>>170
10億あったら専用のエンジニア３，４名くらい40年雇えたのにねｗ
カスタマイズ自由自在で

**仕様書無しさん** · 2015/05/30(土) 23:14:42.70

なにが問題だったのか今後のために
どんな形でベンダを選定したり設計書を
レビューしたり、プロマネすればいいか
を有識者集めて検討会をしているが、
会社は上流にシフトと言っておりコード
は書くなどはあり得ない。ベンダーに
開発をやらせてるからこっち側で頑張っ
も限界があるように思う。
って本当に少ない

**仕様書無しさん** · 2015/05/31(日) 02:54:38.44

プロジェクトの失敗ってあらかた政治の問題だと思っていたが。
要件の甘さは、行間と空気読めるベンダが請け負えば、まぁ問題ないだろ。
使いたくも無いデータモデル(SIDとか・・)、フレームワーク、下流ベンダ(主にオフショア)。
政治的にこんなもん押し付けられたら、そりゃ失敗するわｗ

**仕様書無しさん** · 2015/05/31(日) 07:30:19.87

>>178
まあ大抵は「政治もどき」が原因だろうなあ。
要件定義が杜撰なのはすぐに発覚するし、
最初から10年以上通用する完璧な要件を一発で
決めるってのも、現実的じゃない。
問題は、要件定義がまずいと判っても、それを
修正させない圧力が強すぎること。

**仕様書無しさん** · 2015/05/31(日) 07:31:05.85

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

**仕様書無しさん** · 2015/05/31(日) 08:25:12.66

>>178
そういうコストアップ要因絡みの案件を安請け合いする責任者（承認する上司も含め）の問題。
よく、複雑さやメリットを上司に説明出来ない技術者のせいにしているけど、これは問題の半分でしかない。
経営者が、自分のところのリソースで出来るだけ利益を出そうと考えてないから、平気で従業員に対して、「これくらい簡単だろう」って言っちゃう。
要は客を説得するのを放棄して、内部コストを下げる方向しか向いてないからね。
これじゃあ負けるのは当たり前。

**仕様書無しさん** · 2015/05/31(日) 08:36:23.60

１％の不良品でも、それをつかまされた客から見れば、それがすべて。

のようなことを誰かが言ったそうな。
ま、ＩＴシステムだと９８％くらいが不良品なんだがｗｗｗｗｗｗｗ

**仕様書無しさん** · 2015/05/31(日) 08:41:46.23

>>177
結局は、下流だと金にならないから、ぶん投げ企業にのし上がりたいってこと？
自分の会社向けのシステム作りをしているのではなく。

なら、さんざん、ＤタとかＦとかＮとかＩとか悪口言ってたのに、その難しさを知って泣いたってことか？
元請⇒会社発揚子会社
都度、リーダーだけ自社から出向、あとは派遣を安値で引っ張って開発。
これが一番良いよ。なんだかんだリスクもスケジュールもスピードも。
失敗したらリーダーはそのまま戻れず子会社社員に・・・。
成功したら席がワンランクアップして戻ってこれる。
っつー制度で。

**仕様書無しさん** · 2015/05/31(日) 08:46:17.12

ＩＴの上流工程やりたいなら、ベンダーが（涙涙涙涙涙涙涙涙涙涙涙涙涙
とかいってんなよ。
全責任は仕事をお客様から請けた会社の責任なんだから

**仕様書無しさん** · 2015/05/31(日) 09:48:00.10

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

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

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

**仕様書無しさん** · 2015/05/31(日) 12:19:25.40

>>183
ユーザー企業でも社内で協力会社つかって直接やった方がいいのかね？

**仕様書無しさん** · 2015/05/31(日) 12:50:54.46

>>186本当のユーザーなら一番の理想はユーザーが作る
これ以上に最高のパフォーマンスをたたきだせるものは無い

**仕様書無しさん** · 2015/05/31(日) 13:04:34.29

偽物のユーザーとかいるのかよ

**仕様書無しさん** · 2015/05/31(日) 13:15:45.77

なんだかこのスレにかこつけて
自分達客の不手際を開発のせいにしようとしている人がいるねw

頭の悪いお前ら客のしょーもない要望を
聞いてあげているだけ感謝くらいしろよ

**仕様書無しさん** · 2015/05/31(日) 13:58:36.97

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

**仕様書無しさん** · 2015/05/31(日) 15:12:58.81

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

**仕様書無しさん** · 2015/05/31(日) 18:50:15.28

ありがとう
今やっていることは間違ってることがわかったよ。他のユーザー企業もベンダーに開発任せてるとおもったけど違うことがわかってよかった。
丸投げだとダメなだね

**仕様書無しさん** · 2015/06/01(月) 01:01:27.62

丸投げはダメだねぇ。
「そのシステムを作りたいと思っているのは誰か？」ってことを考えると、結局自分たちになるじゃない。
自分たちが何をしたいのかわからなかったら、開発側だって作れないよ。
必要以上に開発側に便宜を図る必要は無いけど、自分たちがやりたいことはきっちりまとめないとね。

**仕様書無しさん** · 2015/06/01(月) 01:24:08.38

>180
あぁ、言葉足らずでごめん。
俺の体験を書いたんだけどフレームワークとオフショア強制は
ベンダ側のアホなお偉いさんが原因です。
データモデルは世界標準だ！みたいな感じでお客さんから押し付けられたけどね。
結局PM以下の権限が及ばない範囲で失敗する要素を
押し付けられてるってことね。
要件定義が甘いからじゃなかったかな、って事が言いたかった。
あなたはお客さん側の人か。お互い苦労するねぇ。。

**仕様書無しさん** · 2015/06/01(月) 06:27:51.40

>>193
そのと～り
で、そのやりたいことをまとめて渡すわけだが、今度は受け取る側が無知だから理解できない
理解できないまま更に投げられる
更に受けた先でも理解しないまま投げる
ムリだっちゃ

**仕様書無しさん** · 2015/06/01(月) 08:32:55.82

ユーザー企業の人です。みなさんアドレスありがとう。
要件定義はしっかりやったつもりでも、細かなところでどうしても要件が漏れてしまう。
それで毎回ベンダーからは追加精算、納期遅延と指摘されて失敗するパターンです。
小さな案件は自分たちで抱えてる協力会社の人でやってるんだけど、大型になるとリスク回避の意味もあって大手に任せているんだけど、ユーザー企業でも技術を習得して自分たちで開発できるようにならないとダメなんだね

**仕様書無しさん** · 2015/06/01(月) 09:21:45.07

！
【料理】韓国で『猫鍋』・ナビタン（나비탕）が話題…釜山では600匹の猫を茹でた男も(c)2ch.net
http://yomogi.2ch.net/test/read.cgi/news4plus/1432548053/

猫は生きたまま沸騰した釜に放り込まれ調理される。

猫を生きたまま入れる理由は、猫の悲痛な鳴き声を聞いたら、年の厄を防いでくれると信じられていた。

また大事なお客さんに振る舞うことがあり、その際は生後3ヶ月の猫を用いるようだ。

**仕様書無しさん** · 2015/06/01(月) 12:28:43.35

>>196
どうやっても一発ではムリなの
それを一発でやろうとすると
チェックにチェックにチェックにさらにチェック
と。
その期間だけで実装が余裕で出来てしまう期間になる

だから書類は最初の簡単なのだけ、あとは10000回の無料リプレイスと即時実装をやるか。
自分で作るか。
のどっちかじゃないと結局客は満足しない

**仕様書無しさん** · 2015/06/01(月) 17:23:36.40

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

**仕様書無しさん** · 2015/06/01(月) 20:22:21.61

要件は漏れるものじゃない。ずれるものだ。
そこが分かっていなければ誰がやっても何度やっても失敗を繰り返す。