Yappli Tech Blog

株式会社ヤプリの開発メンバーによるブログです。最新の技術情報からチーム・働き方に関するテーマまで、日々の熱い想いを持って発信していきます。

ヤプリWebフロントエンドの現在地(2025年版)

プロダクト開発本部 開発2部 フロントエンドグループ マネージャーのこん(@k0n_karin)です!

今回はタイトルの通り、ヤプリのWebフロントエンドが現在どんな状態か、どんな課題があるのかなどを整理してみました。本記事を通して、ヤプリのWebフロントエンドに興味を持っていただけたら何よりです。

ヤプリのプロダクト状況

ヤプリのプロダクトは全部で3つあります。

  • Yappli(ノーコードアプリプラットフォーム、コア製品)
  • Yappli CRM(アプリを起点としたCRM、成長製品)
  • Yappli WebX(AI x Web構築プラットフォーム、新規事業)

YappliとYappli CRMはプロダクト開発本部という本部で開発していますが、Yappli WebXは新規事業開発室という別の部署で開発されています。

フロントエンドで使われている技術は、YappliではVue(Nuxt)、Yappli CRMとYappli WebXではReact(Next.js)で開発しています。いずれもTypeScriptを採用しています。

ヤプリのプロダクトと使われているフレームワーク

ちなみに、社名は「ヤプリ」で、サービス名は「Yappli」のように使い分けられています。

今のチーム規模や開発の体制

フロントエンドグループは私を含め現在6人です。この6人が様々なプロジェクトに参加して業務を行っています。

プロジェクトの開発は数人〜十人程度で複数の職種(PdM・PdD・フロント・サーバー・iOS・Android・SRE・QA)でプロジェクトが組成されています。

このプロジェクトは、期間限定のものもあれば、長期で走り続けるのものもあります。また、開発の仕方(スクラム・カンバン・ウォーターフォールなど)はプロジェクトの性質によって異なります。

ヤプリのプロジェクト構成例。プロジェクトによって関わる職種や人数が異なります。

YappliのWebフロントエンドの面白さ

ここからは、主にノーコードアプリプラットフォームのYappliを中心に書きます。

大規模な開発と事業の中核となる開発ができる

Yappliの管理画面は30万行を超える大規模なコードベースで、ノーコードでネイティブアプリを作る体験を支えています。この管理画面は100画面強・60機能弱の多機能なシステムで、広いドメイン知識が求められます。もちろん現在も複数の新機能開発が進んでいます。規模が大きい分、どうやって長期的に安定したスピードを維持しながら開発するか、他のメンバーの開発を考慮したり、チームでどうやって協働して開発していくか、という難しさと面白さがあります。

また、管理画面で作られる様々なデータが、最終的にネイティブアプリのユーザー体験を決定します。そう考えると、管理画面とはいえ事業で果たす役目は大きいですよね。

管理画面とヤプリの営業生産性への影響

管理画面はヤプリの自身の営業活動の観点でも重要で、社内にいるアプリデザイナーという職種の方々がYappliを使って、営業活動でお客様に提案するためのサンプルアプリや、お客様が作りたいアプリの制作を代行しています。

アプリデザイナーは月に30〜60ほどのアプリをYappliで制作しています。実は、彼らが世界で最もYappliの管理画面を触っています。つまり、管理画面の操作性がアプリデザイナーの生産性と自社の営業力そのものに直結しています。これはヤプリならではの面白さだと思います。高品質なアプリをいかに早く生み出せるかが、我々フロントエンドエンジニアの使命です。

動的で複雑なUI・データの実装

Yappliでアプリを作る際には、様々な用途別の機能を組み合わせてアプリを構築していきます。その中で、アプリのトップに表示する画面や様々な機能のハブになる画面をBlock UIと呼ばれる機能で構築できます。Block UIは名前の通り「ブロック」という単位を積み上げて画面を作ります。

ヤプリの社内アプリで使われるBlock UIのスクリーンショット

デザインエディタのような見た目をしていますね。大きく3つのパネルが存在しており、左からブロックの一覧、ブロックのプレビュー、ブロックに入稿するデータ・スタイル設定のようになっています。Block UIは、追加したブロックによって入稿できるデータやスタイルを細かく指定できるため、Yappliの中でも最も多機能で複雑な機能です。当然、開発目線でも難易度が高く、考えることが多いので歯ごたえある機能になっています。ワクワクしませんか?

約4000万MAUのネイティブアプリのWebViewを使った機能開発

管理画面から作られるネイティブアプリ側にも目を向けてみましょう。Yappliで作られたすべてのアプリは約900アプリあり、合計のMAUは約4000万です。とても多いですね!(ちなみに、2024年11月時点のTikTokの国内MAUが3300万と言われています。*1

管理画面よりも圧倒的に多くのユーザーが関わるネイティブアプリの開発では、機能の大半はKotlinとSwiftを使ったOSごとのコードで開発されています。ですが、いくつかの機能はWebViewを使って機能開発をしています。WebViewはネイティブに比べてできることに制約はありますが、それが問題なければWebの技術を使ってOSに両対応しながらスピーディに開発ができます。また、新機能のPoCとして、WebViewでスピード開発→効果検証→ネイティブで作り直す、のような活用もできます。

ネイティブアプリのWebView向けの開発では、エンドユーザーの端末負荷を下げるパフォーマンス向上施策やMAU増加に耐えられる基盤づくり、エラー監視など、管理画面の開発に比べてやることがまだまだ盛りだくさんです。

今抱えている課題感

人が足りない!!!!

現在は6人でYappliとYappli CRMのフロントエンド開発を行っており、4名と2名で分担して開発しています。ただし、Yappliの開発ではどうしても人数が足りず、一部サーバーサイドエンジニアの手を借りて実装を手伝ってもらっている状態です。現状、機能開発は何とか回っていますが、後述する技術的な課題解決や運用フローの改善、R&Dなど、やりたいことには十分に手を回せていません。

テストが足りない!!!!

以前、Yappliの状態管理ストアの課題について https://tech.yappli.io/entry/yappli-cms-with-vuex で投稿した内容の都合で、テストも書きづらくなっていました。小さいコンポーネントでテストを書こうとしてもStoreのモックに手間がかかるため、今までテストが避けられていた背景があります。まずストアへの依存を減らすリファクタリングが必要なのが現状です。

代わりに、過去にはVuexのユニットテストをできる範囲で書いてきましたが、これも部分的にしか書かれていません。ディレクトリごとのカバレッジを見ると赤裸々な現実がおわかりいただけると思います。

全体で20%強、少ないディレクトリだと一桁%のカバレッジ

現在は、社内でテストの知見・経験を増やしながら、テストを書きやすい設計を目指して試行錯誤しています。Composition APIを使ったローカルな状態管理に移行しつつ、依存関係を整理して疎結合な設計にしてテストを書きやすく改善しています。インテグレーションテストもようやく書き始めているところなので、より拡充していきたいですね。

複数プロダクトの統合とマルチフレームワーク環境

Yappli、Yappli CRM、Yappli WebXの3つは、現状完全に別々のプロダクトになっています。今後これらを統合していくことを考えてみると、一筋縄ではいかない問題がいくつもあります。

フロントエンドの観点では、それぞれのプロダクトで異なるフレームワークを使っている点が最も頭を悩ませているところです。どちらかに寄せるか、あるいはうまく共存の道を模索するか、これについては現在も答えが出ていません。

これらの統合によるシームレスな体験の実現が、今後のヤプリの課題になってくると考えています。

おわりに

もちろんここには書ききれない大小様々な魅力・課題が数多くあります。もしご興味を持っていただけたらカジュアル面談でお話しましょう!

open.talentio.com