1. はじめに
技術本部 Sansan Engineering Unit Mobile Application Group でEM（エンジニアマネジャー）をしている赤城です。私たちのチームは、法人向け営業DXサービス「Sansan」のモバイルアプリ開発を主に担当しています。
今回は、Mobileチーム「技術負債返済」をテーマとしたTech Blogリレー企画の第二弾となります。
Sansanモバイルアプリは初期リリースから約10年が経過しており、継続的に機能拡張を行いながらサービスを提供し続けています。この10年間で、モバイル開発における技術トレンドは大きく変遷してきました。その結果、いわゆる「技術的負債」と呼ばれるコードが、どうしても蓄積してしまっています。
また、モバイルアプリの運用においては、毎年アップデートされる言語・OSの破壊的変更への対応などのリスクに対応する必要もあります。
機能追加開発も事業を加速させるためには間違いなく重要です。
一方、「長期的に安定してサービスを提供し続ける」という観点では、このような技術的負債やリスクにも適切に対処をし続ける必要があります。なぜなら、先送りにした問題が忘れた頃に顕在化し、事業継続において致命的な影響を及ぼす可能性があるためです。
そこで、Sansan Mobile開発チームでは、直近半年間「負債・リスクに適切に対処していく運用」にトライしてきました。今回はその取り組みについて紹介します。
2. 用語整理と前提条件
本記事で扱う用語を整理しておきます。
技術的負債（Technical Debt）
Ward Cunningham氏が1992年に提唱した「技術的負債」の概念は、端的には「機能の追加を優先し、リファクタリングに正しく時間を割かなかった結果、将来的に開発スピードが落ちてしまう状態」を借金に例えたものと言われています1。
これは特に長期間運用されるプロダクトにおいて避けられない課題です。
10年という期間でモバイルアプリにおけるライブラリや設計のトレンドが変遷する中、当時のベストプラクティスが現在では非効率となっているケースの比重が大きくなっています。
技術的リスクの定義
「リスク」は文脈により意味合いが変わりますが、一般的には「将来のいずれかの時において何か悪い事象が起こる可能性」と言われています。2
私たちの運用の中では、「技術的リスク」を、「顕在化した場合に問題が発生し、解決には技術対応が必要な可能性」と定義しています。
具体的に、次のような事例です。
- App Store / Google Play Storeのポリシー改定による審査Reject
- AndroidにおけるEdge To Edge対応3や、iOSにおけるPrivacy Manifest対応4などに代表される、OSアップデートにあたる必須対応化の可能性
- Encrypted SharedPreferences5やFirebase Dynamic Links6に代表されるエコシステムのサポート終了可能性
- OWASP7で指摘されているような、セキュリティ対策漏れによる問題発生の可能性
これらは技術的負債と異なり、対応せずにリスクが顕在化してしまうと、サービス提供に直接影響が出る という特徴があります。
3. 技術的負債・リスクへ対処する事の難しさ
このような技術的負債・リスクに対処するに当たり、さまざまな難しさがあります。
組織間での、視点の違いによる難しさ
特に、規模が一定以上の組織でこのような問題に対する対処を難しくさせているのは、いわゆる「群盲象を評す」8問題です。
例えば、アーキテクチャに関心が強いエンジニアであれば、現状の設計がレガシーなまま放置されている問題を重要視するかと思います。一方、パフォーマンスに関心が強いエンジニアは、おそらく計算量を軽視した実装が散見されている点を問題視するでしょう。
また、モバイルにおいては、iOS/Androidそれぞれのエンジニアがそれぞれの担当プラットフォームの領域に最も強く関心を寄せているかと思います。
私のようなエンジニアマネジャーであれば、現在のコードの状況が採用やビジネスにどのような影響を与えるか、俯瞰した観点での問題に着目しがちなど、ロールによっても観点は異なってくるでしょう。
それぞれの視点は部分的には正しいものの、全員の意見を等しく反映してすべての問題に対処することは、エンジニアのリソースにも限りがある点から、現実的ではありません。
課題分析の難しさ
このような問題へ対処する際は、課題を適切に分解することの難しさもあります。
例えば、「あるアーキテクチャがレガシーで負債となっているため、別のアーキテクチャに移行すべき」という問題提起をしたとします。
この場合の「レガシー」という言葉には裏には、さまざまな背景がある可能性があります。
- アーキテクチャの前提となるライブラリがEOLを迎える見込み
- 開発者コミュニティで「開発しづらい」という評価が多数で、採用に不利
- 処理の流れが追いづらく、開発メンバーがコードを読みづらいと感じることが多い
どの背景なのかに応じて取るべき手段や重要度も変わってきます。ライブラリがEOLとなってしまう事が問題なのであれば、その点に特化した解決策も考え、比較検討の必要があるでしょう。
しかし、「別のアーキテクチャに移行すべき」という解決策も同時に出してしまうと、どうしても「移行すべきか否か」という議論になり、適切な解決策を選択するチャンスを逃してしまう可能性があります。
この例は単純なケースですが、実際の開発現場においては、この数倍も複雑な事象に関して課題を深掘りしきれないまま解決策を検討してしまい、選択を誤ることがどうしてもあるかと思います。
難しさに向き合い、適切な対処をしていくために
チーム・コードベースともに大規模なSansan Mobileアプリにおいては、これまで述べたような難しさを乗り越え、問題に取り組んでいく必要がありました。
誰か一人のみがリードするのではなく、「事業に対して成果を出すために技術負債・リスクに向き合う」という共通目的のもと、全員の意見を吸い上げて議論し、組織として適切にリソースをフォーカスする意思決定が必要となると考えて、運用をし始めました。
4. 技術的負債・リスクの体系的な整理と優先順位付け
背景と課題の顕在化
2025年4月頃の状況としてはKotlin Multiplatformの導入9や、大きな新規機能開発が一段落しており、一定蓄積した負債・リスクへの対処に向き合う時間ができたフェーズでした。また、新規メンバーのジョインも相次いでおり、スケールした組織において、どう統制を取りつつ成果を出していくかも課題でした。
ジョインしたエンジニアからのフィードバックや、元々問題として話されていたものを軽く列挙するだけでも、
- LocalDB (Realm) の設計上の課題
- セキュリティ対応の必要性
- レガシーライブラリへの依存
- ビルド速度の低下
とさまざまな問題があり、大量に課題Backlogに挙げられているものの、全体の総量を把握し切れていない状況でした。
しかし、巨大なコードベースであるが故に、すべての問題を完全に解決しようとすると膨大な工数が必要となることは見積もりせずとも明らかでした。
そのため、まずは大量の問題の中から、取り組むべき重要な問題を見定めていく必要がありました。
技術的負債・リスクの網羅的な洗い出し
開発メンバーの@elu697さんと、@eaglesakura さんに、すべての技術観点でのリスク・負債を網羅的に列挙してもらいました。
ただ列挙するだけではなく、前章で述べた「課題分析の難しさ」によって誤った選択をしないよう、各問題すべてに対して次の軸での評価を言語化しました。
- 問題の内容: 具体的にどのような技術的課題が存在するか
- 顕在化した場合の影響: サービス停止、開発速度低下、セキュリティリスク等
- 影響の定量化: 可能な限り金額ベースでの影響度を算出
- 対応期限: 外部要因による期限の有無
- 推定工数: 解決に必要なエンジニア工数
特に重要視したのは、できる限り定量的に顕在化時のインパクトを算出するという点です。
これにより、エンジニア以外のステークホルダーとも共通言語で議論して、必要に応じてダイナミックにコストをかける判断を行えるような土台を作りました。
その結果、約50個の技術的負債・リスク項目がリスト化されました。これらの負債・リスクを評価するのにはかなり労力がかかりましたが、このような問題分析を怠ると後々大きな問題になると考え、時間をかけてすべての負債・リスクに対して漏れなく言語化を行いました。
負債・リスクに対する評価と優先順位付けを行う
承認者としてEMとアーキテクトを配置し、開発メンバー全員で議論しながら最終的な評価を決定していきました。
ここで重要だったのは、全員の合意を目指さないという割り切りです。全員の合意を目指すと、合意形成に膨大な時間がかかり、意思決定のスピードが著しく低下してしまうと考えました。そのため、最終的な意思決定権限を承認者に集約し、スピード感を優先しました。
すべての負債に優先度を付け、プロダクトの機能開発と同じバックログ上で優先順位を管理しました。その上で、技術改善のBacklog Itemとして起票し、PdM（プロダクトマネージャー）の合意を得た上で開発に着手していきました。
推進体制
各技術的負債・リスクにはオーナーを設定し、責任を持って取り組む体制を構築しました。
例えば、前回のブログリレー記事である諦めかけた技術負債返済を3カ月で完遂させた2つの決断 – Epoxy48個削除の軌跡 – Sansan Tech Blogで取り上げたEpoxy・ビルド速度に関する問題は、記事を書いた @kilalabu さんがオーナーとなって推進してくれました。
各負債・リスクの対処は、その問題の規模から長期化することも少なくなく、何も対策しないでいると他業務に押されて進捗が止まってしまうことも珍しくありません。
そこで、問題解決を推進するに当たり、OKR10の考え方を参考にした推進システムを構築し、運用しました。特に効果のあった点は下記2つです。
定例の進捗確認のMTGを行う
進捗確認MTGの場で、定期的なレビューと現状の進捗を報告してもらいました。進捗していないものがあれば対処を促したり、他業務の都合を鑑みて一時凍結を判断するなど調整し、進捗を推進させました。
また、この定例の場においては状況の変化に応じた優先度の組み替え判断も行なっています。例えば、メンバーの異動が発生した時は、優先度を再判断した上で引き継いで進捗させるか、凍結させるかの判断をしていました。
必ずすべての技術的負債・リスクに対して、SMARTな目標設定11を設定する
SMARTの中でも、特に、「測定可能であること（Measurable）」、「期限を必ず設ける（Time-bound）」という点は厳守するようにしました。
進捗の実態が掴めなかったり、期限が設けられていないと、想定より遅れているのか判断がつかず、進捗が出ていない際の適切な支援ができません。
結果、問題対処が終わり切らないまま、差し込みの重要な新規機能開発により頓挫してしまう事態になることを防ぎました。
これにより、個々人がオーナーシップを持ち、中途半端ではなく最後まで責任を持ってやり切る体制を目指しています。
5. まとめ
Sansanモバイルアプリにおける技術的負債・リスク管理の実践について紹介しました。
それぞれの技術負債・リスクにどの程度リソースを割けば良いのかの判断は、モバイルアプリ開発を深く知るエンジニアの知識・経験はもちろん、プロダクトや事業・採用などさまざまな観点を考慮しなければなりません。
過剰なコスト投下をしてしまうと、事業成長のブレーキとなり機会損失を発生させますし、過小な対応では先送りにした問題がいつか顕在化する可能性もあります。
「最適な選択をし続ける」ことの難しさに向き合い続けていくことで、今後もプロダクトを成長させ続けていきます！
本記事で紹介した取り組みが、同様の課題に直面している組織の参考になれば幸いです。
Sansan / Eightのモバイルアプリ開発を進めていく仲間を募集中です！ 選考評価なしで現場のエンジニアのリアルな声が聞けるカジュアル面談もありますので、ご興味のある方はぜひ面談だけでもお越しいただけたら幸いです。
open.talentio.com
open.talentio.com
