昔のITってどんなだったの？

1 ：2010/07/17 〜 最終レス ：2013/06/30

技術から言えば1/5位のレベルで今よりも単価が3倍位高かったみたいなんだけど本当？
10年前くらいらしいけど、HTML組めるレヴェルで500kとか貰えたって・・・

2 ：

嘘だよ？

3 ：

３年前でも、Javaかけるだけで５０万くらいもらえたよ？

4 ：

15年くらい前だと、ただ単にHTMLを使える人がほとんどいなかっただけ。
ていうかHTMLはプログラミング言語じゃないんだから組めるとかふつう言わない。

5 ：

2001年のJavaOneにも参加して、JAVAの仕事も結構やってるが未だに２０万だな

6 ：

>>1
技術は昔の人のほうがはるかに高い。
なにせ資料はまったくなく、自動化も簡略化もサポートも少ない。
となれば、コンピューターのことをちゃんと理解してないと動かすことすらままならん。
オタクな職業だったから、絶対数が少なく単価は高かった。
今のように誰でも１，２週間でプログラマを名乗れる時代ではなかった。
少なくとも新人教育にはマジで半年はかかった。

7 ：

まともなIDEがないとコード書けません^^;

8 ：

>>6
技術と技能の違いも解ってなさそうな人に長文書かれても…。

9 ：

>>8
雑魚に言われても・・・。

10 ：

>>6 >>8 30年前、40年前ならともかく、10年前程度じゃ大して変わらんよ。

11 ：

ドラム缶サイズのハードディスクで
コンパイル１回するのに計画書が必要な時代ですね

12 ：

テープやカードに穴開けてた時代だろ？
人が読んで解析したりな。

13 ：

>>8
このスレの流れからその文章を書いた意図がわかりません。
ＫＹですか？
6じゃありません。

14 ：

>>10
そだな。でも15年前にしたら急激に状況は異なるぞ。
>>13
だって>>8は専門卒のバカだもん。

15 ：

>>14
Fラン乙

16 ：

>>15
あぁやっぱ専卒なんだｗやっぱバカだなぁと思った通りｗ

17 ：

何故高卒じゃなく専卒を持ってきた

18 ：

いい大人がお子様の煽りに簡単に揺すぶられてどうするよ。
本気でやってきた技術者なら、この20年やら30年やらで、
後輩に覚えていてほしいこととか、自分らの反省とか、色々あるだろ…

19 ：

いわゆるInterne breakの頃(90年代中盤)
HTML組むだけで＝Web pageのデザインをするだけで月100万の仕事は存在しました。
今はどうなんですか？ツールの充実で納期は５倍ぐらい短くなったかもしれませんが、
会社としては人月あたり数十万以上入らないと経営が成り立たないですよね。
デザイン＝狭義の見てくれ（表現）もエンジニアがやることがあって失敗作続出でした。
当時は標準ははっきりしないし、ユーザーが使いやすいデザイン規範も決まらないので、
HTMLソースもハチャメチャなものもありましたね。これを技術的なレベルの低さとも解釈できるでしょう。
でもどの時代でも、はっきりしない分野、新しくて方法論が定まらない分野ではハチャメチャな
ものがありますよね。

20 ：

昔のITは、当たり前だけどユーザーが使うインターフェースと、アプリケーション本来の機能を一緒にして、
時にはハードも組で売ってました。
最初は1980年代にハードが切り離されて「オープンシステム」とか呼ばれるようになって、
インターネットの興隆後にインタフェース（Web)が切り離されるようになりました。
今、データの保存(あるいや永続化)にはデータベースを使うのが当たり前ですよね。
実はこれは、インターネットの興隆前はそんなに当たり前ではありませんでした。
自前の保存システムや永続化システムが、システムに埋め込まれて売られることが
非常に多かったのです。
脆弱だし、性能もよくないはずですが、「アプリケーションに特化してある」と言い訳していました。
こうしたコンポーネントも組になって売られている分、今との比較では、お金も納期もかかってたはずです。

21 ：

当時Internet breakと平行してホットだったのは「オブジェクト指向」でしょう。
世の中の誤解を良いことに、継承だけで(encapsulationなしで)オブジェクト指向を標榜して、
10倍のお金をもらうこともあり得た時代でした。
今もAjaxとかWeb2.0とかを標榜してるが実は…とかいうのありませんか？
オブジェクト指向で開発するから、今回はちょっとお金多く貰うけど、
次回や修正の際は短納期で安くできるよ、とかいう営業トークをしたようです。
実際はそうはなりませんでした。
今そういう営業トークは誰も信じませんが、実はオブジェクト指向が浸透した今は、
多方面でじわじわそういう効果が出てると思います。劇的でないにしろ。

22 ：

昔＝無計画に設計し、人海戦術でこなす。大金が動いていたのでこれでもなんとかなる。
今＝計画的に設計し、既存のものを最大限活用し、少人数低コストで実現することを最大目標とする。

まあ今でも人海戦術大好きな連中が化石のようにはびこってるけどねｗ
将来を棒に振りたくなきゃ、そんなとこに参加しないこった。

23 ：

>>22
これはおかしい。昔はシステムが高かったからそんな無計画になんてできるわけがない。
そもそも人海戦術というが、昔はそんなにプログラマなんて人いなかったから人海戦術は物理的に無理だし。
そもそも、昔の人はそういう環境しかなかったのだから。gotoでしか分岐できなかったんだから。
そういった時代を生きた人の中で優秀な人が改良改良を加えて今の開発環境ができた。
というプロセスを忘れてはならない。今の人がある日突然gotoをなくしてJavaやOOを開発したわけではないんだから。
おっさんたちの中の優秀な奴らが、修正を加えた構成気を自分たちの功績のように語るのは問題あるぞ。
今は、そういった過去の問題点への改良のおかげで、高度な開発環境を手にできてレベルが低くても開発できるよう
なったおかげでプログラマがたくさんできた。同時にコストも下がった。

24 ：

>>20
RDBの流行は、インターネットの興隆と関係ないという意見も多いかも。
直接的には、性能と安定性の向上のせいかも。
「インター」に限らずネットワークの機能向上は、
システム中のコンポーネントを分離あるいは分散させるという意味で、
RDBの一般化についても重要な要素だったでしょう。
ところが９０年代、ネットワークハードウエア、あるいはコンポーネントの分散化、並列化の
技術者は極端に少なく、あるいはこれを専門の職、あるいは独立した仕事と考えてお金を
払う思想は全くありませんでした。できる人が便利屋的にひっぱりだされるか、
組織によっては「誰もそれの知識がない」という状態でした。

25 ：

今と大きく意識が違う点として、ハードの価格というのもあるでしょう。
ハードディスクなんて、まずは利用が考えられない時代がありました。
１９８０年代： オフコンで中華なべぐらいの50KBのディスクが数百万
１９９０年代はじめ：PCにＨＤＤがつくけどＰＣのシステムの仕事はなく、
ワークステーションでも数十メガあたり百万。
私の場合では、容量を気にせずハードディスクを使えたのは１９９０年代中盤からです。
ハードディスクに限らず、メモリ、ディスプレイ、なんでも同じです。
当時は、こうした資源をケチケチ使う技術がいろいろありました。資源をケチることは、
ハードを含めたシステムの全体的な価格を抑えることができるので、非常に重要視されました。
設計の非常に早い段階から、ハードの制約（どうケチるか）が関係者の頭に必ずめぐってました。
もちろん、これは出来上がりの美しさを歪めることが多かったです。でもお金には代えられない。
逆に、９０年代中盤ハードの価格が下がりだしてから、ケチケチしない「富豪プログラミング」
という思想が出ました。ソフトウエア工学的に正しいし、人に優しいし、今はこちらが当たり前で
死語ですよね。

26 ：

>>23
設計って書いてあるだろ。
君の言ってるのは、全て実装の話だ。

27 ：

一時期メモリ全然無かったからCPU依存のコードがもてはやされたっけ。
今じゃＤＢインストールするのに云ギガメモリーとか普通だもんな。
果ては分散すりゃいいじゃん的風潮。マンプス系の工夫フェチが減った。
コンパイル後のアセンブラを意識して、スーパースカラーを誘うようにＣ言語書いたり。
クロック数稼ぐためにループ割とかやったら可読性最悪だったり。(IntelC++でメイクすると上手く配置してくれそうだけど)
SSEとかハード的に凄い命令がやってきて、俺の最下層ループのフーリエどうよって自慢しても、後でRーにされるだけだし。
ノスタルジーに浸るほど、時代に振り回され報われない生涯をおくってきた自身を嘆くばかり。

28 ：

>>26
設計者と実装者がイコールであった時代になにを言うんだ。
いや正確には設計者は実装のベテランが担当した時代だ。
今のように新卒ＳＥなんて言葉がなかった時代だぞ。

29 ：

>>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命令は
マシン語で組み易かったし。

30 ：

>>28
新卒SEが設計してるところってあるの？
新卒SEはSEって言う名前だけど連絡係なところはいくつか知ってるけど。

31 ：

設計者じゃなくて設計の話なんだが。

設計者の話が出たので、話としては丁度いいが、
実装者に設計やらすとか、無計画な設計の典型だよね。

32 ：

>>22
昔＝計画的に設計し、計画と実際のずれが判明した後でも人海戦術でこなす。
大金が動いていたのでこれでもなんとかなる。
今＝無計画に設計し、計画と実際のずれが判明したら再度設計しなおす。
少人数低コストで実現することを最大目標とする。

33 ：

MVC分離とか疎結合とか、概念すらない時代の設計の
どこが計画的だったのかと

34 ：

あ、わかった。
実装者＝設計者って話になるぐらい、昔は設計の段階で
そのままコードに出来るぐらい詳細に書いちまってた。
それって、単なるコーディング指示書作成プロセスってやつで、
本来設計と呼ぶべきじゃないんだが、昔の言い方では設計と呼ばれてた。
俺の言う無計画計画ってのはそういうこと。
計画的に詳細設計（＝事実上のコーディング）を行うことは、
計画的な設計とは違う。

35 ：

組み込みでポリモーフィズムなんて言ったら親方にぶん殴られるけど

36 ：

今から１０年後同じようにお前らも言われるのにｗ

37 ：

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

38 ：

>>35
関数ポインタだろ？

39 ：

後で一意のポインタで実行するって話だから、キャストかな

40 ：

インジェクションによるファサードを実現するためのランタイムインプリメンテイションだろ

41 ：

>>40
なんなんだ、そのインチキ英語は

42 ：

>>30
NTTデータ

43 ：

32Mのメモリー買う予算が無いからプログラマー3人を一ヶ月投入して最適化したりしてた。
最近の若者に言っても全く信じてくれないが

44 ：

未だに１０ＫのＲＡＭでがんがってる

45 ：

256KBのメモリーが数万円の時代は、１日掛けてコード量を１０バイト減らしてグッジョブな状態だったな。
メガじゃないぞ、キロだからな。

46 ：

あの時代はあの時代で求められるものがあった。
今の時代は今の時代で求められるものがある。
求められるものが違うけど、その時代を生きる人間には、自分の時代が一番つらいと感じるものさ・・・。
今の時代にとりあえず求められるもの「おまえの仕事量は増やすが、給料を減らすの了承しろ」以上。
まぁ未来が見えないというのはつらいよね。
少なくとも昔は、こんな時代が来るとは思ってなかったもん・・・。（；＿；）

47 ：

仕事は物理的に増やしようがない。
それなのに増やせと言われる。
寝るなと言っているのと同義だ。
給料減らすって言われるのはまだ親切だなｗ

48 ：

今フレームワークになっているものを、昔はアドホックな方法で実装していた。
ホリエモンの会社も、初期は今でいうajaxでやっているようなインタラクティブなページを作るという評判で大きくなった。

49 ：

組込みに移って６年、もう業務系には付いていけないかも

50 ：

昔からのやり方しか知らない人が多いのか、フレームワーク上に無理矢理
昔ながらの方法で設計を乗せてるプロジェクトは多いよね。
フレームワークとかみ合わなくて、昔ながらの方法からさらに手間が倍掛かるだけだっちゅうの。

51 ：

短納期だと、フレームワークの勉強してる暇が無いからねぇ。

52 ：

センスの問題なんだよな。
大局的な設計が出来ないというか、最初から全部詳細に決めてしまわないと
全体を掌握できない人って居るわあ。
フレームワークもそのごく一部に過ぎないけど、現代の設計技法ってのは、
アリモノを最大限に利用して、作り物を最小限に減らそうってことだからな。
アリモノ使って上手く行かない場合には、どちらかになんらかの論理的な矛盾
があるはず！と考えて、論理的に上手い設計にするにはどうしたらいいのか？
を常に考える能力が要求されてくる。

53 ：

フレームワーク使って開発進めてたら、途中でフレームワークから外れた要求が出てきたとかはよくあること。

54 ：

フレームワークなんてのは、システムの物理設計の塊という側面も持っている。
当然、論理的設計というものから、遠くかけ離れた部分も多い。
だから、正しい論理設計を満たせないようなことがあると、
フレームワーク側が頑張って論理的に対応するというのが本来あるべき姿だ。
フレームワーク様が真ん中にふんぞり返っていて、「さあお前ら使え」
みたいなとこは駄目だ。
「基盤チーム」みたいなのが権力強いようなのは、糞プロジェクト認定。

ただし、正しい論理設計ってのは、どこにも解が存在しない。
説得力のみが命だ。
「コレが正しい論理設計なのだ」と言える程の設計が出来ないから、
というのが、そういうのが蔓延る諸悪の根源なんだけどね。

55 ：

ずいぶん昔居た会社から、ジャストシステムの創業者・元経営者の浮川夫妻が、
ソフト開発を請け負っていて、当時自社ブランドと、日本NCR向けOEM販売して
いた8086とMSDOSを搭載したオフィスPC用に、日本語ワープロを開発していた
らしい。
その後、ジャストから発売された一太郎の原型になったとか。
今なら、ソース持ち出しとかNGだし、安い賃金で個人のノウハウを吐き
出させられて使い捨て。

56 ：

原型つのは、概要設計や技術的必要性と言えるレベルのノウハウだろ。
製造成果物であるソースやら、個別要件を満たすために場当たり的に考えたノウハウなぞ、
他に転用して金になる訳はなし。

57 ：

>>55
>ずいぶん昔居た会社から
某A社?
西社長から聞いたような。ユニシスとかF2(オアシスじゃなくてFacom)
向けにも「移植」しただけのを売って、かなり儲けたらしい。
i8080向けのCP/Mをi8086向けに西社長の鶴の一声で移植させられたな。
ニモニックが似てるだけで、アーキは全然違うのに。しかもたった百万円で
ビルゲイツに売っちゃった、とか。

58 ：

何百ページもの仕様書を、全部手書きで書いてましたね。
図も、なんとか定規を使って書いたり。
80年代の話。

59 ：

業務システムを自動化するだけで、莫大な利益が生まれていた時代ですからね。
１システムに掛けられる金額が桁が２つも３つも違うし、
けっこうショボい小規模システムでもライバルも居ないし、
ノンビリ作ってて大丈夫な時代だったからねえ。
平和だったねえ。

60 ：

俺が最初に付き合ったのは、昭和４５年で、ＨＩＴＡＣ−８３００。
ＩＢＭ−Ｓ／３６０互換機で、メモリー６４ＫＢ、磁気テープ８００ＢＰＩが６基、磁気ディスク８．５ＭＢが２基、
８０欄紙カードのカードリーダー１基、ラインプリンタ１基。
水冷式クーラー２基。
以上総額買い取りならば２億７千万円を４４ヶ月レンタル。
言語は、３６０互換アセンブラ、ＣＯＢＯＬ、ＲＰＧ、ＦＯＲＴＲＡＮ。
日立製作所本体からＳＥが４人派遣され、日立電子サービスから保守員２人常駐。
設置してから２ヶ月間の点検と試験運用を経て、お祭り騒ぎの始動式典をやった。

61 ：

なんで保守員が２人も必要かというと、
１週間に１度、３〜４時間の点検、頻発する故障、不慣れな操作による不具合対策のため。
特にコンピュータ室は稼働中２３℃以下を厳守、もし２５〜６℃を１時間くらい見逃してしまうと、
それから十日ほどの間に間違いなく故障が発生する。
発熱はそりゃもうすごいもんで、真冬でもクーラーをかけなければ３０分ほどで
室温３０℃を越える。
真夏でも寒くてたまらんので一年中厚着をしてコンピューター室で作業をする。

62 ：

>>1
へ？業務システムの構築なんてダンピングが横行してたから０円に等しいぞ。
保守料で金とってたけどｗ

63 ：

>>62
懐かしいな、富士通の1円入札事件とか

64 ：

>>58
>なんとか定規を使って書いたり。
テンプレート、だな。フローチャート用のテンプレ定規なら大学生協でも売ってた。
>>63
国内でも、NECが図書館システム1円入札してたな。
F2が国際市場でやらかしてからは、ダンピング叩き、日本バッシングが
激しく成った。

65 ：

Javaどころか、C言語も普及してなかったがw
アセンブリ言語で開発してたよ

66 ：

まだ、アセンプラーが存在するプロセッサーなら、幸せな方だなｗ

67 ：

アセンブラくらい作れよ。

68 ：

プロセッサが実行するコードを吐き出すツールは良く作ったな。
アセンブラーとか、ニモニック言語とか低級言語を
プロセッサーコードに変換するだけなら、ツール的には楽勝だが、
それじゃプログラムを作る方が大変なので、ある程度構造化とか、
プロセッサーの制約に縛られない論理的データ構造が使えたりとか、
特殊な言語にしていた。
また、コードが無駄にデカくなるプロセッサーとかの場合、
コード量を減らすために動作仕様に合わせたコンパクトなコードバイナリー
を実行する仮想プロセッサーを設計し、物理的なプロセッサーには
ＶＭを実行させるとか、色々好き放題やったわな。
何でも自分でやんなきゃならんのは面倒ではあるが、
好きに考えてオケーってのは、逆に楽なものだ。

69 ：

ＪＣＬが曲者というより、有用だった・・・。
COBOLのプログラムは単調だからそんなに難しくはなかったが、
１０年くらい前のCOBOLだと変数のスコープとか関数とか普通に使えたからなぁ。
COBOLは全部広域変数だと思っている人は、COBOLへの理解が足りてない。

70 ：

10年前が昔って・・・いくらなんでも近すぎ。

71 ：

既に20年前にオブジェクト指向なFortran90が制定されたわけだが。

72 ：

だって・・・実際コボったの１０年前なんだもんｗ
でもそのころから、広域変数うんたら・・・ってみんな言ってた。

73 ：

COBOLを使うと馬鹿になる

74 ：

だが日本のＩＴ業界は、どこもCOBOL（２０年前）で培った設計ノウハウを踏襲し（他の設計ノウハウは無い）、
いまだに現役である（コストに見合うパフォーマンスを発揮しているとは言っていない）

75 ：

いや、コスパは十分だろ。
なにせ、必要なものを必要な分だけプログラミングして使ってるんだから。無駄はない。
ただし、はるかに安いハードで、同等の安定性をもって、その資産を生かせれば、それ
に切り替えることも当然選択の一つ。

76 ：

無駄はないけど、生産性の低いやり方。
無駄は発生するけど、生産性の高いやり方。
どちらの方が安くできるかというと、大抵後者。

77 ：

>>76
ところが、
実際メインフレームからオープン系、オープン系からメインフレームに移行したけど
　費用の予想計算、実際の経費
を実際に経験してみると、メインフレーム向きの業務はやっぱりメインフレームのほうが
無駄も生産性も高かった・・・。高いリスクと勉強費用だったとうちのシステム課では反省している。

78 ：

メインフレームって、昔ながらのウォーターフロー開発しかできないんだ。

79 ：

開発手法は、環境にそこまで依存しないでしょ。

80 ：

昔ながらの人間しか居ないので、フォーターフォール方式しか頭にないってのがあるな。

＞開発手法は、環境にそこまで依存しない
そうだね。てか、ぶっちゃけ無関係だね。
環境で比較してどうだったってのは、フォーターフォールがどれだけ効率悪いかって話には、
あんま参考にならんな。

81 ：

フォーターフォールの欠点はあっても、効率悪いなんていう話はない。

82 ：

今まで何度もやったことのある定形作業なら、ウォーターフォール最強。
ただ、なにか新しい要素が入ると顧客に提供するまでのスパンが長くなりがち
なんで、スピードが求められる昨今の案件には向かない。

83 ：

スピード重視ならウォーターフォール最強。

84 ：

つ、釣られないぞ

85 ：

＞今まで何度もやったことのある定形作業なら、ウォーターフォール最強。
それなんだよね。
日本のＩＴはコピペ産業だから、ウォーターフォールがベストマッチする。
だが、コピペでモノを作り上げてくるのにも限界な時代になった。
仕事＝クリエイション　さらにスピードが要求されると、そりゃ破綻するわな。
海外のクリエイター達に仕事持ってかれるってのは、単に労働賃金だけの問題じゃないよ。
多分日本人が時給３００円で働いても、海外には適わないだろうな。

86 ：

ウォーターフォールにコピペは向かないだろ。

87 ：

コピペ産業というのは、ソースのコピペのことを指している訳ではない

88 ：

>>82
本当に新しい技術開発でも無い限り
ウォーターフォールで十分だな
業務分野が生産管理でも金融でも中身なんて大して変わらんしな

89 ：

そうやって過去に作ったモノの仕組みやノウハウをコピペすることでしかシステム構築できねえから、
２社のシステム統合させると、２つのシステムを残したまま、出入り口で無理矢理対応させる
とかしか出来なくなっちまうんだよな。名ばかりの統合ってやつ。

90 ：

君の言ってる事はあまりにもレベルが低すぎるぞ
旧システム残したまま入り口のみ統合ってのは
新システムできるまでの一時凌ぎにしか過ぎん
それは開発と呼ぶにもおこがましいレベルだ

91 ：

adapter patternも知らない老害

92 ：

実際、銀行のシステム統合がそんな感じだな。
一気に統合させると、新たにデザインしなきゃならない部分が多くて、
日本人のやり方では間に合わない。
実際ミズホがそれで失敗した。
だから入り口だけ統合して、システム統合したと見せかけて、
裏でコソコソとちょっとずつ統合していく方法が王道になってしまった。

93 ：

>>90
疎結合って知ってる？

94 ：

デザパタはそんな万能なのか？

95 ：

なんか「統合」の定義が、モノシステムじゃなきゃダメって奴がいるな

96 ：

昔のITには英語の「それ」という意味しかなかった
以上

97 ：

以上
進歩の無いIT技術者達がお送りしました。
日本の次代は暗いな

98 ：

状況のITは？

99 ：

フォーターフォールって何？

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

印象に残ったコメントを晒せ　0x04 (812)
残業代を払わない残業は違法だ (875)
【char】変な読み方するな その３【ちゃー】 (972)
プログラマー川柳 (228)
”元号とか面倒くさいからさっさと廃止して” (121)
A型のプログラマーは神 (353)
--log9.info------------------
AI特化のＲＰＧを作って売りたい 2層目【避難所】 (175)
むしろjavascriptでゲーム作ろうぜ (694)
【初心者】ステフと一緒にゲーム製作part10【歓迎】 (840)
3Dエンジンの技術について語ろう (825)
人工知能or人工無脳作ろうぜ (933)
著作権の切れた名曲を晒すスレ (194)
ZUN (275)
Javaで作るスタンドアローンゲーム (238)
モチベーション維持の方法を話あおう (319)
【総合】プロジェクト発表【作ってます】 (152)
ガンダム版大戦略 (379)
★ゲーム製作期待の星！ HSP Part 9 ★ (279)
スクウェアがＦＦ作るときに使ってるソフトおしえれ (170)
固定概念って・・・ (220)
◆　ツクールは終わった　◆ (300)
もうマンネリなシナリオは充分だ (378)
--log55.com------------------
【Sound】サウンドクラッシュPart58【Clash】
ベートーベン　ピアノソナタ総合　その38
【上級国民】 飯塚幸三 【池袋暴走】
NHK クラシック音楽館 11楽章
交響曲第5番一番の名曲はどれ？
グスタフ・マーラーPart23
来日オーケストラ総合スレ 32
ベルリン・フィルハーモニー管弦楽団　13