どうしてソフトウェア開発は必ず失敗するのか？

これまで一度も成功例に遭遇したことが無いんですが、
何故でしょうか？

どんな開発？

おまえ！疫病神だろう。

勝手に設計しちゃったんじゃない

１.発注元が何を作りたいかはっきりしていない。
2.発注元の担当者がやる気ゼロ。
3.発注元の担当者に決裁権限がない、足りない。
4.発注元の担当者が複数いる。
5.取りあえず作り始めてしまう。
6.開発側の担当者にスキルなさすぎ。
7.開発側の発注元の要件に対する理解不足
8.下請けがダメダメだった
9.担当者が辞めた、異動した
10.実際の運用を考えない、新しいもの好きな開発側

実際に見たまま、思いつくまま書いてみた

>5
かなり的をえてるね。

なにが成功でなにが失敗なの。１は理想が高いの？
オレ的には、黒字なら成功なのだが。

>>5
常に自分以外の誰かが悪いのね。
なんだかなー。

しかし、発注元が悪いときたか…
そら失敗するわ。

＞黒字なら成功なのだが。

おれ、それが嫌でユーザー企業に移った。
予算が苦しくなったからってある日突然ＰＧごっそり抜くんだもん。
稼動後にバグ出まくりで、大赤字になったらしいけどね。

>>8
発注元が悪いケースは、多々あるでしょ

俺は成功率７割ってとこだね。

ちなみに「成功」の基準は、
１．当初スケジュール通りで完了
２．利益率３０％以上
３．完了後のバグ報告ゼロ

>>11
完了後のバグ報告ゼロ
これだけでもかなり高い成功率と思われ。

>>11
開発側の立場からみて1は満足。2は部門原価レベルで満足。
3は数件ありますが数日で対処可能なレベルのものです。
しかし、納品先（社内別部門）の事業収支は完全に赤字です。
これは成功でしょうか失敗でしょうか？
最近こんなのばっかりです。俺らまで赤字物件の開発者
として白い眼で見られます。
付き合う部門を替えたほうがいいのかな？

いつもプロジェクトを失敗させる人ってのは、
いるよね。
その人が通ってきたところは振り返れば
失敗プロジェクトばかりの死屍累々な惨状。
そういう人は本人にその自覚もなかったりする
から質が悪い。

２．利益率３０％以上

>>14
それって稼ぎ頭のこと？
プロジェクトを指揮している間はその部下は喰いっぱぐれがないんだろう。（ｗ

何を基準にして成功か失敗かを判断するか？
それによって、随分変わりますよね。
個人的に成功と思っていても、属する組織及びリーダが失敗と判断すれば
失敗となりますし・・・・
ただ個人的には、クライアントの利益に貢献できれば成功と思えますが？
どうでしょうか？甘いですか？

>>17
俺はそうしたくてソフトハウスを辞めた
今は自社開発ありの企業の電算室みたいなとこでＳＥやってる
何しろ開発した物は自社で使うわけだし、保守契約だの何だの
関係無くあれこれ要望が出てくる。
不満も祝福もストレートだから、こっちの方が性にあってる。

>>18
いいですね！！
あなたのように自分の方向性を決めて転職する方が、
これから増えていけば、よどんでいる今の日本の
労働環境が変わっていくのでしょうね。
今はＩＴ関連など一部の業種のみ、人材移動が激しいですが、
ゼネコン・公務員（？）などの不況業種でも、あなたのような
考えを持って行動してほしいですよね。
（ごめんなさい。スレの趣旨と違った書込になってしまいました）

失敗が確定したプロジェクトにしか
参加させてもらえないってだけ。

確かに失敗がおおいな

まず、一般的なのは古いシステムの仕様をどうしても
捨てきれず、新しく開発するものにもそれを引き継い
でしまう。

それが延々繰り返されるからいつまでたっても新しい
ものは失敗するのさ。

それと、「どうしてソフトウェア開発は必ず失敗するのか？ 」
っていう質問は「どうしてこの世から馬鹿は消えないのか？」
の答えと同じで、追求するだけ無駄だと思うよ。

ソフトを育てるという感覚が発注元、発注元にないと失敗する。

>>1
責任者不在だと失敗する。
失敗したくなければ、責任者を作ることです。

日本人に本当のソフトウェア開発は無理。聖書に匹敵する作品がある？
貝原益軒の養生訓や、もっとさかのぼって万葉集とか古今和歌集なんて
話にならんな。あんなの人間のあるべき姿を徹底的に頭を使って作られ
たモノじゃないからダメだね。言葉で表現することに対する執着心がす
さまじいよん。欧米諸国は。

>>18
そうですね。やっぱり、自分で使わないものは、
どうしても、いいやいいやになってしまいがち。
労力少なく、利益は大きくになってしまいますね。

メンテをやっていたとき、エンドユーザ（利用者）からの
改善要求に、「はっとする」ことが多々ありました。

エンドユーザーの責任者からお礼の言葉を得られれば、成功！

デスマーチは常態である

ＣＭＭに関する資料を読んでいたら、
「品質保証が出来るほどにプロセスが定義されていれば、品質管理は可能。」
とあったのでですが、ということは、
「品質保証が出来るほどにプロセスが定義されていなければ、品質管理は不可能。」
ということになるのかな？

>>29
そのとおりですよ。
唯、現実的に考えると必ずしも文書化する必要はありません。(ここがポイント)

プロセスを定義しているものが、人ということもあります。
いわゆる、その道のプロ、職人さんが、エンドユーザには
いますかれね。
その人から、いかに、ノウハウをひきだすかが、SEの手腕
なのでしょうね。

>>31
ちょっとずれてる。
>>29
ＣＭＭ興味有ります。
俺は、品質保証できるだけの測定が必要と読み取ったんだけどどうかなぁ？
ＩＳＯ−９０００はプロセスを文章化
ＣＭＭは品質保証のマイルストーン。（プロセスはお任せ）
こんな風に感じた。実際のところどうなんだろ？
ご意見欲しいッス。

３１と２９は同一人物です。

まだ、CMMについては、勉強中の身ゆえ、
さきばしったことを書いてしまったと思います。

でも、３１は、私が現場で経験したことです。

本来、リエンジニアリングは、そういう、ノウハウを持った人
の暗黙知を、形式知にすることだと思っています。

暗黙知→形式知に変換する人が、SEで、
それを、コンピュータ上に実装する人が、プロのプログラマ
（プロのグラマ〜じゃありません。。。）
と思っています。

単なる、御用聞きとコーダでの集団では、この業界は
お先真っ暗と思っています。

agfe

俺客側の担当で、いまソフト屋にシステム頼んでるんだけど

>>5のいうところの
１.発注元が何を作りたいかはっきりしていない。
2.発注元の担当者がやる気ゼロ。
3.発注元の担当者に決裁権限がない、足りない。
4.発注元の担当者が複数いる。
7.開発側の発注元の要件に対する理解不足
9.担当者が辞めた、異動した
６/１０当てはまるな
失敗確定か（ｗ

プロジェクトが区切りついたら、総括する時間が欲しい…
特に失敗プロジェクトだったとき。何が原因で崩れはじめたのか、
どんな対応をとるべきだったのか？とか検討して次に生かせればなぁ。
古傷をえぐるような嫌な作業だろうけど、学習できれば失敗プロジェクトも
糧になるのに。

押せ押せで次のプロジェクトにほりこまれるから、結局毎回似たような
デスマーチになってしまうんだな。

>>36
うむ、それはいつも思うな。
いちおーレポートを書いて提出してるが、上司はそれを読んで感心する
だけで何も変えようとはしてくれん。

>>36
プロジェクトに区切りがついたとき＝全員燃え尽きたときです。
多少面倒であっても、定期的に総括(?)した方が、
残されるデータの質・量ともに上がるんじゃないでしょうか

「なんだか解らないけど、とにかくなんとかしてくれ」
ではアカンと・・・・・・・

＊ただ、仕様書って案外つくるのむずかしいんよ

プロジェクトは失敗するべくして生まれてくる

　・派閥など政治的問題
　・上の人間の楽観的過ぎる計画
　・下の人間の楽観的過ぎる計画、「明日のAM9:00まで12時間もある」
　・冒険的な計画に対する希望的観測
　・世の中の変化に対する納期へのしわよせ
　・規制緩和、制度変更に対する納期へのしわよせ、401Kなど
　・偶発的事故、○○さんがやめちゃった

以上、「デスマーチ」からほぼパクリ

>>36
>プロジェクトが区切りついたら、総括する時間が欲しい…
プロジェクトの初期の段階で既に総括が終わっている、
というのが成功パターン加茂。少なくともオレの場合は
そうだった。

あの〜新しいシステム（ソフト）をたちあげることは非常に大変なことです。
それをハードやそのほかのことのように簡単にできると誤解している人が多すぎます。

あくまでノウハウを積み上げ、
新しいシステムは応用再利用により創られるべきというのが持論です。

あげー

>>42
ただね、そんな余裕がないのも事実よ。
もう駄目かな＞日本

なぜ失敗するか。。。

新しい技術の採用＝大きなリスクを伴う。極力避けるべき。
貧弱な要件定義＝後の工程に大きな負荷をかける。はじめの工程ほど時間をかけ慎重に。
下請けの低い技術力・意識＝明確な基準による選別が必要。
規模＝小さいに越したことはない。難しいなら、いくつかの段階に分ける。

失敗したプロジェクトには、以上のいずれかの失敗要因がたいていの場合
含まれています。システム構築の困難さを正面から認識し、それをマネー
ジする能力が必要とされます。システムはただ頑張ればできるといものでは
ありません。

>>45
下３つについては同意だけど、技術者としては
>新しい技術の採用＝大きなリスクを伴う。極力避けるべき。
→大きなリスクを伴う。ハイリスク・ハイリターンを計算に入れた上で慎重にチャレンジしれ
ってスタンスのほうが好きだな。
(リターンにはパフォーマンスだけでなく、スキルの蓄積とか営業ネタが増えるとかも含む)

>11
>12
＞完了後のバグ報告ゼロ

それは作ったはいいが、あんまり使われてないってことじゃないのか？（w

>>47
ん〜、昔々のシステムで、リリース後のバグ１件に付き１００万円のペナルティ
ちゅうシステムが有った。

>>33
>暗黙知→形式知に変換する人が、SEで、
ＳＥ自身が、自らが持ってる暗黙知（経験則）を形式知（共有情報）に変換できない
ところが痛い。

>>48
ペナルティはあるが、何年連続稼動しても結局感謝すらされんしな

>>47
>それは作ったはいいが、あんまり使われてないってことじゃないのか？（w
そんなことないよ。金融機関のオンラインとかで、ばんばん使われ
てたりした。

聞いた話だけど、客が発見したバグ件数の５倍の件数のバグをさら
に発見してからでないと（再）納品できない、というルールにして
いるところもあるらしいね。

>>50
なんじゃそりゃ。
もしそれ以上見つからなかったら一生再納品できんのか？
いったいどこのあほが考えたルールなのか名前をさらしたまえ。

>>50 >>51
5倍ってのはどうかと思うけど、原理的にはありえる話。
客が総合テストレベルの粗いテストで、数件のバグを検出できたなら、
単体レベルではその数倍のバグが潜在しているはず、という考えが根拠。
倍数もベンダーと客のテスト粒度（orテストケース数）の比を考えれば、
算出可能。単純にテスト粒度だけで比較したら、5倍ってのは優しいかも。
ただ、再納品ルールに例外が無いというのは明らかにおかしい。
本当に品質がいい場合に備えて、例外を認めさせるルールが必要。
51の言うとおり、一生再納品できない。（笑）

根本的なとこでは、技術や情報の共有が出来ないってことが、ソフト開発の難しさだろうね。
元ダメＳＥより。

>>14
＞いつもプロジェクトを失敗させる人ってのは、
＞いるよね。

いるいる。
そんなやつに限って、納品後のトラブルが多い。
やつにばかり電話がジャンジャン掛かってくるんだ。
何も知らない新人達には、誰よりも仕事が出来る先輩だと
思われてたりする。

おれの見たいつもプロジェクトを失敗させる人。
・作業の優先順位が狂っている。（自分では気づいてない）
・ついでに言えば、作業の総量（自分の役割）の認識も狂っている。
・１手先が読めないから、すべてがその場しのぎ。
・仕様や作業の本質を考えないから、客の言いなり。
などなど。

>>7
>>17
成功の定義って「黒字」「納期通り」「バグ少ない」
も重要だけど、人材・組織が育ってなければ失敗って
判断もいいんじゃないか？

納期寸前に入院。これで成功率１００パー（のりか風にシャウト）

ほぼ>>52の人が書いてくれた通りだよね。
ただ、まあ、当然、例外はあると思うよ。
ミソは、納入する側がいい加減な検証で済ませられないという
ところだろうね。そのルールだと、自分たちでバグをつぶしてお
いたほうが経済的にも得だから。

実際、ＭＳの「仕様です」って回答来たら顧客にどう対応してる？

>>59
もちろんそのまま伝えるよ。
ただし、アプリでの回避策（当然有償）を必ず同時に提示するよ。

>>60
あ〜
日本語で会話できる顧客なんだ....
うまやらしい...

また失敗した宇津田〜

>>8
> 常に自分以外の誰かが悪いのね。
> なんだかなー。

> しかし、発注元が悪いときたか…
> そら失敗するわ。

お！、至極的を射た発言で嬉しく思いました。
結局、成功する条件が判ってるにもかかわらず、その条件を満たす努力を怠ってる
ってことだよね。
他者のせいにするのは至極簡単だけど、それじゃ失敗する。
成功する為に如何に自身が努力したのかを己に問うべきだと私も思います。

ってゆーか請負側は実は失敗したほうが
儲かるんじゃないですか？
結局人月単価だし･･･

最近じゃ追加発注なんて儲からないよ…
責任はどっち？？みたいな話になってさ〜
結局、殿様商売のお客様の場合、こっちが食らう。
客も選びたいと思う今日この頃…
その前に、失敗しない為に会社や上司の協力も欲しい所。
技術者の能力はそれなりに評価できるんだけどなぁ〜

全員、エクストリームプログラミングを勉強してから出直せ。
http://objectclub.esm.co.jp/eXtremeProgramming/

>>66
いや〜、私はプロなんで予算に見合った成果物を最初から定めてお仕事しています。
後で、「変更なんで予算よこせ〜」ってやってると一向に埒があかないし非合理なんでね♪

# 「さっさと片付けて次いこう次！！！」が合言葉だね♪

>>67
XPも予算に見合った成果物を最初から定めてるんですけど・・・。

>>68
そう？
私からすると「試行錯誤で宜しく！」って意味にしか読めんよ。
先の変更を見越すのは当然だろうけど、不確定状態で開発を進めよう〜！って考え方が気に入らないね。

# 間違った結論であってもその時点で確定さすことが肝要だと思うぞ！
# 成果がはっきりしないものに予算が付くわけないじゃん。

>>69
「試行錯誤で宜しく！」ってのは、ウォーターフォールでも変わらないと思います。
次工程に行く前は、次の工程は不確定です。

XPで行こうと思っていたプロジェクトを、
「やっぱりウォーターフォールにしよう」
と決めたところで、確定していないものが確定するわけじゃないですよね。

XPは「何が出来るか分からない」やり方ではありません。

情報シス板の知ったかはスコブルバカだと、いうわけか。

出張32みたいな奴がいるかぎり開発は必ず失敗するな。
作れたとしても、誰も使わないシステム。
金は取れても役に立たない物ですか。

ご愁傷様。

>>70
理屈じゃそうなるね♪
私が言ってるのは物の考え方であって心情なんだって！ (笑

# 単に理屈だけで論じるならば何でも良しになるぞ！(理屈さえ通ってればな

>>73
XPを誤解しているみたいだから、その誤解を解こうと思っただけです。

つまり「XPは性に合わない、嫌いだ」ということですね？
それなら何も異論はありません。
性にあったプロセスで開発するのが一番ですからね。

># 単に理屈だけで論じるならば何でも良しになるぞ！(理屈さえ通ってればな

理屈無しの議論の方が「何でもアリアリ」な言い合いになってしまうと
思いますけど。

XPが駄目だと主張するなら（こう言うと、そんなこと言ってない、と言われ
そうですが）、どの点がどう駄目なのかを「理屈」をつけて議論しないと、
意味が無いと考えます。
もちろん間違った理屈でもOK。
誤りを正しながら議論すればよいのですから。

>>74
彼は、

自分の考えが一番
自分が正しい
自分が言えば正論
反論する奴は粘着
後付けの理論派
やばくなるとごまかす

ような輩だから、議論するのは無駄。やめとけ。

>>74
> つまり「XPは性に合わない、嫌いだ」ということですね？
> それなら何も異論はありません。
> 性にあったプロセスで開発するのが一番ですからね。

ほい、そういうことです♪
人にはそれぞれ歴史があり、価値観もまた違うのです。
なんでもかんでも、理屈が通っていれば良いというものではありません。
特に、この業界は腐るほどの真理論と称する考え方が時代の脚光を経て出現します。
その中で自身に必要か？、考え方に価値があるのか？って自問自答があり判断があるんですよ。
歴史の浅い方や拘りに乏しい方には無縁でしょうけど、私にとっては大事なんですよ。

>>75
本当だね。進化のない輩だな。
彼、この板の常連なの？
XPを導入しようとするとき彼みたいな人が一番邪魔。
開発側にはいて欲しくない。

それにしても彼だけではなく、真のXPを導入する際にもっとも
難しいのが顧客の説得だと思うのだけど
オンサイト顧客的なアプローチは成功できるでしょうか。

XPに興味あって実践もしているけど
オンサイト顧客に関しては実行できずに
SEを仮のオンサイト顧客に割り当てて開発するという
事例がものすごく多いと思うのだが

XPへの私個人的な感想は、
少人数による小規模な（延べ１５人／月程度）新規システムへなら適用可能・効果もあるかもしれない。
ちゅうところです。

それ以上のでかいシステム、または改修システムへの適用は無理と考えています。
一番ネックとなるのがコミュニケーション、設計・開発に係わる情報交換じゃないかと。
この仕事をする人の特性として、情報を抱え込む要素は無視できませんね。
特に、不明点・不確定要因・作業の遅れの原因などは、皆さんプロジェクトの中で公開
したがらないです。
＃　ま、従来モデルでも同じ事は言えるかとも思いますが。

XPにこういう話が出ていたな。

「私は150人からなるプロジェクトを管理しているんだ(すごいだろう)」
管理者が印象的に見られようとするので、この問題により、
プロジェクトは失敗に導かれることもある。
最終的に10人のプログラマで同じプロジェクトをやった場合の
半分の時間で納品できたとしても、どれだけのステータスがあるだろうか

なんか訳がひどいが、意味通じるかな。


結局、でかいシステムというのは砂上の楼閣というか
大体意味をなさないですよ。
全部が全部無駄の上に無駄を塗り重ねているという感じ。
そういう事、意識したことありますか？

あんなの優秀な奴に任せたらそれこそ生産性10倍界王拳以上...(ﾌﾙｯ
東海と住海のweb保険試算システムをマジカで見ててそう思った。

何が客にとって重要かを切り分けて細分化すれば
XPに適応できないプロジェクトというのはありません。
大規模なシステムと、思っているドロドロしたものは
単に問題の切り分けが出来ていないだけ。

>この仕事をする人の特性として、情報を抱え込む要素は無視できませんね。
>特に、不明点・不確定要因・作業の遅れの原因などは、皆さんプロジェクトの中で公開
>したがらないです。

いや、そう思い込んでいるあなたに問題ありまくりですよ。
作る人と作ってもらう人の間にコミュニケーション不足があるから
プロジェクトは見事に失敗するんでしょ？

あなたが開発者ならお客が一言も話さないのにシステム作れる？
あなたがユーザーならプログラマが一言も話さないで利益のあるもの作ってもらえる？

>結局、でかいシステムというのは砂上の楼閣というか
でかいプロジェクトという意味で読んでください。

でかいと思われるアプリケーションやOSやシステムの開発でも
実際のプロジェクト単位にしっかり分けると少人数開発できるし
そうすべきです。

>>79
うーん、79さんの言わんとする所が何なのか、いま一つ読み取れないのですが、文脈から考えて、
でかいプロジェクトでも適切に細分化すればXPでも適用できる。
という事でしょうか。

上記を79さんの意見と考えてみますが、
私の言いたい所はシステム開発における情報交換の難しさであって、プロジェクトの大小は情報交換の
量及び質の増加を示す付帯事項に過ぎません。
しかし、それがプロジェクト開発を困難にする大きな要因の一つである事は確かだと考えています。

プロジェクトを細分化すれば、自ずとインターフェースとして情報交換作業は増加します。
論理単位としてのユニットが増大する程に、ユニット間・ユニット内での情報交換も増加します。
ユニットスペックは、縦・横のインターフェースの変更に伴い、日々変化していきますし、その度に情報交換も
必用とします。
各ユニット内部でも、各要員が自タスクとして作業を受け持ちます。タスク間情報交換も当然起こり得ます。

情報交換の難しさとは、例えば
（１）発信ユニットから関係ユニットへの送達確認。
（２）受信ユニットでの影響調査、及び自らが新たに発信ユニットとして（１）の作業が発生。
（３）ユニット内情報交換のイニシアティブ、メンタリティ。
などでしょうか。

ペアプロひとつとっても、メインとアシに分けるか対等にするかで情報交換の主導権は変わってきます。
対等にすれば、合意が得られるまで時間を要しますし、主従とすれば主が示す方向に従は引っ張られます。

上記の例は、情報交換に伴う感性の部分ですが、もっと重要な要素はその量・質・内容です。
この業界、プロジェクトは様々ですし、それに携わる人員も多種多様です。
全ての要員を優秀な者で揃えるわけにも行きません。
各ユニットリーダーがユニット内スペックを全て把握しているとも言い切れませんし、担当者も他のタスクまで
理解はできないでしょう。

システムを情報の局所化と見なして、それを開発するに必用な情報も局所化する。
開発要員も自タスクに必用な情報のみを選択する。
私自身、このスタイルは好きではありませんが、これ以外に現実的なプロセスモデルは勉強不足で知りません。

>>81
あんね、相手の顔が見えなきゃ意思統一は難しい！

# 理屈ばっか言ってないで現実を直視しろや！（笑

>>82
おめーだけには言われたくね〜な。（晋）

>>83
> おめーだけには言われたくね〜な。（晋）

おお！、やっとトリップから抜け出して現実の世界に戻ってきたのですね。（良かった良かった
開発規模が大きくなると、対応する技術者の数も多くなっていきます。
コミュニケーションの効率を考えれば必要人員は比例＋αで増えていきます。
で、開発時にトップダウン手法を取るのが通例ですから上から順に情報を下層へと降ろして行く訳なんですけど．．．
規模が大きくなると階層化数が多くなるので大変なんですよ。
小規模なシステムならば、必要人員全てを集めて小学校スタイルで済むのだけどね。（笑

>>82オマエは黙れ。バカ

>>81
＞でかいプロジェクトでも適切に細分化すればXPでも適用できる。

そうです。その通りです。

情報交換の難しさを(1)〜(3)まであげておられますが
それを文字通りエクストリームして究極までその手間を省くために
オンサイト顧客やペアプログラミングをコミュニケーションの道具として
用いることができるのがXPではないでしょうか。

むしろ、XPを導入せずにいると
困難なコミュニケーションの問題を解決せずにプロジェクトが進行することに
なるわけですから、手間ばかりかかって
プロジェクトが成功とは遠い方向に流れていくと感じます。

>ペアプロひとつとっても、メインとアシに分けるか対等にするかで情報交換の主導権は変わってきます。
>対等にすれば、合意が得られるまで時間を要しますし、主従とすれば主が示す方向に従は引っ張られます。
意味がつかめません。ペアプロではないプログラムモジュールの結合を行う方がよほど
双方の合意が得られるまで時間が取られます。

＞全ての要員を優秀な者で揃えるわけにも行きません。
全ての要因が優秀なものだけがXPを行えるというのは
XPにおける誤った理解の一つです。全くそんなことはありません。
XP入門本のP120に記述されていますが

二人の経験レベルが遥かに違う場合でも、2ヶ月もたつとパートナーギャップは
解消されるという事です。
ペアはお互いの長所短所に気が付き生産性、品質、満足度上昇とされています。
一人がコードの入力に忙しくても、もう一人は戦略的レベルで考えられるというのは
非常に互いの助けになります。

そして、コードの一部を"あの人だけが理解している"というリスクを回避できます。
その人がいないとシステムが出来上がらないというのは、とてつもないリスクです。

また、
ペアプロは研修ではないですが教育の面からも
日本の開発者にありがちないわゆる技術のない人間を技術のある人間に変えることのできる
方式だと思っています。

>>85
顔をつき合わせてさえ難しいコミュニケーションをブラウン管でＯＫって全く信憑性がありませんな！
所詮は絵に描いた餅ってことだよね♪

# まあ、使い方次第じゃメールより少しだけ便利だけどね。
# 成功事例が見たいね♪

>>86
XPは顔をつきあわせるコミュニケーションの開発手法ですよ。

>>86
>顔をつき合わせてさえ難しいコミュニケーションをブラウン管でＯＫって全く信憑性がありませんな！

どこから「ブラウン管」が出てきたのか知らんけど、XPは物理的に
離れたコミュニケーションを否定してるよ。

># 成功事例が見たいね♪

C3 project

>>87
ほう、するっていとＸＰを導入すれば1000名が顔をつき合わせてお仕事するってことですかい？

すいません、この方は相手にしないほうがいいのでしょうか？
教えてください＞＞この方以外オール

>>89
そうです。

虫が一番

>>90
>>75で言ったとおり。やっとわかったかな？
彼はただ会話を混乱させて楽しんでるだけ。
相手にするのは、時間の無駄。

時間の無駄だけならまだしも、彼の相手をすると、必ず議論が
破綻してしまう。

彼は

・普通使わない怪しげな単語
・意図的なtypo
・どうとでもとれる文章

という罠を張り、相手がのってきたところで、舌なめずりしながら
会話をさらに混沌とした方向に持っていく。

完全無視が一番＞All

>>93=75さん、ありがとう。
まあ、この程度の煽りなら2chならどこでもだから気軽に流しておきます。

クラックがダメな理由。クラックだと怒る理由。
http://pc.2ch.net/test/read.cgi?bbs=prog&key=1001269042
ここのバカより256倍ほどマシだし。(ｗ
コイツを駆逐するのは骨が折れました。

>>91
> そうです。

ほうほう、するっていと実作業する以前に会話だけで開発期間は終わってしまうね。

# ＸＰを全く評価しないとは言わないが、過大評価し過ぎるのも問題あるぞ！（笑
# まあ、それなりに使うってところで押さえて置くのが正解でしょうな。

彼とは関係ないが（ｗ

周囲の大規模ＰＪは、必ず情報交換のＱｕｅがオーバーフローするか
情報交換に業務時間が全て割かれて、中身が進まなくなる。

その辺を仕分けするという、ワケワカなチームが出来た事もあるけど
業務を知らない奴が仕分けするから余計タチが悪くなった。

その辺うまい方法無い？

>>95
いえいえ、会話しながら実作業するので、全然問題ありません。

>>96
そんなあなたにXPってのはダメですか？

XP的にいうと、そういう場合スコープを小さくすることが
もっとも効果的だと思います。

プログラムのもっとも価値の高い、ユーザーのビジネス上の問題を解決する
機能だけを、先に作ってしまうのです。

>>86　出張32へ。
話に首突っ込む時は予備知識くらいは仕込んでから参加しては如何？
せめて↓くらいは読んでみた？
http://mentai.2ch.net/test/read.cgi/infosys/986909661/l50

それと、＃の卑怯な使い方やめろよ。
＃のコメントにはレス入れない、フレームの中で出来た暗黙のルールくらいの事知ってるだろう？
−−−＃の利用例−−−−−−−−−−−−−−−−−−−−−−−−
　貴方のコメントが誰に対して書かれているのか、主語が判りません。
＃文法の勉強、小学校からやり直せ　バカ。
　私に対してのコメントと見なしてお答えします。　　　　　　
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
>>82
># 理屈ばっか言ってないで現実を直視しろや！（笑
で煽っておいて >>84 は >>81 の要約でもしてくれたの？（笑
ホントは＃の意味、知らないんじゃないの？

今日はもう寝ます。>>85さんへのレスはまた後日。

なーー！！！、後日にされてしまた。

なんか他のスレみてきたけど
出張32がプロの煽り屋とか書いてあたけど、

この程度のお子様煽りでプロの煽り屋名乗られたら片腹いたいぜ。

みんなかちゅーしゃ使って透明あぼんすればいいよ。

>>99
そのリンク先、非常にレベルが低くて
読んで泣けてきた。、せめてこちらをみよう。

eXtreme Programming
http://pc.2ch.net/test/read.cgi?bbs=tech&key=989482113

>>99
> それと、＃の卑怯な使い方やめろよ。
> ＃のコメントにはレス入れない、フレームの中で出来た暗黙のルールくらいの事知ってるだろう？

知らんなぁ！
私は単に、理解しとらんバカに助言を#付きでカキコしてるだけなのよ。（笑

>そのリンク先、非常にレベルが低くて
そうでもなかったです。スマソ。
無意味にXP否定する人もいるけど
わかっている人も沢山いるみたい。
みんな試行錯誤中なのか。


>>102
はいはい。理解してないのは、キミでちゅよー。
バカはキミでちゅから、さよならしてくだちゃいねー。

>>103
> みんな試行錯誤中なのか。

そういうこと！
何処まで使い切れるかを検証中なんですよ。
ある程度、検証してからでないと良いとも悪いともいえませんからね。

もっとも、ＭＳ言ってるほど過大評価出来るほどの物じゃないけどね♪

>>104
??? ＭＳがeXtreme Programmingについて何か言ってたっけ？

>>１０４
おまえ、論文とか読んだことないだろ？（プ

>>105
おう、一杯発言してるぞ！

>>106
いや、読んでるよ。
まあ、ＸＰはアホらしかったけどね。

で、c3 projectについてはgoogleしたのか？
検索は得意なんだろ。
とりあえず、そのリンク先を全部読め。

ってか全く興味なかったりしまふ。
時間幾らの契約なんてしないのでＸＰのような手法は物理的に難しいのですよ。

で、結局
オンサイト顧客を実践できている事例ってありますでしょうか？

>>109
では、何故このスレにコミットしているのだ？

>>111
相手すんなって。ｼﾞｻｸｼﾞｴﾝ?

>>111
> では、何故このスレにコミットしているのだ？

会話が面白いからに決まってると思うぞ！（笑

>>113
オマエがいるから他のみんなは面白さ120%OFFだな。

>>109
>時間幾らの契約なんてしないのでＸＰのような手法は物理的に難しいのですよ。
それは違うぞ。
C3にしても、言ってみれば極端なRADだが、発注する側があんなもんに人月で
払うのには絶対承知するわけないだろ。まあ、XPもRADと同様にタイムボック
ス単位でマイルストーンが切られるわけだ。
C3で実際にどうしているのかはしらないが、普通、RADのようなプロセス
の場合、逐次マイルストーンの目標に対して継続的に契約をしていくと
いう形にするだろ。XPも含めてRADを適用する必要があるのは、解決策
提供側にも明確なゴールが引けないからだ。
そんな世界でどういうプロジェクト完了基準が置けるんだ？ソフトウェ
アプロセス違ったらサービス内容違うんだから契約もそれ用になるの
当たり前だろ。
今だって、保守と新規は別の契約してるのと同じだよ。

一方、スレの原点に帰ると、XPを「失敗しないための」プロセス
として捉えるのもどうかと思うけどな。
やっぱ、XPも含めRADには非効率な部分はある。つまりさ、プロジェクト
の性質によってはそれが許されないんだ。それでもXP的にやらなきゃな
らないってのは、受注したとこで間違ってるだろ。

本題である「どうしてソフトウェア開発は必ず失敗するのか」という
問いに対して、答えるとするなら、生まれながらに「不可能領域」に
あるプロジェクトばっかりだからってのが俺の思うところだ。

たとえば、COCOMO的な視点からというケースもあるし、または、RUPい
うところのアーキテクトとかのリソース不在によるケースもある。
いずれにしてもできないことを「やれます」って言っちゃったところ
から始まってる。

ソフトウェアプロセスとかをしっかりと押さえて、やれるのかやれない
のかを判断することこそ大事なんじゃないか？

>>115
> C3にしても、言ってみれば極端なRADだが、発注する側があんなもんに人月で
> 払うのには絶対承知するわけないだろ。まあ、XPもRADと同様にタイムボック
> ス単位でマイルストーンが切られるわけだ。
> C3で実際にどうしているのかはしらないが、普通、RADのようなプロセス
> の場合、逐次マイルストーンの目標に対して継続的に契約をしていくと
> いう形にするだろ。XPも含めてRADを適用する必要があるのは、解決策
> 提供側にも明確なゴールが引けないからだ。
> そんな世界でどういうプロジェクト完了基準が置けるんだ？ソフトウェ
> アプロセス違ったらサービス内容違うんだから契約もそれ用になるの
> 当たり前だろ。
> 今だって、保守と新規は別の契約してるのと同じだよ。

良いこというねえ。
結局、どんなプロジェクトであれ「請負形態であるならばそれなりのゴールと費用を明確にする」ってことなんだよね。
その意味で、ＸＰは非常に使いづらい。
社内開発やパッケージ開発ならば使えるのだけど．．．
そこらでの使用となると概念に特殊性などあるようには思えんし、単に作業進め方に付いて
の提言でしかなく何方でも知ってるレベルであると言える。

> ソフトウェアプロセスとかをしっかりと押さえて、やれるのかやれない
> のかを判断することこそ大事なんじゃないか？

その通りだと思うよ。
ってか、やはり自己責任を考えかかわるのならばそれなりの姿勢に立つって
ことだと思うよ。

>>116
>そこらでの使用となると概念に特殊性などあるようには思えんし、単に作業進め方に付いて
>の提言でしかなく何方でも知ってるレベルであると言える。

まぁ、そうですね。
だからこそ、他のプロセスとの置き換えが可能なんですよ。
ウォーターフォールをスパイラルに置き換えたからといって、ゴールが不明確に
ならないとの同様、XPに置き換えてもゴールは不明確になりません。

また、費用も現状では、イコール人件費なわけですから、ウォーターフォール
だからといって、事前に費用が明確になるわけでもありません。

115=116なんじゃないの？

age

>>117

> ウォーターフォールをスパイラルに置き換えたからといって、ゴールが不明確に
> ならないとの同様、XPに置き換えてもゴールは不明確になりません。

うん、理屈だとそうだね。
本来、試行錯誤工程は実在するし完全に払拭など出来ない。
だけれども、極力試行錯誤工程を減らす努力を行いコストパフォーマンスを最大に
持って行く努力をするのが私どもの商売(請負業者)なんだわさ．．．
その意味において「痒いとこに手の届くシステム」は開発不能だといえる。
上記の前提を考慮するならば、設計段階での費用見積りが重要となり
その段階(更にはその前段階)にゴールを明確にする(即ち、試行錯誤工程の排除)ことが要求されるのよ。

とかいっても、ゴールが勝手に逃げてったりゴールの方向が勝手にかわるのが
日本の顧客といいうものでして
事前に千回確認しておいたって要望連絡票さえ切れば予算そのままで
仕様の１８０度変更などあたり前田のクラッカーですし
この業界の製造工程ほど、契約と言うものがないがしろにされる業界も
珍しいのではないかと。

>>121
そんなお話は耳にたこが出来るぐらい聞くのだけど、その手の発言してる人って
かなり設計が甘いように思います。
現実に優秀なＳＥほど、そのような発言は少なくなりトラブルも少ないですからね。
全てを相手のせいにしているように聞えてきて同意し辛いです。

荒らしを無視できない奴は荒らし
出張32を無視できない奴は出張32

>>121
かといって、そこで仕様変更を受け入れないと使われないシステムになる。
また、ユーザから見ればシステム導入ってのは一大イベントだから、
（ユーザ自身含めて）徹夜や休出当たり前の感覚だけど、我々はそれが
1年中だからな〜。

因果な商売だよな〜。

>>122
論理をいくら積み重ねたって、鶴の一声が間違ってたり人の話もアドバイスも見ない・聞かないとか
うっかり顧客側に経験のない担当がついちゃったりするだけでＰＪが壊滅的打撃になる事はよくあるよ

俺は指示から方針がはっきりするまで放置したり、差し替え用も平行して作ったりして
急な変更に常に対応できるようにしてる
決して設計が正しいとは信じず、素早くフォローできるようにしておく感じ
顧客だって足元を把握しきれるとは限らないから、駄目そうなら進行方向の障害物を取り除いておく
分岐先も経験的に分岐しそうな方向は全て点検しておく。
客に修正線標を提示しておくが「随分と心配性ですね。まぁどうぞ」の一言で大体終了。後でズッポシ大当たり。

出張32さんは、むしろ優秀な顧客に恵まれた事を神に感謝すべきではないかと。

どうしてソフトウェア設計は必ず失敗しているのか？

>>125
言ってることは凄く良く判るんだけどね。
それってやっぱ現状分析が正しく行えてないケースだわ。
確かにユーザー側で要件分析を行うＳＥを用意されると、その人の独断で
いい加減な(間違った)要件分析が進行するケースはあるさ。(これほんと困るね)
そして、こちら側からはユーザーと接触することすら出来ず作業が進んで行くってことだよね。
これらは要件分析を行ったユーザー側に問題があり事例的には要件分析過程での
分析ミスってことになるね。
どちらにせよ、立場と責任の所在を明確にしておけばトラぶっても此方の被害は最小に押さえれます。

※『日立ソフト』（金７２）の松本・塚本
投稿者: aho_hitachisoft (男性/日立ソ○トは問題児) 2002年1月21日 午前12時20分
メッセージ: 1 / 1
こいつらは、
『人間の屑』
『社会のゴミ』
『非人間』

早急に死すべし！

>>123 は荒らし

情報処理技術者試験にも
合格できないような奴らがやってるから。

http://www.aurorasd.co.jp/MaiDvoClu/rebuild.index/rebuild.02.index.htm

ウオーターフォールモデルっていい？
１３１で否定してます。

日本は大抵ＮＴＴモデルです。

根性⇒根性⇒根性⇒根性⇒根性⇒根性⇒根性⇒根性
・１日１個、バグという名の仕様変更があると思え
・レビューは全く聞いてないから仕様と思うな
・仕様が決まるのはサービスイン１年後

これを念頭に置いた設計が必要です

「失敗する可能性のあるものは、必ず失敗する」

マーフィーより。

基本的にソフトウェア開発に携わっている現場の連中の思考回路の貧弱さというか、
脳ミソのしわの数の少なさに原因があると思う。
例えば小学生に１０進数を２進数に変換する事の意味を説明する自信ありますか？
その辺りが開発の成否の別れ道だったりすることに気付いていないでしょう。
総合的な知識、語彙、表現力、センス、教養、ＩＱがSE、PGには不足していると思う。

>>135
> 例えば小学生に１０進数を２進数に変換する事の意味を説明する自信ありますか？

何を伝える必要があるのかを考えていない人が多いですね。
上記の例でだと、変換する意味を伝えるのではなく、二進数にした場合の各ビットの
値が個別に利用されることを伝えれば済むお話ですな。

だから「各ビットの値が個別に利用されること」が小学生に理解できるんですか？
と云っているんです。小学生の教科書に記述すると仮定して、この板に書いてみてください。

>>137
お嬢ちゃんが知ってる2と言う数字はコンピュータの世界だと00000010って書くんだよ。
それでね、1って数字は00000001って書くんだよ。
２の場合は右から２番目が「1」ってなってるよね？
右から２番目の数値が「1」ってなってるときはこのランプがつくようになってるんだ！
そして右端の数字が「1」になってるときはそのランプが付くんだよ？
判ったかい？

>>138
お兄ちゃん、コンピューターって、ランプが点く機械なの？？

>>139
そうだよ♪
お嬢ちゃんのお父様が使ってるこのコンピュータはそうなってるんだよ♪

あ！、そうそうさっき言い忘れていたけどね。
３って数字は00000011って書くからこのランプとそのランプの二つとも付くことになるからね♪
判ったかい？

うん！
だけどさぁ、両方とも消す時はどうするの？
それはね♪
０ってここに入れればいいよ。
０の時は00000000ってなるから両方とも消えるんだよ。
判ったかい？

うん！
よく判ったよ。

じゃ、お兄ちゃんはこれで帰るからお父さんにさっき話したことを教えてあげてね♪
うん！！

# ほい！お仕事完了♪

>>出張３２へ

お前のＩＱは、見切った。お前の絡んだシステムは必ず失敗する。
ユーザーの言ってる事、主旨、疑問点にまったく噛み合った回答が出来ないヤツだな。
もしかして出張ヘルスか？
そっちの方が社会的に存在価値はあるか・・・。

>>141
現実と異なることを急に言われても納得出来ないね♪

> ユーザーの言ってる事、主旨、疑問点にまったく噛み合った回答が出来ないヤツだな。

そのように考えるのは君が妄想の世界で生きてるからだと思われる。
発言の趣旨をもう一度確めてみるべしですな。
会話と言うものは噛み合う必要を感じたときに噛み合えば宜しい。
伝えたい要件と、相手が聞きたい内容が必ずしも一致する必要など無いことを理解されたし。
そのことを踏まえて会話を進める癖を付けないと相手に振り回されるだけで、
時間の浪費となるよ。

ところでハードがわからないで、なんでソフトが作れるの？
何で文系の人がソフトつくれるの？

>>143
プログラムって、論理的な思考で作るもんでないの。
制御系の人達は知らんけど、わし業務系アプリの人なんで、
ハードなんて知らんでも今のとこ生きて行けてる。

>>143
なんでここの板の人って理系、文系ってすぐわけたがるの？
理系の人って大学で４年間（修士も含めても６年間）みっちり
数学でもやってきてるわけ？大部分は数学科でもないのに？
大学入る時点での違いがそんなに尾を引くものなの？
マジメな話、さっぱり理解できないよ。

文系出身でも制御系の仕事が回ってきたら、それ用に勉強して
仕事になるようにするのがプロなんじゃないの？それができなければ
理系でも文系でもなんも関係ないって。

>>1
失敗する理由として、日本国内ではプログラマやＳＥなど、請ける側を
まもるための法規制がまるで整っていないことがあるとおもいます。

もう、発注者側のいいなりですよねぇ。立場弱すぎですよ。こんなんじゃ
日本のソフトウェア産業がいつまでたっても米国に遅れをとっている上に
韓国やインド人に簡単に追い抜かれてしまうのは当然じゃないかと。

つーか、発注者側も、>>52にあるような５倍のバグみつけろなんて
超がつくぐらい古い考えのやりかたで仕事まわしてるからみずほみてぇな
ザマになるってぇの。
グチになってしまった、ｽﾏｿ。

>>145

俺が今やってる電気回路・電子回路・電磁気・・・・etc.
これを文系卒の人間が１からやろうとしたら

「それ用に勉強して仕事になる」

までに何年かかると思ってるんだよ？
まあ一言に制御系と言ってもピンキリだろうけどさ。

まあその前に微積で何年かかるかな

決めりゃいいだけの問題を只単にやりたくない、っていうムードから
ず〜っと先送りして、期限来ると「時間がないので」なんて理屈通してるから。

あとCが居ると必ず・・おっととと、こっから先は示威壊死軽スレに書こう（藁

age

>>143 の言ってるハードって・・・コンピュータのこと・・・？

>>1答え一発　無能者が多いからです。有能者は退職か、皆さんがどこかへ
追いやったのです。

ハードウェアの開発も沢山、失敗してると思う。
だから、失敗は、成功の母なんて諺ができたんでしょうね。
つまりは、ソフトウェアは歴史が浅いので、失敗が
まだまだ足りない、だから、成功しないんですよ。

ハードも失敗するんだよね？
建設途中のビルを見たときに、よく最後まで作れるなぁと
感心するのですが、あれも結構失敗するらしい。
ソフトウェア開発が失敗するのはやっぱ「ソフト」って意識が
あるからだよね。取り返しのつかなさってやつに対する感度が
決定的に違う(甘い？)のでは。

ハードの世界の開発じゃロケットなんか数百億単位の国税使った
失敗プロジェクトがあるけど、ソフトの場合、せいぜい数億で、
しかも、国税使うような国家プロジェクトでの失敗ないよね。
大失敗も無い代わりに、大成功もないんでしょうね。

あと、ロケットなんか３回やれば成功するけど、
ソフトのプロジェクトは、二度と同じプロジェクト
やんないでしょ。だから、失敗の経験が成功の母に
なんないで、同じ失敗くりかえすんだね。
みずほも、同じプロジェクト３回やりゃ成功すると思う。

終了　　　　　　　　　

失敗しても責任とらされず　大きな顔して　のさばっている
何故　誰もそいつの責任を追及しないんだ
不思議　不思議　不思議　不思議
誰かの弱みを握っているのかな

読むだけでも、とても勉強になります。
考え方を学び、それに則って当たり前のことをコツコツやれば、
成功するはずです。何も特別なことではないのです。
そのための最短のツールも紹介しています。

http://www5a.biglobe.ne.jp/~ka-mi/method.htm

>>159
感動した。
これからの時代はネットワークだね。

>155
有名な大失敗プロジェクトの話を聞いたことありますけど。
確かシ

>>159
最短のツールはいらんからコツコツやることにした。

曖昧な人達の為の曖昧な人達が作った曖昧なソフト達。
うまくいく訳がない。
成功するべくして成功した訳ではない。たまたま成功しただけさ。

何度も何度もレビューしても、客にうるさいと言われるまで確認に確認を重ねても、
仕様凍結して開発期間中にもし客の気が変わっても選択できるように準備しておいても
納期前に顧客の会社のお偉いさんがどっかのIT関連の記事読んでこうしろと言い出して
仕様変更＆機能追加になることなど日常茶飯事過ぎて話題にもならない。
とにかく日本はSI側の立場が弱過ぎ。いつまで経ってもこの分野では日本は3流のままだね。

>>164
禿同
仕様が固まらないから、システムが作れない。
途中で変更を強引にいれるから、システム間の整合性がとれなくなる。
ユーザーは、金を出さない。
ユーザーは、納期は変えたくない。
ユーザーは、経営者にいい顔をしたい。
だから、ＳＥに無理難題を押し付ける。おまけにその自覚が無い。
結果、当初は順調だったプロジェクトが変な方向へ動き出す。

システム開発や運用には金がかかることを、もっと客は自覚すべきだと思う。

>>164,165
言ってることは良く分かります。
ですが、厳しい意見を言わせて貰えれば、
それまでに築き上げた仕様が顧客にニーズに合致していない。
平たく言えば、表面しか汲み取っていない設計になってるのではないでしょうか？

顧客のニーズを的確に汲み取り設計された仕様ならば、そうそうは改定など起こらないです。

>>166
その「顧客のニーズ」ってのがはっきりしないのよ。
お客さん自身がシステムでどういったことが実現できればいいのか
がわかっていないことが多いと思いやす。
要するに「問題定義」ってのが甘くて、とりあえず何か作業してるぞ
ってアピールできてればいいってのがほとんどで、
会社の生命線になるようなシステムを本気で考えているのは
ほうたうに極一部の会社にすぎんと思われる。
ITベンダーもそういった状況に甘えていて、結局はお互いに馴れ合ってるん
だよね。

>>167
そのことも良く分かる。
だけどね、それを言っちゃ設計者失格ざんしょ？
そのような状況でさえ手とり足とり顧客を誘導せんといかんし場合によっては
動機付けさえせんといかん。
確かに、周りの状況は「有耶無耶のまま波風立てずに突っ走れ！」って無責任な態度なんだろうけどね。
それに乗っかってはダメざんしょ。

設計者として為すべきことを最優先にすべきだとおもうよ。（嫌われてもね。

>166
はっきりさすためにﾌﾟﾛﾄﾀｲﾌﾟ作れ。
「これで(・∀・)ｲｲ! 」っていわれるまで何度も作り直して黙らせろ。

>169
やりたいのは山々なのだけど、人も期間もあんましかけられない
のが現状なわけで。
で、しかも適切なレビューができるお客さんも限られててねぇ。
本当に(･∀･)ｲｲ!システム作って効率化できちゃうと人がいらなく
なってそれはそれで困るという罠。

>>170
正直、時間が無いというのは言い訳にしか過ぎない。要は自分の会社の上司に
仕事をちゃんと説明出来ていないから押し切られちゃうんじゃないの？
厳しい事言っちゃってスマソだけどね。
この仕事、ペースを作る側になれなきゃしんどいだけだよ。

何をもって「失敗」と呼ぶのか？
予定の開発期間とコストをオーバーしたことか？
だとしたら、失敗するのはソフトウェア開発だけに限らないね。
例えば、ドーバートンネルは、大失敗したことになってしまう。

>>172
必要な時に出来あがらなかったものを言うんじゃないの
システムっていうのはビジネスに直結とたものだから、納期が大幅に
遅れて　出来あがったときには　使い物にならないっていうのは
失敗じゃないの？

あいかわらずXPもわかってない香具師ばっかりか。
仕様変更なんて当たり前。
自分がユーザーの立場になったら、>>165に
書いてある事をするのに
開発の立場から、「もっと客は自覚すべき」だと、おめでてーな

このスレに書き込んで何か会話から得ようとする前に
とりあえず、一通りソフト開発ってものを勉強してきて欲しい。

>>174

君はXP勘違いしすぎ。
XPはあくまでも「仕様変更を前提とした開発をする」であって、
「仕様変更を是としろ」とは一言も言ってない。
そこを勘違いする香具師がいるんだよね。

その証拠に、
XPでは開発初期から顧客との緊密な関係を維持するよう訴えている。
要件定義段階を重要視しして、
なるべく意識違いを減らし、仕様変更を起こさないためだ。

ある程度の自由度を最初から盛り込んだ設計を考えることと、
言われたことを何でもそのまま受け入れるのとでは全然違う。

まあ、当たり前の話だが、
ずっと仕様変更を受け入れていたら、
一生システムなんて出来上がらない。

＞とりあえず、一通りソフト開発ってものを勉強してきて欲しい。

ｵﾏｴﾓﾅｰ

>>175
良いこと言うねぇ。
まったくその通りです。
「計画する」「思考する」「熟慮する」このことがあって初めて目的通りに物は作られる。
それらをより具現化し思考する為の手順としてＸＰが提案されている。
不必要に何でもかんでも「思考錯誤せよ」等とは言っていないからね。
技術が未熟であったり、思考が浅かったり、要件を整理出来ていなかったりする場合
思考は停滞してしまう。
そんな状況が一番不味いのであるから、その状況を打ち破る為に「判るところから具現化してみて検討しなさい」って
子供を諭すように論じてるのがＸＰなんです。
勿論、それらの手順は熟練者においても場面により活用できる。
特に、技術者からユーザー側へのプレゼンテーションとしては強力です。
技術者が思考するほど、ユーザーは思考されていないケースが多いからね。
まあ、当たり前といえば当たり前なんだけど．．．
それらを忘れている技術者も多いから配慮不足も多発し仕様変更の主要因になってたりする。
その意味では、>>174さんの言い分にも同意できるね。

無能度がム板よりPowerUpするね。さすが情死す.
すばらしい！こうやっていつも失敗するわけだ。

＞「仕様変更を是としろ」とは一言も言ってない。
車の運転のように開発を進めろ
たびたび方向修正しろ
と主張されているのだが。

＞その証拠に、
＞要件定義段階を重要視しして、
＞なるべく意識違いを減らし、仕様変更を起こさないためだ。

すごいよ。その自分で勝手に決めた結論について
むちゃくちゃな証拠まで突きつけられるとは。

そのやり方で顧客をだまして、また役に立たない死捨て無導入ですか。
すばらしい。他人に胸はって誇れる仕事をしてますね。

"要件定義段階を重要視する。"そんな号令はどこにあったかな〜
その段階の次の段階に何がくるんでしたっけ？（藁
えっと、ｽﾊﾟｲﾗﾙとかｳｫｰﾀｰﾌﾛｰとかも死っておいた方がいいかな？

>>177
おいおい、おたくのレスは「まったく無意味な発言」＆「煽るだけ」のパターンになってるよ。

# 手法を知ってても意味なし！（使えるだけの技量を先に身に付けてや〜（学校では教わらんかもね）

>>178
目くそ鼻くそを笑うとはこのことだな。

>>171
やっぱ言い訳になっちゃうんですかねぇ。
でもね、上の人(管理職)って結局レベニューで判断してるんで、
お客さんからお金が引き出せない以上、「なんとかしてよ」
ってぐらいしか言ってくれないのよ。
最後はお金なんですよねぇ。いい仕事したいのは山々だ！

>>180
まあ、何方もが通過する道だね。 => 最後はお金なんですよねぇ。いい仕事したいのは山々だ！

で、積極姿勢な方でも対処方法は分かれてきます。

１）もっと自由に開発したいが最優先な人。
このタイプは最終的に会社を飛びだし放浪する人です。
予算を出来るだけ有効に使いたい訳ですから無駄を切り詰めることを念頭に
出来るだけ機能を詰め込んだ設計をします。

このタイプが注意しないといけないことは「自身を過信せず趣味に走らない」ってことでしょう。
まあ、プロであることを自覚し節度を持って行動すればそれなりに道は開けると思います。

２）今為しえることに全力で応じ、為しえないことは個人としての宿題と考える人。
自身の成長を源泉と考え次回に今回為しえなかった内容を盛り込むことで対処する人を指します。
このタイプは安定と成長のバランスを重視する方です。
ユーザー側からすれば一番理想な技術屋ってとこでしょうか？
ですが、このタイプにも弱点はあります。
所属している会社が安定を望み過ぎると窮屈となり飛び出すことになるでしょう。


# 貴方はどのタイプですか？

>>181
どっちかというと２)です。
なんとかかんとか帳尻の合うところまではもっていくんですけど、
必死こいてできあがったシステムを見たときに覚めてしまうん
ですよねぇ。何やっとるんだおれは？と。

>>167
最近、やたらとビジネス・モデリングがどうのこうのとか聞きますが、なんとなく
その理由がわかるような気がすますた。

http://www.atmarkit.co.jp/fjava/devs/redge01/redge01.html
ＩＴプロジェクト（ソフト開発も、パッケージ導入も）の成功率は
２５％程度、３０％が中断、４５％が失敗。失敗とは、コスト、納期が
２倍以上に超過、機能が１／２しか実現できなかった。
その原因のほとんどは、不完全な要求仕様、仕様変更の多発等
業務分析を中心としたもの。
　では、オブジェクト指向やモデル・ドリブン・アーキテクチャ
が、すっきりと問題解決してくれるかどうかは、まだわからない？
http://itpro.nikkeibp.co.jp/members/NBY/techsquare/20021101/1/

ソフトウエアが目に見えないものであることも
仕様は変化するものだ?・・・甘い、甘い。
要求仕様は変化するべきなのだ。
http://www03.u-page.so-net.ne.jp/dc4/tnaka/fowler/newMethodology_j.html#A42

可哀想に…。
みんな酷い目にしか会ったことないんだね。
まぁわかるけど。

キー入力数回でたちまち不具合も、改良も出来てしまう
ソフトウエアにありがたみがないから
「別に何が必要になるわけでもない、どうせプログラム直すだけだろ。」
って感じで顧客は気軽にオーダーしてくるんだね。
こんな重みのない仕事選んだ自分が情けない。。。

えーっと、ソフトウェア開発の失敗は
出来ないことを出来ないと言えない、開発者のバカさ加減に
あると思います。
ソフトウェア開発の失敗＝ユーザの失敗(損失) なので
ユーザは、SEに出来ないことを要求する気は全然ないんです。
ただ、SEが技術的、または見積もり面でユーザに
｢出来ない｣または｢わかりません｣と言えないため、
自分自身意識せずにユーザを騙してしまい、
ユーザを巻き込んで共倒れしてしまう。
これがソフトウェア開発の失敗の原因の全てです。

ツールや開発手法とか、要求仕様が変化するからとか
XP採用すれば、とかそんなんは本質じゃないですよ。

じゃまた明日。

>>188
> えーっと、ソフトウェア開発の失敗は
> 出来ないことを出来ないと言えない、開発者のバカさ加減に
> あると思います。

それは全く的外れな認識ですよ。
「何を開発すれば良いのかが判らない！」ってのが原因の殆どです。
で、「〜判らない！」ままに開発が進んでいる部外者だと信じられない現実が
この業界では当たり前な事象なんです。（笑っちゃうよね。

でだ、「何で判らんのに開発してるの？」って疑問が湧くと思うんだけど．．．
実は開発関係者の多くが「判ってるつもり」になってます。
勿論、突き詰めて行けば「判っていないことを認識出来る」筈なんだけどね。
そこが「突き詰めれば責任を背負わされる」と考えて「突き詰めないでおこう」と結論付ける無責任な
対応が顧客側担当者も含めて蔓延しています。

ほんとに嘆かわしい事態なんだけど事実です。

>>189
顧客も「何を作らせるつもりなのか決めてない」からねえ。
どうにかしたいのだけどどうすればいいのか分からなくて、
無責任丸ﾅｹﾞサラリーマン重役
→無責任丸ﾅｹﾞ顧客側システム担当窓口
→SIer
という順序で、「方針決定」の段階から丸投げｻﾚﾃﾏｽから。
それでいてできがわるけりゃ、他人事のように批判して
最後はSIerをトカゲの尻尾扱いするだけ〜。
日本のｴﾗｲ人って、最終的な責任を回避することしか考えて
ない人多いんだけど、なんでそんな無能が役員報酬貰ってん
のよ？

>>189
ユーザは、コンピュータシステムわかってないから
金出して頼むのよね。
出来ないこと、出来ることの判断も言外にSEに
依頼してるんです。
>「何を開発すれば良いのかが判らない！」
これは、｢焼きそば｣くれって言ってるのに
｢ラーメン｣を出して、｢何でお金取れないの？｣って
考えてる中華食堂なので、論外っていうか
開発の入り口にも立ててないです。

こんなときはSESでやればよろし。
SEもユーザも死ぬが赤字にはならん。

>191
いまどき、やきそばくれといってラーメン出してクレームが来たという事例はねえよ。
そもそも焼きそばとラーメンじゃ使う食材がまったく違うでしょ。
しかも食べちゃえばなくなっちゃう。寿命数分ってとこ。
おまけに食べたものの味がイメージと異なっていたからもう一度作りなおせとは
言わない。
システムは（ハードウエア以外は）結局は同じ食材を使って作っているし、
作った後でもねちねちと作り直しを迫られる。
数ヶ月かけてやきそばをせっかく作って出してもその数ヶ月の間に顧客が期待しているやきそばの味が微妙に変わっていたりして
けちを付けてくる。

>192
えーと、少し知ってる方なら下のような方がわかりやすいか・・・
ユーザからWebやりてぇと言われてWebで作ったら
実は社内のエントリ業務に使うつもりで、こんなん使えるか！
ってしかられるとかね。要するにスケールは違うけど
ユーザと開発者のイメージが違うから作り直し
させられるってことよ。

ちなみに一括契約だと、作り直しはないのよ。
仕様が変更になった分だけ、別契約です。
そう持っていけないのは、わかってるとことわかんないとこの
切り分けが出来てなくて、ユーザと何処まで作るか
合意できてないときでしょ。(つまりSEがアフォ)
それで、
>>｢出来ない｣または｢わかりません｣と言えないため、
>>自分自身意識せずにユーザを騙してしまい、
>>ユーザを巻き込んで共倒れしてしまう。
ことになるんです。

#今と昔を比較すると、昔の方が開発失敗なんか少ないのよ。
#さっきの例でいうとメニューが焼きそばしかなかったからね。

#文の構成ぐちゃぐちゃでｺﾞﾒｿ

おまい、さては↓の社員だろ

カテナの開発手法Lyee その9　【スゲェ！】
http://science.2ch.net/test/read.cgi/infosys/1033655245/

>>187さんの
＞キー入力数回でたちまち不具合も、改良も出来てしまう
＞ソフトウエアにありがたみがないから
そうですね、簡単にソースの修正がきくから安易に仕様変更をする面は
ありますね。
仕様変更って、いえの建築にたとえたら、
壁紙をきちんとはって内装ができたと思ったら、間取りの変更が入って
基礎打ちからやり直しという感じがします。

>>193
＞#今と昔を比較すると、昔の方が開発失敗なんか少ないのよ。
昔の方が時間的に余裕があったからかなぁ。

>>191
> ユーザは、コンピュータシステムわかってないから
> 金出して頼むのよね。
> 出来ないこと、出来ることの判断も言外にSEに
> 依頼してるんです。

勿論、ユーザがコンピュータシステムを理解している必要はありません。
ですが、業務の実情に付いては理解している必要があります。
設計者はユーザ担当者と協力してシステム(業務)分析、システム(業務)設計を行う訳ですから
双方が互いの分野に付いて責任を持って貰わないと困るんです。
まあ、ここら辺りがいい加減なプロジェクトは絶対に失敗しますね。

>>193,196
えっとね、オープン系の技術は技能者の含めて発展途上なんだよね。
ある程度完成された領域にあるメインフレーム系と比べても仕方ないと思います。

まあ、今の時代でも「優秀な技術者」の数は変わらないし成長度合いも変化していないと思います。
ですが、中堅技術者層になると「オープン系は貧弱」であり、中堅技術者を育てる環境は最悪と言えます。
で、相対的に「質の悪い成果物が世に溢れる状況」となっております。

# まあ、そのおかげで私なんかは楽に商売されて頂いております。m(_　_)m

開発ルールを作ったらソフトウェア開発は失敗しない　らしいです

>>198
標準化のことなのかな？

開発ルールを作っても失敗します。
そのルールが陳腐なら、なおさらです。

---------------------------------------------------------------------
　　　　　　　　　　　　　　　　　　　こ　こ　ま　で　読　ん　だ　。
---------------------------------------------------------------------

結論：
出張32 ◆Rb.XJ8VXow はｷｼｮｲ

少数のスーパーSEと、文句言わず
開発ルールを遵守するガテンPGで
成功間違いなし。

おまえのようなソフトウェア小僧に
うちのシステムを任せられるか！

と言われたことがあります。

>>200
でも、ルール作ればそれでokと信じて
ルール作りにハゲんでいます
エライ

おれは、末端のデジドカだ。
上のやつらは、「いついつにリリース」が決まりましたという通達はだすが、
どういうシステムを作成するかというイメージ図や、結合データを作成する
為に必要な情報を提供することはあまりない。
何を作るかというイメージがプロジェクトの中に統一されてない。だから、
仕様変更は、頻繁に発生する。そのくせリリース時期に変更はない。また、
「こういうふうにしたらどうですか？」と未知の問題事項と解決案まで提出
してやってもスケジューリングすらしない。

SIerが客に対して言うべきことを言わないでいると現場に負担がかかって
デスマーチになることぐらいわかっているだろ。
まったく、中間マージンはとってやることやらないSIerは糞だ。

＞どうしてソフトウェア開発は必ず失敗するのか？

・業界がゼネコン体質で元請けが○投げ会社で、付加価値ゼロの○投げリーマンが
　SEと称して給料とっているため

・もしくは出張32のような実は無能で分かっていないくせに知ったかぶりする
　PCオタク上がりの奴が業界にはびこっているため

ここで費やす時間、もったいなくない？

リアルの技術は失敗を糧にして成功をもたらすが、
バーチャルの技術は失敗が失敗を呼び失敗を繰り返す。

人月でもってお金をもらえるから、さっさとやってもいいことは何も無い。
外注の要素が多いと、その外注を受けた側の会社は実際には内部で
複数の仕事をかけもちしていたりするのである。裏バイトをしている
プログラマーもいたりするだろう。
　早くおわらせようとして、新たに人間を投入すると、ますます混乱して
出来たものの品質はぼろぼろになってしまう場合が多い。

うんこ

----------
終了
----------

>>6
的は「える」ものではない。「射る」ものだよ。
日本語は正しく使おうね。(亀レスすまそ)

>>198
> 開発ルールを作ったらソフトウェア開発は失敗しない　らしいです

開発ルールは効率性を犠牲にして安定性を確保する為の手段です。
だから、技術者の質が向上しない限り「失敗しないけど可也高く付いたね♪」ってことなる。

# 出来上がりの品質も要求を満たしているわけじゃなくて「まあここまで管理してこの成果なんだし我慢してね♪」って
# ことであり、顧客からの突っ込みをガードする防波堤の機能でしかありません。

所詮は人の作るもの
失敗があるのは当然のこと
世のかなに完璧・完全というものはありえない

なにが成功で、なにが失敗なのか？

・利益が予定通り／予定以上にでたこと
・（なんとか）納期に間に合ったこと
・システム稼動後に大きな障害がでなかったこと

デスマーチであったか否かは成功／失敗の尺度じゃない。

実態としては、マッキントッシュの開発も、
スペースシャトルの打ち上げもデスマーチ状態。
でも、やっている本人たちがそれをどう受け止めるかどうかは別。

どっかの会社のSCMとかCRMとかWebアプリとかを
開発するなんていうSIのプロジェクト、
こういったプロジェクトに関わるひとの大部分にとってみると、
”残業／休日出勤が如何に少なかったか？”
”残業代等の報酬がきちんと支払われたか？”
ということが、成功、失敗の基準だったりする。

プロジェクトの末端で働いている限りにおいては、
常にソフトウエアは失敗していることになる、かもしれない。

>>212
>だから、技術者の質が向上しない限り「失敗しないけど可也高く付いたね♪」ってことなる。

つまり、出張32みたいな奴を使うと、こんな言い訳される訳だ（藁

ソフトウェアの完成度は非常に高いことを要求される。なぜなら
それは人の介在なしで高速に動作する前提だし、計算機の高速性
により繰り返しが多数回なされる。いろいろな場合が短い期間の
間に実行される。
　だから、大学の期末試験のように、100点満点のうち６０点で
合格というようなわけにはいかない。
　非常にレアなケースに対する事前の考察が抜けていたり、
試験なされていない場合には、プログラムコードには水雷が埋めて
あるようなものだ。そこの個所にたまたま到達して、初めて
バグが生じたりする。あと、グローバルな変数を通じて、とおく
離れたコードが相互に関係を持ってしまうということが、通常の
機械などと違う難しさを生じる原因でもある。

>>216
その通りだが、「非常にレアなケース」をシステムに盛り込むか否かは慎重に検討すべき事柄である。
つまりは、「全てをシステム化」ではなく「予算・規模に見合った選択的システム化」を行っているのが
現実です。
但し、「非常にレアなケースの扱い」を決定されないまま開発すると後で問題に発展する。

ところでさ、なんでみんな出張32相手するの？
レス返さないで放置でいいじゃん

>>219
オレはお前の様な情けない意見の奴を無視したい（ｗ

219 名前：非決定性名無しさん ：02/11/26 15:07
>>219
オレはお前の様な情けない意見の奴を無視したい（ｗ


ワケワカラン．．．．

ソフトウエアであることが、そもそも困難の大きな比重を占めてるような気がします。
コンピュータって、建築の比喩が多いように思えるので、ビルの例を出すけど、ビルのオーナーが、３階建てのビルを計画して、
基礎工事の途中でいきなり２０階建てにしたいとか、普通言い出さないよね。IT業界だと、そういう変更が多いんじゃないかって思う。
建設もプログラミングも普通は、顧客には理解できないテクノロジーだけど、土建って、丸投げはあっても、無茶なデスマーチってないよね。
具体的な建設物と違って、どこを変えることが、根本的な仕様変更で、どこを変えることが、些末な仕様変更なのか切り分けが出来てないんじゃないかって思う。

バグ、一件につきって上にあったけど、例えば、ビルが崩壊するほどのミスと、釘の頭がちょっと出たミスがあって、同じミスだけど、重要さとしては違うよね。
でも、バグ一件は一件みたいな感じで、重要度とかダメージとのトレードオフとかが余り出来てないように感じる。
目に見えないモノだから、見通したり、全体の構造を把握するのが難しいのだろうなって門外漢ながら思ってしまう。

>>218
激しく狂おしく同意

>>222
同意、同意、同意。

>>218
２ちゃんねるは来場者も多いし、出張32がどんな人間だか
知らないで書き込んでしまうケースも多いんだろう。
まったくアリ地獄みたいだよね、出張32って。

　　.|　 ｛　　´　　 ‐-　....__　　　　__...　-‐　　　`　　　｝　.|
　　.|　　〉,,・^'' - .,, 　 　 　~ 　i　~　　　　__,,.- ＾`・､.〈　　|
./￣|　 /,／~ヽ､　　`'' ‐--‐ ,.| ､‐-‐'' "~　　 _ノ~＼,ヽ　|￣ヽ
| （` |　/ ヽ,,_____`‐-､_､..,,___ﾉ八ヽ___,,.._-‐_'"´___,, ノ ヽ .|'´） |
|　｝.| ./'　　 ＼二二・二../ ヽ　 / ヽ､二・二二／　　'ヽ | ｛　|
.| //| .|　　　　　　　　　 ／　|　 |.　＼　　　　　　　　　|　|ヽヽ|
.| .|　| .|　　　　　　　 ／　 　 |　 |. 　　 ＼　　　　　　　|　|　| .|
｜ヽ.|　|　　　　　　/　　　　 .|　 |. 　　　　ヽ　　　　　 .|　.|./ .|
　| 　.|　|　　　　　/　　　　　 |　 |　 　 　 　 ヽ　　　　 |　 |　/ 　 ／￣￣￣￣￣￣￣￣￣
　ヽ　.|　|　　　　/　　　　 　 .|　 |　　　　　　 ヽ　　　 |　 |　/　　|　　要件を
　　.ヽ.|　| 　 　/　　　　　'二〈___〉二` 　 　 　 ヽ 　　|　 |./　　＜
　　　　|　|　　　　　　　　　　`-;-′　　　　　　　　　|　 |　　　　 |　　聞こうか…
　　 　　iヽ|.　　　　　　,,... -‐"`‐"`'‐- ､、　　　　　|／i　　 　 　 ＼＿＿＿＿＿＿＿＿＿
　　　　 |　 ヽ　　　　 /...---‐‐‐‐‐----.ヽ　　　　/　 .|
　　 　　|　　 ヽ.　　　　,, -‐ ''"~ ~"'' ‐- ､　　　　/　　 |

>>225さん
　出張32を黙らせて下さい。





　殺しても構いません。

>>211
厨房は氏ね。

前と同じに作ったのに「なんで前と同じにしなかったの？」といわれて仕様変更が
起きてしまうのは失敗でつか？

>>228
本当に同じなの？

↑微妙に違う。角度とか。

１．納期最優先でとりあえず必要最小限の機能、ユーザーインターフェイスを中心に作成。
２．「バグがある」＆「使い勝手が悪い」ことを承知のうえで納期通り納品。
３．納品後、下っ端１名は客先の現場にて運用を見守る（人質）
４．残りのＰＧ要員で完成品を作成。バージョンアップと言いながら上書き。
５．やっと客の運用も軌道にのったと思ったところへ、意味不明のバグ出現。
　　「あああ、こういうケースもあるのか」と客の運用方式をここで初めて知る。
６．ＰＧに関する客の改善要望を「それはできないです」と断っていたが、
　　客が直接上司に改善要望を話したため上司にバレ、ＰＧ修正＆機能追加。
７．・・・とかやっているうちに次の納期が迫る。

漏れの場合、客からの苦情の電話がかかってこなくなったら、
そのプロジェクトは終了であり成功です。
みなさんと「成功」の概念が少し違うと思わざるおえません。

作るものの技量があまり選別されていないからだ。
現実の物理的な存在物を作る場合は、失敗やヘマをすれば、物が壊れたり
爆発したり、人が死傷したりするが、そういう怖れがあまりないような種類の
ソフトで、しかも後で直せると思うと、どうしたってバグとか不具合とか
設計の見積もりの技量に関する基準が甘くなる。人間の側も精神に油断や
隙が出るし、経営者も同様だ。しかも、人月でお金をとっていたりすると、
ちっともものごとが良くならない。バグがでたら罰金や返金ではなくて
サポート料、アップグレード需要が生じるのでは、なんにも問題を未然に
防ごうという欲望が湧かないはずだ。
　本当のプロを育てるのには、１件バグを入れていたのが発覚したら、
給料を３％カット。納期が遅れたら免職。バグが月換算で１０個あるような
設計をしたら、銃殺。これぐらい厳しいプロの世界だったら、覚悟を決めて
とりかかるだろうし、中卒のくるくるパーを沢山人数あつめて人かしという
ようなこともあるまし。ひとつにはこれまでずーっとソフト作りの人間は
供給が需要に追いつかなかったために、人間の質については出鱈目がまかり
通ってきたのが大きいのだよ。

>>232
> 作るものの技量があまり選別されていないからだ。

いや、全くおっしゃる通りなんだけどね。
それを言ってしまうと経験３年程度以下は全く使えなくなってしまう。
それじゃ人は育たない。

ただ、キーマンだけは最低でも揃えて置きたいのが実情かと．．．
キーマンが不足すると中途工程で破綻しクローザー頼みになってしまう。
そうなると、予算も無いからクローザーも必要最小限度の繕いしか出来ない。

>本当のプロを育てるのには、１件バグを入れていたのが発覚したら、
>給料を３％カット。納期が遅れたら免職。バグが月換算で１０個あるような
>設計をしたら、銃殺。

銃殺ﾜﾗﾀ。そして禿しく同意。

>234
そんな会社、社員数０だろ。みんな銃殺だ。

（＾＾）

今から失敗スレに書くのもなんですが・・・。


私はSEではないのですが、こんど従業員400人以上いる事業所の文書管理シス
テムを立ち上げる仕事を上司から言い渡されています。

システムはISO9001に準拠していなくてはなりません。
社内規定のみならず、規定のもとで作成される全ての品質文書や品質記録を作
成から授受管理まで、全て電子化しろとのお達しです。
年間２万ファイルぐらいの文書ファイルを扱う事になります。

で！その予算がサーバ用PC1台（Pen4 1.8GHz,HDD 256GB）とソフト代20万円。
※クライアントPCは200台ぐらいすでにあります。
担当者はわたし一人！
最初に書いたように本業はSEではなくCSです。
定時間内は電話対応やクレーム品の調査・解析などで全く時間は無く、この件
に使える時間は週に１時間程度。
PC関連の経験は高校生の時にコンピュータ部にいた事と、趣味でLinuxをいじ
ってはいますが、インストしてWebサーバ立てる程度がやっとです。
あと、VBとPerlをちょこっと出来る程度です。

これで、６月までに何とかしなくてはなりません。
どう思います？

>>237
受ける受けないは貴方次第。（私なら笑って「自分で作れ！」と言うけどね♪

# ソフト代って購入分予算だよね？
# 後は全て、貴方の成果物ってことだよね。

>>238
> # ソフト代って購入分予算だよね？
> # 後は全て、貴方の成果物ってことだよね。

そう言う事です。

上司はPC１台と適当な文書管理ソフト（グループウェアみたいな）ものがあれ
ばすぐに出来ると思っているようですが、20万円程度の汎用ソフトでISO9001
準拠の完全電子化システムが出来るとは到底思えない。
自作も考えましたが、スキルもさることながら、時間が全く無いので途方に暮
れています・・・。

ここのSEさん達は百戦錬磨な方々もいらっしゃるでしょうから、実際のところ
、このような状況で成功するにはどのような方策があるかをお教え願いたい。

まあ、わたしがバリバリの天才プログラマなら可能なのかもしれませんが、今
さらそうもなりませんので・・・。

>239
グループウエアのソフトを導入するとしても予算が足りませんね。
クライアント２００台×ライセンス料＝最低１００万は必要です。

>>237
休日でればいいだけじゃないの

>>241
休日出勤も残業も経費ですよね。
予算は最初に書いた２０万円のみです。
それが現在の超効率主義の製造業（わたしは製造業です）の実情です。
実際にはサービス残業などをしている人もいますが、それが発覚すれば
役職者は労働基準監督署などから処分されますので、そのような存在自
体を自分の近くに置きたくありません。

そのような状況でもこの件を実現する方法こそが必要なんですけどね。

まあ、あくまで一般的概念の範囲ではどのようなご意見が伺えるのかを
確認してみたかったのですが、難しい感じですね。

>>237
> 上司はPC１台と適当な文書管理ソフト（グループウェアみたいな）ものがあれ
> ばすぐに出来ると思っているようですが、20万円程度の汎用ソフトでISO9001
> 準拠の完全電子化システムが出来るとは到底思えない。

ここが大事なところなんじゃないかな。
到底思えない理由があると思うのだけど、
その根拠と、可能だと思われる予算と根拠を
柔らかい言葉で示してやれば納得するしかないのでは？
# 後はそれをどうどうとね。

後は転職くらいかな。
世の中には「無理」と「無理かもしれない」状況があると思うけど、
文書管理システムの仕様にもよるだろうけど。
上司の要求を満たすには明らかに「無理」なんだよね？

>本当のプロを育てるのには、１件バグを入れていたのが発覚したら、
>給料を３％カット。納期が遅れたら免職。バグが月換算で１０個あるような
>設計をしたら、銃殺。

バグの定義で大揉め、ってな感じ

>237
出入りのＳＩ会社の営業がいるならば、システムの見積もりださせて
上司と貴方と一緒に説明を聞くというのはいかがですか？
いかに無理な話かを他人から言われれば上司も納得するかもしれません。

>>237

某ＳＩ業者のもので、比較的大手の相手ばかりしているので
ここまで、無茶な話がくることはないのですが、
これほど、ユーザー部門が開発に関して予算感がずれているとは
知りませんでした。
プラットフォームによるとも思われますが、要件分析だけで
上司の方の想定予算をかなり超えそうです。
引き受けないことが身のためと思いますが、
立場上そうもいかなければ、最初に無理な注文だと言うことは
宣言しておくことです。
開発経験のある者なら誰でも無理だという案件です。

237って、転職板で見たような。見なかったような・・

みなさん、イロイロとご意見・ご指導ありがとうございます。
私はそもそも使う側の人間なので、出来ることなら立ち上げたいの
ですが（使う立場として）、理想と現実のギャップは大きいですね・・・。
もう少し慎重に検討してから方向性を決めたいと思います。

>>247
別人です。

>>248
結局、Ｅｘｃｅｌでそれなりのフォーマットのシート作って、管理フローを
整理するだけで終わるような気がふと。

>248さん
249さんの言う通りにも感じられます。
サービスでAccessでもからめてあげたら？

ＮＴＴと郵政公社
http://www.asahi.com/business/column/K2003022500629.html

ＮＴＴの担当者に家に来てもらう必要が出た。以下は電話でのＮＴＴとのやりとりである。

「今週末に我が家に来て回線の状況を見てもらえますか」「こちらはウイークデーしかやっていません」
「えっ、では今週金曜日の１８時に」「いえ就業時間中でないと困るんです。１０時から５時の間にお願いします」
「それは仕事のある身には厳しいですね。昼休みに職場から家に戻ります。午後１時に来て下さい」
「２時にしてもらえませんか。食事を終えてから出ますので」「もしかして昼食時間は働かない規則ですか」
「実はそうなんです。それから当日ですが車で行きますので早く着いてしまうかもしれませんから家には１時３０分ごろには居て下さい」

サービス業を生業としながら今時こんな風にやっている企業も珍しい。そう思っていたらつい先日、
電話回線の事業者間接続料金値上げを総務省が検討しているような記事を紙面で見た。

冗談ではない。通信コスト低減のためには通信事業者間の競争は不可欠で、何よりも新電電の競争力は担保しなければならない。
なすべきはＮＴＴ経営陣が労働組合を巻き込んで一層の合理化、効率化に取り組むことである。
民間企業の多くは合理化の上で賃下げもやむなしという状況にある。

遅ればせながら通信事業を追いかけ郵政事業が４月から郵政公社に衣替えとなる。
民間から総裁が起用され、客の視点による郵便局窓口の改革を実現しようとする取り組みもなされている。
だが国から独立して公社となっても競争状態がなければサービス、価格はいずれ硬直したものとなる。

民営化であってもＮＴＴ回線事業のようなことになる。要は市場における価格、品質、サービスの競争を通してしか
事業は健全化しないということである。役所仕事を考えてみればよく分かる。
郵政３事業が真の意味での民営化を必要とするゆえんである。（啄木鳥）

（02/ 25 ）

>>249
正解！
結局、管理フローと運用手順が作成されれば完成かと♪

（＾＾）

　　　　 || 　　　　　　　　　　　｜｜
　　　　　∧||∧ 　　　　　　　　　｜｜
　　　　（ / ⌒ヽ 　　　　　　∧||∧ 　　　　　　　　　｜｜
　　　　（ / ⌒ヽ
　　　　　| | 　　| 　　　　　　　
　　　　　∪ / ﾉ
　　　　　 | ｜|
　　　　　 ∪∪
日本ロジテムの子会社せいも素で過労による自殺者が出たんだってね。
http://www.samos.co.jp
http://society.2ch.net/test/read.cgi/traf/1046749189/l50
http://tmp.2ch.net/test/read.cgi/company/1046775680/l50

出張３２氏の発言を見たくない方は「かちゅ〜しゃ」のＮＧワードに
以下の行を追加しましょう。

</b>◆Rb.XJ8VXow <b></b>

>>1
開発途中で失踪したり、昼夜逆転したり
無断欠勤する香具師がいるから。
また、机の中にガンダムのフィギュアを、
溜め込んでいるリーダーがいるから。

　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）

あぼーん

みいそのSEならプロジェクト失敗多いね
開発したシステムが実稼動までいかないとか。

早稲田でみいそトラブってたな（ﾜﾗ

あぼーん

>>1
ゴルゴムの仕業だ！

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

客にデタラメな進捗報告をする現場に遭遇した。
これは間違いなく失敗するプロジェクトだと確信した。

あぼーん

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

ゲイツ様の飯の種がなくなるから。

２ちゃんで話題になった「みーほ」女子○学生 B86 W57 H88（○5歳）
がこのHP内のギャラリーで何を考えているんだか、衝撃的なセルフのヌードを晒してます！！
削除される前に早めに見ておいた方がいいとおもいます！マジでやば過ぎ！！

ttp://www.neeez.com/~miho-room/

不治痛の痛い子会社であるFFC、FFCシステムズが糞ソフト会社だから（ﾌﾟ

坊やだからさ（ｗ

まとも設計とお見積もりが出来ないからです。

舵取り役がいないか、逆に多すぎるから。

営業がバカだから。

ﾄﾗﾌﾞﾙが無いことを前提に
見積もり立ててるからだろ。

>>270
ある意味正解。
ボジョレ・ヌーボーを解禁瞬間から飲んでるようなコン猿が
仕切ってるからなぁ。ヽ（´ー｀）ノ

>>1が救いようのないｳﾞｧｶだから（ｗ

やりすぎるから。希望的観測のみで動くから

何人月の案件ということで、仕事をいただき。
最初に行うのが作業規模の調査で、作業規模が多くても、
その枠内（最初の人月）に無理矢理押し込む。
じゃあ、最初の何人月の作業規模は誰が決めたの？
予算で自動的に決定なのか？

企画提案時には予算枠だけは告げられている
　↓
受注したいが為に希望的観測のスケジュールを立てる
　↓
詳細な機能仕様が確定する
　↓
ムリヤリ押し込められる
　↓
(´Д` )

保守age

性交するまで続ければ失敗など存在しない。

ていうか本当に本気で一度も成功ＰＪに参画したことない人っているの？
そりゃ方法論を考察するよりお祓いでもしてもらった方が…

成功者：工程オーバーした分を二次開発として新たに金を取れる人。

敗北者：工程オーバーした分を抱え込んで金を浪費する人

それは日立ソフトの某ＧＬに詳しく聞いてください（ｗ

日立ホモソフトね

失敗談の宝庫
日立ソフト

　　　　　　　　　　　　 ,,----、,,,,,,,,,､､
　 ;''　"''―-､γ　　 / ,,-‐―、ヽヽヽヽ
　 |　　　　　 ヽυ　〔/　 　 　））））ヾヽヽ 　 　
　ヽ　　　　.,,,,､､）　 /.,,,,、､　,ヽξ＼Ξ/　.
　Ν　　　　-== ＼/ ==/　 .,==- 　 レi!　
　(6ヽ...........''''' ） (´ ）,(_,､ﾉ（ "",,ﾉ:: 6） 　　
　|::::::::::::::::::::::::::::::::::３ε 　＾ﾝ ...::::: |/ 　　
/ 〔::::::::::::::::::::::::::::::::ヽ::::. .::.. ::...::::::/ λ 　　　　　
　　　　::::::::::::::::::::::::::）::::::::::::::／/ .　λ
　　　　　　　＿＿ノ　￣|￣　　　 　　/~~￣⌒＼

名言

ソフトウェアは作るものではない。
使うものだ！

録音◆Rb.XJ8VXowも新しい攻撃方法を憶えてきたからな。。

最近、録音を攻撃すると
「それじゃ、録音と変わりないなw」とか
「録音なみだな、お前」とかいう反撃は
みんな録音の自演。自分の自演とばれないように
録音自身をバカにしたような論調で
実は録音がむかついたヤツを攻撃してる。
最初は別人かと思ったけど録音がいるところで必ず
同じパターンが続くんでわかってきた。

＞＞1
たしかに。
うちもそうだ。
設計者がダサいのが原因。