イベントレポート：10年以上続くサービスを展開する2社が語るリニューアル時の成長痛と未来への開発戦略

【モデレーター】

株式会社ポテンシャライト
代表取締役　山根 一城
青山学院大学を卒業後、株式会社ネオキャリアに新卒入社。人材紹介の営業とキャリアカウンセラーを兼務しマネージャーとして従事した後、2011年に IT/Web業界に特化した人材紹介会社の立ち上げに参画。2014年より取締役に就任。 その後ベンチャー/スタートアップ企業に寄り添った採用支援を実現するために2017年4月に独立、株式会社ポテンシャライトを創業。ベンチャー企業に特化し創業4年で250社超の採用支援に携わり現在に至る。

【登壇者】

株式会社マネーフォワード　
エンジニアマネージャ　田辺憲行（たなべのりゆき）
ネットワーク機器の組込みソフトウェアの開発からエンジニアとしてのキャリアをスタートし、その後独学でRailsによるウェブアプリケーション開発技術を身につけWeb業界へ転身。その後アプリケーション開発やフロントエンド技術を身に着けフルスタックエンジニアとして活躍し、2019年12月株式会社マネーフォワードへジョイン。現在はエンジニアマネージャを務める。
田辺憲行と申します。マネーフォワードには2019年に入社して今3年目です。個人事業主本部でクラウド確定申告の開発に関わっており、現状は現場から一歩退いてエンジニアリングマネージャーの仕事をしており、趣味は一応…ゲームです（笑）。

▶当日の資料はこちら

早速ですが、マネーフォワードのサービスについてご紹介していきたいと思います。
今日紹介するのは「確定申告クラウド」というプロダクトです。名前の通り、確定申告作業を楽にするためのクラウド型確定申告ソフトです。日本は年末調整の仕組みがあることで、就業者の約25％のみが自分で確定申告をしているので、ユーザは個人事業主の方が大半です。
毎年の開発サイクルとしては、大体5月に次年度の確定申告に関する概要が発表され、e-Taxの仕様が確定するのが11月。つまり、全体で1年かかるプロジェクトなのに、開発用の期間は12月から1月の2ヵ月間しかないという…超短納期での開発が求められるという特徴があります。

構造が複雑化し、技術的な負債が蓄積した状態に…

サービスのリニューアルに至った背景としては、保守が臨界点に達して、技術的負債が大量に出てきてしまっていたことが挙げられます。
例えば、マジックナンバーが頻出し、エンジニアが数値から意味を識別するのが非常に大変な状態、という例も。（図参照）





ユーザ視点においても、自動計算機能の一部に手入力が必要で、内容を深く理解していないと入力自体が厳しい部分もあって。入力不足の検出においては、一部自動ではなくユーザ自身のチェックが必要でした。モバイル体験においてもレスポンシブ対応ができていなかったりと、なかなか厳しく…（苦笑）弊社の会計モバイルアプリから参照するにも、体験が悪い状態でした。
これは私の造語なのですが、「キーバリュー型スキーマ（on MySQL）」というものがありまして。確定申告の全機能において、この3つ（id、name、content）しかカラムがないという、何も情報が得られない素敵なデータ設計だったんですね。





Ruby on Railsでバックエンドがつくられ、MVCのアーキテクチャを採用していましたが、Controllerのbefore_actionのようなCallbackでModelのロジックを操作する、といったことが普通に行われている状態だったんです。

また、確定申告の年次によって仕様が異なる計算を、たった1つのロジックで管理していました。確定申告って毎年計算や仕様が異なるものなんですが、年次が違ってもロジックが単一、となると分岐が大量に発生して構造がスパゲッティ化していたんですね。
フロントエンドにおいても、JS、CoffeeScriptなどが混在。JSでもスクリプトベースであったりクラスベースであったり…いろんなものが混在しており、複雑な処理はRubyではなくJSで実行されていたりしました。

要望も盛りだくさんな中、短納期での開発が決定

最終的に、「全部捨ててリニューアルするか！」ということにはなったんですが、稼働も多く見込まれたため「先3年ぐらいで最高のプロダクトにしよう」という体で進めていました。しかし、なんと1年での実施が決まりまして…とにかく大変でした。
1年で実施した開発はこのようなものです（図参照）

リニューアルの成功

結果として、クラウド確定申告は、マネーフォワード内で何十個と展開するプロダクトの中でもかなり歴史が長く古いものでしたが、2012年設立以降、7年を経て初めてフルリニューアルとなりました。何が変わったかというと…全部、です（笑）！変わりすぎてその全てを説明することができないくらいです。これはほんの一例ですが、









もともと確定申告機能は会計プロダクトの一機能だったものを、リニューアル後では分離されて疎結合になりました。フロントとバックエンドもSPA（Single Page Application）のような感じで分岐しています。
一旦、LTパートは以上になります。

▶当日のLT資料はこちら

【登壇者】

株式会社LITALICO（りたりこ）　https://litalico.co.jp/
プラットフォームエンジニアリング部　副部長　磯貝和樹（いそがい かずき）
10年ほどインターネットプロバイダ企業で、IP電話、VPSやオンラインストレージのバックエンドシステム、プロバイダの業務システムなどを開発でリード。大きなプラットフォームの開発を経験してみたいと思いグリーに転職して技術を磨き、その後LITALICOにジョイン。現在はマネージャーとしてチームマネジメントを行いつつ、システムアーキテクトなどの立場でプロジェクトとサービスがグロースするために必要な開発も実施。

よろしくお願いいたします。私のエンジニアとしてのキャリアは中小企業のSIerではじまり、その後インターネットプロバイダでIPやVPSなど、通信系のキャリアを歩んでいました。2017年の5月にLITALICOに入社し、そこからは毛色の違う障害福祉の分野でエンジニアをやっています。今日はLITALICOのリニューアルプロジェクトの経験から、長期目線でのシステム設計についてお話ができたらと思います！
まず、簡単にLITALICOの会社説明をさせてください。

実店舗とWebメディア/SaaSの両方をもち、自社開発もする業界では珍しい会社

教室や事業所を合わせると、全国に約260拠点ほどあり（2022年5月時点）、障害福祉の中ではかなり大規模にビジネスを展開している会社です。こちらの図のように、メディアも複数持っています。福祉業界で自社のエンジニアリソースを使って複数のメディア運営をしているのは結構珍しいです。

支援の記録も、請求業務も一括して処理できるシステム

長年、toCのメディアが主軸でしたが、今回のメインになるのはtoBで、障害者福祉の事業所向けの業務支援をおこなうSaaSプロダクトです。長年現場で顧客と向き合いながら専門性を高めてきた支援力と、自社のエンジニアリング力をあわせ持つことで、会社としての競争優位性を確立したいという考えです。





障害者福祉といわれても、馴染みがある方は少ないですよね。
例えば、お子さま向けの発達支援を行う教室では、専門性の高い支援を提供するためにも日々の支援計画や実績の記録が必要不可欠です。また、その記録を国へ報告することで社会保障費を基とした給付費用が支払われる仕組みであるがゆえに、行政と顧客、双方への請求関連の作業が大量に発生してきます。






これらの一連の複雑な対応を一つのSaaSプロダクトで完結し、業務を簡略化・効率化していくのがこのプロダクトのミッションです。法令に遵守したシステムでないといけないので、国の制度や給付費の算定要件をしっかりと理解したうえで設計する必要が出てきます。

自社を支えてきた業務支援システムに、限界が…

これは、先ほど説明した弊社の実店舗の成長グラフなんですけれども（図参照）。





今回のリニューアル対象は、2012年からのLITALICOの急激な成長を下支えしてきた自社内のシステムでした。数年の間で保守がどんどん厳しくなっていく中で、定期/不定期の法改正にも対応する必要がありリスクのある状態でした。

これはリニューアル前の状態を表す調査結果で、2017年くらいのものです。




300くらいある機能の半分が使われていない状態だったんですね。左は循環的複雑度で53、右がコードの行数を表します。一つのクラスに53個もif文がある状態というのは、結構びっくりする状態なのかなと思います。

会社の規模や業務フロー、そして法律も次々と変わっている中、システムは全然追いついてない状態でした。しかも初期設計者のエンジニアはすでに退職済み。今保守している社員たちも設計思想を理解できていない状況で…日々の事後対応に追われてシステムをよりよくする動きができていませんでした。

「何度でも壊しやすいシステム」を目指したリニューアル計画

いざリニューアル！となった際にはこういった様々な要望も挙がりました（図参照）。





さあ、どうしましょう？（笑）というところで…先々で絶対に法令自体が変わることがわかっているので、変更容易性が求められるシステムをつくらなければなりませんでした。つまり、今回のリニューアルのコンセプトは「何度でも壊しやすいシステムをつくる」だったんですね。





結果として、システムを「関連付けられたコンテキスト」に分離してシステムの開発、追加変更があった場合でも影響範囲が狭い状態を目指した結果、今回はマイクロサービスアーキテクチャを採用しています。バックエンド、フロントエンド側で大きく分離しており、フロントはSPAでつくっています。
複数のSPAを一つの画面になっているように見せ、裏側はマイクロサービスでつくっています。SSR（Server-Side Rendering）の仕組みも用いて低コストに向けた工夫もしてます。

リニューアル成功、さらにはSaaSプロダクトとして商材化！

こちらがリニューアル後を表した図です。（図参照）




さっきの図では赤い丸が非常に大きかったですが、リニューアル直後は平均的な状態ですね。2年経った後ではコードは倍になっていますが、複雑度は変わらず運用できています。品質維持できているという状態を実現できました。

そして何より、自社だけではなく全国の障害者福祉事業所にもSaaSのプロダクトとして提供開始することができているので、リニューアルしてよかったね！という結果で終わることができました。以上です。

ここからはポテンシャライトの山根さんにモデレートいただき、Q＆A形式で各トピックについて掘り下げていきました。

Q.ここからQ＆A形式で進めていきたいと思います。システムのリニューアル時に大変だったことは何でしょうか？

（田辺）他システムとの接続が難航して6ヶ月ぐらいかかったことです。プロダクトを巨大な会計システムから分離したため、分離前後の通信周りはかなり苦労しました。
スクラム開発を導入したんですが、2月15日までにリリースしないと全てがダメになる、という厳密な期限に対して、スクラム開発の場合はそこまで厳密にエンド管理をしない手法のため、相性という点でかなり苦労しました。

（磯貝）うちと似てますね。「法令」ってどれも期限が決まっているんですよね。こちらは3年ごとの4月1日が期限。2ヶ月前くらいに来る正式アナウンスをもとに開発していきます。
我々もスクラムっぽくやりたかったんですが、自分も周囲も当時入社間もない時期で、チーム作りも同時並行でやる必要があり、法令の知識が組織内で平準化できず知識の偏りも大きかったので、なかなかスクラムで進めるのは難しかったです。

Q.チーム開発の手法の話題が出ましたね！一方で技術的な話にスポットをあてると、今回のリニューアルはどうでしたか？

（田辺）先ほどのバックエンド間で連携する通信のところが一番苦労どころでした。e-Taxを電子申告するときに使っているのですが、そのAPI通信がブラックボックスになっていて。試行錯誤しながら最終的に申告まで持っていくのが大変でした。
また、バックエンド間の通信にGraphQLを採用したのですが、もっとマイクロサービスで利用されるような通信方法を使用したほうがよかったかなとは思っています。そのあたり実はLITALICOさんのアーキテクチャが気になっていて…非常に興味があります！

Q. ではこのまま、LITALICOさんのアーキテクチャ戦略について教えていただければと！

（磯貝）当初、入社したてのメンバーといきなり難しい技術的な課題に取り組むのは大変でした。技術バックボーンも違うし、新規開発だと最終形態もまだぼんやりしていますからね。なので、最初はコテコテのQueue（メッセージキューなど）を使ってバックエンド連携してました。古典だからこそ、共通概念としてみんな理解できるだろうと考えまして。今では3年程経ちお互いの課題感も合ってきたので、イベントソーシングとか未来のアーキテクチャを話題にすることも多いですよ。
あとは、マイクロサービスで開発を進める中で、フロントについての情報が少なくて大変でした。どんどん巨大なSPAになってしまい、フロントがモノリシック的になりそうだったので、これはやばいぞ、と…。

そこで、小さなSPAを統合してコントロールできるアーキテクチャを作ることにしたんです。情報が少ない中でチームで議論して答えを導き出した、いわば独自のアーキテクチャです。昨今ではネット界隈で「マイクロフロントエンド」という言葉も出てきていますが、「当時の自分たちの方向性は間違ってなかったんだな！」なんて後から思いました！

（田辺）我々も、法改正に影響を受けて毎年UIが変わるのですが、確定申告の場合は5年前まで正式に申告できるのでそこも大変で…

（磯貝）僕たちも5年前の法令分は残さないといけないので一緒ですね。

（田辺）リニューアル当初はフロントエンドを分割する話もあったんですけど、作りやすさを優先したので、完全に面で分割され巨大になってまして。現状ビルド時間に影響してるので、まさに議論している状態です。

（磯貝）先ほど300機能あるとお伝えしたんですけど、開発時にどんどん機能追加するとどうなるかを、フロントリードとしっかり話して、早めに手を打てたのは良かった点ですが、まだ私たちも完璧には対応できていないですね。
フロントのマイクロサービス的な作り方をさらに突き詰めて、法改正により柔軟に対応していきたいとは思ってます。

Q. コンポーネント単位で分割されている印象を受けたんですが、LITALICOさんはどういう単位でフロントSPAをつくっているんですか？

（磯貝）マイクロサービスで作っていますが、関連で作られたコンテキストは一つの業務単位です。例えば「書類作成の業務」が一つ必要なら、その単位でマイクロサービスを作っています。ユーザ側からはアプリ（画面）を選択できる仕組みです。

（田辺）確定申告は業務単位で分割しにくいのが悩みの種です…帳票がいっぱいあるんですが、裏で繋がっているので分割しにくいんですよね。

（磯貝）年度ごとに綺麗にアプリ（画面）で分けられたらいいですよね。令和1年とか2年とか。毎年の法改正に安心して対応できるだろうなと。でも、今はまだフロントはカオスな状態です（苦笑）

（田辺）年度単位の分割については、実は僕たちは裏も表も対応はできていて。同じコードが重複する悩みはありますが…。バックエンドは年度ごとにバージョンが増えるので、それに紐づくバージョンでリクエストすると動く仕組みで、フロントはディレクトリ単位で年度分けています。

（磯貝）コードの重複については、僕らは問題とはせずに、あえて重複する状態を避けません。「同じようにみえるけど、違う意味合いを持ったコードと捉えて汎用化は避けていますね。

（田辺）汎用化しない点は、僕たちもまさに全体の方針として定めたところです！下手に混ざると困りますもんね。

Q. スタートアップ企業ではなく、長く続いてきたサービス開発に関わる魅力はなんでしょうか？

（田辺）僕がマネーフォワードより前にいた会社は少人数スタートアップでした。ある程度大きな会社に転職したいと思ったのはチーム開発がしたかったから。複数人で一つのゴールに向かって開発できるのはポイントです。前職は正社員が私ひとりの状態で、一人フロント、一人バックエンド、だったので。
今のように大規模な設計やアーキテクチャ戦略などの技術的チャレンジは、スタートアップではなかなか体験できないかなと。

（磯貝）田辺さんと似ているんですが、僕もベンチャーで少人数開発のところに10年程在籍していました。個別最適が優先なので目の前のゴールを追うのに必死でした。10年先までは考えず、長くて3年までしか考えられません。
今は、「10年はもたせる」という思想で開発してます。10年間運営され続けているシステムって殆ど例がないから、「これが正しいだろう」という仮説も立てにくい。だからこそ、実際に長年運用され続けたサービスに触れ続けることで、失敗と成功のどちらも数多く学ぶことができました。本やインターネットには載っていない、エンジニアとしての真の設計力を身につけられたなと思います。

（田辺）めちゃくちゃいい話ですね！僕は今までたくさんのアプリやプロダクトを作りましたが、1年後にはもう無くなっていることも多々ありました…
（磯貝）僕はたまたま自分が開発してから20年残っているシステムもあるんですけど、突貫で作ったものが大半で。低コストでスピード重視な開発もありだとは思うんですが、その繰り返しだと、何十年ももつようなシステムの設計力をつけるのは難しいかなと。スタートアップも楽しかったんですけど、システムの作り方の「方向性が違う」って感じですね。

Ｑ. ここからは参加者の方からの質問になります。
「同じく設計したエンジニアがいない中での引継ぎに苦悩しています。技術的な質問ではないのですがどのようなモチベーションで業務に取り組まれましたか？」

（磯貝）10年使われたシステムならば、10年蓄積されたものがあるはず。レガシーサービスを、僕は「ビンテージ」と考えます。この事業を大きくしてきた根幹のサービスであり、宝物がいっぱいあると思っていて。このプロジェクトで開発者と直接対峙はできませんでしたが、システムを通してその方が持っている宝物をいっぱい奪って、新しいシステムに投入していくんですよ。
「宝物探し」だと思って僕はやっています！

Ｑ.「技術的負債の返済、経営者から見たときに成果が見えにくいと思います。社内政治、どのように制しました？」

（田辺）この話題は、あるあるかもしれませんね。負債対象を維持する費用は抑えたい、とか、リニューアルするにしてもコスト面で指摘を受けたりしますから。
マネーフォワードに関していえば、負債解消にリソースを使っていい、という経営判断がしっかり出ている会社なので全然苦労はしていないんです。当時は技術的負債がたまりすぎていて、事業継続のためにはリニューアルが絶対不可欠だったんですよ。経営者からみたコストと負債が釣り合ったためやむにやまれずだったのかもしれませんが。
（磯貝）僕自身はリニューアルするぞ、というのが決まっていた段階で入社したので、ここはCTOの市橋が経営者と話した部分ですね。LT資料にもあったように、今のままで新規の機能を投入しても余計に技術的負担がかかる、というのを経営者にも伝えたと聞いています。分かりやすく可視化することや、信頼関係の構築も大事かと思います。

あとは、そもそも負債を発生しにくくするために、「やっていることや書き方が一緒でも、コンテキストが違うものは別物だ」という考え方をもっと拡げていきたいと思っています。思考停止で、「なんでも共通化」はよくないなと。DDD（ドメイン駆動設計）的な考え方でもあるんですが。今後、マイクロサービスのシステムは業界的にも増えると思っていて、同じロジックが集まると修正しづらいサービスが増えてしまうんですよね。ぜひ、エンジニアみんなで拡げていきたい考え方です！

（田辺）3回書いたら共通化するとか、一か所にすべき、といった思想が過去のものになっているのかもしれないですね。僕は個人的にテンプレートメソッドがあまり好きじゃなくて。機能修正がしにくい気がしています。今主流のモジュラビリティと違う方向になってしまうのではと。

Q.「技術的負債を蓄積しないために、普段から取り組まれていることやチームでの方針などがあれば教えて欲しいです。」

（田辺）ユーザ体験に直結するようなものばかり作っていると、ユーザへの価値提供の品質も落ちてしまいます。ストーリー開発は7割程度に抑えて、あとは新しい技術にチャレンジする時間に使いたい考えです。弊社は1年おきに開発プロセスを見直せる時期がくるので、過度に時間を使いすぎている部分があれば、見直して次に生かしていくサイクルです。
（磯貝）モデリング、つまり設計力を高めましょうという話は私たちもよくしていて、RDRAをやっているチームもあります。モデリングをやることで「本質的に何が価値なのか？」を考える力がつくなと。もし負債となることがあっても直せばいい、という失敗を恐れない思想です。

Q. 「新しい社員に対して、10年モノのノウハウをどうやってひきついでいますか？」

（磯貝）僕自身も、10年前の法令については詳しくないんです。法令知識もドメイン知識も、過去分はそこまで求められません。でも、現在のものを覚えるだけで結構大変…という課題感は大きいです。研修を作ったり、新しく入ってきた方にモブプロに参画して貰ったりして、これから組織として強化していきたいと考えてます。

（田辺）自社のエンジニアが必要な知識は、技術的なものと、ドメイン知識の大きく2つに別れます。組織がかなり大規模になってきてはいますが、チーム内でトレーナーがつき、モブで一緒にプログラミングしたりすることで技術的な点は解決する傾向にあります。一方のドメイン知識の習得は僕たちも本当に大変で…そもそも、「確定申告って難しい！」と感じる方向けのサービスなので、中の人はより深く理解する必要があります。
今後は、ドキュメンテーションを今以上に強化していきたいです。自分たちも1年経つと忘れちゃったりしますからね。詳細な設計というより、仕様の部分をドキュメントで残して新しく入った人が苦労しないように、と考えています。

Ｑ. 「レガシーなシステムをリプレイスする業務が各社増えている印象ですが、そのような大規模改修で一番気を付けるべきコトはありますでしょうか？」

（田辺）多くを望まないことだと思います！（笑）リプレイスのあるあるかもしれませんが、「せっかくだからこれも！」という意見を貰うことが多いんですよね。全部詰め込みすぎると、誰かが倒れるか、スケジュールが破綻するかなので…。リニューアルするならそこに集中し、追加機能はその後に作る、という線引きが重要だと思います。

（磯貝）これは、我々のリニューアルからの学びでもあるんですけど、僕が機能ソースをみて新しいシステムの方向性についてレポートのようなものを書いたんですが、新しいメンバーが古いシステムのコードを見ないまま開発が進んでしまうんですね。ソースレベルでもいいので、古いシステムを各々見つめなおす時間を作った方がよかったかな、と。

Q. エンジニア志望の文系学生さんからです。
「チームでお仕事されているというお話がございましたが、プロジェクトにおけるチームはどれくらいでしょうか。また、チームでお仕事することの利点は何だとお考えでしょうか。」

（磯貝）プロジェクトは複数ありますが、5人単位くらいでいくつもチームを作って複数の開発を進めます。各々が得意ではないところも含めて他の人と分担できる仕組みなので、チームとして成果を上げていただければいいと伝えています。
弊社全体が考え方として「多様性」を大切にしているのもあるかもしれません。フロントが得意な人も、バックエンドが得意な人もいる。どちらかに偏ってしまってもつまらないので、お互いの強み・弱みをいかして話し合いながら進めていくのが、チームで働く醍醐味なのではないでしょうか。

（田辺）私たちも「2 pizza rule」が原則で、多くても1チーム8人単位。入替や分割は柔軟に行っています。月並みかもしれませんが、1人でできることには限界があるので、得意なことを各自が持ち寄ったら、1人×人数分とまではいかなくとも、一人よりはチームの方が実現できることも増えますよね。

Q. 最後に一言お願いします！

（田辺）思った以上に、LITALICOさんとの共通点が多くてびっくりしています！悩みポイントとかも似ていましたね。お互いにいいとこどりしあえたら、お互いのシステムが良くなるかもしれないなと。外部要因に振り回されがちなプロジェクトですけど（苦笑）、これからも頑張っていきましょう！

（磯貝）僕も同じようなシステムだなぁと思いました。LITALICOという会社については、エンジニアが転職する先としてはすごく面白味があると自負しています（Webでも、Techでも、SIerでもない）。今回の話を聞いて興味をもっていただけたら嬉しいです。エンジニア、絶賛募集中です！