こんにちは、マネーフォワード CTOの中出(なかで)です。
CTOの私が普段なにを感じて、どんなことを考えているかを、改めて言語化して、社内に共有するという取り組みをしています。 そうしたところ「当社のエンジニア組織に興味を持っている方にも読んでいただくのがいいのでは？」という社内の意見もあり、今回公開することにしました。
もちろん、日々考えていることは変化しているので、今後は四半期に一度ぐらいの頻度で、変更があれば更新していきます。 ※公開用として、社内向けの内容を一部編集しております。
これからのマネーフォワードのエンジニア組織について
まず、マネーフォワードのエンジニア組織として「どこを目指すのか」という話をしたいと思います。
もちろんビジネスには「やれる・やれない」という議論も必要ですが、まずは私たちが「どこを目指すのか」という意志が必要です。
そして、「どこを目指すのか」を決めた時点で、どこまで到達できるかが決まると思っています。そのため、まずはその話をさせてください。
私たちよりも前を進んでいるIntuitという企業
海外には、先行して私たちと同じようなサービスを展開している企業があります。 その1つとして挙げられるのがアメリカのIntuitという企業です。
Intuitの社内にはJavaの開発者がいたり、ハーバードやスタンフォードのPhDがたくさんいます。
私たちよりも前を進んでいるプレイヤーに追いつくためにはどうしなければならないかを考えるときに、社内で働く人材の優秀さで追いつくことは最重要です。
もちろん一足飛びには出来ないですし、今はそれを口にするのもおこがましいのかも知れない。しかしそういう目線を持ち続け、それに向かって少しずつでも前に進めていくことが必要だと思っています。
会社のMission/Vision/Value/Cultureが魅力的であることはもちろんですが、待遇しかり、やりがいのあるチャレンジや自主性の発揮しやすさ、働きやすさなど総合的に魅力を向上させないといけないと考えています。
そもそもできるのか？
できると思っていますが、まだまだ足りないことがたくさんあります。
ありがたいことに、以前に比べてマネーフォワードという会社の知名度の向上、地方拠点やMoney Forward Labの影響もあり、優秀なエンジニアの方に接触する機会が増え、採用に繋がっていると実感しています。
そして国内だけでなく、海外採用ルートの選択肢やノウハウも溜まってきました。
優秀なエンジニアの方を採用できはじめている一方で、やはり一番大事なのは、すでに社内で働いているエンジニアの成長カーブを最大化すること。そのためにも学習機会やチャレンジをもっと増やすことが大事だし、会社全体でチャレンジを応援する雰囲気づくりも大切と考えています。
必要なスキルの変化とメンバーの要求
それではどんなチャレンジが必要なのか。その背景には、サービスのステージの変化に伴い、特にバックエンドエンジニアにおいて必要なスキルセットが変化しています。
正確には、今まで必要だったものが不要になったのではなく、必要なスキルセットが増えています。 全員がスキルセットを増やす必要があるわけではないですが、組織レベルで必要なスキルセットを持った人材を確保する必要があります。
これを機会に自分のスキルセットを拡大させたいと思う人には、その機会を用意していきたい。どのようなスキルセットが求められはじめているかというと、具体的には以下のようなスキルセットです。
サービスの大型化に対応するスキル
ユーザーやデータが増えても、応答性能やスケーラビリティーを確保する必要があります。
応答性能やスケーラビリティーの問題は、多くの場合、プログラミングスキルだけで解決するものではありません。
アーキテクチャーの決定が、そのサービスの応答性能やスケーラビリティーの限界を決めます。
軽自動車にいくらお金をかけてチューニングして優秀なドライバーに運転させても、F1レースで勝つことは難しいはずです。
もちろん、より最適なアルゴリズムやSQLなどのチューニングで、応答性能やスケーラビリティーは改善します。そうした努力をするのは、全てのバックエンドエンジニアの責務です。しかし根本的な解決策は、アーキテクチャーを変えることです。例外はあるかもしれませんが、多くの場合はそうです。少なくとも私の経験上。
私たちは、サービスの成長に合わせて、選択するアーキテクチャーを変えていく必要があります。 マネーフォワードには、たくさんのサービスがあります。 創業間もないころに開始した『マネーフォワード ME』のように950万人を超えるユーザーがいるサービスもありますし、リリース直後でユーザーがまだまだ少ないサービスも存在します。
すでにいくつかのサービスは、アーキテクチャーの見直しが必要になっています。
まずは『マネーフォワード クラウド会計』です。おそらくそのあとは『マネーフォワード クラウド経費』や『マネーフォワード クラウド給与』がそういうステージを迎えると推測しています。
冒頭に書いた通り、全てのエンジニアにこういうスキルの取得を求めるものではありません。
ご存知のように、私たちはどんどん新規サービスを開発してリリースしています。そういったサービスは、長年私たちのビジネスを支え続けているRuby on Railsを使い続けます。
Ruby on Railsは、現時点で、新規サービスを立ち上げる開発生産性が最も高いと判断しています。0-1のステージにおいて最も効果的であり、多くの場合は1-10でも有用です。ただし10-100のステージでは、デメリットが見えはじめます。しかし10-100のサービスにおいても、Ruby on Railsの利用範囲がゼロになることはないと考えています。
10-100のステージのサービスは、機能の一部でGolangをメイン言語とし、非同期化や並列化を進めることで、応答性能やスケーラビリティーの向上を目指します。またKubernetesやサーバーレスアーキテクチャーなどを活用して、スケーラビリティーや可用性の向上を目指します。
機能を開発するスピードはRuby on Railsには及ばない場合が多いでしょうが、今後も引き続き、ユーザーに価値提供し続けるために、そういう技術選択をしていきます。
Googleの「10の事実」と呼ばれる経営理念の一つに「遅いより速いほうがいい。」という項目があります。
Google は、ユーザーの貴重な時間を無駄にせず、必要とする情報をウェブ検索で瞬時に提供したいと考えています。自社のウェブサイトにユーザーが留まる時間をできるだけ短くすることを目標にしている会社は、世界中でもおそらく Google だけでしょう。Google は、Google のサイトのページから余計なビットやバイトを削ぎ落とし、サーバー環境の効率を向上させることで、自己の持つスピード記録を何度も塗り替えてきました。検索結果の平均応答時間は 1 秒足らずです。Google が新しいサービスをリリースするときには、常にスピードを念頭に置いています。モバイルアプリをリリースするときも、新時代のウェブにふさわしい高速ブラウザの Google Chrome をリリースするときも同じです。今後も、さらなるスピードアップを目指して努力を続けていきます。 出典：Google が掲げる 10 の事実
非常に重要な観点だと思っています。この観点をマネーフォワードも重視していきます。
私たちのサービスも、ユーザーの生産性の向上や省力化を目指しています。ユーザーの仕事時間を、つまりは私たちのサービスを利用する時間を、1秒でも減らしたいのです。
これまで、私たちの技術選定においては、開発生産性を優先してきました。機能を素早く開発してユーザーに提供することが、最大のUser Focusだったのです。一方10-100のステージのサービスは機能を増やすだけでなく、一つ一つの機能をより洗練させていくことも重視していくべきです。
別の言い方をするとユーザーが増えると一つの機能をより良いものにすることに、より多くのコストをかけられるようになります。
例えば、あるサービスのMAUが100万人だったとします。私たちがこれまで100時間で開発できていた機能に500時間をかけたとします。しかしこの開発によって一人のユーザーの業務時間を毎月1分短縮できたとするならば、社会全体の生産性を向上させることができています。
ユーザーが増えたサービスにおいては、こういう判断ができるようになってくるのです。
また全く別の観点として、一般的にユーザーが増えるとエッジケースやレースコンディションなどが原因の不具合の発生頻度が高まります。
当初はなんとなく動いていたサービスでも、不具合調査や対応に時間を使うようになります。
これらの問題は、開発者のスキルや経験が向上することで防げるようになるはずです。
私たちは、今よりもスキルを改善していく必要があります。
マイクロサービスに対応するスキル
これもサービスの大型化に対応するスキルの一部ではあるのですが、これはこれで非常に幅広い意味を持つので、あえて項目の1つとしました。
あらかじめ言っておきたいのは、全てのサービスをマイクロサービスにしたいわけではありません。
モノリスで問題ないサービスは、あえてマイクロサービス化する必要はありません。
やはり10-100ステージ以降のサービスが、マイクロサービス化の候補になるでしょう。 最初は『マネーフォワード クラウド会計(Plusを含む)』から始めます。次はおそらく『マネーフォワード クラウド経費』になると思っています。
マイクロサービス化のメリット/デメリットは、いろいろなところで取り上げられているので、あえてここでは一つ一つを取り上げません。一点だけ強調したいのは、マイクロサービス化した後は、そのチームは、より広範囲のスキルが必要になります。設計、開発、テスト、運用という工程でチームを区切るのではなく、一つのチームでマイクロサービスの全ての工程を対応することになります。
職能で区切ることでそれぞれの生産性を高めて全体の生産性を高めるというアプローチではなく、一つのチームがサービスについての全ての責任と役割とオーナーシップを持つことで生産性を高めようというアプローチです。
これは、マネーフォワードがもともとスモールチームを志向していた理由と、非常に重なる部分があります。
チームメンバーには、インフラや運用を含めたスキルや知識が必要になります。それをわかった上で、マイクロサービス化を進めようとしています。
もちろん、一人の人が全てのスキルを高度に身に付けることは難しいと思います。チーム全員でチームに必要なスキルをカバーすることになるのですが、一人一人がより多くのスキルを身につけるべきであることは間違いありません。そうしないとスモールチームを維持できないのです。
他にもマイクロサービス化を進めるためには、各マイクロサービスの適切な境界線を決めるスキルや、複数のマイクロサービス間でトランザクションが分離しても全体のデータの整合性をどう担保するかなど、設計の難易度が上がります。つまりは、エンジニアに高いスキルを要求するのです。
高いスキルが求められるから「やらない」と判断するのではなく、高いスキルを身に付けるチャレンジを求めたいと思います。高いスキルを身に付けることが難しいということを前提にするのではなく、身に付ける前提でアーキテクチャーを検討していきます。
クラウドインフラの活用スキル
マネーフォワードは今後、クラウドインフラをより活用していくことになります。
クラウドインフラはマイクロサービス化やサービスのスケーラビリティー、可用性の向上、開発生産性の向上において大きな武器になります。
一方、クラウドインフラはランニングコストが問題となります。ですのでクラウドインフラを使うことは投資です。マネーフォワードのエンジニアがクラウドインフラを活用してサービス開発の生産性を向上できないと、投資に対するリターンが得られません。
これまでのようにインフラの管理をインフラチームに依頼するだけのチームには、クラウドインフラはコスパが悪いと考えています。
クラウドインフラは新しいスキルを身に付け、自主性をもってインフラ含めたサービスのライフサイクル全てに責任を持つことにチャレンジするチームであれば、積極的に使っていくべきです。
チームごとに決めればよいのですが、現状にとどまらずにどんどん良いものを使いこなし、よりサービスのユーザー提供価値を高めて欲しいと思います。
Technology Driven実現に向けた施策の見直し
大きな変更点として、今年からエンジニア全員での開発合宿を廃止することにしました。
簡潔にいうと、Valueに掲げているTechnology Drivenを追求する手段として、エンジニア全員が参加する開発合宿を継続することはコスパが悪いと判断しました。
開発合宿は、エンジニア全員に均等に平等に技術的チャレンジを行う機会を提供しようと思って始めたのですが、よりチャレンジに貪欲な人に機会を提供する方針にしました。
具体的には、以下の施策に開発合宿分の費用を振り分けるつもりです。
クラウドインフラ学習の支援
クラウドインフラの活用にチャレンジすることを決めたチームに、その知識獲得の立ち上がりを支援するためのトレーニングや環境の提供に費用を使います。
個別合宿の支援
今実在している、あるいは将来顕在化することが確実なマネーフォワードのサービスの技術的課題を根本解決するために、新しい技術の検討を行うための合宿に限り、その宿泊費用や交通費、新しい技術を試すための費用一式をサポートします。
マネーフォワード版ISUCONの開催
先ほど、Googleの「遅いより速いほうがいい。」を私たちも観点として重視すると書きましたが、それを楽しく競う合う場としての社内向けに開催予定です。 現在開催に向けて準備していますが、本場ISUCON同様に賞金も準備しました。もちろん、私も参加します。
最後に
人は本来なにかしら思いや主張を持って生きていると思ってます。会社以外のコミュニティーでそれを実現させているかもしれません。「自己実現している」「自分らしく生きている」ということです。
でもどうせだったら、会社というそれなりに人生の長時間を過ごすコミュニティーでも積極的に参加、貢献して自己実現できた方がハッピーじゃないかなと考えています。
会社で自己実現できるということは、会社で働くことで「なりたい自分に近づける」であるとか「成長できる」というのも、もちろん重要です。それはいうまでもないのですが、それ以外にも「そもそもなぜ自分は成長したいのか？」「最後はどういう自分になりたいのか？」を突き詰めると会社が実現しようとしていることと自分がやりたいことと一致しているというのは重要だと思います。つまり、自分はMVVに共感しているかどうかということです。
世の中に大きな価値を提供し続けているエクセレントな会社があったとしたら、その会社には会社のMVVに共感している人が多く働いているのではないかと思います。
私は「目的意識が同じ人、それも強い思いを持っている人たちと一緒に働けている」と自分が幸せだと感じます。楽しいだけじゃなくって仕事がはかどるのです。
そういう人が多く集まる会社を作っていけたらと思いますし、そういう人をリスペクトし評価する会社にしたいと考えています。
この会社が、みんなの自己実現の終着駅でありたいとも思います。
そのためになるべくMVVCに共感する優秀な人に仲間になってもらい、なるべく能力を発揮して存分に自己実現してもらいたい。切磋琢磨しながら、仕事で成長し、給料が上がって、経済的にもやりがい的にも満足してもらえる会社にしていきたい。
そんな想いを持っているということを伝えたくて、このブログを書きました。
--
マネーフォワードでは、エンジニアを募集しています。 ご応募お待ちしています。
【採用サイトのご案内】 ■マネーフォワード採用サイト ■Wantedly
【プロダクトのご紹介】 ■お金の見える化サービス 『マネーフォワード ME』 iPhone,iPad Android
■ビジネス向けバックオフィス向け業務効率化ソリューション 『マネーフォワード クラウド』
■だれでも貯まって増える お金の体質改善サービス 『マネーフォワード おかねせんせい』
