  |
はてなキーワード: プログラマーとは
これは私自身が、また私以外の業界から転職されてきた方々を見てきて、これではないかな？と思うことがあります。
それはプログラマー以外の仕事は、常に本番環境である、ということです。
たとえば営業であれば、取引先との打ち合わせも見積もりも、ひとつひとつが「本番」です。やり直しはききませんし、次の瞬間には社外の人の評価や信頼がかかっています。接客や教育、医療、建築…どの仕事もそうです。人や社会に直接つながっている以上、テスト環境など存在しません。常に結果が「本物」として記録されていくのです。
その点、プログラマーの世界は少し違います。そこには「テスト環境」があり、「デプロイ」という明確な境界があります。エラーが出ても、まずはコードの中で直せばいい。実験と修正を繰り返しながら、本番に近づけていける。失敗から学ぶ仕組みが、仕事の構造として組み込まれているのです。
もちろん、だからといってプログラマーが気楽だという話ではありません。むしろ「テストできる」ことが前提だからこそ、完璧なシミュレーションを作り上げる責任が生まれます。本番環境を一歩でも誤れば、大きなシステム障害につながることもある。
けれど、「試すことが許されている」という点で、プログラマーの仕事は他の仕事とは質的に異なる、と私は感じます。多くの職業では「やってみること」そのものがリスクになるのに、プログラマーだけは「やってみること」が日常の一部として制度化されているのです。
たとえるなら、プログラマーの仕事は「楽屋のある職業」なのだと思います。
多くの仕事は、目を開けた瞬間からステージの上に立たされるようなものです。接客業ならお客さんの前に立った時点で本番が始まっていますし、教師なら教室に入った瞬間に舞台袖はありません。間違えば生徒が戸惑い、客が離れ、取引が破談する——それらはリハーサルのない一回きりの公演です。
一方で、プログラマーは楽屋での準備が長く、ステージに出る時間は驚くほど短い。コードを書く、テストする、修正する。その多くは「誰にも見られない暗闇の中」で進んでいきます。そして、いざデプロイという名の本番を迎えるときには、すでに何十回ものリハーサルを終えているわけです。
そう考えると、プログラマーの面白さは「安心して失敗できる時間」が保証されていることかもしれません。社会の多くの仕事が「失敗しないための緊張」で成り立っているのに対し、プログラマーは「失敗を前提とした反復」で完成に近づいていく。
この違いは、単に働き方の差ではなく、「世界との関わり方の構造の違い」にまで広がっているように思うのです。
その境界線こそが、プログラマーとそれ以外の仕事を分ける根本なのかもしれません。
プログラマーの失敗は、基本的にログに残ります。誰が、いつ、どんなエラーを出したのかが正確に記録されます。でもそのログは、「修正可能な痕跡」であり、「過去をなかったことにできる記憶」です。失敗は恥ではなく、改善のためのデータとして保存される。むしろ失敗を残さない方が恐ろしい——なぜなら、それは検証も再現もできないバグだから。
一方、他の多くの仕事での失敗は、ログではなく「印象」として残ります。顧客の言葉、上司の記憶、誰かの評価。修正パッチは配信できませんし、「新しいバージョンをリリースしました」と言っても、その印象が上書きされるとは限りません。世界が自動でキャッシュをクリアしてくれることはないのです。
だからこそ、非プログラマーの人々は無意識のうちに「失敗を避ける設計」で働くようになります。完璧に準備してから発言する、波風を立てないように動く、見せ方に細心の注意を払う。彼らの本番環境には“try-catch”構文が存在しないのです。
一方で、プログラマーは「例外処理」を書くことを前提に思考する。すべての失敗を想定し、起こり得るエラーを受け止める枠組みを最初から組み込む。そこには、世界を「壊れ得るもの」として見る柔軟さと、「壊れても直せる」という信念がある。
その考え方の違いが、やがて人の思考様式や言葉の慎重さ、さらには生き方そのものにまで影響していくのではないか——そんな気がしています。
覚えておいてください。これから踏み出す世界には、「実行ボタンを押す前にコンパイルしてくれる親切な仕組み」はありません。人の言葉も、会話も、メールも、一度送ったら基本的に戻ってきません。Undoはありませんし、Gitもありません。世界は常にmasterブランチで動いています。
ですから、まずはその“冗長な曖昧さ”を恐れないでください。コードの世界ではif文で整理できたことが、現実の人間社会ではあいまいなまま動いています。それを「エラー」だと考えないでください。人間は仕様書なしで動いているシステムです。バグだらけで当たり前なのです。
現実の世界では、修正にも時間がかかりますし、再デプロイにも人の気持ちというプロセスが関わってきます。あなたが「パッチを当てました」と言っても、相手の心がそれをすぐに適用してくれるとは限りません。
ですから、焦らずに。ログを読むより、人の表情や沈黙を読む方が大切になります。
そして何より大事なのは、「テスト環境がない」という世界でどう生きるかを考えることです。
あなたの言葉は、すべて本番環境に直接デプロイされます。その恐ろしさの裏側には、同時に大きな自由もあります。本番だからこそ、本気が伝わります。人間関係も仕事も、常にリアルタイムで最適化されていくのです。
プログラマーらしい慎重さと、非プログラマー的な即興性。その両方を持てる人は、なかなか多くありません。もしあなたがその橋渡し役になれたなら、どんな職場でもきっと大きな価値を発揮できるはずです。
世界はtry-catchのないシステムです。しかし、恐れることはありません。catchできない例外に出会ったときこそ、人は成長します。これからのあなたのフィールドには、テスト環境の代わりに「出会い」と「経験」が用意されています。それもまた、悪くない環境だと思います。
息子はプログラマーになりたがってるけど、これからの時代はどうも論理的思考力とか数学力、英語力よりコミュ力がプログラミングに必要になってくるっぽい。
生成AIが直接機械語やバイナリを出力するようになるのではないか、という問いは本質的に間違っている。
自分は、まだ素朴なニューラルネットワークで光学文字認識(OCR)の精度を出していた頃から似たようなことを考えていたので、少し他人よりも蓄積がある。
これは、Large Language Model(LLM)を開発する企業が資金を集めるために多少誇張した未来を語るという文脈では大目に見た方が良いが、正確性に欠ける。
本質的な問いは、なぜ我々は、ノイマン型コンピュータを用いて、主記憶に置かれたプログラムをCPUを用いて実行する形式をとるのか、というものである。
まず、筋の悪い反論から説明し、妥当な反論にも触れたうえで、本質的に問うべき課題を説明する。
これは明確に、いいえ、と答えることが出来る。
最初こそ人間による補助は必要だが、LLMを含むAIは明確な目標があれば人間のデータなしでも十分に学習することが出来る。
これは身近なところでは将棋、有名なものだと囲碁で実証された研究が存在する。
そのため、単純に「機械語は人間による学習データが少ないので扱いが難しいだろう」という反論は成立しない。
そういったものはLLMではないだろうという指摘は可能だが、LLMでそういったAIを出力することは限定的とはいえ現在でもできる。将来できないと言うだけの論拠にはならない。
英語に限った話ではなく、人間が意思疎通に用いる言語である自然言語(natural language)は、曖昧さやばらつきがある。
これを形式言語(formal language)という、曖昧さを無くして語彙や文法を限定した言語に記述しなおすことで、厳密にする手法がある。
この形式言語での表現が、アルゴリズムやデータ構造になり、現代のノイマン型コンピュータにおけるプログラムそのものと言うことが出来る。
なぜ限定的かと言えば、形式言語の一種であるプログラミング言語には曖昧さが許容されているからである。
ほとんどのプログラミング言語では、同じ目的を達成する為に複数の記述が許容されている。
主に、人間が書きやすいから、とか、複数の人間で書きやすいように、といった理由で、曖昧さが許容されている。
そのため、機械へ命令するためには厳密さが必要だからプログラミング言語が必要だ、と言う反論は妥当ではあるが、弱い。
なぜ大統一プログラミング言語のように、自然言語の意図を機械に伝えるための形式言語が一種類になっていないかと言えば、人間の認知能力には限界があるからだ。
そのため、簡易で曖昧さを含むために最適化はできないが十分な性能を持つプログラミング言語や、非常に複雑で記述量も多くなるが大人数で作業するには最適なプログラミング言語などが複数存在する。
これらはいずれも、人間が楽に記述できる形式言語であったり、人間同士が齟齬なくコミュニケーションを取るために必要な形式言語である。
ありていに言って、人間や人間たちが理解可能な形式言語でないと機械にその意図を伝えることが出来ないから、と言える。
ただし、コンパイラから出力されたニーモニックやLLVM-IRを監査できる人間は現代では非常に少なく、現状ほぼ監査なく受け入れていると言って良い。
何故非常に少なくなったかと言えば、機械に伝える意図が大規模になり、単純にマンパワーが足りなくなったので監査しきれなくなっただけに過ぎない。
（もちろん、途方もない努力の末に最適化が進み、ほぼどの様な書き方をしても最適な機械語が出力されるようになったから、とも言える）
同様の理屈で、単純に大規模になり監査が間に合わなくなったので、受け入れるようになる未来が来ないとは言い切れない。
本質的な問いは、なぜ我々はノイマン型コンピュータを用いて機械に意図を伝えるのか、である。
ASIC(Application Specific Integrated Circuit)と呼ばれる、特定の用途向けの集積回路がある。
蟹チップとして、Realtek社のNIC(Network Interface Card)をご存じの方も多いと思う。
必要十分な処理があらかじめ定まっているのであれば集積回路を組んだ方が高効率省電力にできる。
暗号化や復号もASICで行われることが多く、ブロック暗号はその性質上集積回路での実装が容易であり、それに向けた研究も行われている。
一般的にも、ハードウェアエンコーダーなどでお世話になっている人も多いと思う。
ではなぜ、我々は身近な全てをASICにしないのか。
それは、書き換えできず、単純な処理しかできず、大量生産しないとコストに見合わないからである。
FPGAのように、ハードウェア記述言語を用いて集積回路を書き換えるものも、ほぼ同様の理由で研究開発用途や産業用途に留まっている。
（一部のPLD (Programmable Logic Device)は根強く産業利用されているし、大規模に展開され高効率を要求されかつ書き換えを求められるネットワーク機器では一部採用が進んでいる）
汎用的で書き換えが可能、伝える意図を変更できる様々な処理が可能な機械に価値があるから、である。
ここ半年から1年で急激にLLMの性能が上がったと感じている人と、コーディングツールとしてLLMの利用が洗練されたと感じている人の間には溝がある。
自分は、LLM自体は順調に進歩し続けているが、それほど劇的な変化はない、という立場をとっている。
これはモデルそのものが質的に大きく変化したと感じないから、である。
しかし、プログラミングの世界に限って観ると、コーディングエージェントや実利用では大きな変化があったと思う。
この、"コーディングを取り巻く環境としてのLLM利用"という文脈は、"LLMの進化"という文脈とは異なる、という点は頭の隅にでも覚えて帰ってほしい。
これは、LLMから直接と言う意味であれば、個人的にはNOだと思う。
ただし、LLMに指示すればバイナリが出力されるという意味であれば、個人的にはYESと答える。
この二つは明確に異なるので、今後自分の意見を述べる際には区別すると良いと思う。
コーディング周りの環境が劇的に整備されつつある、という話題に軽く触れたのはこのためで、LLMが直接バイナリを出力しなくても、結果が同じであれば人々はそれほど気にしない。
例えば、現時点でもローカルのLLMに指示するとGO言語で書かれたコードが生成され、ローカル環境に合わせたシングルバイナリが出力される一連のパイプラインを組むことはできる。
自分の想定する、未来のAIがバイナリを直接出力するというのは、この延長にあると思う。AIがイコールLLMである必要はどこにもない。
少しでもクラウド上でのサーバー処理について触れると、廃棄容易性(Disposability)は俎上に上がる。いつでも落とせていつでも捨てられる、という性質のことである。
こうした、単機能バイナリをコンテナ等に載せて処理し、日に数度デプロイするような環境だと、LLMがバイナリを出力するというのもそれほど遠い未来の話には思えなくなる。
LLMが機械語を出力する未来は個人的には来ないと思う。それは難易度が高いからではなく単純にメリットが少ないからである。
ただし、パイプラインが組まれた一環として、LLMがバイナリを出力する未来は、それほど不思議には思わない。現時点でも可能である。
単純なLinterから進んで静的解析や、動的な結合試験が組み込まれているCICDパイプラインが珍しいとまでは言えない現代において、来るべき近未来像としては妥当性がある。
（その場合、ソースコードはログとして機能し、テキストで保管が容易な、次回以降変更可能なコンテキストの一部になるだろうと思う。今後変更不要ならHDLでFPGAを弄った方が早い）
現代人のすべてがJavaで同一の書き方をしているのではない現状において、自然言語では揺らぎが強すぎて形式言語ほど意図を機械に伝えきれないという反論は、弱い。
それよりは、現代のLLMはコンテキストウィンドウが人間の数倍～数十倍程度で、適切に分割して処理しなければならず、大規模なソフトウェアを丸ごと扱えるほどではない、という反論の方が適切である。
ただ、LLMに適したプログラミング言語が生まれるのではないかと言う予測には懐疑的である。既存のプログラミング言語を使う方が人間が読みやすい。
AIが、人間が欲しいバイナリに適したプログラミング言語をLLMを用いて書き、LLMを用いてレビューし、テストツールでテストし、コンパイラでビルドし、ツールでデプロイし、実稼働するという未来予想図が、荒唐無稽とは思えない。
LLMに適したプログラミング言語が生まれる未来よりも、(冗長であっても)人間可読性の高いコードやSelf-documenting codeが生成される未来の方が、来そうに思う。
また、おそらくこの文章のもつくであろう「どんなプロンプトで書いたのか」という、一定以上の長さの文章はLLMが出力しただろうと仮定する人間が増えている(そしてある程度の妥当性がある)現状において、プロンプトで指示してデプロイまでされる未来はそこまで遠いとも思えない。
ただ、購入できるハードウェアの性能とコストが律速になるので、よほど特殊な(CPUやGPUの設計をLLMが劇的に改善する)状況にならない限り、5～10年はプログラマーが消えることは無いと思う。
金に糸目をつけないのであれば、再来年当たりからはLLMレビューのみで仕様バグ以外のほぼ無いプロダクトが世に出てもおかしくは無いと思う。
東大卒で都知事選で得票数が暇空より多くて他の選挙で勝って本当に政治家になれてITリテラシーがあり年下なのに嫁がおり資産は暇空よりも上、もう完全に安野は暇空の敵
一時期暇空が山田太郎叩きしてたのも、安野が大学時代に山田の講義を受けていたと判明したのがきっかけだった
安野叩きが再燃しこれはもう止まらねえよ
暇空茜
@himasoraakane
安野たかひろの嫁のりなくろがなけなしの2000万円を突っ込んでくれたって言ってたのは完全な嘘ってこと？
暇空茜
@himasoraakane
暇空茜
@himasoraakane
安野たかひろ、動画でも確認したんだけど、寄付3000万あつまって自腹は2000万出してます、お金余裕あるんだねと言われて
暇空茜
@himasoraakane
安野たかひろの嫁、最低3.6億あるけど2000万をなけなしかのように装ったことを認め、しかも「別に総資産全額つっこんだとはいってませんw貯めてた金をつっこんだことは事実ですw草w」
まあ一生こいつを信頼することはないな
暇空茜
@himasoraakane
10億持ってる人（当時の時価総額は違うかも）が、それを隠して2000万円をつっこんだのを「ためてたお金全部」と言って寄付をつのるのはちょっと僕はナシと思うかなあ
安野たかひろさんが言うことを信じることは一生ありえないですね
暇空茜
@himasoraakane
安野たかひろがすごい！とかはひろゆきの嫁とかホリエモンとかうさんくせー奴らが言うけど、こいつらも信者も安野たかひろがどうしてすごいのかは説明してくれない
暇空茜
@himasoraakane
わかってないアホが意味不明な反論してくるんだけど、日本人は「嘘つきは泥棒の始まり」と躾けられて育つから嘘つきが嫌いなんだよ
暇空茜
@himasoraakane
問題とされてるのは、安野たかひろ夫婦が、貯めてた金2000万全部突っ込みました！寄付してください！と詐欺的な表現、普通に嘘としか思えないことを言ってたことだとわからないわけないですよね？それってあなたの感想ですよね？
暇空茜
@himasoraakane
安野たかひろはカップラーメンを忙しいから食ってるそうですが、両手が塞がるし汁が飛び散るし栄養も味も良くないカップラーメンとかアホかね？
暇空茜
@himasoraakane
安野たかひろ「貯めていた2000万円全部出しました！選挙のために寄付してください！」安野たかひろ「資産3.6億円+α」嘘つきでは？ @YouTube
より
暇空茜
@himasoraakane
最近入ったプロジェクトのマネージャー（いわゆるPM的な）の指示が理解できない。
ちなみに自分は名目上プログラマーなんだけど、何でも屋みたいな人。
コーディングすることはもちろんなんだけど、要件の調整もするし、設計もする、テストもするし、スクラムマスターもするし、課題管理もする。
例えばこんな感じの指示がくる
「今回作る資料ですが、これは希望というか要望というか、気付いたことなんですが、この資料はある程度の業務知識を持った新しいメンバーが読んでもいい感じで理解できるように作って欲しいです」
ボカシて書いているが、これはいったい業務指示なのだろうか、それともただの個人の感想なんだろうか。
そして、新しいメンバーがいい感じに理解できる内容とは、どういう人を想定しているのだろう。ある程度の業務知識とは...
いったい俺は何を書けばよいのだ、という悩みに行き着く。
もう1つ
「今回のバグ修正を行うときは、別のバグも気にしながら、もし別のバグに関連していそうな箇所を発見した際には、その感触を共有してください」
まぁ「お気持ち察して善きに計らって」ということなんだろうけど、善きに計らうとそれはそれで成果物に色々突っ込んでくるんだよなぁ...
https://x.com/i/status/1983745679433269398
このCMへ対して一部のユーザーが「M.U.G.E.Nじゃねぇかｗ」の様なコメントを付けている。
この「M.U.G.E.N」こそが格ゲー界の公然の秘密である。
M.U.G.E.Nとは、1999年にElecbyte社が公開した、ユーザー拡張型の2D格闘ゲームエンジンだ。「キャラクターやステージを自由に自作して追加できる」という画期的な仕様により、本来なら交わるはずのない別作品のキャラ同士を戦わせる「ドリームマッチ」を実現できるツールとして、2000年代のネットの片隅で熱狂的な支持を集めた。
だが、このエンジンには致命的な「暗部」がある。
全盛期に最も広く利用された「WinMugen」と呼ばれるバージョンは、実は正規にリリースされたソフトウェアではない。
開発元のElecbyte社が一度消息を絶つ直前に、本来は非公開だった次期バージョン（Mugen 1.0）のベータ版が何者かによってリークされ、それがアングラサイト経由で広まったものなのだ。つまり、WinMugenを使っている時点で、それは「流出した未完成の開発データ」を勝手に使っている状態に他ならなかった。
正直に申し上げて、M.U.G.E.Nというコミュニティは、このエンジンの出自も含め、著作権的に見れば限りなく真っ黒に近いグレーだ。
「キャラクターやステージを自由に自作して追加できる」という画期的な仕様は、実質的に「既存の商用格闘ゲームのキャラクターをファンメイドで移植できる」環境を意味していた。
つまり、スプライトのぶっこ抜きである。この事実は否定しようがない。
だからこそ、格闘ゲームのプロプレイヤーや開発者、そして我々のようなコアな格ゲーマーにとって、M.U.G.E.Nは長らく「名前を言ってはいけないあの人」のような存在だった。
みんな知っている。家でこっそり触ったこともある。でも、表立って「M.U.G.E.Nで遊んでいます」とは口が裂けても言えない。そういう「公然の秘密」として、格闘ゲーム史の影に存在し続けてきた。
けれど、あえて今、その「技術的・文化的な功績」についてだけは語らせてほしい。
法的な問題を一旦脇に置いて（肯定するわけではないが）、なぜあそこにあれほどの熱量が生まれたのかを言語化するならば、「あれはプログラムによる同人活動だったから」という結論に行き着く。「絵」ではなく「挙動」を模写するのだ。
同人作家が、好きな漫画のキャラクターを愛ゆえに模写し、自分の手で二次創作漫画、そこから更に発展してBL同人などを描くようにだ。
M.U.G.E.N職人と呼ばれた人たちは、好きな格闘ゲームのキャラクターを愛ゆえに解析し、自分の手で動かそうとしていた。
彼らにとって、リュウの波動拳やテリーのパワーウェイブのドット絵は、単なる画像素材ではない。「完成された美」であり「憧れ」そのものだ。
しかし、画像をM.U.G.E.Nに持ってきただけでは、それは動かない。
憧れのあの技を放つためには、中身のエンジン……つまりプログラムを、自分たちの手で一から組み上げる必要があった。
彼らがやっていたのは、MS-DOS時代から続く古臭い仕様のスクリプト言語を駆使して、最新ゲームの挙動を「コードで模写する」という作業だった。
これは、プログラマーやゲームデザイナーにとっての一種の「写経」であり、エンジニアリングの側面から愛を表現する手段だったのだと思う。
さらに特筆すべきは、単なる模倣に留まらない「実験場」としての側面だ。
M.U.G.E.N界隈には、既存の格闘ゲームの枠組みには収まりきらないアイデアを形にするクリエイターたちもいた。
ドット絵からアニメーションまで全てを一から描き起こした「完全新規オリジナルキャラクター」の制作。あるいは、商業ゲームならバランス崩壊として即座にボツになるような、複雑怪奇かつ斬新なシステムの実装。
「売れるかどうか」を考える必要がない同人活動だからこそ、そこには尖ったアイデアが無数に投入されていた。
プレイヤーが操作することを放棄し、キャラクターに搭載されたAI（人工知能スクリプト）同士を戦わせる。
そこでは「いかに強いAIを書くか」というプログラミング競争が勃発し、時にはゲームのプログラム仕様の隙を突くような「凶悪キャラ」「神キャラ」と呼ばれる人知を超えた存在が生み出された。
そして、それらが公平に戦えるよう、有志によって厳格なレギュレーション（階級分け）が整備され、毎日のように動画サイトで大会が開かれる。
これは、ある種の「レジェンド級プロ格ゲーマーを超えた理論値格ゲープレイのシミュレーション」であり、eスポーツとは全く異なるベクトルでの技術的進化だったと言える。
現在では将棋や囲碁などのAI同士が対戦し、その強さを競うことは珍しくないがM.U.G.E.N界隈ではそれらよりもずっと前に対戦AIを専門的に書く人たちが認知されていたのだ。
漫画界で「同人出身」がある種の実力の証明(例えば高い評価を受けていた同人作家が商業誌での新連載が決まり、同人作品を知る一部界隈で話題)になるように、実はゲーム業界にも「M.U.G.E.N出身」の才能が確実に存在する。
例えば、Steamで世界的な評価を得た2D格闘ゲーム『Skullgirls』や『Indivisible』でリード・アニメーターを務め、『熱血硬派くにおくん外伝 リバーシティガールズ』にも関わったJonathan "Persona" Kim氏は、かつてM.U.G.E.N界隈で伝説的なスプライト改変職人として知られた人物だ。
また、セガ公式の『Sonic Mania』でコンポーザーを務めたTee Lopes氏も、キャリアの初期にはM.U.G.E.N等のファンゲームへの楽曲提供で腕を磨いていた。
最近の例では、ホロライブのファンメイド格闘ゲーム『Idol Showdown』が記憶に新しい。
このゲーム自体はUnity製だが、プロジェクトを牽引したGura_D氏や、美麗なドット絵を統括したアートリードのSodan氏は、海外のハイレベルなM.U.G.E.Nプロジェクト（Hyper Dragon Ball Zなど）出身のベテランだ。
彼らにとってM.U.G.E.Nは、GitHubやUnityが普及する前の時代における、ポートフォリオであり実験場だったのだ。
もっとも、彼らのように自らそれを語り、その出自が明るみに出ることは業界の慣習としては稀なケースなのかもしれない。
プロ格ゲーマーを含めた多くのプロフェッショナルたちが、過去の経歴としてM.U.G.E.Nを語ることはない。そこには、あえて触れないという「暗黙の了解」が、今も静かに横たわっている。
「俺ならもっとこう動かす」「もしもこのキャラとあのキャラが戦ったら」という妄想（IF）を、絵や文章ではなく、実際に動くゲームシステムとして出力する。
それは紛れもなく「挙動の二次創作」と呼べるものだったはずだ。
現在はYoutubeなどのSNSを通して格ゲー界のプロフェッショナルへ気軽に話しかけられるようになったが決してM.U.G.E.Nの話を振ってはいけない。無視されるか立場上、表面上、便宜上M.U.G.E.Nを否定する発言しかしないだろう。
二次創作の経歴がある人へ「盗作ってどう感じますか？」と質問しても多くは「悪いことだと思う」と返すしか無いはずなのだから。
現在は、Ikemen GOのようなMITライセンスのオープンソースエンジンが登場し、エンジンの権利問題はクリアになった。Steamでは『The Black Heart』のように、この系譜から生まれたインディー格闘ゲームが正規に販売され始めている。
かつてのM.U.G.E.Nが抱えていた著作権侵害の罪は消えない。
しかし、「憧れのキャラを自分の手で動かしたい」というあの熱量と、そこで培われた技術的土壌までを「黒歴史」として封印してしまうのは、あまりに惜しい。
あれは無法地帯だったかもしれないが、同時に、間違いなく数多くのクリエイターを育てた、一つの巨大な「同人界隈」でもあったのだ。
