  |
はてなキーワード: Visual Basicとは
プログラマーって聞くと今の若い人は稼げる業種って思うかもしれない。でも昔は、そのイメージとはまるで真逆だったんだよ。
90年代初頭、日本はバブルの余韻が残ってたけど、IT業界なんてまだオタクの延長みたいに見られていた。NECのPC-9801シリーズがオフィスの定番で、OSはMS-DOS 3.3とか、その後にWindows 3.1が出ておお、マウスで操作できる！なんて騒がれていた時代だ。
もちろんインターネットなんて一般にはまだ普及してなかった。せいぜいパソコン通信。ニフティサーブ、PC-VAN、アスキーネット。回線速度は2400bps。ピーヒョロロっていうモデム音が夜中の住宅街に響いていた。
俺らはそういう環境でC言語やアセンブラを叩いてたんだ。コンパイルに時間がかかるから、トイレに行って戻ってきてもまだ終わってなかったりした。
今みたいにGitHubでコードを共有なんて夢のまた夢。ソースのやり取りはフロッピーディスクで手渡しだ。5インチのぺらぺらのやつな。運が悪いと磁気にやられて一発で飛ぶ。だから俺たちはよくフロッピー神社に参拝とか冗談言ってた。
正社員で手取り20万ちょっと。下請けやフリーランスだともっと安い。今でいうSESの走りみたいな人売りも普通にあった。客先常駐でCOBOLやらされてバグが出れば徹夜。オフィスに寝袋持ち込んで、カップヌードルと缶コーヒーの山を築く。徹夜明けに食う吉野家の牛丼が唯一のご褒美。今みたいにエンジニアは市場価値が高いなんて考え方はなかったからな。ただの駒だよ。
仕事は増えるのに単価は下がる。Windows 95の発売で世の中はインターネット元年なんて浮かれてたけど俺たちプログラマーの現実は泥臭いコード修正の山。Visual Basic 6.0やDelphiが出て「これで開発効率が上がるぞ」なんて言ってたが、結局は納期に追われるだけ。SunのJavaが登場したときも「Write once, run anywhere」なんて夢を見せてくれたけど、実際には動かないアプレットと格闘する日々。
Linuxが台頭してきたのもこの頃だ。
SlackwareやRed Hat Linux 5.2をCD-ROM雑誌付録で手に入れて、夜な夜なインストールに挑戦。LILOがうまく動かなくて起動しない、ネットワークカードを認識しない、X Windowが真っ黒。そんな壁に何度もぶつかっては2ちゃんねる（当時はまだ草の根BBSが多かったが）やUNIX USER誌を読み漁って解決する。それが楽しくて仕方なかった。でも金にはならなかった。オープンソースに貢献しても無償の善意で済まされるだけ。Red HatやMySQL ABが上場するまでは、ただのボランティア活動と見なされてた。
今思うと、あの頃は純粋だった。
技術そのものが楽しくて、ASCIIやOh!Xを小脇に抱えて徹夜でコードを書いた。秋葉原でジャンクパーツを漁って自作PCを組み立ててベンチマークの数字で一喜一憂した。
飯代を削ってもSCSIのハードディスクに投資したし、月刊アスキーの付録CD-ROMに入ってたシェアウェアを片っ端から試した。儲けようなんて意識はなかった。ただ、面白いものを作りたかった。
それが今じゃITは完全に拝金主義。コードの美しさより投資家の顔色を見てる。エンジニアもどこが年収高いかばかりで、言語やフレームワークを選ぶ基準が金になっちまった。Pythonが流行るのもAIブームに便乗してのことだし、ブロックチェーンやNFTなんかバブルがはじける前提のネタ探しにしか見えなかった。
もちろん、技術が商業化されて豊かになった面もある。AWSやGCPのおかげで誰でも世界規模のサービスを立ち上げられるようになったし、GitHubやDockerで開発環境も夢みたいに便利になった。だがその一方で楽しいからやるという純粋さはどこへ行ったんだろう。GitHubの草がどれだけ生えてるかが採用基準になる時代。Qiitaに記事を投稿するのも、技術共有じゃなくて転職市場でのポイント稼ぎ。
あの頃には確かに、金ではなく面白さに突き動かされる熱があった。それが今は金の匂いに上書きされてしまったように感じる。
でも稼げなくても、やる価値があった。
今の若いエンジニアたちにその気持ちがどれだけ伝わるかは分からない。
当時「Hello, world.」と表示されるだけのプログラムに、30年前の俺は心を震わせていた。
それは序盤の過密日程の影響とか、親会社の経営危機とか、地元有力者との関係性の話ではない。それらの影響が全くないとは言わないが枝葉だ。
マリノスは「アタッキングフットボール」というものをクラブのフィロソフィー（企業理念）に置いている。1年間のスローガンではなく永続的なものとして。
アタッキングフットボールとはざっくり言えばボールを常に持ちながらゴールに向かうスタイル（以下「ポゼッション型」とする）であり、2018年のアンジェ・ポステコグルー監督から始まった戦術でもある。
そして2019年と2022年にJ1リーグ優勝を果たし、2021年と2023年も2位と一時代を築いていた。
しかしサッカーのスタイルは数年スパンで栄枯盛衰を繰り返すものであり、本来それを企業理念に置いてはいけないものだ。
一般企業に例えたら「当社はガラケー向けサービスに特化」とか「当社はVisual Basicの技術者集団としてお客様に貢献」という、寿命が長くない技術的な要素を理念に置いてしまうのと同じだ。
そしてポゼッション型が栄枯盛衰の「枯・衰」側に明らかに傾いたここ1-2年で、見事にマリノスは壊滅している。
いくつかあるがこの3点が大きい。
・3人→5人交代制に変更/夏季飲水タイムの追加：いずれもコロナ禍の副産物。これにより個々の選手がより長い時間走れるようになり、ポゼッション型よりも「ボールを持っている相手を追い込む」サッカースタイルの方が有利になった。後者は2022年ワールドカップでドイツとスペインを撃破した日本代表が好例。
・主審のポジショニング変更：主審は「よりボールに近いところに位置取りをしなさい」というFIFA通達が2024年にあり、その結果主審のポジショニングがグラウンドのセンター付近から極力離れないようになったため、ポゼッション型のチームにとっては常に主審が邪魔になるようになった。カウンター型のチームはボールを持ったら主審を追い越すボールをさっさと前方に出すので、主審は邪魔にならない。つまりポゼッション型のチームとカウンター型のチームが対戦するというのは、11人vs12人で試合をするのに近しくなる。
特に後者の影響は大きく、2024年のJリーグではマリノス以外でも川崎フロンターレなどのポゼッション型のチームがことごとく低迷した。
そして川崎は2025年シーズンはポゼッション型の戦術を止めてカウンター型に切り替え、ACLでは決勝進出、Jリーグも昨年より上の順位に位置するなど健闘している。
一方でマリノスはポゼッション型の継続を選択したが全く勝てず、監督解任を経てカウンター型の戦術に切り替えて、首位の鹿島などに2連勝。これを続ければ残留は出来そうだと誰もが見ていたが・・・
「俺達はアタッキングフットボールをやりたいからマリノスに来たんだ！話が違う！サッカー変えるなら他所に移籍する！」と言い出す選手が多数出て来てしまい、このままではクラブ存続どころか翌月以降の試合開催が不可能になる可能性すらあったため、戦術をポゼッション型に戻したうえで6/19に今月2度目の監督解任の運びとなった。（こういう流れが起きていることは、直近1週間の各メディアからの報道で分かる）
まさに、サッカースタイルを企業理念に置いてしまっていたが故の事象である。川崎はサッカースタイルを企業理念に置いていないのでスタイル変革が出来たが、マリノスには困難なのである。
しかしその戦術は、上述の通り賞味期限切れである。天皇杯でJFL（4部相当）かつ中2日でコンディション万全ではないチームに0-2で負け、さらにその後の新潟との裏天王山でなすすべなく完敗という体たらく。
そして今日も岡山とホーム日産スタジアムでの試合だが、おそらく0-3か0-4くらいで負けるだろう。
そして、秋が深まる前に、J2降格が決まっているだろう。
それでも増田はマリノスの年間チケットホルダーでもあるので現地に行く。
「過去の成功体験に囚われ、変化への対応を拒否する、レガシーな人達の集まり」がどういう末路をたどるかという、今後の自分の社会人生活でも大いに参考になるであろう、生きた教材を見に・・・。
1990年代半ば、九州大学病院（九大病院）は病院情報システムの全面刷新を計画していた。従来の断片化したシステムを統合し、最先端のオブジェクト指向技術を全面採用した次世代システムに生まれ変わらせるという大胆な構想である
tumblr.com
。入札条件にも「純粋なオブジェクト指向技術で実現すること」を掲げ、業界内でも前例の少ない大規模プロジェクトに挑むことになった
tumblr.com
。この計画に応札した日本IBMは、開発言語にSmalltalkを採用し、社内外からオブジェクト指向開発の専門家を総動員する。日本IBM自身のチームに加え、Smalltalkの豊富な経験を持つ多数のシステムインテグレータ各社が協力企業として参画し、一時期は約200名もの技術者が開発に従事する巨大プロジェクトとなった
tumblr.com
。医療現場からは「21世紀を先取りするシステムになる」という期待の声が上がり、IBM側も「国内最高峰の病院に最新技術を投入できる」と意気込んでいた。誰もが、この試みに大きな希望を抱いていたのである。
プロジェクトは1996年、本格的に動き始めた。九大病院の情報システム担当者たちは、院内各部門から新システムへの要望をヒアリングし、「新システムへの要望リスト」を作成して日本IBMに提示した。しかし、その内容は具体性に欠けていたと言われる。「実現したい業務の全体像がはっきりしていなかった」のだ。病院側は約1,400床を擁するマンモス病院ゆえ、部門ごとの意見をまとめ上げ全体方針を打ち出すことが難しく、提出された要件定義書は「中身はほとんどなかった」と関係者は振り返る。一方の日本IBMも、その不十分な要件定義を十分詰め直すことなく開発を進めようとし、この問題を放置してしまった。プロジェクト序盤から、実は大きな不安の種が芽生えていたのである。
それでも当初の計画は極めて野心的だった。フェーズごとに順次システムを稼働させる計画で、第1次カットオーバー（最初の稼働開始）は1997年1月と定められていた
tumblr.com
。限られた時間の中、日本IBMと協力各社の開発チームはオブジェクト指向の新手法に挑みつつ、多数のサブシステムを並行開発するという難事業に取り組み始めた。しかし要件の曖昧さは各所で影響を及ぼす。開発メンバーの一人は後に「実際にはオブジェクト指向の入り口にさえたどり着けなかった」と語っており、肝心の新技術を活かす以前に基本事項の詰め直しに追われる状況だったという。
1997年初頭：見えてきた遅れとすれ違う思惑
年が明けて1997年になると、第1次稼働予定の目前になっても開発は難航していた。結局、日本IBMは1996年10月末になって九大病院側に「当初予定の1997年1月にはシステム稼働が間に合わない」と突然伝えることになる。これは病院側にとって青天の霹靂であった。代替策として「一部機能に範囲を絞れば1月稼働も可能」といった提案すら無く、一方的に延期が告げられたことに、病院担当者たちは強い不信感を抱いたという。プロジェクト・マネージャー同士の密なコミュニケーションも欠如しており、延期決定前から両者の意思疎通は十分でなかったようだ。これが最初の綻びとなった。第1次稼働時期は当初計画より9カ月遅れの1997年10月へと大幅に後退する
tumblr.com
。
この延期表明を境に、現場は混乱に陥る。病院側は日本IBMだけに任せておけないとの思いから、一部の協力会社と直接組んで独自にプロトタイプ開発に乗り出すなど、プロジェクト体制は分裂気味になった。一方、日本IBM側の士気も下がり始める。ある協力会社メンバーは「これほど求心力のないプロジェクトも珍しい」と当時を振り返り、リーダーシップ不足だったIBMの姿勢に驚いている。複数の外部企業（延べ10社以上）が関与する巨大プロジェクトでありながら、日本IBMは1997年10月頃まで一貫して主導権を握れずにいた、と多くの関係者が指摘する。誰がハンドルを取っているのかわからないまま巨艦だけが突き進む――そんな不安定な状況であった。
事態を重く見た九大病院と日本IBMは、1997年2月から6月にかけて要件定義のやり直しに着手する。一度作成した要件定義書を更地に戻し、業務フローも含めてゼロから整理し直す作業だ。しかしこのリカバリーにも時間を要し、プロジェクトの遅延はさらに広がっていった。「ようやく問題点に光を当て始めたかに見えたが、時すでに遅し。気づけば頭上に厚い雲が垂れ込めていた」と語る関係者もいる
。プロジェクトは先の見えないトンネルに入り込み、関係者の心にも次第に不安が募っていった。
1997年春：一筋の光明 – オブジェクト指向データベースの導入
混迷を極めるプロジェクトに光が差し込んだのは、1997年春のことである。要件定義の立て直しと並行して、日本IBMはシステムの技術基盤を強化すべく重大な決断を下した。従来のリレーショナルDBではなく、米国GemStone Systems社のオブジェクト指向データベース（ODB）「GemStone」を採用する方針を固めたのだ
tumblr.com
。GemStoneはSmalltalkとの相性が良いことで知られ、オブジェクト指向開発との親和性が高い製品である
tumblr.com
。この採用決定に伴い、GemStone社から複数名のコンサルタントが来日しプロジェクトに参加。停滞していた開発体制の再整備が行われた
tumblr.com
。経験豊富な専門家の助言により設計も見直され、チームはようやく開発の目処を掴み始めたのである
tumblr.com
。
病院側もこの動きを歓迎した。長引く遅延に業を煮やしていたものの、最新のODB導入で性能や拡張性の課題が解決されるならばと期待を寄せた。協力各社の技術者たちも「ようやくトンネルの先に光が見えた」と胸をなでおろした
。現場には久々に前向きな空気が漂う。遅れを取り戻すべく、再結集した開発チームはスパートをかけた。システム全体のアーキテクチャをGemStone前提に再設計し、失われた時間を埋めるため懸命な努力が続けられる。巨大プロジェクトは今、再び軌道に乗ろうとしていたかに見えた。
しかし、その光は長くは続かなかった。1997年7月初旬、プロジェクトに再び試練が訪れる。日本IBMとGemStone社との契約交渉が突如決裂し、参画していたGemStone社コンサルタント陣が全員帰国してしまったのだ。肝心のGemStone製品も利用不能となり、頼みの綱を断たれた開発チームは一瞬にして暗闇に放り込まれた。まさに「悪夢のような出来事」であった。
7月20日になって、日本IBMはようやく協力各社を集め緊急説明会を開いた。日本IBM側の説明によれば、「GemStoneとの交渉決裂は企業（日本IBM）の根幹に関わる問題による」という。詳しい理由として、契約書の条項に**「システムのユーザー等が何らかの理由でGemStone社を訴えた場合、メイン・コントラクタである日本IBMが全ての法的対応を負わねばならない」といった内容が盛り込まれており、日本IBMはこの重い責任リスクを受け入れられなかったのだという。さらに料金面でも折り合わず、3カ月間におよぶコンサルタント8名の派遣とソフトライセンス料などに数億円近い費用**を要求されたことも判明した。法的リスクとコスト高騰――企業として譲れぬ一線を越える契約条件に、日本IBMは最終的に「ノー」を突きつけた形だ。だが、それは即ちプロジェクトの生命線を断つことを意味していた。
この報に接した開発現場は騒然となった。GemStoneを中核に据えて進めてきたアーキテクチャ設計を一から練り直す必要が生じたためである。ある協力会社の関係者は「この時点でプロジェクトの失敗を覚悟した」とまで語っている。大黒柱を失ったチームには動揺と失望が広がった。折しも夏本番を迎え、福岡の空は照りつける日差しに覆われていたが、プロジェクトには再び厚い雲が垂れ込め始めた。
GemStone脱落という非常事態に対し、日本IBMと九大病院は必死のリカバリーを図る。1997年8月上旬、急遽代替のODB製品としてフランスA.D.B社の「Matisse」を採用する決断が下された。Matisseは国内では知名度の低いODBだが、日本でも過去にSmalltalkアプリケーションのデータベースに採用された実績があり、「何とか使えるめどは立つ」と判断されたのである。
しかし代替品とはいえGemStoneとMatisseでは機能に大きな違いがあった。GemStoneで可能だったサーバ側でのSmalltalk処理実行がMatisseではできず、セキュリティ機能も貧弱だったため、開発チームは不足分を自前で作り込む必要に迫られた。この結果、システム全体の設計をクライアント中心処理へ大幅に変更せざるを得なくなり、再び設計の手戻り作業が発生した。炎天下での再出発である。エンジニアたちは寝食を忘れ、懸命にコードを書き直した。
その甲斐あってか、1997年9月末の時点で第1次開発の主要部分を年内に実現できる見通しが立ったという。一度は暗転したプロジェクトにも、わずかながら光明が見えた。病院側も「何としても年内稼働を」という思いで支援を続ける。だが、このとき水面下では別の動きが進んでいたことを、現場の多くは知らなかった。
1997年10月9日、事態は最終局面を迎えた。この日開かれた会議で、日本IBMはSmalltalkによる開発断念と、マイクロソフト社のVisual Basic（VB）への全面的な方針転換を突如宣言したのである。晴天の霹靂とも言えるこの決断に、現場は凍りついた。幾多の苦難を乗り越えようやく目指してきた最先端技術での構築を諦め、当時広く普及していたVBという「オブジェクト指向ではない」開発ツールで作り直すというのだ。九大病院が当初求めた**「純粋なオブジェクト指向」**という条件にVBが合致するかは議論の分かれるところだが
tumblr.com
、病院側ももはや背に腹は代えられない。最優先すべきはシステム稼働そのもの――この苦渋の転換を受け入れる以外になかった。
実はこの決断に至る伏線は存在した。日本IBMは1997年4月頃から密かにVB採用の可能性を九大病院に打診しており、さらに8月頃からは段階的にSmalltalk担当エンジニアを現場から引き上げ始めていたという。ある協力会社のメンバーは「裏ではVBによる開発をすでに進めていたようだ」と振り返っている。つまりGemStone交渉決裂後、表向きはMatisseによる巻き返しを図る一方で、日本IBM本体は別動隊でVB版システムの構築に乗り出していた可能性が高い。振り返れば、日本IBMにはSmalltalkに固執しない理由もあった。同社は翌98年2月の長野冬季オリンピック向けシステムをSmalltalkで構築しようとして失敗し、結局VBで作り直したという“前歴”もあったと伝えられる。アトランタ五輪（1996年）では自社Smalltalkツール（VisualAge）を投入したものの、国内の大型案件では苦戦が続いた経緯があった＊4。豊富な人材がいるVBなら「最後は人海戦術で何とかできる」という計算も働いたようだ。GemStoneとの契約不成立も、IBMにとっては結果的にSmalltalkを断念する良い口実になったのではないか――協力会社メンバーの一人はそんな憶測さえ口にする。
方針転換の発表とほぼ同時に、Smalltalkで開発を担っていた協力会社の大部分はプロジェクトから撤退することになった
tumblr.com
。10月中旬には、多くの外部技術者が病院を後にしている。自ら招いた転換とはいえ、日本IBMにとっても苦渋の決断であった。投入したリソース・費用は莫大で、一からVBで開発し直すのは会社としても大きな後退だ。しかし背に腹は代えられない状況まで追い詰められていたことも事実であろう。IBMの現場責任者は病院側に深々と頭を下げ、「必ずや残された方法で間に合わせます」と約束したという。九大病院の担当者も沈痛な面持ちで頷き、「形はどうあれ、患者さんに影響を及ぼす前にシステムを動かしてほしい」と絞り出すように告げた。
以降、日本IBMは自社内のVB技術者や、自社が持つ病院向けオーダリングシステムのパッケージ製品＊5などを総動員してシステム構築を続行した
tumblr.com
。データベースも、当初IBMが提案していながら見送っていた自社のリレーショナルDB「DB2」を採用する公算が高まった
tumblr.com
tumblr.com
。もはやオブジェクト指向の夢を追う余裕はない。現実的かつ確実に動く仕組みを、一刻も早く届ける――プロジェクトはその一点に向け再編成された。かつて200名近くいた開発陣は大幅に縮小され、構成メンバーも一変する。病院の看護師スケジュール管理など一部のサブシステムは、撤退しなかった協力会社が細々とSmalltalk開発を続けていたが、その姿はもはや主流から外れた存在となっていった
tumblr.com
。ある古参の協力技術者は去り際に「全力を出して戦う前に、白旗を上げてしまったという感じがする」と寂しげに語ったという。こうして九大病院プロジェクトの第1フェーズ――オブジェクト指向技術による野心的挑戦のフェーズは幕を下ろしたのであった。
VBへの方針転換後、九大病院の現場には複雑な空気が流れていた。病院スタッフにとってシステム刷新は長らく待ち望んだ悲願だったが、その中身は当初聞いていた「最新技術の結晶」から一転して、従来型の技術で作られるものになってしまった。「結局、夢物語に終わったのか」という落胆の声も一部にはあった。しかし同時に、「多少古くてもいい、とにかく業務を改善する仕組みを早く動かしてほしい」という切実な声も強まっていた。目指すゴールは変われど、一日でも早く新システムを稼働させ、慢性的な業務負荷を軽減することが現場の切実な願いとなったのだ。プロジェクトチームは日夜作業を続け、簡易な操作研修なども始めながら、年明けまでの稼働に向け突き進んだ。
そんな中、1997年11月3日付の西日本新聞朝刊一面にこのプロジェクトに関する記事が掲載される。タイトルは「九大病院システム未完 巨額費用に批判」。内容は「九大病院はシステムが未完成にもかかわらず日本IBMに月額4,250万円を支払い続けており、税金の無駄遣いとの指摘が出ている」という衝撃的なものだった。同日、このニュースは地元RKB毎日放送（東京ではTBS）のテレビニュースでも報じられ、九大病院プロジェクトは社会問題として一気に世間の注目を浴びることとなった。院内では「患者そっちのけで何をしているのか」といった批判も耳に入るようになり、大学本部や所管官庁からの問い合わせも相次いだ。追い打ちをかけるように外部からの視線が厳しくなる中、病院とIBMはただひたすら開発を前に進めるしかなかった。
結末：プロジェクトの結末と残された教訓
1998年初頭、紆余曲折を経た九大病院の新システムは、当初の構想とは似ても似つかない形でようやく一部稼働に漕ぎつけた。日本IBMは多数のVBプログラマを投入して力技でシステムを完成させ、旧来システムの置き換えを順次進めていった。最終的に納入されたのはSmalltalkでもオブジェクト指向DBでもなく、Visual BasicとリレーショナルDBによるシステムだった。かくして九大病院の「純粋オブジェクト指向システム」への挑戦は事実上の敗北に終わった。現場の医師や職員は、当初期待された華々しい先端技術の恩恵を受けることはなかったが、ひとまず業務に支障のない情報システムが手に入ったことで安堵するより他なかった。プロジェクトは当初の理念を捨てて現実路線へ舵を切ることで、なんとか沈没だけは免れたと言えるだろう。
振り返れば、この失敗の背景には最新技術への挑戦ゆえの困難もあったが、それ以上に古典的とも言えるプロジェクト運営上の Permalink | 記事への反応(0) | 21:29
有益なことは書いてない。ただ現状を記した。
まだなにも就活してない、就活関連のゴミメールを消してたら1日が終わるだけ。
【事前情報】
・夏のインターン未参加
・働く意欲はわりとある
まだ詰んでるとは思ってないけれど、結構全部しんどい。完全に詰む前にどうにかしたい。
面接対策とかSPI、やったほうが良いことはたくさんあるんだろうけど、どれも手付かず。具体的になにから始めるべきか分からない。
わがままでしかないけどインターンには参加したくないし。働く意欲は結構あるのに、全部怖くてなにも就活してない。してる人はセミナーとかインターンとか参加してるっぽい。
薄々、気づいてはいたけどこんな大学じゃ高いGPA取っても就活にほぼ意味ないっぽい。学内推薦もあるにはあるが、弊学の立地的に東京の企業の推薦はまずないと思われる。実際のところ、給付型の奨学金欲しさに成績を取るのをいろいろ頑張っただけで、これと言って自信のある学問分野もべつにない。
漠然とシステム開発（SIer的なやつ、たぶん）に興味があるけれど、プログラミングの経験も特になし。授業でPython、Visual Basicに触れたことがある程度。システム開発に興味を持ったのも、単純に東京ならそういう会社が多いだろうと目を付けただけ。
あー、就活終わんねぇかな、なんにもしてないけど。
はてな匿名ダイアリーはじめて書いたから、いろいろおかしいとことあったらごめん。
今から25年前の1997年ののこと。当時小学生だった自分の1歳年上の従兄が、夏休みにお婆ちゃんの家にこのゲームを持ってきていたのが全ての始まりだった。
「タクティクスオウガっていうゲームがあるんだ。すげーから一緒にやろうぜ。」
従兄に勧められるままゲームを始めたのだが、タクティクスオウガが『すげー』ことはすぐに分かった。
中世ヨーロッパ風の権謀術数渦巻く世界観。重厚なBGMの中で敵味方がターン関係なく立体的なマップで繰り広げるリアルな戦闘。
背中に翼の生えたキャラクターが民家の屋根の上に移動して弓を射ると放物線上に矢が飛んでいくわ、ふわふわと宙に浮かぶ幽霊が魔法を唱え敵が炎に包まれると足元の草が焼けるわと細部までこだわったビジュアル。
とにかく衝撃的なゲームだった。いてもたってもいられなくなり、従兄がお婆ちゃんの家から帰った直後にお小遣いを握りしめて町のゲーム屋さんに走った。
お店のレジで商品を買うときにすごくドキドキしたのを今でも覚えている。スーパーファミコン版のタクティクスオウガの商品パッケージは英語でタイトルが書かれており、フォントが英語の旧字体みたいな形だったので、読み方があっているかな、間違って別のソフト買っちゃうんじゃないかなとすごく緊張したのだ。ぜんぜん自信が無かったが、店員さんにタイトル合ってるか確認して無事に買うことができた。
ワクワクしながら商品を持ち帰り、ゲームを始めたが小学生にとっては、難易度が高く難しいゲームだった。初回プレイ時にはキャラクターの強さを表すパラメータが多すぎてさっぱり分からなかった。
だけど作りこまれたチュートリアルとオンラインヘルプ等の親切な機能がたくさんついていたおかげで何とかゲームを進めることができた。一番助かったのは戦闘中の中断セーブ機能だ。小学生の時には、1日ゲームは30分までというルールがあったので非常に助かった。
さて、ゲームを買ってから2週間くらいの時のこと。難しいながらも俺はどうにかChapter1の終わりまでシナリオを進めていた。このゲームはプレーヤーが会話中の選択肢を選ぶことでシナリオが分岐するんだけど、途中で出てきた選択肢が衝撃的だったのは今でも忘れられない。ネタバレになるので詳細は伏せるが小学生には重たすぎる内容だった。無茶苦茶悩ましい選択だったが、片方を選んでゲームを先に進めてみた。だが、すぐにゲームに行き詰った。キャラクター育成をよくわからずに進めていたので自軍のユニットが弱く戦闘で勝てなくなったのだ。このまま先に進めないのも悔しかったので攻略本を買うことにした。
ここで話は少々脱線するのだが、俺の生まれ育ったのは日本海側の田舎町だ。町の本屋さんはあまり大きくない。なので、地元の本屋さんの攻略本コーナーにはメジャーな作品のものしか置いてないわけだ。ゼルダの伝説とか、ドラクエとかFFとかまあそれくらい。それらに比べるとタクティクスオウガはマイナーだった。苦労を重ねて隣町の古本屋さんで偶然攻略本を見つけて手に入れるまで1か月かかった。その後は攻略本を熟読してゲームシステムの理解を深めて1から再挑戦したのだが、家の方針で1日のゲーム時間が30分に制限されていたので、クリアするまでにはさらに2ヶ月ほどの時間を要した。だけどその分クリアしたときの達成感は大きかった。興奮冷めやらぬ俺は、小学校の同級生たちにタクティクスオウガのすごさを布教したが上手くいかなかった。俺がタクティクスオウガに出会った1997年当時、家庭用ゲーム機の主役はスーパーファミコンからプレイステーションに移行しつつあり、同級生たちはファイナルファンタジー7やファイナルファンタジータクティクスといったスクウェアの大作ゲームに夢中になっていたのだ。
同級生のN君に、「タクティクスオウガってファイナルファンタジータクティクスのパクリでしょ？」と言われたのは傷ついたなあ。なんていうか、自分がイケてると思ったゲームをディスられるという経験がなかったので。残念ながら、うちの地元では最初にタクティクスオウガを紹介してくれた従兄以外に周りでタクティクスオウガファンを見つけることができなかった。
それから2年後の1999年。俺は中学生になり、田舎町の我が家でもインターネットが使えるようになった。ネットが使えるようになってすぐに、以前はまっていたゲームのタクティクスオウガの攻略情報を調べてみた。地元の田舎町にはいなかったタクティクスオウガファンは、ネットの向こうにはたくさんいるようだった。ファンの集めた情報は膨大で、攻略情報にとどまらずゲームの舞台背景の考察やクリエイターの音楽の趣味までカバーしていて、中学生の俺の知的好奇心はガンガン刺激された。ディレクターの松野氏の名前もこの時に知った。余談だが、「タクティクスオウガとファイナルファンタジータクティクスは主要な開発スタッフが同じ」というのも同時期に知ったので、小学生の時にパクリ呼ばわりしてきたN君に対して「両方同じ人が作ってんだよ、適当言うなざまあ」という気持ちが芽生えたのはここだけの話である。
ネットの情報から刺激を受けた俺はゲームの世界観をもっと味わいたくなって、前作の「伝説のオウガバトル」もプレイしてみた。ディレクターの松野氏が好んでいたらしいQueenの楽曲を聞いてみたくなり、生まれてはじめて洋楽のCDを買いにも行った。コーヒーを飲めるようになった時のように、背伸びして少し大人になった気分がした。
そのうち自分でも似たゲームを作りたくなって、おこづかいでVisual Basicを購入したりもした。プログラミングの入門書片手にそれらしい画面までは作ったが、しょせんは中学生。体系だったプログラミング言語の知識がないためサンプルコードのコピペに終始し、1年くらいかかって紙芝居のようなものが出来て終わった。その後は、高校入試・大学入試で忙しくなったのでしばらくゲームから遠ざかっていた。
そこからさらに時が流れて俺は社会人になった。中学生の時のゲーム作りの経験から、ソフトウェアエンジニアの適性は無いなと思ったのでハード系のエンジニアとして就職した。タクティクスオウガから受けた影響は俺の人生を変えたのである。ゲームから遠ざかっていた俺だが、2010年にタクティクスオウガの1度目のリメイクのニュースを聞いて再び情報を集めだした。そこでたまたま開発者の松野氏のプロフィールを見つけたのだが、なかなかの衝撃だった。
まずはスーパーファミコン版のタクティクスオウガ開発時の年齢。発売日の時点で29歳なのである。ゲームの開発期間が2年くらいだとすると、開発開始時は27歳くらいだろうか。その若さであの革新的なゲームの開発指揮を執ってたのかよ！松野氏と面識のあるゲームクリエイターがインタビュー記事で天才という理由が分かった気がする。次に出身地。新潟県の妙高市となっている。地方出身であのゲームの重厚なシナリオを描くだけの知識を身に着けたのか！というのがもう一つの驚きだ。
先に俺の出身地が日本海側の田舎町だと書いた。地方で育ったからわかるのだが、地方はゲームの攻略本に限らずあらゆる情報が都会に比べて乏しい世界だ。タクティクスオウガの世界観を形成している中世ヨーロッパの歴史や文学の知識を松野氏はどこで得たのだろう？世代的にインターネットが無い時代なので、俺が田舎で育った時よりもさらに情報は手に入れにくいはずである。これは今でも気になっているので、今度出る予定のリメイク版の開発者インタビューでだれか聞いてみてほしいところである。
最後になったが、今回出る2回目のリメイク版もすごく楽しみにしている。なんていうか2回もリメイクが出るだけでもすごいのに、2回ともオリジナルの開発メンバーがかかわっているのがまた驚きなのだ。
発売元のスクウェア・エニックスはFF・ドラクエ等の過去の作品をよくリメイクしているけど、オリジナルのスタッフが何度もかかわるケースは珍しくないだろうか？しかも開発者の松野氏はリメイク前にスクウェアを退社しているのだ。それでも声がかかるのだから、本人のカリスマ性がメチャクチャ高いのだろう。過去に会社を辞めた人が2回も開発現場に呼ばれるって相当なことだと思うんよね。
VBA（Visual BASIC for Application）からプログラミングを始めて、「プログラミングとはこういうもの」という感覚を身につけてしまった人は、絶対に他のプログラミング言語の世界に入ってきてはならない。
一度VBAに慣れてしまうと、プログラマとしての正常なセンスを身につけることがほぼ不可能になるからだ。
これは、ヒトラーやポルポトや金日成などを良しとして政治に入門した人が、ふつうの政治の感覚を身に付けるよりも大変なことだ。
VBAでプログラミングに入門した人は、これからもVBAだけをやること。間違ってもプログラマになろうなどとは思わないこと。そして、プログラミングを知らない人にVBAを推薦したりしないこと。
以上。
エンジニア仲間どうしで年に何回か情報交換を兼ねて飲み会を開催していたのだが、今年はコロナウイルスのせいでZoom呑みに変更した。結果的に、これ以上この会意味あるんだろうかと思うようになってきたので吐き出しておく。
最初のうちは感染の拡大や緊急事態宣言による仕事への影響や、リモートワークの生産性の話をしたり、最近上中里にも店舗ができたらしいオメガラーメンの食レポめいた話題が出たりした（参加者にはラーメン好きが多い）。
雲行きが怪しくなってきたのは、いちばん年上の方のムラタさんが会話を独占し始めてからだ。Visual Basic一筋でもう20年以上やっているフリーランスで、いろいろな知識をシェアしてくれて悪い人ではないのだが、もともと朴訥というか突っかかるような話し方をする人で、酔っぱらうとそれに拍車がかかる。最近やっと住宅ローンを組んで町屋にマンションを買ったのだが、コロナのせいで案件が細ってきて、返済がやばいという話をして場を暗くしていた。
そこまではまだいいとしよう。問題は、ユウダイを絶対に許すなとムラタさんが強硬に主張し出してからだった。
ムラタさんによれば、ユウダイという名前の響きがまずよくない。ユウダイはキラキラネームに属するべきもので、一般に広く普及するべきではない。それなのに、平成の頃にユウダイと名付けられた男児が大きくなって社会のメインストリームに大量に出てくるようになって、テレビなどでもごく普通にユウダイを見かけるようになった。これは非常によくない、ジェネリックな名前なら太郎とか一郎にしておくべきであって、ユウダイは許されない、現状はコロナウイルスよりも危機的状況である。もとはといえば、ユウダイなどという響きの名前がかっこよいと思って名付ける、ゆるゆるの平成ママが悪いのだが（名付けるのは母親だけとは限らないと思うのだが、ムラタさんの頭の中ではユウダイは母親が名付けているらしい）、もはやどうしようもない。残された道は「日本全国のユウダイを許さない会」を結成し、ユウダイの社会侵食を防ぎ、いずれ根絶することである。
画面の向こうではムラタさんの目が据わってきて、ボサボサの髪を振り乱し、他の参加者に向かって、お前らも「日本全国のユウダイを許さない会」に加入しろ、おのれっユウダイ、許さんと叫んでいた（リアルでおのれとかいう人をはじめて見た）。若干コミュ障気味のムラタさんは最近祐大か雄大という名前の人事担当者に干されたのかもしれないが、ユウダイに対する深い怨恨の原因は結局不明である。この状況がしだいにだるくなってきたので、iPadの充電が切れそうだから寝ると言ってWindowsをシャットダウンしてから歯を磨いた。
このプログラミング言語はMtGだと多分この色の組み合わせだろう。
みたいなのをまとめたら次のようになった(TIOBEのランキング順トップ50)。
後半は知らない言語もあって怪しいが、おおよそこのようになると思われる。
※改めて見てみると何箇所か違和感があったので最初の版からちょっとだけ修正した。
| 順位 | プログラミング言語 | 色の組み合わせ | 内訳 |
|---|---|---|---|
| 1 | Java | アブザン | 白黒緑 |
| 2 | C | ゴルガリ | 黒緑 |
| 3 | Python | ティムール | 緑青赤 |
| 4 | C++ | ジャンド | 黒赤緑 |
| 5 | C# | バント | 緑白青 |
| 6 | Visual Basic .NET | セレズニア | 緑白 |
| 7 | JavaScript | ボロス | 赤白 |
| 8 | PHP | グルール | 赤緑 |
| 9 | SQL | 無色 | |
| 10 | Swift | 4C(緑欠色) | 白青黒赤 |
| 11 | Go | ゴルガリ | 黒緑 |
| 12 | Assembly language | 黒単 | 黒 |
| 13 | R | イゼット | 青赤 |
| 14 | D | グリクシス | 青黒赤 |
| 15 | Ruby | 赤単 | 赤 |
| 16 | MATLAB | イゼット | 青赤 |
| 17 | PL/SQL | 無色 | |
| 18 | Delphi/Object Pascal | アゾリウス | 白青 |
| 19 | Perl | ラクドス | 黒赤 |
| 20 | Objective-C | エスパー | 白青黒 |
| 21 | SAS | アゾリウス | 白青 |
| 22 | Visual Basic | 緑単 | 緑 |
| 23 | Dart | ジェスカイ | 青赤白 |
| 24 | Scratch | 白単 | 白 |
| 25 | Scala | 5C | 白青黒赤緑 |
| 26 | Groovy | ナヤ | 赤緑白 |
| 27 | Transact-SQL | 無色 | |
| 28 | F# | アゾリウス | 白青 |
| 29 | Rust | マルドゥ | 赤白黒 |
| 30 | COBOL | オルゾフ | 白黒 |
| 31 | ABAP | アゾリウス | 白青 |
| 32 | Lisp | シミック | 緑青 |
| 33 | Kotlin | 4C(緑欠色) | 白青黒赤 |
| 34 | Logo | 白単 | 白 |
| 35 | RPG | ディミーア | 青黒 |
| 36 | Lua | 緑単 | 緑 |
| 37 | Fortran | スゥルタイ | 黒緑青 |
| 38 | PowerShell | ジェスカイ | 青赤白 |
| 39 | Ada | ディミーア | 青黒 |
| 40 | LabVIEW | ディミーア | 青黒 |
| 41 | Erlang | 緑単 | 緑 |
| 42 | Julia | イゼット | 青赤 |
| 43 | ML | 青単 | 青 |
| 44 | Scheme | シミック | 緑青 |
| 45 | Haskell | エスパー | 白青黒 |
| 46 | TypeScript | ジェスカイ | 青赤白 |
| 47 | OpenEdge ABL | アゾリウス | 白青 |
| 48 | LiveCode | アゾリウス | 白青 |
| 49 | PostScript | 無色 | |
| 50 | ActionScript | ジェスカイ | 青赤白 |
見返してみるとおおよそ次のルールに従って決めているような気がした。
緑の判定があやふやな気が若干しないでもない…
| 色 | イメージ |
|---|---|
| 白 | 高レイヤ、初心者向け |
| 青 | 浮世離れ、ベンダー |
| 黒 | 低レイヤ、黒魔術 |
| 赤 | 速い、先進的 |
| 緑 | 基盤、グルー |
| 無色 | 道具 |
何かの参考とかにしたらダメです。書き始めて半年経つんだけどこっからどう直したらいいんだか（何をゴールにしたらいいのか）わからない。。
追記：合流性とか強正規化可能性とか停止性とか、全部チューリング不完全で、事前の静的解析で使うメモリの最大量が確定できる、とかそういう風に読み替えられる人を増やしたいのです、数式の添え字とΣと∫にびびらない人を増やしたいようなもので
数理論理学の一分野である証明論から成長した、数理論理学と理論計算機科学の境界領域の研究領域である型理論(type theory)は、大規模なプログラムの内的な整合性のチェックを行うための方法論を必要とする情報処理技術の分野で関心を集めている。
そもそも「型」(type)とは何か。プログラミング言語は一般的にはレコードや関数といったプログラムを構成する「値」(value)の定義をする道具である(*1)。その言語のコンパイラ作成者はこれらレコードや関数などの値、もしくは第一級の対象(first-class object)の種類を区別する型システム(type system)を必要とする。抽象代数学の観点からすると、「型」とはこれらの値もしくは第一級の対象が属する高階の対象(higher order object)としての空間(space)ないし代数系(algebraic system)で、型システムはそれら「型」とそれら相互の関係(relation)つまり型のなす順序構造(order structure)ないし束構造(lattice structrure)であるといえる。
プログラムを構成する値すべてに型が付くためには、曖昧でない(*2)こと、自己矛盾していないこと、悪循環を含まないこと、それぞれの値の内容をチェックするために無限の時間を要しない(*3)ことなどが必要で、これらを満たすなら、プログラムは有限時間で実行を終え、停止する。手続き型言語では無限ループ、型無しラムダ計算では無限再帰によって型付け不能なプログラムを書くことができるが、型理論はこれらのチューリング完全な計算機を意図しない停止しないプログラムから守る装甲でもあり、再帰やメモリ確保で好き勝手をさせないための拘束具でもある。型が付くプログラムには単に停止するというだけでなく、可能な実行経路（訂正：経路→方法）のすべてで同じ結果を出すなど種々の良い性質がある。
1)この定義は現実に使われているプログラミング言語の特徴を覆い切れていない、狭い不満足な定義だが本稿では都合上この定義に立脚して限定的に議論する。例えば変数(variable)というものを持つプログラミング言語もあり広く使われているが、これについてはレコードや関数と同じように性質の良いものとして扱うことが難しい。難しさの原因は次の注の内容と関連する。近年は変数を扱うかわりに値の不変のコピー(immutable copy)やその参照に名前を付ける機能を持つプログラミング言語が増えている。
2) 現実の情報システムでは、COBOL言語のレコード再定義やC言語の共用体、一般的な関数ポインタやVisual Basic言語のvariant型変数のように、同一領域に異なる型の値が共存する共用型(union type)の値がしばしば必要となる。共用型の値はgoto文を排除した構造化／オブジェクト指向プログラミングにおいて条件キャストやクラス分岐などによる実行経路の複雑さの主要な原因になるが、これは和型(sum type)すなわち相異なる型の非交和(disjoint sum)として定義することで曖昧さなく定義できる。
3) ゲームプログラムやネットワークサービスにおいてしばしばみられるように、入力として無限リストや任意に深い木のようなものを想定する場合には明らかに（条件を満たさない限り）停止しないことが正しい動作となり、この場合は最外周のループを（←どうする？）メモリリークを起こさないなど別の考慮が必要となる。
外部ライブラリが果てしなくあり、
← それはPythonに限ったことじゃないでしょ。JavaでもRubyでもPerlでもCでも同様。主要言語はほぼそうでしょ。
それはむしろ逆。Python のスローガンは There's Only One Way To Do It で、これは Perl のスローガン There's more than one way to do it. を意識したもの。
https://wiki.python.org/moin/TOOWTDI
なお、個人的には C# は良さそうだなとは思うけど、Windows以外のプラットホームではどうなんでしょう。（よく知らない。） これは Visual Basic についても同様。
外部ライブラリが果てしなくあり、似たような機能を実現する方法が複数あるので、本によって書いてあることが違ったりする。
逆説的ではあるが、初心者は、Visual BasicやＣ＃あたりから入るのがいいような気がしてきた。
逆引きハンドブックのような本を片手に、チュートリアル本を手打ちでコードを動かしながら読了すると、Visual BasicやＣ＃の世界は一通り把握できる。わからないことは索引を見ればだいたい出ている。Visual BasicやＣ＃があんまり尊敬されてなくて、限界や不満もあることもだんだん理解できる。
Visual BasicやＣ＃でも相当なことができるし、そこからスマートな言語に移行すれば、比較対象となるものがあるので、守備範囲を自分のペースで広げていける。
その発言した増田ではないが、その発言は少し無責任な気がするので補足。
まずRはやめるべき。
逆に統計くらいでしか使わないので、貴方が算術処理をバリバリやるのでなければ使用するべきではないだろう。
Pythonも言語だが、Rに比べると汎用的であり、かつ機械学習（scikit-learn、NumPyやPandas等の統計ライブラリ主体だけど）などでも使われていてホットな言語である。
ホットな言語だと、書籍やネット情報が豊富にあるので、学ぶ分には困らないのでもしプログラミング言語をやりたいのであればPythonをお勧めする。
そして、Excelマクロも一応Visual Basic for ApplicationというVBを下敷きにした言語なので、その言語を今から学ぶのであればPythonを学べばいいのではないかというのが先の発言の趣旨ではないかと推察する。
しかしながら、言うまでもなく、Excelのセルに書かれたデータをあれこれしたい（主に業務で活用したい）という要件ならVBAが最適である。
プログラム言語って得意／不得意があるから、やりたいことに合わせて使う言語を変えたほうが幸せになれます。（本格的なプロジェクトだと選択の余地はなかったりするけど）
なお、おうちで触りたいというレベルなら私もPythonをお勧めします。
MacでもWindowsでも同じ書き方で、Excelに囚われず色々な処理ができる。AIやIoTなどで需要が高まっているので覚えておいて損はないし。
「これだけ凄いから導入許可をください」と情シスに掛け合えるレベルまで成長したら会社でも使えばいい。
ただ、対象者はちょっとしたプログラミング言語を覚えて、手間がかかることを自動処理とかしてみたいなぁと考えられる人。Excelが効率よく使えれば十分って考えの人にまでお勧めするものではないので、その辺は誤解がないように。
ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。
今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。
「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。
タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー
面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。
Javaの1.0がリリースされたのは1996年1月23日ですね。発表されたのが1995年5月23日でJavaの誕生日といった場合にどちらを取るかで揉めることがあります。
かれこれ20年前なわけで、当時のパソコンというとハードウェアはCPU が Pentium 133MHz メモリ16M とかそんな感じだったかなあ。今どきの携帯電話の例としてiPhone 6sを挙げるとCPUが1.85GHz メモリ 2G ってんだから凄いですね。OSは1995年11月23日にリリースされたWindows95とかそんな時代背景です。インターネットがようやく一般に普及し始めたところでしょうか。
今から思うと相当弱いハードウェアですけども、そろそろVM方式を採用しても良さそうな、そんな時代でした。インタープリタだと流石に遅い、でもC言語のようなコンパイル言語だと"Write once, run anywhere"とはいかない、という判断もあったのだろうと思います。Javaが純粋なオブジェクト指向言語ではなくintなどのプリミティブ型を持つというのは、当時のマシンスペックを考えた場合、ある程度妥当な判断だったと言えるでしょう。これが後々苦しくなってくるわけなのですが。
Javaを作った会社はSun Microsystems(サン・マイクロシステムズ)というアメリカの会社で、2010年1月27日にオラクルにより吸収合併され今はありません。SolarisというOSとSPARCプロセッサでUNIXサーバーの販売で90年代後半までは一人勝ちのような状況だったと聞きます。当時にすでに「ネットワークこそがコンピュータ」（The Network is the Computer）というモットーを掲げてたんだからおかしい。1996年リリースのJavaが標準でネットワーク機能を備えていたのもこのあたりの思想から来ているのかもしれませんね。
当時のプログラミング言語としてC++が挙げられますが、C++でのプログラマへの負担といいますか、ヒューマンエラーの起きやすさといいますか、その辺を改善する目的で開発されたのがJavaだったわけです。
1996年の時点にこんな言語が登場したのですから革新的でした。
いろんな企業がJavaに賛同します。その中にはMicrosoftもありました。この時期、Microsoftは次期のWindows開発用のプラットフォームにJavaを据えようと考えていました。その後、袂を分かつことになるのですが……。
プログラム言語として構文などを見ると、C++を強く意識した構文なのは間違いなく、しかしポインタ演算を廃してポインタを機能を限定した「参照」に置き換えるなど簡素化が多く見られます。C++からはいろんな機能が削られています。関数ポインタ、構造体、演算子オーバーロード、テンプレート((テンプレートについては実装が間に合わなかったという話を聞きます))などなど。そのためC++の劣化であるように揶揄する人もいますが、こうしたものを捨てて言語仕様を比較的小さくシンプルに抑えた点は評価に値すると思います。しかし、今でもこうした削減された機能を愛する人からはJavaを腐す要素として挙げられてしまうのでした。
Wikipediaからピックアップすると1.1での大きな機能追加は
といったところです。当初よりJavaの内部文字コードはUnicodeで文字を表すchar型は16bitで設計されていました。Unicodeは当時それほど普及しておらず、Unicode対応のテキストエディタさえ少なかったと記憶しています。時代を先取りしていると言えますが、大きな誤算はUnicodeが当初16bitのコードポイントに世界のあらゆる文字を格納しようとしていたことで、漢字圏の我々からすると16bit=65,536程度の空間に文字が全部入るわけないだろ！というものだったが故に早々に破綻し、Unicodeは21bitのコードポイントに拡張されることになるのです。これはまた後の話。
なんにせよ、日本語が対応されたのは1.1からで、日本でのJavaの採用が始まったのはこの頃からと言えましょう。
当時のJavaのGUIはAWTというものでしたが、これを用いたGUIの開発は当時は結構行われていたイメージですね。Visual BASIC でGUIを作るプロダクトも結構あったと思います。GUIのためのオブジェクト指向言語としてJavaが使われていたイメージがありますね。JavaBeansもそのための仕様でした。件のsetter/getterの話題に繋がっていくのですが。
JDBCはJavaとデータベースをつなぐインターフェースです。RMIではあるJava VMから別のJava VMにオブジェクトを送って実行する、といったことができます。こうした機能が用意されたことで、ソフトウェアのフロントとしてのGUI、裏方の実装のためのネットワーク機能、データベース機能、さらにはソフトウェアを配布するためのJava Appletという布陣でJavaでのソフトウェア開発が加速していた時代といえます。
Microsoft Visual J++ もこの時代ですよ。
Java 1.1以降のバージョンのものは互換性確認のためにOracle Java Archiveからダウンロードすることができ、今でも入手することができます。もちろん、Java7ですら2015年4月にEOL(End of Life,サポート終了)となっているので、通常利用するのはJava8としてください(本稿執筆時点)。
当時のドキュメントを見るのも一興です。現在と比べると標準APIがかなり小さい。なお、当時のjavadocは今とはデザインが大きく異なります。
この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。
strictfpキーワードは浮動小数点演算をやる人は覚えておきましょう。JavaはパフォーマンスのためにCPUの浮動小数点演算を扱うことが許されており、そのため実行するCPUによって精度が異なることがあるんですね。まあ今時のCPUだと大丈夫だとは思うんですが。
リフレクション機能ではJavaのクラスを抽象的に扱うことができます。設定ファイルに書かれたクラス名のclassをロードして実行する……みたいなことができるんですね。フレームワーク的なものを作る場合には多用することになります。
1.2からは新しいGUIのSwingが採用されました。AWTがOSごとのGUIパーツを用いていたためデザインに違いがあったのに対し、Swingでは統一的なルック・アンド・フィールが用いられるようになりました。まぁ今ならJavaFXを使うのが良いと思います。
初期のJavaはやはりVM方式の実行速度の遅さが指摘されていました。実行時の構文解析を伴わないだけインタープリタよりは早いものの、実行バイナリを作るC/C++よりは遅い、そうした評価です。ここではサン・マイクロシステムズのVMにJIT(ジャストインタイムコンパイラ)が乗ったことが挙げられていますが、JIT自体は別の会社が先駆けて開発していたことは記しておきたいと思います。
JITコンパイラは実行時にJavaのバイトコードを環境のネイティブコードにコンパイルして動かす技術です。この後、JITコンパイラ、動的再コンパイル技術、世代別ガベージコレクションを備えたHotspotといった様にJavaVMは進化していきます。現代では実行時の最適化が進み、大きなスケールで見た場合、Javaの実行速度はC/C++での実装と比べてそれほど遅れるものではありません。遅くても倍の時間は掛からない程度といったところでしょうか。
あとは特記すべきはコレクションフレームワークです。皆が多用しているであろうjava.util.Listやjava.util.Mapといったライブラリが整備されたのがこの時なのです。それ以前はjava.util.Vectorやjava.util.Hachtableというクラスが可変長配列の機能を一手に担っていました。今ではVectorやHashtableは使うべきではありません。
Java の開発はSun Microsystems が主導していたけども、すべてがSunのものだったというわけでもなく。Javaには多くの会社が出資していてその中のひとつがMicrosoftだったわけですね。
Microsoft の Visual J++ では delegate とか独自機能拡張もありましたけど、裁判で問題になったのは J++ でコンパイルしたclassファイルはMicrosoftのVMでしか動かないという部分ですね(他社製のVMで動くclassファイルを作ることもできる)。classファイルがどこのVMでも動くの大事だろ、"Write once, run anywhere"だろ、お前何してくれてんの！と喧嘩になったわけです。当時のMicrosoftはブラウザまわりでも独自拡張がやりたい放題、標準規格？なにそれ美味しいの？みたいなスタンスをあちこちで見せていたものです。
結局、この事件でMicrosoftのJavaはバージョン1.1相当でストップ。好き勝手にやれないなら独自に言語作るわーとばかりに.NET フレームワークと C# といった方向に舵を取ります。
JavaがPC上でのUI開発の主力になろうとした勢いはここで潰えます。
Java SE とは別にこの時代に Java EEがリリースされていることは特記しておきたいですね。これ以後、それまでのCGIに取って代わって、JavaはWebサービスの開発のプラットフォームとして多用されるようになります。
2000年あたりからはJavaはGUI開発というよりは、Webサービスの開発が主流という流れになっていきます。インターネットのサービスが非常に発達していった時代、背後ではとてつもない量のJavaのプログラムが支えていたわけです。ただまあ、こうした産業利用は一般的なユーザーの目にはあまり入らないわけです。一般人からすればJavaといえばJava Appletみたいなイメージはずっと残っていたでしょうが、実体としてはJavaといえばServletという時代になっていたわけです。
企業で用いられる社内システムにもServletは多く採用されました。
理由はいろいろ挙げれると思うのですが
というのが大きな理由だろうと思います。JSPというテンプレートエンジンを用いてHTMLを整形してWebページを作り出す、というアーキテクチャはある意味では便利で簡単でした。
もっともHTMLの表現力に足を引きずられるため、GUIの機能性という点では後退したわけなのですが。それでもメリットが大きいと判断されたのでしょう。というか、まともにGUIを組めるプログラマがほとんどいないから、GUIのシステム開発がなかなか成功しないってのもあったんでしょうけどね。
2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホ、ガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。
そこにdocomoのiアプリ、Jフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ！というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリはちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。
iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。
docomoはiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。
この賭場が、将来にAppleのiPhone, GoogleのAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoはSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。
話を2001年に戻しましょう。
Microsoft離反でGUIのプラットフォームとしてのJavaというものは存在感を弱めていました。この分野の復権に寄与したのはJava 1.4 (2002年2月6日)で導入されたJava Web Startです。
Java Appletがブラウザ埋め込みで動作したのに対し、Java Web Startではブラウザから起動しつつも独立したアプリとして起動するのです。
Webシステムが企業の社内システムに採用された話は先に述べたとおりですが、やはりWebシステムのGUIというのはHTMLに引きずられて貧弱だったんですね。
端的に言えば入力値が数字かどうか？みたいなチェックがなかなか難しい。HTML上でJavaScriptでやるわけなんですが、なかなか気持よく入力できるような感じにはならなかったんですね。
また、Ajaxによるブラウザのページ遷移を伴わない通信というのが出てきたのも2005年ぐらいなので、入力値に対してサーバ問い合わせするようなことはできなかった。当時だと一旦画面遷移させないとできなかったわけです。
こうした事情から、クライアントサイド、要するにPC側でもっとリッチなUIが使いたい！という要望があったわけです。Webシステム使いにくい！という不満の噴出と言ってもいい。そこで出てきたのがRIA (Rich Internet Applications)というわけです。
Javaは1.0時代のAppletからそうですが、ネットワークを介して別のPCにプログラムを送り込み、そこで動作させるという能力を持っていました。それこそまさにRIAに求められる機能性だったわけですね。
RIAの代表とされるのは
あたりです。三つ巴の戦い、どこに軍配が上がるのか！？と注目されましたが、勝利したのはHTML / JavaScriptでした。
Google MAP で注目を浴びたAjax技術、それまでブラウザでは不可能と思われていた高級なGUIをHTML / JavaScriptで実現させました。もうやめて欲しいですよね。せっかく脱ブラウザの流れが来たと思ったのにまたWebシステムに逆戻りですよ。
RIAが失速した理由として考慮して置かなければいけないのはスマートフォンの台頭です。RIAでは端末を選ばずどこでも同じアプリが動かせる点がポイントのひとつでしたが、スマートフォンではそうは行かない。"Write once, run anywhere"を破壊したのはスマートフォンだったというわけです。
しかし、先日インストールなしでアプリを実行するAndroid Instant Appsが発表されたりしまして、結局RIAの思想といいますか、要求というのは今でも息づいているのだなと思った次第です。
1.3 / 1.4 では機能追加はあっても言語構文が大きく変わることはありませんでした。大きく変わったのはJava 5です。この時からバージョニングが変わって1.5ではなく5と表記されるようになりました。
Java5の特徴はなんといってもジェネリクス。それまでjava.util.Listにデータを出し入れするのにはキャストが必須だったわけですが、ようやくキャストから開放され型の安全度がぐっと高まりました。その他に以下のような変更があります。
言語としては随分変わっったわけですが、もうかれこれ10年以上前のことですからこれらの機能が「Java5から導入された」という知識は今となってはあまり必要とされません。これらの機能が使えないJava 1.4で開発をする事案が殆ど無いからです。0ではないのが悲しいところではありますが。
Java 6 (2006年12月11日)がリリースされた後、Java 7 (2011年7月28日) が出るまでJavaは停滞してしまいます。その間にSun Microsystemsという会社がなくなってしまったためです。
Sun Microsystems の経営状況が悪化しており、ついに身売りをすることになりました。身売り先はIBMともGoogleとも噂されましたが結局2010年1月27日にオラクルに吸収合併されました。
Javaの停滞中にはJava VM上で動く非Java言語も台頭してきました。Scalaなどですね。
やや戻って2007年にAndroidが発表されます。Androidの開発言語にはJavaが採用されていますが、実行環境はJava VMではなく、ライセンス的な事情でJava(TM)は名乗らない微妙な位置関係にあります。
Java 5 以降で大きく言語仕様に手が入るのは Java 8 (2014年3月18日)です。並列処理を行うためのStream APIと、そのために簡易に関数を定義するためのラムダ式が導入された点が大きいですね。日付APIも刷新されました。
このように、Javaは1.1の黄金時代から今に至るまで利用ジャンルを転戦しながら産業の土台となって支えてきた歴史があります。ジャンルの趨勢により浮き沈みもあります。今後についても決して楽観視はできないでしょう。Javaを学ぶことはプログラミングを学ぶステップとしては意義はあると思いますが、Javaを学べばゴールというわけではありません。プログラム言語も次世代へと移りつつあります。業界動向には注視していきましょう。
好きに表記すればいいと思いつつも見ると内心もやもやしてしまう。
やっぱりJavaと表記してほしい。Java……かっこいいじゃん！
※ Javaだけだと馴染みのない人もいると思うので似たような例を挙げる。
× SKYPEアプリ ○ Skype × PHOTOSHOPソフト ○ Photoshop × YOUTUBEサービス ○ YouTube
大まかには次の二点だと思っている。
COBOL、LISP、ALGOL、FORTRAN、PL/I、APL、BASIC……
今はFORTRANも新しいFORTRANはFortranと名乗っているし、BASICもBASICの派生はVisual Basicなどと名乗っていたりする。
時代に逆行してJavaをJAVAと表記してしまうとJavaがあたかも古い言語であるかのような印象を与えることになる。
× JAVA ← 1960年代の言語ですか？ ○ Java ← 今時の言語っぽい！
「言語」という接尾辞をつけてしまうと二重敬語のようなまわりくどい印象を与えることになる。
Cのようにググラビリティが低いため止むを得ずC言語と表記するという場合もあるが、Javaならそういった問題は無い。
コンピュータ関係で他のJavaと衝突していないか？それは大丈夫だ。
https://ja.wikipedia.org/wiki/%e3%82%b8%e3%83%a3%e3%83%90
Scalaちゃんは今日も「余裕でした(´･_･`)ﾄﾞﾔｯ」とツイートするんだろうか。
