はじめまして、マネーフォワードケッサイ(以下、MFK)でフロントエンドなエンジニアをしている@miki_tです。
2020年11月の社名変更と共に、マネーフォワード(本社)からチャレンジシステム制度(※後述)を活用してMFKにJOIN(出向)しました。
今回は、エンジニアの目線からMFKがビジネスを通して、何に挑戦しているのかをお話してみようと思います。
とはいえ、実は私自身、マネーフォワード社内から見ていても、ちょっと謎の集団に見えていました。
近そうで、よく見えないMFK。
面白そうで、こわい気もするMFK。
スゴそうで、なにしてるかわからないMFK。
トンネルを抜けるとそこに何があったのか、異動して見えた景色をご紹介したいと思います。
さっそくだけど、MFKって何してるの?
マネーフォワードグループの中で、実際のお金を扱う Financeドメイン を担うサービスを提供しています。
- 企業間後払い決済サービス、マネーフォワード ケッサイ
- 売掛金早期資金化・ファクタリングサービス、マネーフォワード アーリーペイメント
(引用:マネーフォワード 2020年11月期 第3四半期決算説明資料)
MFKのサービスについて、詳しくはサービスサイトをどうぞ!
MFKのビジネスモデル
マネーフォワードでは、事業者向けにマネーフォワード クラウドを提供しています。
こちらは、ユーザー様自身や士業パートナー様にプロダクトをご利用いただくことでバックオフィス業務の効率化を支える、いわばプラットフォーム型のサービスです。
MFKのコアサービスであるマネーフォワード ケッサイは、企業間の掛け払いに関わる請求業務自体をまるっと引き受けるBPO(Business Process Outsourcing)型のサービスになります。
- 売掛金の入金が保証され、未入金のリスクから解放
- 請求業務(取引先の与信審査・請求書発行・入金管理・督促 …)から解放
といった価値をご利用いただくユーザー様に提供します。 同じtoBのサービスですが、少し違ったアプローチのビジネスモデルです。
BPO型サービスのエンジニアリング
エンジニアの目線では一般的に、BtoBの開発は次のような比較で語られることが多いように思います。
自社開発 vs 受託開発
- 自社開発
- ビジネスを意識した開発に取り組め、社内で直接コミュニケーションが取れるので、必要な調整がかけやすい
- 長期間継続して開発することが多いので利用技術が固定されやすい
- 受託開発
- 幅広い技術を身に付けられるが、ビジネスや何を作るかは依頼主側が決める
- 納期が厳しくなりがち
SaaS vs オーダーメイドシステム
- SaaS
- 不特定多数のユーザーに使われ、各社の運用を考慮しながら機能開発する必要がある
- スケールしたときのビジネスインパクトも大きいが、マーケットフィットしなければ、使われずに終わってしまうこともある
- オーダーメイドシステム
- 依頼主のユーザー様に直接向き合って開発が可能
- 予算という制約によって思うように開発が進められないこともある
私自身も、パッケージ/SaaS開発、システム受託開発の経験があり、それぞれ違った魅力やそれゆえの難しさを乗り越えるところに面白さを感じてきました。
これらと比較して、BPO型サービスであるMFKのモノづくりは次のような特徴があると考えています。
- 業務スコープが絞られている
- 請求業務は複雑なドメイン知識が必要な難しい領域ですが、業務スコープがある程度絞られていることもあり、エンジニア自身もドメイン情報を解像度高く保つことができます
- オペレーションを社内で回している
- 実際にオペレーションするメンバーといつでも直接やり取りできるので、高速にトライアンドエラーを繰り返せます
- 具体的な情報(データ)が社内に集約・蓄積される
- それによって実績データが蓄積されていくので、データから要因や傾向を見つけることや、MLによる自動化といった解決策が取れます
そうです。つまり、DXし放題です。
継続的に開発効率を高めるためのアーキテクチャの見直し。
課題を見つけるためのデータ分析。
審査自動化のためのモデル設計。
ユーザーを戸惑わせないUI/UXの追求。
できることは全部やる。
なんだかワクワクしてきませんか?
※図はイメージです。実際の職場とは異なる場合があります。
MFKではこの特性を活かして、自分たちにとって適切だと考える技術を適宜取り入れながら、より生産性の高い会社を作っていこうとしています。
MFKってどんなとこ?
具体的に採用している技術のお話は他の記事にお任せして、MFKの開発組織の文化を中心にお話できればと思います。
いまでも、やっぱりカオスだった
3年前の立ち上げ初期の全然話が進まないカオスな仲良し感溢れる素敵な記事があるのですが、私もこの記事を読んで、共感していました。
- 当たり前のことを当たり前にできる環境
- その時に最適なものを選択していこう
- 頻度や質が高く、密に連携できたり気軽に相談できたりする
- エンジニアもビジネスサイドの領域に深く関わっている
中に入ってみた感想は、「そのままだった」です。
実際、記事の中で語られている 正しいことを言っている人が正しいことをやっていけるチーム で有り続けるために、いまでも実直に取り組んでいるように感じています。
役割があいまい、それが気持ちいい
フロントエンドエンジニアとしてJOINしましたが、実は、まだフロントの開発はあまりしていません。
- お問い合わせデータの分類・分析(スプレッドシートでExcel芸)
- BigQueryでSQL書いて、データの見える化
- 計画値を元に、未来のシミュレーション・KPI策定
- 改善策をブレストして優先順位付け
- UI改善のためのプロトタイプのデザイン
このように、何でも屋のような動きをしていますが、不思議と物足りなさは感じていません。
いまのチームはサーバーサイドエンジニアとデザイナー、私(フロントエンド)の3人。
それぞれが肩書き上のロールにとらわれず、守備範囲広く得意なところは活かしつつ、必要に応じて役割分担しながら活動しています。
その背景に感じるのは、目的意識という文化。
何のためにやるのかの意識をそれぞれが持っているので最短ルートを通るためになにしようという思考で動いています。 もちろんどう楽しむかも大切で、楽しむためにも最速で進もうとバランスをとりながら走れるチームだと感じています。
いまは、ちょうどゴール設定ができていたので、アクションを取っていくフェーズ。
目下の楽しみは、作りやすさといった制約を一度取っ払って、ユーザーが本当に便利に使えるUI/UXをフロント技術で実現することです。デザイナーとも無茶振り待ってます!と会話しています。
どうやって実現してるの?
この開発文化をどうやって実現しているのか?
これは私自身が、JOINする前に持っていた疑問であり関心でした。
チームリーダーがいない?受け身になれない組織づくり
MFKの開発組織はミッションごとに複数のチームに分かれていますが、チームは2〜3人で構成されています。
そして面白いのは、そこにチームリーダーというロールがありません。
これは、受け身になってしまうメンバーが生まれないようにという思想で設計されています。
それによって、タックマンモデルでいうストーミング(混乱期)・ノーミング(規範期)のステージをササっと駆け抜けて、チームとしてのミッションに向き合える状態が生まれやすいよう工夫されています。
採用がガチ
たとえグループ内異動でも、通常と同等のステップ・基準で選考をしているとのことです。
私の場合、異動するにあたって合計7名(!)と面接の機会をいただきました。
グループ内なので、GitHubやSlackでの会話も全て見れる状態。それでも容赦なしです。
それだけ、一緒に働くメンバーの採用に真剣に向き合っていることでもあると思います。 結果として、JOIN後のイメージがしやすく、安心して異動に踏み切れました。
課題もやりたいことも山積み
さて、MFKの魅力をお話ししてきましたが、やはりまだまだ課題もやりたいことも山積みです。
そして、いまの規模だから”いい感じに”で回ってきたことも、今後、さらにスケールする中で意思疎通の壁にぶつかるかもしれません。
まさにこれから新しいカオスステージに向かおうとしている段階です。
私自身もすでに「地方(京都)からリモート入社」「2人目のフロントエンドエンジニア」という、実験的な人柱属性でJOINしているので、早く貢献できるように取り組んで行こうと思います。
いろんなカオスが待っていると思いますが、これからの日々にワクワクしています。
こんな冒険の機会をくれたチャレンジシステム制度にも感謝です!
そんなこんなで、マネーフォワードからのグループ間異動という形で、MFKの中に入って見えた景色をお伝えしてみました。
MFKの開発、組織づくりにご興味持っていただける機会になれば幸いです。