こんにちはマネーフォワード CTOの中出(なかで)です。 どうやらエンジニアブログが年間の投稿数100に到達しそうだということで、最後の100番目を私が担当させていただくことになりました。 luccaさん、エンジニアブログの盛り上げと最後のお膳立てありがとうございます。
なにを書こうか考えたのですが、実は今年の11月末をもってCTOに就任してから丸5年がたち(2016年12月1日就任)、色々あったなーなどと一人で感傷に浸っていたのを思い出し、そんな感じのことを書いてみるのも良いんじゃないかと考えました。 特になにか主張したいことがあるわけでもなく、単なる個人的な振り返りです。
そもそも
私はマネーフォワードの創業メンバーではありませんし、CTOとして入社したわけではありません。 元々創業メンバーの一人がCTOを務められていましたし、自分がCTOになりたいとも思うこともなければ、なるという想像をしたこともありませんでした。 たまたま、前任の方がCTOを退任することを決められて、後任探しをする中で私に声がかかり、私は元来振られた仕事をお断りすることをあまりしない性質なのでお受けしてみることにしました。 こういう時はいつも思うんですけど、まあ命までは取られないだろうと。 私は、私と一緒に仕事してくれている方々はみな気づかれているかと思いますが、すごく楽観的なのです。
とはいえ
楽観的にお受けしてみたものの、はっきり言ってなにをやればいいか全然わかりませんでした。 初期のCTOあるあるなのではないかと思います。 何やればいいかわからないので、取り敢えず社内のエンジニア全員と1on1してみようと考え、それを四半期毎に繰り返しやってみようと思いました。 それぞれのエンジニアから1on1で課題感を聞いていたのですが、私もそれまで現場のエンジニアとして普通に働いていたので、そんなに目新しい課題は見つからず、しかもエンジニアの数がどんどん増えるので、全員と1on1していくことが回らなくなり、2周ほどしたところで全員と1on1する試みは打ち切られました。
当時の状況
当時の状況を書いておきます。 私がCTOになった当時のエンジニア組織は60-70名程度だったと記憶しています。マネーフォワードが設立されて4年半が経過していました。 まあまあ既に大きくなっていたけど、全員顔と名前が一致する、ほぼ全員と話したことあるぐらいの感じでした。 サービスはME(家計簿)、クラウド会計などを含めて既に7-8個あり。それぞれのサービスごとにチームが作られていました。 今もそうですが1サービスあたりにすると10名以下ぐらいの開発チームで構成されていて、それぞれが独立してサービスの意思決定をして開発している。 一方、全てのサービスが一つのDBを共有して動いているという状況でした。
DB分割
私がおそらく、CTOになって一番最初に行った意味のある意思決定は、上記で書いた全てのサービスが一つのDBを共有している状態から、各サービスごとにそれぞれ別のDBを持つようにすることでした。 色々あるので細かいことは省きますが、当時は一つのサービス（主にマネーフォワードME）から発行されるSQLがDBサーバーの負荷を上げてしまって全てのサービスが停止（あるいはスローダウン）してしまうということが頻発していました。 バラバラのタイミングでリリースされたサービスたちが、障害時には同時に停止することから、社内ではこれを桃園の誓いアーキテクチャと呼んでいます。（三國志をご存知でない方申し訳ありません。本題からそれるので、桃園の誓いアーキテクチャのついてはこれ以上触れません）
各サービスは同じDBを使っていたことで、簡単に他のサービスのテーブルを参照できてしまうために、別のサービスが所有しているテーブルがジョインされたクエリがなんの躊躇いもなく自然と発行されていました。各サービスのスケーラビリティの観点と各サービスが密結合していることで、どんどん複雑性が増してしまうことの観点の二つから、DB分割していくことを意思決定しそれをミッションとして実行するチームを作りました。
この意思決定はCTO就任直後にやっているのですが、そして大変お恥ずかしい話ですが実はまだDB分割は完了していません。幸いにも新しく作るサービスは個別のDBを持つようにするという方針は守られているので、状況が悪くなることはありませんし、DB分割も終盤の局面になってきていて元々の課題であったDBサーバーの負荷で全サービスが停止するようなことはほぼ起こらなくなっていますが、創業から4年半かけて積み上げた技術的負債が5年かけても返済しきれていないという事実は考えさせられるものがあります。
各サービスのグロースも優先しなければいけないために、技術的負債の返済には長期的な目線で向き合う必要があります。まだ負債の返済は終わっていませんが、負債が拡大し続ける状況から脱することができたことは価値があったと思います。
CTO室
上記のDB分割のためのチームを作ったことがきっかけでCTO室という組織を作りました。全社的な、あるいは複数のサービスにまたがるような技術的負債の返済を主なミッションとした組織です。 ちなみに私はCTO就任当時から、なにか特定のサービスの開発に関わるということはほとんどやっておりません。横断的な立ち回りに徹しています。 それぞれのサービスの開発の優先順位付けや日々の意思決定にはほぼ関わっていません。各サービスの方針に口を出す権限を持っていないぐらいに思っています。各サービスのことは担当する開発チームが最適な意思決定できるはずだと信じております。
一方、各サービスチームの意思決定はどうしても個別最適な意思決定になりがちなので、時には全体最適で意思決定して取り組む必要がある課題も出てきます。 私はCTO室を作って以来、全体最適の取り組みにアサインするべきリソースをCTO室で確保するようにしていて、タイミングによって増減はありますが、おおむね10-15%ぐらいのエンジニアにCTO室で働いてもらってます。 各サービスの開発チームにアサインされているエンジニアの人事権は私にはありませんが、CTO室のリソースは全社的な課題にアサインしたり、その時に最もフォローが必要なサービス開発チームを支援したり等の調整弁になっていて、リソース調整のスピードと柔軟性を高めることに役立っています。
開発拠点
マネーフォワードの一番最初の国内開発拠点である福岡開発拠点の検討を開始したのは2017年5月で、半年後の12月に開設しています。 同時期に札幌、仙台、名古屋、大阪、京都も開発拠点の候補地として上がっていましたが、最終的に福岡に決めたのは福岡で開発拠点を立ち上げることにモチベーションをもったエンジニアがいて、その人が能力的にも人格的にも拠点長としてふさわしいと判断したからです。 マネーフォワードでは福岡以降も京都、大阪、名古屋と次々と開発拠点を開設していますが、基本的には全て同じ発想で開発拠点の開設を決めていて、つまりは拠点長人材ファーストで開発拠点を決めています。 当然ですが地方都市での開発拠点はエンジニア採用の強化を目的に開設しています。都市の人口規模などによって、どの程度の採用が見込めるかが変わってきますが、一番大きな変数は拠点長人材であり、その人がどれだけ採用や拠点運営で手腕を発揮するかが一番重要であると判断したのです。 今では各開発拠点は拠点長の人柄によってマネーフォワード共通のカルチャーの中にも独自のカルチャーを持ち、東京を含む各拠点が良い意味でライバルの関係で切磋琢磨して新しいサービスを自らの拠点に引っ張ってくるように努力しています。
ベトナムでのサービス開発
マネーフォワードはいくつかのサービスをベトナムで開発しています。最初の取り組みは2017年8月から始まりました。 昔からそして今も継続してエンジニアの採用がビジネスの成長のボトルネックになっていますが、ベトナムでの開発の取り組みはそんな状況を変えることを狙ってスタートしています。
ベトナムで開発を始める時にいくつかの方針を決めました。 - ベトナムでサービスを開発する時は、そのサービスの開発を全てベトナムでやる（日本の開発チームの下請けのような扱いはしない） - 開発の初期にプロダクトオーナーが自らベトナムに行ってチームビルディングを行う - ベトナムの開発チーム内のコミュニケーションは英語を中心とする - オフショア開発でよくあるようなコスト圧縮を目的としない
この方針はコロナ禍でどうしてもプロダクトオーナーがベトナムに行けないなどを除き現在も守られていて、現在多くのサービスがベトナムで開発されています。 ベトナムに限らず、マネーフォワードでは一つのサービスはどこか一つの開発拠点で開発しているためベトナムは東京を含む他の開発拠点とも対等な関係として独立していています。 他の拠点と比較してもっとも速いスピードでエンジニアの採用が進んでいて、もちろんエンジニア採用の課題がなくなったわけではないですが、課題が大きく改善することに貢献してくれてます。
VPoE
マネーフォワードは2017年9月29日に東証マザーズに上場しています。私がCTOに就任してから10ヶ月ぐらいたったタイミングです。 詳しくは書きませんが、この頃からエンジニア組織でサービス開発にうまく向き合えないような事が起こりだしました。オブラートに包んだような書き方をしましたが、つまりはエンジニア組織が荒れだしました。エンジニアは100名を超えるぐらいになっていたと思います。 当時は組織のマネジメントをミッションとしているエンジニアは存在しておらず、よく言えばフラットな組織でした。 複数の開発チームが存在していて、それぞれにリーダーの役割をやってくれている方はいましたが、基本は自らも手を動かしながら自分のチームが守備範囲となっていて、全社的な視点で私と一緒に課題解決に取り組んでくれる人がいなかったのです。
マネジメントキャパシティーがボトルネックで組織をこれ以上拡大させることが出来なくなると感じたために、2018年4月にVPoE(Vice President of Engineering)という役職を設置することにしました。 通常はVPoEは全社で1名であるイメージが強いと思いますが、最初のタイミングから3人のエンジニアにVPoEになっていただきました。 それぞれ開発チームのリーダーとして活躍してくれていて、社内のエンジニアからの信頼されている方達でした。 みなプレイヤーとして自分で手を動かすことも好きな人たちでしたが、以降は明確にミッションが変わり私と一緒にエンジニア組織をマネジメントすることにコミットしていただくとともに、給料も一人200万程度昇給させました。明確にミッションが変わり責任が大きくなるのに給料が変わらないのはアンフェアだし、責任の重みの分だけ報酬も報いるべきだと思ったからです。おそらくこの時の意思決定が私がCTOとしてこれまでに行った意思決定で最良なものでした。
３人が完璧に役割を果たしてくれたために組織の課題が激減しました。また様々な課題解決の打ち手をVPoE達と相談して考えたり、手分けして実行できるようになり、課題を対処したり先回りしたりするスピードが圧倒的に早くなり、エンジニア組織を再びスケールさせることが出来るようになりました。
仮想通貨関連事業
2018年５月に仮想通貨関連のビジネスを行うために、マネーフォワードフィナンシャル株式会社という子会社を設立しました。 結果から先に書くと、約一年後の2019年4月に仮想通貨関連事業への参入延期を発表していますので、現在は主だった活動は行なっておりません。 私も中心メンバーの一人として参加していて参入延期の決定までの約1年間は自分の時間の半分以上を費やし、自らもコードを書いて仮想通貨取引所の開設を目指していました。 仮想通貨取引所の開発はほぼ終了していて、リリース間近というタイミングでしたが、私はそこでおそらくエンジニア人生で一番辛かった経験をしました。 仲間と一緒に長期間開発してきたサービスを一度もユーザーに届けることなくクローズさせることを、中心メンバーの一人として意思決定したのです。
当時の一緒に開発していたエンジニア達は、何人かは退職していますがほとんどが今もマネーフォワードに残ってくれています。 仮想通過取引所はGolangで開発していたのですが、その時のメンバーが中心となってその後のマネーフォワードでのGolang導入が大きく進捗しました。
技術ポートフォリオ
マネーフォワードは創業以来長らく、Ruby on Rails(RoR)を中心にサービスを開発してきましたが、現在はバックエンド技術にRoRだけではなく、GolangやKotlinなどを使って開発しています。エンジニア組織にとって開発言語の変更はそれなりにインパクトのあることだと思います。 実際にRoR一辺倒だったバックエンド開発にGolangを導入する時は社内になにかしらアレルギー反応のようなものがあったと感じました。 ただそれなりの規模となった開発組織で技術を固定し続けるのはかなりリスクが大きいと感じています。技術には流行り廃りがありその変化について行けない場合には悲惨な未来が待っています。今も世界中でCOBOLやVisual Basicなどで開発されたシステムが稼働しています。 私たちは技術のトレンドを常にフォローして適切に社内の技術のポートフォリオを維持することを決めました。既にGolangは社内への導入が進み、Golangを使って開発するエンジニアの割合は増加傾向にありますし、Kotlinはまだ途上ですが少しづつ導入事例が出てきています。最近はRustもトライアル的に使っています。 マイクロサービス化が進行しているので小さな単位で新しい技術を使うことが簡単にできるようになりましたし、変化に強い組織を作ることが大事であると考えています。
英語化（グローバル化）
2021年8月に、2024年度末を目処に社内のエンジニア組織の共通言語を英語化することを決めました。 決めたからといってそれが実現されるわけではなく、その道のりはかなり厳しいですし今もどのように英語力を身につけるか、どのように移行していくか探り探りの状況ですが、社内のエンジニア達は想像以上にポジティブな反応を示してくれました。 2017年後半から外国籍のエンジニアが増え始めて、かなり色々な分野で活躍してくれていましたし、今後もますます外国籍のエンジニアが増えていくことが予想される中で、彼らに日本語を努力して使ってもらうよりかは、私たち日本人が英語を使えるようになった方が、会社も個々のエンジニアも将来の可能性も広がると理解してくれているのだと思います。
この意思決定の結果はまだ見えていませんが、多くの意思決定は意思決定そのものよりも意思決定を正しいものにするためのその後の行動が重要ですので、しっかり意思決定が正しかったと言えるように励みたいと思います。 おそらく私がCTOとして行った最大の意思決定になるのだと思います。
最後に
CTOになって5年間、良いことも悪いこともありましたし、時々なにかの意思決定もしてきました。 15年間CTOを務められているGREEの藤本さんのような、私などよりももっと多くの経験をされている偉大なCTOの先輩方もいらっしゃって、なんだか気が遠くなったりもします。 いつまで続けられるかわかりませんし、自分自身が会社の成長のボトルネックにならないようになりたいとつくづく思いますが（というかなっている自覚があって辛いのですが）先にも書きましたが元来の楽観的な性格ですので、楽しみながらもうしばらく取り組んでいきたいと思いますし、少しでも貢献できるようにしっかりと自分自身が成長していきたいと思います。
今回はそこそこ上手くいっていると感じていることしか書いてないかもしれませんが、悪い意思決定もたくさんあったと思います。 常にVPoEであったり他の経営メンバーからのサポートがありましたし、何よりもエンジニア組織や会社全体に他者をRespectする文化があり、それに助けられてきました。 マネーフォワードのビジネスが伸び続けることが前提の意思決定ばかりで、むしろ私は役割の多くは会社がどんどん成長することを前提に、それを阻害しないようにすることでした。そういう恵まれた状態にいるからこそ私のようなものでも５年間CTOを続けてくることが出来たと感謝しています。
今後はエンジニア組織のグローバル化がとにかく最重要なのでそこに注力しつつ、グローバル化が終わった後のエンジニア組織を前提とした、後継者探しや後継者育成に取り組んでいきたいと思います。
こんな内容もなくひたすら長い個人の振り返りにお付き合いいただいてありがとうございました。 それではみなさま、良いお年を
マネーフォワードでは、エンジニアを募集しています。 ご応募お待ちしています。
【サイトのご案内】 ■マネーフォワード採用サイト ■Wantedly ■京都開発拠点
【プロダクトのご紹介】 ■お金の見える化サービス 『マネーフォワード ME』 iPhone,iPad Android
■ビジネス向けバックオフィス向け業務効率化ソリューション 『マネーフォワード クラウド』
■だれでも貯まって増える お金の体質改善サービス 『マネーフォワード おかねせんせい』
