こんにちは！採用担当の枝野です。
今回はエンジニアの秋田さんに、Smart相談室初の大規模なリファクタリングについてインタビューしました。

Smart相談室に入社して、もうすぐ2年になる秋田さん。メインで任されたプロジェクトをどのように進めて、どんなところにやりがいを感じているのでしょうか？ Smart相談室のエンジニアの仕事を深ぼっていきます！

＊秋田さんの入社エントリはこちら

Smart相談室初の大規模なリファクタリング

（枝野）本日はよろしくお願いします！今、秋田さんがリファクタリングを進めているというお話を耳にしました。リファクタリングに馴染みのない方も多いと思うので、まず、ざっくり何なのか教えていただけると助かります。

（秋田さん）リファクタリングの定義としては、ユーザーの方たちが触る画面や動作など表側には影響を出さずに、中身のソフトウェアを改善していく試みです。

（枝野）具体的にはどんなことをしているんですか？

（秋田さん）Smart相談室は今年サービス提供3周年を迎えましたが、これまですごいスピードで開発を進めてきました。さまざまな機能を動かすために作るところがメインだったんです。いろいろな機能がどんどんリリースされるのは、ユーザーにとって価値が高いですよね。

　一方で、その裏側では複数のエンジニアがコードを書いていました。まったくバラバラの書き方というわけではありませんが、それぞれ好みの方法があるんですよ。だから正直なところ、書いた人以外があとになって読み解こうとすると、少し時間がかかる部分もありました。
それで、複雑になったソースコードを整理して、ルールづくりをするという作業をやっています。

規模拡大を見据え、さらなる効率化を目指す

（枝野）リファクタリングは、開発をさらに円滑にするための整理整頓ということですね。身近なところで言うと、Notionや共有フォルダにたくさん入っている情報を、ルールに沿って項目分けして整理していく⋯⋯というのに似ているでしょうか。

（秋田さん）まさにそんな感じです。整理整頓しておけば、今後の開発をより効率的に進められますから。サービスを使ってくださっているユーザーさんには見えない部分なので、地味な作業ではあるんですけどね。

（枝野）どういう経緯で、このタイミングでやることになったんですか？

（秋田さん）背景となる課題が2つありました。まず、エンジニアの人数が増えてきたことです。これから規模が拡大してさらにエンジニアが増えていくことを考えると、今のうちにリファクタリングをしておいたほうがいいという話になりました。
今のソースコードはオリジナルで書かれているところもあるので、新しく入ってきた人が見たら迷子になってしまうかもしれません。そこで、教科書に載っているような誰が見てもわかる形で整理しようということになったんです。

　もうひとつは少し専門的な話になりますが、エンジニアチームマネージャーの山根さんのWBS（＊）に「アーキテクチャの分離」というタスクが入っていました。ざっくり言うと、現在はまとめて開発しているところを「機能ごと」「ユーザーごと」などいろいろな形で開発を分離させていくという試みです。そのとき、現在のコードだと分けにくい部分がありました。

（枝野）開発を分けることによって、どういうメリットがあるんでしょうか？

（秋田さん）分けておくと、影響範囲を小さく限定することができるんです。何かバグが起こったときもそうですし、「こちらのリリースをしているので、そちらの開発を止めてもらってもいいですか？」というようなことが起きにくくなります。結果として開発スピードが上がるということですね。

（枝野）なるほど。たとえて言うなら共有スプレッドシートでも、適切な設定をしないでフィルターをかけられてしまうと、「見たい列が見られない！」となってしまうことがありますもんね。

（秋田さん）そうです。使う人ごとにシートを分けておくような感じです。

周りに支えられながらの「1人プロジェクト」

（枝野）このプロジェクトのメンバーは秋田さんだけですか？

（秋田さん）はい、1人でやっています。

（枝野）1人でやるプロジェクト！ でもみんなでやったら、いろんなルールができちゃいそうですもんね。

（秋田さん）そうですね。ルールを決めるときって、まずは1人が独断と偏見で決めて、それをみんなで叩いていったほうがいい気がします。もちろん、自分がやったものをレビューしてもらうことはありますよ。マネージャーの山根さんとリーダーの長濱さんには必ず見てもらって、方針に違和感がないかなどを確認しています。

＊山根さんと長濱さんのインタビューもぜひご覧ください！

（枝野）それ以外のメンバーに聞いたりすることはあるんですか？

（秋田さん）いっぱいありますよ！いろんな人からコメントをいただいています。

（枝野）そもそも秋田さんに依頼が来るまでに、どういう背景があったんでしょうか。

（秋田さん）1年くらい前から、僕が「リファクタリングしようぜ！」って言っていたからだと思います（笑）当初はサービスを動かすことが優先だったので、ようやく時期が来たということですね。

（枝野）一般的に考えても、サービスが始まってから一定のタイミングで「リファクタリングしよう」となるものなんですか？

（秋田さん）他社さんの状況はわかりませんが、創業7年目くらいのスタートアップ企業が大規模なリファクタリングをしているという話を聞いたことはあります。

（枝野）リファクタリングをしないままだと、何か問題が起こり得るんでしょうか。

（秋田さん）Smart相談室の場合、今までに十数人のエンジニアが、それぞれいろんなところを触っているんですよ。たとえば50個くらいの処理がまとまって書かれていても、1行目はAさん、2行目はBさん……というように、全部を1人で書いたわけではありません。それぞれ意図があって書いているので、整理しないと読み解くのが難しいんです。

新しい人がたくさん入ってきてから整理やルールづくりをやろうとすると、より大変になります。今なら「10人が書いたものを1つに集約する」で済むのが、「30人が書いたものを1つに集約する」になってしまいますからね。だから今のうちにできてよかったです。

（枝野）期間はどれくらいかかるんですか？

（秋田さん）今回については、あと1か月くらいで大枠は終わらせようと思っています。そこから方針を定めて、あとはちょこちょこ回していく感じになりますね。リファクタリングは「ここで終わり」というのではなくて、ずっと続いていく感じなんです。日常的にコツコツとリファクタリングをしているのが理想的な組織だと思います。

先人と対話しながら、エンジニアとして成長していく

（枝野）実際にリファクタリングをしていて、何が特に大変ですか？

（秋田さん）複数の人が触った処理を集約させるのが難しいですね。たとえば、50行くらいあったものを10行ほどにまとめたんですが、みんなの意図を集めて抽象化するのは、なかなか大変でした。
とはいえ、パズルや将棋をやっているような感じもあるので、めちゃくちゃしんどいけど楽しいところでもあります。「あの人とあの人の処理は、こうするといい感じにくっつけられる」みたいな。

（枝野）すごいなぁ。今回リファクタリングを任されることになって、実践したインプットの方法などがあったら教えていただきたいです。

（秋田さん）リファクタリングすることが決まってから、リファクタリングをするうえで欠かせないとされている文献に目を通しました。まず全言語に関するリファクタリング一般についての本と、Rubyに関する解像度が高い本です。あと、エンジニアさんのブログとかネット記事もめちゃくちゃたくさん読みました。

　山根さんがよく「過去に敬意を払って開発をしよう」とおっしゃっているんですが、リファクタリングって先人との対話みたいな感じがあるんですよね。リファクタリング自体にも歴史があって、海外を含め著名な人たちが「こういうふうに進めていったらいいよ」といった軌跡を残してくれているんです。書籍やネット記事を通して、そういう人たちと対話できている感じが楽しいですね。

（枝野）エンジニア目線でリファクタリングのやりがいとか、やりきったときの成長のイメージってありますか？

（秋田さん）何より「コーディングのルールを作った」という実績になりますね。ルールって、1回決まってしまったら大枠はあまり変わらないものなんですよ。僕が経験してきた案件でも、ほとんど初めから決まっていました。そこを一から考えられるというのは、貴重な経験だと思います。

　あと今回に関して言えば、自分がやりたいと言ってきたことを裁量権をもって任せてもらえたことが大きいですね。これまでは開発のスピードを重視してきましたが、このタイミングでルールづくりという新しいチャレンジができて、エンジニアとしていい成長の機会になりました。

（枝野）エンジニアチームの業務について、すごく解像度が上がりました。ありがとうございました！今回のリファクタリングがひと段落したところで、またお話を伺えたら嬉しいです。

＊秋田さんがこれまでに関わってきたプロジェクトもnoteで紹介しています！

◼️Smart相談室へのお問い合わせ・取材依頼は以下よりご連絡ください。
・お問い合わせフォーム：https://smart-sou.co.jp/contact
・メールアドレス：pr@smart-sou.co.jp