技術的負債を覗く時、技術的負債もまたこちらを覗いているかもしれない話

はじめまして。8月よりAndroidアプリエンジニアとしてスペースマーケットに入社しました毛塚です。以後、宜しくお願いします。

これまでやってきたこと

ガラケー時代からFlashなどのモバイルコンテンツメインにデザイナー、ディレクター、マネージャー、エンジニアとよくわからないキャリアを歩んできました。色んなところをつまみ食いしてましたがずっとモバイル関係の仕事をしてます。また、ここ最近は割とエンジニア専任でやらせてもらってます。

これからやろうとしていること

さて、早速ですがタイトルの回収に向かいたいと思います。僕は入社してすぐにAndroidアプリの技術的負債を解消する為の方策を練ってきました。現在、スペースマーケットのAndroidアプリは

・AndroidArchitectureComponents(AAC)が導入されていない
・レイヤーの分離が不完全
・ファットなActivityやFragmentが散見
・処理負荷が高い実装がされている箇所がある

といった状態です。秘伝のタレのように継ぎ足しを繰り返してきたようなコードで書き方にあまり統一性がありませんでした。とは言え、全てのコードはKotlinで書き直されており、DataBindingも導入されていて「どこから手を付けていいか分からないよトホホ」状態ではなく、「もっとよくできそう」でいい具合にリファクタ欲を唆る状態です。また、コード品質がアプリの挙動に悪い影響を与えているところもあり、これらの技術的負債は早めに返済しないとより良いサービスをユーザーに提供できません。

弊社のアプリはAndroidとiOSで提供されておりますが、最近の日本のスマホシェア率と比べるとAndroidアプリの利用率は結構低めです。もっと上げられるポテンシャルはあるハズ。この数字を上げる為にも負債は返済していかないといけないでしょう。

MMD研究所

そういえばここ数年で日本でもだいぶAndroidが盛り返してきましたね。感慨深いです。

技術的負債

ところで技術的負債、いやな言葉ですね。負債ですよ。負債。負けてるんですよ。負ってるんですよ。こんないやな言葉、誰が考えたんでしょう。というわけで調べてきました。いかがでしたかブログ風ですみません。 

1992年にアメリカのエンジニアであるウォード・カニンガム氏が言及したのが最初と言われているようです。技術的負債という言葉がここまで(本人の意図した意味とは異なって)バズワードとなったのはエンジニア以外にも概念が捉えやすかった事に起因しているようです。しかし、技術的負債という言葉、エンジニア(というか一般的な方々)と経営者とでは捉え方が大きく異なるらしく、僕をはじめとする一般的な感覚の「負債は返済しないといけない」に対して経営層の方々は「借りても利子が大して付かないからばんばん借りよう」という考え方の違いがあるようです。僕はこれを知って経営者はサイコパスが多い、というどこかで聞いた言葉を思い出しましたが全然違う話で「借金」と捉えるか「資本」と捉えるかの立場の違いから生まれる齟齬であり、今日まで色んなところで解釈の違いから生まれる数々の問題を引き起こしてきました。

技術的負債を解消する

負債の解消問題は僕も過去何度も直面しておりまして、非常に頭の痛い問題です。というのも「立ち止まる」事に対しての特にビジネス面での説明が非常に難しいからです。

・ビジネス上のメリットが見えない
・新機能の方が重要だから後回しにして
・ユーザーが離れちゃう
・今もう問題なく動いてるんだから意味なくない？
・なにそれおいしいの？

みたいなことを言われながら「既に動いているものに新たなバグを生み出すリスク」を犯しつつ問題を解きほぐす作業は非常に骨が折れます。まさに深淵とも言えるコードの闇を頑張って覗こうとしても周囲の理解を得られないととても孤独な戦いとなってしまい、やがて深淵へと自らも呑まれてしまいます。・・・もういいや、と。あくまでこれは僕の個人的解釈ですがこういう状態こそを負債と呼ぶにふさわしいと考えています。

ですのでリファクタリングの提案をする時は内心、少しだけ気が重かったのは事実です。入念に準備していかないと論破されてしまいます。また、気付くとリファクタそのものが目的になってしまうのでそこも注意して考えます。具体的には何をしたいのか？

・AACの導入
・Daggerの導入
・Navigationの導入
・アーキテクチャの導入
・RxJava or Coroutineの導入
・マルチモジュールの導入

です。これらを実際のコードに書きました。そして、

・変更に強くなるので今よりもっと早く新機能を導入しやすくなる
・手離れがよくなり人とコードが疎結合になって開発スピードが人に依存しにくくなる
・保守性が上がり、バグが見つけやすくなる
・今後のサービスグロースの為の土台作り

などの理由も添えながら提案しました。
するとどうでしょう。あっさりOKが出ました。やったー。

よくよく考えてみたら負債解消Weekの実施や緊急性の高いバグ対応を当番制で実行されている会社なのでこの辺の理解はとてもされやすい環境だったのでした。特に弊社CPOの三重野さんのようなアプリエンジニアでもある方がいてくれるのはなかなかないのでとても心強いです。その中で少し論点になった部分にフォーカスしてみます。

アーキテクチャをどうするか？

これは過去の経験からFluxにしました。Googleの推奨であるMVVMとどちらにするかに迷いがありましたが、前職でFlux導入経験があった事、MVVMだとViewModelの解釈揺れが起こりがち且つファットになりがちな事を考慮してFluxで行くことに決めました。

RxJava or Coroutine

Coroutine FlowでほぼほぼRxJavaに近しい書き方ができるのでCoroutineを選択しました。これにはiOSにもRxSwiftを導入してRxJavaとで合わせるべきでは？の意見もありましたが、

・iOSにもRxSwiftか標準のCombineの選択肢があり、将来的にどちらがスタンダードになるか分からないこと
・主な使い方がよくあるAPIとの繋ぎの非同期処理メインであること
・現時点でiOS/Androidで整合性を取るような事は殆ど行ってないからそこまで考慮しなくてもよい
・単純にCoroutine Flowで書いてみたい

などの理由でCoroutineを選択しました。

さいごに

とは言え、長く大変な作業になるのは間違いなく、そしてもちろんユーザーへの新しい価値を提供する事へのバランスも保ちながら進めないといけません。少しずつでも負債を解消し、より多くのユーザーに楽しくサービスを利用して頂けるようにプロダクトをどんどん磨いていきたいと思っています。