【モンスト開発チームに聞いた】常時リファクタリングにレビュー2人以上。巨大プロダクトを成長させ続ける秘訣

2013年にリリースされたMIXIのスマホゲーム「モンスターストライク（通称：モンスト）」。2023年6月時点で世界累計利用者数が6,000万人を突破するなど、日本を代表するスマホゲームとして世界中で愛されています。

そんなモンストの開発チームでは、新規開発とリファクタリングを、同じチームで日常的に行っているそう。2023年で10周年を迎えるプロダクトにおいて、月1回のペースでバージョンアップを実施しながら、リファクタリングも同時に進める秘訣について、モンスト運営部でマネージャーを務める原田さんと王さんに聞きました。

• keyboard_arrow_down 息をするようにリファクタリングに取り組むモンスト開発チーム
• keyboard_arrow_down コードレビューは必ず2人以上。リソースが厳しくても、レビュープロセスやリファクタリングは削らない
• keyboard_arrow_down 失敗は個人の責任にしない。詫びオーブを恐れずリリースを重ねる
• keyboard_arrow_down リファクタリングに向き合い続けると、成功も失敗もチーム全体のナレッジにできる

——モンストといえば多くのユーザーに愛されるゲームです。エンジニアの皆さんは、頻繁に行われるコラボイベントへの対応や新機能開発など、忙しい日々を過ごされている中でも、リファクタリングに積極的だと聞きました。

原田：そうですね。月1回のペースでアップデートがあるので、それに備えた新規開発とリファクタリングを一緒に進めています。

メンバーそれぞれが気になった点を見つけたり、将来的に問題になりそうだと感じた点を持ち寄ったりして、みんなで対策を考え、手の空いた人が率先して改善していくやり方を採っていますね。

王：モンスト開発組織全体の文化として、「リファクタリングをするのは当たり前」という価値観が浸透しています。各メンバーが自分の開発タスクを進める中で、既存のコードを変えたほうがいいと思ったらその場で直しておく、といった進め方をとることもよくありますよ。

——リファクタリングというのは、近い将来、運営上支障が出ることが明らかになってから、ようやく重い腰を上げて取り組むものだと思っていました。

原田：受け身な開発文化だったり、開発リソースが少な過ぎたりすると、そういう捉え方になるかもしれませんが、少なくともうちには当てはまりません。

もちろん、私たちマネージャーが優先順位を決めてメンバーをアサインすることもありますが、メンバー自身が必要だと思う改善を、自らの意志で行うのが基本。むしろ忙しいからこそ、日常的にリファクタリングに取り組んでいる面があるんです。

増改築が簡単だからといって、積み木細工で組み上げた家に長く住み続けられないでしょう。それと同じで、「とりあえず動けばいい」という基準でつくられたシステムを、長く使い続けることはできません。特にモンストは大規模なユーザーを抱えており、複雑な計算や処理が多く、リリースサイクルも早い。小さな不都合でも、改善せずに放置してしまうと、その反動がものすごく大きくなって、どんどん忙しくなるんです。

実際、10万行以上におよぶモンストのコードのうち、リリース当時から残っているコードは数パーセントあるかどうか。モンスト開発チームにとってリファクタリングは日常的な取り組みであり、呼吸のような自然かつ必要不可欠なものです。逆にいえばそれぐらいの感覚でいないと、ユーザーの皆さんに喜んでいただけるサービスが提供できないプロダクトでもあるんです。

——息を吸うようにリファクタリングされていると？

王：はい。開発当時はベストな選択だとしても、時間が経てばベストではなくなっていくのが世の常ですからね。

それにモンストは、ユーザーの皆さんにゲームを楽しんでいただくために、レスポンススピードの速さ、処理の正確さを保証した上で、定期的なイベント開催や新キャラクター追加などの新規開発も必要不可欠です。そんな中でリファクタリングを怠れば、レスポンスが遅くなったり、バグが多発したり、リリースペースが落ちたりして、ユーザーに迷惑をかけてしまいますし、事業としても大ダメージを受けてしまいます。だからこそ、問題が顕在化する前に改善しようという開発文化が定着したのだと思います。

原田：自分が書いたコードでも、他のメンバーが書いたコードでも、さらによくする余地があるならば改善するに越したことはない、というのがモンスト開発チームの考え方。シンプルで美しいコードはプロダクトの保守性を高めてくれますし、サービスの安定と成長にも寄与します。そう考えると率先してやらない理由はないというのが、私たちのリファクタリングに対する捉え方です。

——開発組織にとって、新規開発とリファクタリングを並行して進めるメリットはなんですか？

王：やればやるほど、エンジニアが書くコードの質が上がるという利点はあるでしょうね。かつて自分がいいと思って書いたコードを手直しすると、おのずと自分のコードを客観的、批判的に見て考える力が養われます。

一般に、リファクタリングはプロダクトをよくするために行うものとされていますが、実はエンジニアの経験値を上げ、自分がそのコードを書いた当時から今に至るまでの間に、どれだけ成長できたかを感じられる取り組みでもあるんです。

原田：私たちのチームでは、機能を実装する際には必ず2人以上にレビューしてもらっていて、常に意見を交わしながらコードを改善しています。レビューを重ねる習慣のおかげで、指摘されることに抵抗がなくなりますし、「自分の正解が絶対の正解ではない」という認識もできています。それもリファクタリングに前向きな理由のひとつでしょうね。

溜まりに溜まった技術的負債を一気に解消するより、新規開発の延長で改善し続けるほうが、リスクを最小限に抑え、ユーザーにもビジネスにもいい影響をもたらすと信じています。

——新規開発のたびにリファクタリングもして、レビューも2人以上回して、となると、リソースが足りなくなりそうですが…

王：リソース配分が厳しくなっても、レビューを削ったりリファクタリングを諦めたりしないために、配置を工夫しています。

リファクタリングは得てして予期せぬ何かが発生するものですから、最初にスケジュールを決める時点で、バッファをしっかりとっています。それでもリソースが足りなくなりそうなときは、まずチーム全体で手が空いている人と詰まっている人のタスクを調整します。調整しきれないときは、僕たちマネージャーが開発に入ります。めったにないことではありますが、それでもどうしても終わらないときは、企画の皆さんに「リリースを遅らせてください」と頭を下げに行きます（笑）。

リリースに間に合わせるためにと、リファクタリングやレビューを削ったせいでコードの品質が下がってしまっては、リリース後にはユーザーにも開発組織にもマイナスです。ユーザーによりよい体験を提供し続けるために、「やるべきことは削らない、やりきる」が最優先ですね。

——レビューを重ねるうちに、議論が二転三転することもありそうだと感じます。どんなコードなら「良いコード」だといえるのか、決まっている部分もあるんでしょうか？

王：「良いコード」の定義はその時々によって大きく変わるので特に決めていないのですが、「絶対にやってはいけない書き方」は決まっています。これだけは守ってね、という形でドキュメントに残して周知徹底していますね。

原田：レビューを複数人で回し続けることで、チーム全体で共通認識ができている部分もあると思いますよ。

意見が分かれてなかなかおさまらないときもありますが、「より読みやすく、無駄のないコードを目指したい」という思いは全員共通していますし、それに向かってレビューを重ねています。その結果たどり着いたコードが、モンスト開発チームにとっての「良いコード」になっていくんだと思います。

——マネージャーであるお二人にとって、「良いリファクタリング」とは何でしょうか？

原田：「良いリファクタリング」を定義するのは難しいですね。私自身は「同じ目的を果たすコードを、より便利につくり変えること」だと思っています。

例えば、径が変えられないモンキーレンチがあるとしましょう。そのモンキーレンチの「ボルトを回す」という用途を守ったまま、径を変えられるようにすることは、良いリファクタリングだと思います。では、そのモンキーレンチで釘を打ち始めたりしたら？　全く打てなくはないかもしれないけれど、釘を打つのに適しているのはトンカチやハンマーであって、わざわざモンキーレンチで釘を打つ必要はありませんよね。

そういった「本来の用途から逸脱せず、より便利にする」というプラスな変化を起こすことが、リファクタリングにおいては大切だと思っています。

王：たしかに、「できなくはないが、適切な用途ではない」は望ましくないですね。あと、「物量を減らし、汎用性を高める」という側面もあると思います。

同じモンキーレンチの例えだと、径が変えられないなら、回したいボルトのサイズに対応するレンチが、各サイズ1つずつ必要です。でも、径を自在に変えられるモンキーレンチがあれば、その1本だけでさまざまなサイズのボルトを回せるようになります。

適切な用途を守ったまま、より便利につくり変えて汎用性を高めることで、物量を減らせる。これがソースコードでできれば、バグを起こしにくく、拡張性があり、読みやすいコードにつながっていくんだと思います。

——具体的に、どのようなプロセスでリファクタリングを行っているのでしょうか？

原田：簡単な改善であれば、エンジニアの手が空いているときに、気になる部分を都度手直しするようにしています。工数がかかるものは、年末年始や周年イベントなど、トラフィックが確実に増大するタイミングに合わせて実施することが多いですね。データベースにかかる負荷を軽減する対策を施したり、使用頻度が高い機能を切り分けモジュール化しておいたりするなど、エラーが起こったときの影響が大きいものから優先的に取り組むようにしています。

王：ほかには、メンバー自身の気づきだけでは拾えないところをチェックするために、ボトルネック分析をやっています。アクセスに対してレスポンスが遅くなっている部分をデータから読み解いたり、コードが複雑化、肥大化しがちな部分をあらかじめ把握しておいたりと、定期的に行っています。リファクタリングのレベル感や難易度によってプロセスは千差万別ですが、現場のエンジニアが主導して行う点は同じです。

——モンストの人気と歴史を考えると、リファクタリングでソースコードを書き換えるのも怖くなってしまいそうな気がします。

原田：モンストのユーザー数の多さやトラフィックの大きさが、リファクタリングの原動力になっているのは確かですが、実は日々の業務のなかではあまり意識していません。

どんなプロダクトであれ、サービスの質を高めるには常にコードを保守していかなければなりませんし、あるべき保守の姿を実現したいならリファクタリングは当然やるべきです。そうした認識を開発チーム全員で共有しているので「気が重い」「やりたくない」といった、後ろ向きな気持ちになりにくいのかもしれません。

——リファクタリングにまつわって失敗した経験があればお聞かせください。

原田：モンストが立ち上がって間もなくのことです。ミッションクリア報酬のロジックをリファクタリングした際にミスがあり、一回しか受け取れないはずの報酬を何度も受け取れてしまうトラブルを起こしてしまったことがありました。かなりレアな条件が揃わなければ起こらない性質のバグだったため、テストが行き届かなかったのが原因です。

ユーザーデータを毀損するようなバグではなかったのが不幸中の幸いでしたが、バグによる差を埋めるために、全ユーザーに33個ずつ詫びオーブを配りました。

――オーブ33個ですか…。損失額を計算すると肝が冷えます。

原田：当時は「一生かかっても到底ペイできないくらいの損失を出してしまった」という申し訳なさでいっぱいでした。でも、ありがたいことに、責められたり、責任を問われたりするようなことはなかったですね。

私たちには「失敗を個人の責にせず、チーム全体の教訓として共有する」という文化があるんです。ミスを犯してしまった人に責任を負わせるような文化だと、アンタッチャブルなコードが増えてしまったり、理に適った行動や発言が阻害されたりしかねませんから。

当時のこの経験のおかげで、マネージャーとなった今でも、失敗を恐れず開発を進めるかじ取りができているように思います。

王：もちろんバグやミスを出さないように準備を整えることも大事ですし、問題発生時の迅速な対応、再発防止策の徹底が大事なのはいうまでもありません。ただ、失敗や障害を過度に恐れてチャレンジしなくなることのほうが、ミスを防ぐよりもはるかに大きな問題といえます。

モンストの初代プロデューサーで、現社長の木村（弘毅氏）は、約10年前、モンストを開発し始めたころから「失敗を恐れずどんどんリリースしていこう」という方針を打ち出していて。経営陣やビジネス側のメンバーはもちろん、品質管理をリードしているQA部門のメンバーを含め、エンジニアのチャレンジが優れたプロダクトを生む原動力であることをよく理解してくださっています。リファクタリングはエンジニアだけで行うものというより、関係者全員で取り組むべきものなんです。

——エンジニアにとって、リファクタリングのやりがいは何だと思われますか？

王：エンジニア自身の自己実現につながっている面もあるんじゃないかと思いますね。プログラミングが好きなエンジニアにとっては、簡潔で美しいコードを書くこと自体が快感をもたらす面もあります。リファクタリングによってそれが実現できた喜びは計りしれませんし、仲間から賞賛されればさらに大きな達成感が得られます。

原田：同僚から「あのとき改善してくれたおかげで新機能開発がやりやすくなった」という声を聞くのも、リファクタリングしてよかったと思う瞬間ですね。

リファクタリングによってゲームの挙動が変わるわけではありませんし、機能が増えるわけでもありません。ユーザーには見えない部分ではありますが、システム上のボトルネックが解消され、保守性が上がれば、結果的にユーザーに喜んでいただけるチャンスは確実に増やせますから。

——リファクタリングを習慣化させるための方法を教えてください。

原田：余裕を持ったスケジュールを組むことが何よりも重要です。何か大きな問題が起こっても迅速に対処できるよう、マネージャーが中心となって関係部署と調整したり、設計や開発の相談に乗ったりできるよう、常にバッファを持たせるよう心がけています。

また、サービスの信頼性を担保するQAチームに対し、開発チームからテストに必要な設定などを自動化するツールを提供するなど、関係者全員がリファクタリングに前向きになれるよう環境を整えたり、マネージャーがリファクタリングの効果や難易度を正しく評価し、適切に報いるのも大切なポイントです。

王：リファクタリングに前向きな文化を育むには、ドキュメントを残したり、コードレビューやミーティングなどの際に忌憚なく意見交換したりするなど、成功も失敗もエンジニア個人の経験に留めないことも重要だと思います。こうした日々の取り組みから共通認識が生まれ、それがやがて文化になって根付くものだからです。

リファクタリングを「イヤイヤ取り組むもの」ではなく、「プロダクトの理想を追求するための取り組み」にしたいのであれば、風通しがよくチャレンジを尊ぶ環境づくりからはじめるべきなのかもしれません。

取材・文：武田 敏則（グレタケ）
撮影：曽川 拓哉