こんにちは。『楽楽請求』でフロントエンドを担当しているtakenamiです。
『楽楽請求』では立ち上げ当初から、要件定義から画面仕様の作成までを設計チームが担い、開発チームがそれを実装するという分担で開発を進めてきました。2024年10月のリリースから約1年半が経った2026年4月、顧客への価値提供スピードをさらに高めるための部の方針として、UI設計をフロントエンドが担う体制へと移行しています。
実際に担ってみると、実装を担当していた頃には見えていなかった景色と、いくつもの壁にぶつかりました。この記事では、この体制に至った背景・進め方と、現時点で向き合っている課題をお伝えします。
1. 前提となる開発体制
『楽楽請求』は、クラウド型請求書処理システム市場へ後発として参入したプロダクトです。初期フェーズでは、市場のニーズに迅速に応え、PMF（Product Market Fit）を達成することが最重要課題でした。初期メンバーによる徹底した現場視点と迅速な価値提供があったからこそ、現在の『楽楽請求』の成長につながっています。
当時の役割分担は次のとおりです。
- 製品企画チーム：どの機能を作るかの企画を担当
- 設計チーム：要件定義から概要設計まで。その一環として、FigmaでのUI設計までを担当
- 開発チーム（バックエンド・フロントエンド）：詳細設計・実装・テストを担当
この明確な分担は、開発効率を高めるうえで大きく機能してきました。設計チームは要件と画面仕様の検討に、開発チームは実装品質にそれぞれ集中できる。短期間で多くの機能を届けられてきたのは、この体制があったからだと思っています。
私が参画した当時、『楽楽請求』では楽楽シリーズ共通のUIの統一がすでに完了していました。統一された画面をベースにできるため、Figmaの画面仕様は設計チームが作成し、必要に応じてデザイナーに依頼する形で運用されています。
これから紹介するのは、この分担を否定する話ではありません。共通基盤が整っているからこそ、UI設計を誰が担うのが最も速いかを、組織として問い直した話です。
2. なぜ踏み出す必要があったのか
設計フェーズに負荷が集中していた
体制上の制約がありました。当時の設計チームは少人数で、事業部の製品企画と連携しながら、要件定義から画面仕様の作成までを一手に担っていたことです。
企画・要件・UI設計が直列でつながっているため、どれか一つが詰まれば後続がすべて待つ構造になります。開発チームは実装の準備ができていても、画面仕様が出てくるまで着手できない。顧客に価値を届けるスピードを高めるうえで、ここが構造的な制約になっていました。
- 問題：要件定義からUI設計までが少人数の設計チームに集中し、設計フェーズが価値提供スピードの制約になっていた
- 課題：UI設計を分担し、設計チームが要件の検討に集中できる状態をつくる
その課題解決の案が、フロントエンドの役割の引き直しでした。
なぜフロントエンドだったのか
理由は大きく2つあると理解しています。
ひとつは、UIを実際に動く形にできることです。フロントエンドがUI設計からプロトタイプ作成までを一気通貫で担えば、設計と検証の間の受け渡しがなくなります。
もうひとつは、実装して初めて見えることがあるという点です。実装フェーズに入り、実際に動く画面を触る中で、次のような気づきを得ることがありました。
- この操作フローだと、ユーザーが迷う場面がありそうだ
- この情報配置だと、目的の項目にたどり着くまでに時間がかかりそうだ
- この入力体験は、もう少し工夫の余地がありそうだ
ただ、その時点では開発プロセスもすでに後半で、操作体験を大きく変更することは難しい状態でした。
ここで起きているのは、誰かの検討が足りなかった、という話ではありません。Figmaの画面仕様は、情報設計やレイアウト、コンポーネントの選定といった判断を固めるうえで欠かせないものです。ただ、操作の連続性や入力のテンポといった「実際に動かしてみないと分からない情報」を、設計フェーズの時点で確かめる手段がありませんでした。
だとすれば、実装まで担うフロントエンドが設計段階から関わり、動く状態で確かめてしまえばいい。この2つが重なった結果としての体制変更だったと捉えています。
プロトタイプを作るコストが下がった
もうひとつの後押しが、開発組織全体で進んでいる「AIを活用した開発スタイル」への転換です。
AIを活用することで、アイデアや仕様を素早く動くプロトタイプとして形にできるようになりました。これまでは「作ってから検証する」ことのコストが高く、現実的な選択肢になりにくかった。そのコストが下がったことで、設計フェーズで動かして確かめる進め方が、例外ではなく標準の選択肢になったと考えています。
プロダクトのフェーズも変わってきた
機能拡張は今も続いており、強化すべき領域は残っています。
一方で、ユーザーの声を聞く中で見えてきたのは、画面の見やすさ以上に、日々大量の業務をどれだけストレスなく処理できるかという操作感そのものへの期待でした。
そのため、次のような観点で体験の質を磨き込むことの優先度が、以前より上がってきていると感じています。
- 直感性：初めて触るユーザーでも迷わず操作できること
- 効率性：無駄な画面遷移やステップを削ぎ落とし、大量の処理をスピーディーに行えること
- 信頼性：誤操作や確認漏れを防ぎ、日々の業務で安心して使えること
3. まずは小さくUI設計を担う
立ち上げは小さく、定着は着実に
方針が決まったとはいえ、これまで実装を中心に担ってきた私たちが、いきなり全機能・全工程を引き受けるのは現実的ではありません。
そこで ラクスリーダーシッププリンシプル（RLP） の一つである「小さく試して大きく育てる」を意識し、今後リリース予定の新機能から着手することにしました。現時点で実践したのは2案件です。
小さく始めたのはあくまで立ち上げ方の話であり、単発の試行として終わらせるつもりはありません。この2案件で得た手応えと課題をもとに、今後の新機能開発の標準にしていくことを目指しています。
Before → After
進め方
概要設計で整理された機能要件をもとに、フロントエンドがUIを設計し、実際のコードでプロトタイプまで作り込みます。画面遷移や入力操作を本物同様に試せる状態にするのがポイントです。
- 設計チームが概要設計（機能要件の整理）
- フロントエンドがUIを設計し、プロトタイプを作成
- フロントエンドチーム内でレビュー
- 設計チームによるレビュー・仕様の確定
- UIのブラッシュアップ
- 本実装
UI設計そのものはフロントエンドが担いますが、仕様の確定は設計チームとの合意を経て行います。要件の背景や事業判断を持っているのは設計チームであり、そこと接続されていないUIは成立しないためです。役割を引き取ったというより、UI設計の検討をフロントエンド側に前倒しし、二者で詰める形に変えた、という表現が近いと思います。
実際、プロトタイプを持ち込むことで、言葉や画面仕様だけではイメージを揃えにくかった操作感について、設計チームと早い段階で具体的な議論ができるようになりました。
4. 担ってみて見えてきた、3つの課題
始めて数か月が経ちました。設計フェーズの領域に踏み込んだからこそ、向き合うことになった課題が3つあります。
課題① 顧客・業務理解を深める
最も大きな壁が、ドメイン知識と業務フローの理解でした。
実装に必要な理解と、UIを設計するために必要な理解には、思っていた以上に差がありました。「ユーザーはどういう業務の文脈で、どのタイミングでその設定を変更したくなるのか」「前後の作業とどう繋がっているのか」。ここを押さえていないと、業務に馴染むUIにはなりません。
→ 営業商談の録画視聴、設計チームとのディスカッション、経理業務の専門書などを通じて、インプットを継続しています。
課題② UIパターンの引き出しを増やす
顧客の業務が理解できても、それを直感的なUIへ落とし込むには別のスキルが必要でした。
情報量の多い設定画面において、「ポップアップで出すべきか、インラインで表示すべきか」「どのように視覚的なガイドを出せば迷わないか」。こうした選定を、経験則や感覚だけで判断してしまう場面がありました。
→ UI/UXデザインや各種UIパターンを学び、既存画面に積み上げられてきた判断の意図を読み解きながら、選定の引き出しを増やしています。
課題③ 設計意図を言語化する
「なぜこのUIにしたのか」を言語化し、関係者に説明する力も新たなハードルでした。
プロトタイプを持ち込んでも、「使いやすそうだから」では議論になりません。「この操作フローならユーザーの思考を妨げない」「実装コストとのバランスが良い」といった理由を、ビジネス視点も含めて説明し、合意形成を図る必要があります。
→ プロトタイプを軸にした早期のすり合わせを重ね、意図を説明する力を磨いています。
3つ並べて改めて思うのは、これらはいずれも、少人数の設計チームが日常的に引き受けてきたことの一端だということです。自分で担ってみて初めて、その難しさを実感しました。
5. 一歩踏み出した先に見えてきた、次の景色
運用面では、詰めるべき論点も残っています。プロトタイプと本実装の境界線をどこに引くか、UI仕様のドキュメントをどう管理するか。この進め方をチームの標準として定着させるうえで、避けて通れないテーマです。
そうした中で、直近では私自身が設計メンバーとして設計チームに加わることになりました。より事業や顧客に近い場所で、課題解決や設計判断に携わっていくことになります。
実装に閉じず、顧客視点でプロダクトづくりを主導できるエンジニアになる。そこに向けた、はじめの一歩だと思っています。
おわりに
今回紹介した取り組みは、正直に言えば、まだ「成功事例」と呼べる段階ではありません。課題のほうが山積みです。それでも、「より良いプロダクトを作りたい」という思いから踏み出した以上、ここから引き返すつもりはありません。
この記事が、「もっとプロダクトの意思決定に関わりたい」と考えているフロントエンドエンジニアの方にとって、何かのヒントになれば幸いです。
設計チームの一員として見えてくる景色や、そこでの気づき・失敗についても、機会を見てまたお伝えできればと思います。
