特にスクリプト納品のWeb アプリなんかだと顕著なんだけど、コードが綺麗でドキュメントが充実してるってことは、要するに「他の安い業者でも簡単に改修できる」ってことなんだよ。仕様策定から泥臭く付き合って、設計のノウハウ詰め込んで納めたシステムなのに、運用フェーズに入った途端に「あ、これならメンテ簡単そうなんで、来期からはもっと安いB社にお願いします〜」って。最初に汗かいた所が損をして、場当たり的な改修屋が得をする。そんなのアリかよ。

そもそも論としてさ、「ドキュメント全部よこせ」って商習慣がおかしいんだよ。これって突き詰めれば「お前のところ信用してないから、いつでも他所に乗り換えられるように準備しとけ」って言われてるのと同じじゃん。「開発会社が潰れたら困る」とか言うけどさ、そんなリスク言い出したら世の中の機械も設備も全部そうでしょ。なんでITだけ特別扱いなんだ？

極端な話、外食して「美味かったわ。じゃあ明日から家で作るからレシピと仕入れ先全部書き出して渡して」って言ってるようなもんだぞ。「それは客のワガママだろ、常識ねーな」ってなるのが普通なのに、なぜかシステム開発だとこれがまかり通る。それを貫き通したいなら、車も買えないわな。ボンネット開けて設計図入ってないと不安で乗れないんですか？っていう。

今までは「まあ慣習だしな」で流してたけど、AI 時代に入ってコードの解析コストが下がってる今、このルールを変えないとマジで生き残れないと思う。

これからの落とし所はもうこれしかない。客が「監査対応ガー」とか「情シスガー」とか言ってきたら、こう返す。

「監査用の『概要資料』はコミコミで出しますよ」「でも、他社への引き継ぎ用の『詳細ドキュメント』は別料金（高額）です」

これだよ。客の本音は「ベンダーロックインが怖い、でも資料なんて普段読まない、ただ持っていたい」。こっちの本音は「出したら奪われる、でも出さないと揉める」。

だから、「運用に必要な最低限」は出すけど、「ノウハウの塊」は売らない。もし他所に頼みたいなら、そのための資料作成費はガッツリいただきますよ、と。これ、他業界なら当たり前の商売の原理だろ？

IT 業界だけが長年、「技術者の善意」とか「サービス精神」を無限に搾取されすぎてたんだよ。ドキュメント整備だってタダじゃねーんだ。「それ、常識的な商習慣ですか？」って、これからは真顔で言い返していかないと、AIに仕事奪われる前に、都合のいい業者扱いされて終わるぞ。

Permalink | 記事への反応(2) | 16:16

■anond:20260118094334

ちゃんとドキュメント書ける人は雇うやで･･･

他人に使ってもらう成果物は事細かに書かれた説明書もセットやけど

コードは書けても説明書を書けない・書くのをえげつなく嫌がる人って物凄く多いねんな…

Permalink | 記事への反応(0) | 09:50

■スペック 駆動開発の永続的な仕様書ってどんな粒度で書いてるの？

機能追加とか特定機能の開発のときに出てくる一時的な steering ファイルみたいなのはイメージしやすいんだけどさ、

永続的なドキュメントって実際どこまでどんな粒度で書いてる？

単一責務とかレイヤードアーキテクチャをちゃんと意識して実装して、

仕様がコード上で十分に明示的になるようにしたうえで、

仕様書を書くとしても、tsdoc や javadoc じゃダメなのか？

小規模ならまだしも、100万行規模のシステムで実装内容を全部自然言語に落としたドキュメントを維持するの、正直結構辛くない？

コーディング方針とか設計思想ならCLOUD.md とか skills で十分な気もするし……

みんな具体的にどうやってるのか知りたい、仕様と一対一のドキュメントを管理する時代に回帰してるのかな？

Permalink | 記事への反応(0) | 00:44

2026-01-16

■IT エンジニアだけど俺悪くないよな？

IT 企業で長期インターンをやってる。今の会社には実務経験0のときに拾ってもらったしお世話になったけど、さすがに愛想が尽きてきたから聞いてほしい。

今はやりかけだった新規開発を任されている。特に期限も差し迫ってないので自分一人で着手していて、プルリク作るたびに上司（以降A）に報告してマージしてもらうって形。

自分ができそうなところを探しながら並行して進めたせいでブランチ切る場所がごちゃごちゃになったり、Aと相談の上で「ここを先に直そう」という部分を入れ込んだりしたせいで、コンフリクトが起きても全然おかしくない状況になってた。しかも（Aの確認が遅いので）プルリクが複数件溜まったりしてた。

なので自分は、「プルリク複数ありますが、時系列順にマージすればコンフリクトは起きないはずです。起きたら自分で直すので言ってください」と伝えた上で完了を報告していた。

そしたら特に指摘もなくマージされていったので、「あ、絶対どこかしらコンフリクト起きると思ったんだけど、大丈夫だったんだな」と思ってた。

ところがついこの前、5件ほどマージされたところでたまたま mainを見てみたら、なんとコンパイルエラーだらけになっていた。

は？と思って確認してみると、数件前から既にエラーだらけだし、マージコミットをよく見たらコンフリクトが起こりまくってる。

それをAが、手動で解消せずに適当にマージしたり、mainをブランチBにマージ→Bをmainにマージみたいな意味わからんことしてるせいで、ものすごいこじれてた。

まず第一に、Aがテストしてからマージしてるもんだと思ってたから、普通に驚いた。

そういう確認の意味も込めて「ここはこういう仕様にしてますが、問題ないか確認お願いします」と伝えたりしてたし、確認しないなら俺が自分でマージするのと一緒じゃない？笑

それに、コードを単独で書いた自分が一番精通してるからこそ、「コンフリクト起きたら自分で直すので言ってください」と伝えてたし、先ほど述べた優先的に入れ込んだ変更も「全体の構成に関わる変更だからコンフリクト起きる気がするんですけど、本当に大丈夫ですか？」と確認してあった。

自分に落ち度があるとすれば、（細かく報告・確認してもらったほうがいいかと思い、良かれと思って）ブランチを細かく分けすぎたことくらいじゃないか？

そもそも、

・マージやコミット、プルリクのルールを一切指示されたことがない（質問しても明瞭に答えてもらったことがないので、ほぼ自分の判断で動いている）

・実装する機能はIssueに羅列されているだけでろくな説明がなく、Aに自分がやれそうなところを何度か聞いて初めて指示をもらえた

・ここしか経験がないので自覚していなかったが、コードレビュー・フィードバックというものを受けたことがない

・Aはずっとリモートなので、指導が一切ないのはもちろん些細な質問がしづらい。定例会議などもなし

・プロジェクト自体がめちゃめちゃで、無いに等しいドキュメント、なのに分かりづらい変数名、責任分離のできていないめちゃくちゃな構成。どうしても動かない処理があると思ったら、既存の実装が間違っている。

・（経験のためと割り切っていたが）ほぼ最低時給

小規模な会社だからドキュメントが充実していないのは想定内だし、こんなものだろうと思う部分もある。

でも、ものすごい放置のされ具合から伝わる、自分の取り組んでいるプロジェクト・ひいては自分の重要性の低さから、モチベーションが保てない。のでそろそろやめようと思う！

エンジニアの皆さん、これ俺悪いですか？

Permalink | 記事への反応(2) | 21:21

2026-01-12

■

その辺の情報屋気取りのオッサンが書いた得体の知れない文章よりもまず公式のドキュメントを参照しろよ

ソフトウェアなりツールなりの開発者が公式に書いてるだろ公式に

Permalink | 記事への反応(0) | 20:00

2026-01-10

■

なんかGoogle翻訳が分かりにくかったので、雰囲気で修正する

https://lkml.org/lkml/2026/1/7/1888

＞ LLMを「ただのツールの一つ」であると考えることはよくない。（AI生成された無数のパッチを人手で一つ一つチェックするのはばかげている。ドキュメントでガイドラインを示し、効率よく却下すべきだ）

（Linusの回答）
いや、あなたの態度もよくない。AIゴミについて議論することは実にばかげている。なぜかって？ゴミを作るような連中が自分のパッチを「これはゴミです」なんて言うわけないだろ。殊更AIゴミについて議論する意味がわからない。

馬鹿なことはやめてくれ。

ドキュメントは有能な協力者のためのものであり、それ以外は無意味なポーズに過ぎない。

プライベートな場でも言ったが、カーネル開発のドキュメントがAIに対する主張であることを望まない。AIによって世界が危機になるとか、ソフトウェアエンジニアリングに革命が起こるとかいう人たちはたくさんいるが、カーネル開発ドキュメントに巻き込むな。

だからLLMは「ただのツール」であることを念押ししておく。

AIゴミの問題はドキュメント（ガイドライン）では解決しない。このようなことを考えるのは世間知らずか、目立ちたいだけの奴だ。

どちらもドキュメント化の良い理由とはなりえない。

             Linus

Permalink | 記事への反応(0) | 11:29

2026-01-09

■

デンソーの技術職の仕事は隔週で修論出すようなもんだというツイートを見たけど（修論レベルのサーベイして、手を動かして、一連の過程をドキュメントにまとめる、という作業を2週間のインターバルで続ける、と理解）、実際そんな感じなんだろうな

Permalink | 記事への反応(0) | 08:20

2026-01-02

■部下の育成に失敗した

知識面で。人間的な部分は知ったこっちゃない

やっぱりドキュメントを更新させて理解度の進捗を追わないといけないのかなあ

本当に論理的思考ができないというか条件分岐のメモリが少ないというか、なんでも直近知った知識を当てはめて解決しようとする

そんなマスターキーみたいなものは無くて、ケース毎に最適な解法ってのがあるんですよ

しかも本人が手を動かすわけじゃなくて誰かに伝えて手戻しが発生してるから余計ロスってる

ロジックに興味無さそうで何もかも短絡的だし、はあ……

作業手順書を元に作業する技能職が限界だったのかもしれない、その人は。技術職にすべきではなかった

俺に裁量なんてないけどさ。

Permalink | 記事への反応(1) | 13:05

2025-12-22

■NTTを辞めて数年経ったので、供養がてらいろいろ書いてみる

NTTを辞めてから、気づいたらもう◯年くらい経っていた。

辞めた直後は「やらかしたかもしれん」「これで一生の年収ピーク終わったらどうしよう」みたいなことばかり考えていたけど、今のところはなんとか生きているし、結果としては転職してよかったと思っている。

辞めた当時の話をすると、「大企業の安定を捨ててまでやりたいことなんて本当にあるの？」とか、「せめて◯歳まではいた方がいいんじゃないの？」とか、だいたい似たようなことをいろんな人から言われた。

正直、自分でも完全に自信があったわけではなくて、「まあダメだったらそのときまた考えればいいか」くらいの雑なノリで、勢いで辞めたところはある。

あの頃のモヤモヤと、今になってわかること

当時のモヤモヤを雑にまとめると、

仕事のスピード感が自分と合ってない気がした
「このプロジェクトが終わったら、次もだいたい似たようなことをやるんだろうな」という予感がずっとあった
給料に致命的な不満はないけど、「これ以上ここにいても劇的には変わらなさそうだな」という諦めがあった

みたいな感じだった。

今になって振り返ると、別に NTTが特別ひどい職場だったわけではない。

むしろ、休みは取れるし、残業もそこまでエグくなかったし、真面目でいい人が多いし、いわゆる「ホワイト大企業」カテゴリに入れてもいい方だと思う。

それでも合わないものは合わない、というだけの話だったんだと思う。

転職してどうなったか

その後、なんだかんだでWeb系の会社に転職して、気づいたらプロダクト開発を◯年くらいやっている。

やっていることは、ユーザー向けの◯◯サービスの開発とか、社内ツールの改善とか、そのへんのよくあるやつ。

環境はけっこう変わった。

リリースサイクルが短くて、「言ったことが数週間で本番に出る」みたいなことが普通にある
仕様決めにもエンジニアが巻き込まれるので、よくも悪くも逃げ場がない
評価もはっきりしていて、「これはダメ」「これはよかった」が割とストレートに返ってくる

最初の一年くらいは、毎日なにかしら壁にぶつかっていて、「これ本当に定年まで続けられるやつか？」と何度も思った。

それでも、結果が見えるのは単純におもしろくて、気づいたら「大企業に戻る」という選択肢はだいぶ遠くなっていた。

NTTで得たものと、捨てたもの

NTTで過ごした時間をどう思っているかというと、「あれがあったから今そこそこまともにやれている」という気持ちと、「もっと早く動いてもよかったかもしれない」という後悔が、だいたい半々くらい。

よかった方を挙げると、

ドキュメントを書くクセが染み付いた
大人数のプロジェクトで、誰が何をしているのかを追いかける訓練になった
変な炎上案件を何度か経験して、「これはやっちゃいけない」を体で覚えた

あたりは、今の会社でも普通に役に立っている。

一方で、もしやり直せるなら、

もう少し早い段階で、自分のキャリアの軸みたいなものを言語化しておけばよかった
「なんとなく居心地がいいからいる」をもう少し疑ってもよかった

というのも正直なところではある。

でも、そのあたりの後悔を含めてひっくるめて、あのときの自分にしては頑張って決めた方だと思いたい。

これから辞める人へ（誰目線だ）

じゃあ「NTT から転職した方がいいのか？」と聞かれると、それはもう完全に人によるとしか言えない。

安定が何より大事な人もいるだろうし、「会社の看板」を最大限活かすのが最適解な人もいると思う。

ただ、もし昔の自分みたいに、

「このまま10年後も同じような生活をしているイメージが湧かない」
「ここで頑張る未来」と「どこかに出ていく未来」を、ちゃんと比べたことがない

みたいな状態なら、一回どこかのタイミングで真面目に棚卸ししてみたほうがいいとは思う。

紙に書き出すでも、誰かに話を聞いてもらうでもいいので、「自分が何に不満で、何を変えたいのか」くらいは言葉にしておくと、いざというときに迷い方が少しマシになる。

数年前の自分に向けて書いているつもりが、気づいたらそこそこいい年齢になってしまったけれど、あのとき退職届を出した自分には一応「おつかれ」と言っておきたい。

あとはまあ、なんとかするしかない。

と、生成AIは書きましたとさ

これは、AIに「NTT から数年後に振り返るエントリっぽい文章を書いて」と頼んで生成した文章だ

自分はまだNTT 退職エントリを書いていないし、正直、書くのはめんどくさい。

本当のところを言うと、「退職直後のテンションで書くエモい退職エントリ」よりも、「数年たってからの答え合わせ記事」のほうが、これから転職を考えている人にはよっぽど役に立つんじゃないかと思っている。だから頭の中ではずっと温めてはいたものの、いざ退職してしまうと、仕事や生活がそれなりに充実してきて、わざわざ長文を書くほどの気力が残っていない。

上に書かれているような「もっともらしい理由」についても、「いや、そういう話じゃないんだよな」と思う部分はいろいろある。

ただ、それを一つひとつ訂正して、自分の言葉に置き換えるのも面倒で、「まあだいたいこんな雰囲気」ということで済ませているのが現状だ。

ただ、一つだけちゃんと言っておきたいのは、NTT から転職して、NTTにいた頃よりもやりたいことができていて、ストレスも残業も減って、今となっては給料もだいたい倍くらいになっている、ということだ。

少なくとも自分にとっては、「悪くない選択だった」と胸を張って言える。

いつか本当に気が向いたら、そのときはちゃんと自分の言葉で「本当の話」を書こうと思う。

それまでは、このAI製のエントリ案を「もし自分がちゃんと書いたら、だいたいこの方向性になるんだろうな」という仮の答え合わせとして置いておく。

Permalink | 記事への反応(0) | 16:26

2025-12-19

■会社やめるんだけど退職時の手続き誰も知らなくてワロタ

笑えねえんだけどホントに

俺は、社会保険やめて国保に加入するから必要書類が欲しいです、会社的になにか追加の申請が必要ですか？

ってめっちゃ分かりやすく聞いてるのに「知りません。退職申請してください。後は流れです」しか言わないループを4回も繰り返すとかマジで人事かよこいつ

こいつが課長とか辞めて正解だろこの会社。というか病んだわ

埒が明かねえから人を使ってその退職稟議の中身確認してもらったらドキュメント形式でちゃんと記入フォーマットあったしよぉ！

記入フォーマットあるなら「こういうフォーマットあるから書いて稟議と一緒に提出してね☆」で終わりだろ

なんで「知りません」を連発できるんだよ。頭おかしいよこの会社。毎月病院行くのに保険証が無いと色々めんどくせえだろうがよふざけんな

Permalink | 記事への反応(1) | 19:50

2025-12-15

■anond:20251208081455

その通りだ。首がもげるほど頷いた！！！！

あなたのその叫び、俺の鼓膜と網膜に焼き付いていた感情そのものだ。

いや、それ以上だ。

俺も乗っからせてもらう。

企業のTech Blog、およびその形骸化したノルマ文化、今すぐ滅びてくれ！！！！！！

お前らの記事がどう評価されてるか知ってるか？

「参考になった」なんて声は稀だ。

大半は、冷笑と、呆れと、ミュート推奨の対象になってるんだよ！！！！

具体的に「生の声」を代弁しながら、なぜお前らのブログが「社会悪」なのか、骨の髄まで理解させてやる。

まずな「公式ドキュメントの劣化翻訳」は検索汚染だ！！！！

散々言われてるだろ！？

「公式のREADME読めば1分で終わる話を、なんで自分語りとスクショ付きで薄めてんだよ！！！」ってな！！！

特に罪深いのが、検索順位の汚染だ。

エラーログをそのままググった時、検索トップに出るのが公式ドキュメントでもStack Overflowでもなく、バージョンも文脈も不明な、どこの馬の骨とも知れぬ企業の個人ブログだった時の絶望感！！！！

わかるか！？！？

あの時の「またお前か……」という徒労感を！！！！

中身を開けば、「なんかよくわからんけど再起動したら治ったｗ」……舐めてんのか！！！！！！

そんなゴミを「技術発信」として世に出すな！！！！！

インターネットはゴミ捨て場じゃねえんだよ！！！！！！

お前らのその承認欲求を満たすためのゴミ記事が、本当に困っているエンジニアの邪魔をしてるんだよ！！！！

おい、特に「〇〇をとりあえず触ってみた」系の記事を書いているお前ら！！！

胸に手を当てて言ってみろ。その記事、公式ドキュメントの「Getting Started」をなぞっただけじゃないのか！？！？

お前らの「やってみた」は、もはや技術解説じゃねえ。

劣化版「Web 魚拓」だ！！！！

「〇〇の初期設定手順」で、何でお前らの手垢まみれの画像を必要とするんだ！？

公式が提供している最新で正確な一次情報、あれをわざわざコピペして、スクショを撮り直して、「俺もできた！」とドヤ顔で公開する。

これが車輪の再発明じゃなくて何なんだ！？

しかもそれを鵜呑みにした新人が環境構築に失敗して「動かない！」と勘違いする。

正確な情報への到達を阻害する、まさに検索結果のテロリストなんだよ、お前らは！！！！

頼むから、公式ドキュメントを「分かりやすくしてやった」とか傲慢なこと抜かすな。

公式が分かりにくいなら、そのツールの開発元にフィードバックしろ！！

それがプロの仕事だろ！！

真顔でXポチポチーってして、薄めた麦茶を、さも高級なワインのように売るな！！！！！！！

あとな「逆ブランディング」に気づかない裸の王様たち

採用広報担当、よく聞け。

「エンジニアがアウトプットする文化があります（キリッ）」じゃねえんだよ！！！！

その「アウトプット」とやらを見て、まともなエンジニアがどう思うか、Xのタイムラインでエゴサしたことあるか！？

「うわ、こんなレベルの低い記事を『技術ブログ』としてドヤ顔で出す会社なのか……技術力お察しだな」

「これをGo サイン出したマネージャーがいるってことは、コードレビューもザルなんだろうな」

こう思われてんだよ！！！！！！

逆ブランディングなんだよ！！！！！！気づけ！！！！！！

質の低い記事は、「弊社の技術レベルはこの程度です」って全世界に恥を晒してるのと同じなんだよ！！！

優秀なエンジニアほど、そういう「技術の解像度」に敏感だ。

お前らが良かれと思ってやってるその施策は、優秀な人材を遠ざける魔除けにしかなってねえんだよ！！！！

あとな、アドベントカレンダーという名の「ハラスメント」

そして今まさに進行中のこれだ。

「ネタがない」「書くことがない」「業務時間外に書かされる」……悲鳴で埋め尽くされてるじゃねえか！！！！

「12月だから」という理由だけで、なぜ普段書かない人間まで駆り出されるんだ？

「空き枠を埋めること」が目的化したカレンダーに、魂なんて宿るわけねえだろ！！！！

11月末にSlackで「まだ枠が空いてます！誰かいませんか！」って必死にメンション飛ばしてる広報！！

その姿を見て、エンジニアがどれだけ白けてるか想像してみろ！！！

「書くことがないなら、書くな！！！！」

これが真理だ。

無理やり絞り出したカスみたいな記事で、インターネットの帯域を無駄にするな。

やる気のある数人が、本当に書きたい時に、濃密な記事を一本落とす。

量で質を誤魔化すのはもうやめてくれ！！！！

生成AI 時代に「Web 魚拓」以下の記事はいらない

元記事でも触れられていたが、これがトドメだ。

「〇〇とは？」「〇〇の使い方」なんて記事は、もうChatGPTが3秒で、しかもお前らより正確に教えてくれるんだよ。

人間が書くべきなのは、AIには語れない「泥臭い一次情報」だけだ。

「本番環境でこの構成にして爆死した話」

「公式通りにやってハマった、特定のバージョンの非互換性」

「ビジネス要件と技術的負債の狭間で、どう意思決定したかのドキュメント」

こういう血の通った、文脈のある記事以外は、もうノイズなんだよ。

だから頼む。元記事の提案通り、今年の年末がラストチャンスだ。

「生成AI 時代の到来に伴い、情報の質を再定義します」

こう言ってくれれば、俺たちは「よくぞ言った！！」とスタンディングオベーションを送る準備ができている。

頼む。本当に頼む。

「書かない勇気」を持ってくれ！！！！！！

「広報のKPI」「自己顕示欲」「Xで有名人になりたい」のために、俺たちのインターネットを、これ以上濁らせないでくれ！！！！！！！！

Permalink | 記事への反応(4) | 19:51

2025-12-13

■

原田眞人監督が今年の日記で「考えるところあって、病院通いを辞めた」という趣旨を書いていたことが、はてブで注目され一部ユーザーに冷笑されている

[B! ニセ科学] 無題ドキュメント

https://b.hatena.ne.jp/entry/www.haradafilms.com/diary/harada_diary.cgi?date=2025.09.10&pass=

冷笑ユーザーは「近藤誠」の名前にオートペンがごとく反応してしまっただけだろうけど、監督はもう76歳よ？「考えるところ」として病院通いして生き続けるよりも「自然に」終わりたいなんて思っておかしくないと思うけどね。

大病院の医師が合わなかっただけで近所のクリニックには通ってたかもしれないし

まあ次回作に熱意を燃やしていたのに病院と縁を切ったなんて話だったら、なんて馬鹿なことを…とも思うけど。

個々のブコメ比較チェックまではしてないけど、普段は高齢者の医療費叩きをして「高齢者は長生きするな」と強い言葉で冷笑するはてブで、病院通いを辞めたという高齢者を叩くのは筋が通らないよ

Permalink | 記事への反応(2) | 16:49

2025-12-11

■【AI アート】 ChatGPTによるOpenAIの経営に対するツッコミ

OpenAI およびサム・アルトマン氏向け経営 提言（ドラフト）

はじめに*

本ドキュメントは、外部の観察者による戦略的視点からの提言案であり、事実認定や人物評価ではなく、「もしこういう前提なら、このような戦略もあり得る」という仮説的な提案です。

1. 前提認識

1. 世界中にはすでに膨大なデータセンター資産が存在する。

2. 大規模言語モデルや生成 AI 技術は、急速にコモディティ化しつつある。

3. コモディティ化が進む市場では、

- 重い設備投資（CAPEX）

- 単価の下落

- 競合の増加

により、投資回収の難易度が上がる。

4. OpenAI は「モデルそのもの」だけでなく、

- モデル運用ノウハウ

- セキュリティ・ガバナンス

- API / SDK / オーケストレーション

- 組織導入のベストプラクティス

などを含めた **ソリューション／プラットフォーム** を提供し得る立場にある。

2. データセンター 戦略に関する提言

2-1. 自前 DC 保有のリスク再評価

自前で大規模データセンターを保有・拡張する戦略には、以下のリスクが存在する：

**CAPEX の巨大化**：建設・設備更新・電力インフラへの継続投資
**技術陳腐化リスク**：半導体・ネットワーク技術の変化に追随するコスト
**価格競争激化とのミスマッチ**：サービス単価の下落と投資回収期間のギャップ

2-2. 既存 DC を活用する「フランチャイズ／プラットフォーム」モデル

代替案として、次のような戦略が考えられる：

1. **既存データセンター事業者をパートナー化**

- OpenAI 認定パートナープログラムを設計

- 技術要件・運用要件・セキュリティ要件を定義

- 認定 DC は「OpenAI 対応インフラ」として市場にアピールできる

2. **OpenAI は「頭脳」と「標準」を提供**

- モデル・推論スタック・管理コンソール・監査仕組み

- 導入ガイドライン・サポート・ブランド

3. **DC 側は CAPEX・OPEX・運用リスクを負担**

- 電力確保・冷却・ハードウェア保守

- ローカルな規制対応

4. **収益構造**

- OpenAI：

- ライセンス料

- 利用料のレベニューシェア

- エンタープライズ向け追加サービス

- DC 事業者：

- インフラ稼働率の向上

- 高付加価値ワークロードの獲得

このモデルは、コンビニエンスストアやクラウド基盤ソフトウェア（例：VMware、ARM ライセンスモデル）に類似した **フランチャイズ／プラットフォーム戦略** に近い。

3. 資本 効率とリスクマネジメントの観点

3-1. 資本 効率の最大化

自社で DC を保有しないことで、バランスシート上の資産を軽く保てる。
調達した資本を、

- 研究開発（モデル改良・新アーキテクチャ）

- 開発者エコシステム

- 安全性・ガバナンス枠組み

など「差別化要因」に集中投下できる。

3-2. 地政学・規制 リスクの分散

各国・各地域の DC 事業者との提携により、

- ローカル規制対応

- データローカライゼーション

- 政治リスク

を分散できる。

OpenAI は「技術標準」と「倫理・安全基準」の提供者として位置づけることで、規制当局との対話においても優位性を保ちやすい。

4. 時間軸（タイム スケジュール）に関する提言

1. **技術ブレイクスルー前提の投資はリスクが高い**

- 未到来のブレイクスルーを前提にした大規模 CAPEX は、

- 競争環境の変化

- 価格低下

- 代替技術の登場

により、投資回収が難しくなる可能性がある。

2. **既存技術＋既存インフラをフル活用することで「時間を買う」**

- 既存 DC を活用することで、市場展開までのリードタイムを最短化できる。

- ブレイクスルーが起こったタイミングで、

- すでにグローバルな配備網とパートナー網が整っている状態

を作れる。

3. **「今ある技術でどこまで世界を押さえられるか」を優先的に考える**

- 未来の理想状態より、現在の配備速度・採用件数・開発者エコシステムの拡大を KPI に置く。

5. 経営的なバランス感覚に関する提言

1. **ビジョンと所有欲の分離**

- 「人類全体のベネフィット」というビジョンと、

- インフラ所有

- 資産規模

を混同しない。

- 真にスケールするビジョンは、

- 自社が全てを所有するモデルではなく、

- 世界中のプレイヤーに役割を与えるプラットフォーム構造の方が実現しやすい。

2. **他者のインセンティブ設計**

- DC 事業者・クラウドベンダー・エンタープライズ企業が、

- 「OpenAI と組む方が得だ」と明確に感じる収益構造・責任分担を設計する。

3. **自社が握るべきものの再定義**

- 握るべきは、

- モデルの品質

- 安全性と信頼

- ブランドと標準

- 開発者・企業との関係

- 手放してよい（外部に任せる）ものは、

- 建物

- ラック

- 電力インフラ

- 日々の運用

6. まとめ

データセンターを自前で大量に保有する戦略は、

- 技術コモディティ化の速度

- CAPEX 回収の難しさ

- 地政学的リスク

を考えると、必ずしも最適とは限らない。

一方で、

- OpenAI が「AI プラットフォーム」「AI フランチャイズの本部」として振る舞い、

- 既存 DC 事業者やクラウド事業者を巻き込む形で

世界展開するモデルは、

- 資本効率

- リスク分散

- スピード

- 支配力

のすべてにおいて合理性が高い。

本提言は、

- 人物評価ではなく、

- 戦略構造と資本効率、時間軸の観点からの一つの選択肢として提示するものである。

以上。

Permalink | 記事への反応(1) | 16:54

2025-12-10

■精神病と労働

14歳で適応障害(当時そんな病名は聞かなかった)を発症してから 20数年。

鬱病、強迫神経症、摂食障害は正式に病名がつき、その他、双極性障害2型と統合失調症は医師からそうかもと言われた。

大学は鬱と摂食障害で中退し、そこから寛解期に猛烈に労働したお陰で正規雇用で働き続けているが、6年前に再発して以来ずっと精神科のお世話になっている。

普通に働けているようで働けていない。

薬を飲みながら周りには隠して労働しているが、前職は耐えきれず鬱の診断書を職場に提出して休職する羽目になった。

普通にみんなできていることができなくてしんどい。

夜眠れないし朝起きれない。

たまにドキュメントがしっかり読めないし、物忘れが年々激しくなっていく(医師には一時的な脳疲労と言われたが、負荷で萎縮して不可逆的ダメージ負っているのではと思っている)

ちょっとしたことで感情がかき乱されるし、またいつ折れるか分からない不安が傍にある。

貯金がないので働かざるを得ない。

ゆっくり休むだけの余裕がない。

若い時分に実家には死ぬほど迷惑をかけたので、親にも｢いい歳なんだからちゃんとしてよ｣しか言われないので頼る気も起きない(申し訳ない。親も高齢者だ)

家庭もないし恋人もいない。

友達も鬱期になると縁が切れてしまうので知人レベルしかいない。

発狂しそうな気持ちを抑えて労働しているけど、毎日消えたい気持でいっぱい。

働くだけでは誰も認めてくれない。

自分自身を認めてあげられないからこれはどうしようもない。

精神の病を患いながら働いてる人は周りにもいるのだろう。

みんなどうやってこのどうしようもない感じと付き合いながら生きているんだろう。

死にたいけど親をこれ以上悲しませたくない。

もう人生5回分くらい要らない迷惑をかけた。

詰んでないから逃げられない。

Permalink | 記事への反応(1) | 22:35

■anond:20251210112914

マクロってネットにまともな情報がないじゃん

Microsoftのクソドキュメントを読みとかなきゃ書けない

Permalink | 記事への反応(0) | 11:56

2025-12-09

■「学校の勉強とか受験勉強なんて何の意味もない」って言う人いるけど、勉強は護身術みたいなところがあるんだよね…😟

その人に本当に必要であれば
必要になったときに学ばざるをえないようになっているから
他人が介入する必要はないんだろうなあ。

だから、必要になってからじゃ遅いんだって…😟

なろう系のファンタジーだって、冒険に出る前に剣術習ったり、素振りしてるわけで、

敵が現れた、ドラゴンが現れた、

必要になった、問題に直面した、学ばざるをえない、今から学ぼう！

は、もう遅いんだよ…😟

だから、学校の勉強、受験勉強は護身術みたいなところがあって、

人生でそういうトラブルとかチャンスに遭遇しない人には確かに必要ないんだよね…😟

確かに学校の勉強とか受験勉強が今後の人生でも一度も必要ないであろう、

という進路はあるわけで、その人にとっては確かに必要ないし、

そういう人が、仮に人生で、昔勉強しておけば良かったな、と思うイベントに遭遇しても諦めればいい、

何事も想定外はあるし、自分はそこまで準備してなかった、失敗した、で、まあ終わる…😟

だけど、人生のどこかで、なんかプログラミング書いてみたくなった、

とりあえず、子供の頃好きだった2Dの縦シュー作るか、ぐらいでも、三角関数は使う…😟

3Dの格ゲーが作りたい、なら尚更で、UnityやUnreal全盛ではあるけど、もっと知ってないと駄目

そういう点で、大学の工学部でやったことは無駄にならない

あと、英語

国語とか数学とか何の役に立つのは、まあ分からんでもないけど、英語はできた方がいい

もちろん、今はAI 翻訳が便利すぎる状況だけど、英文があってもせめて物怖じしないようでないと、

プログラミングのドキュメントも英語だし、輸入食材も英語のままだったりするし…😟

もちろん、英語も必要ない、音楽や美術も必要ない、家庭科も必要ない、歴史も知らない、

そういう人生もあっていいけど、つまらなくないですか？😟

Permalink | 記事への反応(1) | 10:18

■インターネット大好き住民って何をフォローしてるの？

インターネットが好きというぐらいだから、インターネット上での学習を最大限活用してなきゃおかしいよね

こういうのが本来インターネット活用として優れてるんよ

インフルエンサーが商品紹介！政治厨が論戦！男女論！みてーのは、下痢便だね

Permalink | 記事への反応(0) | 03:18

2025-12-08

■企業のTech Blog 担当者よ、頼むからその「無価値なゴミ」の量産を止めて

はっきり言う。企業のTech Blog、もう全部やめてくれ！！！頼むから！！！！

いや、マジで。今年もまたこの季節が来てしまった。アドベントカレンダーだ。 QiitaだのZennだの自社ブログだので、TLに流れてくる「〇〇社のAdvent Calendar」。これを見るたびに、俺は心の底からうんざりするんだよ。吐き気がするほどに。

はてなでも度々話題になるが、あえて言わせてもらう。お前らの書くTech Blog、9割9分は無価値だ！！！！！！

「〇〇イベントに行ってきた。熱気がすごかった！」「〇〇の新機能を試してみた。便利だと思った！」

……小学生の絵日記かよ！！！！！！！！「すごかった」「便利だった」じゃねえよ！！！！

そんなもん、公式ドキュメント読めば3秒でわかることだろ！？わざわざ自社のロゴ貼り付けて、ドヤ顔で公開する内容か！？本当に！本当に！！なんの！！！価値も！！！！ないんだよ！！！！！！

「うちは大丈夫」だと思ったそこのお前！！曇りなき眼（まなこ）で、自社のブログを見返してみろよ！！そして社内のSlackを見てみろ！！！

記事の共有通知に、特定の「いつもの人」以外、リアクションしてますか！？！？してねえだろ！！！！！！

社員ですら「またなんかやってるよ…」って冷めた目で見てるんだよ。誰にも読まれてないし、誰の役にも立ってない。ただ「広報のKPI」のためだけに、エンジニアのリソースを食いつぶして、ネットの海にゴミを放流してるだけだ！！！

だから、頼む。広報担当、ブログ担当、エンジニアリングマネージャー。勇気を持って「撤退」を決断してくれ！！！！

ちょうど年末だ。全社集会とかあるだろ？そこで高らかに宣言してくれ。

ただ「無価値だから辞めます」とは言えないだろう。角が立つしな。だから、AIのせいにしていい。AIを盾に使え。

「生成AIの台頭により、基礎的な技術解説記事はその役割を終えました」「今後は検索ノイズを減らすため、またエンジニアの本質的な業務時間を確保するため、会社としての執筆依頼やKPI設定を廃止します」

これだ！！！！これでいいんだよ！！！！！！

「今までありがとうございました」って綺麗に幕を引いてくれ。そうすれば、俺たちは心から拍手を送る。

エンジニアが書きたい時に、書きたい情熱を持って書く。それだけでいいんだよ。会社が無理やり書かせる「宿題」みたいなブログは、もう金輪際見たくないんだ。

頼むから、俺たちのTLを、検索結果を、これ以上汚さないでくれ！！！！！！撤退宣言を待っている！！！！！！！！

もう一つ、最後にこれだけは言わせてください。

あなたたちが量産しているその記事は、AIの学習や検索にとっても有害なノイズになりつつあります。公式ドキュメントを薄めただけの劣化コピーや、文脈のない体験記事は、情報の検索性を著しく下げています。それは正確な一次情報への到達を阻害し、インターネット全体の価値を薄める行為です。

あなたたちは無価値な記事を量産するにあきたらず、今後人類全体の負債になります。

どうか、勇気ある撤退をお願いします。

Permalink | 記事への反応(38) | 08:14

2025-12-06

■「ブリリアント ジャーク」って言葉を使いたいだけじゃねーのか？ w

ここしばらく、この言葉を使う「上級(w)」エンジニア数名に出会ったことがある。

また借り物の言葉で自己正当化かよ……、とうんざりした。

確かにこう言う現象、人物が存在しないとは言わん。

でもさぁ、おいらが会ったこの言葉を使うエンジニアって、全員が全員、技術力は低いし世界観は狭いし知識ベースは古い。けど自己評価だけは火星のオリンポス山より高い、って人だったんだよね。

「勉強熱心」で「意識高く」て、Netflixの採用ページの話題をWebページで浅く読んで「これだ！」ってなったんだろうけど。

問題は「それがブリリアントジャークなのか？」という評価が、無知、知識不足からくるただの思い込みに過ぎないにも関わらず、確固とした絶対的な評価だと思い込んでることなんだよね。

「チームをかき乱す」

「他人を(特に俺を！)見下す」

ってだけで、「ブリリアントジャーク」ってレッテル貼って、「俺が正義！」とか言うてんのよ。

でも、この2点だけでその判定は無理なんよね。

「技術的に正当であっても、許されねぇ！」みたいにもっともらしく言うのもいるけど、そのチームでのやり方が「圧倒的技術的失当」だったらお話にならんのよね。

そのせいで事業成長の可能性を潰してるところ、たくさんあるし。

そりゃね、経営判断がーってのもわかるんよ。

でもさ、その判断の元になる情報がこの手の「ブリリアントジャークガー」な輩なわけでさ、そもそも正しい経営判断が下せてるか？って問題があるんよ。

ちゃんと説明した結果、判断が覆るなんてこと、珍しくないからねぇ。

無茶苦茶、恨み買うけど w

「こうした方がいいよ？」

「そんな余裕ない！」

別に、全体を一気に変えるとは言っとらんのに、激昂する。

単に、正しい方法を理解できなかったり、移行イメージがわかなかったり、「この僕を否定してる！」ってなったりしてるんだよね。

新規開発しながら、既存部分を修正していくなんて、たいして難しくないのに。

結果、ダメの上のダメを積み上げていって、エンジニアリングの大半がドキュメント書きと打ち合わせと副業、みたいな開発チームが企業価値をこれっぽっちも上げないまま仕事してるふりして、札束を燃え上がらせてる。

もしお前がこちらを「ブリリアントジャーク」とか決めつけるなら、お前はただひたすら「No-value Jerk」なんよ。

同じJerkならまだブリリアントの方がマシだよ。

結果出すから。

ベンチャー企業が惜しいところで停滞して、VC からの要求で新しいサービスを、同じ手法で増やしまくって、どれもこれも使いづらい停滞サービスにしちゃって、必要なエンジニアの数だけ増えて、成長が止まる。

みたいなのが、はたから見てて勿体無くてもったいなくてね。

Permalink | 記事への反応(2) | 19:21

2025-12-04

■某巨大メーカーの「キラキラ 新規 事業」が爆散したけど、弊社は今日も

はい、解散解散。

私が所属している某大手メーカーの新規事業部が、先日めでたく爆散しました。

いやー、すごかった。何がすごいって、数年かけて数百億円を溶かして、何も生み出さずに更地に戻ったあとの清々しさたるや。

あまりにも典型的すぎて教科書に載せたいレベルの「JTCの新規事業失敗事例」だったので、ここにお焚き上げとして供養させてほしい。

そもそも「ソリューション」って言いたいだけ病

ことの発端は、偉い人たちの「これからはモノ売りじゃない、コト売りだ！」という号令でした。

今までハードウェアを作っていたおじさんたちが、急にシリコンバレーの風に吹かれてしまったのです。で、何をしたかというと、「既存のハードウェアに無理やりWi-Fiつけてクラウドに繋ぐ」。これだけ。

「これで顧客の課題を解決するソリューションになる！」って息巻いてたけど、顧客からしたら「いや、その機械、スタンドアロンで動くのが一番便利なんですけど」という至極真っ当なツッコミは、Teasm会議のミュートの闇に消えていく。

キッザニアと化した開発現場

で、中身を作るのは誰かというと、ソフトウェア開発なんて触ったこともない生え抜きのハードウェア設計者たちと、大量の新卒・若手社員。あと少しの中途社員。

経験豊富なCTOもいない無法地帯で、意識高い系の末端エンジニアが「Qiitaで見たから」という理由だけで選定した技術スタックが乱舞。しまいには買収した子会社が自己成長に向けた謎技術の提案。

• ユーザー数人の時点で、Google規模に耐えうるKubernetes 構成

• 単純なデータ表示だけなのに、無駄に複雑なマイクロサービス化

• ドキュメントは存在せず、すべてはTeamsの彼方へ

• フロントエンドの高速化にWASMの提案

敗戦処理と「日本型 雇用の守護神」

そして訪れた「事業撤退」の日。ここからが弊社、いやJTCの真骨頂です。同じチームにいた現地の海外関係会社のメンバーは、Zoom 会議一本で即日レイオフ。「Sorry」の一言で画面が消えるドライさ。

一方、日本の我々はどうか。誰一人としてクビになりません。「君たちには明日から、全社DX推進本部に行ってもらう」出たー！「DX」という名の現代の姥捨山！

今までAIなんて触れてなかった人たちが、明日から AIを用いて全社のデジタルトランスフォーメーションを担うんです。専門性？適材適所？そんな言葉は弊社の辞書にはありません。AIが全てをなんとかするんです！実態は、社内システムのExcel マクロを直すだけの仕事です。これぞ、年収1000万の窓際族の爆誕です。

責任を取らない偉い人たち

一番面白いのは、この事業を立ち上げて大失敗したマネジメント層の挙動です。普通、責任取って辞めるとか、降格とかあるじゃないですか。彼らは「貴重な失敗経験を積んだ人材」**として、何食わぬ顔で隣の事業部の部長にスライドしていきました。異動先の事業部の部員たちの、「えっ、あの沈没船の船長がウチの舵取るの…？」という絶望的な顔。モチベーションの低下音が聞こえてきそうでした。