新規プロダクトにおけるシステムマイグレーションの判断

1. 1 新規プロダクトにおける システムマイグレーションの判断 nacal GMOペパボ ロリポップ‧ムームードメイン事業部 for Gamersチーム 2025.09.24 10年以上続くプロダクトの苦労と知恵 〜運⽤と技術の本⾳、3社がぶっちゃけます〜
2. 2 ⾃⼰紹介 GMOペパボ ロリポップ‧ムームードメイン事業部 for Gamersチーム 2022年 新卒⼊社 nacal • Webアプリケーションエンジニア • フロントエンドが好き • 東京からきました • X: @_nacal
4. ロリポップ！for Gamesについて 4 パルワールドのマルチプレイサーバー需要 Webホスティングサービス運⽤のノウハウ 実質13営業⽇でのリリース サービス⽴ち上げの歴史 2024/1/19 パルワールドリリース 2024/2/9 プロジェクト発⾜ 2024/2/29 無料モニター提供開始
5. ロリポップ！for Gamesについて 5 最速リリースのためのMVP開発 → 機能拡張の際のシステムの構造上の課題が顕著化 我々はこれを、「技術的負債」と呼ぶ 既存のシステム設計のまま機能を拡張していくことは負債を肥⼤化する 1. 我慢してどうにか既存設計に対して機能拡張していく 2. 機能拡張を⽌めて時間を確保してシステムマイグレーションをする 新規プロダクトにおいては機能追加も⼤切なフェーズ サービス安定期の課題
6. 6 技術的負債 𝐓𝐃(𝐒, 𝐞) = 𝙢𝙖𝙭{ 𝐂𝐂(𝐒, 𝐞) - 𝐂𝐂(𝐒’, 𝐞) | 𝐒’ ∈ 𝑺𝒚𝒔(𝐒) } クラウス‧シュミットによる数学的定義 𝐒 システム 𝐞 システムへの変更 𝐂𝐂(𝐒, 𝐞) システムの変更コスト 𝑺𝒚𝒔(𝐒) Sと同⼀機能の別システムの集合 K. Schmid. Technical Debt --- From Metaphor to Engineering Guidance: A Novel Approach based on Cost Estimation. Technical Report 1/2013, SSE 1/13/E, University of Hildesheim, SSE, 2013. （エンジニアリング組織論への招待 第5章 引⽤) 技術的負債は、機能追加時の２つのシステムの⼯数(コスト)の差で表現できる
7. 技術的負債 7 技術的負債の総量とシステムマイグレーションの⼯数を⽐較 クラウス‧シュミットによる数学的定義 追加したい機能：{𝐞₁,𝐞₂} 現在のシステムおける⼯数：𝐂𝐂(𝐒, 𝐞₁) + 𝐂𝐂(𝐒 + 𝐞₁, 𝐞₂) = 30 + 50 = 80⼈⽇ 理想的なシステムにおける⼯数：𝐂𝐂(𝐒’, 𝐞₁) + 𝐂𝐂(𝐒’ + 𝐞₁, 𝐞₂) = 20 + 35 = 55⼈⽇ 技術的負債の総量：80 - 55 = 25⼈⽇ 技術的負債の総量 > システムマイグレーションの⼯数 であれば合理的な判断と⾔える
8. 技術的負債 8 機能拡張の不確実性：実現可能性に関わらず負債として加算される  → やるかもしれない機能拡張がたくさんあるフェーズで    単純な総和と⽐較した場合にほとんどの場合で返済の⼯数の⽅が少なくなる “きっと使う"だろう"という予測で作られた機能は、実際には10％程度しか使われない” 再設計においても使われない機能への考慮による複雑性や⼯数が増幅する 新規プロダクトにおける観点 YAGNI原則
9. 9 技術的負債 𝐓𝐃(𝐒, 𝐄) = ∑[𝐢=𝟏 𝐭𝐨 𝐧]𝐅(𝐞 𝐢 ) 𝐓𝐃(𝐒, 𝐞 𝐢 ) クラウス‧シュミットによる数学的定義の拡張 𝐄 システムへの変更の集合 𝐅(𝐞 𝐢 ) 実現可能性 𝐓𝐃(𝐒, 𝐞 𝐢 ) 変更iに対する技術的負債の総量 機能拡張の不確実性を数式に落とし込む
10. 技術的負債 10 - 不確実性の考慮を⼊れることで、「きっと使うだろう機能」の⼯数への影響を減らす - 𝐅(𝐞 𝐢 )を軸として、再設計も主に実現可能性の⾼い機能に対して実施する 数値的根拠 + 不確実性を考慮した合理的判断 ロリポップ！for Gamersでは結果的にシステムマイグレーションの優位性を⽰して実施 1. 実現可能性の⾼い３つの機能の現在のシステムにおける⼯数算出 2. それぞれに対する理想のシステムの考察 3. 理想のシステムにおける⼯数算出 4. 数式に当てはめて判断 クラウス‧シュミットによる数学的定義の拡張
11. まとめ - 技術的負債は、機能追加時の２つのシステムの⼯数(コスト)の差で表現できる - 機能追加の不確実性が⾼いプロダクトにおいては単純な総和では過剰になる - 不確実性を考慮することで実際の負債により近い値を出す - 数値的根拠 + 不確実性を考慮した合理的判断 - 再設計をする際も不確実性の⾼いものを考慮しすぎないようにする 11
12. 12 Thank you!