「AIはSREを置き換えない、スキルを奪う」の指摘にHNで賛否
姉妹サイトの新着
海外エンジニア向けニュースレターSignozに掲載された「AIはSREを置き換えているのではなく、スキルを奪っている」という記事が、Hacker Newsで活発な議論を呼んだ。SRE(Site Reliability Engineering)はGoogleが提唱した運用職種で、記事はAI支援ツールに頼るほど障害対応の地力が落ちていくと指摘する内容。スレッドでは、DevOpsという働き方は実際には定着していないという指摘や、パイロットの訓練義務を手本にすべきかという意見、AIに任せていい作業とそうでない作業の線引きなど、賛否が分かれる議論になった。
AIはSREを置き換えていない。スキルを奪っているだけだ
出典: newsletter.signoz.io / 元記事はこちら
SREって肩書きはそもそもダサかったし、ゼロ金利時代(ZIRP)に流行った『DevOps』運動も同じくダサかった。本物のエンジニアは自分が作ったシステムのオンコールを自分でやるものだ。
>>4
> SREって肩書きはそもそもダサかったし、ZIRP時代の『DevOps』運動も同じくダサかった。本物のエンジニアは自分が作ったシステムのオンコールを自分でやるものだ。
いろいろなモデルを一緒くたにしてるよ。実際『開発者は自分が作ったシステムのオンコールをすべき』という考え方は、DevOps派のほとんどが強く支持している原則だ。
> SREって肩書きはそもそもダサかったし、ZIRP時代の『DevOps』運動も同じくダサかった。本物のエンジニアは自分が作ったシステムのオンコールを自分でやるものだ。
いろいろなモデルを一緒くたにしてるよ。実際『開発者は自分が作ったシステムのオンコールをすべき』という考え方は、DevOps派のほとんどが強く支持している原則だ。
>>4
ZIRP?聞き慣れない略語だな。
ZIRP?聞き慣れない略語だな。
>>4
SREはどうせインフラ/プラットフォームエンジニアリングに取って代わられて消えていく運命だよ。結局Terraformを使ったKubernetes管理人みたいな仕事になってる気がする。
SREはどうせインフラ/プラットフォームエンジニアリングに取って代わられて消えていく運命だよ。結局Terraformを使ったKubernetes管理人みたいな仕事になってる気がする。
みんな『テクノロジスト』や『テクノロジーディレクター』という新しいキャリアパスに流れ込んでいるんだと思う。目標とフィードバックを踏まえて、適切なタイミングで適切な問いを立て、注意を向けるべき場所を示せる人たちのことだ。
単純作業しかせず、なぜそれをやるのか考えない人間ならAIに置き換えられるだろう。SREの本質は高度な思考、コンテキストの切り替え、パターンやワークフローの把握、データの流れの理解とかにある。
数日前にAIによる『スキルの剥奪』全般について調べてみた。明るい兆候はどこにも見当たらなかったけど、できる対策はいくつかある。毎週『コーディングの時間』を意識的に作る、LeetCodeの問題を解く、マージ前にエージェントに自分をテストさせる(Notionのやり方を真似た)とか。
Golangを使うべき場面で、イメージのビルド層を書くのが面倒だからって複雑なbashに逃げるようなやつのスキルが失われるなら、それは大賛成だ。
自分で考えたんだけど、こういう喩えが好きだ。『物書きでない人』は読むに耐えない記事を見栄えだけ立派に書けるし、それは『プログラマーでない人』が使うに耐えないソフトを見栄えだけ立派に作れるのと同じだ。
AI利用がチームや組織文化に与える影響に今もやもやしていて、『アルジャーノンに花束を』を読み直すことにした。直接関係はないけど、あの比喩は今の状況にかなり当てはまる気がする。
100%同意。まさに現場で見ている。SREやNOC(監視室)の人間が、ただの『肉の中継役』になりつつある。
AIのSREエージェントがあっても『デバッグ可能なWebインフラ』がなぜ重要かを、自分のWebサーバープロジェクトのブログでこの記事を引用して書こうと思ってたんだけど、結局書くのが遅れて、代わりにHNに投稿しちゃったよ…(笑)
もうこの状況だと、会社は『エンタープライズLLMへのアクセスを剥奪する』だけで実質的に社員を解雇できるようなものだ。
>>23
それより心配なのは、LLM企業がアクセスを止めたり、資金が尽きて潰れたりすることで、会社全体がダメになる可能性の方だ。
それより心配なのは、LLM企業がアクセスを止めたり、資金が尽きて潰れたりすることで、会社全体がダメになる可能性の方だ。
>>23
給料がもらえるなら気にしないよ。好きなだけ皮肉を言ってくれていい!
給料がもらえるなら気にしないよ。好きなだけ皮肉を言ってくれていい!
>>2
パイロットと同じように、SREも年に一定時間はシミュレーターでの訓練が必須になって、腕を鈍らせないようにする必要が出てくるだろうね。
パイロットと同じように、SREも年に一定時間はシミュレーターでの訓練が必須になって、腕を鈍らせないようにする必要が出てくるだろうね。
>>2
航空業界が違うのは、必須の法的規制によって『既得権益の確保』が強制されている点だ。ソフトウェアの世界に同じインセンティブ構造があるかは怪しい。つまり、俺たちは別に趣味を見つけた方がいいのかもね。
航空業界が違うのは、必須の法的規制によって『既得権益の確保』が強制されている点だ。ソフトウェアの世界に同じインセンティブ構造があるかは怪しい。つまり、俺たちは別に趣味を見つけた方がいいのかもね。
>>26
パイロットという肩書きを持つ人に、非常時に手動で飛行機を操縦できることを求めるのが、どうして『既得権益の確保』になるんだ?
パイロットという肩書きを持つ人に、非常時に手動で飛行機を操縦できることを求めるのが、どうして『既得権益の確保』になるんだ?
>>26
学ぶべき良い業界だとは思うよ。ソフトウェア業界がそのまま航空業界になるべきだと言ってるわけじゃない。
学ぶべき良い業界だとは思うよ。ソフトウェア業界がそのまま航空業界になるべきだと言ってるわけじゃない。
>>4
DevOpsという発想自体は理にかなっていたけど、実際にまともに実現されることは稀だった。開発者と別に『DevOpsチーム』を作っている会社があるとしたら、それ自体が定義上DevOpsをやっていないということだ。
DevOpsという発想自体は理にかなっていたけど、実際にまともに実現されることは稀だった。開発者と別に『DevOpsチーム』を作っている会社があるとしたら、それ自体が定義上DevOpsをやっていないということだ。
>>4
組織の規模がある程度大きくなると、チームが自分たちの作ったシステムのオンコールを、擦り減らずにきちんとこなせるように、ある種の集約化をした方が合理的になる段階が来る。
組織の規模がある程度大きくなると、チームが自分たちの作ったシステムのオンコールを、擦り減らずにきちんとこなせるように、ある種の集約化をした方が合理的になる段階が来る。
>>4
システムの下にはいつもインフラ/プラットフォームの層がある。それがSREだよ。
システムの下にはいつもインフラ/プラットフォームの層がある。それがSREだよ。
>>4
組織が大きくなるとそれは当てはまらない。
組織が大きくなるとそれは当てはまらない。
>>7
例えばクラスター全体に及ぶ障害を分析するのに、そもそもそのシステムが既に収集しているオブザーバビリティデータ以外に、AIモデルにどんなコンテキストが必要だって言うんだ?
例えばクラスター全体に及ぶ障害を分析するのに、そもそもそのシステムが既に収集しているオブザーバビリティデータ以外に、AIモデルにどんなコンテキストが必要だって言うんだ?
>>7
構築するのはそんなに大変なことか?基本形なら、好きなターミナル型コーディングエージェントのCLIから全部動かせるようにして(大体もう揃ってるはず)、アラートに繋いで、あとは隅っこで動かしておくだけじゃないか?
構築するのはそんなに大変なことか?基本形なら、好きなターミナル型コーディングエージェントのCLIから全部動かせるようにして(大体もう揃ってるはず)、アラートに繋いで、あとは隅っこで動かしておくだけじゃないか?
>>8
> 毎週『コーディングの時間』を意識的に作る、LeetCodeの問題を解く
きっと叩かれるだろうけど言わせてくれ。経験15年の自分からすると、絶対に嫌だ。日々のコーディングの魅力なんて3〜4年前に失っていて、今はただの手段にすぎない。AIは自分にとってまさに良いタイミングで来てくれたと思ってる。
> 毎週『コーディングの時間』を意識的に作る、LeetCodeの問題を解く
きっと叩かれるだろうけど言わせてくれ。経験15年の自分からすると、絶対に嫌だ。日々のコーディングの魅力なんて3〜4年前に失っていて、今はただの手段にすぎない。AIは自分にとってまさに良いタイミングで来てくれたと思ってる。
>>42
経験40年の自分から見ると、あなたはそもそも心からコーディングが好きじゃなかったんじゃないか。自分は仕事でコードを書けなくなったのが本当に寂しい。個人プロジェクトでは今でもたくさんコードを書いてるよ。
経験40年の自分から見ると、あなたはそもそも心からコーディングが好きじゃなかったんじゃないか。自分は仕事でコードを書けなくなったのが本当に寂しい。個人プロジェクトでは今でもたくさんコードを書いてるよ。
一番笑えるのは、大規模障害の最中に2人の開発者が頭を使わずにClaudeの出力をただ投げ合っているだけのパターンだ。自分の頭を使えよと。
>>54
どうもその2人は『BC(Before Claude、Claude以前)』の時代からあまり頭を使うタイプじゃなかった気がするな。
どうもその2人は『BC(Before Claude、Claude以前)』の時代からあまり頭を使うタイプじゃなかった気がするな。
他サイトの新着
>>34
いいね、『実はGoogleのSREだけど』ってコメントがどれだけ早く出てくるかタイマーで計ってたんだけど、しっかり期待に応えてくれたな。
> SREの要点は、機能リリースを急ぐプロダクト側との緊張関係のバランスを取るために、スケーラビリティ/耐障害性に専念するチームを持つことだ。
それは文化的な問題に聞こえるな。Googleはそこを見直した方がいいんじゃないか。
いいね、『実はGoogleのSREだけど』ってコメントがどれだけ早く出てくるかタイマーで計ってたんだけど、しっかり期待に応えてくれたな。
> SREの要点は、機能リリースを急ぐプロダクト側との緊張関係のバランスを取るために、スケーラビリティ/耐障害性に専念するチームを持つことだ。
それは文化的な問題に聞こえるな。Googleはそこを見直した方がいいんじゃないか。
>>63
多くの組織が抱える文化的な問題だよ。大企業の大半がITとは別に情報セキュリティ部門を置いているのも同じ理由だ。
多くの組織が抱える文化的な問題だよ。大企業の大半がITとは別に情報セキュリティ部門を置いているのも同じ理由だ。
>>63
あの人の言う通りだよ。
あの人の言う通りだよ。
>>37
シスアド/DevOps/SREという肩書きの人たちが、基礎的なスキルより特定ツールのスキルばかり身につけて、5年おきに『なんで仕事がなくなったんだ』と首をかしげる、という永遠に続く流れがまた繰り返されてるだけだ。
シスアド/DevOps/SREという肩書きの人たちが、基礎的なスキルより特定ツールのスキルばかり身につけて、5年おきに『なんで仕事がなくなったんだ』と首をかしげる、という永遠に続く流れがまた繰り返されてるだけだ。
>>68
SREをそういうものだと思ってるなら、あなたは何も分かっていない。
SREをそういうものだと思ってるなら、あなたは何も分かっていない。
>>55
AWSやAzure、GCPなんかは、もっと効果的に同じことをすでにやれる立場にある。銀行はさらに効果的にね。
ただLLMの場合、最悪のシナリオでも自分でモデルを動かせば済むという救いはある。
AWSやAzure、GCPなんかは、もっと効果的に同じことをすでにやれる立場にある。銀行はさらに効果的にね。
ただLLMの場合、最悪のシナリオでも自分でモデルを動かせば済むという救いはある。
>>73
クラウド利用の話は俺に振らないでくれ。その懸念は十分わかってるから。
クラウド利用の話は俺に振らないでくれ。その懸念は十分わかってるから。
>>71
そう決めつけるのは早いよ。年を取れば欲求は変わるし、業界自体も変わった(『がむしゃらにコードを書く』ことの意味も含めて)、燃え尽き症候群に悩む人も多い。
それに、細かいコードの問題をゴリゴリ解くのが好きな人もいれば、システムレベルの設計を組み立てるのが好きな人もいる。これは昔から変わらない話だ。
そう決めつけるのは早いよ。年を取れば欲求は変わるし、業界自体も変わった(『がむしゃらにコードを書く』ことの意味も含めて)、燃え尽き症候群に悩む人も多い。
それに、細かいコードの問題をゴリゴリ解くのが好きな人もいれば、システムレベルの設計を組み立てるのが好きな人もいる。これは昔から変わらない話だ。
>>84
みんなこの10年のReactコンポーネントのくだらない話を、自分が16歳の頃に学んでいたコードと同じものみたいに扱ってるけど、まるで違うものだよ。それにそのどれもDaybreakの審査を受けていない。
みんなこの10年のReactコンポーネントのくだらない話を、自分が16歳の頃に学んでいたコードと同じものみたいに扱ってるけど、まるで違うものだよ。それにそのどれもDaybreakの審査を受けていない。
>>88
自分の本来の作業の周辺にくっついてくるReactなどの付随的なツールの処理は、ロボットに任せられて本当にありがたい。チームメイトの手を止めさせたり、自分の仕事にとって長期的な価値のないことに時間と思考力を使ったりせずに、作業の詰まりを避けられる。
自分の本来の作業の周辺にくっついてくるReactなどの付随的なツールの処理は、ロボットに任せられて本当にありがたい。チームメイトの手を止めさせたり、自分の仕事にとって長期的な価値のないことに時間と思考力を使ったりせずに、作業の詰まりを避けられる。
>>88
まさにそれが言いたかったことで、『本物のコード書き』においてさえ、業界自体が変わったってことなんだ。
まさにそれが言いたかったことで、『本物のコード書き』においてさえ、業界自体が変わったってことなんだ。
この話題の背景と論点
SRE(Site Reliability Engineering)は2003年ごろGoogle社内で生まれた運用職種で、システムの信頼性をエンジニアリングの手法で担保する点が従来の「運用」と異なるとされてきた。元記事は、AIによる障害対応支援が広がるほどエンジニア自身の勘や手順理解が鈍っていくという、自動化と熟練度低下という古くからある議論をSREに当てはめたもの。スレッドでは、この現象をDevOpsやSREという職種自体の形骸化の延長と見る声と、「開発者が自分のシステムに責任を持つ」という原則はむしろ健在だとする声とに分かれた。また、AIにどこまで任せるべきかの受け止め方は、キャリアの長さによって大きく異なっている点も読み取れる。
※本記事は海外掲示板 Hacker News のスレッド「AI Isn’t Replacing SREs. It’s Deskilling Them」から抜粋し、編集部で日本語に意訳したものです。訳文の責任は当サイトにあります。
この記事のリアクション
まだコメントはありません。