エンジニアが問題なのではありません。問題は、彼らに任せている仕事です。
正直に最後のスプリントを見てください。そのうちのどれくらいが新しいものを構築していて、どれくらいがすでにデプロイされているものの監視でしたか?
オンコールシフト。トリアージローテーション。 Null チェックが行われずに終了した調査。同じ回帰の事後分析を 1 年に 3 回実施。プラットフォーム チームは、厳密にはプラットフォーム チームですが、実際には照明を点灯し続けるために存在します。という Slack チャネル #消防 ミュートするのは無責任だと感じるので、誰もミュートしたくないのです。
私たちはこれがエンジニアリングであると確信しています。
そうではありません。監修です。
高価な仕事が必ずしも印象的な仕事とは限りません
生産保守は外から見ると深刻に見えるかもしれません。ダッシュボードが開いています。スレッドが移動しています。ログがスクロールしています。エンジニアはプレッシャーの下で判断を下しています。
その作業の一部は必要です。その多くは、組織が不完全な自動化のバックアップ システムとして人間に依頼しているだけです。
チームの優秀なエンジニアは、インシデント チャネルを更新したり、同じデプロイ ウィンドウを 2 回比較したり、何かが赤くなるまでパイプラインを子守したりするために参加したわけではありません。彼らは製品を構築し、アーキテクチャを改善し、制約を取り除き、活用を生み出すために参加しました。
週の 3 分の 1 が生産監督に費やされると、会社は単に時間を失うだけではありません。上級エンジニアが将来について考えるという複合効果が失われます。
ループは手動であるため、パターンが繰り返されます
繰り返し行われる制作作業のほとんどは、次のようなおなじみの手順に従います。
- 何かが失敗します。
- アラートは人間に届きます。
- 人間はトレースを開き、ログを記録し、履歴を展開し、最近のコミットを実行します。
- 誰かがサービスの所有者を尋ねます。
- チームは、それがバグなのか、不適切なデプロイなのか、上流の問題なのか、データのエッジケースなのかを議論します。
- 実際の修正は小規模であることが判明しました。
修正は必ずしも難しいわけではありません。修正に取り組むことが午後の熱意です。
このギャップにより、チームは製品の勢いを失います。また、AI エージェントがエンジニアから制御を奪うことなく支援できる場所でもあります。
2026 年には、これは解決可能な問題です
自己修復ソフトウェアは、モデルが黙って生産を変更することを意味するものではありません。それは、本格的なエンジニアリング チームが望んでいることではありません。
より優れたモデルは範囲が狭く、より便利です。
- トレースを読む
- 失敗を要約する
- デプロイを比較する
- 可能性のある回帰を見つける
- 所有者を特定する
- プルリクエストの草案を作成する
- 証拠を見せて
- 承認を待ちます
これにより、エンジニアはエンジニアリング上の判断を失わずに時間を取り戻すことができます。人間は依然として診断を確認し、パッチを編集し、テストをチェックし、マージするかどうかを決定します。
エージェントが監督業務を担当します。エンジニアが決定を行います。
CTO への質問は変わりつつある
今四半期、すべての CTO にとっての疑問は、「エンジニアは十分にいますか?」ということだけではありません。
また、「修正を出荷するための人間の承認を待っている間、なぜ当社のエンジニアはエージェントが 90 秒で準備できる作業を行っているのでしょうか?」とも言えます。
答えがコンプライアンス、所有権、または安全であれば、それは有効です。それらの制約は重要です。ただし、手動を維持するためにレビュー前のすべてのステップを必要とするわけではありません。
チームは制御を維持しながら、本番シグナルからレビューされたプルリクエストまでの反復的なパスを自動化できます。
エンジニアに生産時間を取り戻してください
最も優秀なエンジニアは、40,127 行のログ出力を読んでいるため、製品の作業を欠かすことはできません。
これらは CI/CD の冗長層であってはなりません。
同じクラスの回帰が戻ってきたことを再び証明するために火曜日の午後を費やすべきではない。
彼らは、会社が実際に資金を集めて構築したものを構築する必要があります。
目標は、運用上の責任を排除することではありません。目標は、人間の注意をシステム内で最も安価な監視プリミティブとして扱うのをやめることです。
エンジニアは子守りではなく、構築する必要があります。彼らに構築する時間を返してください。
