X



昔のITってどんなだったの?
■ このスレッドは過去ログ倉庫に格納されています
0001仕様書無しさん
垢版 |
2010/07/17(土) 02:13:31
技術から言えば1/5位のレベルで今よりも単価が3倍位高かったみたいなんだけど本当?

10年前くらいらしいけど、HTML組めるレヴェルで500kとか貰えたって・・・
0003仕様書無しさん
垢版 |
2010/07/17(土) 05:25:00
3年前でも、Javaかけるだけで50万くらいもらえたよ?
0004仕様書無しさん
垢版 |
2010/07/17(土) 07:07:12
15年くらい前だと、ただ単にHTMLを使える人がほとんどいなかっただけ。
ていうかHTMLはプログラミング言語じゃないんだから組めるとかふつう言わない。
0005仕様書無しさん
垢版 |
2010/07/17(土) 07:07:31
2001年のJavaOneにも参加して、JAVAの仕事も結構やってるが未だに20万だな
0006仕様書無しさん
垢版 |
2010/07/17(土) 07:19:31
>>1
技術は昔の人のほうがはるかに高い。
なにせ資料はまったくなく、自動化も簡略化もサポートも少ない。
となれば、コンピューターのことをちゃんと理解してないと動かすことすらままならん。
オタクな職業だったから、絶対数が少なく単価は高かった。
今のように誰でも1,2週間でプログラマを名乗れる時代ではなかった。
少なくとも新人教育にはマジで半年はかかった。
0008仕様書無しさん
垢版 |
2010/07/17(土) 08:30:13
>>6
技術と技能の違いも解ってなさそうな人に長文書かれても…。
0011仕様書無しさん
垢版 |
2010/07/17(土) 11:23:35
ドラム缶サイズのハードディスクで
コンパイル1回するのに計画書が必要な時代ですね
0012仕様書無しさん
垢版 |
2010/07/17(土) 12:00:19
テープやカードに穴開けてた時代だろ?
人が読んで解析したりな。
0013仕様書無しさん
垢版 |
2010/07/17(土) 14:08:36
>>8
このスレの流れからその文章を書いた意図がわかりません。
KYですか?
6じゃありません。
0014仕様書無しさん
垢版 |
2010/07/18(日) 09:10:53
>>10
そだな。でも15年前にしたら急激に状況は異なるぞ。

>>13
だって>>8は専門卒のバカだもん。
0015仕様書無しさん
垢版 |
2010/07/18(日) 12:04:44
>>14
Fラン乙
0017仕様書無しさん
垢版 |
2010/07/18(日) 12:23:08
何故高卒じゃなく専卒を持ってきた
0018仕様書無しさん
垢版 |
2010/07/18(日) 13:02:32
いい大人がお子様の煽りに簡単に揺すぶられてどうするよ。
本気でやってきた技術者なら、この20年やら30年やらで、
後輩に覚えていてほしいこととか、自分らの反省とか、色々あるだろ…
001918
垢版 |
2010/07/18(日) 13:12:34
いわゆるInterne breakの頃(90年代中盤)
HTML組むだけで=Web pageのデザインをするだけで月100万の仕事は存在しました。
今はどうなんですか?ツールの充実で納期は5倍ぐらい短くなったかもしれませんが、
会社としては人月あたり数十万以上入らないと経営が成り立たないですよね。

デザイン=狭義の見てくれ(表現)もエンジニアがやることがあって失敗作続出でした。

当時は標準ははっきりしないし、ユーザーが使いやすいデザイン規範も決まらないので、
HTMLソースもハチャメチャなものもありましたね。これを技術的なレベルの低さとも解釈できるでしょう。

でもどの時代でも、はっきりしない分野、新しくて方法論が定まらない分野ではハチャメチャな
ものがありますよね。
002018
垢版 |
2010/07/18(日) 13:24:38
昔のITは、当たり前だけどユーザーが使うインターフェースと、アプリケーション本来の機能を一緒にして、
時にはハードも組で売ってました。

最初は1980年代にハードが切り離されて「オープンシステム」とか呼ばれるようになって、
インターネットの興隆後にインタフェース(Web)が切り離されるようになりました。

今、データの保存(あるいや永続化)にはデータベースを使うのが当たり前ですよね。
実はこれは、インターネットの興隆前はそんなに当たり前ではありませんでした。
自前の保存システムや永続化システムが、システムに埋め込まれて売られることが
非常に多かったのです。
脆弱だし、性能もよくないはずですが、「アプリケーションに特化してある」と言い訳していました。

こうしたコンポーネントも組になって売られている分、今との比較では、お金も納期もかかってたはずです。
0021仕様書無しさん
垢版 |
2010/07/18(日) 13:26:16
当時Internet breakと平行してホットだったのは「オブジェクト指向」でしょう。

世の中の誤解を良いことに、継承だけで(encapsulationなしで)オブジェクト指向を標榜して、
10倍のお金をもらうこともあり得た時代でした。
今もAjaxとかWeb2.0とかを標榜してるが実は…とかいうのありませんか?

オブジェクト指向で開発するから、今回はちょっとお金多く貰うけど、
次回や修正の際は短納期で安くできるよ、とかいう営業トークをしたようです。
実際はそうはなりませんでした。

今そういう営業トークは誰も信じませんが、実はオブジェクト指向が浸透した今は、
多方面でじわじわそういう効果が出てると思います。劇的でないにしろ。
0022仕様書無しさん
垢版 |
2010/07/18(日) 13:29:25
昔=無計画に設計し、人海戦術でこなす。大金が動いていたのでこれでもなんとかなる。
今=計画的に設計し、既存のものを最大限活用し、少人数低コストで実現することを最大目標とする。


まあ今でも人海戦術大好きな連中が化石のようにはびこってるけどねw
将来を棒に振りたくなきゃ、そんなとこに参加しないこった。
0023仕様書無しさん
垢版 |
2010/07/18(日) 13:34:47
>>22
これはおかしい。昔はシステムが高かったからそんな無計画になんてできるわけがない。
そもそも人海戦術というが、昔はそんなにプログラマなんて人いなかったから人海戦術は物理的に無理だし。
そもそも、昔の人はそういう環境しかなかったのだから。gotoでしか分岐できなかったんだから。
そういった時代を生きた人の中で優秀な人が改良改良を加えて今の開発環境ができた。
というプロセスを忘れてはならない。今の人がある日突然gotoをなくしてJavaやOOを開発したわけではないんだから。
おっさんたちの中の優秀な奴らが、修正を加えた構成気を自分たちの功績のように語るのは問題あるぞ。

今は、そういった過去の問題点への改良のおかげで、高度な開発環境を手にできてレベルが低くても開発できるよう
なったおかげでプログラマがたくさんできた。同時にコストも下がった。
002418
垢版 |
2010/07/18(日) 13:36:34
>>20
RDBの流行は、インターネットの興隆と関係ないという意見も多いかも。
直接的には、性能と安定性の向上のせいかも。

「インター」に限らずネットワークの機能向上は、
システム中のコンポーネントを分離あるいは分散させるという意味で、
RDBの一般化についても重要な要素だったでしょう。

ところが90年代、ネットワークハードウエア、あるいはコンポーネントの分散化、並列化の
技術者は極端に少なく、あるいはこれを専門の職、あるいは独立した仕事と考えてお金を
払う思想は全くありませんでした。できる人が便利屋的にひっぱりだされるか、
組織によっては「誰もそれの知識がない」という状態でした。
002518
垢版 |
2010/07/18(日) 13:53:42
今と大きく意識が違う点として、ハードの価格というのもあるでしょう。

ハードディスクなんて、まずは利用が考えられない時代がありました。
1980年代: オフコンで中華なべぐらいの50KBのディスクが数百万
1990年代はじめ:PCにHDDがつくけどPCのシステムの仕事はなく、
ワークステーションでも数十メガあたり百万。
私の場合では、容量を気にせずハードディスクを使えたのは1990年代中盤からです。

ハードディスクに限らず、メモリ、ディスプレイ、なんでも同じです。

当時は、こうした資源をケチケチ使う技術がいろいろありました。資源をケチることは、
ハードを含めたシステムの全体的な価格を抑えることができるので、非常に重要視されました。
設計の非常に早い段階から、ハードの制約(どうケチるか)が関係者の頭に必ずめぐってました。
もちろん、これは出来上がりの美しさを歪めることが多かったです。でもお金には代えられない。

逆に、90年代中盤ハードの価格が下がりだしてから、ケチケチしない「富豪プログラミング」
という思想が出ました。ソフトウエア工学的に正しいし、人に優しいし、今はこちらが当たり前で
死語ですよね。
0026仕様書無しさん
垢版 |
2010/07/18(日) 13:56:30
>>23
設計って書いてあるだろ。
君の言ってるのは、全て実装の話だ。
0027仕様書無しさん
垢版 |
2010/07/18(日) 14:17:34
一時期メモリ全然無かったからCPU依存のコードがもてはやされたっけ。
今じゃDBインストールするのに云ギガメモリーとか普通だもんな。
果ては分散すりゃいいじゃん的風潮。マンプス系の工夫フェチが減った。

コンパイル後のアセンブラを意識して、スーパースカラーを誘うようにC言語書いたり。
クロック数稼ぐためにループ割とかやったら可読性最悪だったり。(IntelC++でメイクすると上手く配置してくれそうだけど)
SSEとかハード的に凄い命令がやってきて、俺の最下層ループのフーリエどうよって自慢しても、後でオナニーにされるだけだし。

ノスタルジーに浸るほど、時代に振り回され報われない生涯をおくってきた自身を嘆くばかり。
0028仕様書無しさん
垢版 |
2010/07/18(日) 14:24:33
>>26
設計者と実装者がイコールであった時代になにを言うんだ。
いや正確には設計者は実装のベテランが担当した時代だ。
今のように新卒SEなんて言葉がなかった時代だぞ。
0029仕様書無しさん
垢版 |
2010/07/18(日) 14:30:13
>>25
そんなことは無い。
1970年代後半、PC-8001ですら32kB RAM載ってた。俺のは64kBに拡張して
CP/M動かしてた。1980年代初頭にはPC-9800シリーズ用の5inch HDDが
登場して、これですら最初から10MB有った。
1990年なんて既に64bit RISC WSが発表に成って、ウチの自宅でまだ稼働
してるが、最初から540MB HDDが載ってた。それ以前(1980年代)に使ってた
R3000マシンには、2GBのHDDを増設してた。その当時既にGB超えてたよ。

そんなけ有っても、速度の面からケチってCのような高級言語使わず、
MIPS RISC命令をマシン語で組んでたけど。CISCと違って、MIPS命令は
マシン語で組み易かったし。
0030仕様書無しさん
垢版 |
2010/07/18(日) 14:34:10
>>28
新卒SEが設計してるところってあるの?
新卒SEはSEって言う名前だけど連絡係なところはいくつか知ってるけど。
0031仕様書無しさん
垢版 |
2010/07/18(日) 14:36:41
設計者じゃなくて設計の話なんだが。


設計者の話が出たので、話としては丁度いいが、
実装者に設計やらすとか、無計画な設計の典型だよね。
0032仕様書無しさん
垢版 |
2010/07/18(日) 14:44:44
>>22
昔=計画的に設計し、計画と実際のずれが判明した後でも人海戦術でこなす。
大金が動いていたのでこれでもなんとかなる。
今=無計画に設計し、計画と実際のずれが判明したら再度設計しなおす。
少人数低コストで実現することを最大目標とする。
0033仕様書無しさん
垢版 |
2010/07/18(日) 14:48:46
MVC分離とか疎結合とか、概念すらない時代の設計の
どこが計画的だったのかと
0034仕様書無しさん
垢版 |
2010/07/18(日) 14:54:58
あ、わかった。
実装者=設計者って話になるぐらい、昔は設計の段階で
そのままコードに出来るぐらい詳細に書いちまってた。
それって、単なるコーディング指示書作成プロセスってやつで、
本来設計と呼ぶべきじゃないんだが、昔の言い方では設計と呼ばれてた。

俺の言う無計画計画ってのはそういうこと。
計画的に詳細設計(=事実上のコーディング)を行うことは、
計画的な設計とは違う。
0035仕様書無しさん
垢版 |
2010/07/18(日) 14:55:09
組み込みでポリモーフィズムなんて言ったら親方にぶん殴られるけど
0036仕様書無しさん
垢版 |
2010/07/18(日) 15:06:40
今から10年後同じようにお前らも言われるのにw
0037仕様書無しさん
垢版 |
2010/07/18(日) 15:11:01
>>34
いつの世も・・・。

社長が嫌いな色、好きな色ところから、すでに決定事項が決まっており、その後、新インターフェースデザインの会議に入る。
意思決定権を持つものがJavaの勉強をしたから開発言語はどんな状況でもJavaで対応することが決定事項として決まっており、その後、システムの設計に入る。

こんなもんですが?
0039仕様書無しさん
垢版 |
2010/07/18(日) 15:57:32
後で一意のポインタで実行するって話だから、キャストかな
0040仕様書無しさん
垢版 |
2010/07/18(日) 17:13:40
インジェクションによるファサードを実現するためのランタイムインプリメンテイションだろ
0042仕様書無しさん
垢版 |
2010/07/18(日) 20:58:01
>>30
NTTデータ
0043仕様書無しさん
垢版 |
2010/07/18(日) 21:42:51
32Mのメモリー買う予算が無いからプログラマー3人を一ヶ月投入して最適化したりしてた。

最近の若者に言っても全く信じてくれないが
0044仕様書無しさん
垢版 |
2010/07/18(日) 21:49:29
未だに10KのRAMでがんがってる
0045仕様書無しさん
垢版 |
2010/07/18(日) 21:50:28
256KBのメモリーが数万円の時代は、1日掛けてコード量を10バイト減らしてグッジョブな状態だったな。

メガじゃないぞ、キロだからな。
0046仕様書無しさん
垢版 |
2010/07/18(日) 23:13:47
あの時代はあの時代で求められるものがあった。
今の時代は今の時代で求められるものがある。
求められるものが違うけど、その時代を生きる人間には、自分の時代が一番つらいと感じるものさ・・・。

今の時代にとりあえず求められるもの「おまえの仕事量は増やすが、給料を減らすの了承しろ」以上。
まぁ未来が見えないというのはつらいよね。
少なくとも昔は、こんな時代が来るとは思ってなかったもん・・・。(;_;)
0047仕様書無しさん
垢版 |
2010/07/19(月) 01:57:58
仕事は物理的に増やしようがない。
それなのに増やせと言われる。
寝るなと言っているのと同義だ。
給料減らすって言われるのはまだ親切だなw
0048仕様書無しさん
垢版 |
2010/07/19(月) 05:10:14
今フレームワークになっているものを、昔はアドホックな方法で実装していた。
ホリエモンの会社も、初期は今でいうajaxでやっているようなインタラクティブなページを作るという評判で大きくなった。
0049仕様書無しさん
垢版 |
2010/07/19(月) 08:43:09
組込みに移って6年、もう業務系には付いていけないかも
0050仕様書無しさん
垢版 |
2010/07/19(月) 10:55:29
昔からのやり方しか知らない人が多いのか、フレームワーク上に無理矢理
昔ながらの方法で設計を乗せてるプロジェクトは多いよね。
フレームワークとかみ合わなくて、昔ながらの方法からさらに手間が倍掛かるだけだっちゅうの。
0051仕様書無しさん
垢版 |
2010/07/19(月) 11:15:12
短納期だと、フレームワークの勉強してる暇が無いからねぇ。
0052仕様書無しさん
垢版 |
2010/07/19(月) 11:25:59
センスの問題なんだよな。

大局的な設計が出来ないというか、最初から全部詳細に決めてしまわないと
全体を掌握できない人って居るわあ。
フレームワークもそのごく一部に過ぎないけど、現代の設計技法ってのは、
アリモノを最大限に利用して、作り物を最小限に減らそうってことだからな。

アリモノ使って上手く行かない場合には、どちらかになんらかの論理的な矛盾
があるはず!と考えて、論理的に上手い設計にするにはどうしたらいいのか?
を常に考える能力が要求されてくる。
0053仕様書無しさん
垢版 |
2010/07/19(月) 11:36:40
フレームワーク使って開発進めてたら、途中でフレームワークから外れた要求が出てきたとかはよくあること。
0054仕様書無しさん
垢版 |
2010/07/19(月) 11:56:04
フレームワークなんてのは、システムの物理設計の塊という側面も持っている。
当然、論理的設計というものから、遠くかけ離れた部分も多い。
だから、正しい論理設計を満たせないようなことがあると、
フレームワーク側が頑張って論理的に対応するというのが本来あるべき姿だ。

フレームワーク様が真ん中にふんぞり返っていて、「さあお前ら使え」
みたいなとこは駄目だ。
「基盤チーム」みたいなのが権力強いようなのは、糞プロジェクト認定。



ただし、正しい論理設計ってのは、どこにも解が存在しない。
説得力のみが命だ。
「コレが正しい論理設計なのだ」と言える程の設計が出来ないから、
というのが、そういうのが蔓延る諸悪の根源なんだけどね。
0055仕様書無しさん
垢版 |
2010/07/19(月) 18:03:38
ずいぶん昔居た会社から、ジャストシステムの創業者・元経営者の浮川夫妻が、
ソフト開発を請け負っていて、当時自社ブランドと、日本NCR向けOEM販売して
いた8086とMSDOSを搭載したオフィスPC用に、日本語ワープロを開発していた
らしい。

その後、ジャストから発売された一太郎の原型になったとか。

今なら、ソース持ち出しとかNGだし、安い賃金で個人のノウハウを吐き
出させられて使い捨て。
0056仕様書無しさん
垢版 |
2010/07/19(月) 19:29:58
原型つのは、概要設計や技術的必要性と言えるレベルのノウハウだろ。

製造成果物であるソースやら、個別要件を満たすために場当たり的に考えたノウハウなぞ、
他に転用して金になる訳はなし。
0057仕様書無しさん
垢版 |
2010/07/19(月) 21:15:25
>>55
>ずいぶん昔居た会社から
某A社?
西社長から聞いたような。ユニシスとかF2(オアシスじゃなくてFacom)
向けにも「移植」しただけのを売って、かなり儲けたらしい。

i8080向けのCP/Mをi8086向けに西社長の鶴の一声で移植させられたな。
ニモニックが似てるだけで、アーキは全然違うのに。しかもたった百万円で
ビルゲイツに売っちゃった、とか。
0058仕様書無しさん
垢版 |
2010/07/20(火) 18:01:19
何百ページもの仕様書を、全部手書きで書いてましたね。
図も、なんとか定規を使って書いたり。
80年代の話。
0059仕様書無しさん
垢版 |
2010/07/20(火) 21:33:27
業務システムを自動化するだけで、莫大な利益が生まれていた時代ですからね。
1システムに掛けられる金額が桁が2つも3つも違うし、
けっこうショボい小規模システムでもライバルも居ないし、
ノンビリ作ってて大丈夫な時代だったからねえ。
平和だったねえ。
0060仕様書無しさん
垢版 |
2010/07/21(水) 16:18:08
俺が最初に付き合ったのは、昭和45年で、HITAC−8300。
IBM−S/360互換機で、メモリー64KB、磁気テープ800BPIが6基、磁気ディスク8.5MBが2基、
80欄紙カードのカードリーダー1基、ラインプリンタ1基。
水冷式クーラー2基。
以上総額買い取りならば2億7千万円を44ヶ月レンタル。

言語は、360互換アセンブラ、COBOL、RPG、FORTRAN。
日立製作所本体からSEが4人派遣され、日立電子サービスから保守員2人常駐。

設置してから2ヶ月間の点検と試験運用を経て、お祭り騒ぎの始動式典をやった。
0061仕様書無しさん
垢版 |
2010/07/21(水) 16:26:02
なんで保守員が2人も必要かというと、
1週間に1度、3〜4時間の点検、頻発する故障、不慣れな操作による不具合対策のため。

特にコンピュータ室は稼働中23℃以下を厳守、もし25〜6℃を1時間くらい見逃してしまうと、
それから十日ほどの間に間違いなく故障が発生する。
発熱はそりゃもうすごいもんで、真冬でもクーラーをかけなければ30分ほどで
室温30℃を越える。
真夏でも寒くてたまらんので一年中厚着をしてコンピューター室で作業をする。
0062仕様書無しさん
垢版 |
2010/07/21(水) 19:17:56
>>1
へ?業務システムの構築なんてダンピングが横行してたから0円に等しいぞ。
保守料で金とってたけどw
0063仕様書無しさん
垢版 |
2010/07/21(水) 21:38:42
>>62
懐かしいな、富士通の1円入札事件とか
0064仕様書無しさん
垢版 |
2010/07/22(木) 03:20:06
>>58
>なんとか定規を使って書いたり。
テンプレート、だな。フローチャート用のテンプレ定規なら大学生協でも売ってた。

>>63
国内でも、NECが図書館システム1円入札してたな。
F2が国際市場でやらかしてからは、ダンピング叩き、日本バッシングが
激しく成った。
0065仕様書無しさん
垢版 |
2010/07/23(金) 13:30:17
Javaどころか、C言語も普及してなかったがw
アセンブリ言語で開発してたよ
0066仕様書無しさん
垢版 |
2010/07/23(金) 16:23:44
まだ、アセンプラーが存在するプロセッサーなら、幸せな方だなw
0068仕様書無しさん
垢版 |
2010/07/24(土) 00:36:11
プロセッサが実行するコードを吐き出すツールは良く作ったな。
アセンブラーとか、ニモニック言語とか低級言語を
プロセッサーコードに変換するだけなら、ツール的には楽勝だが、
それじゃプログラムを作る方が大変なので、ある程度構造化とか、
プロセッサーの制約に縛られない論理的データ構造が使えたりとか、
特殊な言語にしていた。

また、コードが無駄にデカくなるプロセッサーとかの場合、
コード量を減らすために動作仕様に合わせたコンパクトなコードバイナリー
を実行する仮想プロセッサーを設計し、物理的なプロセッサーには
VMを実行させるとか、色々好き放題やったわな。

何でも自分でやんなきゃならんのは面倒ではあるが、
好きに考えてオケーってのは、逆に楽なものだ。
0069仕様書無しさん
垢版 |
2010/07/24(土) 01:38:20
JCLが曲者というより、有用だった・・・。
COBOLのプログラムは単調だからそんなに難しくはなかったが、
10年くらい前のCOBOLだと変数のスコープとか関数とか普通に使えたからなぁ。
COBOLは全部広域変数だと思っている人は、COBOLへの理解が足りてない。
0071仕様書無しさん
垢版 |
2010/07/24(土) 05:12:14
既に20年前にオブジェクト指向なFortran90が制定されたわけだが。
0072仕様書無しさん
垢版 |
2010/07/24(土) 11:58:05
だって・・・実際コボったの10年前なんだもんw
でもそのころから、広域変数うんたら・・・ってみんな言ってた。
0074仕様書無しさん
垢版 |
2010/07/24(土) 15:27:39
だが日本のIT業界は、どこもCOBOL(20年前)で培った設計ノウハウを踏襲し(他の設計ノウハウは無い)、
いまだに現役である(コストに見合うパフォーマンスを発揮しているとは言っていない)
0075仕様書無しさん
垢版 |
2010/07/25(日) 06:13:26
いや、コスパは十分だろ。
なにせ、必要なものを必要な分だけプログラミングして使ってるんだから。無駄はない。
ただし、はるかに安いハードで、同等の安定性をもって、その資産を生かせれば、それ
に切り替えることも当然選択の一つ。
0076仕様書無しさん
垢版 |
2010/07/25(日) 06:24:42
無駄はないけど、生産性の低いやり方。
無駄は発生するけど、生産性の高いやり方。
どちらの方が安くできるかというと、大抵後者。
0077仕様書無しさん
垢版 |
2010/07/25(日) 12:44:04
>>76
ところが、
実際メインフレームからオープン系、オープン系からメインフレームに移行したけど
 費用の予想計算、実際の経費
を実際に経験してみると、メインフレーム向きの業務はやっぱりメインフレームのほうが
無駄も生産性も高かった・・・。高いリスクと勉強費用だったとうちのシステム課では反省している。
0078仕様書無しさん
垢版 |
2010/07/25(日) 12:46:23
メインフレームって、昔ながらのウォーターフロー開発しかできないんだ。
0080仕様書無しさん
垢版 |
2010/07/25(日) 16:47:43
昔ながらの人間しか居ないので、フォーターフォール方式しか頭にないってのがあるな。


>開発手法は、環境にそこまで依存しない
そうだね。てか、ぶっちゃけ無関係だね。
環境で比較してどうだったってのは、フォーターフォールがどれだけ効率悪いかって話には、
あんま参考にならんな。
0081仕様書無しさん
垢版 |
2010/07/25(日) 17:38:04
フォーターフォールの欠点はあっても、効率悪いなんていう話はない。
0082仕様書無しさん
垢版 |
2010/07/25(日) 19:12:04
今まで何度もやったことのある定形作業なら、ウォーターフォール最強。
ただ、なにか新しい要素が入ると顧客に提供するまでのスパンが長くなりがち
なんで、スピードが求められる昨今の案件には向かない。
0084仕様書無しさん
垢版 |
2010/07/26(月) 01:02:40
つ、釣られないぞ
0085仕様書無しさん
垢版 |
2010/07/26(月) 01:32:21
>今まで何度もやったことのある定形作業なら、ウォーターフォール最強。
それなんだよね。
日本のITはコピペ産業だから、ウォーターフォールがベストマッチする。

だが、コピペでモノを作り上げてくるのにも限界な時代になった。
仕事=クリエイション さらにスピードが要求されると、そりゃ破綻するわな。
海外のクリエイター達に仕事持ってかれるってのは、単に労働賃金だけの問題じゃないよ。
多分日本人が時給300円で働いても、海外には適わないだろうな。
0087仕様書無しさん
垢版 |
2010/07/26(月) 07:15:37
コピペ産業というのは、ソースのコピペのことを指している訳ではない
0088仕様書無しさん
垢版 |
2010/07/26(月) 12:03:15
>>82
本当に新しい技術開発でも無い限り
ウォーターフォールで十分だな
業務分野が生産管理でも金融でも中身なんて大して変わらんしな
0089仕様書無しさん
垢版 |
2010/07/26(月) 14:08:37
そうやって過去に作ったモノの仕組みやノウハウをコピペすることでしかシステム構築できねえから、
2社のシステム統合させると、2つのシステムを残したまま、出入り口で無理矢理対応させる
とかしか出来なくなっちまうんだよな。名ばかりの統合ってやつ。
0090仕様書無しさん
垢版 |
2010/07/26(月) 17:30:55
君の言ってる事はあまりにもレベルが低すぎるぞ
旧システム残したまま入り口のみ統合ってのは
新システムできるまでの一時凌ぎにしか過ぎん

それは開発と呼ぶにもおこがましいレベルだ
0092仕様書無しさん
垢版 |
2010/07/26(月) 19:03:10
実際、銀行のシステム統合がそんな感じだな。
一気に統合させると、新たにデザインしなきゃならない部分が多くて、
日本人のやり方では間に合わない。
実際ミズホがそれで失敗した。

だから入り口だけ統合して、システム統合したと見せかけて、
裏でコソコソとちょっとずつ統合していく方法が王道になってしまった。
0093仕様書無しさん
垢版 |
2010/07/27(火) 07:35:03
>>90
疎結合って知ってる?
0095仕様書無しさん
垢版 |
2010/07/27(火) 13:44:35
なんか「統合」の定義が、モノシステムじゃなきゃダメって奴がいるな
0096仕様書無しさん
垢版 |
2010/07/27(火) 23:08:19
昔のITには英語の「それ」という意味しかなかった
以上
0097仕様書無しさん
垢版 |
2010/07/27(火) 23:19:27
以上

進歩の無いIT技術者達がお送りしました。
日本の次代は暗いな
0099仕様書無しさん
垢版 |
2010/07/30(金) 09:15:09
フォーターフォールって何?
■ このスレッドは過去ログ倉庫に格納されています

ニューススポーツなんでも実況