  |
はてなキーワード: javaとは
■30半ばで年収900万円達成したんだけど、向上心が失われて行って辛い
新卒時は大手SIer(プライムコントラクター)に就職、30手前でユーザ企業に転職して今は上流・下流工程を知ってるITシステムの発注者側の立場にいる。
新卒でIT企業に就職した時はまだ自分がこれからどうなっていくのか明解なキャリアパスは描けていなかったが、
30歳に近づくにつれ、ユーザ側（発注側）に転職してITエンジニアを指揮する立場にならなきゃダメだと思い転職活動を頑張り、結果望み通りユーザ側の企業に転職して現在に至る。
新卒当初はSIerの中でチームメンバー(システム設計・実装・テストをする人) → チームリーダー → PM → 統括PMのようなキャリアパスを描くのが王道だと思っていた。
だが、元請けとは言えどんなに非合理なシステムでも客に言われた通りに作らなきゃいけない下請け企業でPMになったところで大して意味がないことに気づく。
自分に裁量などほとんどなく、理不尽な客に怒られたりバカにされたりする頻度が増えるのに比べて給料は大して上がらない。
担当していたプロジェクトは超大企業のサービス開発。なのだが、ユーザ側の担当者のレベルがびっくりするほど低い。発注担当者は中学生の作文みたいなクソRFP書いてよこしてくる。納期も費用も工数もめちゃくちゃ。しかもやりたいことが全く分からない。多分発注担当の上の奴がテキトーに言ったことをそのまんま真に受けて左から右に流してるだけなんだろうが、有名な大企業にもこんなおバカな社員が堂々と給料もらって平気で定年まで安泰なんだなと思ったら複雑な気持ちになっていた。
だけど、幸か不幸か、そのダメな担当のおかげで20代のうちにユーザ側へ転職しないと仕事のレベルも上がらないしスキルも上がらないことに気づけた。30半ばになって思い返すと、本当に感謝しかない。
まだ30半ばで成功とか失敗とか書くのは時期尚早だとは思うが、給料も大幅に増えてフルリモート・フルフレックス・コアタイム無しの環境を手にしている現状は控えめにいっても成功だと思わざるをえない。
年収も30半ばにして900万円を超えた。
ユーザ企業に転職して思うのだが、ユーザ企業ではITのスペシャリストというのは新卒ではほとんどいない。ゼロとは言わないがSIerのレベルから見ても平均から下のレベルしかない。
なので業務を改善する社内システムの開発や、売り上げに直結するWebサービスのバックエンド・フロントエンドの開発プロジェクトが検討され始めると必ず声がかかり、システムのアーキテクチャを選定する段階から意思決定で主導権を握れる。
こちらとしてもそういう役割を期待されて中途採用されたというのもあるし、何よりこういう会社は新卒採用時にITのスペシャリストを採用することもないので、社内の新卒の誰かと争って主導権をようやく握る、などのようなこともなく、自然と企画、設計、実装、運用まで全て意思決定に関われる。
まさかSIerから転職した身で、自分でTypescript, React, Firebase, Java, C#, C++, SQL, Python, TensorFlowを駆使してゴリゴリ開発して企画を実現し、それがプレスリリースされて正式に会社のサービスとして世に出るようなことになるとは20代の頃は想像していなかった。
ここまでは20代の頃に目指していた理想の30代のキャリアパスそのものだと自負していて大変満足している。
だが、30半ばにして20代の頃ギラギラとした向上心が次第に失われつつあるのを日々実感している。
30前半までは自分で目標設定してそれを達成するのが楽しかったが、30半ば以降は金と評価が欲しくなってくる
30代前半までは日々成長し、技術の選択肢も勉強する度に着実に増え、サービスの企画が持ち込まれるとそれを実現するためには～すればいい、などとパッと浮かんで日夜シミュレーションしてPoCして…というサイクルが楽しくしょうがなかった。
今でも楽しくはあるのだが、これまでとは違って「ただ楽しい」だけでは到底満足できなくなっている自分に最近気づいた。
これまでは金になろうがなるまいが、依頼された仕事は自然と全力で取り組むことができた。報酬はやりがい、のようなところは正直あった。
だが、30半ばを超えてくると物の価値がだんだんとわかってくる。
仕事が忙しくなった時に皆さんはタスクに順位付けをするだろう。
これまではその優先度は難易度で昇順ソートかけて上から順に消化していく方式をとっていた。
すぐできるものから片づけることで、仕事の見かけのスループットが上がる。客観的には仕事が早く進んでいるように見える。
だが、今では、そのタスク・プロジェクトが将来金になるかならないかでタスクの優先順位を検討するようになりつつある。
結果が魅力的でなければそもそも仕事のやる気すら湧き上がってこない。
年収900万円
これは30代半ば、理想のキャリアを追い求めて突っ走ってきた人間の向上心が奪われてしまうような大きな金額なんだろうか。
このへんで満足してあと20数年まったり定年まで過ごすべきなんだろうか。
20代の頃あれだけ将来のキャリアについて真面目に考えていたのに、30代になって40代の理想のキャリアパスが描けない。
うちの会社は年功序列なので、年収も40代になれば自動で1000万円を超える。
このへんで走るのをやめてジョギングに切り替えても、多分未来はそう暗くない。
なのに、アクセルが減速しかかっている自分を冷静に見つめると、何か、本当はもっとできるのに手を抜いている、みたいな罪悪感が湧き上がって止まらない。
はてなを読んでいると、自分と同じ30半ばくらいの年代の人が多くいるように感じる。
30半ばでようやく安定を手にしつつある自分と似たような境遇の人がいれば、
40代に向かってどのような準備をしているのか、さらに上を目指しているのかそれとも今のポジションでの安定を取るのか、それとも会社を辞めて起業を考えているか、など、
恐縮ではあるが共有してほしい。
30半ばでクズになりかかっている自分に、勝手ながら発破と刺激を与えてやってほしい。
よろしくお願いしたい。
最初のプログラミング言語として最もおすすめなのは、Bourne (Again) Shell。通称sh(bash)です。shはUNIXの標準的なシェルであり、bashはその拡張です。現在、多くのLinuxディストリビューションでは、bashが標準のシェルです。以下、これらのシェルの上で動作するコマンド言語およびそれによって作られたプログラムを指して「シェルスクリプト」と呼ぶことにします。
シェルスクリプトを最初のプログラミング言語におすすめする理由は、主にその実用性にあります。ほとんどのプログラミング学習者にとって、プログラミングで実現したいことは、「10000以下の素数を求める」などの教科書の課題のようなものではなく、大量のファイルから情報を検索するとか、インターネットから定期的にコンテンツを取得する、などの具体的なタスクのはずです。シェルスクリプトを使えば、後者のような実用的なプログラムを手軽に作成できます。一方、多くのプログラミング入門書には、制御構文などの細かい説明はあっても、後者のようなトピックはあまり載っていません。というのも、そのような機能は汎用的なプログラミング言語（C、Java、Python、Rubyなど）のコアの機能ではないからです。それらの機能は通常、ライブラリによって提供されます。したがって、汎用的なプログラミング言語で実用的なことをしようと思えば、外部モジュールの読み込みや、場合によってはパッケージ管理ツールを使ったライブラリのインストール方法などを学ばなければいけません。これらは、初学者にはいささかハードルが高いです（たとえば、Webフロントエンドのツール群を初学者が独学でインストールするなどは、ほぼ不可能でしょう）。一方、シェルスクリプトでは、grep、sed、awkのようなシェル上のユーティリティは全て、他の言語における組み込みの関数と同様です。つまり、モジュールのインポートや初期化処理などを行わずに使用することができます。
また、シェルスクリプトは、より本格的な言語やフレームワークへステップアップする過程としても非常に適しています。プログラミング入門書ではほとんど語られないことですが、プログラミングにおいては「プログラミング言語以外の技術」がプログラミング言語自体と同様に重要です。たとえば、ファイルやディレクトリを操作するには、OSのファイルシステムにアクセスしなければいけませんし、インターネットからコンテンツを取得するには、HTTPというネットワークプロトコルを知らなければいけません。シェルスクリプトを使う場合、それら「プログラミング言語以外の技術」を自然に利用します。それらは、プロのエンジニアを目指す上でも欠かせない知識です。また、多くのプログラミング言語では、制御構文を用いて変数の値を更新していくプログラミングスタイルが取られます。一方、シェルスクリプトでは、コマンドの出力を他のコマンドの入力に渡してデータを変換するプログラミングスタイルが取られます。後者のスタイルは、現代のソフトウェア開発では多くの場合、良いスタイルだと認識されています。シェルスクリプトを最初に学ぶことで、そのような良いプログラミングスタイルが身につきます。
シェルスクリプトを体系的に学ぶならば、次の文献が信頼できます。
なんか以前からずっと思ってたんだがRailsというかRuby界隈は宗教というか自己啓発ビジネス臭さえするのがイヤだ
金持ち父さん…とか７つの習慣とか、そういう詐欺のカモっぽい人も多いイメージがある
しかし、Ruby登場当初からやたらとエレガントに書ける、スッと書ける（この「スッ」という表現も詐欺で多い表現なので嫌い）とか、
そんなことは個人的にはどうでも良くて、ソフトウェアを使うユーザーは機能が便利かとかそういう視点でしか見ない、悲しいけど
保守の観点からも美しいソースコードを書こうという意気込みは間違っていない、というか正しいと思う
しかし、プログラマーが美しいコードが書けたと悦に浸る、自己満足におちいっているだけのようにも見えるのが納得いかない、不愉快にさえ思える
C++やJavaのような型のあった時代から、型なんてダセーよな、プレステの方が全然おもしれーよな、を経て、また型に戻ってきてる
型推論云々にかまけてパフォーマンスよりも綺麗なコード、富豪プログラミングからまた元に戻ってきてる
学習コストが高いものほど評価されるような傾向も個人的には感心しない
どうせ同じゴールなのに、そこに辿り着く方法が険しいほど評価されるなんて、プログラマーの美徳の怠惰だのから逆行している
実によろしくない
そういう点ではRustよりもGoやC#の方が評価できる気がする
もちろんRustの守備位置はそこではない気もするので単純比較はおかしいのだけど、ゴールが同じなら自分はC#やJavaで書いて終わらせるのにと思うことがある
別にWebだけでなくコマンドラインでの捨てコードにPHPやJavaScriptも適している
そういう意味ではPythonはやはり強い、Glueだからだろう
正直PHPなんかよりPythonの方が言語としてはおかしい気もするのだけど、正しいとかエレガントが生き残る条件ではないのである
しかし、学習コストとしては低いシェルスクリプトは便利ではあるが流石に古いというか罠が多い気がする
PowerShellの方が使える気がする、少なくともWindowsでは優先的な選択肢になった
生き残るというのはそういうことではないのではないか
プログラミングが好きで、高校の頃にアルバイトしてパソコン買いました。
KotlinでAndroidアプリ書いたり、最近では10年ぶりにSpringFrameworkのコードを書きました。
展示会の説明員やったり、セミナ講師であちこち出張したりなど、思いも寄らない仕事もいただきました。
楽しい思い出も、つらいこともいっぱい有りました。
でも、もういい。もう疲れた。
1日2時間の残業とか、片道1時間の通勤ですら耐えられなくなりました。
直近の案件は、契約延長のお話を頂いていたんだけど、9月に体調を崩し、体重が9キロも減ってしまってとても続けられないので、打ち切ってもらいました。
残業ありません。通勤しなくてもリモートワークで良いですよって仕事があれば良かったのですが、そんな都合の良い案件はなく、今後の展望も見込めないので、辞めようと決めました。
なにより、辞めると決めたら、とても気分がスッキリしたんですね。
プログラミングは好きなので、これからもアマチュアプログラマとしてプログラミングは続けたいです。
あとはプログラミング始めたい方のための入門サイトみたいなの作ろうと思ってます。
新人教育とかOJTなどの評判は良いので、果たして私が説明上手なのか、ちょっと試してみたいのです。
Apple M1の高性能の理由について、ネットはクソみたいな解説記事に溢れている。
技術に明るいはずのはてなーですら某AVライターの間違いだらけの記事に釣られて、300ブクマ超が集まっていて嘆かわしい。
それもこれも後藤センセーがいつまでたっても解説記事を書いてくれないせいではあるが、公開情報が少なすぎるせいでまともなライターほど記事を書けないのも理解できる。
違います。
そもそもM1はDRAMをSoC化／ワンチップ化していません。M1がやっているのはSiP(System in Package、複数チップをワンパッケージに組み込む）であって、eDRAMによるSoCとは全く異なるものです。
SiPとSoCはJavaとJavascriptくらいには違います。
違います。
HBM系のメモリを採用していたらメモリ帯域は大幅に向上しますが、M1は標準DDR系メモリをワンパッケージ化しているだけなので、帯域もレイテンシも変わりません。
帯域はM1 MBPとIntel MBP(Ice Lake)でチャネル数同じ、前者はLPDDR4X-4266、後者はLPDDR4X-3733なのでメモリ帯域は14%しか向上していません。また、x86／x64最新世代のTiger Lake／ReniorはLPDDR4X-4266に対応しています。レイテンシはM1が96.8ns、Tiger Lakeが98.4nsでほぼ同等です。
Apple M1の実力を最新世代のIntel/AMD CPUと比較。M1が両者を大きく上回る結果ににあるように、SiP化によって消費電力の削減は期待できます。
違います。
SoC-DRAM間がマザーボード上で30cmあったとしても、電気信号の伝送にかかる時間は片道1nsです。仮にSiP化で物理的距離が1/100になったとしてもレイテンシ100usが98.02usになるだけで、CPUにとってDRAMが絶望的に遠いことに変わりありません。
違います。
まず、同一チップ上のCPUとGPUが同一のメモリーコントローラ／DRAMを共有するという意味では、Intelは2011年のSandy Bridge、AMDも2011年のLlanoからUMAです。一歩進んだメモリ空間の共有、コヒーレンシの確保という意味でも、AMDは2014年のKaveriから対応していて、この点においてM1に革新性はありません。
違います。
上記のSandy Bridge、Llanoの世代からかつてのノースブリッジがCPUに取り込まれたため、2011年以降のモバイルPC向け”CPU”のほぼ全てにはGPU／メモリーコントローラが含まれています。
かつてのサウスブリッジはIntelは今でもワンチップ化こそしていませんが、2013年のHaswellからMCMでワンパッケージ内には収められています。AMDは2014年のCarrizoからサウスブリッジ機能もCPUに取り込まれています。
この意味で、x86／x64のモバイルPC向け”CPU”は、かなり以前からSoCです。
違います。
NPUを活かせるアプリケーションは2020年現在では未だ限定的です。もしNPUの有無によってUXが決定的に改善されるなら、NPUありのSnapdargon 8cxを積むSurface Pro Xは同世代のSurface Pro 7よりずっと快適でなければなりませんが、そのような事実はありません。
違います。
CISC／RISCの論争は20年以上前に終わった話です。その後CISCはRISCの美点、RISCはCISCの美点を取り入れたので、現代のCPUはISAがCISCか／RISCかだけで性能が決定されることはありません。
歴史的経緯からx86／x64のデコーダが複雑になりがちなのは事実ですが、5W以下のローパワープロセッサの開発へ向かうIntelにあるように、ISAの差による消費電力増は10～20%のレンジで、さらに性能増によって相殺される分、電力効率の差としてはわずかです。
頑張って最適化してIPC上げたのと、スマホ由来の積極的なDVFS・クロックゲーティング・パワーゲーティングで浮いた消費電力を回しているからです。
気が向いたら書きます。
そこから2年経って、この2年間でTypescriptだったり, M1だったりとソフトウェア開発者の中では大きなトレンドなりニュースに触れられた。
今となっては、始めて聞いた＆触った時には???だったトレンドも随分消化できるようになってきた。
そこで、太古、昔、ちょっと前、の大きなソフトウェア業界の変化やニュースを体験した先駆者がその時にどう感じたのかを知りたくなったので教えて下さい。
大昔ならCの登場とか?
ソフトウェアないしIT業界で実際に手を動かしている１個人としての大きな変化やニュースに接した際の感想を教えてほしいです。
どの会社が~とかはあんまり興味ないです。開発者個人の経験がいいです。
宜しくお願いします。
とりあえず動くソースコードでそれなりの規模のが欲しければGitHubからcloneしてくればいいんだよなあ。
と言っても、元増田が「gitって何？」のレベルだとそこで話が折れてしまい、
gitとは？バージョン管理とは？ハッシュ値とは？みたいになってしまうので説明する側も辛い。
自分が説明される側でも説明する側でも辛いのは、それだけ専門性が高い分野ではあるのだろうけど。
自分だって自分の専門外のことをそれ専門の人にまくし立てられて説明されるの辛いｗ
ソフトウェアの命名規則が天邪鬼でなければ、スタート地点はmain.cppみたいに類推もできるはず。
デバッガでメインルーチンからブレークポイント打つなりしてポチポチ動作させたり変数の中身の変化を確認していく。
色々なクラスとかソースコードを眺めて全体像を把握し、そこからコアとなる機能、自分が知りたい箇所を目指す。
ソースコードがある、デバッグ情報があるなら、当たり前だが変数名や関数名があるので類推しやすい。
（Javaとかで難読化してると、逆コンパイルできても変数名や関数名は分からなくされていて読み辛かったりする。
いや、だから難読化なんだけどｗでも、.classファイルしかなくてもそれで中の肝心のアルゴリズムは読めてしまったりする）
自分には大した技術はないと自分でも思ってるけど、普段やってることをまったく知らない人に説明するのは難しいだろうね。
というか、できる人やプロだって新しいビルド方法なんて分からない。
C++ならcmakeやpremakeは分かるけど、ninjaってなんじゃ？みたいなｗ
そこで新しい道具に手を出して躓くことも多々あるし、
他人は他人で自分の知らない道具、好きでない道具を使ってたりもするわけで、ビルドするために嫌々最低限即席で学んだりする。
Javaはそんな間違ってないんでないの？
というのを初めて知ったときちょっとショックだったんだけど理由はなんでなんだろう
なんか文法的にミニマムな言語作りたいんだなあ、という意思は伝わってくるんだよなあ
goroutineは凄いんだけど、なんか削りすぎてない？という気がした
Rustと違ってGoは一通り勉強したけど結局使ってないという
まあ例外あっても、それこそ全体をtry-catchで囲んで握りつぶすことは大抵どんな言語でもできそうだよなあ
go言語のアプローチだとerrorは関数の戻り値なので、戻り値を受け取らない関数呼び出しという
一見何の問題もなさそうに見えるコードが、errorを握りつぶすというよくない挙動を引き起こす。
throw-catchのアプローチならばerrorを握りつぶすには意図的にそれを行うためのコードを書かないといけない。
かといってerror戻り値を必ず受け取らねばならないよう言語仕様で制限を入れると、
かつてJavaが犯してしまったように例外処理がめんどくさすぎることになる。
まず、コンピュータゲームがほとんど巷に存在しない時代にPongが登場すれば、そりゃみんなゲームにワクワクしたはず
アメリカにアーケードゲーム筐体だってそのものがない時代なんだから
だからスティーブ・ウォズニアックだってApple IだのIIだのでPongの実装はやっていたはず
それもスティーブ・ジョブズは売りにしてたはずだ
Pongが動作すると、次はブロック崩し（Breakout）が作れる
プログラミングのコツの一つは他人のプログラムを改変することだ
Pongが動くなら、そこからドットやドットの塊をVRAMに描画することは可能だと気付くだろう
でも、単なる壁打ちや対戦ゲームだったPongのゲーム性を大きく変えることになる
日本のゲーム企業タイトーは、このブロック崩しをインベーダーゲームに「再々」発明した
これも実現可能であることは誰でも分かるが、ゲーム性を大きく変えることはある種の発明だと思う
ちなみに、孫正義はタイムマシン商法が得意で、このインベーダーゲームをアメリカに輸出し大儲けした
相変わらず、左から右、右から左に他人のものを移動して儲けるのが上手い（いや、本心から褒めてるんですよ
インベーダーゲームでは、ブロックは上から段々と降りてくることになる
また、ブロックが左右に動く、UFOは高速に動く、手前のバリケードがありドット単位で破壊される
プログラミングのコツの一つである、他人のコードを改造する、は本当に素晴らしい再発明を起こしてくれる
Pong → ブロック崩し → インベーダーゲーム → ギャラクシアン → ゼビウス → グラディウス → 斑鳩だの東方だの弾幕避けだの何だの
に繋がっていくわけだが、
この矢印での「パラダイムシフト」の段差が高いほど、ゲームに対するワクワク感が増すと自分は考える
つまり、ギャラクシアンのようなグラフィックからゼビウスが登場したときは、
安っぽい言葉で形容するなら一大センセーションというかエポックメイキングという感じだったわけだ
しかし、今の時代、2Dシューターにそんなにワクワクはあるだろうか？
というか、マニアでない奴が口を挟むな、と言うぐらいタコツボ化しているように思うのだが、
寧ろ、様式美とかお約束が守られてることがプレイヤーの安堵感につながる
2Dシューターができれば3Dシューターが作れるのも自明である
ただ、マシンのグラフィクスの能力が低かった時代にはリアルタイムでの3次元CGの実現が難しく、
アメリカではベクタースキャン、つまりオシロスコープやブラウン管テレビの走査線方式が主流だった時期もあったが、
アメリカではワイヤーフレームの3Dゲームが実現していた時代、日本はファミコンに向かっていた
自分にはハードウェアによるスプライトに固執し、束縛され過ぎているかのように今からすると思える
一方、ファミコンのスプライトの数はMSXと比べると段違いであったが、
ファミコンは2Dスプライトベースのゲームだけを前提としていた
つまり、ファミコンでブレゼンハムのアルゴリズムによる直線を引くとか困難だったのではないだろうか
自分はファミコンの開発はよく知らないのだが、ファミコン版のテグザーは酷すぎると思った
MSXの方がファミコンよりもトータルのグラフィック性能が劣るにも関わらず、
こうやってだらだら書き連ねてみると、
つくづくワクワクするのは何だってアーリーアダプターの段階であって、
そのあと結婚だって何だって倦怠期？ワクワクが減少する時期がやってくるのである
何もない状況にパラダイムシフトを起こす何かがやってくるとワクワクするのであるならば、
乳児はこの世界の何もかもにものすごくワクワクしていると思われる
乳児でなくなると、この世界の変化しないものは常識として脳に定着して、つまらないものにさえなる
でも、若ければまだまだ体験していないことはあるわけだ
若ければギャラクシアン → ゼビウスがどれだけスゴかったかなんて知らんし、俺も知らんｗ
でも、ギャラクシアンより先にゼビウス見た世代だけど、凄いなあとは思ったんだよな
だって、自分の場合はギャラクシアンを飛び越えてゼビウスだったんだから
逆にギャラクシアンの方を後から知って、古臭いゲームだなー、レトロだなーと思ったんだから
（ただ、ギャラクシアンの曲線的な軌道はゼビウスなんかより凄い発明に思うんだが。整数演算なんだよね？
ただ、レトロレトロとバカにする人はプログラマーでないとかなんだろうけど、
ゼロからコード書くって、何もないところから作ることを考えさせられるわけで、
それはゲームのプログラムを書くならば、ゲームの基本のPongから考えさせられることになる
例えば、ゲームプログラムを書くときSDLとかSFMLみたいなライブラリは使うかもしれないけど、
自分も何か新しいゲーム開発のライブラリとかフレームワークとか検証するときは、
から始めて、次に倉庫番、簡単なブロック崩し、テトリスを実装するとかやることにしている
そこで開発の大まかな進行とかフレームレートとか、色々分かってくるわけだ
ジョン・カーマックがどこで語ってたのか忘れたけど、最近のFPSは完全にMOD開発になっていて、
そのMOD開発の費用はどんどん膨らんでいっていると言ってた気がする
つまり、レベルエディットとかキャラクターだアイテムだとか、そういうコンテンツの緻密な開発だけが進んでいる気がする
GTAみたいなゲームもFPSとかで培った技術の集大成にすぎない
可視領域をどう区切るか？遠くの建物にLODを使うか？インポスターを使うか？とかそういったゲームエンジンの話は、
マシンパワーの向上やUnityなどのゲームエンジンの登場であまり議論する意味がなくなってきている感がある
もっとも、Unityなり導入すれば簡単に作れるという話ではないと思う
思うが、もうゼロからチマチマCのベクトル計算のコードを書く時代ではなくなっているのは確かだろう
カーマックはその高騰するMOD開発をマインクラフトは意図的に安価にしたと言ってた気がする
つまり、マインクラフトであれば子供でもゲームを改造する体験ができるようになる
それはマインクラフトの開発者であるnotchがそういうゲーム開発に対する思想を持っていたからだ
私はnotchはシンプルなものを積み上げるのが好きなように思っている
ただ、jsdo.itだかに投稿していたソフトウェアレンダリングのコードは北欧のメガデモっぽさがあって、
読もう読もうと思って未だに読んでいないことを今思い出した
文章書き直す気がないまま、だらだら書いてみたが、読み返して自己分析するに、
まず、ゲーム開発でなくてもそうだが、
まず何かがあって、それをコピー改造した何かが生まれる、この連続で物事は進化していく
手塚治虫があって、それを高橋留美子がコピー改造して新しい漫画が生まれ、
次に若い漫画は高橋留美子の漫画をコピー改造して、また新しいものが生まれていく
開発する側も消費者もワクワクするのは、この改造して新しい何かが生まれる、守破離の離のインパクトであろう
黎明期はその離のインパクトが大きいが、どんどんそのインパクトは小さくなっていく
そして、ありふれたものが溢れるようになっていく
これが成熟期と言える
しかし、その成熟期に溢れるものは様式美であり、お約束であり、マンネリズムである
あの時代は3DOが先行したがコケたり、ドリキャスも登場してコケたり、面白い時代だったのである
ただ、今の時代にああいう群雄割拠というか、戦国時代というか、そういう活気がゲーム業界にあるようには思えない
VR元年って毎年言ってない？というツッコミは分からんでもないが、まだまだVRは伸びると思う
物体を触れないなんてのはまだまだVR市場が伸びる余地があるということだと思っている
あと、FPSみたいに走るゲームだと自分も走るのか？ということになるけど、うーん、ルームランナー方式はなあ…
あと、これも自分は専門でも何でもないので、
というか、この文章自体がダニング＝クルーガーなのは認めざるを得ないわけだけど、
敵というかNPCというか、今の時代だったら高度な汎用性のある人工知能をゲームでも実現するべきだと思うわけで、
そうすれば当然、同じセリフを延々と喋るドラクエの村人みたいなのは笑い話にしかならなくなる
ゲーム内に高度な人工知能が実現すれば、それらと会話したり、それらとマルチプレイと同様の感覚の連携プレイが可能になる
今までと同じことを繰り返しててもワクワクしないし、
どんなに優れたツールや設計思想などがあっても、使う奴がダメだと全く無意味。弊社もWebアプリを作ってて、RESTだのFluxアーキテクチャだのいろいろ導入を試みたが、ほとんど無駄に終わった。
どんなクソ組織でも効果があると確信持って言えるのは上の3つだけ。1つ目は初歩的すぎると思われるかも知れないが、筆者の想定するダメな組織・ダメなプログラマというのは、このレベルの連中を含む。
静的型付け言語（サーバーサイドならJavaやC#、フロントエンドならTypeScript）を使わせれば、少なくともコンパイル時に分かるエラーは修正させられる。
というか、ダメなプログラマに動的型付けの言語は触らせてはいけない。必ずそのプロジェクトは半年後には保守できなくなる。
テストは強制的に書かせるし、テストのないクラスや、通らないテストあったらコミットできないようにする（それは容易にできる）。
もう一つの方法は、そもそも優秀なエンジニアしか参加できないようにすること。たとえば、Scala、Haskell、Erlang、Common Lispなどで書かれていれば必然的にそれが分かるエンジニアしか開発できないし、こういう言語を自主的に学習しているエンジニアは優秀である可能性が高い。
