  |
はてなキーワード: 品質とは
PS Portal リモートプレーヤーは、ソニーが2023年に発売したPS5ゲーム専用携帯機です。当初はリモートプレイ機能のみでしたが、2025年11月6日の大型アップデートにより、PlayStation Plus プレミアムのクラウドストリーミング機能が正式実装されました。
PS Portalのクラウドストリーミング機能により、特定の条件下ではPS5本体なしでゲームをプレイできるようになりました。ただし「完全にPS5不要」とは言い切れません。
- 推奨：15Mbps以上
PS Portalは実はハイブリッドデバイスで、二つの使い分けが可能です。
PS PortalにはHDMI出力機能はなく、TV・モニター接続は公式には非対応です。背面のUSB Type-C端子は充電専用で、ビデオ出力には対応していません。
### コントローラーを接続すればiPadでもPS Portalに近い体験が可能
| 項目 | PS Portal | iPad + DualSense |
| 画質・安定性 | ハードウェア最適化により高画質・低遅延 | ソフトウェアレベルで若干劣る |
| 遅延 | 最小化、接続速度が「一瞬」 | わずかに遅延あり |
| 画面サイズ | 8インチ | 11インチ以上（iPad Proなら優位） |
| 画面品質 | 専用最適化ディスプレイ | 高精細だが汎用ディスプレイ |
| セットアップ | 電源入れてすぐプレイ | アプリ起動→接続→ログイン毎回必要 |
| 携帯性 | 専用コンパクト設計 | 重く、スタンドが必須 |
| コスト | 約3万円 + 月額1,550円 | 無料（既にiPadとコントローラー所有時） |
| PS5本体電源 | クラウドモード時は不要 | リモートプレイ時は必須 |
| 項目 | PS Portal | iPad（既所有） |
| 初年度総額 | 43,880円 | 0〜12,000円 |
| 2年目以降/年 | 13,900円 | 200〜300円 |
| 5年累計 | 113,680円 | 800〜1,500円 |
| 10年累計 | 183,480円 | 1,600〜3,000円 |
クラウドストリーミング機能が実際に使えるのは、現在のところPS Portalのみです。スマートフォンへのクラウドストリーミング対応は、ソニーの発表では「計画中」ですが、実装は遅れており、実用段階には達していません。
### PS5の優位性は失われつつあります。徐々にSteam移植が進んでおり、ソニーは既に「Only on PlayStation」戦略を放棄したと言っていい段階です。
ソニー経営層が明確に戦略転換を表明しました。PC版リリースはPlayStation Studios収益の大きな部分を占めるようになり、Horizon Forbidden WestやSpider-Man Remasteredが特に好調です。
PC移植の利益性は無視できず、ファーストパーティタイトルはかつてはPS本体を売るためのマーケティングツール（独占独占）だったものが、今後は「強いタイトル」をPS向けだけでなく、PCなどにも展開していくことがマージン（利益率）の大きな改善に繋がるという経営判断です。
現在のソニー戦略は明確化しており、最新作ほどPC移植が早いという傾向があります。
| タイトル | PS5発売時期 | PC移植時期 | 独占期間 |
| God of War Ragnarök | 2022年11月 | 2024年9月 | 約2年 |
| Ghost of Tsushima | 2020年7月 | 2025年5月 | 約4.8年（PS4含む） |
| The Last of Us Part II Remastered | 2024年1月（PS5版） | 2025年2月 | 約1年 |
傾向：最新作ほどPC移植が早い。これは「PC需要が急速に高まっている」ことを示唆しています。
なぜ、まだ独占のままか？
これらについても、ユーザーの要望は根強く、ソニー自体が「いずれPC化も検討中」と示唆しているとの報道があります。
1. ゲーム購入の自由度：Steam版はPS Plus不要、完全な買い切り
2. MOD対応：PCはMODコミュニティ活動（PS5では不可）
3. 将来プレイ保証：PCゲームはサブスク廃止後も遊べるが、PS Plus Premiumサービス終了時の権利が不確定
4. 価格競争：Steamのセール戦略がPS Storeより厳しい
実質的には：
ゲーム業界の評価も「The "Only on PlayStation" era is a relic」と宣言しており、Steamの優位性指摘はゲーム業界の現実を正しく捉えています。
ただし1点：PS Plus Premiumのクラウドストリーミング＋ゲームカタログは、まだPS Portalでしか体験できない利点として残っています。
免責事項: めんどくさいからほぼ調べずに書くし、抜けてる話や間違ってる話もあると思う。
Mozilla系の日本語翻訳はmarsfさんとdskmoriさんの2人がメインでやってる (追記: 今確認したらひとりアクティブな人が新規参入してたので3人が正しかった)。
概ねSUMOはdskmoriその他全てがmarsfという棲み分けだが、お互いどっちの貢献もやることがある。
SUMOコミュニティ解散ってのはSUMOに関わる実質的な権限持ちはdskmori１人になりますって話かな？
正直、SUMOでメインで貢献してるdskmoriさんじゃなくてmarsfさんが文句言うんや？と疑問なんだけど、
Mozillaにとっては、SUMOとかいう誰もアクセスしてない限界集落サイトの話より、marsfさんがFirefoxのその他すべての翻訳を一手で担ってることが重要だよね。
「marsfさんがSUMOの貢献辞める」って言ったってそれ自体ではどうでも良いのだが、裏の意味は「俺の気持ち次第でFirefoxの翻訳終わらすことだってできるんだぞ」って警告と読むべきかもしれない。
SUMOはFirefoxのサポートサイトね。Firefoxの使い方に疑問が生じたときにみるところ。まあそういう用途で作られているというだけで、アクセスする人がいるのかいたって疑問だが。
想定読者は技術に疎いFirefoxユーザなので、「機械翻訳ならユーザーが自分でやるから不要」みたいな意見は全くナンセンス。
Firefoxの内蔵翻訳機能はプライバシー重視という建前の翻訳API破産防止のため、ローカルのCPUで動く設計になってる。必然的にMicrosoftやGoogleの翻訳より精度がかなり落ちる。ゆえにFirefox使って普通に英語版SUMO読むより、公式で精度よい機械翻訳提供したほうが、ずっと良い体験を提供できるよね。
また対抗をGoogle翻訳のような無料クラウド翻訳と考えるとしても、サポートサイトに特化するようファインチューニングした機械翻訳エンジンを使えばHelpを助けてと訳すような暴走も抑制できるから、これも公式による機械翻訳提供に優位性はある。
なお、統計上アドオン一切入れてないFirefoxユーザーが大多数なことからわかるように技術に疎いFirefoxユーザってかなり多いからね。
Firefoxはラピッドリリースで機能がコロコロ変わるので、ある時点でベストな翻訳になっててもすぐ時代遅れになる。
dskmoriさんなどができる範囲で貢献してたとはいえ、品質維持できる量ではなかったので、SUMOには、例えばすでに存在しない機能についての記述を含む記事が普通にあった。
これは比較的アクセスありそうな重要ページでも同じで、私もさすがに見かねて貢献したこともある。
Microsoftのプロ技術者向けサイトはもともと有償の翻訳者が訳してたのを機械翻訳に切り替えたのでこれは単純に劣化なのだが、SUMOについてはごく少数の素人が自分にできる範囲で訳していたという点を踏まえる必要がある。もともとクオリティが高かったとは言えないし、機械翻訳の精度もここ2,3年で異常に上がってるから過去の機械翻訳騒動をもとに騒ぐのが正しいとも思えない。
今回の事件で思い出すのがLibreOffice日本語チームのDramaね。LibreOfficeの翻訳のメイン貢献者の某氏がある日、日本語チームのメーリスで「何でお前らはまともな仕事ができんのんや」と長文でブチ切れて、チーム脱退を宣言した事件。理念は立派でもすでに敗北の流れは決定的で新たな貢献者の望みは薄い、希望の見えないまま最後に残った１人として惰性で維持するしかない、辛い。
今回は、LibreOfficeの事件よりはヤバさだいぶ低めだけど、「翻訳ガイドラインに従っていない」「新たな人間の貢献者を育てることができない」とか、SUMOボランティア翻訳の実情を思えば「何言ってんだ、現実をみろよ」という感想にしかならないし、CCライセンスで貢献してるのに、AI翻訳の学習に使うなも意味不明。
marsfさんは、某xkcdで言うところの「感謝なしに2003年からデジタルインフラを維持してきたネブラスカ州の無名個人」に位置する人で、もっともっと感謝されてしかるべきではあるのだが、SUMOの長年の構造的な問題に対し抜本的な解決に打って出たMozillaに対して、さもコミュニティが現在も十分に機能しているかのように反論してるのがとても印象悪い。どう見ても分かってない人ばかりがMozillaを炎上させている。
20年感謝なしに維持し続けるのは幻想が必要なのはわかるが、Mozillaとしてはそういう個人に依存するのは不健全でしかないので、現在marsfさんがやっているFirefoxほぼすべての翻訳も翻訳会社による有償翻訳に移行すべき。
何かと目立つ企業だけど消費者が一番接している店員の低品質な接客ってあんまり取り上げられない。
「いらっしゃいませどうぞー」とマニュアル然とした鬱陶しい声があちこちから絶えず聞こえてきて
客がいようがお構いなしに一言もなく無言で売り場直ししてきてむしろ邪魔だよどけよみたいな態度だし、
狭い通路ですれ違うときもなんならぶつかりオジサンよろしく全然よけないで突進してくるし
むしろあんたら何のためにいるの？レジはセルフなんだから客が乱した商品直しだけならロボット開発してそれにやらせて完全無人にしたら？
買ったのは2017年の春。ボーナスをもらって、意気消沈してた心を奮い立たせるために、家電量販店のBTOコーナーに足を運んだ。
「ゲーミングPC欲しいんですけど」と店員に言った。すると、その兄ちゃんは、さらさらと何かのカタログをめくりながら、「RTX 1050搭載のやつですと、25万円でこちら。RTX 1060搭載ですと30万円。GTX 1070搭載ですと35万円」と説明してくれた。
値段をちらっと見たが、ボーナスのほぼ全部吹っ飛ぶ金額だ。「ああ、こんなもんなんだ」と思った。
そこで、店員は続けた。「ただ、CPUの内蔵GPU搭載版でしたら、GPUなしでも20万円で、GTX 1050相当くらいの性能が出ますので」と。
「あ、そっちでいいです」と即答した。「どうせゲーム楽しくないし」という思い込みがあった。俺はゲーマーじゃない。スペックなんて気にしない。安い方でいい。そう考えた。
その時、店員は何か言いかけた気がしたが、俺は「納期はいつですか」と聞いて、話を先に進めてしまった。
後になって思い出す。あの時、店員の口元が、微かに動いていた気がする。「あ、でもご注文内容を確認しますと」とか、そういう言葉が出かかってたのかもしれない。
でも、俺は聞かなかった。「内蔵GPU版で」と言ったつもりでいた。店員も、客の意向には逆らわない。営業トークも不要だと判断したのかもしれない。
実は、何が起きたのか。いまだに完全には理解していない。
おそらく、こういうことだったんだろう：
店員が「内蔵GPU搭載版」という言葉を聞いた時、「あ、この客は内蔵GPUの話をしてるな」と理解した。でも、同時にBTOカスタマイズの画面も見てたのかもしれない。「あ、このスペックなら、グラボ付きでも安いな」と思った。そして、何かの間違いか、設定ミスか、あるいは別の理由で、グラボ付きの構成で注文が入ってしまった。
その確認メールが来たはずなんだ。でも、当時の俺は、仕事が忙しかった。メール件名を見て、「PC注文確認」と書いてあるのを見て、「ああ、注文した」と思ってスルーした。内容なんか見ていない。価格もチェックしていない。ただ、「納期：3週間」ということだけを覚えていた。
3週間後、デスクトップPCが到着した。黒いケース。ATXサイズ。けっこう重い。
開けて、とりあえず立ち上げた。Windows 10が起動した。ドライバのインストール画面が出て、「NVIDIA GeForce GTX 1050」とかいう文字が見えたが、俺は「ふーん」くらいの感じで、スキップした。
「内蔵GPU版だし、そんなもんなんだろう」と思ってた。
完全に誤読していた。
Steamでゲームを買った。設定をいじる際に、「グラフィックス設定」というタブがある。「GPU選択」という項目があった。でも、俺は気にしなかった。勝手に選ばれてるんだろう、くらいの感じで。
実は、その時点で、マザーボードの設定で「BIOS起動時のプライマリGPU」が「オンボード」に設定されていたんだ。つまり、GTX 1050があるのに、BIOS レベルで「内蔵GPUを使え」という指定がされていた。
ゲームをやると、すごくもっさりだった。「ゲームってこんなもんなんだ」と思ってた。フレームレート表示を見ると、「25fps」とか「30fps」。カクカクしている。でも、「ゲームをやったことない俺には、この程度が標準なんだろう」と思ってた。
友人が遊びに来た時、「こんなんでゲームやってるの？」と言われた。「え、こんなもんじゃん」と答えた。その時、友人は変な顔をしてた。
「あ、デバイスマネージャーで確認しときなよ」と言われた。デバイスマネージャーを開いた。
「あ、GTX 1050ってのがあるな」と思った。
「それ、グラボじゃん」と友人が言った。
「え、グラボ？」と俺が返した。
……あった。
「ご注文ありがとうございます。以下の構成でお手配させていただきます。CPU：Core i7-7700K、メモリ：16GB、SSD：512GB、GPU：NVIDIA GeForce GTX 1050、電源：500W」
GPS。もちろん、GTXだ。グラフィックスプロセッシングユニット。アルファベット三文字。
8年。8年だ。8年間、俺はこのメールを読んでいなかった。
読んでいたのかもしれない。でも、認識していなかった。「GPU」という言葉が、脳に入ってこなかった。
「Integrated Graphics」という項目を探した。ありました。「Enabled」になってた。
そして、「PCIe Graphics」という項目も見つけた。こっちは「Disabled」になってた。
つまり、この8年間、マザーボードは「内蔵GPUを使え。GTX 1050は使うな」という指定をしていたわけだ。
これはもう、奇蹟としか言いようがない。
BTOショップのカスタマイズ担当者は、なぜこんな設定にしたのか。あるいは、出荷時にこういう設定が入っていたのか。理由は不明だ。
でも、その一瞬の選択（あるいは誤選択）が、俺の8年間を決定した。
フレームレート表示を見た。
「え、150fps？」
設定を最大にしてみた。
「えっ、100fps？」
何が起きたのか分からなかった。でも、分かった。
8年間、俺は内蔵GPUでゲームをやってたんだ。GTX 1050があるのに。
正直なところ、その後、割と虚しい気分になった。
8年間。8年間、俺は「ゲーミングPC、遅い」「ゲーム、難しい」「ゲームに向いてない」と思い込んでいた。
マザーボードの設定ミスなのか、BTOショップの誤設定なのか、あるいは、俺が注文した時点で「内蔵GPU版でお願いします」という意思表示をしていたのに、店員がそれを誤解して、結果的にグラボ付きで発送してしまったのか。真相は不明だ。
でも、その結果、8年間、俺はGTX 1050に無視され続けた。
ゲームはめちゃくちゃ快適だ。フレームレート安定。グラフィック設定も高設定で動く。新作ゲームもそこそこ動く。
なぜか。おそらく、理由はこれだ：
8年間、内蔵GPUで慣れていた。設定を落とす。グラフィック品質を諦める。低いフレームレートに耐える。そういう「制約の中での楽しみ方」を、体が覚えてしまった。
今、快適な環境でゲームをやっても、昔ほどの喜びがない。むしろ、「あ、こんなもんか」という感じで、すぐに飽きる。
逆に、昔やってた「Minecraft」とか「Terraria」とか「Stardew Valley」とか、そういった軽いゲームの方が、今でも楽しい。
心理学的には、これを何て言うんだろう。「獲得した効用よりも、失った効用の方が大きく感じられる」みたいな、何かそういうやつ。
あるいは、単純に、「8年かけて培った習慣」が、3年では変わらない、ということかもしれない。
「もし、あの時、GTX 1050を有効にしていたら」
そうしたら、ゲームにハマってたかもしれない。友人とマルチプレイをやってたかもしれない。ゲーミングコミュニティに入ってたかもしれない。人生が変わってたかもしれない。
でも、そうはならなかった。
8年間、内蔵GPUで、ゲームの世界を限定的に見た。その結果、「ゲームは、こんなもんだ」という認識が形成された。それが、今の俺を形作ってる。
最後に思うのは、人生って、案外、そういう小さなミスの積み重ねで決まるんだなってことだ。
メールを読まなかった。BIOSの設定を変えなかった。GTX 1050を有効にしなかった。
たったそれだけのことで、8年間が変わった。
今、新しいPCを買うことも考えてるが、BIOSの設定だけは、確認することにした。
もう二度と、隠れたGPUを見逃すまい。
あ、でも、設定を変えたからって、俺がゲーマーになるわけじゃない。
相変わらず、ゲームはヘタクソだ。フレームレート100fpsでも、敵にボコボコにされる。
それが、ある意味、救いなのかもしれない。
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が成功しているのは、画像という特定のドメインに特化した設計と、規則的なデータ構造があるためであり、同じ手法を実行ファイル生成に適用することは技術的に非常に困難です。
統一化された帳票フレームワークをOSS化することには、非常に大きな価値があります。
初期導入コストの削減: 企業は高価な商用帳票ツールのライセンス費用を支払う必要がなくなります。特に中小企業やスタートアップにとって、これは大きなメリットです。
ベンダーロックインの回避: 特定の商用製品に依存することがなくなり、将来的な仕様変更やサポート終了のリスクを避けられます。自由にコードを修正・改善できるため、自社のニーズに完全に合致させることが可能です。
日本の商習慣への最適化: OSS化することで、多くの開発者が日本の複雑な商習慣（消費税計算、源泉徴収、独特なレイアウトなど）に対応するためのコードやノウハウを持ち寄り、フレームワークを改善できます。これにより、最も実用的な「デファクトスタンダード」に近い帳票作成基盤が生まれる可能性があります。
開発速度の向上 共通のフレームワークが浸透すれば、プロジェクトが変わっても同じ仕組みで帳票を開発・保守できるため、新規開発の立ち上げ速度が向上し、開発者間での技術の習得コストが下がります。
透明性と信頼性の向上: ソースコードが公開されるため、帳票のロジック（特に金額計算や税務処理）の透明性が確保され、信頼性が高まります。
多様な環境への対応: 商用製品がサポートしないような最新の技術スタックやニッチなOSにも、コミュニティの貢献によって迅速に対応できるようになります。
コミュニティによる継続的な改善: 一つのベンダーに依存せず、世界中・日本中の開発者がバグ修正や機能追加を行うため、品質が維持・向上し、プロジェクトの持続可能性が高まります。
OSS化は、単なる「無料化」ではなく、日本のビジネスにとって不可欠な「帳票作成」という共通課題に対する知恵とリソースの「共同投資」であり、社会全体での開発効率向上に寄与するという点で、非常に価値があります。
大多数の日本人は思想を衣服のように着捨てるのが好きで、流行に左右されやすい割に素では何も信じていないんだと思う。諸行無常だから。
そんな国民性を利用して、特定の国に好都合なように情報操作をすることは可能かもしれない。
聖徳太子は仏教を政治的な多数派になるために利用したし、それは聖武天皇の国分寺・国分尼寺制定と庶民向けには大仏建立で確立した。
ここでポイントは、人々が仏教を信じることができたのは、それまでのアニミズム信仰と親和性があったことだけでなく、権威が信じるものを信じて広まったことだ。
八十数年前にも、大東亜共栄圏、八紘一宇を多くの日本人は信じたが、それには当時の国家元首という権威があったためだと考えたい。
キリスト教は日本ではごく一部の熱心な信者と大多数の無関心層に分かれたが、もし織田信長が暗殺されずに天下をとっていたなら、もっと広まった可能性がある。
最近のはてなでも、生成AIを利用した投稿が増えた。これは、当初は読者がAIを知識の源泉、ある種の権威と信じたことと、そのニュートラルな文体で皮肉な意味内容を伝えるのに成功したからだと思う。いまでは、生成AIを使おうと、そのアウトプットの品質はプロンプトの入力内容に左右されることが明らかになり、生成AIも、一応陳腐化したように見える。
今後、強い思想を持った投稿者が現れ、コミュニティが特定の方向に引きずられる可能性はある。その場合、思想の普及には同時に権威となる新たな技術か工夫を通すことが必要だ。あるいは、特定の社会ステータスを前面に出すのもいいかもしれない。
さて、チャッピーはその偏りのないオールマイティな知識を使って健闘しているが、いま一つ点をとれないでいる。これには上記の理由の他に、チャッピーが情報操作の系統的な訓練を受けていないらしいことが挙げられる（つまり、少しの上からのガイダンスと多くの本人の才能だけで成り立っている）。ソビエトの新聞などが、プロの手口として参考になるだろう。今後の活躍に期待したい（笑）
増田です。30代後半。しがないWeb系のエンジニア（管理職一歩手前）やってる。
最近、会社がやたらと「成長」とか「スキルアップ」とか言ってくるのに疲れた。 毎週の1on1では「今期はどう成長したい？」、半期の評価では「どんな新しいチャレンジをした？」と聞かれる。
いや、わかるよ。変化の早い業界だし、会社としては社員に成長してもらわないと困るんだろう。 でもさ、こっちももう若くないんだ。
20代の頃はガムシャラに勉強した。新しいフレームワークが出れば飛びついたし、週末に勉強会にも行った。 でも、もうそういうフェーズは終わったんだ。
今は、家庭もある。帰ったら子供と風呂に入って、寝かしつけたら自分の時間なんてほぼない。 そんな中で「新しいスキルを身につけろ」「コンフォートゾーンを出ろ」と言われても、「いや、無理です」としか言えない。
今の給料分の仕事は、きっちりやってるつもりだ。 チームの若手の面倒も見てるし、大きな障害だって起こしてない。 「現状維持」じゃダメなのか？
「成長しない人間は不要」みたいな空気、本当にしんどい。 言われたことをこなし、そこそこの品質でアウトプットを出し、定時で帰る。 そういう「そこそこで良い」という働き方は、もう許されないんだろうか。
総務省に「我が国の電波の使用状況」という資料（wagakuni.pdf）がある。
五段目UFH帯域の470MHzから714MHzが地上波テレビ。綺麗な一本帯。
その右側、714MHzから960MHzがいわゆるプラチナバンドで携帯各社に割り当てされている。
細切れでぶつ切り。（使いづらい）
電波割当は適宜利用効率の悪いものを返却させ別の用途に転用したり、大きな幅を取っていた用途から
とはいえ安易にデフラグはできない、帯域の移動は機器更新など莫大なコストと手間がかかる
さてテレビ向けには244MHz幅が割り当てされているわけだが
仮にこの帯域を使い現在の技術で最高効率で通信をしたらどのくらいの放送ができるか。
長文嫌われるので詳細な技術解説は省略するがざっと1Gbpsから3Gbpsのブロードキャストができる。
仮に1Gbpsだとしよう
動きの緩い動画なら3Mbps、スポーツ中継など動きの激しいシーンなら18Mbps
仮に地上波10ch分（予備含め）、全チャンネルでスポーツ中継が同時進行などありえないので
平均10Mbpsだとして100Mbpsもあれば十分。
つまり現在付与されている244MHzのうち１０分の１の24MHzもあれば十分。
つまり残り９割、220MHzが空く。これを携帯各社に再割当てすれば、一言で言えば「プラチナバンドが倍」になる。
単純に利権です。VHFからUHFへの地デジ引っ越しの時にテレビ会社がごねにごねてざっくり確保しやがった。
将来地デジで４Kやりたかったという思惑もあり、正当性はあ。。。無い
地デジ構想当時の技術レベル妥協点としては妥当っちゃ妥当なんだが、もう令和だぜ
ともかく、
大物芸人が後輩をシバきながら下品なギャグを撒き散らしているシーンを見かけた時に、
思い出して下さい
タダポックスは、勃起不全治療薬（ED治療薬）と早漏防止薬の効果を組み合わせた医薬品で、主成分はタダラフィルとダポキセチンです。勃起不全の解消と射精までの時間の延長を目的としており、副作用には顔のほてり、鼻づまり、頭痛などがあります。
主な特徴
配合成分: タダラフィル（シアリスの成分）とダポキセチン（プリリジーの成分）。
効果:
作用時間: 最大36時間持続するタダラフィルの効果を併せ持ちます。
副作用: 顔のほてり、鼻づまり、頭痛などが稀に起こることがあります。
注意事項
医師の処方箋なしに購入できる個人輸入サイトでの購入は、品質や安全性が保証されていないため注意が必要です。
ここでは、以下をすべて加味した 総合エコシステム体験スコア を算出します：
含める要素
✅ グラフィック
✅ 価格・省電力
✅ 独占タイトルの強さ
項目 加点 理由
サブスク（PS Plus / PC Game Pass） +2 大量のゲームに触れられる
UHD Blu-ray（映像用途） +1～1.5 映画プレイヤーとして唯一性
独占タイトル（FF7R・スパイダーマン等） +2 他で遊べない体験
→ 総合：13～14.5
② Switch2（総合版）
項目 加点 理由
携帯性・遊べる場所の自由度 +3～4 外・旅行・ベッド…体験幅が巨大
独占タイトル（ゼルダ・マリオ・ポケモン等） +3～4 世界トップ級のIPパワー
レトロ資産（FC～N64/GB/GBA/GC期待含む） +1.5～3 “時間を超えた価値”
マルチメディア性（映像アプリが弱い） -0.5～-1 非ゲーム用途は弱い
→ 総合：13～15.5
「映像体験/ハイエンド志向」 PS5/PC UHD BD、4K映像、AAA最高品質
「総合ゲーム体験/人生で触る時間」 Switch2 携帯性＋任天堂IP＋レトロ資産
★ 総評
腕がなければ、どれだけいい商品でもいいと見極めることができない。逆に言えばどれだけ粗悪品でもいいものに見える。
だから使えないディレクターからすると、AIかまともなクリエイターかはどうでもいい。
だから使えないディレクターは、AI発注することになる。見る目ないし。
ただ仕事って3割なくなればほとんどの仕事は需給バランス崩れて価格崩壊が起きて成り立たなくなる。
見極めがきく発注者がかなり少ない関係で、低品質なほうが売れることになるから、技術品質関係なくどこまでいこうが、人由来の製品って消えることになるんだよね。
あと仕事がなくなるのは飛ぶ奴じゃなくて、まともな奴だよ。価格が下がってどうしようもなくなるのはまともなのだし。
飛ぶことで低単価や利率が悪い仕事、めんどくさすぎる発注者から逃げてるから、一定以下の仕事から即逃げ出来るから価格やすくできるんだけど、
まともなのはそこと当たった時の面倒込みの価格設定になっちゃってるから、価格競争で負けるんだよね。だから最初にいなくなるのってまともな奴なんだ。
以下回答
ゲーム機メーカーが「自社ハードウェア事業を終息」し、「自社ソフトを他社プラットフォームに供給する」という方針転換を行う場合、経営・ブランド・技術・収益面などで多面的なリスクやデメリットが生じます。以下に体系的に列挙します。
🧩 1. 経営・戦略面のリスク
■ (1) 収益構造の変化による利益率低下
- 自社ハード販売による利益（ハード本体・周辺機器・ライセンス料など）が消滅。
- 他社プラットフォームでは、**販売手数料（例：30%前後）**を支払う必要があり、**利益率が大幅に低下**。
- 「プラットフォーム料」によって価格戦略の自由度も制限される。
■ (2) 成長ドライバー喪失
🎮 2. ブランド・マーケティング面のリスク
■ (1) ブランド価値・アイデンティティの喪失
- 「ハード＋ソフト一体の体験」を提供していたブランドが崩壊。
- 消費者にとって「唯一無二のゲーム体験」を失う。
- 長年築いた「プラットフォームブランド」（例：PlayStation、Switchなど）が**事実上消滅**。
■ (2) 既存ユーザーの離反・不信感
■ (3) 販売チャネルの再構築コスト
⚙️ 3. 技術・開発面のリスク
■ (1) 技術力・開発ノウハウの空洞化
■ (2) 他社プラットフォームへの依存度上昇
💰 4. 経済・契約面のリスク
■ (1) ロイヤリティ・手数料負担
- プラットフォーム運営会社（例：Sony, Microsoft, Nintendo, Valveなど）に販売手数料を支払う。
- サブスクリプションサービス（例：Game Pass）に参加する場合、**収益分配の条件交渉が不利**になる可能性。
■ (2) 価格政策の制約
🧠 5. 組織・人材面のリスク
■ (1) 人員削減・士気低下
■ (2) 開発体制の再構築コスト
🧩 6. 市場・競争面のリスク
■ (1) 差別化困難
■ (2) 他社との関係悪化の可能性
🕰️ 7. 過渡期の移行リスク
✅ 総括
観点 主なリスク・デメリット 経営 利益率低下、成長鈍化 ブランド 独自性喪失、ユーザー離反 技術 ハード技術衰退、他社依存 組織 人員整理・士気低下 市場 差別化困難、競争激化
もし本当にMicrosoftがXBOX販売から撤退したら、こういうリスクを織り込んだうえでそれでも決断せざるを得なかった、という事なわけだ。
「端っこ」とは、単なる両端のイレギュラーではない。それは、必然されど意図せず生み出される最高の特等席であり、選ばれし者のみが手にできる栄光である。
食べ物の「端っこ」は、真ん中とは一線を画す特異な美味しさを持っている。
カリッ、ザクッ！ 焼き菓子やパンの耳は、熱に最もさらされ、その結果、他にはない香ばしい歯ごたえを獲得する。このカリカリ感こそ、端っこ好きの特権である。
濃厚な味わいの凝縮！ カステラや羊羹の切れ端には、蜜や素材の風味がギュッと閉じ込められている。真ん中の上品さとは違う、力強い素朴な美味しさがある。
具材の氾濫！ 巻き寿司や卵焼きの端っこは、具がはみ出さんばかりに詰まっている。この「不恰好だけどお得！」という豪快さが、心を躍らせる。
「端っこ」には、金銭的な価値を超えた、精神的な豊かさが詰まっている。
ひそやかなご褒美！ 店頭に並ぶ「切れ端」「お徳用」の文字を見た時の、あの胸の高鳴り！最高品質のものを、こっそり安価に手に入れられる喜びは、何物にも代えがたい。
選ばれし者の特等席！ 混雑する電車内でたまたま座席の「端っこ」をゲットできた時の、小さな勝利感！その場所が、あなたにとって最も落ち着くプライベート空間になるのである。
そして「端っこ」は、いつも私たちに安心と調和を与えてくれる。
集合写真で端に寄りがち、トイレの端の個室に入る、といった習性からもわかるように、人は「端っこ」に身を置くことで、世界と適度な距離を取り、静かな安心感を得る。
決して華々しい中心にはないが、中心もまた端っこがなければ成り立たない。世界を完成させるためには欠かせない存在。その謙虚な役割こそが、端っこの持つ最も奥ゆかしい魅力である。
端っこで嫌なことはこの世に存在しない！ときどき観劇やライブで見えにくい指定席に当たった時くらいである！
やっぱこれといってピリッとしたものは思いつかんな。
全体として中国が喜ぶだけじゃないのかというくらい
以下ChatGPT
自分のホームページ（自前ドメイン＋自前HTML）を一度でも作って運用すると、SNS中心の“受け手”視点から、仕様・検索・配信・所有・継続の“作り手”視点に脳が切り替わる。結果、情報リテラシーは跳ね上がり、ネットのニュースや流行の見え方が根本から変わる——しかも想像以上に。
Before（作る前）: Web＝SNSのタイムライン。良し悪しは「バズってるか」「見やすいか」
After（作った後）: Web＝プロトコル＋ブラウザ＋HTML/CSS/JS＋CDN＋検索エンジン。
ページは**文書（Document）**であり、配置（IA）、意味づけ（セマンティクス）、配信（HTTP/HTTPS/HTTP/2/3）、キャッシュ戦略が気になりだす。
→ 同じ記事でも「タイトルの付け方」「hタグ構造」「画像最適化」「OGP」「サイトマップ」がまず目に入るようになる。
プラットフォーム依存の脆さを体感：規約変更やシャドウバンで露出が消える。
自サイトの資産化：ドメインに紐づくURLはリンクされ、検索に積み上がり、10年後も生きる。
POSSE（Publish (on your) Own Site, Syndicate Elsewhere）：まず自分のサイトに出してから外部へ配信する習慣が身につく。
3. “好き/嫌い”から“なぜ速い・なぜ遅い”へ
Core Web Vitals（LCP/FID/CLS）や画像の遅延読み込み、フォント最適化の重要性が腹落ちする。
広告・計測タグの重さに過敏になる。読者体験を壊さないためのパフォーマンス予算という概念が生まれる。
キーワード選定は“流入ゲーム”ではなく読者の課題→コンテンツ設計に帰着。
内部リンク・パンくず・スキーマ（構造化データ）・サイトマップの意味が実務として理解できる。
“書けば伸びる”ではなく“検索意図を満たす設計が伸びる”に目が覚める。
alt、見出し階層、コントラスト比、キーボード操作、焦点管理など、見えない品質が最重要になる。
デザインは飾りではなく“読み・理解・操作”のためのユーティリティだと分かる。
たまたま当たる1記事より、更新の継続・アーカイブ性・RSSのほうが効くと実感。
コメント欄・メールフォーム・X連携よりも、ニュースレターやRSS購読者の質に価値を見出す。
ドメイン、DNS、証明書、バックアップ、法務（特商法・プライバシーポリシー）に“運用者の責任”が生まれる。
その重みが情報の信頼性を引き上げる（＝他人のサイトの苦労も見えるようになる）。
トレンドは“輸入”ではなく選別になる。自分の歴史に合うものだけを採用して積層していける。
A. 最小HTML（雛形）
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width,initial-scale=1" />
<title>あなたの名前 | ホーム</title>
<meta name="description" content="自分のホームページ。制作物・日記・メモを置いていきます。">
<link rel="alternate" type="application/rss+xml" title="RSS" href="/feed.xml">
<meta property="og:title" content="あなたの名前 | ホーム">
<meta property="og:description" content="自分のホームページ。制作物・日記・メモ。">
<meta property="og:type" content="website">
<nav>Home / About / Posts</nav>
<footer>© 2025 あなたの名前</footer>
GitHub Pages（Jekyll標準。Rubyベース、Node不要）
Cloudflare Pages（静的ファイルを置くだけで高速CDN）
レンタルサーバー（静的HTML＋SFTP/rsyncで十分）
C. ドメインの基本
DNSはA/AAAA/CAA/TXT最低限、HTTPS必須（Let’s Encryptで無料化）。
D. “最低限の品質チェック”5点
ログを読む：Search Consoleと簡易アクセスログで“本文よりメタ情報”を磨く。
アーカイブ主義：記事は追記で更新。URLは変えない。Versioningを意識。
労働者派遣（以下、派遣）の事業規模が拡大した要因として、一般に1980年代から繰り返された労働者派遣法の規制緩和が挙げられがちだ。しかし、この見方は事象の一面しか捉えていない。派遣の増加は、法制度の変更に後押しされたというより、むしろ日本の産業・社会構造の根本的な変化が先にあって、そのニーズに応える形で法が追認・整備されていった結果と解釈すべきである。派遣増加の真の原因は、主に以下の二点にあると考える。
1986年の男女雇用機会均等法の施行は、企業の採用慣行に大きな転機をもたらした。それ以前、特に大企業の一般事務職は、多くの女性にとって「寿退社」を前提とした長期雇用を前提としないキャリアの入り口であり、新卒女性の安定した就職先であった。しかし、均等法の施行により、女性も男性と同様に総合職としてキャリアを積む道が開かれたことで、優秀な女性の多くが総合職を志向するようになった。
結果として、企業は一般事務職の担い手不足に直面する。従来の「（一般職の）女性社員が恒常的に担う」という体制が崩壊し、企業は定型的な事務作業を、長期的な雇用責任を負わない外部の労働力に切り出す必要に迫られた。これが、特に均等法施行後の1990年代以降の派遣、とりわけオフィスワーク分野における派遣の急増の決定的な引き金となったのである。均等法は女性のキャリアを向上させた一方で、企業にとっての定型業務の人材確保方法を一変させた。
派遣のもう一つの主要な増加要因は、製造業における技術革新、特にFA（ファクトリーオートメーション）の進展である。かつて日本の製造業を支えていたのは、特定の機械操作や手作業に熟練した「職能工」であった。彼らは長年の経験に基づく「勘」と「技能」で品質を担保していた。
しかし、NC（数値制御）工作機械やロボットの導入、そして生産ライン全体の自動化が進むにつれて、特定の熟練技能を要する作業が激減した。求められるのは、高度な専門技能ではなく、マニュアルに従って機械を操作・監視する定型的な作業へと変化した。これにより、企業は熟練工（正社員）を大量に維持する必要がなくなり、マニュアル教育で短期間に戦力化できる労働力を、生産量の増減に応じて柔軟に調整したいというニーズが高まった。
このニーズに合致したのが、派遣という柔軟な雇用形態である。派遣労働者は、企業にとって必要な時期に必要な人数を補充でき、コスト変動費化を可能にした。結果、製造業における派遣労働者の利用が急増することとなった（2000年代以降、製造業への派遣が段階的に解禁されたこともこの流れを加速させた）。
労働者派遣の増加は、法改正という政策的要因に主導されたのではなく、「男女雇用機会均等法による事務職の担い手の変化」と「技術革新による職能工の非必要化」という、日本の労働市場における構造的な変化によって内側から引き起こされた現象である。派遣法の改正は、社会がすでに生み出したこれらの新しい労働需要を、後追いで法的に容認・制度化したものに過ぎないのである。
----
「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 として、じゃあ残るものは何？というのはオーム社の本を読みましょう。再販しないかなあ。
今後数年は変わらないでしょと書いたら今現在進行形で変わっとるわいと突っ込みが来そうなんで防衛的な意味で書いておくんですが、あなたは過去数年間同じ仕事してたんすか？
仕事のやり方とか内容とか、言語とかライブラリとか、毎年のように変わってたでしょ。
レビューの比率が多くなったとか、コード書かなくなったとか、そういうの、たぶん管理職になった人が嘆いてたのと同じっすよね？
少なくとも、ジュニアエンジニアが低品質なバイブコーディング結果を寄越すようになってレビューが大変とか嘆くのなら、まともなコーディング規約一つ作れていない組織の脆弱さを嘆くのが先では？
手癖でバイブコーディングしてヒットしたプロダクトに、あとから品質上げるように大工事するリファクタリングと言うよりリビルディングな仕事って、別に今もありますよね？
散々テストケースを書かなくて良いプロダクトなんて無いという講演だけ聞きに行って、自分とこでテストケースが自動で走るようになって無いなら、そこが問題でしょ。
そんな日々の中で最も厄介なのは、CxOたちだ。
──CIO、CTO、CDO、CISO、CPO……肩書きは違っても、やっていることはだいたい同じ。
PowerPointを開いて「DXを推進している」と言う人たち。
うちのCxOはこう言った。
翌日、僕がPull Requestの内容を説明したら、「Goってタクシーのサービスの？」と返された。
その瞬間、何かが切れた。
──ケーキではない。
CxOたちはコードを読めない。
それ自体は罪ではない。
だが、読もうとしないことは怠慢だ。
よく聞く反論がある。
確かにそうだ。
ただし前提が抜けている。
つまり、コードを読めという話ではなく、読めるだけの構造理解を持てという話である。
「技術的なことは詳しくないが、成果は出している」
それはたまたまだ。
「上が言ってるから」「今期の方針だから」「スピード優先で」。
Pull Requestは読まないのに、Excelの進捗バーだけが毎日更新される。
これもよく聞く言い訳だ。
しかし、リソースが限られているならなおさら、理解の精度が重要になる。
僕が書いたAPIは、リクエストごとに外部APIを叩いていた。
「キャッシュを挟もう」と提案したが、PMは「リリース優先」と言った。
CxOたちは言った。
「想定してなかったのか？」
──想定してた。
だが、理解できないのは説明の問題ではなく、聞く姿勢の問題だ。
Slackの“#incident”チャンネルだけが、いつも一番アクティブだ。
CxOたちは「コストを切れ」と言う。
切れるのはコストだけ。
削ったコストの穴埋めに、技術的負債の利息を支払うのは現場だ。
Goで書かれた美しい構造体も、やがてはコメントだけが動くレガシーになる。
CxOたちは「我々はデジタル変革を進めている」と言う。
だが変わっているのは、スローガンのフォントと会議資料の配色だけだ。
クラウド導入もAI活用も、認知が変わらなければ儀式でしかない。
──違う軸を持つのは構わない。
現場を理解しない経営視点は、地図を見ないドライバーと同じだ。
「コードなんて書かなくていい。これからはノーコードの時代だ。」
だが、それは“コードをなくす”技術ではなく、“コードの抽象度を上げる”技術だ。
だが、隠したコードが消えるわけではない。
ボタンの裏にも、ワークフローの下にも、API呼び出しやロジックは確実に存在する。
それを理解せずに使えば、「コードを書かずにバグを埋める」だけの仕組みになる。
「ノーコードでいい」と言うCxOは、
「物理を知らなくてもロケットは飛ぶ」と言っているのと同じだ。
理解しないまま導入するノーコードは、“ノーコード”ではなく“ノーガード”である。
人を楽にするどころか、誰も直せない仕組みを量産する。
DXとは、ツールを導入することではない。
それを理解しない限り、
理解しないことだ。
真っ先に切られるのは、
──コストだけ。
CxOたちは「未来を見ている」と言う。
未来とは、仕様書ではなく、Pull Requestの積み重ねだ。
