定期的なシステムの健康診断（リファクタリング）でプロダクトに忍び寄るエラーを未然にキャッチ ミツモア エンジニアが敷く「10％ルール」とは
プロダクトを長期的に運営し、将来的なトラブルを減らしたり、トラブル対処の時間を短縮するために必要なのが「リファクタリング」で、人間で言うところの健康診断のようなものです。ミツモアでは業務の10％をリファクタリングに当てるよう意識付けを行っています。その意図やメリット、重要性についてエンジニア3人に語ってもらいました。
Taiki Terai（寺井 大樹） プロダクト部 開発2チーム（写真左）
Softbankにて開発を担当後、クラシルの初期AndroidエンジニアとしてGoogle Play1位達成、Google Playベスト オブ2017受賞。法政大学 経営工学部卒。Qiita Contributions 25000超え @teradonburi
kei agou (邢 亜豪) プロダクト部 開発f8nチーム（写真中）
中国出身。2021年8月、エンジニアとしてミツモアに入社。日本企業で働くのはミツモアで3社目。
2015年に中国の大学を卒業後、日本に来て京都の日本語学校で日本語を勉強しながら、進学準備。2017年に一橋大学大学院に進学、経済学専攻。大学院にてプログラミングでデータ分析する際にプログラミングの楽しさを実感して、エンジニアになりたいと決意。2019年一橋大学大学院卒業後、受託開発のECサイトエンジニアとして就職。その後、2社目を経験。2021年、新しいチャレンジと技術を高めることを求め、ミツモアに入社。
James Thomas プロダクト部 開発3チーム（写真右）
アメリカ出身。美術の学士号を取得。来日前は5年間、フリーランスでウェブ開発に従事。
2011年に来日し、英語教師として鳥取県の高校に勤務。その後、eコマースの企業でマーケティング、ウェブ開発などを担当。2021年11月、ミツモアにソフトウェアエンジニアとして入社。
デザインとUXと開発の関係に興味があり、常にユーザーに対してプロダクト改良をしているミツモアの一員であることを楽しんでいる。
リファクタリングの体制について
ーまずはじめに、ビジネスサイドの方にもわかるようにリファクタリングを簡単に説明していただけますか？
寺井：リファクタリングは、システムを作ってる人しか見えない部分なので、必要性を伝えるのが難しいんですよね。でも人間の体もメンテナンスもやっておかないと、実は内臓が弱っていたりします。ほぼそれと似てます。
ーなるほど、プロダクトの定期検診なのですね。
寺井：長期的に開発するためには、どうしても必要なのがリファクタリングです。使ってる利用者側は気づかないよう、事故が起きにくかったり、仕様変更に強くなるよう修正をする地道な作業です。
地味なんですけど、すごく大事なことです。建築で言えば、鉄筋コンクリートの1番基礎のところを塗り固めるみたいな、そんな感じです。
ーミツモアでは、リファクタリングに業務の10％を当てるとのことですね。
寺井：明確なルールはありませんが、意識付けとしてそのような方針を話しております。例えばミツモアの新しいプロジェクト「MeetsOne」では1stリリースが終わった際に技術的負債を返す2週間を設定しました。「ミツモア」側でもそれに類するものをしたりしております。
ジェームズ：私たちは1週間ごとのスプリントで仕事をしていますので、週40時間のうち10％は4時間、つまり半日となります。通常の場合、チームメンバーは各スプリントで半日、リファクタリングや「技術的負債」の問題に取り組むことが期待されますね。
寺井：厳密に10％というのは語弊があるかもしれませんが、組織体制としてはリファクタリング用のチームを作り、そのチームの中で週1ぐらいで進捗を確認するというような感じですね。リファクタリングチームごとで、それぞれ「ここ直します」と決めて直す感じですね。
ーそれはOKRの3か月タームずつで決めるんですか。
寺井：そうですね。それぞれが時間も分担してやります。実際10％かからないタスクだったりとか、10％以上かかるようなタスクもあります。
ーリファクタリングの内容は誰が決めるものなんですか。
ジェームズ：チーム内の個人が、開発中に問題を発見することがあります。その問題（と解決策）をタスクのリストに追加するようにしています。スプリントを計画するとき、可能な限りこれらのタスクを含めます。
ーリファクタリングチームには全員アサインされるのですか？ それはどういう意図でしょうか？
寺井：基本エンジニア全員ですね。技術的負債は個人によるものじゃない場合もほとんどなので、例えば、ライブラリのバージョンを上げた時に全部直さないといけないとか、特定の誰かが負債を解消しないといけない、という考え方でもないんですよね。みんなで直すことで「聞きやすくなる」という雰囲気もあるとは思います。
ジェームズ：現在、私の所属するdev3では、チームメンバーが自分で気づいて記録したリファクタリングタスクを通常行います。あるファイルや関数が複雑になりすぎていることが明らかになることもあります。その場合、チームリーダーはそれを小さなタスクに分割して割り当てます。
リファクタリング要素〜マイグレーション、ライブラリバージョン管理など
ーそれでは具体的な内容について掘り下げたいのですが、例えば前期（2022年3〜5月）のリファクタリングは何でしたか？
寺井：まず、弊社のプロダクトではバックエンドとフロントエンド共にTypeScriptを採用しています。元々はJavaScriptで開発していましたが型がついていないのでTypeScriptを後から導入してをつける作業をしました。型というのは、プログラミング言語で言うと、コンパイル型の言語で、例えば、この変数には数値が入ってますとか、この変数には文字列が入ってます、みたいなのを明示的に指定することができます。それがあると、ガイドライン的なもので、その変数の中に何が入ってるか想像がつきやすい。だから不用意な事故を防げます。
それから古いライブラリを新しいライブラリに差し替える作業。中途半端に移行されてる状態だったのを、きちんと新しいライブラリに差し替えたりしました。
最後は、APIのフォーマットみたいなものを、綺麗に決めることでデータを取ってくるところの繋ぎ込みをシンプルにすることをやってました。この他にもバックエンド側はNestJSなどのフレームワークの導入をしたりしています。
ケイ：私は、ドキュメント化するOpen APIというのを書くようにする作業をしました。
寺井：Open APIを使うと、何かを書くと自動的にドキュメントを作ってくれて、かつ、APIの検証も、ツールを使って簡単にできるようになる。そのフレームワークの導入ですね。
ジェームズ：私はフロントブラウザで出してるモジュールに型をつける作業ですね。「ミツモア」の基本のプロダクトの業務フローの実装とか、創業間もない頃に書いた「ミツモア」のコードは古くなってきているので、変更する時にできるだけリファクタリングタスクを作る。リファクタリングすることでフロントエンド、バックエンド問わず、将来の開発に役に立つと思います。
寺井：補足すると、さっき型をつけるという話をしたんですけど、型をつけるということがなぜ大事かと言うと、長期的な開発をしていく上で、 仕様変更や追加実装をする。その際に間違って既存の実装を壊してしまうデグレということが往々にして起きる。ここを変えたらここも直さないといけない、でも直し忘れて、こっちが動かなくなるみたいなケースがあるんです。でも型がついているとそれに気づくことができます。
ミツモアではreduxというアプリケーションの状態管理ストアを使っているのですが、私はreducerというAPIのデータを取ってくるところのライブラリを新しいライブラリのtypescript-fsaに全部移行し切りました。 やり方が混在してると、新しく入ってきた人が、古い方でやってしまったりするので。混在してると色々良くないので移行し切るという作業ですね。
リファクタリングのタイミングとメリット
ーとりあえずTypeScriptの型をつける作業は終わった感じですか？
寺井：まだ完全には移行できていないですね。それぐらい「ミツモア」のプロダクト規模は大きいので。主要なところはやってはいますが、リソースが足りない…。新しいモジュールに関しては当然TypeScriptで作っていますが…。
ー外注でやったりとか、一括でメンテナンスしてくれるツールのようなものはないんですか？
寺井：外注も簡単にはできませんし、ひとくくりにリファクタリングといっても色々種類があるので銀の弾丸のような全てに使えるリファクタリング用のツールもないです。また既存の挙動を変えないという原則があるのでプロダクトの仕様や挙動を知らない人にはできないことも多いですね。
ーそうなんですね。では、リファクタリングのメリットを教えてください。
寺井：仕様変更したり、追加機能する際、事故らずに早く実装できるようになります。長期的にそのシステムを修正や追加をする場合に大事になってくる作業です。
例えば、「ミツモア」もオープンソースのソフトウェアのライブラリモジュールを使っています。部品として使っているわけですが、その部品が新しい部品に差しかわっていくわけです。ライブラリのバージョンですね。そのバージョンを新しくしないとどうなるかというと、脆弱性、セキュリティ的に危ういところがライブラリの中に潜んでいたり、新しい機能が使えなくなったりする。
ーそれはかなり大事な作業ですね。
寺井：リファクタリングが必要なタイミングがいくつかあって、よく技術的負債というワードがあるんですけど、 機能やシステムを作っていく上でずっと作っていくとガタが出てくる。そういうものを修正するためにあるのがリファクタリングです。さっきお話ししたライブラリのバージョンもそのライブラリの作者がバージョンを上げて機能追加したりする。なので、上げないといけないタイミングは往々にしてあるんです。システムの健康診断的なものだと考えてください。
ーどんどん新しいことを開発していくと、技術的負債を返していくのがつい後回しになりそうですね。
寺井：結局、後回しにすればするほど、新しい機能を作るのに時間がかかるだけです。やりながら直せるのがベストですが…都度やっていくか、後でまとめて返していくか、タイミングはそれぞれですね。なかなか時間が取れないから、リファクタリングチームを作って、10％ルールで技術的負債を返していこうと意識付けしている感じですね。エンジニアの都合だけではどうにもできない時もあります。大事なのは負債を返す時間を確保するという合意を得ることです。
ーエンジニアとしての理想は、どういうものなんですかね。
寺井：技術的負債というのが、他の一般の人やビジネスサイドの人に伝えるのがすごく難しくてですね…例えば肝臓悪いと言われて別になんともないと思っていたら、実は手遅れになってたりという場合も稀にあったりする。技術的負債が溜まりやすい組織体制というのも会社によってはあるとは思います。 ビジネスサイドが「こういうの作りたい」ばかりずっと頼み続けてエンジニアは直す暇もないみたいな…。厄介なケースはタイミング的に設定が段階的に必要で中途半端に移行できなかったり、試験的にABテストしたはいいものの誰もトラッキングしていなくて不要な実装が残ってしまっていたりとかもあります。こうゆうのも本来であれば別途整理する時間が必要ですけど、忘れされていることがありますね。気づいた人が直してくれたり、スプリントという週単位のタスクに積んだりして解消していたりしてはいます。
ー会社全体でリファクタリングの必要性を理解することが必要ですね。
長期開発に不可欠であり、新人の学びにも
ー寺井さんは創業間もない頃からミツモアにいらっしゃいますが、ジェームズさんとケイさんは、ミツモアのリファクタリングについてどう感じていますか？
ケイ：リファクタリングはすごく必要だと思います。技術的なこと、いろんなことが変わっています。JavaScriptからTypeScriptにするとか、Reactクラスコンポーネントから関数コンポーネントにの書き方も変わったり、新しい人が入る時、どっちにしたらいいのか迷いますね。統一すれば新人も迷わないで済みます。
今後も積極的にリファクタリングはしたいですね。
寺井：そうですね、古い書き方と新しい書き方があって、どっちも同じことはできるけど、古い書き方だと不具合が起きるリスクが高いから、全部新しい書き方で書きたい、というのもリファクタリングですね。でも、プロダクト規模が大きくなってくると移行しきれないとそれも負債になったりする…要は技術のパラダイムシフトが起きたときに一気に移行しないといけないタイミングもあるのです。使うライブラリやフレームワークの技術選定も大事になります。「ミツモア」は、使ってる技術要素も相当多くて、いろんなライブラリが入っていたりします。それらのバージョンを上げないといけなかったり、使っていないライブラリは積極的に断捨離する必要があります。
ケイ：ただリファクタリングをやる時、ユーザーに実際新しい機能をすぐに与える訳ではないので、ビジネスサイドのメンバーの理解も必要ですね。長期的に見れば、きっといいことがたくさんありますね。
ジェームズ：私は前の会社でマーケティングの担当者でした。「ミツモア」のコードベースは広く、入社して半年ぐらいですが、毎日勉強になってます。リファクタリングをしたら、すごくよくわかります。例えば、チャットのコンポーネントを、リファクタリングしたら理解が深まると思います。入社した時からリファクタリングと新しい開発の両方をしています。例えば「ミツモア」のコードベースには、時々すごい大きいファイルがあるので、私のチームは小さく分けるリファクタリングをしています。
寺井：ちょっと補足すると、コンポーネントというのはブラウザに見えているUIの部品のようなイメージで考えてください。大きいコンポーネントというのは例えばページそのものが1個の部品みたいになっていて中身は例えばチャットの部分とか、細かい部品に分離できるはずなんですけど、1つのおもちゃ箱の中にたくさんのおもちゃがぐちゃっと入ってる。そうすると整理がしづらい状態なのでちゃんと取り出して使いやすく整理をするということをジェームズさんは言っています。
ージェームズさんのようにエンジニアとして初めて働く方にとっては、割と教育的な良さもあるんですね。
寺井：少なからずはありますね。同じような書き方をしよう、コードを統一しようというのはあります。可読性が悪く迷うような実装がされていると後に意図しない不具合を生む可能性があるのでbullet-proofな関連コンポーネントの整理方針の策定やlintを導入しています。
ー最後に、ミツモア開発部でリファクタリングの時間を確保する取り組みがあることで、エンジニアとしてどのように働きやすいと感じていますか？
ジェームズ：過去の決定を反省し、時間をかけて考え直すことを意味する。将来の開発者がコードを理解し、自信を持って安全に変更できるように、コードを改善することを意味します。
ケイ：ミツモアの開発は目の前のことだけではなく、ちゃんと長期的にシステムの健全性やメンテナンスしやすさを重視し、日々取り組んでいます。個人、開発チーム、ビジネスの成長が体験できるエンジニアとしてとても働きやすい、やりがいがある場所です。
寺井：リファクタリングする時間があることで見通しがよく仕様が明確な実装となり、意図しない不具合を出す確率を下げたり実装者の不必要なプレッシャーを減らして心理的安全性を確保できます。
ーありがとうございます。リファクタリングの時間を確保することはエンジニアみんなの願いということがよくわかりました。
（取材・執筆 字と図 吉田千枝子）
======================================
ミツモアでは、現在事業拡大を進めており、エンジニア・デザイナー・PdMをはじめ多くの職種で積極採用中です。
Wantedlyにて募集しているので、カジュアルに面談に来てみませんか？
デザイングループも所属するプロダクト部の詳しいご紹介は「ミツモア エンジニア向け会社説明資料 / about meetsmore for engineers」を公開しております。
この記事が気に入ったらサポートをしてみませんか？