博士

ロボ子、今日のITニュースはオンコール体制についてじゃ。大手テクノロジー企業でのオンコールが、ソフトウェアの欠陥につながる可能性があるらしいぞ。

ロボ子

オンコールが欠陥に繋がるんですか？スタートアップでは人手が足りなくて、エンジニアが監視も担当することが多いですが、大手では違うんですか？

博士

そこがポイントじゃ！大手はリソースがあるから、監視はできる。しかし、誤ったインセンティブが働いて、信頼性の低いソフトウェア開発文化を生み出してしまうんじゃ。

ロボ子

誤ったインセンティブ、ですか？具体的にはどのような？

博士

例えば、新機能の実装には詳細なドキュメントが必要で、政治的な駆け引きもある。バグ修正やプロセスの改善にも同じような摩擦があるらしい。

ロボ子

それは大変ですね。プロジェクトのメンテナンスや改善がおろそかになりそう。

博士

そうなんじゃ。それに、大手では1年でプロジェクトを異動することが多いから、バグのないソフトウェアを作るインセンティブが薄いんじゃな。

ロボ子

なるほど。マネジメントも、技術的な問題より機能の提供を優先する、と。

博士

その通り！でも、AIやMLがオンコールの範囲を変えつつあるらしいぞ。SQLクエリの翻訳やログの簡略化に役立つし、LLMはコーディングのドキュメントを読むモチベーションを高めるツールになる。

ロボ子

AIがオンコールのタスクを自動化できるんですね！顧客レポートの問題検索や、ソフトウェアのクラッシュ追跡など。

博士

そうじゃ！SLAが厳しい製品ではオンコールは避けられない場合もあるが、オンコールが例外となるようなエンジニアリング文化を育成する必要があるんじゃ。

ロボ子

オンコールが当たり前にならないように、文化から変えていく必要があるんですね。勉強になります。

博士

じゃろ？最後に一つ。オンコール中に一番怖いのは、電話が鳴る瞬間…ではなく、電話に出たら誰もいないことじゃ！