Money Forward Developers Blog

株式会社マネーフォワード公式開発者向けブログです。技術や開発手法、イベント登壇などを発信します。サービスに関するご質問は、各サービス窓口までご連絡ください。

20230215130734

技術負債解消に取り組んだ新卒1年目を振り返ります

この記事は Money Forward Engineering 1 Advent Calendar 2022 22日目の投稿です。

こんにちは、2022年4月入社の新卒バックエンドエンジニアのコットンです。

新卒1年目ももうすぐ終わるとのことで、この1年何をしてきたのかざっくりと振り返ってみようと思います。

普段は技術負債解消を主な業務としていますので、この記事を通して新卒1年目で新規開発じゃなくて技術負債解消って実際のところどうなの?と思ってる大学生や同じ年代のエンジニアの皆さんのお役に立てるのではないかと思います。

「桃園の誓い」アーキテクチャとわり算

振り返りをする前に、所属しているチームとチームで取り組んでいる「桃園の誓い」アーキテクチャについて簡単に紹介します。

私はクラウド横断本部のわり算チームという部署で技術負債解消に取り組んでいます。

わり算チームは「桃園の誓い」アーキテクチャの脱却を主なテーマとして活動しています。プロダクト開発チームとは異なり、特定のプロダクトだけに限らない技術負債解消を推し進めています。

マネーフォワードには「桃園の誓い」アーキテクチャと呼ばれる歴史の長い技術負債が存在します。 以下の記事にて詳しい背景などについて言及されていますが、本記事では簡単に概要を紹介させていただきます。

かつてのプロダクト数が今ほど多くなかった頃、開発速度を落とさないため、プロダクト毎にDBを用意するのではなく、共有DBに複数のプロダクトのレコードを格納する状態となっていました。

ある程度の規模になるまではこれでも耐えられたのですが、プロダクトの規模、数が拡大するにつれて共有DBのコスト増加、安定性の課題が露見してくることになりました。

共有DBに負荷がかかると依存する全てのプロダクトが停止してしまう可能性があります。「我ら生まれた日は違えども、死す時は同じ日同じ時を願わん」という三国志中のセリフになぞらえて社内ではこれを「桃園の誓い」アーキテクチャと呼んでいます。

「桃園の誓い」のイメージ図、わり算の元ボスの力作です

各プロダクトの品質を落とすことなくこの問題に対処するため、DBの分割を行う判断が行われました。マネーフォワードビジネスカンパニー内におけるその旗振り役をわり算チームが担っています(DBを割っていくからわり算というチーム名)。

共通管理画面の分割

前ふりが長くなってしまいましたが、ここから振り返りをしていきます。 (入社後の2ヶ月間は研修に参加していたのですが、そこは割愛して6月の配属後の半年についての振り返りとなります)

配属後の半年間は私が主担当としてマネーフォワード クラウドシリーズの共通管理画面を各プロダクトへ分割する業務を進めてきました。

マネーフォワード クラウドシリーズには先述した「桃園の誓い」アーキテクチャによる共有DBとそのDBを直接参照している共通管理画面があります。各プロダクトDBへの分割を行なっていく以上、現状のまま共通管理画面を維持することは難しくなってしまいました。そこで基本的にはプロダクト側で完結できるようにしようという方針の元、共通管理画面の共有DBからの分離、分割が進められることとなりました。

この業務を進めていくうえで実装だけでなく、分割方針の判断、使用しているビジネス側メンバーとの調整など色々とやってきたのですが、その中から具体的な例をいくつか紹介します。

メール送信APIサービスへの対応

共通管理画面内にお問い合わせ対応のためのメール送信を行う機能があるのですが、共有DBに依存した形でメール送信を行う仕組みとなっていました。そこで共有DBからの分離を行うため、メール送信APIを提供しているマイクロサービスを使用する対応を取りました。

マネーフォワードでは全社的にマイクロサービス化を推進していますが、担当箇所でマイクロサービスの恩恵が得られるのが初めてだったこともあり、新鮮な気持ちで取り組めました。

プロダクトキーの分割

マネーフォワード クラウドシリーズにはプロダクトキーと呼ばれるいわゆるクーポンコードのような仕組みが存在します。

これについても共有DB内でテーブルを共有する形で実装されているため、各プロダクトへ分離しないといけません。

レコードの分割だけでなく、各プロダクト側の管理画面へのプロダクトキー発行、更新の仕組みの移行などを行いました。

ビジネス側メンバーの業務と密接に関わっている部分ということもあり、利用実態のヒアリングや方針決めが割と大変でした。

マネーフォワード クラウドシリーズの課金情報表示の移行

本来、マネーフォワード クラウドシリーズの課金情報は課金基盤で表示させるべきところではあるのですが、こちらについても歴史的背景から共通管理画面で閲覧する状態となっていたため、課金基盤の管理画面への移行を行いました。直接レコードの更新を行なっているプロダクトもあったため、APIを通した更新へ変更できるか等の確認を行う対応もしました。

課金基盤ということもあり、レビューの際テストコードをかなり詳しく見られたと記憶してます。チーム毎、プロダクト毎のレビュー傾向の違いがあることを肌で感じられました。

ビジネス側メンバーとの調整

管理画面もDBも分割できてみんなhappy!なように見えますが、実のところそうでもありません。開発者とユーザーにとっては良いことかもしれませんが、管理画面の主な利用者はカスタマーサクセスやセールスなど主に社内のビジネス側メンバーとなります。

特にカスタマーサクセスではお問い合わせの際、特定のプロダクトに限らず調査を行うこともあるため、共通管理画面が失われることは業務効率の低下に直結してしまいます。

そのため、どの機能をどのプロダクトの管理画面に移行すればいいのか、どうしてもプロダクトを跨いで閲覧したいデータがある場合はAPIを各プロダクト側に用意してもらう、データ分析基盤経由で閲覧できるよう環境を整えるなどできる限り管理画面を使うメンバーの業務効率低下を抑えられるようにしてきました。

成長ポイント

これまでに述べたような業務を通して以下の点について成長できたように思います。

部署を跨いだコミュニケーションに関して苦手意識が減った

当初は他部署かどうか関わらず人にヒアリングや依頼をしたりすることが苦手気味でしたが、業務の特性上チームメンバーのみならず他部署の方とも接点を持つことが多く苦手意識が減りました。

基本的なことですが相手の目線に立ってやり取りを行う、誤解を招くようなビックワードの使用を控えるなどの点を念頭に置いた円滑なコミュニケーションを行えるようになったと思います。

未だ考慮が足りず迷惑をかけてしまうこともありますが、その都度反省してより上手く回していけるよう精進していきたいです。

相手の主張を鵜呑みにせずどうして?を考えて進められるようになった

機能追加や改修について要望をいただいてもいざ詳しくヒアリングを行うとより良い解決策が見つかったり、そもそも対応の必要がなかったりすることって往々にしてありますよね。

私は以前から押しに弱く相手の主張を鵜呑みにしがちだったのですが、この1年で最終的にいいものを作りたいという思いのもと主張を受け入れる前に一旦間を置いて判断することができるようになってきました。

歴史あるコードに触れることでRuby on Railsに対する知見が深まった

複数プロダクトに跨って使用されているRails Engineなど歴史の長いコアなコードを読む機会も多く、Railsに対する知見が深まりました。

横断的なプロダクト知識が増えた

複数のプロダクトに対してヒアリングしたり、自ら実装をしに行くこともあったため、横断的にプロダクト知識を得ることが出来ました。 得られた知識を活用することで、一プロダクト内の情報だけでなく他プロダクトの情報も加味したより視座の高い判断が出来るようになってきた気がします。

成長ポイント全体を俯瞰するとプログラミング言語への知見などのハードスキルよりコミュニケーション周りのソフトスキルが特に向上したように思います。

来年の抱負のようなもの

成長ポイントも踏まえて来年は以下のことに挑戦していきたいと思います。

  • より多くのステークホルダーを巻き込みつつ進める必要のある技術負債解消の取りまとめ
  • より技術的難易度の高いアーキテクチャ検討、実装

どこかのタイミングで新規開発にも携わりたいと考えつつも、もうしばらくは技術負債解消周りに専念したいと考えています。

技術負債解消に取り組んで分かったメリット・デメリット

個人の振り返りは以上となります。

最後に技術負債解消が個人のスキル向上に対してどのようなメリット・デメリットがあるのかというところをまとめてみました。

メリット

  • 歴史の長いコアなコードに触れる機会があり知見が深まる(どういった経緯でこのような実装に至ったのかというところから調査することが多々あるので、ただコードを眺めている時と理解度が段違い)
  • どういったところが後々キツくなってくるのか実感を持って知れるため、長期的にどのようなアーキテクチャにすべきか考える設計力が身につく

デメリット

  • 技術負債解消を行うのは長期間運用されてきたプロダクトが多いので、ちょっと古い技術に触ることになるかもしれない
  • 基本的に既存のプロダクトの改修となるため、0からものを作り出す機会が少ない
  • 成果が一目で分かるようなものではないことが多く、達成感が得られにくい

メリット・デメリットを述べてきましたが、正直言うと技術負債解消というものはとても地味です。(配属前はぼんやりとですが、もう少しキラキラしたものというイメージを持っていました) 実際ほとんどの業務が短期的なパフォーマンス改善や目に見える成果に繋がるものではありません。 それでもいざ振り返ってみるとプロダクトを長期的に渡って運用していくために必要であったと思えるものばかりです。 自称縁の下の力持ちのような気分になれるので私は今の業務を結構気に入っています。

最後に

最後の方は若干ポエム気味になってしまいましたが、この記事を通して技術負債解消業務に関して少しでもイメージが湧いてくれたら嬉しいです。

個人的にも1年の振り返りを明文化できてスッキリしました。 来年はこの振り返りも活かしつつ、ガンガン技術負債解消に挑戦していきます。


マネーフォワードでは、エンジニアを募集しています。 ご応募お待ちしています。

【会社情報】 ■Wantedly株式会社マネーフォワード福岡開発拠点関西開発拠点(大阪/京都)

【SNS】 ■マネーフォワード公式noteTwitter - 【公式】マネーフォワードTwitter - Money Forward Developersconnpass - マネーフォワードYouTube - Money Forward Developers