移行したのに、そのまま消した — google_sign_in v7 対応と機能削除の判断
「ぽんっ！」（旧称：でいりんぐ）で google_sign_in を v7 に移行しました。ところがその直後、Google/Apple 連携そのものを実装しない方針が固まり、機能ごと削除しました。一見ムダに見えますが、ここには「休眠コードをどう扱うか」という学びがありました。
背景（当時の状況）
少し珍しい経緯の記録です。Dependabot が上げてきた google_sign_in のメジャー更新に対応して v7 へ移行したその直後、2026-07-17 に「Google/Apple 連携はそもそも実装しない」という方針が確定し、移行したばかりのコードを機能ごと削除しました。ムダに見えて、実は「休眠コードをどう扱うか」を考える良い機会でした。
まず v7 移行で得た設計の学び
削除する前の v7 移行では、いくつか良いパターンが得られました（将来復活させるなら再利用できます）。
- 初期化ゲート:
GoogleSignIn.instanceを使う前に初期化を保証するゲートを置く（memo 化し、失敗時は破棄して再初期化できるように）。これは課金 SDK の「設定完了を保証してから呼ぶ」と同じ発想です。 - 設定は設定ファイルに委ねる: サーバクライアント ID をコードにハードコードせず、Android / iOS それぞれの Firebase 設定ファイルから自動構成させる。flavor による差異も吸収できる。
- キャンセルの契約を維持: v7 でキャンセルが例外方式に変わったため、既存の呼び出し側契約を保つよう自前の例外型に変換し、仕様テストで固定した。
そして「機能ごと削除」を選んだ
移行の直後に方針が変わり、Google/Apple 連携は当面実装しないことになりました。ここで選択肢は 2 つです。
- コードは残す（将来のために取っておく）。
- 機能ごと削除する。
ぽんっ！では 2（削除） を選びました。理由は、この連携コードが当時から UI に到達できない休眠コードだったからです。
休眠コードを抱えるコスト
「いつか使うかも」で残したコードには、地味なコストがあります。
- 依存が増える（
google_sign_inとその推移的依存、iOS 側 SDK など）。攻撃面・ビルド時間・更新追従の負担が増える。 - 保守対象になる。使っていないのに、依存更新のたびに壊れていないか気にすることになる。
- 読み手を惑わせる。到達不能なコードは「使われているのか？」という疑問を生む。
将来必要になったら、そのときのバージョンで作り直すほうが健全だと判断しました。過去の実装は git 履歴（移行 PR）に残るので、参照はできます。
まとめ
- 依存移行で得た設計パターン（初期化ゲート・設定ファイル委譲・例外契約の維持）は、機能を消しても再利用できる資産になる。
- 休眠コード（UI 到達不能なコード）は、依存・保守・可読性のコストを静かに増やす。「いつか使うかも」より、必要になったら作り直すほうが健全なことが多い。
- 消す判断をしても、実装は git 履歴に残る。復活の可能性は履歴で担保できるので、思い切って削除できます。