こんにちは、マネーフォワード CTO の中出（なかで）です。
CTO の私が、普段「なにを感じて、どんなことを考えているか」について、四半期に一回社内へ共有している内容を一部編集し、 Developers Blog に公開したいと思います。
前回はこちら：マネーフォワード CTO が考えていること（2023 年 9 月）
技術的負債とその返済
7年前、2016年12月にCTOになって、最初の大きな決断は、すべてのサービスが一つの大きなデータベースに依存している状態から抜け出すことでした。私たちは小さなベンチャー企業でしたから、素早くサービスを立ち上げるためにデータベースを分割せず、大きなデータベースを共有するという技術的な意思決定がされていました。
しかし、その決定はサービスが軌道に乗るにつれて問題を引き起こすようになります。毎月、給料日になるとデータベースの負荷が高まり、全サービスがスローダウンしたり、あるいは1人のユーザーの操作によって全サービスが利用停止に追い込まれたり、信じられないことが頻繁に起こっていました。
このアーキテクチャはいつしか「桃園の誓いアーキテクチャ」と呼ばれるようになりました。これは、中国の物語『三国志演義』に出てくる有名なシーンから名付けられています。劉備、関羽、張飛という英雄の三人が、義兄弟の誓いを結び、生まれた日は違うけれど死ぬ日は一緒だと誓うシーンです。私たちのサービスもバラバラのタイミングでリリースされていましたが、ダウンするタイミングは誓ったかのように同じという皮肉です。
この問題の解決が、私がCTOとなったときの最初の大きな決断であり、そのプロジェクトのことを「桃園脱却」と名付けました。
プロジェクトは最初の数年で大きな進展がありました。大規模なデータの切り離しをすることができたので、負荷が原因となるサービスの遅れはほとんどなくなりました。また、全体がマイクロサービスアーキテクチャへと再構築されていき、重要な基盤として認証認可やデータ取得のためのマイクロサービスなどが誕生しています。
そして、今年になって、開発時から共有データベースを前提として構築されたサービスから共有データベースへの直接的な依存を取り除くことが初めてできました。それも一つばかりではなく、続々と「桃園脱却」に成功するサービスが生まれました。まだ全てのサービスが「桃園脱却」できているというわけではないのですが、来年にはほとんどのサービスで作業が完了する予定です。
トータルで8年です。会社設立から4年半で積み上げた技術的負債を返済するのに、その倍くらいの時間がかかりました。ユーザー影響やサービスの追加機能開発にできるだけ影響を与えず、根幹のアーキテクチャーを変更していくのは技術的にも難易度が高く、多くの開発チームとの連携が必要でした。
とはいえ、技術的負債を生み出した最初の意思決定が間違っていたとは考えていません。最も早くサービスを開発し、ユーザーに価値を提供できる方法がデータベースを共有する方法であり、そのおかげで私たちの事業は成長することができました。
マネーフォワードの開発組織の強みのひとつとして、たくさんの新しいサービスをユーザーに提供し続けることができることがあります。そして、その裏側には「桃園脱却」のようなプロジェクトを進めているチームもいます。こうしたチームの貢献によって、開発者がサービス開発に集中することができる環境が実現できています。
出社方針について
マネーフォワードでは、出社の新方針を定めました。これによって、原則週2日（推奨は週3日）のオフィス出勤とすることとしました。このときの議論で考えたことを少し共有させてください。
私はハッカソンをしたり、開発合宿をしたり、みんなで集まって何かを作ったりするのが楽しくて好きです。先日、AWS GameDayで多くのエンジニアがオフィスに集まって盛り上がっているのを見て、うらやましく感じていました。やはり、大勢が集まるからこその楽しみもあります。私はそういったお祭りのような雰囲気が大好きです。
大規模な技術カンファレンスも、一時期のオンラインイベントだけの提供から、オンラインとオフラインのハイブリットで開催されるようになりました。技術カンファレンスは、セッションの内容を聞くだけであれば、オンラインで十分ですし、利便性も高いかもしれません。
しかし、ずっと労力がかかるにもかかわらずオフラインでの開催をするというのは、そこに特別な盛り上がりがあるからです。主催者のみなさんが、どのようなカンファレンスにしたいのか、どのようなコミュニティにしたいのか、そのような思いがあって方針を決めているのでしょう。
私はCTOですから、私たちの会社について考えます。どのような会社にしたいのか、どのような場にしたいのか、思いを込めて方針を決める必要があります。私は、私たちの会社をみんながより熱狂して働ける場にしたいと考えています。単にアウトプットや効率だけを求めるのではなく、一人一人が集まってみんなでミッションに向かって熱中して働く、そういう会社にしたいと思っています。
出社の方針を決めるときにも、そのことを考えました。大勢が集まるからこそ生み出される特別な熱量は重要です。出社頻度を減らしていくことと、熱量を持って働く雰囲気づくりの両立は難しいと考えました。まったくの無理ということではないのかもしれません。しかし、その難易度はずっと上がるはずです。
出社をすることで、集中して仕事に取り組むエンジニアにとって、作業の効率が落ちてしまうこともあるでしょう。しかし、そこだけにフォーカスすると、中長期的に素晴らしいサービスを提供しつづけることが難しくなってしまうのではないでしょうか。そのサービスを生み出す人の熱気こそが、ユーザーに感動を届けるプロダクト作りに必要だからです。
もちろん、出社が全ての解決策ではありません。パッションを持って働ける会社になるためには、さまざまな工夫が求められます。力不足を感じる場面も多くあります。また、意図や背景をしっかりと丁寧に伝えられなかった部分もありました。
しかし、出社方針の変更に関する決定は、中長期でみてそれが私たちの成功にとってより良い選択だと信じています。これからも、どうやったら会社をみんながより熱量を持って働ける場にできるか、そして最高のサービスを提供しつづけられるかを考え続けていきます。
