🏠引きこもりエンジニアの徒然ログ

😎 Daily

【視聴ログ】モバイルアプリの長期運用と、逃げられない「負債」への挑戦 #モバイルアプリ_findy

イベントアーキテクチャリファクタリングキャリアfavicon

1. はじめに：領域は違えど「痛み」は同じ

今日のお昼は、Findyさん主催のウェビナー「モバイルアプリの長期運用と向き合う」#モバイルアプリ_findy を視聴しました。

私自身はモバイルアプリ開発の経験はありません。しかし、Webフロントエンドやバックエンドの領域で、それぞれ1年〜1年半ほどリアーキテクチャやリファクタリングの案件に携わってきました。

「言語やプラットフォームは違えど、10年を超えるプロダクトが抱える『負債』の痛みは共通しているのではないか？」という仮説を持って参加しましたが、結果として画面の前で何度も深く頷くことになりました。

2. 資料から見る「二つの正解」

今回のウェビナーでは、対照的な二つのアプローチが示されていました。どちらも凄まじい熱量のリスペクトすべき事例です。

3. 【共感】「有識者不在」というリアーキ最大の壁

ここが今回のウェビナーで最も強く共感し、自分自身の古傷が疼いたポイントです。

ヤフオク!の事例でも「過去のノウハウが失われていた」との言及がありました。また、ZOZOの事例で語られた「リアーキ後の言語の有識者が少ない」という問題。これは領域を問わず、リアーキ案件が抱える最大の難所です。

私が過去に経験したWebフロントのリアーキ案件でも、まさに「現行仕様を知る人がいない」かつ「新技術の有識者もいない」という、出口の見えない二正面作戦でした。現行実装の解読（考古学）と、新しい設計スキルの習得を同時並行で進める過酷さ。この学習コストの増大こそが、プロジェクトを泥沼化させる正体だと再認識しました。

4. OSSと「内製」のジレンマ：技術選定の責任

技術選定の考え方についても、深い学びがありました。

  • 資料からの学び：
    • ヤフオク!の事例では、特定のOSSに依存しすぎないシンプルな仕組み作りが強調されていました。
  • 自分の経験と対比して：
    • 私が経験したバックエンドのリファクタでは、逆に「自社製フレームワーク」への移行を選択していました。
    • OSSへの依存を減らすことで制御性は高まりますが、直面したのは「独自仕様を理解するための圧倒的な学習コスト」でした。
  • 持続可能な技術選定とは：
    • 開発メンバーが業務委託中心である場合、ドキュメントの薄い内製FWのキャッチアップは並大抵ではありません。「OSSに頼らない」ことは、同時に「自分たちが永続的にメンテナンスし、教育し続ける責任を持つ」ことと同義です。誰がどう維持していくかまで含めた選定の重要性を、改めて痛感しました。

5. リアーキ戦略比較図

項目ヤフオク!（フルリプレイス）食べログ（段階的改善）自社バックエンド（内製FW刷新）
主な手法1から作り直すプロダクトを止めない基盤となるFW自体のリプレイス
技術選定Swift 100%への統一柔軟な変更を許容自社製フレームワークの採用
メリット負債の一掃、ビルド時間短縮事業成長を止めない自社に最適化した高い制御性
最大の壁過去のノウハウの消失完了までの長期化内製FWの学習・維持コスト
主な課題リリースのリスクを伴う新旧コードの共存業務委託メンバーへの継承

6. 終わりに

結局、どんなに銀の弾丸を探しても、負債を溜めないための継続的な努力から逃れることはできません。しかし、その「救い方」は今、大きな転換期を迎えていると感じます 。

かつては「泥臭いドキュメント作成」や「人海戦術のリファクタリング」だけが唯一の道でした。しかし今、食べログの事例で語られていた「AIによる自律的なリファクタリング」のように、生成AIという強力な武器が私たちの手にあります 。

今後は、AIに負債を解消させやすい「疎結合な設計」を人間が担い、実際の書き換えやドキュメントの同期はAIが担う。そんな**「AIとの共闘」**こそが、未来の自分たちを救う新しいスタンダードになっていくはずです。

実体験に基づいた貴重な知見を公開してくださった登壇者・運営の皆様に、心からのリスペクトを捧げます。