今日は別のことを書くつもりだったのですが、まったく、nerd-snipedされてしまいました。
先週、Honeycombブログに「You Had One Job: Why Twenty Years of DevOps Has Failed to Do It」という記事を公開しました。自分自身の言葉を引用すると：
In retrospect, I think the entire DevOps movement was a mighty, twenty year battle to achieve one thing: a single feedback loop connecting devs with prod.
On those grounds, it failed.
Not because software engineers weren’t good at their jobs, or didn’t care enough. It failed because the technology wasn’t good enough. The tools we gave them weren’t designed for this, so using them could easily double, triple, or quadruple the time it took to do their job: writing business logic.
This isn’t true everywhere. Please keep in mind that all data tools are effectively fungible if you can assume an infinite amount of time, money, and engineering skill. You can run production off an Excel spreadsheet if you have to, and some SREs have done so. That doesn’t make it a great solution, the right use of resources, or accessible to the median engineering org.
自分でもなかなか面白い記事だと思うので、ぜひ読んでみてください。（たくさんの棒人間アート付き！）
昨日朝、LinkedInにリンクを投稿したところ、いつものようにコメントが寄せられました。
（インターネットは間違いでしたね、バージニア。）
「devs should own everything（開発者がすべてを所有すべき）」「make every team responsible for their own devops work（各チームが自らのdevops業務を担当すべき）」といったコメントや、私のお気に入りである次のようなコメントがありました：
“I still think the main problem is with the ownership model - the fact that devs don’t own the full system, including infra and ops.”
（Alex Pulverさんによるものです。快く実名引用を許可していただき、「彼はこの発言をしっかりと支持している😂」と付け加えています。）
実は、私自身もここ10年ほど、ソフトウェア開発者が本番環境で自分のコードを所有する（そして所有することが期待される）という、私の友人がここで述べているようなモデルを積極的に提唱してきました。異論はありません！
しかし「devs should own the full system, including infra and ops（開発者がインフラやopsを含むシステム全体を所有すべき）」というのはどうでしょうか？
少し話をしましょう。
ソフトウェアの世界——ソフトウェアに限って——では、opsが汚い言葉になってしまいました。誰もそれを名乗ろうとしません。OperationsチームはDevOpsチーム、SRE、インフラストラクチャ、プロダクションエンジニアリング、あるいは最近ではプラットフォームエンジニアリングチームへと改名されました。Ops以外の何かに。
OpsとはToilのこと！ハッシュタグ#NoOps！
第一に、これはまったくバカげています。
Opsの何が問題なのでしょうか？Opsはtoilの同義語ではありません。Opsは文字通り「できるだけ効率的に物事を成し遂げる」という意味です。あらゆる機能には規模に応じた運用面が存在します。business ops、marketing ops、sales ops、product ops、design ops、そして他に思いつく限りのものを検索してみましたが、ソフトウェアエンジニアリングが自らの運用機能に対して示してきたような軽蔑や無視、露骨な侮辱に匹敵する扱いを受けているものは、一つもありませんでした。1
第二に……いったい何が起こったのでしょうか？
いくつかの要因（APIやクラウドコンピューティング、急上昇した利益率など）を考えられますが、簡単で明白な、口ひげをひねる悪役を一つ思い浮かべることもできます。それならあなたにとっても良い話になり、私にとっても作業が少なくて済みます。（根本原因分析の勝利です!! ✊）
Googleです。Googleのせいです。
Googleに聞いたところ、そう教えてくれたのでわかります。
（何ですって？これは無料のSubstackであって、科学ではありません。）
私が思うに、こういったことが起きました。Googleは伝統的な運用ではスケールしないため、よりソフトウェアエンジニアリングに近づける必要があると力強く主張しました。これはまさに正しいタイミングでの正しいメッセージでした。なぜなら、クラウドコンピューティング、API、SaaSなどがちょうど登場し始め、システムをよりプログラム的に管理することが可能になっていたからです。
ここまでは良い。しかし、私たちがこれを「開発者（コードを書く人：善）」対オペレーター（手作業で物事を行う人：悪）と定義し始めたときに、重大な区別が失われてしまいました。これが、私たちが今日に至る滑りやすい坂道を下り始めたきっかけです。運用エンジニアリングという事業にとって重要な機能全体が、後進的で無能なものと広く見なされるようになったのです。
「dev」と「ops」の違いは、コードを書けるかどうかではありません。皆さん、2026年です：みんながソフトウェアを書いています。
devとopsの違いは、関心事の分離です。
もしあなたの関心事が、新機能や新製品を構築して顧客を引きつけ、新たな収益を生み出すことであるなら、おめでとうございます：あなたはdevです。（それはわかっていましたよね。）
もしあなたの関心事が、基幹サービスを構築し、あらゆる脅威（リストの最上位には自社の開発者も含まれます）に対して顧客にサービスを提供し続ける能力を守ることであるなら、おめでとうございます／ご愁傷様ですが、あなたは実際にはopsにいるのです。
これらの機能的な関心事はどちらも不可欠であり、「文字通りそれなしでは生き残れない」ものであり、補完的な関係にあります。製品開発者には、機能や製品の構築に集中し、各ユーザーの体験を深く気遣い、ビジネスに価値を付加する方法を探してもらう必要があります。運用には、それらの製品が動作するための回復力があり、スケーラブルで効率的な基盤を提供してもらう必要があります。
Opsは「toil」ではありません。「プログラミングが下手なバカ」という意味でもありません。運用エンジニアリングは、製品や機能を作るためのソフトウェアを書くことより簡単でも劣っているわけでもありません。
皮肉なことに、むしろ逆が真実です。
製品エンジニアリングは、通常、インフラストラクチャエンジニアリングよりもはるかに単純です——もちろん、それは運用の主要な機能の一つが、製品をできるだけ簡単に構築・出荷できるようにすることだからでもあります。運用は最も困難な技術的問題を吸収し、製品開発にとってシンプルで信頼性が高く、ナビゲートしやすい表層を提供します。
製品エンジニアが愚かだったり劣っていたりするからではありません（その罠にはまらないようにしましょう2！）。理由は、認知的な帯域幅は、あらゆるエンジニアリング組織において最も希少なリソースであり、それをできるだけ多く、ビジネスを具体的に前進させることに振り向けたいからです。システムの混沌とした下部構造と格闘するのではなく。
最も困難な技術的課題と、解決困難な問題の長くしつこい尾は、常にインフラストラクチャ側にありました。だからこそ、私たちはそれらを持たないようこれほどまでに努力するのです——パートナーシップ、クラウドコンピューティング、オープンソースなどによって解決するために。何でもいいのです。ゼロからやり直してそれらを再構築するよりは。3
私が何千回も言ってきたように：ディスクにビットを書き込むことに近づくほど、あなたはより保守的（そして恐れるべき）であるべきです。
ユーザーとのインタラクションに近づくほど、実験をしたり、AIに任せたり、この子犬をYOLOしたりすることが許容されます。
これが正しいあり方です。
devとopsの違いは、コードを書くかどうかではありません。しかし、違いは存在します。視点、優先順位、そして（しばしば）気質において。
これらのいくつかについては、私が先ほど書いたフィードバックループに関する記事で触れましたので、ここでは繰り返しません。
言及しなかった最大の違いは、リソースとの関係と成功の定義が異なるということです。
インフラストラクチャはコストセンターです。会社の全員にノートPCを10台ずつ与えても収益は増えませんし、インフラストラクチャに過剰に支出しても収益は増えません。優れた運用エンジニアやアーキテクトは、コストがエンジニアリング上の意思決定における一級の市民であることを決して忘れません。
理論上は、製品エンジニアリングにより多く支出することで収益を増やせます。これを「投資」と呼んでいますが、時には「自分の時間がお金をかけるものだと忘れているエンジニアたち」という意味であることもあるようです。
（失礼しました。）
「プラットフォームエンジニアリングについてはどうか？」——それはopsが着飾ったものです。
少し率直に言うと：私の友人のAbby Bangserの引用が好きです：「プラットフォームは、あなたのビジネスに固有だが、チーム間で共通するものをエンコードすべきだ」。そしてJack Dangerの棒人間アートと、彼の「システムの中央を見るようにエンジニアを自然に引きつける唯一のものは、純粋な盲目的な怒りだ」という指摘も好きです。
プラットフォームエンジニアリングムーブメントについて私が好きな点は、運用領域にデザイン思考と製品開発の実践をもたらしたことです。
はい、私たちは製品開発者を顧客のように扱い、彼らに与えるインターフェースについて批判的に考えるべきです。はい、インフラストラクチャと製品エンジニアリングの間には、中間層があり、それ独自のパターンと落とし穴が存在します。
またはい：機能的な観点から、プラットフォームエンジニアリングは依然としてopsです。（あるいは少なくとも、opsでない部分よりopsである部分の方が多い。）
ええ、私はそう思うんです。
これらの流行のネーミングスキームは、運用の本質的な価値を変えるものではありません。その価値とは、収益を生み出す部分の機能を統合し、効率的に提供することです。4これはテクノロジーにおいても、営業やマーケティングにおいても同様に真実です。言葉から逃げて目的を否定することは、水を濁し、まさに明確さが最も必要とされる時点で混乱を引き起こします。
エンジニアリングチームは、自分たちが効率性に向いているのか、投資に向いているのかを知る必要があります。両方を最適化することはできません。それは、どのように採用し、どのように構築し、成功をどのように考え、進捗をどのように測定するかを変えます。それはリスクに対する嗜好だけでなく、何がそもそもリスクとみなされるかをも変えます。
また、彼らはビジネスロジックを担当しているのか、それともそれが動作するプラットフォームを担当しているのかを知る必要があります。
なぜなら、誰もがすべてをできるわけではないからです。開発者に自分のコードを所有するよう求めることは一つのことです。（素晴らしい。）しかし、自分のコードとその下にある技術的な氷山全体を所有するよう求めることは、全く別の話です。誰かに習得し、注意を払うよう求める表面積が大きければ大きいほど、どの場所においても彼らから期待できる集中力は少なくなります。
収益を生み出すチームに、収益を生み出してほしいですか？それともそうでないですか？
もし現時点でこれらの関心事を分離できないのであれば、それは目指すべき目標かもしれません。しかし、部屋の半分が逃げ出し、残りの半分が「toil!」とわめくような状況では、運用の機能について話すことは困難です。
運用の厳格さと優秀さは、テクノロジー業界で当然のように期待できるものには、まだなっていません。2025年のDORAレポートで最も印象的だったのは、大多数の企業が、AIがすでに混沌としたシステムにさらなる混沌を加えていると報告していることです。言い換えれば、ほとんどの企業はopsが下手なのです。
ある程度、これは問題が難しいからでもあります。しかし、より大きな要因は、私たちが運用という言葉を誇りとして放棄してしまったことの原因（そして結果）だと思います。
それはまたの悪しきフィードバックループです。野心的な若手エンジニアは、opsに関わることは良くないというメッセージを受け取り、そうしたチームから逃げ出します。マネージャーや経営幹部は優秀な人材を採用し、仕事を魅力的に見せようとするため、トレンドのネーミングスキームを採用して、この仕事がopsではないことを明確にします。
何かをうまくやりたいのであれば、歴史的に見て、これは正しい方法ではありません。優秀さを築く方法は、それをあるがままに名付け、実践コミュニティを構築し、基準を引き上げ、よくできた仕事に対して報酬を与えることです。
あるいは、ある予言者が2016年にこう言ったように：
私は、「operations」を誇りある言葉として取り戻す時が来たと思います。価値があり、報われるものとして。
「Operations」には確かに荷物があります。しかし、何かをより良くするための効果的なアプローチは、距離を置いたり否定したりすることではないと思います。ましてや、あなたが質の高いサービスを提供するために必要とするスキルセットをdisったり、価値を下げたりすることではありません。
チームを「DevOps」や「SRE」などに改名したからといって、運用成果が魔法のように良くなるわけではありません。 それを改善する方法は、それをあるがままに名付け、主張し、すべての人が自らの役割が運用目標とどのように関連しているかを理解できるようにすることです。
すごい。本当に、私自身がこれ以上うまく言えなかったでしょう。
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.