上の画像はWikipediaのイメージから参照しています。そのものズバリだったので。

私の父親がなぜかそんなパソコンを2～3年落ちぐらいで買ってきたのが私のPC遍歴の最初になります。（というかパソコン買いに行くぞ！ってルンルンで家電量販店に連れて行かれた。今は無きマ○ヤデンキに…）

当時5歳ぐらいでした。たしか一年制の幼稚園入ってなかった筈なんで…。

余談ですが、私の家ではファミコンは「パソコンあるでしょ！」を理由に相当しばらく買ってもらえませんでした(´；ω；｀)ﾌﾞﾜｯ

完全に父が私（たち）を技術方向にハメようとしていた事は間違いないですね。結果として兄弟３人ともエンジニアで飯食ってますし。

그 당시의 스토리지 환경

なおそんな当時だと、パソコンのフロッピーディスクドライブは１つで2万円ぐらいしてたようです。これまたいい値段しますね。

当時の個人向けストレージは専らカセットテープでした。最近は入ってきた新人にフロッピー知ってる？って聞いても反応が薄いので、
カセットテープとかも、今となってはオーパーツ一歩手前ですよね。

ちなみにカセットテープに０と１に相当する音を録音して記録し、それをパソコンに読み込ませる事でプログラムをリードするという代物を使っていました。
FAXの電話回線の音を聞いた事がある人はわかるかもしれません。あんな感じの音です。

なお、今も高密度化はされて現代的にはなっていますが、バックアップ用ストレージとしてはあるところにはあります。磁気テープ。

時代がちょっと進むとフロッピーディスクが一般的になってきますが、それは８０年代後半～９０年代に入ってからのような気がします。

これまた余談ですが、ファミコンのディスクシステム（ファミリーコンピュータ ディスクシステム）はフロッピーじゃないですよ。
もうちょっと簡単な機構で作られてるものです。

그런 무렵의 프로그래밍 환경은…

そんな頃の個人でやるレベルでのプログラミング環境は、あまりに選択肢が狭すぎて2行で書けてしまいます。そう。２択。

• BASICインタプリタ環境
• マシン語(だいたいBASICでメモリにバイナリコードを直接書いてメモリ転送して実行。いわゆるDATA文)

コンパイラなんて高級なものが庶民の手元に降りてくるまでにはもう少し時間がかかるわけです。

また、最初に８０年代プログラミング雑誌の話をしましたが、なぜそういったものが流行っていたかというと、以下のような要因があります。

• 個人持ちできるストレージデバイスなんてものはほぼなかった（カセットテープに録音するケースは例外としてあったけど）
• マシンのメモリがとにかく少なかった（メインメモリ32kとか64kとかザラ）
• 色々貧弱だったのが逆にいい面もあって、プログラムは基本的に雑誌の印刷で提供され、真面目なパソコン少年はそのコードを打ってプログラムを覚えた（という体でゲームを遊んでいた。普通にそのレベルでパソコンの限界に挑戦するようなゲームが遊べてしまった）

なお、コンパイラなんて高級言語みのあふれるものが降りてきた後も、プログラミング環境は次の３択だったような覚えがあります。

• BASICインタプリタ環境
• 高級言語でコンパイルしてバイナリ実行(ただしコンパイラは別売)
• マシン語

やっぱりパソコン本体があったら無償ではじめられたのはBASIC→マシン語 なのでした。

（なお、私がCコンパイラに初めて触れたのは、大学入ってからです…　オープンソースコンパイラみたいなものも、まだ一般的ではなかったので。）

그런 시대가 갑자기 바뀔 때는 단번에 바뀌는 것입니다.

また、コンパイラに任せると当時はコンパイラも性能が悪く、生成バイナリコードが最適な状態からは程遠い出力になることも多かったようで、当時の事を知ってる人と話したりした分には「基本的にはCで書いて、最悪困ったらそこだけアセンブリで書き直したらめちゃ早くなったわ！ガハハ！」みたいな人がプロの世界ではたまに観測されていました。

加えてそういったアセンブリ書き直しおじさん（仮称）は結構な頻度で「儂がフルアセンブリで書いたほうが５倍は早い… フォフォフォ…」みたいな事を言っていたのです。

ですが、このアセンブリ書き直しおじさん（仮称）は2000年ぐらいを境にばったり観測されなくなったのでした。（元アセンブリ書き直しおじさんが普通に開発するようになった　という方が正しいかもしれない。）

2000년을 넘었을 때 무슨 일이 일어났는가?

いくつか要因はあります。情報処理産業全体で見るとやっぱりシステム開発関連のコストが高いような気がするので、そこに重心をおいて考えてみましょう。

・Javaがサーバサイド言語としての地位を得た関係でC関連の言語で業務システムを書くケースが激減した
・Microsoftも.netFrameworkを出してきて(Ver1.0が2002年ですね。)VisualStudioで業務システム書いてた人たちも基本的に.netFrameworkに移行していった（ので基本的にはCLR環境に向けたアプリを書くようになった）

なお、ゲームや組み込み系はまだその頃は仕様制約が厳しく、その後しばらくはC言語系の環境が残っていたそうなのですが、そちらも次第に減っていきましたね。

また、コンパイラも計算機リソースが以前とは比べ物にならないレベルで使えるようになった事もあってか、だいぶ賢くなりましたし、並列処理は人が設計して捌くにはだいぶん辛いのでそれを踏まえた言語、環境なども多く出てきていますね。

加えて、プログラムの保守性や技術的負債についての見地も飛躍的に変化したのはここ10年ぐらいでしょう。本筋とは外れますが、非機能要求グレードなどについてもそうですね。昔は言われなかった論点についても問われるようになってきたのは大きな変化だなと感じます。

色々と要因を雑多に書きましたが、めちゃくちゃ簡潔に絞ると以下の点に集約されると思います。

開発の時に特殊な事をやってコストをかけるより、維持管理などを見据えたトータルコストにバランスを置くほうがコスト配分として適切になった

そう。アセンブリ書き直しおじさん（仮称）は非常に属人的なハイパースキルなので、その人がいなくなると保守が一気に辛くなるんですよね…。

비슷한 이야기를 다른 각도로 (차)

ちょっと話は変わりますが、別の角度からも同種の課題について見てみましょう。

車の免許を取られている方は多いと思いますが、30代以上の方って免許を取られた時ってMTも含めた形での免許を取りませんでしたか？（最近の方はAT限定も多いと思います。）

MTを含めた免許を取るほうが良いと周囲にいわれ、そうされた方が多いと思いますが、理由は次の内容に集約されると思います。

「会社の社用車はMTの方が燃費が良い為、MTしか無い可能性があるのでMTで免許取っておきましょう。」

2000年ぐらいまでは確かにそうでした。今はどうでしょうか？

ハイブリッド車が出てきて、状況は一変してしまっていますね…。かくいう私もMTで車の免許を取りましたがそのあとMTを運転する羽目になったのは生涯１度きりです。そんなものですね。

그런데 현대의 개발 환경에 눈을 돌릴까요…

ここから先は人によっては闇を背負ってしまうかもしれません。すまぬな…

프레임 워크 세계

フレームワーク界隈はなんか大きく次の３流派に分かれる気がしています。

• めちゃくちゃ変化しつつ生きていこうな！系のFW(RoRとか)
• 従来の互換性を死守してパワープレイで押し通る系のFW(.netFrameworkとか)
• そっと舞台袖に消えるFW

でも設計思想を伝達するコストとか考えたら、もう素組みでNoフレームワークで開発・・・はすべきじゃないように思いますね（勉強のために自分で組んでみるとかなら良いとは思うのですが、仕事ではやんないほうがベターかなと。）

자바 스크립트 세계

変化が激しすぎて栄枯盛衰が激しいですね。

私はフロントエンドの民ではないので、jQueryがもてはやされてその後今はちやほやされなくなっている印象は受けているのですが…　今は何がいいんでしょうか。

なお私も１０年前ですら、フロントもバックも全部JavaScriptで書いちゃおうなんて時代が来るとは正直想像はしてませんでしたね…

(初めに触ることになったのは2010年ぐらいにやったクラシックASPの改修案件だったかなぁ…　確か。)

데이터베이스 경계

個人的にはDBへのアクセスはSQL直書き派とORマッパー派に二分されるような気がしています。

私個人としてはSQL直書き派閥なんですが、どこかで前述のような大地殻変動が起きて、「SQL直書きなんて老害！はよ引退しろ！」と言われる未来がすぐそこまで迫っている気はしなくもないです。

((((；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

여담

そういえば2005年頃に1本1億ぐらいしちゃうAlphaのサーバを仕事でぶん回してた事があるんですが、CPUが16パラ、メインメモリ128Gだったんですよね。

確か1ノードでCPU4パラ、メインメモリ32Gの4ノード構成でした。

今だとそれぐらいのスペックなら個人PCで買えちゃうんですよね。すごい時代になったものです。(実際、この記事を書いてる私のPCが3年前に買って2コアHT有りのメモリ32Gなので…)

そういえば、当時の1プロセスで10Gぐらいメモリ食ってましたね…。

10年ぐらい経つと例えばこれぐらい、計算機リソースの変遷にインパクトがあるんですよね。

「10年でだいたい1000倍」

ここテストにでますよ！覚えておきましょう。(笑)

하나 하나 여담

ある技術分野で起きたブレークスルーは、他の技術分野でも形を変えて起きるケースがあります。（前述の車の件とかアセンブリ書き直しおじさん（仮称）の件とか）

たまにはIT以外に目を向ける事で、新たなヒントがあるかもしれませんね。

昨今、M1チップを載せたMACが恐ろしいスピードを叩き出して話題になっていますが、ノイズ対策の観点やデータ通信の速度は光の速度を超えられない、などの観点から高周波電子回路のノイズ対策を生業にしていた父はよく「おそらく辛くなって最終的には全部ワンチップに載りだすと思うよ…」って言ってました。

（ちなみに興味があれば、８０年代マイコンの基盤のイメージ、９０年代のPCの基盤イメージ、００年代、１０年代、最近のマザーボードのCPUとメモリ位置のレイアウトなどを見てみるといいでしょう。どんどんCPUとメモリの物理的な距離が近づいているはずですよ。）

今年は、普通のノイマン型コンピューターの最後の進化が始まった…といえる年なのかもしれませんね。(笑)

ただ、コンピューティングの長い歴史を紐解いた時によく出てくるブレークスルーパターンであるやつだと、シングルでの処理能力が辛くなるとパラレルに処理を捌いてなんとかしちゃう系ソリューションが幅を利かせてきた歴史（シリアル転送→パラレル転送、シングルコアCPU→パラレルコアCPU）が結構発生率が高いので、そういう事を考えるとワンチップコンピューターが今度は数珠つなぎになって強大な計算機リソースを実現しだす未来もあるのかもしれません。そうして歴史は繰り返すのです。たぶん。

そしてそんな時代になるとたぶんパソコンめっっっっちゃ熱くなると思います。（もしくは放熱がちゃんとできてないとすぐスピードでなくなるみたいな奴。個人的には熱対策の観点で、全部１チップになった上、１チップだと１点に熱が集中しちゃうので、チップが口の字型の構造になって、チップの真ん中を通るように熱伝導体が巡回する　要はオイルヒーターみたいな思想に収斂していくんじゃないかなと想像していますが…　ならんかな。）

どうなるんでしょうね。楽しみですね。

さすがにそれまでに量子コンピューターが実用フェーズに来るとは思うのですが。

결론

見た人で何か思いついたらコメントとかで教えて頂けると…。