【後編】リファクタリングから読み解くサービス成長〜各社の取り組み、落とし穴や抑えておきたいポイント〜
2021年2月18日に開催されたCTOmeetup「リファクタリングから読み解くサービス成長」のイベントレポート後編記事です。
ご登壇者紹介、リファクタリングの定義、タイミングなどを各社の技術責任者が語る前編記事はこちらをご覧ください。
注目される3社がどのように技術選定やソースコードのアップデートを行っているのかをはじめ、リファクタリングに関わる様々なテーマでお届けします。
目次
【後編】リファクタリングから読み解くサービス成長
上司にOKと言わせるリファクタリングプロジェクトの立ち上げ方
Sansan株式会社 執行役員／CTO 藤倉 成太 氏（以下、藤倉）：事前質問でもいただいている内容ですが、上司に対してリファクタリングすることをどう説得するのかという視点があります。お二人は部下からの説得を受ける立場だと思いますが、どういうケースはOKで、どういうケースはNGになるのでしょうか？
株式会社トラストバンク CTO／開発部長 山崎 賢 氏（以下、山崎）：僕はシステムをこのまま継続したパターンとリファクタリングしたパターンで損益分岐点を指し示し、経営にジャッジしてもらったことがあります。求める数字は、例えば機能追加をする際にシステムの複雑性がどれくらいの係数になるのか、あるいは障害が現状のパーセンテージで発生したら対応のためにどの程度の工数が必要になるのかといったものです。2、3回同じように稟議を通すことで信頼感に加えて「リファクタリングは必要な工数である」という共通理解が生まれるので、その後はやりやすくなります。
山崎：リファクタリングを実施する背景には、エンジニアがビジネスに対する価値の定量化にチャレンジする必要があるのかなと思いますね。
ナレッジスイート株式会社 取締役執行役員 DXビジネスユニット 開発部門管掌 兼 先進技術開発部部長 雄川 賢一 氏（以下、雄川）：同感です。先ほどもお話した通り、経営視点で見たリファクタリングというのは「リスクをどう解消するか」がポイントです。
雄川：同リスクがどれくらい高いのか、いつまでに解消しなければいけないのかといった情報を経営層に渡すことが、説得への近道になります。
リファクタリングによってドメインモデルやインフラ基盤に成功した例
藤倉：失敗談は先ほど少し触れていただきました（※）が、逆に成功した経験はありますか？ ※前編記事 参照
雄川：6年程かけてリファクタリングした話は成功経験でもありますね。長かったですが、全て書き変わったときは気持ち良かったです。
藤倉：僕も一つご紹介します。Sansanに入社した当初、法人向けのプロダクトの中心は「名刺」でした。同じ人物の名刺が複数枚あった場合に人物と名刺は1体ｎの関係になるのですが、そもそもデータベースに「人物」というテーブルが無かったんです。
しかし当時、我々のプロダクトの本質は「名刺」ではなく「人と人とのつながり」ではないかと議論されていました。そして新たに「人物」という概念を組み込まない限りこのプロダクトは発展しないということで、データベースのスキーマを変えるプロジェクトが立ち上がりました。僕はプロジェクトをリードするために入社したわけです。ドメインモデルを変えるためのリファクタリングですね。
当時の開発エンジニアは5～6名だったのですが、入社してから3ヶ月ほどで僕がプランを立て、あとは丸一年、エンジニア全員が新規開発を止めてリファクタリングを行いました。性能の問題がありリリース自体は1ヶ月ほど後ろ倒しになったものの、それ以外は計画通りに進められたので良かったと思っています。
山崎：僕はリクルート時代にインフラを移行するプロジェクトに参加したことがあります。当時のリクルートはオンプレミスでサーバー運用をしていたのですが、新たにAWSの基盤を構築し、リクルート内にある情報のルールを吸収できる環境を展開しようとしていました。
その基盤が現在もリクルート全体で使われているそうなので、価値ある仕事にチャレンジできたと感じています。
リファクタリングに失敗しないコツは「範囲を限定して完遂すること」
藤倉：みなさんの中で、リファクタリングに失敗しないコツのようなものはあるのでしょうか？
雄川：しっかり目標を定めてリファクタリングすることですね。また、無理が無い形で少しずつ進めるのも手だと思います。途中で挫折すると共通モジュールで作ったものが生き残って2本になってしまうので、やり遂げる気持ちが必要です。
山崎：全く同意見です。手を出す範囲を限定的にした上で、必ず完遂することを目標にする。これが前提です。
また、長い間裏側でリファクタリングしていると表側で機能追加したときに追従しなければいけなくなるので、少しずつ新しいものに置き換えていける仕組みをセットで考えることも大事にしています。
藤倉：アーキテクチャなんかを書き換えようと思ったら、最長で6年は取り組むつもりで向き合ってほしいという感じですかね。
山崎：途中で終わると技術負債が倍になりますからね。
雄川：リファクタリングをするとバグが混入するケースもありますよね。テストでどのように品質を担保するかもセットで考える必要があるかなと思います。
仕様を削るかどうかの議論にはビジネスサイドも巻き込みたい
藤倉：仕様を削ることができるかどうかについて先ほどは決着がつきませんでしたが、みなさんは実体験として仕様を削ってでもリファクタリングをした経験はありますか？
山崎：ビジネスとしてほぼ使われていない決済手段を外した経験はあります。
雄川：僕は仕様を削ったことはありません。仕様は変えないまま進めるケースが多いです。
藤倉：実は僕も仕様を削った経験はありません。現場から「この仕様が理由でメンテナンスや機能追加ができないし、パフォーマンスも出ない。もう削りましょう」と言われても、別の案を考えたら意外とクリアできてしまうんですよね。仕様を削らなければどうにもならないような状況は、あまり見たことがありません。
山崎さんがおっしゃった例は削らざるを得なかったというよりは、「使われなくなっているから切り離してきれいにしよう」というポジティブなケースだと思います。
山崎：理想としては、ビジネスサイドと会話がしたいんですよね。ビジネスとエンジニアの間で共通言語をそろえる必要がありますし、例えばドメインモデルの定義をはじめ、今ある仕様の中でどれを残してどれを捨てるのか、同じフィールドで議論できたらいいなという思いがあります。リファクタリングという活動がエンジニアだけではなく、会社全体のものになったいいなと。
雄川：そういう状況だとエンジニアも前向きに取り組めますよね。
あらかじめリファクタリングの「工数予算」を確保しておくと楽
藤倉：新規開発とリファクタリングにかける工数はどんな割合ならいいのかという話もよく出ると思うのですが、考え方やコツはありますか？
雄川：例えば機能開発もセキュリティリスクを下げるためのリファクタリングも、同列で考えて進めています。分けるとどうしても機能開発に偏ってしまう気がするので、あえて差をつけずに判断するようにしているんです。
山崎：僕も同じですね。一気に変えなければいけないようなケースを除外して考えると、リファクタリングは継続的な活動として少しずつ良くしていく方がいい。そのためには、リファクタリングをビジネス側からは見えない工数として聖域化することが結構あります。インフラエンジニアの開発が工数に入らないのと同じように、リファクタリングの工数を10～20％ほどあらかじめ分けておくんです。都度ビジネス側の承認が必要なくなるので楽ですよ。
藤倉：うちも山崎さんの考えに近いかもしれません。エンジニアは1日8時間働いていても、その全てを開発業務に充てているというわけではありませんよね。全社会議に出ていたり、面接官をやっていたりもします。そこであらかじめ、「60％～70％は開発の工数である」という計算をします。人数で合算すると数千時間が開発に使えるリソースだということですね。ここから例えば、プロダクトの未来を作るような案件や営業やコンサルタントがどうしても実現したい案件に使う割合を決める。こういった「工数予算」と呼ばれるものをきっちりクォーターごとに作っていき、その中にリファクタリングも含めます。工数予算と実績が乖離していないかどうかが経営に対するレポートにもなっています。
Youtubeライブでリアルタイムに質疑応答
「目的を決めない」「手段の目的化」はアンチパターン
質問者：リファクタリングのアンチパターンはありますか？
雄川：「このぐらい時間があるからとりあえず実施しよう」という形で進めるのは厳しいと思います。やはり「ここを変えていこう」というリファクタリングの目的がないと破綻しますし、期間を決めると突貫になってしまいます。
山崎：人によるかもしれませんが、手段を目的化したリファクタリングはアンチパターンだと考えています。リファクタリングの多くは生産性に寄与するものだと思いますが、生産性というものはソフトウェアを作るだけではなく、どんな仕様にするかはもちろんどれだけテストを簡単にできるかなども大きく関わります。例えば教科書に乗っているようなマイクロサービスの分け方をそのまま取り入れてみたら、「こんなつもりじゃなかった」という事態が発生しがちです。きちんとシステムの現実と前後関係を見るのは、アンチパターンを作らない考え方として大切にしています。
藤倉：しっかり目標を定め、計画を立てた上で確実にやりきるということですね。
リファクタリングにおいてテスト自動化は必須条件
質問者：リファクタリングする際のテストの考え方や方法論などはありますか？
山崎：うちの場合はWebサービスなので、リファクタリングするのであればテストはほぼ自動で回るような仕組みをセットで提供するのが大事かなと思います。テストコードをセットで書けばCIで自動的に回るとか、E2Eのように外から叩くテストが定常的に回るといった仕組みを整えてからでないと、怖くてリファクタリングできません。
雄川：テスト自動化ができていないと、手動で全件テストするのが厳しくなったときにバグが残ってしまうんですよね。6年間かけてリファクタリングしたときも完全にテストを自動化していて、45万ケースほどテストを組ませていました。新旧両方叩いて完全に一致するかどうかまで見ていたと思います。
藤倉：ユニットテストとE2Eテストは可能な限り常時用意されているのが理想ですよね。それが無いとすれば、リファクタリングのプロジェクトの一環としてまずテストを書くことから始めるのが重要かもしれません。
最後にひとこと
ゴールに至るための道筋を立てればリファクタリングは成功する
藤倉：では最後皆さんから一言ずつお願いします。
雄川：何度もお話ししましたが、リファクタリングは何を解消するのかを明確に定めてブレないように進めれば実行できると思っています。定めた目標を上司に提案すれば必要な対応をしてくれるはずなので、ぜひ試してみてください。
山崎：ゴールに至らないリファクタリングは何も生み出さない作業になってしまうので、自分たちできちんとゴールまでの道筋を考えるのも重要です。今日ご参加された皆さんがリファクタリングをするのであれば、ぜひ「この期間でここまでやりましょう」というところまで社内で議論していただけたらなと思います。
藤倉：お二人に完全に同意します。視聴者の中にはリファクタリングをプロジェクトとして立ち上げきれなかった苦い経験がある方もいるかもしれませんが、僕は「変えたほうがいいのでは」という気付きが非常に重要だと思っています。
とはいえ、最初から自分の感覚を理路整然と整えられるわけではありません。立ち上げに失敗してしまったという場合は、「なぜ自分はそれを美しくしたいと思ったのか」を言語化し、経営が理解できる数字やストーリーを紡ぐ努力が足りなかったのかもしれません。ぜひエンジニアとしての嗅覚は大事にしてほしいと思います。
では、ディスカッションは以上とさせていただきます。本日はありがとうございました！
FLEXY編集部
