駅メモ！開発チームエンジニアの id:yokoi0803 です。
駅メモ！チームで運用している「駅メモ！ - ステーションメモリーズ！-」は今年で 8 周年を迎えました。
スマートフォン向けゲームとしては長く続くサービスとなりましたが、長期運用に伴ってそのコードベースは大きく、複雑になり、保守性の面での課題が段々と無視できなくなってきています。
しかし課題だと認識されているにも関わらず、その改善、つまりリファクタリングを行う機会は少なく、結果としてコードの複雑さは増す一方になっています。
この記事では、上記の問題はなぜ起きているのか、現状を再認識し、問題を解決するために考えたことを記述します。 直接、技術に関わる話はありませんが、読んでみて、自分のチームやプロダクトはどうなっているのか、思い返すきっかけになれば幸いです。
開発チームの構成
後の話を理解しやすくするため、まず開発チームの構成について軽く説明します。
開発チームの主な役割は駅メモ！内のコンテンツであるでんこやイベントの開発、その他機能の追加や修正です。 技術職(エンジニア)と非技術職(ディレクター、マネージャー)で構成され、チームで行うタスクはほとんど非技術職が主体となって決定しています。 エンジニアはそれらタスクのうち、主にコーディングが関わる部分を受け持っています。
現状の整理
記事の冒頭で述べた通り、当プロダクトのコードは保守性の面で課題を抱えています。 今回は保守性に影響を与える要素として「技術的負債」に焦点を当て、現状を整理しました。
技術的負債の発生
開発チームの業務の忙しさには年間を通して波があります。 繁忙期にはエンジニアもほぼフル稼働することになり、開発における余剰リソースがない状態になります。 そのような状態でコードの複雑性と納期が相まって、どうしても「その場しのぎ」な実装にせざるを得ないことがあります。
また、当時最善だと思った実装だとしても、機能追加などでコードが変化していくにつれて最善ではなくなっていたというケースもあります。
技術的負債の解消
繁忙期がある一方で閑散期もあり、このタイミングでは業務の改善をチームで積極的に取り組んでいます。 ただし、先述したようにチームのタスクは非技術職が主体となって決定するため、どうしても非技術職の視点から見える範囲の作業効率化などが優先されてしまいます。 エンジニアとしても、技術的負債があるからと言って直ちに問題があるわけではないため、その解消をすることの優先度を下げてしまっています。
ここまでのように現状をまとめると、技術的負債は溜まっていく一方になっていることが明らかになりました。
問題はどこか
技術的負債が生まれることはビジネス上、避けられないものです。その前提で考えると、生まれた負債の解消、つまりリファクタリングをする機会を作っていない事が問題でしょう。 ではなぜ機会がないのかというと、技術的負債が溜まっていることを、非技術職を含むチーム全体が課題として認識していないからだと考えました。
チームとしての課題にするには
コードベースの詳細な事情はエンジニアしか知り得ませんし、非技術職に対してそのまま説明しても成果が目に見えるような課題と優先度比較をできず、チームとしての課題に上げることは難しいです。ですから、お互いにとって共通の概念であるプロダクトを基準にしてみます。
このままだとどのようなリスクがあるか、リファクタリングの意義は何か、考えてみました。
このまま技術的負債が溜まるとどうなるか
- 複雑さ故に実装速度が下がり、バグの混入率は上がる
- 実装中、負債にぶつかる可能性が高くなり、その解消をしなければ作業が進められない場合は想定外の工数がかかる
- 上記 2 点を考慮すると、作業見積もりは不正確、あるいはマージンを取らざるを得なくなる
プロダクトが抱えるリスク
- 実装速度が下がったり、見積もりが不正確になるため、ユーザに届けられる価値が減少する
- 不具合の発生率が増加する
リファクタリングの意義については、「プロダクトが抱えるリスク」の解消になります。
これで一応、技術的負債の解消をチーム内の他の課題と同列に扱う根拠は得られました。
問題の解決に向けて
技術的負債が溜まっていることは課題であり、リファクタリングの意義についても明らかになりましたが、まだチーム内の成果が目に見えるものと優先度比較をすることは難しいです。 何がどのくらい良くなるのか、定量的に評価ができないからです。
とはいえ、やる意味があることは明らかですし、やってみることで効果を計測できるようになるという考えのもと、弊チームでは定期的にリファクタリングを集中的に行う時間を設けることを考えています。
また、リファクタリングの定量的な評価については別軸で動きがありまして、つい先日の記事にもなっていますので、興味があればそちらも是非読んでみてください。
まとめ
- 弊チームでは現状、技術的負債を解消する機会が存在せず、溜まっていく一方になっている
- なぜなら、技術的負債の解消が、チーム内の他の課題と同じステージに立てていないから
- 非技術職では事情を知り得ないので、エンジニアが問題を認識し、それを提起しなければ状況は変わらない
- 技術的負債が溜まることでプロダクトがリスクを抱えることになる、という職種関係ない概念で認識を合わせるべき
- とりあえず、リファクタリングの時間を取ってみよう
