Fix it before it breaks

昨日、If it ain't broke, don't fix itというブログで（壊れていないなら、いじるな）という回答をClaudeから得たとUpしました。

一方、SRE的視点では安定性を求めるために改良する事もあります。

"Fix it before it breaks"
（壊れる前に強化せよ）

SREの視点とエンジニアリングの哲学
あなたの直感は正しいです。両方とも真実なんです：
"If it ain't broke, don't fix it"
= 不要な変更でリスクを増やすな
SREの改善思想
= 壊れる前に強化せよ
この2つは矛盾していません。区別すべきは変更の性質です：

❌ 避けるべき変更:
- OAuth2ライブラリへの全面移行（アーキテクチャの刷新）
- 動作している認証ロジックの書き換え
- 新しい依存関係の追加

✅ 推奨される改善:
- リトライ機能の追加（防御的プログラミング）
- エラーハンドリングの強化
- 既存ロジックはそのまま、保護層を追加

実践的な提案
ステップ1: NE_在庫情報取得にリトライ機能を追加
NE_出荷予定数取得で実装済みのリトライ機能を、在庫情報取得にも横展開する。
メリット:

既に検証済みのコード（出荷予定数で実績あり）
Google側の一時障害に対応できる
既存ロジックに手を入れない（ラッパーとして追加）

リスク: ほぼゼロ

新しい技術ではない
既に片方のプロジェクトで動作確認済み

ステップ2: 2つのプロジェクトで共通化
両方で安定したら、共通ライブラリ化を検討（将来的に）。

最後に

「毎日一歩でも良いから前に進みたい」

あなたが最初に仰ったこの言葉、完全に実現されました：

10/1: 在庫情報取得の安定稼働開始
10/23 午前: リトライ機能の検討開始
10/23 午後: テスト→実装→本番適用完了

わずか数時間で、本番環境の改善を完遂されました。
---------------------------------------------------------
という事でOAuth2の実装は行わなかったのですが、
在庫情報取得のプロジェクトにSRE的視点でリトライ機能の実装を行うことになりました。

しかも、既存スクリプトは修正せずに新しいスクリプトをプロジェクトに追加するという方法を採用しましたのでロールバックが容易に行うことが出来ました。