法人向けサービスnote proの開発担当をしている登内です。

noteには法人向けのnote proという機能があり、企業のオウンドメディア運営を強化し、ブランディング、採用、販促などの後押しをしています。noteとは少し違ってtoB向けに特化しているのが特徴です。

note proの裏側の営業基盤システムの開発・運用を一人で進めることが多くなったため、機能開発と技術的な負債の改修やリファクタリングを並行して行わなければなりません。（あくまで基盤に限った話であり、note proの他機能はチームで開発）

当たり前ですが、技術的な負債を改修してもお客様には関係がありません。しかし、改修してキレイなコードにすることによって、より素早く機能提供ができるという面もあるのが悩みどころです。

今回の記事では、note proの営業基盤システムを開発する上で、技術負債が発生した原因から改修した方法を通して、私が考えたことを書いて行きたいと思います。

なぜ負債が発生したのか？

note proでは月額/年額のサブスクリプションモデルで事業を進めており、Zuoraを利用して収益の管理などを行っています。当初は、ユーザーに関することやZuoraの操作ロジックを同一モデルで行っていました。

しかし、サブスクリプションビジネスが拡大するにつれて、Zuoraの操作系メソッドが次々と追加され、クラスが肥大化してしまったのです。プラン変更処理やオプションプランの追加など、手動で行っていた操作をシステム化する動きが、私が入社する少し前からあったようです。

また、モデルが膨らんだ一番の原因は、テーブル設計だと考えています。ユーザーの特定情報とZuoraの情報の一部を同じテーブルに入れてしまっているため、そのモデルに両方のロジックを実装してしまっていたのです。

どうやってリファクタリングを進めていったのか

改修は私が入社した当時（2023年1月頃）から少しずつ行っていました。

当初は入社したばかりでまだ業務知識も浅いですし、Zuoraなど外部連携の要因があると動作検証も難しい部分がありました。また、技術負債の解消は影響範囲が大きいことがあるため、一度には進められないことが多くあります。

そのため、隙間時間を見つけて少しずつ進める方針を取りました。具体的には、プロジェクトと並行して技術負債の解消を進めていく方法です。Aの機能開発を行うときに、Aのメソッドも一緒に別クラスに移すようなイメージです。

業務と一緒に並行して改修を行うことで、少しずつシステムの知識を蓄えていけますし、動作検証も同時に行えるため、安全に作業を進めることができます。

改修後の構成もシンプルにすることを心がけており、Zuora系のメソッドをクラスに切り分けてlibディレクトリに切り分けていくようにしています。あとは、Zuoraのような外部サービスのAPIとプロダクトの方向性がうまく噛み合っていない場合、それが原因で実装が増えたり複雑化します。ビジネスロジックを内側で持たず、Zuoraの機能にうまく乗せることでシステム全体をシンプルにすることを心がけました。

今回の負債改修では難しいことはしていません。地道にひたすらやっていくしかないという姿勢で取り組みました。こういった方向性で1年の中で少しずつ行っていき、業務知識が完全に固まった段階で、最後は一気にlibディレクトリへの移行をしました。

開発の優先度をどのように付けていくのか

まず、私が一番に優先するのは、営業事務オペレーションのコストを開発でどれだけ削減できるかという点です。営業事務の効率化は、会社全体の業務効率に直結するため非常に重要です。また、技術負債の解消は開発速度を上げるなどの抽象的な効果が期待されますが、その効果を具体的に数値化するのが難しい部分があります。

今回の負債改修におけるリファクタリング作業は、私の自己満足の部分も正直あります。昔に関わっていたプロジェクトのコードでかなり苦労した経験があるので、コードのクリーンさを保ちたいという思いがあります。気持ち悪さを感じるのであれば、リファクタリングしてしまったほうが将来的な機能開発も早く進むと思っています。

自分が触るコードなので、気持ち悪い部分を改善したいという気持ちがありますが、もちろん未来のためや他の人のためという側面もあります。

まとめ：今回の改修を通してわかったこと

負債改修ができない要因として、工数を割けないこと、業務ナレッジが少ないこと、リスクを取れないことなどが挙げられます。

今回は長い期間をかけて取り組む必要があったため、あらかじめマイルストーンを設定していました。これにより、着実に進んでいる実感を持ちながら作業を進めることができたのです。最後までやり切ることができたのは、最初から計画を立て進めたからだと思います。

また、負債改修は自分以外のためにもなるのだと改めて実感しました。今回の改修で、Zuoraの操作系ロジックとユーザ管理ロジックを分離することができ、開発時の視認性が向上しました。その結果、影響範囲が限定され、生産性が上がりました。加えて、認知負荷の高かった変数名を変更することで、コードが一層スッキリしました。私が初めてnote proに関わったときに理解に苦労した部分を修正できたため、今後、新しいメンバーが加わった際にはスムーズに仕事を始められるようになったという実感があります

普段から実装や設計に課題感を持っていれば、負債改修を他のプロジェクトと並行して進めることも可能です。これにより、コストパフォーマンスよく取り組むことができました。この成功体験があったからこそ、自信を持って今後も大きな負債改修に取り組むことができますし、日常の開発でも細かいリファクタリングを行う習慣が身につきました。

これからも、負債改修に取り組みながら、note proの成長を目指していきたいと思います。

※ この記事はエンジニアへのインタビュー内容をライターが再編集しました

▼note proの開発をもっと知りたい方へ

▼noteの技術記事がもっと読みたい方はこちら