バックオフィスSaaS「マネーフォワード クラウド」を提供し、企業の生産性向上を支援する株式会社マネーフォワード。経理、人事労務、法務、確定申告など、多岐にわたる領域でサービスを展開する同組織が提供するプロダクト数は、今や40以上にのぼります。

急速に拡大する組織と、技術スタックの異なる40以上のプロダクト群。マネーフォワードでは、これらのプロダクトにおいて一貫したユーザー体験と開発効率の確保に取り組んでいました。2024年に新たなデザインシステム「MFUI（Money Forward UI）」の本格的な提供を始めたものの、改善活動や会社全体への浸透には、組織固有の課題が立ちはだかっていました。

そこで同社は、デザインシステムのさらなる強化と運用体制の構築を目指し、グッドパッチをパートナーに選定。約半年間のプロジェクトでは、ビジョンの策定やグロースサイクルの定義といった戦略フェーズから着手し、その上で「ライブラリやドキュメントの構造改革」を実行するという、多層的なアプローチが採られました。

今回は、MFUIプロジェクトのマネージャーである清川さん、エンジニアの品川さん、デザイナーのつるさん、そしてプロジェクトに伴走したグッドパッチのUIデザイナー乗田にインタビュー。MFUIがどのようにして「感覚値の運用」から脱却し、「データと仕組みで成長するインフラ」へと進化したのか。その緻密なプロセスの全貌に迫ります。

＜話し手＞
株式会社マネーフォワード CTO室 フロントエンド推進部 部長 清川さん
株式会社マネーフォワード CTO室 フロントエンド推進部 エンジニア 品川さん
株式会社マネーフォワード デザイン戦略室 プロダクトデザイン部 デザイナー つるさん
Goodpatch UI/UXデザイナー 乗田拳斗

異なる技術スタックが混在した、40以上のプロダクトを支える「MFUI」

──まずはデザインシステム「MFUI」について、その立ち位置やプロジェクト開始当時に抱えていた課題を教えていただけないでしょうか。

マネーフォワード 清川さん：
現在、マネーフォワードでは、法人や個人事業主向けのバックオフィスSaaS「マネーフォワード クラウド シリーズ」を展開しています。会計、確定申告、請求書、給与計算、勤怠管理など、提供するサービスは多岐にわたり、BtoB領域のプロダクトだけでも今や40以上にのぼります。これだけ多くのプロダクトがある中で、一貫性を維持しながら併用体験を提供することは簡単なことではありません。

そのため、2021年ごろからデザインの標準化に向けてデザイナーによる「UI Design Standard（UIDS）」という取り組みが進んでいました。40以上のプロダクト間でUIの共通化を目指していたものの、UIDSだけでは実装のバラつきを解消できず、標準化されたデザインをユーザーに提供することには至らなかったことが大きな課題でした。

──40以上のプロダクトとなると、開発された時期も技術もさまざまですよね。具体的にはどのような状況だったのでしょう。

マネーフォワード 品川さん：
デザインデータ上はそろっていても、実際のプロダクトの実装現場では、技術スタックがバラバラでした。あるプロダクトはReactを使っている、別のところもReactだけれど、異なるコンポーネントライブラリを使っている、また別のところはVue.js、あるいはRailsのテンプレートエンジンを使っている……といった具合です。

そのため、実装されるプロダクトのレイアウトや振る舞いが微妙に異なるといったことが起きており、プロダクトごとに使い方や使いやすさが異なる状態が続いていました。

──スタックについては、開発当時のトレンドもあるでしょうし、開発にあたるメンバーにもよるところがあって、確かに統一するのは大変そうです。

マネーフォワード 清川さん：
そこで2024年にフロントエンドエンジニアの横断組織が立ち上がり、デザイナーとエンジニアがタッグを組んで、実装用ライブラリも含めた強固なUI開発基盤「MFUI」の開発が始動しました。また、マネーフォワードのベトナム拠点でも、UIDSをベースにした独自のライブラリ開発が進んでいた経緯があり、それらも統合・再構築しながら、全社で使える新しいデザイン基盤の開発を進めていました。

──すでに1年半運用され、コンポーネントやガイドラインも拡充されていた中で、今回改めて外部パートナーであるグッドパッチにご依頼いただいたきっかけは何だったのでしょうか？

マネーフォワード つるさん：
MFUIの利用者は増えていたのですが、「どう使ったらいいのか分からない」「どこに何があるのか分からない」といった声がデザイナーやエンジニアから上がり始めていたんです。開発当初から2024年頃までは、コンポーネントなどのコンテンツを充実させることを優先していたこともあり、コンテンツの整理はチーム内部の目線による評価に留まっていたというのが実情です。

加えて、運用者の視点では、すでに提供が始まっているデザイン基盤に対して、稼働を止めずにどのように改修を進めることが最適か。どこを目指して改善すべきかという点に非常に強い課題感を持っていました。

マネーフォワード 清川さん：
開発は進めていたものの、チーム全体としても「このデザインシステムは本当に良いものになっているのか？」「今後どのように拡張していくべきか？」という点において、自分たちの知見だけでは判断しきれない部分がありました。

また、組織の規模や提供するライブラリの大きさに対して、チームのリソースの不足が切実な問題としてありました。

これまでの取り組みを第三者視点でレビューしてもらい、デザインシステムとしての評価や今後の拡充方針の策定について専門的な知見を入れたかったこと。そして、40以上のプロダクトチームへの浸透活動や効果測定といった「運用・グロース」のフェーズにおいて、私たちのチームだけでは手が回っていない課題を解決したかったことが大きな理由です。

──デザインシステムの構築支援を行う企業は他にもありますが、その中でグッドパッチを選んでいただいた決め手はどこにあったのでしょうか？

マネーフォワード 清川さん：
複数社とお話しさせていただきましたが、グッドパッチさんが最もデザインシステムに関する実績と知見が豊富だと感じたのが一番の理由です。グッドパッチさん自身が「Sparkle（スパークル）」という独自のデザインシステムを構築・運用されている実績や、さまざまな組織のデザインシステムの構築・運用を支援している実績があったため、それらの知見に基づいた提案には非常に説得力がありました。

他にもいくつかの会社を比較検討しましたが、グッドパッチさんは、私たちの状況や課題に合わせた柔軟な動き方を提案してくれたのが印象的でした。

単に「これを作ります」という成果物の構築ではなく、専門家的なアプローチで、弊社が抱えている課題を解決してくれると感じた点が大きかったです。当時の私たちが求めていたのは、単なる制作代行ではなく、チームの一員として動いてくれるパートナーでしたので、その期待に応えてくれそうだったのが決め手でしたね。

Goodpatch 乗田：
私自身、マネーフォワードさんのプロダクト開発やデザインへの取り組みは、他社と比較してもかなり進んでいる・成熟しているという印象を持っていました。

すでに高度な運用がされている中でさらに良くしていくためには、セオリー通りにコンテンツを拡充するだけでは不十分です。既存のコンテンツを生かしながら、運用の中で生じた課題を特定して解決するアプローチを重視して提案を進めました。

現状の「分析」から、3つの支援方針を策定する

──プロジェクトではどのような流れで改修作業を進めていったのでしょうか？

Goodpatch 乗田：
いきなり改修を進めることはせず、まずは「分析」のフェーズを設けました。既存のMFUIやMFUIの前身であるUIDSを構成している要素をマッピングしたり、どのようなステークホルダーがいるのか、どのように利用されているか、そして現状と理想のギャップはどこにあるのかを可視化することから始めました。

マネーフォワード 品川さん：
プロジェクトが始まってから最初の数週間は、徹底的に現状のヒアリングとコンテンツの分析をされていましたよね。特につるさんとは密に連携をとっていた印象があります。

マネーフォワード つるさん：
そうですね。今のMFUIの構造や、なぜこうなっているのかという経緯をすべてお話ししました。運用する中で私たちが感じていた課題や、現場からのフィードバックも包み隠さず共有しました。

Goodpatch 乗田：
ヒアリングで見えてきたのは、「運用者視点での管理しやすさ」と「利用者視点での使いやすさ」のズレです。既存のMFUIは、少人数の運用チームがいかに効率よく管理・保守するかという観点では最適化されていました。

しかし、利用者が40プロダクト、数百人のエンジニア・デザイナーへと拡大する中で、「使いたいコンポーネントが見つからない」「ドキュメントのどこを見ればいいか分からない」という検索性の低さがボトルネックになっていたのです。そこで、今回のプロジェクトでは「運用者視点から利用者視点への転換」をテーマに、以下の3本柱を策定しました。

1. ビジョンの明文化
2. 利用調査による現状把握
3. アセットのアップデート

今回はこの順番通りに、大局的な「定義」から詳細の「改善活動」へと、ステップを踏んで進めていきました。

ビジョンを言語化し、「グロースサイクル」でMFUIの成長モデルを明示する

──となると、まず取り組んだのは「ビジョンの明文化」ですね。すでに運用されているシステムに対して、なぜ改めてビジョンを定義し直す必要があったのでしょうか？

マネーフォワード 清川さん：
これまでのMFUIは、利用者の要求に応じるために「とにかく良いものを作って提供しよう」という動きが先行していました。しかし、改めて「なぜMFUIが必要なのか」「解決したい課題は何か」と問われると、チーム内でも言語化しきれていない部分があったんです。

マネーフォワード 品川さん：
そうですね。「なんとなくこういう方向だよね」という暗黙知はありましたが、明文化された指針はありませんでした。そこで乗田さんと一緒に、MFUIのプロジェクトビジョンを「目的」「目標」「課題」「手段」の4つの要素に分解して整理を進めました。

マネーフォワード 清川さん：
個人的には「目的」と「目標」の違いを明確に意識できたことが大きな収穫でした。「何のためにやるのか」と「そのためにどこを目指すのか」が整理できたことで、チームとして思考の整理がつき、意思決定に迷ったときの立ち返る指針ができました。作成したプロジェクトビジョンは、すでにチームの羅針盤になっています。

Goodpatch 乗田：
「目的（Why）」と「目標（Where）」を混同してしまうことは、プロジェクトにおいてよくある落とし穴です。目的は「なぜやるのか」という存在意義であり、目標は「いつまでにどうなっていたいか」という到達点です。ここを明確に分けることで、施策が手段の目的化に陥る現象を防ぐことができます。

マネーフォワード つるさん：
ビジョンが明確になったことで、後述するライブラリの大規模な改修についても、「ユーザーのために必要だ」という判断軸がぶれずに済みました。もしビジョンがないまま改修に入っていたら、「ここまで変えていいのか？」と迷い続けていたかもしれません。

──プロダクトビジョンを定めた後は、どのような取り組みをされたのでしょうか。

Goodpatch 乗田：
ビジョンの実現に向け、MFUIの成長サイクルである「グロースサイクル」を明示しました。 デザインシステムは構築して終わりではありません。「利用」「運用」「浸透」を継続的に実行し続ける必要があります。

また、定期的な評価を行いながら、改善活動を進めることも重要です。MFUIの価値を測るためのKPIとして、以下の4つを設定し、グロースサイクルを回すことで、それぞれのKPIが向上するように設計しました。

• 浸透率
• 導入率
• 生産性向上度
• 品質向上度

マネーフォワード 品川さん：
これまでも「良くなった」「ここは使いにくい」という定性的な情報はSlackなどで拾っていましたが、それを定量的な指標として定義したことはありませんでした。「利用」「運用」「浸透」がどうつながり、どの数字が上がればMFUIが成長したと言えるのか。このサイクルが可視化されたことで、感覚値ではなくデータに基づいて改善を回す土台が整いました。

マネーフォワード 清川さん：
MFUIにおけるグロースサイクルの考え方と実践方法がチームにインストールされたことが、今回の支援で得られた最大の資産かもしれません。

これまでは、目の前の実装や修正に追われてしまい、「MFUIを入れることで開発効率がどう上がったのか」を組織に対して説明しきれていない部分がありました。しかし、このサイクルができたことで、デザインシステムの投資対効果を定量的に示し、戦略的に改善を進めるための指針を手に入れることができました。

ユーザーの声をデータ化し、事実を基に意思決定ができる土台を作る

──指標が決まったことで、現状の活動度を測る調査が行われたわけですね。

マネーフォワード 品川さん：
はい。策定したKPIに基づき、8月にデザイナー、エンジニア、PdM（プロダクトマネージャー）を対象に「MFUIの浸透度調査」を実施しました。結果として、90件近くの回答を集めることができました。

──回答90件というのは、社内ツールに対するフィードバックとしてはなかなかの数ですね。そこから見えてきたものは何でしたか？

マネーフォワード 品川さん：
「デザインはそろっているが実装コストが高いと思われている」「ドキュメントのここが見られていない」といった、これまで薄々感じていた課題が、明確な「数字」と「具体的なペインポイント」として浮き彫りになりました。「MFUIを知っているが使っていない」層がこれだけいる、その理由は「使い方がわからないから」だ、といった事実を数字で突きつけられた形です。

Goodpatch 乗田：
この調査のポイントは、単に満足度を聞くだけでなく、先ほど設定した「浸透率」や「導入率」への寄与度も測った点です。これにより、MFUIが組織にどれだけ貢献しているかを客観的に示せるようになりました。品川さんにはアンケート設計の段階から深く連携したので、今後もチームで定期的に計測し続けるためのノウハウを残せたと思います。

マネーフォワード 品川さん：
調査結果自体は、ある意味「予想通り」の部分もありましたが、それが「事実」として確認できたことが大きかったです。何となくの感覚が明確な課題に変わった瞬間でした。これにより、次のステップである課題解決の実践への決心がつきました。

課題解決の実践：Figmaライブラリの統合とNotionへのドキュメント移行

──ビジョンを固め、現状をデータで把握した上で、いよいよ具体的な「リソースのアップデート」に着手されたのですね。ここでは、かなり大きな変更が行われたと伺っています。

マネーフォワード つるさん：
はい。今回は「Figmaライブラリの統合」と「ドキュメントのNotion移行」を行いました。先程お話しした調査の結果からも「検索性の低さ」や「情報の見つけにくさ」が課題であることが裏付けられていたので、データも用いながら意思決定をして改修に踏み切りました。

──具体的にはどのような変更を行ったのですか？

マネーフォワード つるさん：
Figmaライブラリはこれまで「1コンポーネントにつき1ファイルを用意する」という方針で管理していました。このFigmaライブラリを「全コンポーネントを単一ファイルに統合する」という対応を行いました。これは利用者のライブラリ導入コストを抑えたり、コンポーネントの探しやすさを確保するための変更です。

──それは影響範囲が大きそうですね。変更によるリスクもあると思いますし、大きな決断だったんじゃないでしょうか。

Goodpatch 乗田：
そうですね。既存のシステムには「作られた意図」や「ユーザーのメンタルモデル（使い方の慣れ）」が確実に存在します。それを無視して新しくしても、現場は混乱するだけです。 ですので、Figmaライブラリを統合するという提案をした際も、既存の認知や使い勝手を維持しながら、いかにスムーズに移行できるかを最優先に考えました。

マネーフォワード つるさん：
きちんと現場のデザイナーに方針の共有を行い、了承を得るといったプロセスも含めて丁寧に進めていただきました。統合を実施した当日は、乗田さんも一緒に作業してくださり、無事に移行を完了させましたよね。

ドキュメントについても、全社としてNotionへ移行したタイミングでMFUIも移行を行ったのですが、単なるコピー＆ペーストはしませんでした。グッドパッチさんの知見を借りて、情報の粒度を整理し、ユーザーが必要な情報に最短でたどり着ける構造へと再設計しました。これにより、ドキュメントが単なる仕様書の置き場から、開発者が自ら答えを見つけられるナレッジベースへと進化しました。

改善サイクルが文化として定着　10年続くシステムへ、MFUIが描く持続可能な未来

──戦略策定から実装まで、一連のプロジェクトを進めたパートナーとして、皆さんから見て、グッドパッチはどのように映っていますか？

マネーフォワード 清川さん：
グッドパッチさんは「外部のコンサルタント」というより、完全に「チームの一員」として動いてくれました。一般的なコンサルティング会社だと、第三者視点で「ここはこうすべきです」とレポートを出して終わり、というケースもあるかと思います。でも乗田さんは、私たちのチームのSlackに入り、定例ミーティングに参加し、現場の泥臭い作業も一緒にやってくれました。

マネーフォワード つるさん：
本当にそうですね。私がグッドパッチさんのブログを以前から読んでいて抱いていた「技術力が高い」「知見が豊富」というイメージ通りの信頼感はもちろんありましたが、それ以上に、ここまで深く入り込んでくれるんだという驚きがありました。

Figmaの統合作業の時も、当事者としてリスクを背負って実行してくれましたし、チームのメンバーがこれまで築いてきたものへのリスペクトを持ちながら改善を進めてくれた点も、非常にありがたかったです。

マネーフォワード 品川さん：
グッドパッチさんの参画によってチーム全体でMFUIのレベルを上げていこうという機運が盛り上がり、現状の分析から改善活動まで一気に進めることができました。 

プロジェクト開始当初は、グッドパッチさんが抜けた後に「さて、どうしよう」と何もできない状態になってしまうことを懸念していましたが、乗田さんが考え方や計測の手法、フレームワークを私たちにインストールしてくれたおかげで、プロジェクト終了後も「次は自分たちでこう計測しよう」「ここを改善しよう」と自走できる体制が残りました。

Goodpatch 乗田：
ありがとうございます。私としても、単に成果物を納品するのではなく、チームに文化を残すことを意識していました。「浸透度調査」や「生産性向上度を計測する試験」を行う際も、私が被験者になったりと、当事者として一緒に取り組むプロセスを大切にしました。この地道な積み重ねによって、MFUIのグロースサイクルを自分たち自身でも回していく文化のようなものが根付いたのではないかと思います。

──ありがとうございました！最後に、MFUIの今後の展望について教えてください。

マネーフォワード つるさん：
私は今回のプロジェクトで、「試行錯誤に勇気を持って取り組むべきだ」と学びました。 これまでは「動いているシステムを変えるのは怖い」と思っていましたが、ユーザーリサーチとデータに基づいて適切に行えば、変化は歓迎されると分かりました。今後もユーザー（社内の開発者たち）の声を聞きながら、恐れずに「やってみる」姿勢でMFUIを進化させていきたいです。

マネーフォワード 品川さん：
私も、客観的に状況を把握する手法と、それを次につなげる仕組み作りのフレームワークを得たことが大きな財産です。今後は自分たちでこのサイクルを回し、全社的な生産性と品質の向上に貢献していきたいですね。

マネーフォワード 清川さん：
最も重要なのは「持続可能性」だと考えています。デザイン基盤を構築する取り組みは多くの会社でも実践されていますが、そのチームのリソースはどの会社も限られています。限られた人数で、今後もっと増えていくプロダクトの開発を効率よく支え続けるためには、基盤そのものが強固で、メンテナンスしやすいものでなければなりません。

今回のプロジェクトで、「調査 → 仮説立案 → 改善 → 計測」というイテレーションを回す仕組みが整いました。このサイクルを回し続け、今後10年先もマネーフォワードのプロダクト開発を支え続けられるような、強固なインフラに育てていきたいです。