  |
はてなキーワード: メンテとは
幾つも見てきてる。
ってキョトンとした表情で言われることがよくあるんだけど、「札束燃えてるやん」。自覚はないんか？
ビジネスの伸びに比べて、クラウド課金、エンジニア人件費の伸びが抑えられてなんぼなのに、ビジネスが伸びれば伸びるほど、課金も人件費も鰻登りじゃ意味ないんだよ。
「でも、規模が大きくなったら、その分固定費も増えるでしょ」
って、Webサービスとか「システム」をビジネスにしてるなら、規模が大きくなっても「比例して」あるいはそれ以上に固定費が増えるのはおかしい。
どうしてエラーがこんなに発生しているのか？
どうして手動メンテがこんなにたくさん発生しているのか？
「技術力がなくて設計から失敗」しているし、改善するだけの技術力もない。
から。
男は黙ってSnowflake？
男は黙ってTiDB？
K8s？
「俺、これ知ってるぜ」は技術力じゃない。
ビジネスの規模がデカくなったら、インスタンスをただひたすらデカく、増やすしかない設計しかできないのは、カスだ。
混乱に拍車をかけるだけだ。
何をしているか自覚できるだけの技術力があれば、「AIガー」という前に、かなりの部分、解決できる。
『「Mozilla/Firefoxの日本語コミュニティ解散」とかいうDramaについて知っておくべき2,3のこと』とかいうのが回ってきた。あまりにもひどい内容なので、あえてリンクにはしない。もし私がこういうタイトルで書くなら、という if を書いてみる。
など。今回解散したのは SUMO のコミュニティで、それ以外への直接の影響はない。また、SUMO もコミュニティの活動はないものの、今回の騒動以降も複数の個人が貢献している。なお、SUMO のアクティブな貢献者は 3 人よりも多い。例の記事では、gecko-l10n と SUMO の貢献者を足しても 2 人 (後から 3 人に訂正) としていたが、これは明らかな誤認。
(これを書いている私は幻の 3 人目、もしくは存在を消されたその他の貢献者かも)
他に影響がないなら安心、とはいかない。なぜなら、Mozilla はアクティブなコミュニティが解散する理由を作ったことになり、他のところでもこういう方針転換は起こる可能性を否定できなくなってしまうから。
まあ、Firefox、Thunderbird のリリース版は翻訳完了率がほぼ 100% で Bot が暴れる余地はなさそう、MDN では過去に検討されたが導入しないこととなった... など安心できる事情もある。
貢献者不足だけが原因ではないと思う。例えば、原文に新しい内容が追加された場合、それが句読点の修正でも最新の仕様に合わせるためのアップデートでも、翻訳者には「更新が必要」としか表示されない。作業が必要な順にトリアージできないので、修正は間に合わない。
Mozilla は Bot の導入後に翻訳者に望む作業として、修正だけでなく UI 部分の翻訳を挙げている。Bot が記事を翻訳すると、Firefox などのボタンに書いてある内容を翻訳せず、英語のまま残す。Mozilla のコミュニティ担当者すら最初バグだと思ったらしいけど。どうやら、人類には刺身にタンポポ()のせる仕事は残るようだ。いや、独自の翻訳モデル作る前に、翻訳ファイルからもってくる Bot を作ってよ。
Mozilla がもっと適切な支援をくれていたら、メンテできる記事はもっと多いと思う。
一部の貢献者の活動の恩恵の割合がかなり大きいことは否定できない。しかし、どこも複数人が活動していて、誰かが自分の撤退によって Mozilla やユーザーを脅迫することはできない。本当に困った事態になれば、ライフステージの変化などで今は活動していない、古の貢献者たちが復帰することもあり得る。
コロナ以降、新規の貢献者獲得のためのアピール活動は低調になっていたと思う。しかし、MDN のメンバーがブース出展などを数年前から再開し、最近は gecko-l10n の人も一緒に出しているっぼいのでこのタイミングは残念。
なお、今回の件は事前の提案に反対意見がなかったからフォーラムへと書き込まれていて、暴走ではない。私はあの時点で今後も貢献を続けると決めていたけど、解散には反対ではない。Bot の合間を縫って貢献しつつ新しい翻訳者を育て、次の世代にコミュニティを引き継ぐなんて不可能なので、合理的な判断だと思う。
CC がある限り相手が自分の著作物を使用することを強制的 (法的) にやめさせることはできないけど、使用しないように要請することはライセンス上否定されないはず。もちろん、要請に応じる義務はない。私は、例の主張は要請に留まるものだと思っている。そのような要請も CC の理念に照らして好ましくはないし、SUMO を使用する第三者に対してならば私は絶対に許容できないけど Mozilla に対してする分にはまあ。というか、そんなことは知っているはずの人だし、コミュニティとしてでなく個人の行動なので特に言うことがない。
あまりいい形で注目を集めている訳ではないけど、Mozilla やオープンソースの翻訳コミュニティに光が当たっているので参加する人が増えたらいいな。Mozilla 関係だと毎月 MDN のコミュニティが新規参加の人向けの会をやってるし、他のところでもいいので。メーリスとか Slack とかに入るだけでも何卒。
リアクションを見ていると、元リーダーとか、Mozilla 側の担当者とかを中傷するような投稿がちらほら。ほとんどは英語だけど、一部に日本語のものもあって大変悲しい。たとえ日本の貢献者を支持している内容でも Mozilla のスタッフ個人の悪口を書いているものは見るに堪えないし、コミュニティ側の問題を指摘している意見にはうなずくものもある。だから、何も書くなとは思わないけどさあ...
ここに書いてあることは全部フィクションかもね。しらんけど。
MacOS と iPhone・iPad のユーザーにはその他より迷惑がかかるかも。ごめん。Bot がガイドラインに従っていないという問題の影響で、SUMO と Firefox などで表現が異なるものが若干存在する。日本語では Bot は一時停止しているっぽく (土日は Bot も休むとかでなければ)、かなり近い将来に翻訳も含めて一時撤回する可能性はあると思う。また、活動を継続している貢献者は意外と多いので、誰かが修正するかも。それまでは困ったら原文を見てほしい。
各国の貢献者が活発に意見を述べている。こういう問題が海外や別のプロジェクトのコミュニティでは起こらないようにするために、徹底的に議論する必要があるはず。今回の自動承認は論外だけど、下書きとして活用する分には十分役に立つぐらいの精度ではあると思っているので、今度はコミュニティとしっかり話し合って役立つ形に改良してほしい。
今回の件で、Firefox や Thunderbird の使用をやめるという声も聞いている。過去にも非英語圏のユーザーやコミュニティを蔑ろにするような決定は存在したけど、まだ相対的、総合的にはましだと思っている。私は使用も貢献も少なくともあと 10 年は続けるつもり。SUMO の問題が解決することだけではなく、Mozilla 自体の姿勢に何か変化があればいいと思う。
お前、何を勘違いしてるんだ？
OSSにフリーライドなんて概念を持ち込む時点で、思想の土台が自己放尿してるんだよ。
そこから学び、改良し、再配布し、再進化する。つまり乗ること自体が前提条件なんだよ。
お前がフリーライドと言っているのは、車輪の発明を見て「タイヤ使ってるやつ多すぎ」って文句垂れて自己放尿してるのと同じ。
OSSを使うこと自体がOSSへの貢献の一部だ。利用が増えればバグも改善され、検証も進み、メンテの意義も上がる。生態系が回ってるんだ。
それをフリーライドとか言って悦に浸ってる時点で、論理的に二重に放尿してる。まさに認識と現実のダブル放尿だよ。
OSSにフリーライドしたくなければ、お前はまず電気もインターネットも使うな。
TCP/IPもGNUもPOSIXも全部OSSの遺産だ。お前の吐いたそのフリーライドって言葉自体、OSSで動くプラットフォームの上で出力されてる。
電車→線路の上を大量に人を乗せた箱を走らせる？線路壊れたらどうすんの？スピード出し過ぎたら？電源どうすんの？アホかできるわけないやろ
電線→全世帯って全世帯？数ｍおきに柱立てて線引いて？雪降ったら線切れるんじゃないの？鳥は？そもそもそんな電圧どうすんの？火事とか起きそう。現実的じゃないやろアホくさ
車→高速で走る箱を庶愚民たちが走らせる！？いやどんだけ死人でんのよ…全国にアスファルト引くとかどんだけ時間と金と人かかるか分からんし。そんで対向を区別するのが地面に引いた線って、社会人やったことないやろ
水道→どんだけ長い距離をいかすねん…水腐るやろ普通に考えて…大体地中に水道管埋めるって、地震とか知らない国から来たんですか？大体メンテどうすんだよ提案者学生か？
ガス→爆発物を！？管を辿って！？バカなんですか！？家で火つけた瞬間全て爆発するやん。弁すれば大丈夫って、そんなんいつイカれるか分からんし。リスク高すぎて話にならないでしょ。
飛行機→そーらをwじゆーにーwとーwびたーwいなーーwww何百トンあるものが飛ぶわけないやろ…人乗せてパニックになったらどうすんの？だいたい空なんて乱気流とか起きてるわけやん。まわってまわってまわってまわるんか？
船→海怖。乗るわけ無いやん、なんでひっくり返らないと思えるのか逆に聞きたい。
免責事項: めんどくさいからほぼ調べずに書くし、抜けてる話や間違ってる話もあると思う。
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ほぼすべての翻訳も翻訳会社による有償翻訳に移行すべき。
町場まで車で50分、旧村部の人口が1000人を切っいる、もう限界集落どころかそれを突破したような所で看取り民みたいに暮らしてる増田です。
どうもこんんちは。
何故か、ハンターの協会も、森熊協会も、正反対のところ両方が熊の出没はソーラーが原因と言いだしていて、なんかおかしな方向に行きそうな雰囲気だが、まじやめてくれ。
むしろ人と山との間にソーラーを作って、緩衝地帯にするべきだ。風力でも水力でもいいが、そうやって活用するべき。
最近、熊や野生動物の出没で、メガソーラーがやり玉に挙がってるのがどうも気になるんだよね。
むしろ、メガソーラーとか野生動物対策にちょうどいいシステムだと思うんだけど。
どうするかというと、山付けの耕作放棄地や、かつての村落の荒れ地をソーラー発電にする。
その上で、その収益で周辺を整備する。
整備すると言っても家を建てるとかじゃなくて、ロボット・ラジコン草刈り機が歩いて回れる程度に凹凸を均して整備するとか、風水害で崩れないように土留めや排水をきちんと整備するとかその程度でよい。
そうしてくれればかなり広い面積でも守人が一人でメンテを回せる。
そうして山と里の間にソーラーという緩衝地帯を作って、従来は里山が担っていた、人の住む世界と野生動物が棲む世界の間を区別できる訳だ。
里山や畑をソーラーにすることを自然破壊だという人がいるが、これはそこに暮らす人間としてははっきり逆だと言える。
放置されないためにソーラー発電所はかなり有用だ。その金で地域を守っている。
問題は、放置されたところだ。ここがやばい。竹林などになったらもう最悪で、排水も上手くないから大雨などが降るとあっという間に崩れたりする。
かつて人が植えた果樹が残っていたりするとそれも野生動物を呼んでしまうが、放置されてでかくなった木は切るだけでも金がかかる。
里山はほっとくと里山じゃなくなる。単なる山になる。そうなると山と同じ災害が起きるようになる。それは当たり前の話だが、それは人の暮らす町の近くで山と同じ災害がおきるということだ。遠く離れているから関係ないと思うかもしれないが、あなたの近くに流れている川はどこから来ているかとか考えてみてほしい。
経験的に最悪なのが竹林で、古い段々畑で放置するとほぼ崩れる。次が山林に帰る前の荒れた状態が危ない。蔓植物が蔓延るのも厄介。
きちんと植生がついて山になると地盤は安定してくるが、今度は野生動物が住む場所に変わって人間のエリアではなくなる。土砂災害になるよりはマシと植林するという手もあるが、植林しても今度は林業従事者が足りなくてメンテが行き届かない。
そうなってしまうのを、ソーラーを設置することによって、きちんと排水は設置されるようになるし、草刈りなどの整備は最低限であっても森に帰らない程度には行われる。フェンスなどで囲まれる上に食べ物などはないので、適切に処置すれば野生動物には荒らされにくい。
ソーラーは放置されてしまう土地をきちんと利益を上げて、その利益で守っていくと言う商材としては最適なのだ。
実は俺も何カ所かソーラー発電所（メガソーラーではない。規模は事業用としては小規模）の草刈りや除草剤散などのメンテナンスを請け負っている。その意味でこれはポジショントークだが、そう言う施設があるところの近くでは、放置されているところに比べて野生動物の被害は少ないと思う。
そりゃ、かつてそこに人家があった時代に比べたら増えてはいるだろうが、放置よりはかなりマシだ。
再エネを変に敵視するようなことにしないでくれ。単に目立つだけだ。そして目立つということは野生動物に対しても目立つのだから、町と山を隔てるのに適するという事も理解してくれ。
----
「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を運用する責務を負った。
どの言語だってその可能性は常に念頭にあるが、この歴史的転換点を観測してしまうと、高すぎるリスクを保有するテック企業として技術力を喧伝してきた信用は底値を叩く。
コンピューターサイエンスの信頼性という文脈で、信用を失うのだ。
アルオスメンテ
→ずっとアルスメオンテだと思ってた
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 https://anond.hatelabo.jp/20251020170626# -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaPXtgwAKCRBwMdsubs4+ SERAAQCY72jsWqfl6FvxX42ws77SzPcFQxklES8uo5BDnzMRSwEAwlcTct8N+oWt Olg2lmZGO/ZMhzJ6FmFwdXz7f1muRAY= =4azX -----END PGP SIGNATURE-----
月額1200円で14400円。これに神社費1000円と交通協力金が3000円かかる。年二万円。今は事情があって200円余分にとられてる。
要するにお祭りの補助金。屋台が練り歩く大きなお祭りと、季節ごとのお祭りがある。
なんだかんだと伝統がある。
1000円は自治会費として回収するもので、実際にはさらに寄附を集めている。ワイはさらに1万円と酒を出してる。商売のお付き合いです。
地域の道路の修繕費。カーブミラーを整備交換したり、消えかかった表示を直したり、落書きを消したり、崩れかかった路肩を治したり、防草シートを貼ったり、と言う地域でやっている活動に使われる。
住民税払ってるんだから自治体に出させろ、と言うのは正論で本来そうであるべきだが、昔からこう言う予算が集められていて過去の経緯。ただこれのおかげで道路や側溝が小ぎれいにメンテされている。
https://togetter.com/li/2617426
こんな記事があったので。
で、これたぶん事実じゃないよ。
自治会加入が100戸ととして3万円とったら300万の予算なんだけど、ビールとか出した程度でそんなに金いらないからそれにしか使われてないなんてことは考えられない。
なんつうかいつもの、よくしらんし知りもしないのに妙な言いがかりつけてる奴じゃないかと思った次第。
なお、ワイの自治会も、公式の懇親会は年に2回、花見と忘年会をやる。単位は「隣組」単位なので10戸とかでやる。会費制で補助は出ない。
