こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。(なお、お昼休みに聴いていた都合上、最後の2つのLT(伊東さんと黒田さん)を聞くことができていません)
会の概要
以下、イベントページから引用です。
技術的負債は、ある程度成長したサービスであれば抱えるのは少なからず起きてしまいます。いずれは向き合わなければいけない負債に対してどこからどのように向き合うのが良いのか。
本イベントでは、モバイル開発における技術的負債の解消に向き合い乗り越えた5名の方をお招きしてLTをしていただき、参加者の方には明日からの技術的負債に対しての向き合い方に活きるTIpsを持ち帰ってもらうことを目指します。
会の様子
モバイルアプリにおける技術的負債とは？
最初に、380,000step×100画面以上のモバイルアプリケーション(食べログアプリ)の中で、技術的負債をどのようにして定義しているのか？という話を太田さんから聴いていきました。
まず、食べログアプリの中ではマーティン・ファウラーが言う「意図的でない」負債(=学びがあったタイミングで生じた負債)が多いと太田さんは考えているということで、技術的負債が見つかる事自体はどちらかというとポジティブに捉えているという話がありました。
とはいえ負債は負債であり、大きくなってしまうと返済が指数関数的に難しくなるのは間違いないので、画面ごとにミニリライトするなど、小さなリリースを繰り返しているということです。
また、モバイルアプリ特有の技術的負債としては、ライブラリのアップデートがめちゃくちゃ早いことや環境起因の負債*1が挙げられるということで、技術動向のキャッチアップを選定観点(自分たちの課題解決とのマッチング度合い、移行容易性...)で意識的に実施したり勉強会を定期的に実施したりしているということでした。
技術的負債解消に向けて最初にやるべきこと
続いて、ニュースピックスの金子さんから、10年以上稼働しているモバイルアプリの技術的負債を解消した際、作り直しをする前にやって良かったことの話を聴いていきました。
具体的には、コードをレイヤー化してマルチモジュール化して依存方向を強制化することとユニットテストを書くことを強制する環境が重要だということで、以下にそれぞれの詳細を記載します。
コードをレイヤー化してマルチモジュール化して依存方向を強制化する
マルチモジュール化することで、古いコードを使えないようにしたいのが大きな理由ということでした。(どうしても古いコードを使わないといけない場合はAdapterパターンを使う)
他にも、マルチモジュール化することで神クラスが作られにくくなるといった効果もあったそうです。
ユニットテストを書くことを強制する
テスタブルで可読性の高い構成にするために、ユニットテストを書くことを矯正しているということでした。
ただしモバイルアプリの場合は、あまりにも単純なロジックに対してテストを書くケースが出てくるので、そういう部分は例外的にテストを書かないようにしているということです。
iOSアプリの大きな技術的負債に立ち向かう
次に、Chatworkの福井さんから話がありました。以下の発表のサマリ版&最新版ということです。
Chatworkにおける技術的課題としては大きく以下の5つがあるということでした。(上の記事であった「Objective-Cのコードが残っている」という課題は現在解消済み)
そこでリアーキテクチャを考えたそうですが、チームの中で認知負荷の増大と新機能開発の優先着手(リアーキテクチャが進まない)が発生してしまったということで、Team Topologiesの考え方を活用して責任分割を進めたそうです。
結果、リアーキテクチャが進むようになってきた一方で、プラットフォームチーム作業の肥大化や自己組織化していないストリームアラインドチームがいるとプラットフォームチームが認知負荷をより高めるという課題も出てきたそうで、このあたりに対しては現在進行系で向き合っているということです。
会全体を通した感想
すべてのLTを聞くことができなかったのは残念でしたが、どのLTも内部のアーキテクチャやチーム編成、課題といったところをあまりぼかすことなく伝えてくれた印象があって、勉強になりました。
特にモバイルアプリ特有の...という視点で話が聞けたのはよかったです。
*1:TargetSdkVersionの更新やPlay Billing Library
