  |
はてなキーワード: ソフトウェアとは
変化球が集まってるとか、スタンダードとされる都会に対する田舎とか、そんな感じでいいし、
カジノもリニアもいらないし、だったら下水道とかインフラ維持とか、
困難なことは適当にほっぽっといて、トンネル掘ったり、なんか新規に製造する方が楽だもんね…😟
で、レガシーなシステムを維持し続けると、負債だの何だの言って、みんなやりたがらないし、文句言うけど、
そうは言っても、実際社会を動かしてるのがレガシーなCOBOLだったり、古いJavaだったりするかもしれないわけで、
そりゃ、難しいおもり、保守をやりたくないから、新規開発やりたいですよね、高見から物言えるし…😟
でも、その新規で世界的に勝てる感じがしない、近年のAIとか、まあ勝つな、とは言わんし、勝てるなら勝てばいいんだけど、
政治も、その楽な新規開発ばかり応援するんですよ、リニアとか、カジノとかそうでしょ、
そうじゃなくて、みんな困ってることはそこじゃないんじゃないの？と、思うわけですよ
リニアとか、カジノがないから、今の俺の生活が大変だ！死にそう！助けて！ってわけじゃないでしょ？😟
もっと、やるべきことがあって、でも、それを直視して取り組むのは難しいから、
取り組むのが簡単な新規案件にだけ取り組んで、やってます！頑張ってます！感を出すのは違うと思うんですよ
つまり、女性陣が何と言おうが、大切なのは清潔感より清潔なんですよ、
本当に残念なことに、デジタルカメラ時代の「写真家」を名乗る人間のほとんどが自分でRAW処理ソフトウェアの開発をしたことはなく、審査員を名乗っている人間の多くは、実際に行われた処理の内容を想像することすらしない。
主観的に良し悪しを判断するのは間違いではないのだが、何が行われて写真撮影ができているのか、そしてそれをどうやって鑑賞できているのか知らない人間ばかりなのである。
ただひたすらに画角がどうの、コントラストがどうの、彩度がどうのなどと言ってみているが、RAW処理ソフトの「コントラスト」や「彩度」というパラメーターがどのような実装になっているのか、或いはトーンマッピング処理について理解して審査しているまともな人間がどれほどいるというのか？
例えば「ホワイトバランス補正」と言われて「色温度」と思った人は、実写の画像処理に対する理解が足りていない可能性が高い。
特に静止画の撮影者は技術面に明るくないものが多く、動画の人のほうがよっぽど技術面に詳しい。実際には同じことをやるのに。
もっとも重大な誤解は、ある種の「無加工」と信じられている実写映像と肉眼が十分に近い、と思われがちだというところだろうか。
カメラが見ているものとCGは非常に近いが、人間の見ているものとカメラが見ているものには大きな乖離があるという大前提が抜け落ちてしまっているのだ。
なにせ撮って出し信仰者なんてものもいるのだから。カメラの中でどういう処理がされているのか少しでも理解しようとするならば、撮って出しを「真」とするのがいかに愚かなことであるか、初期の段階でわかるはずではないのか。
例えばFUJIFILMのように、この辺りを踏まえて「一般消費者はメーカーの言うとおりにすべきだ」と言わんばかりの姿勢を見せるメーカーもあるが、これはかなり理にかなっているとも思う。FUJIFILMは「記憶色」を謳ってきたが、これ自体は間違いではない。（もちろんFUJIFILMの色の処理が適切だとは微塵も思わないし「フィルムシミュレーション」などという、知識不足の消費者にPROVIA・ASTIA・VELVIAなんてあたかもフィルムを再現しているかのような名称で売るのはいかがなものかと思うけれど）
日本語の意味合いとして「真を写す」なんてものにこだわるのは誤りだと言わざるを得ないが、せめて、何をしているか理解しようという姿勢を見せたらどうなんだ。
「プリセットを販売します」とか「フィルムを再現します」とかいう、ただ消費されるだけの消費者を見ているのは少しばかり腹立たしくもあるが、それを利用して商売を続けてきた側は間違いなく悪い。
美術目的なら好きなようにやれ、と言うことに決めているが、理解した上で全ての利用者が開発者になってくれれば、もっと自由な世界が待っているのに……。
また、せめて複写をするようなプロは「Foveonは正しい紫色が撮れる」「Adobe Camera RawよりCapture Oneのほうが色が良い」「LUMIXは色が良い」「FUJIFILMは撮って出しで正しい色が出る」みたいなバカなことを言っていないで、画像処理（フィルム・デジタル・動画・静止画・実写・CG問わず）の勉強をもう少しばかりやり直していただきたいものである。
フィルム時代に自分の手で現像とプリントを試みることよりも、デジタル時代のほうが圧倒的に安定していてシンプル（同じ処理をすれば同じ結果が得られると言いたい）なのに、それをしない。
「スマホソフトウェア競争促進法」(スマホ新法)っていうのが、12月から施行される。
Android も対象なんだけど、わかりやすくするために、iPhoneだけに絞って話すね。
iOSとiPadOS でAppStore以外からアプリが入れられるようになる。（サイドローディング）
なんかネットを見ていると、この法律について否定的な意見が多かった。
てっきりみんな賛成していると思ったし、私は賛成。
そもそもこの法律って、スマホOS を作っているAppleとGoogleって優位な立場を使って市場を独占していて良くないよねって話。
Apple はわかりやすく、AppStore以外からアプリがインストールできない。
それを、他のアプリストアも使えるように認めなさいよねって話。
あとは、Apple製のアプリしか使えないOSの機能(隠しAPI)も、他の開発者にも開放しなさいよ。とか。
===================================================
ここでよくあるこの法律に反対する人へのアンサー
Q 悪質なアプリが増えるのでは？
A AppStoreにも悪質なアプリはあります。個人的な感想ですが、アプリの審査というのは、
独自の課金システムを使っていないか、3rdパーティーのログイン機能がある場合にApple accountでログインできるか、
他のOS版のアプリを紹介していないかなど、自分たちの規約をちゃんと守っているかを見ていて、セキュリティ的なことは隠しAPIを使っていないかぐらいだと思います。
ちなみにサイドローディングでも、Appleの審査があります。（AppStoreに上げるときとは違う審査）
と反論してみたものの、Appleの審査があるのはそもそも変な気がする。
根本的には、使う人のITリテラシーを上げる必要があると思う。
まあ、サンドボックス内でアプリは実行されるから、サイドローディングでも割と安全だとは思う。自分で権限を与えた場合は知らん。
Apple 自信もサイドローディングは危険だと言っているけど、ただ儲けたいだけ。
Q EU では似た法律で、他の開発者に機能(API)を開放せずに、機能ごと使えなくしていて、不便になるのでは？(macでiPhoneのミラーリング、shareplayの一部機能)
A これは、法の抜け穴だよね。法案に反対するべきではなく、その法の穴を塞ぐべき。
===================================================
サイドローディングは、認めるべきだと思う。
例えば、Microsoft Storeしか使えないWindows、Appstoreしか使えないmacってありえなくない？
（ちなみにMicrosoft Storeしか使えないWindowsはあった。 Surface RT とか Sモード）
自分で買った機械で、好きにプログラムを実行できないっておかしいことだと思うんだけど。
Linuxの場合は、SnapStoreとFlathubという2つのストアがあるんだけど、競争が働いていて素晴らしいと思う。
EUには似た法律があって、サイドローディングがすでにできるんだけど、100万インストール以降は1インストールあたり、€0.5払う必要があるというめちゃくちゃな契約を結ぶ必要がある。
あと、AppStoreに公開するときと同じように、Apple Developer Program($99/年) に登録しないとサイドローディングできないのも良くないと思う。
＜参考＞
https://www.youtube.com/watch?v=GxMjoQ_pIr4&pp=ygUaZHJvaWRrYWlnaSDjgZnjgb7jgbvmlrDms5U%3D
Q.
生成AIにソフトウェア開発を支援してもらう場合、ソースコードの作成を依頼する形式が多いと思いますが、実行ファイルを直接出力してもらうことも技術的には可能なのでしょうか？
A.
生成AIによる実行ファイルの直接出力は、技術的には極めて困難です。現在のLLM（大規模言語モデル）ベースの生成AIは、ソースコードの生成には向いていますが、実行可能なバイナリファイルを直接出力することには根本的な制約があります。
技術的な制約
LLMはテキストベースのトークン処理を基本とする設計であり、バイナリデータを直接扱うことができません。実行ファイルは0と1の連続したバイナリコードですが、LLMはこの形式でデータを生成するようには訓練されていないため、バイナリファイルを直接出力することは現在のアーキテクチャでは実現が困難です。
従来のソフトウェア開発では、ソースコード→コンパイル→アセンブル→リンクという複数段階のプロセスを経て実行ファイルが生成されます。各段階で最適化や機械語への変換が行われるため、この過程を完全に省略してAIが直接バイナリを生成することは技術的に非常に複雑です。
研究レベルでは、バイナリデータを扱う試みも存在します。例えば、LLM4Decompileのような研究プロジェクトでは、バイナリコードを逆コンパイルする際にバイナリを一度アセンブリ言語に変換してからLLMで処理しています。逆に言えば、生成時も同様の変換プロセスが必要になると考えられます。
実務では、生成AIにソースコードを作成してもらい、それを従来のコンパイラやビルドツールで実行ファイルに変換する方式が標準的です。この方法であれば、デバッグやテストも容易で、生成されたコードの品質を確認しながら開発を進められます。
なお、フォントファイルのようなバイナリ形式でもオープンソースとして扱われる例はありますが、これはフォントという特定用途の場合であり、汎用的な実行ファイル生成とは異なります。
Q.
A.
おっしゃる通り、画像生成AIもバイナリを出力しているという点では共通していますが、実は根本的に異なる仕組みで動作しています。
アーキテクチャの違い
画像生成AIは拡散モデル（Diffusion Model）やGANなど、視覚データに最適化された専用のアーキテクチャを使用しています。一方、LLMはTransformerベースのテキスト処理に特化した構造を持っています。画像生成では、ノイズから段階的に画像を生成するプロセスを経て、最終的にピクセル値という数値データ（バイナリ）を出力します。
画像ファイルのバイナリは連続的な数値（ピクセル値）の集合であり、各ピクセルが色情報を持つという規則的な構造です。最近の研究では、画像をビットプレーン（bit-plane）として扱い、XOR演算でノイズを加えるBinary Diffusion Probabilistic Model（BDPM）のような手法も開発されています。
対して、実行ファイルのバイナリは機械語命令の複雑な配列であり、CPUが直接実行できる命令コード、データセクション、リンク情報などが厳密な形式で配置されています。わずかなビット誤りでもプログラムが動作しなくなるため、画像のような連続値とは性質が大きく異なります。
画像生成AIは、ImageNetやLAIONなどの大量の画像データセットで訓練されており、ピクセルパターンを学習します。一方、実行ファイルを生成するには、コンパイルプロセス全体（構文解析、最適化、機械語変換、リンク）を学習する必要がありますが、これは単純なパターン学習では実現できません。
したがって、画像生成AIが成功しているのは、画像という特定のドメインに特化した設計と、規則的なデータ構造があるためであり、同じ手法を実行ファイル生成に適用することは技術的に非常に困難です。
あと、中国って昔から、田舎のよく分からんオッサンが変な物を発明するみたいなニュースがあって、
面白いなあと思いつつ、なんだかんだ格下に見てたんだろう、自分は見下してたんだろう
アメリカも日本も、いや世界中がファブレスだの何だの言って、設計だけやって、
製造は中国や東南アジアに丸投げするようにどんどんなっていって、
で、気付いたら、みんな先進国は手を汚さなくなって、工場とか現場のノウハウがなくなってって、
中国には工場があるし、現場が当然あるので、現場のノウハウが貯まる、
まあ、横流しとかパクリでなくても、先進国からやってくる図面を毎日見ては、
図面通りに作ってるのにうまくいかない、そもそも、日本側の設計図が、上からの命令が間違ってんじゃねーの？
みたいになっていって、現場で直すようになったりして、
アメリカとか日本の技術者がちゃんとした設計図面を書けなくなっていって…
中国はどんどんノウハウを吸収していく、とにかく現物がある、物がある、大量のパーツがある
例えば、スマホを作るために、液晶パネルやバッテリー、モーターなど様々なパーツがある
それをアメリカや日本の図面とは違う組み合わせ方をして、新しい物を作る
それがマルチコプターのドローンになったり、3Dプリンターになったりした
よく分からん中国の田舎のオッサンが光硬化の3Dプリンタを作ってるYouTube動画を見たとき、あ、これはもう負けるなと思った…😟
そのオッサン以外にも、中国各地で同じような3Dプリンタを作っていて、動画やノウハウがネットに現れた
同じようなことを日本でやろうとしても、日本の秋葉原ではそんな部品は手に入らない
中国は下請けで、世界の工場をやっているから、現地であらゆる部品が入手できる
そして、日本の秋葉原は電子パーツよりアニメやフィギュア、そしてメイド喫茶やビジネス街、観光名所みたいになっていく
一方、深センには巨大な昔の秋葉原のような電子部品を扱う店の集合体、
お金を積んで頼めば量産してくれる工場、そんな中から成功した巨大なIT企業、家電企業が巨大なビルを建てていく…
今や、そんな中国の巨大IT企業、電子機器メーカーは玄関に超高級盆栽があったり、
超高級な中国茶を大企業や富裕層同士で売買したり、もう日本のショボーンなムードとは完全に真逆に思える
とにかく、垂直統合と水平統合が縦横無尽になってるところが凄い
良くも悪くも、採算度外視してたりするところも凄い、まあ、それが怖い所でもあるんだけどね…😟
今の中国のロボットは、みんなアクチュエータが内製、独自設計、そのアクチュエータはアリエクでも買えたりする
蟲毒みたいな世界にも思えるし、矛盾してるけど一方でオープンアーキテクチャにしていいの？だったり、
とにかく中国はカオス、中国企業同士も殴り合ってるんだか、同じネタを出し合ってワイワイやりたいんだか、よく分からない…😟
過剰生産とか、危なっかしいんだけど、なんか活気がありそうなのがうらやましい
中国共産党、中央政府は、テクノロジー企業や犯罪組織などが国家以上の力を持つことを恐れている
でも、そういう政府に擦り寄ったり、ばーかばーかｗ言いながら、しぶとく続けたり、そういうところが日本と違うと思ってる
じゃあ、中国が良いかというと、俺みたいな駄目人間は今の日本でないと生きられない
もしくは北欧だろうか？でも、北欧であれ、移民には冷たいのだよ、今は世界中が移民に冷たい…😟
私は違うのだけど、大学で二足歩行とか、四足歩行とか研究してた先生たちは、今の状況をどう思っているのか興味がある
もう私は全然素人の世界になってしまっているけど、数十年の時間を経たとはいえ、最初から格が違ってたんじゃないか、という気もしてくる
時代の流れみたいな、大きな水の流れみたいなものは、人間の努力ではどうにもできないというか…
まあ、時流の中でチャンスを見逃さないのも大事だと思うんだけどね、
例えば、対岸に渡りたいとして、川はとんでもない濁流なんだけど、一瞬のタイミングで渡ることができるかもしれない、
そういうチャンスが何億分の一みたいに訪れるとしたら、ずっと待ち構えている必要がある
なんか、高市政権になったこともあってか、2030年までに、日本も中国みたいなものか分からんけど、世の中の標準となるようなロボットを作るらしい
悪い意味じゃなくて、日本は後だしジャンケンになると強いからね、昔から…
というか、今の中国だって、アメリカや日本の真似して強くなったわけで、
ここから、もう自分にとっては神々の戦いみたいなのが観れるのかな、とちょっとワクワクしてるし、
中国の四足みたいなのは、もう日本のベンチャーが何社か開発できてるんだよね
日本だけじゃなくて中国もだと思うけど、結果が出るか出ないか分からない未知のことは苦手なんだと思う…😟
でも、日本も高市さんとか眺めてると、そういう傾向がある気がする
政治家先生は理系の話は分からないし、理解のない親に、これを買ったらこんな良いことがある、これだけ勉強が捗る、
とかプレゼンする子供みたいなものである、理解のない大人の財布からお金を出してもらわなければならない
せません！
って思うわ。
20年ほど前に業界に入って、OJT受けたおっさんにOJT受けたエンジニアか？ w
ソフトウェアエンジニアリングは、しきたりを1ミリも変えたらいかん伝統芸能ちゃうねんぞ！
E2Eテストなんて、今時のWebサービスの規模、複雑度っていう圧倒的物理量に追いつけるわけがないんだよ。
屁の突っ張りにもならないどころか、
爆上げさせてる
いや、そもそもE2Eテストとセキュリティリスク、なんの関係があるんや？ って問題はあるんやけど w
本来そんな機能がないのにあると勘違いして使うことの危険っての、教えてもらわんとわからんか？
って、安全帯のフックを自分のベルトにかけて、送電線の点検ができるか？
安全帯自体の機能として落下防止が当然あるけど、「正しく使わないと正しく機能しない」し、そもそもそれ、体重を支えられるのか？ それ以前に安全帯か？ ただの100円ショップで売ってたキーホルダーちゃうか？ って問題なんよ。
安全帯でも負荷を支えられなきゃ意味ないし、物が違えば、キーホルダーはキーホルダーだし、安全帯は安全帯なんだよ？
Web記事とかの「単語」だけ相手にするから、こういう致命的な間違いをガンガン積み上げて、炎上現場、高粘性現場にレベルアップさせるんだよ。
DDD、TDD、クリーンアーキテクチャ、マイクロサービス、DevOps。
本人達は真面目に輸送機から「素晴らしいもの」を得るための手順を踏んでるという認識しかなく、おかしなことをしてる自覚が皆無っての、そのままだって気づけ。
理解してるなら、その目的がちゃんと達成できてるか、確認してるか？
ちゃんと適用されたまともな現場を知らんで、「こんなもんでしょ」で満足してるの、頭おかしいぞ。
猿か？
誰も見て見ないふりしてるけど。
問題は繋がっていて、ごく単純な話。
「この規模、この内容のサービスで、なんでこんなにエンジニアが大量にいるんだろう？」って疑問は、どこにいっても、どこと話しても、わく。
先日の才能問題がまさにそうなんだけど、ソフトウェアエンジニア業界に滞留している人、ぶら下がってる人が多すぎやしないか？ と。
リモートをいいことに、サボりまくってる「エンジニア」、特に最近は生成AIででっち上げてサボれるようになってからは、まぁまぁの数、存在していると思う。
実際に観測してもいるし。
そういう極端な例に限らず、才能がない、向いてない「エンジニア」が相当数寄生している。
ジュニアとかコーダーレベルだけじゃなく、いや、むしろリーダー、マネージャー、CTOレベルに。
その組織、企業のそのレベルの「エンジニア」が、それに占拠されたら、多分事態が好転することはない。
アリバイづくり程度の活動は行われるだろうが、永遠の停滞に陥るだろう。
誰か一人抜けても、残りがスクラムを組んで、異分子を排除することに全能力を傾けるだろうから。
まさに獅子身中の虫。
「あの企業が？」ってところが、すでにそう言う状態に陥ってたりする。
名前はあげられないけど w
政府はソフトウェアエンジニアが足りない足りないって喚いてるけど、頭数だけ用意しても現場、プロダクトが混乱するし、利用者が困るだけだ。
これ、旧日本軍の失敗の原因であった「員数主義」って言うんよな。
正直、「え？ ソフトウェアエンジニア……？ を名乗って……んの……？」って人が多い。
語るけど。
延々と語るけど。
滔々と語るけど。
毎度毎度、会議室でMCバトルの、青菜に塩をかけたような真似事をして。
誰が一番最初に、新しいイケてるWebページを見つけたかを競って、ドヤ顔くらべ。
勉強会開いてみたり。
この量と質か？
みたいな。
多分、この手の「エンジニア」の半分以上が、人手不足の工場とか大工とか解体業とかライフライン保守に行ってるべきだったんだろうな、と思う。
どっちが上とか下とか言う話じゃなく、向き不向きの話。
向いてないんよ。
多層抽象化に不自由とか、概念構造の構築に不自由とか、専門書とかの読解に不自由とか。
2、30年ほど前はそこまでの能力がいらなかったからうまくエンジニアに滑り込んだ人もいただろうけど、今時のプロダクトでそれでは通用しないんだよね。
SQL文の書き方とか、DockerFileの書き方とか、ソースファイルのタブの入れ方とか、Web記事のある場所とか、ディレクトリ構成とかの形式的な知識とか、マジで、あったから何？ って。
大事なのは形式的な知識じゃなく、本質的な理解とメタ思考なんだよね。
お前なんていらない。
それだけ。
使いたいっすよね。
って、よく言われる。
この言葉のままじゃないけど、まぁ、だいたいこういったニュアンスだ。
自分はそこそこの腕だと思うなら、彼我の実力の差は正しく測れるようになっとけよ。
こちとら、「だいたいこういう実装されてて、長所短所はこんなもん。こういう処理のために作られたようなもんだな。だから、今のプロダクトだと使い所がないね。料金も高いし」あたりまでチェック済みじゃボケ！
ってことしかない。
こいつら、自分の業務経歴書に書き込む単語を増やすことしか考えてねぇんだよな。
関連サービスなんて増やせば増やすほど、保守運用改善が大変になっていくだろ！
経費もかかるだろ。
「仕組み」は、よりシンプルな方法で実現できるならシンプルな手段を選べ、ってのは常識中の常識だろ。
「KISSの原則？ 知ってますよ」って、知識として知ってる。
KISSが"Keep it simple, stupid"の略だってことを知っている。
けど実現できないんじゃぁ意味がねーんだよ。
この手の「自分はイケてると錯覚しているエンジニア」は、Web記事つまみ食いしながら雰囲気で設計実装するから、リクエストやデータが増えてきたら破綻するような、間違えた設計実装しかできない。
そういう新しいサービスは、それ以前のサービスの欠点を埋めるために作られてるんだから、それ以前のサービスと同じノリで設計実装して十分な性能を引き出せるわけがねーんだわ。
今までの複数の炎上現場で、正しく設計実装できてたところはなかったよ。
おいらが関わった炎上現場はほとんど、こうやって生まれてきている。
そういう炎上現場を作り出したエンジニアは、ふくらし粉で増量した業務経歴書片手に、「サービスの立ち上げを『僕の技術力で』やり切りました」って転職していくんだ。
新しいことに挑戦したくなって。とか言って。
みたいなエンジニアを、なぜどこもかしこもありがたがって採用するか全く理解できないんだが、そういう「エンジニア」が次の現場で生まれ変わったように的確で素晴らしい成果を出せるかって、そんなわけもなく、日をおうごとにグダグダになっていくサービスがさらに一個増えるだけだったりする。
こういうエンジニアが、初回リリースしてからしばらくして、ソフトウェアエンジニア業界に飛び散る。
まるでがん細胞。
こうなると立て直すスピードより、グダグダな新しいサービスが生まれるスピードの方が何十倍、何百倍も早い。
もうね、半ば絶望してるんですよ。
今、生成AIも参戦してきてて、物量だけは爆発的に増えてるから。
多分、そう遠くなく、グダグダサービスで日本は覆われると思う。
AIベビーシッターが必要になってくるだろうけど、それができるだけの技術力を持ったエンジニアの数が圧倒的に少ないし、何よりそういう腕利のエンジニアを、ふさわしい金額で雇おう、招こうと考える経営者が皆無。
今までの炎上現場ですら、高すぎる。無駄金を払わされてる。って扱いをうけてたからな。
「同じエンジニアなのに、どうしてこんなに高いの？」
ここ1年で初めてはてなブックマーク日毎の総合人気エントリ入りしたドメインからのホットエントリ、ブクマ数順トップ30
| ブクマ数 | タイトル | ドメイン |
|---|---|---|
| 2158 | （内閣総理大臣所感）戦後 80 年に寄せて - 先の大戦の終結から、80 年が経ちました。 この 80 年間、我が国は一貫して、平和国家として歩み、世界の平和と繁栄に力を尽くしてまいりました── | www.kantei.go.jp |
| 1886 | みらい議会 | gikai.team-mir.ai |
| 1445 | LINEヤフー株式会社を退職したので歴代社長の感想を書く（元ヤフー社員視点） - ariyasacca(2025-10-20) | sangoukan.xrea.jp |
| 1256 | 万博で、いろんな国の人に前から気になっていたことをたずねてみた - 庭を歩いてメモをとる | www.yoshiteru.net |
| 994 | 日本苗字アトラス｜地図から苗字を見るサイト | www.myoji-atlas.com |
| 961 | 公明 自民との連立離脱表明 高市総裁「一方的に伝えられ残念」 ｜ NHKニュース | news.web.nhk |
| 946 | Affinity ｜ プロフェッショナル クリエイティブ ソフトウェア、無料で万人のために | www.affinity.studio |
| 837 | みらい まる見え政治資金 - チームみらいの政治資金をオープンに | marumie.team-mir.ai |
| 811 | 【詳しく】高市早苗氏が自民党新総裁に 総裁選 女性就任は初 小泉氏抑え選出 ノーカット動画も ｜ NHKニュース | news.web.nhk |
| 694 | 藩 一覧 ｜ 幕末期近世村領域データセット | geoshape.ex.nii.ac.jp |
| 593 | 「じつはグーグルマップよりオススメじゃね!?」アップデートでさらに進化！ トヨタが本気で開発した“完全無料”の「カーナビアプリ」最新版を試してわかった使い勝手とは ｜ VAGUE(ヴァーグ) | vague.style |
| 570 | 認知負荷を下げるテキストコミュニケーション - ジンジャー研究室 | jinjor-labo.hatenablog.com |
| 558 | 人気料理家が繰り返しつくる「ジャガイモとちくわのバター煮」。奥深い味わいに驚愕＜長谷川あかりさんレシピ＞ ｜ ESSEonline（エッセ オンライン） | esse-online.jp |
| 555 | 江口寿史氏制作イラストに関するご報告 ｜ INTERMESTIC INC. | www.zoff.com |
| 533 | 当社所属ライバー「甲斐田晴」に対する極めて悪質な誹謗中傷行為・荒らし行為等への対応結果について ｜ ANYCOLOR株式会社(ANYCOLOR Inc.) | www.anycolor.co.jp |
| 460 | 「gooポータル」サービス終了のお知らせ – gooヘルプ | help.goo.ne.jp |
| 457 | 京都市：市税の滞納処分の誤り | www.city.kyoto.lg.jp |
| 431 | ドラクエ以前のPCゲーム関連の文章一 | roomhakase.ninja-web.net |
| 414 | 40代女性が約2ヶ月で5.5kgダイエットした記録 - ぶち猫おかわり | buchineko-okawari.hatenablog.com |
| 401 | まだガソリン車で消耗してるの？…とか言わんけどさ。 - はてなの鴨澤 | kamosawa.hatenablog.com |
| 391 | ドジャース ワールドシリーズへ 大谷翔平 3本塁打 勝利投手に 佐々木朗希が抑え ブルワーズ戦【詳しく】 ｜ NHKニュース | news.web.nhk |
| 378 | 【作品別】コミケ開催別カップリング表記数（1982夏-2025夏） | public.flourish.studio |
| 353 | 被災地にベトナム窃盗団 七尾署、県警 複数人を逮捕｜社会｜石川のニュース｜北國新聞 | www.hokkoku.co.jp |
| 346 | [PDF]デニーズで使用している江口寿史氏デザインのイラストについて | www.dennys.jp |
| 340 | 全世界“ガンダム”総選挙2025 | gundam-official.com |
| 339 | 心を揺さぶる美術館10選 | www.timeout.jp |
| 322 | 弊社刊『青の純度』につきまして ｜ 集英社 文芸ステーション | www.bungei.shueisha.co.jp |
| 321 | Agents ｜ Playwright | playwright.dev |
| 311 | サッカー日本代表 ブラジルに歴史的な初勝利 14回目の対戦で 東京 味の素スタジアムで強化試合 ｜ NHKニュース | news.web.nhk |
| 309 | 維新 吉村代表“議員定数 大幅削減なければ自民との連立なし” ｜ NHKニュース | news.web.nhk |
才能がないと思ったら、早いうちに河岸を変えた方がいい。
早ければ早い方がいい。
可哀想だから(教え子が？ それとも自分が？ w)、って「がんばれ、がんばれ。才能なんて関係ない」みたいに騙すのは、むしろ害悪だよ。
10年後、気付いて路頭に迷わせるとして、その責任は取れるのか？
まぁ、本人自身が気づいて路頭に迷いつつあるけどどうしようもないのかもしれんが、地獄に道連れはやめてやれ w
それで生計を立てない、趣味の範囲で楽しむ分には好きにすればいいけど、エンジニアに限らず、それなりのお金をもらおうとしたら、才能、向き不向きは超えられない壁として現実に、強固に存在している。
球速120km出ないけど阪神の一軍のピッチャーに、ってのはどう逆立ちしても物理的に不可能だ。
でも草野球は楽しめる。
才能がなけりゃ、一人で永遠に「大いなる助走」を続けりゃいい。
誰にも迷惑かけないなら。
医師、看護師、会計士、経営者、etc.etc. にも、才能、向き不向きはある。
落ち着きないし。
同じことを何日も続けたら、爆発する。
「明日も同じことしなきゃならないのか……」って考えただけでも、死にたくなる。
こんな感じに、才能がものをいう分野って、意外に多い。
ソフトウェアエンジニアは、設計実装の抽象度が多層化していて、その巧拙によって安定度、運用や機動的な新機能追加の手間、リードタイム、金や何やら、数十倍、規模複雑度が爆上がりしている今なら下手すりゃ数百倍差が出る。
その差をちゃんと理解するには、巧の現場の「こういう世界があるんやー……」って実体験が必要だったり、巧レベルの才能が必要だったり、経営知識が必要だったり、経済知識も必要だったりして、「拙」の現場にぶら下がってるだけのエンジニアが「才能なんて幻想」って吠えたっても「マジ、迷惑だからやめてね」って思う。
どの炎上現場でも、高粘度現場(リーダーマネージャが理解できないからって邪魔ばっかりしてきたり、そもそもプロダクトがぐっちゃぐちゃになってたりして、どんな行為がサービスの息の根を止めるかわからなくて身動きが取れない「震える舌」みたいな現場。物事が全然進まない現場。通常、経費で札束ガンガン燃やしてるはずだから、ここも炎上現場っていう)でも、この手のエンジニアが腐るほどぶら下がってるんだよね。
たいてい、生み出されるソースコードとドキュメントの割合がおかしなことになってる。
いや、そういうの主催してる暇があったら、コード書けよ、って。
でも、Web記事引いてきて、「〇〇にはこう書いてある」とかドヤ顔で机上の空論で時間潰して「俺も一端の理論派エンジニアだぜ……」とか、いや、お前はただの受け売りを理解もせず垂れ流してるだけのそこらへんの AI と変わらんクズだよ。
おいらの師匠の一人は「TV出たり、本書いたりするやつは二流。一流は、自分の仕事に集中していて、他のことやる暇ないから」って言ってたけど、ほんとその通りだと思うよ。
シャバと違い、ソフトウェアの世界は驚くほどのスピードで巨大化、複雑化している。
30年、40年前なら、社会性の乏しい、プログラミングコンテスト受賞者みたいなエンジニアでも無双できたけど、今は無理なんだよね。
今だと玉拾いも任せられないくらいだったりする。
ちょい前も、PostgreSQLの中身いじれます！ って東大卒業生いたけど、視点が局所的すぎて全体感に欠けてて、プロジェクトがヤバい状態になってるのが理解できなかったりしてたからね。
そろそろリリースできる状態になってる予定だけど、おいらの読み通りα版完成が3ヶ月遅れ、そこで大量の不具合が発覚してベータ版完成がそこからさらに3ヶ月以上遅れ、不具合積み残したまま見切り発車、ってなるんじゃねーかな、と思ってるんだが w
才能の種類、方向性によっては、10年前も今もたぶん10年後も変わらず十分通用するものはあるんだけどねー。
そこに生活水準をあげてしまうと、自分はもう通用しないと気づいても、撤退できない。
マイカーガー。
マイホームガー。
子供ガー。
愛犬ガー。
んなもん知るかっ！
そういう「元エンジニア」がリーダーとかマネージャとかにクラスチェンジして、事業、プロダクトの足を引っ張る。
あそことか、そことか、具体的な企業名はあげられないけど、そういうエンジニアが漬物石のように重しになって、身動きが取れなくなってるところが多い。
VCとかから、もっと売り上げを上げろ。成長率を上げろ、というプレッシャーを与えられ、何かしなきゃいけない。ってなって、外付けの雰囲気だけのサービスをどんどん外付けしていく戦略を取る。
1年で10。
2年で30とか。
マジかよ w
思い思い行き当たりばったりに作ったら、手間だけ増えてそれを壊すわけにはいかなくなって、さらに身動きが取れなくなっていく悪循環しか見えないんだが、そんな経営方針で大丈夫か？
とか意味不明な決定して、認証認可v1、認証認可v2、認証認可v3とマイクロサービスが増殖して、さらにv4を企画してるとかいう会社だってある。
真っ当な声には、自分の存在感を示すためだけの反対を唱えて邪魔したりして、現場で手を動かしているエンジニアより高級を取ってんのに、事業、プロダクトへ与えるダメージは倍増する。
さらに、自分の地位を死守するために、それを脅かす腕利のエンジニアを陥れる、排除することに全力を傾ける。
これで3倍界王拳だ w
経営者はできるエンジニアたちに任せていると思い込んでいるかもしれないが、さて、どうかね？ w
大本営発表的にはうまくいっているとされているサービスが、その裏側はカーオブファイヤーみたいなところって、結構ある。
はっきりいう。
今はクラウド環境のプロダクトで、どのように自動テストで検証可能なシステムを構築するかの手法の研究を続けてる。
具体的には、今まで関わってきた炎上現場で安定稼働を達成させた手法(TDD)だな。
ワークライフバランス？ w
才能のない人は河岸変えろ。
業務経歴書にも今まで使ったことがあるサービスの名前をたくさんたくさん載せてます。
じゃねーよ。
ボルトに世界水泳、吉田沙保里にNBAに出場させるような使い方してて、どこが技術力だよ。
ってのが多い。
「どうしてこのAurora、リーダーがこんなにたくさんぶら下がってんの？」
「テナントが増えて、アクセスが増えたので、負荷分散のために増やしました。水平スケーリングってやつです」
うん。水平スケーリングは知ってんねん。この程度のテナント数、ユーザー数、アクセス数で、どうしてこんなにでかいインスタンスのリーダーがぶら下がってんのか？ って聞いてんねんけど……。
って現場、多い。
でも、今通常営業してるサービスでも、こういうところ多いんだよな。
それはともかく、
「マイクロサービス化していて、いま120を超えたところで、当面160になります」
「……は？」
「……デプロイの時、どうすんの？」
「変更があるサービス名を書いたファイルを一緒にコミットして、それ読み込んで、GitHubActionsでデプロイさせてます」
「Cloneして立ち上げます」
「これ……、モノリポ？」
「120個？」
「120個」
「なんか立ち上がらないんだけど……」
「あ、修正中なんで、〇〇と××のコミットをチェリーピックしてください」
「……動かないぞ」
「昨日の夕方、変更が入ったみたいなんで、△△のコミットもチェリーピック。いや、＋＋のブランチを……」
5日で立ち上げ切れるんか？
って現場がね、案外たくさんあるんだ。
「ほう……？」
どうして「自分が間違えてる」「自分が見当外れなことをしている」可能性ってのを考慮しないんだろう、この人らは？
っていつも思う。
マイクロサービスの目的も前提も理解しないで、HowToだけ猿のように繰り返してるって自覚ないんか…… (-_-)
ってマーカーで引いた一文見せつけられるんだが、その前に書かれてある前提とか目的とか、書かれてない暗黙のそれとか、いわゆるコンテキスト削ぎ落として、単語レベルの理解を開陳されても、「は？」としか反応できんのよな。
120のマイクロサービスとか、お前、認知科学の知識もないねんな……。
それマイクロサービスじゃなく、「粉砕されたモノリシックサービス」っていうんやで、と。
まーじで、技術本とかの恣意的なつまみ食いで訳分からん理論構築すんなよ。
それでプロダクトがうまく回ってなかったら、それが答えなんよ。
まぁ、「うまく回ってる状態」ってのを知らない、理解できないだろうから、正しい答えに行きつかんだろうけど。
その正しい答えに行きつかない、ってのを
「致命的な才能の欠如」
って呼ぶんよ。
AI ポルノの発展は遅い。すでに動画生成で再現VTRなどを容易に作る技術は存在するのに、それがエロに活用されている事例はない。ソフトウェアの方に制限があるからだ。
もちろん実在女性のポルノ化は個人の権利を侵害していると思う。しかし、非実在の人物であればそのような権利を侵害することなく性のはけ口となることが可能だ。それにより性加害が減ったり、セックスワークの需要が減れば、フェミニストや実在女性にも利益があるのではないだろうか。
私が認識できていない、AI ポルノの問題点があれば教えてほしい。
GPG認証は、公開鍵暗号方式（PGP）を使用する「GNU Privacy Guard（GPG）」というソフトウェアによる認証方法です。データの送信者が、自身の秘密鍵で電子署名を行い、受信者がその署名と送信者の公開鍵を照合することで、メッセージのなりすましを防ぎ、データの完全性を検証します。
dorawiiより
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 https://anond.hatelabo.jp/20251029130858# -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaQGTXQAKCRBwMdsubs4+ SKv1AP0aPZgGDDbx7vWPPpJHGLjv7cxtItRWqYZNev7hTm2omAD/Q0wd3r2idg6N 6IMgzg2/CA731qT13BUNwDVQFWaXwA0= =jF8g -----END PGP SIGNATURE-----
ダイヤモンドの↓の記事が盛りすぎでブクマカが釣られまくっているので、ちょっと落ち着けという意味で少し解説する
普通の人が「フリック入力を発明」というフレーズを見たら、どっちを想像する？
1. 上下左右方向のフリック操作で文字入力する手法を考案した
普通は1を想像するよね。でも、上の記事の「発明」は2の意味。8割くらいのブクマカはここを勘違いしてコメントしてるように見える
同じ発明家氏の記事でも3ヶ月前の東洋経済のほうは、「フリック入力を発明」という釣りフレーズこそ使っているものの本文を良く読めば発明のキモの部分が2であり1では特許を取れなかったことがそれなりに分かるように書いてある
「フリック入力」を発明しMicrosoftに売却した彼の"逆転"人生。元・売れないミュージシャン兼フリーター、家賃３万のボロアパートでひらめく
https://b.hatena.ne.jp/entry/s/toyokeizai.net/articles/-/889631
もちろん2の意味の発明もスゴイし重要なんだけど、釣りは良くないよね
そもそも世の中のほとんどの技術は様々な発明やアイデアの集合体である。歴史の積み重ねであり、最終形がいきなり湧いて出るわけではない。もちろん「フリック入力」にも歴史の積み重ねがある。それを少し紐解いてみよう（なお、下記の「年」は引用可能な特許や論文が出た時期であり、実際にはそれよりもっと前にソフトウェアがリリースされていたりアイデアがメーリングリストに投稿されていたりすることもある）
[追記]※増田の仕様上ひとつの記事に貼れるリンク数に制限があるため一部URLのhを抜いている点、不便ですがご了承ください[/追記]
ttps://dl.acm.org/doi/10.1145/57167.57182 (論文)
放射状に選択肢を並べるUIのアイデアは1960年代から見られるが、接地点からの移動方向情報を用いた入力手法の祖としてはとりあえずこれを挙げることができるだろう。これは文字入力に特化したものではなく、一般的なメニュー選択のための手法である
ttps://dl.acm.org/doi/10.1145/191666.191761 (論文)
pie menuを文字入力に応用したもの。論文の著者はAppleの人。英語用。広義の『「フリック入力」の元祖』に最も該当するのは、おそらくこれだろう
ttps://rvm.jp/ptt/arc/227/227.html
ttp://www.pitecan.com/presentations/KtaiSympo2004/page65.html
T-cubeを日本語に応用したもの。広義の『日本語版「フリック入力」の元祖』の候補
https://web.archive.org/web/20080925035238/http://www.j-tokkyo.com/2000/G06F/JP2000-112636.shtml (特許)
https://newtonjapan.com/hanabi/
Apple Newton (PDA)用に実装された文字入力UI。「中央が『あ』、上下左右方向が『いうえお』」に対応する見慣れた形のフリック入力がここで登場する。『現在よく見る形の日本語版「フリック入力」の元祖』である。なお、開発者が特許を申請したものの審査を請求しておらず、特許としては成立していない
この頃、Human-Computer Interaction分野でT-cubeやHanabiの発展としての文字入力手法の研究が活発になり、特に国内学会で多くの手法が発表された。情報系の学生の卒論や修論のテーマとして手頃だったからだろう。PDA製品に実装されて広まった例もあり、SHARP Zaurus用のHandSKKや、少し時代が下ってATOKのフラワータッチ等もこの系譜である
なお、この頃までの技術は指での入力ではなくペン（スタイラス）による入力を想定したものが主である（iPhoneの登場以前はキーボードレスのモバイル端末といえばPDAやタブレットPCなどスタイラス入力を前提としたデバイスが主流だった）
『スマートフォン上の「フリック入力」の元祖』であり『予測変換機能を備えた「フリック入力」の元祖』である。日本語フリック入力の効率を考える上で予測変換の占めるウェイトは大きく、「実用的なフリック入力」を実現するには予測変換との組み合わせは外せない。2006年にAppleに招聘されてiPhoneのフリック入力機能を開発した増井俊之氏は元々予測変換のPOBox（1998年 - ttps://dl.acm.org/doi/10.1145/274644.274690 ）の開発者として知られる研究者であり、Appleへの招聘もその経験を買われてのものだろう。入力にフリック操作を用いること自体は特筆すべきものではなく、当時の流行を考えれば自然な選択だったと思われる
なお、前述のHanabiの開発者氏がiPhoneのフリック入力を見て
と言っている一方、増井氏はHanabiに対して
知らんがな
と言っている。この分野の研究をしていて知らんことあるか？とも思うが、電話用テンキーの上に五十音かなのフリック入力を実装すると誰が作っても概ねHanabiのような外観になると思われるので、本当に知らなかったとしても齟齬はない
ttps://www.j-platpat.inpit.go.jp/c1801/PU/JP-2008-282380/11/ja (特許)
『画面表示は絶対座標＋移動判定は相対座標で行うことで「フリック入力」の入力効率を向上させる手法の特許』である（詳しい仕組みは上記の東洋経済の記事に書いてある）。ペン先と比べて指先は太いため指によるタッチでは厳密な操作が難しく（fat finger問題）、「実用的なフリック入力」を実現するにはこのような工夫も必須になる。小川氏の凄いところは、スマホの日本語UIをリリースするならどのメーカーも必ず実装するであろうこの工夫を、日本版iPhoneのリリース直前、Apple社としては引き返せないであろうタイミングで特許申請したところだ。機を見るに敏すぎる。特許庁に2回も拒絶された特許を不服審判で認めさせているところも本人が弁理士だからこそできる強さだと思われる
なお、氏の記事を読むと「フリック入力」自体を氏が考案したように思えてしまうが、ここまでに述べた通りそれは誤りである。「フリック入力に関連する重要な特許の公報に『発明者』として掲載されている」ことは疑いない事実なので「フリック入力の発明者」と称するのはギリギリ誤りではないと言えないこともないが、「フリック入力を発明した」はやはりダメだろう。上述の通りフリック入力自体は90年代に既に登場しており00年代の前半にはタッチスクリーン上のかな入力手法の一角を占めるに至っていたので、iPhoneに実装されたことは不思議でもなんでもなく、
このあたりは荒唐無稽な邪推すぎて、ソフトバンクから名誉棄損で訴えられたら危ないのでは（そもそもiPhoneのフリック入力を開発したのはAppleであってソフトバンクではない）
まとめると、さすがに小川氏の記事はモリモリに盛りすぎである。書籍の宣伝にしても酷すぎる。価値の高い特許を取った発明家であることは事実なのに、なぜこういう胡散臭いムーブをしてしまうのか
1998年にApple Newton用に開発された日本語入力システム「Hanabi」が草分けで、2008年にiPhoneに採用されたことで、急速に広まった。従来の「あ段→い段→う段→え段→お段」とキーのプッシュを繰り返して表示・入力する方式（トグル入力）に比べ、素早い入力が可能になる。その入力効率の高さから、2010年頃にはキーボード離れが加速している[1]。
1998年にApple Newton用に開発された日本語入力システム「Hanabi」[2]が草分けで、2008年にiPhoneに採用されたことで、急速に広まった。日本におけるフリック入力は、発明家でシンガーソングライターの小川コータがiPhone上陸以前に考案し2007年から2015年にかけて特許出願した[3]ものであり、取得した権利はマイクロソフトに譲渡された[4]。
ただ、これはおそらく関係者の自作自演等というわけではなく、日本におけるフリック入力関連特許が小川氏のものばかりであることからボランティア編集者が勘違いしてこのような記述にしてしまったのではないか。フリック入力は前述のように地道な技術の差分の積み重ねなので、個々の差分の開発者が「特許」を取ろうという気にならないのは良く分かる。その点でも、自ら弁理士として特許を量産した小川氏の強さが際立っている（が、やはり盛りすぎは良くないと思う）
だからそれは何の証拠があんのよ？エンジニアならちゃんとデータみて判断しろよ
| 企業 | 求人要件（Software Engineer） | CS学位必須？ |
| “Bachelor’s degree or equivalent practical experience” | 不要 | |
| Microsoft | “BS in CS or related field, or equivalent experience” | 不要 |
| Amazon | “Bachelor’s or 3+ years of experience” | 不要 |
| Meta | “BS or equivalent” | 不要 |
| Apple | “BS in CS or related technical field or equivalent” | 不要 |
で、実際の統計な
| 項目 | 割合 |
| ソフトウェア開発者の学歴 | |
| - CS/工学系学士 | 58% |
| - 非CS系学士（数学、物理、経済など） | 22% |
| - 学位なし（独学・ブートキャンプ） | 20% |
----
「My Job Went To India」の改題改訂版が「情熱プログラマー」なんだ！ありがとう発注したわ。（たぶん達人プログラマーと混同して読んだ気になって読んでないパターンだわ）
俺の悪文のせいで意図が伝わらなかったであろうブコメがあったので、要旨だけ書き直しておくな。
ただ忘れないで欲しいんだけど、TerraformメンテしてAWSとかGCPで立ち上げてサービス公開するまでの速度は、相見積取って稟議通して部材調達から入ってた時代に比べると爆速だけど、人間の技術屋の需要は増えてる。
俺は、「マスタリングTCP/IP 入門編」を人間が読んで理解するのは古いよね、という時代にはならないと思ってる。
Slerが自前で手元で試すようになるから～ってのも懐疑的。SIerやメーカーが内製すると必ず子会社作って分離、ぼく発注者きみ受注者にしたがるので。これは技術じゃなくて感情とか経営の問題。
（ただし、Slerが7payみたいなことやらかすのでは？って疑問なら同意。たぶんそういう生成AIで俺たちでプロダクトなんか簡単に作れるじゃんよギークいらね（仕様バグあり）は一時は増えるだろうね）
追記ここまで
----
VibeCodingでIT技術者は不要になるのか？という話題が花盛りなのは理由があります。
ギーク（現場でコードを書いていたい人）が分かる話から、スーツ（人を集めたりお金を集めたり営業をする）が分かる話になってきたからです。
具体的に言うと、OpenAI社をはじめ続々とTDD(テスト駆動開発)でやってますみたいな、具体的な開発スタイルの話が出てきたから。
そうすると、現場の座組チョットワカルという強めの経営者が理解して判断し始めるんですね。
でもね、その道はもう15年も昔に我々は通り過ぎました。前回のブームと何が違うでしょうか？
技術者なら電子も機械も強電も弱電もお世話になったことのあるオーム社が過去に出していた直球の本の話から。
「My job went to India : オフショア時代のソフトウェア開発者サバイバルガイド」という書籍、何と発行年は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 to AI として、じゃあ残るものは何？というのはオーム社の本を読みましょう。再販しないかなあ。
今後数年は変わらないでしょと書いたら今現在進行形で変わっとるわいと突っ込みが来そうなんで防衛的な意味で書いておくんですが、あなたは過去数年間同じ仕事してたんすか？
仕事のやり方とか内容とか、言語とかライブラリとか、毎年のように変わってたでしょ。
レビューの比率が多くなったとか、コード書かなくなったとか、そういうの、たぶん管理職になった人が嘆いてたのと同じっすよね？
少なくとも、ジュニアエンジニアが低品質なバイブコーディング結果を寄越すようになってレビューが大変とか嘆くのなら、まともなコーディング規約一つ作れていない組織の脆弱さを嘆くのが先では？
手癖でバイブコーディングしてヒットしたプロダクトに、あとから品質上げるように大工事するリファクタリングと言うよりリビルディングな仕事って、別に今もありますよね？
散々テストケースを書かなくて良いプロダクトなんて無いという講演だけ聞きに行って、自分とこでテストケースが自動で走るようになって無いなら、そこが問題でしょ。
一連のShopify強奪事件によって、BundlerとGemsがruby core teamに還元されたが、ついに管理権限の全権掌握に失敗した。
そもそもrubyとはrubyという言語単体の開発とメンテを司っており、言語仕様は見ているがエコシステム全域を見てるわけではない。Matzですらそうだ。
rubyにおいては、BundlerもGemsも言語の付属品という立ち位置だ。
近年の言語は言語仕様もパッケージ管理システムも全部コアメンテナに権限を委譲する。しかしrubyはそうなっていない、C/C++のように。
bunやrustに馴染んでる人には意味がわからないかもしれないが、往々にしてこんな権限統合失敗事案はOSSのアセットマネジメントにつきものだ。
古くはperlが、そしてその後phpもが、やらかした。web業界は過激なオープン思想の裏で、常に権限の落ち着きどころにリポジトリを悩ませている。
だから自由という名の管理放棄パッケージから、法人格での中央集中管理へとOSSはシフトしてきた。ここ１０年でFOSは死んだと言って良い。
ソースコードの開示はサプライチェーンの混入可能性を第三者検証可能にする健全性の証左としてきた。OSSコミッターの高額収入はこの信用性が担保していた。
しかし自由ソフトウェアとは自由の範囲を明示的に境界引きしており、本件では自由の範囲外にBundlerとGemsがあった。
つまり自由とは何であるか政治的に理解してない局面においてOSSコミッターはそれを行使するのに無力であり、実際法人格のプレッシャーに負けた事を証明した。
これは歴史的転換点だと思う。
Matzが間に入らなければ、rubyはメンテコストを捻出できず崩壊する所だった。たまたまMatzという優秀すぎる人間がいたので、どうにか死なずに済んだだけだ。
逆に言えばこの崩壊は真祖Matz以外が止められるものではなく実質、Shopifyの強圧に屈してrubyは死んだのだ。
金がないruby core teamはShopify主導のサプライチェーン混入可能性を否定できない環境が整ったのだ。
日本だとクックパッドやSkebが該当するだろう。未だにruby製バックエンドを使ってる企業はサプライチェーン混入可能性を常に評価してrubyを運用する責務を負った。
どの言語だってその可能性は常に念頭にあるが、この歴史的転換点を観測してしまうと、高すぎるリスクを保有するテック企業として技術力を喧伝してきた信用は底値を叩く。
コンピューターサイエンスの信頼性という文脈で、信用を失うのだ。
リンクケーブルが家電量販店に売っていないという状況は実際によくあることで、その代替手段として複数の選択肢があります。
それぞれの方法を面倒さと実用性の観点から詳しく比較してみましょう。
リンクケーブル（USBデータ転送ケーブル）は確かに便利ですが、小さな家電量販店では取り扱いがないことが多いです。
2台のPCをケーブルで接続し、専用ソフトウェアを起動するだけで、ドラッグ&ドロップでファイル転送が可能です。
面倒さ：★☆☆☆☆
手順
注意点
紛失リスクあり
面倒さ：★★☆☆☆
入手できれば最も効率的です。
入手困難
面倒さ：★★★☆☆**
LANケーブル（クロスケーブル推奨、ただし最近のPCはストレートケーブルでも可）
設定手順
2. IPアドレスの手動設定（例：PC1を192.168.1.1、PC2を192.168.1.2）
3. 共有フォルダの設定
面倒さ：★★★★☆**
手順
3. 共有フォルダの設定
4. ファイアウォール設定の調整
転送速度が遅い
設定が複雑
面倒さ：★★★★★
手順
高速転送
確実性が高い
実際的な推奨順序
状況別のベストチョイス
1. 予算に余裕がある場合：外付けSSD購入（後々も活用可能）
3. 技術的な設定が苦手な場合：遠くの家電量販店でリンクケーブル購入
質問の状況では、外付けHDD/SSDの購入が最も実用的でおすすめです。
初期投資はありますが、設定不要で確実にデータ転送でき、今後もバックアップ用途で活用できるためコストパフォーマンスが高いです。
LANケーブルでの直接接続も、設定に多少の手間はかかりますが、高速転送が可能で実用的な選択肢です。
