  |
はてなキーワード:ライブラリとは
いま突如訪れる家事をやりたくない感じは、
うわ！ってシンクに食器が溜まっていたらあちゃー！って思うのよね。
そんな日もあるわよね！って肯定的にすればいいわって思うの。
自動で洗ってくれるけれど、
そこまで食器を持っていくのが辛い辛みがあるのよね。
まあ私が怠けているから悪いんだけど、
ぱぱっとやっちゃって片付けたいわ。
小さい食洗機なので、
先発隊グラス類行って！って
実質私の担当時間は5分も満たない食洗機に食器を突っ込むだけなので楽っちゃ楽なの。
でも今は家事したくないムーブメントの波に襲われてしまっているから、
その食洗機に食器をパズルゲームのように入れて上手く上手に食器入れるの私苦手なのよね。
そう思ってスイカゲームは私は食洗機に入れて流してしまったのよね。
だからテトリスとかぷよぷよとかのなんていうの？パズルゲーム苦手だわ。
テトリスは落ちてきてもどっちに回したらいいのかあたふたするし、
壁に当たって折返しの連鎖が出来ないので、
だから限りなく私のゲームライブラリにはパズルゲームってないのよ。
ほぼないと言っても過言ではないぐらいの言い過ぎではないわ。
あえて言うなら、
あ！思い出したけれど
だからさ、
突如現れるゲーム本編とは一切関係ない作風のパズルゲームがミニゲームで出てくるときあるじゃない！
これを解かないと配電盤の電気が通らなくて電車が走らせられなくて以降ストーリー進めない強制パズルステージ！
あれきたら私苦手だわ。
まさにモノレールが故障しているから配電盤を直すって言うパズルイベントステージ！
数字を組み合わせて順番に電気が通るように考えないといけないこれ私進研ゼミでも習ってないので、
あれは辛かったわ。
ドラクエでもなかったっけ？
岩を押して、
こうなったらお手上げね。
そこだけは攻略方法を見ちゃいたい気分になっちゃいなよ！って思うけど、
まあ私の少なからず持ち合わせているパズル魂を燃え上がらせるの！
でも燃え上がらせるなんか薪的なものがないから焼べることが出来ないの！
たしかゼルダの伝説のブレスオブザワイルドでもパズルゲームみたいな祠なかったっけ？
私はクリアできなくて誇れなかったぐらい、
その祠パスしたけれど、
私が見るからに億劫になっているブレスオブザワイルドの次の作品のティアーズオブザキングダム、
あれは自分で部品を集めて乗り物を作るパズルゲームみたいにして突破しなくちゃいけないのよね？
私の苦手そうなのがたくさん詰まっているようなゲームな気がして手を付けることを恐れているのよ。
だから
お料理って意味でもゼルダの伝説の中でいわばパズルゲームみたいなものじゃない！
材料を組み合わせて凄い効果の高い冒険が一気に有利になるアイテムを料理するやつ！
もうあれ私お料理組み合わせて作る系のも苦手だわー。
でもあれはあれで塩バナナ炒めはリンクのハート全回復の最大ハート量を超える黄色いハートが25個もおまけでついてくる超回復塩バナナ炒めは絶品だったわ。
それが有効となると、
新しい料理にはチャレンジしないそれなんてクッキンアイドルアイ！マイ！まいんちゃん？って思うの、
なんか朝ドラで結局パイロットに大成しなかったのがいまいちなエンディングだったのは忘れられないわ。
もしさ、
そんなゲームにアドベンチャーを燃やしている暇があるなら他のゲームにアドベンチャー魂を焼べるわよ！
だったら私目の前のシンクに溜まっている食器を食洗機に入れるゲームをやるわ！って鼻膨らましながら言うの！
でさ、
私が絶対にその食洗機ゲームでクリアできないただ1つのポイントがあって、
お茶碗とかのひっくり返したとき糸切りの茶碗の底にある円い台座あるじゃない！
あそこにずーっといつも水が溜まってて乾燥しきれないのよ！
その角度が難しいの！
あれさえクリアしたらテトリス棒がスパーンと入って4列消える気持ちよさを味わえるのに、
加減を調整して上手く斜めにお茶碗を仕掛けるでしょ？
あるときは
水の水流の勢いで、
お茶碗がご飯を盛る正しい向きのまま食洗機の中に留まっていて、
水が満載になっていて乾燥どころの話ではなかったぐらいあれはゼロ点だわ！って
せっかく、
フライパン洗い！パーフェクト！
うわ、
パーフェクトゲームが掛かっていたのに！
あのお茶碗の底の部分って水が流れるようにちょっと切り込み入れられないのかしら？って思うのが悔やまれるわ。
でもこれも私がお茶碗の角度を最終調整しなかったラストステージの難しさを露呈した形になっちゃったのよ。
でもとりあえずは
お茶碗とか全部洗えてシンクは片付いたのでこれは100点としたいものだわ。
うふふ。
久しぶりに鮭おにぎりにしたわ。
特に意味はないんだけれど鮭感を口いっぱいに感じたかったのかもしれない本能の導かれるままに、
味付き海苔じゃないベタベタしない海苔かは一応慎重にみて選んだ鮭おにぎりよ。
あれたまにトラップみたいに、
ノールックで具の美味しさだけを追求して棚から選んだおにぎり、
味付き海苔でフィルムを剥いて手に取った瞬間のべたつきであちゃー！ってなるときない？
あれ避けよ。
おにぎりは手を汚さずに片手で持って歩きながら食べられるニューヨークスタイルで食べられるのが最大のメリットなのに！
気を付けないと台無しよ。
キャンセルして再注文したら、
すぐ届きます！って、
もー無駄に1か月待っちゃったじゃない。
でもすぐ届くってわーい！って感じね。
なので
レモン炭酸ウォーラーを恋しがりながら飲むホッツ白湯ストレートウォーラーってところ。
すいすいすいようび～
今日も頑張りましょう！
1.4ナノを目指すのは結構で、まぁそりゃ頑張ってトライアンドエラーやってりゃいつかは稼働し生産にこぎつけるだろうが
量産開始したころには他社はその先に行ってる。
それでは商売にならないんです。
１８ヶ月程度で次のプロセスルールが稼働し始める、稼ぎの本丸はそちらに移る。
半導体価格は月次（年次ではない）３％下がる。DRAMはもっとエグい。
１個一万円の半導体が翌月には９７００円になり、１年後には７０００円になってる。
３年後だと３５００円。そういう世界。
１個１万円をどれだけ長く維持できるかが勝負になる。この期間で一気に稼ぐ。
半導体産業の面白いのは、では世代交代したら古い設備は用無しか？
現代のデジタル機器には無数の半導体が組み込まれており全てが最先端である必要はない。
例えば、ルーターだったり、制御装置だったり。ASICだったり。
話が逸れるが、この仕組みに気がついたのがスティーブ・ジョブズ。
iPhoneが登場するまで携帯電話向けのSoCは２，３世代古い設備で製造されていた。
サーバーやパソコン向け最先端プロセスルールの半導体工場が稼ぎ終わった後の設備で組み込み用SoCが作られており、
携帯電話もそれらが使われていた。
ジョブズのアイデアは「最先端で作れば携帯の性能一気に上るじゃん」
もちろんOSやコンパイラ、ライブラリ群の整備も大きいのだけど、この半導体チートが「iPhone=高性能」の印象を作った。
だから歩留まりも収率も良い。ウェハー単価は高いけど採算は取れる、ジョブズはこれに気がついた。
Android勢がこれに追いつく（最先端プラントで泥用ARMが製造される）のに５年かかった。
ラピダスに話に戻るが、２ナノ。1.4ナノを作るのはそれほど難しくはない。試作品なら。
しかし大規模装置産業の半導体工場は試作と量産技術はまったく別物。
試作品ができたら量産はあと一歩、にはならない。別物。
例えば、一昔前話題になったフッ化水素、１２ナインとか、日本が強いよね。
半導体を作るには大量に使う。
試作品、ラボレベルでメーカーから届いた試験管の少量を扱うのと、
ローリーで輸送され（ここでも汚れる）、プラント内に備蓄され（ここでも汚れる）、配管が適切に設計され、制御され、製造装置に供給されるラインが構築され、その配管で送液され（ここでも汚れる）、半導体が洗浄され（ここでも汚れる）、使用済み廃液が確実に回収する仕組みが構築されており。。。
書けば簡単なようでめちゃくちゃ難しい。別次元の技術やノウハウがある。
そしてTSMCの強みはこれらの製造インフラを高レベルで高速に構築し改善できる、それらの人材も揃ってる、育ってる。
つまりプラント立ち上げが早く競合他社が追いつく前に１個１万円で売り切ってしまう。
競合他社が追いついたときには７０００円になってる。
TSMCは１万円で売り切って爆益を出し、それを原資に次のプラントを立ち上げる。
1.4ナノだろうが３年後には１個３５００円にしかならんのです。
TSMCは戦略的に旧世代の価格を下げてくるのでさらに出遅れ他社の利益率は下がる。
一日でも、一ヶ月でも早くプラント稼働させるのが利益の源泉なのだが、日本企業、しか国策官営企業にそんなもん不可能なのです。
んなもんラピダスの中の人だって百も承知だろう、でも頑張ってる、頑張ってるフリ、宣伝。
ちなみにJASM（TSMC）熊本ですら22nmしか作っていない。
台湾の経済安全保障のため最先端を避けたという説明だけど、ウソです。
作れないの。
天下のTSMCプラント立ち上げ部隊ですら、異国の地でサプライヤー全て巻き込んで最先端プロセスを稼働させる事はできない。
彼らは新工場の設計、プロジェクトマネジメント、立ち上げ、安定量産、これらの業務にそれぞれ精鋭の専属部隊がいる。
実際、JASM熊本も公式な量産開始から一年経ってもフル稼働はしていない。アメリカで大トラブルを起こしているのも御存知の通り。
量産って難しいんです。簡単じゃないんです。小さな外的要因一つで製造は止まる。
夜は憂鬱な気分になる。
ディスコードのボイチャに集まってゲームをしているのを見かけた。遊んだことのあるゲームだった。
私はそのディスコードに遊び相手を求めて参加したのでボイチャに参加したいと思ったが、そうしなかった。
なぜなら私はそのゲームを遊んだことはあるが、今は遊ぶことは愚か所持すらしていなかった。ゲームから与えられる精神的ストレス、それを乗り越えるための特訓、それらから得られる達成感を感じることができず、ただ感情的になってしまい、フレンドと遊んでいても周囲に当たり散らすような行為に走ってしまうことがほとんどだったからだ。そのゲームは私には合わなかったので、最終的に自ら遊べなくした。steamで買ったのでライブラリから削除した。
そのディスコード鯖ではそのゲームが定期的に流行るので、その度に対戦で賑わうボイチャを眺めてどうして楽しめないのかと嫉妬していた。
steamでライブラリから削除したゲームは30日以内であればゲームを復元できるため、嫉妬と羨ましさに耐えきれなくなって復元し、遊べるような気を感じ、ストレスを溜め込んで当たり散らし、ライブラリから削除した。
それを数回繰り返した。
最終的に私が別のゲームにハマって定着したことでストレスの繰り返しは終わり、今ではライブラリからそのゲームは完全に削除された。またそのゲームを遊ぶには一万円弱を支払わなければならない。
サーバー内で散々当たり散らしたことを反省して、私はそのゲームの話題を口にしないことにした。他の話題の時はそのゲームの時よりは冷静になれるので、会話をすることができた。
そうしてしばらく経って、そのゲームをまたディスコード鯖で遊んでいるのを見かけた。
聞くところには、その一人はそのゲームのストレスで机に穴を開けたらしい。にも関わらず、遊び相手に囲まれている。
何が違ったのか。
ほぉ。まるで「ライブラリの移植なんて余裕っすよ」と言わんばかりの口ぶりだな。お前、自己放尿レベルで気持ちよくなってるが、現実を何も理解してねぇぞ。
いいか。「同じ機能を移植するだけ」って発想がそもそも低能の証拠だ。Pythonの強みは言語としての表面構文じゃなく、生態系として積み重なった最適化と実績だ。
NumPyやPandas、Scikit-learn、PyTorch、全部C/C++やFortranの実装をPythonバインディングで何層もラップしてる。
しかもメモリ管理、スレッドセーフティ、BLAS最適化、GPUオフロード、それらを組み合わせたときの挙動の安定性まで含めてライブラリって呼ぶんだよ。
「決まったインターフェースで移植するだけ」とか言ってる時点で、頭の中で想定してるライブラリが、せいぜい数千行のユーティリティレベルだろう。
企業が内部で作るって？そりゃ車輪の再発明だよ。しかも、Pythonが10年かけて磨き上げたアルゴリズムや最適化を、数ヶ月の業務開発で再現できるとでも？寝言は夜だけにしろ。
あと、「いまどきの言語ならそんな大変じゃない」って、まるでNode.jsがCythonやNumbaのようなネイティブ統合の層を持ってるかのように錯覚してるのが痛い。
V8のJITで高速化できるのはせいぜいスクリプトレベルの話。数値演算、メモリアクセス、スレッド制御を最適化できる数学的基盤の厚みがまるで違うんだよ。
Nodeで同じことをやろうとしたら、JSからC++アドオン叩いて、型変換のコストで死ぬだけ。
つまり、「移植できるだろ」って発言は、Pythonの生態系を単なるコード群だと思ってる愚か者の自己放尿なんだよ。
それは「パルスジェットなら自作できるだろ」と言ってる鉄クズコレクターと同レベル。動くかもしれんが、効率も精度も再現性も自己放尿レベル。
Node.js厨が「Pythonのライブラリは移植できる」とか言うのは、「俺でもベートーベンの交響曲ぐらい耳コピできる」と言ってる音感ゼロの自己放尿芸だ。
Delphiなら開発環境に付属するヘルプがとても充実しているはずだ。
ObjectPascalそのものは、これまでのご経験があれば習得に大きな問題はないと思う。
どちらかというとDelphiはVCLというライブラリを使いこなしてこそなのだが、これの説明はヘルプがかなり役に立つ。
実は俺も20年以上前にDelphiの兄弟分であるBorlandC++Builder(BCB)というのを仕事で使っていた。
これもVCLが肝だったのだが、ちょっと慣れたら参考書なんて不要でヘルプでだいたい片が付くようになった。
膨大な内容だが、一度全体を目を通してみるのが良いだろう。
DelphiやBCBのユーザたちはメーリングリストで情報をシェアしあっており、悩み事があればその過去ログがよく検索でヒットして重宝したんだけど今は厳しいね。
メールアドレスが載っているので、自分だったらダメもとで連絡してみる。
こちらに関しては、会社に公式ドキュメントが残っているんじゃないだろうか。
20年前の、紙の資料がそれこそ山のようにあってもおかしくない。
ベテラン先輩に「会社の中にあるUNIFACEの公式ドキュメント全部のありかを教えてください」と言うのだ。
結構ちゃんとしている中小JTCなら、廃棄してないんじゃないかな。
これも出てきた文書すべてにざっと目を通せばとっつきやすさの順番がなんとなくわかるので、その順番どおりにじっくり読んでみるのをお勧めする。
望みはない気はするが、サポート契約してないかも念のため確認してみるといい。
サポート窓口が使えたら随分違うはずだ。
近頃のWeb記事や書籍はよく噛み砕いて初心者にも解りやすく書かれているから、元増田はそういう情報源じゃないと嫌なのかなと感じた。
確かに公式ドキュメントにそうしたフレンドリーさは期待できない。
特に慣れていない分野だったら最初の内は本当に訳わかんなくて読むのが辛いけど、理解できないうちは頑張って三度目を通そう。
眺めているうちに慣れていく。
絶対に助けになるはずだ。
----
「My Job Went ToIndia」の改題改訂版が「情熱プログラマー」なんだ！ありがとう発注したわ。（たぶん達人プログラマーと混同して読んだ気になって読んでないパターンだわ）
俺の悪文のせいで意図が伝わらなかったであろうブコメがあったので、要旨だけ書き直しておくな。
ただ忘れないで欲しいんだけど、TerraformメンテしてAWSとかGCPで立ち上げてサービス公開するまでの速度は、相見積取って稟議通して部材調達から入ってた時代に比べると爆速だけど、人間の技術屋の需要は増えてる。
俺は、「マスタリングTCP/IP 入門編」を人間が読んで理解するのは古いよね、という時代にはならないと思ってる。
Slerが自前で手元で試すようになるから～ってのも懐疑的。SIerやメーカーが内製すると必ず子会社作って分離、ぼく発注者きみ受注者にしたがるので。これは技術じゃなくて感情とか経営の問題。
（ただし、Slerが7payみたいなことやらかすのでは？って疑問なら同意。たぶんそういう生成AIで俺たちでプロダクトなんか簡単に作れるじゃんよギークいらね（仕様バグあり）は一時は増えるだろうね）
追記ここまで
----
VibeCodingでIT技術者は不要になるのか？という話題が花盛りなのは理由があります。
ギーク（現場でコードを書いていたい人）が分かる話から、スーツ（人を集めたりお金を集めたり営業をする）が分かる話になってきたからです。
具体的に言うと、OpenAI社をはじめ続々とTDD(テスト駆動開発)でやってますみたいな、具体的な開発スタイルの話が出てきたから。
そうすると、現場の座組チョットワカルという強めの経営者が理解して判断し始めるんですね。
でもね、その道はもう15年も昔に我々は通り過ぎました。前回のブームと何が違うでしょうか？
技術者なら電子も機械も強電も弱電もお世話になったことのあるオーム社が過去に出していた直球の本の話から。
「My job went toIndia :オフショア時代のソフトウェア開発者サバイバルガイド」という書籍、何と発行年は2006年です。
かいつまんで話すと、インターネットが整備され、輸送コストがほとんどかからないソフトウェア開発では、アメリカのエンジニアは給与の面でオフショアに歯が立たない、だって、1/10の給与でインドのエンジニアは働くんだぜ？という本です。
そうした、価格競争力で負けるアメリカのソフトウェアエンジニアは、如何にして今後サバイブすべきなのか、という本になっています。
（普通に面白いしAIコーディング時代に通づるものがあるので復刊を希望したいところですが、まあ直球過ぎる題名を何とかしないと再販は無理でしょうな）
そして、JTCや外資問わず、過去にオフショア開発を経験された技術屋のみなさんははてブにも多く生息されているでしょう。
では、ジュニア開発者は不要になりシニア開発者のみになって、いまのソフトウェア開発は主に安い給与で働いてくれるところに遠隔で作業してもらって、レビューだけすれば良い環境ですか？
そうはなっていません。なぜでしょうか。
さて、今普通にXと連動する中古品売買プラットフォームを開発しようと思ったら、どうやってつくるでしょうか？
この文脈に埋め込まれたいくつもの情報「今」「普通」「連動」「中古品」「売買」「プラットフォーム」「開発」を解釈し、すり合わせ、未来の運営者も含めた全員に伝えるためのコストが、コミュニケーションコストです。
そうなると、「ちょっと良い感じにラフでいいからプロトタイプ作って持ってきてよ」で話が通じるのは、受注者マインドがしっかりした日本の受託開発現場の精鋭たちになるわけです。
テストケースだけを通過するように、内部テーブルを持たせた関数を大量に持ってこられてレビュー時に頭を抱えた経験が無いひとは、とても幸運なのです。
とは言え、これは何も文化の違いに起因するだけではありません。仕様とは、環境によって定まるものだからです。
例えば、うるう年判定の関数は、1581年以前をエラーにしますか？1873年以前をエラーにしますか？（ヒント：明治六年）
テスト駆動開発、古い言い方で言えばテストファーストの考え方は、成功したすべてのプロダクトで例外なく、ただの一つの例外もなく、必ず最初から取り入れるべきだったものです。
品質は最後に振りかける粉砂糖のようなフレーバーではなく、最初から設計に組み込むべきだからです。
ありとあらゆる趣味において、最初から良いものを使えば時間を無駄にせずに済んだ、と言われるような初期投資の大切さが説かれます。
果たして本当でしょうか？
そうです、その趣味にハマって生き残りサバイブした人から見れば、過去にその時点で投資をすべきだった、というのは正しいのです。
その趣味にハマれなかった人からすれば、少ない投資で自分に合わないことが分かったという合理的な選択であることと矛盾しません。
そのため、全ての失敗したプロダクトは、テストケースを書く時間でプロダクトを作り上げて、さっさと世に問うべきだったわけです。
少し昔話をしますが、オフショア開発において重要なのはドキュメンテーションとテストケース、それにレビューでした。
他の部署で失敗しつづけていたオフショア開発のやり方は、端的に言えば"教化"でした。
具体的には書けませんが、グッとお安い単価の国に出す仕事を、日本の会社に出すのと同じようにすべく、相手の会社のメンバーを教育して仕立て上げるブートキャンプの仕組みを作り上げていました。
発注側を変えずに済むように受注側を教育して、日本の会社に出すのと同じように単価の安いところに出せたらお得ですよね？でもこれは必ず失敗します。
何故か。だって、日本の会社と同じように働けるようになったら、日本の会社に就職するじゃないですか。少なくとも価値は上がったんだから単価を上げるように交渉しますよね？
結局のところ、当初言われていたような劇的な節約にはつながらないわけです。それなら下手に転職されるよりも自前で現地工場でも立てて地元に貢献しつつ雇用を創出した方が喜ばれるし持続可能です。
小なりとも成果が上がった方法は、フィードバックを相手ではなくドキュメントにした場合でした。
例えば先ほどの例で言えば、テストケースは通るが意図したコードにならなかったとき。
「普通はこういう意図でコードを書くから、テストケースを通るにしても、関数は次からこう書いて」というのが、相手に対するフィードバック。
「関数を書く前に、関数の意図をコメントで残して、レビュー時にはそれを見ましょう」というプロセスの修正が、ドキュメントへのフィードバック。
こうすると、担当者が退職していなくなっても、次の担当者はその方法を参考にすれば良いわけです。
これ、何かに似てませんか。現在のAIコーディングのベストプラクティスと呼ばれるものに非常によく似ているんです。
つまり、オフショア開発というのも、設計と実装が分離できるという前提に立って動いていたんです。
そして、実装しながら設計しても問題ないとする場合、それは「技術的な問題」ではなく「組織構造」に起因します。
つまり、プロダクトの構造を分割して、オフショア開発側に設計と実装とを委譲して、実装しながら設計を変えてもらうことが許容できるのは、契約や責任分界点、輸出入の法規を含めた法務の領域です。
少なくとも当時、諸々をクリアにして相手側にプロダクトの一部を荒い設計と共に切り出して、コーディングしながら再設計してもらい、テストケースを完備したコードとドキュメントを共に完成までもっていってもらったことは、大きな成果であったはずです。
（当時日本側と仕事をしたという実績があると大きな実力があるとみなされたと聞いたので、今はより良いところで良い仕事をされていると思います）
（あと、コミュニケーションコストと輸出入の関連法規が複雑だから）
少なくとも、納期までに契約したこれを納品してください、という枠組みの中では、実装作業だけ切り出すことはできない、というのが教訓として残ったはずです。
少なくともあと数年、場合によっては10年スパンで、日本ではほとんど変わらないと予想しています。
これは技術の話ではなく組織構造や、もっと言えばお仕事の進め方と契約の話だからです。
そうは言ってもジュニアエンジニアの簡単な仕事が減って成長機会が失われているのは事実では？と思うかもしれませんが、そもそもの前提が誤っています。
未経験（弱経験）者を雇って戦力まで鍛え上げる必要があるなら、AIに仕事渡してないでそのジュニアエンジニアにやらせるべきなんです。
ジュニアエンジニアとAIと両方にOJTさせて、その違いをレビューの場でフィードバックしてジュニアを育てるわけです。
もし、そんな時間は無いというなら、元々ジュニアエンジニアをOJTで育てていたというのは幻想です。
（たまに、失敗が経験になるとして、会社に損害を与える方法でジュニアを"教育"しようとする人がいますが、商習慣的にも信義則違反ですし言語道断です）
シニアエンジニアだけで事足りるとしてジュニアエンジニアを雇わなかった企業は、シニアエンジニアが抜けてガタガタになります。
これは中核エンジニアがゴッソリやめた会社が傾くなんて言う話で、昔からそうです。（たいてい、もっと人雇ってくれ待遇上げてくれみたいな悲鳴を圧殺した結果だったりします）
昔から、中堅がやれば手早い仕事を新入社員にやらせて鍛える、その代わり質は悪いし時間もかかるしフォローも必要だったわけでしょう。
AI時代が到来するとしても全く同じです。AIが出力するコードレビューで悲鳴上げてる場合じゃないんですよ。
レビューできるシニアエンジニアが足りなくなると予想されるなら、当然、ジュニアエンジニア雇ってレビューできるようにする必要があるんです。
そしてそれは、技術的な問題点ではなく、組織的・経営的な決断です。
国産LLM開発の文脈でもそうなんですが、ハードウェアの進歩を無視して話をする方が多いのが気になります。
現時点のコンピューターパワーは、10年後には手の届く価格になる可能性が十分高く、もっと言えば20年後には個人が所有する可能性すらあります。
いまから20年前の2005年は、Youtubeが誕生した年です。その時に、誰もがいつも手元にビデオカメラを持ち、即座に動画を世界に公開できるようになるとは思っていなかった頃です。
今もそうだと思いますが、ある分野で必要な性能にはもう十分という期待値があり、10年経てばある程度大きな会社の部署単位で現在最先端のコーディングAIがローカルで動くようになると想像するのは容易です。
そうなったときに、果たして営利企業が、エンジニアを育成するというコストを支払うかといわれると、疑問です。その時点で今後のリアルなコストと比較対象可能になるので。
だって、筆耕担当者とか、清書担当者を雇わなくなった企業って、多いでしょう？
My job went toAI として、じゃあ残るものは何？というのはオーム社の本を読みましょう。再販しないかなあ。
今後数年は変わらないでしょと書いたら今現在進行形で変わっとるわいと突っ込みが来そうなんで防衛的な意味で書いておくんですが、あなたは過去数年間同じ仕事してたんすか？
仕事のやり方とか内容とか、言語とかライブラリとか、毎年のように変わってたでしょ。
レビューの比率が多くなったとか、コード書かなくなったとか、そういうの、たぶん管理職になった人が嘆いてたのと同じっすよね？
少なくとも、ジュニアエンジニアが低品質なバイブコーディング結果を寄越すようになってレビューが大変とか嘆くのなら、まともなコーディング規約一つ作れていない組織の脆弱さを嘆くのが先では？
手癖でバイブコーディングしてヒットしたプロダクトに、あとから品質上げるように大工事するリファクタリングと言うよりリビルディングな仕事って、別に今もありますよね？
散々テストケースを書かなくて良いプロダクトなんて無いという講演だけ聞きに行って、自分とこでテストケースが自動で走るようになって無いなら、そこが問題でしょ。
「ぶっちゃけ日本のIT技術者のレベルが元々低いだけ」論、読んだけど、雑に日本叩き→雑に海外持ち上げの“気持ちよさ”に全振りしてて、論としては穴だらけだよ。順に潰す。
“発明”って規格？論文？OSS？製品？この区別を曖昧にして「思い浮かばない＝ない」をやるのは主観の事実化。
反例を淡々と置く（全部2010年代以降の「世界で通る」技術・成果）：
HTTP/3 / QUIC系仕様・QPACKの主要貢献者のひとりは日本人エンジニア（例：Kazuho Oku）。IETFのRFCはまさに“世界標準”。「世界で通用」どころか世界の土台。
Chainer / CuPy（Preferred Networks）は動的計算グラフ系フレームワークの先行例。PyTorch隆盛の流れに技術的影響を与えた。CuPyはいまも広く使われてる。
ソニーのCMOSイメージセンサは世界シェア筆頭。これは“ハード”に見えて、設計・製造・信号処理・ツール群までソフトの塊。スマホのカメラ品質＝AI前処理の土台。
日本人が中心メンテに関与した高性能HTTPサーバ（H2O等）はCDNや低レイテンシ配信に採用例多数。
産業用ロボット（FANUC、安川）周辺の制御・通信・ツールチェーンは世界の現場で常用。表に出にくいB2B領域は“見えないだけ”。
「LINEが～」みたいなB2Cの派手さだけが“発明”じゃない。基盤を握るのは地味仕事。あなたが気づかない＝存在しない、ではない。
Winny／一太郎／CD-ROM／MIDIを“国民的知名度”で持ち上げて、以後は「思い浮かばない」って、知名度＝技術力の誤用。
2000年代以降、ITは不可視化（クラウド、プロトコル、ライブラリ、半導体、サプライチェーン）へシフト。見えないところほど難しくなった。派手なガジェットが減ったからレベル低下、ではない。
問題領域で言語は変える。Webは「5歳児でも」動かせる？今のWebは、
CD/CI、IaC、K8s、SRE、ゼロトラスト、分散トレーシング、暗号化、フロントの再レンダリング戦略……
これらを運用で落とさないのが本番。Cが偉い／Webが軽い、は90年代の教養で止まってる。
起業に国の試験？それ、フィルタにはなるけどイノベーションの十分条件じゃない。
トップダウンは国家プロジェクトやインフラ敷設には強い。しかし、
分野で強弱は揺れる。制度の一軸で「勝ち負け」を断ずるのは幼い。
それ、犯罪としてのサイバー強盗の話でしょ。規制準拠の金融基盤と国ぐるみのハッキングを同じ土俵で比べるのは、
「百メートル走で銃使えば最速」って言ってるのと同じ。比較の土俵設定から破綻。
日本のITが伸び悩んだ要因は複合要因：内需の構造、調達・多重下請け、英語コミュニケーション、ストック報酬の弱さ、エクイティ文化、大学と産業の距離、IPO市場の質、人口動態、為替…
これを全部「技術者のレベル低い」で片付けると、説明力を失う。制度と資本設計の問題は制度と資本で解くのが筋。
「勝ってる」を“B2Cでバズるアプリ”だけに限定するから見落とす。
最後に一個だけ。
