“625画面のアプリ開発”をどう前に進めたか──新規事業でマイナビのデザイナーが担った「翻訳」の役割

2024年12月、マイナビ初となるペット事業「HugWag(ハグワグ)」のアプリ開発がスタートしました。

当時の私は、大規模プロジェクトに初期段階から参画した経験も、プロジェクト内でデザインチーム全体をディレクションした経験もありませんでした。また、犬を飼った経験もなく、ペット業界に関する知識もほとんどない状態でした。

プロジェクトでは、飼い主向けとサロン向け、2つのアプリを社内で設計・開発します。デザインチームはUI設計をはじめ、デザイン領域全般を担いました。

ただし、デザイナーに求められたのは、画面をつくることだけではありません。要件を可視化し、事業部と開発チームの認識をつなぎ、プロジェクトメンバーが同じ前提で判断できる状態をつくることも必要でした。

そのため、事業部の要望や要件、その背景を深く理解したうえで、議論の起点となる「たたき台」を率先して作成しました。さらに、共通言語となるデザインシステムを構築し、プロジェクト全体の認識をそろえていきました。これらもまた、デザイナーが担った重要な役割です。

本記事では、デザインシステムやプロジェクトの進行フローといった開発初期の準備から、複雑な機能を設計した過程まで、HugWagのプロジェクトで実践したことを紹介します。

目次

「MOVE」から始まった、前例のない内製プロジェクト

私は2022年にマイナビへ中途入社し、医療福祉、ウエディング、オウンドメディアなど、さまざまな領域のデザインやコーディングに携わってきました。現在の担当は、UI設計やデザインシステムの構築、ロゴ、キャラクターの制作など多岐にわたります。

マイナビでは2023年、全社員が新規ビジネスのアイデアを提案できる制度「MOVE(ムーブ)」が始まりました。その初代グランプリとして事業採択されたのが、ペット事業「HugWag」です。

HugWagは、トリミングサロンとペットオーナーをつなぐマッチングサービス。愛犬に合うトリマーやサロンを見つけづらいという飼い主側の課題に向き合い、飼い主とサロンの双方が納得できる出会いを支援します。

HugWagの飼い主向けアプリ(上段)とサロン向けアプリ(下段)の画面例。サロンの検索・相談・予約から、サロン側での予約管理や施術実績の登録まで、双方のやりとりを支えます
【URL】https://hugwag.mynavi.jp/

プロジェクトでは、飼い主向けとサロン向け、2つのアプリを社内で開発することになりました。マイナビにとっては、これまで主に取り組んできたHR領域とは異なる、ペット業界への新たな挑戦です。

デザインチームに参加したのは、私を含む3人。私はUIデザインの実務を担当するとともに、チーム内の役割分担や制作物の進行管理も担いました。

HugWagのプロジェクト体制。事業部、デザイン、バックエンド、モバイル開発、インフラなど、複数の領域が連携して開発を進めました

MOVEから生まれた新規事業ということもあり、事業部にはサービス開発の経験者が十分にそろっていませんでした。また、社内主導でこれほど大規模な開発を進めることも、初めての試みでした。

また、HR領域以外の挑戦ということもあり、社内の経験則が通じないことも多く、参考にできる社内事例がない以上、画面だけをつくればよいわけではありません。プロジェクトの進め方そのものから、自分たちで設計する必要がありました。

不確実な状況で、最初に何を整えたか

参加当初、プロジェクトは大きく3つの不確実性を抱えていました。

  • 私を含め、ペット業界に詳しくないメンバーが多かったこと
  • 完全内製でここまでの大きな規模のものが初めてだったこと
  • 社内に同じ領域のアプリ開発事例がなかったこと

私を含め、新規事業への熱意は高かった一方、これほど大規模な開発プロジェクトを経験したメンバーは多くありませんでした。

しかし、すべてが決まるのを待っていては制作を始められません。

このような環境で、デザイナーができることは何だろうか。

私が挑戦したのは議論の土台となる「たたき台」を率先して作り、提示することでした。

これも広い意味でのデザインワークと捉え、後から変更に対応できる土台を整えるとともに、関係者が同じ前提で議論するための共通言語づくりを始めました。

利用者の声から、判断の前提をそろえる

最初に取り組んだのは、事業と利用者への理解です。事業部から共有された飼い主やサロンへのインタビュー記録をはじめ、事業背景に関する資料を読み込みました。

私自身、犬や猫を飼った経験がありません。トリミングサロンを利用する人が何に困り、何を基準にサロンを選ぶのかも、当初は十分に理解できていませんでした。

だからこそ、画面の見た目を考える前に、利用者が置かれている状況や、各機能が求められている理由を捉えることを優先しました。資料だけではわからない点は、事業担当者へ繰り返し質問。飼い主としての視点、ペット業界の慣習、その仕様が必要になった背景まで確認し、UI上の判断と事業上の目的が離れないようにしました。

625画面を見越し、画面IDとデザインシステムを共通言語にする

私たちが、画面数の多いプロジェクトを進めるうえでまず初めに着手したのが、画面IDの付番です。

画面数が増えると、「予約画面」「チャットの次の画面」といった呼び方だけでは、メンバーごとに想定する画面が変わってしまいます。加えて、同じ画面にも入力前、入力後、エラー時など複数の状態が存在します。

事業部、デザイナー、エンジニアがIDを使って話すことで、「どの画面の、どの状態について話しているのか」を特定しやすくしました。

画面IDと画面名をまとめた管理表(上)と、対応するFigma上の画面(下)。画面ごとに一意のIDを設定し、関係者が同じ画面や状態を特定できるようにしました

最終的に、両アプリのデザインは合計625画面(2025年9月時点)に及びます。それだけの規模になっても共通の呼び方を維持できたのは、プロジェクトの初期段階で画面IDを導入していたからこそ。認識のずれを抑えるうえで、大きな支えとなった仕組みです。

未決定事項を、制作を止める理由にしない

画面設計と並行して、HugWagのデザインシステム構築にも着手しました。ボタンや入力欄など、複数の画面で繰り返し使用する要素をコンポーネントとして整理し、画面ごとのばらつきを抑えるためです。

HugWagのデザインシステム。書体や色、ナビゲーション、ラベル、アイコンなど、複数の画面で使用する要素を整理しました
FigmaのVariablesでカラーを一元管理。用途に応じたセマンティックカラーを定義し、各画面へ共通のルールを適用できる構造としました

もっとも、この時点ではロゴもブランドカラーも決まっていません。それでも決定を待たず、色を暫定値として設定しました。正式な色が決まった後にまとめて変更できるよう、「Figma」のVariables(バリアブル)機能を利用した構造にしています。

代表画面に複数の配色を当てはめ、背景色、アクセントカラー、ボタン、アイコンなどの組み合わせを比較しました
複数画面へ配色を展開し、文字やボタンと背景のコントラストを確認。視認性とブランド表現の両面から調整を重ねました

未決定の要素はいったん仮置きし、後から安全に変更できるようにする。その構造を先につくったことで、ブランドの検討とUI設計を並行して進められました。

検討した配色を、ログインや基本情報登録など複数の画面へ展開。画面ごとの見え方や状態表現を確認し、配色ルールを調整しました

不確実なプロジェクトでは、すべてを確定させてから動くことが正解とは限りません。重要なのは、不確実性そのものを扱える設計にしておくことだと感じます。

画面数と関係者が増えても、判断が滞らない運用をつくる

制作が進むにつれ、画面数だけでなく、デザイン部、事業部、開発チームの間で確認すべき情報も増えていきました。個別のチャットや口頭で確認を続けていては、誰が何を確認しているのか見えにくくなります。

そこで最初に定めたのが、デザイン部内で確認した後に事業部が確認する、というレビューの流れです。さらに事業部と共同で、デザイン確認依頼表と文言ルール表を作成しました。

デザイン確認依頼表では、画面ごとに「確認中」「修正中」「確認済み」といった状態を管理。誰の確認を待っているのかが見えるようになり、確認漏れや重複した依頼を抑えやすくなりました。

画面ごとに確認状況、期限、Figmaへのリンク、修正内容、担当者間のコメントをまとめたデザイン確認依頼表。誰の確認や対応を待っているのかを可視化しました

一方の文言ルール表では、アプリ内で使用する名称や表現を事業部とデザイナーが一緒に検討しました。目的は、単に表記を統一することではありません。「利用者に何と伝えるか」を双方で考えるための場だったのです。

また、ペット業界特有の表現もあるため、用語の選定は事業部と慎重に確認しながら進めました。

ペット業界で使われる予防接種や証明書の名称を整理した表。類似する表現を比較し、アプリ内で使用する用語を事業部とデザイナーで検討しました
アプリ内の文章表記を統一するためのワーディングルール表。誤表記と推奨表記を対にし、表記の揺れを防ぐ基準として共有しました

こうした運用の目的は、管理表を増やすことではありません。誰が、何について、どの段階で判断するのかを可視化し、メンバーが制作や議論に集中できる状態をつくること。そのための仕組みです。

HugWagで必要だったのは、アプリのUIだけではありません。サービスサイト、ランディングページ、ロゴ、イラストなど、複数の制作物を並行して進める必要がありました。

そこで、デザイン部内のメンバーにも協力を依頼。担当を分けながら、制作物全体の進行を管理しました。

HugWagの制作物の例

複雑なチャット機能を、「たたき台」から解きほぐす

ここまでに整えた仕組みが特に役立ったのが、チャット機能の設計でした。

HugWagのチャットには、自由にメッセージを送る機能だけでなく、次の3つの機能を組み込む必要がありました。

  • 相談:飼い主が、希望するメニューや施術日時などをサロンへ送る
  • 予約:飼い主が、予約したいメニューや希望日時をサロンへ送る
  • 提案:サロンが、メニューや施術可能日時を飼い主へ提示する

利用者から見れば、いずれもサロンとの会話の一部です。しかし、通常のメッセージとは異なり、相談、予約、提案では入力項目も送信後の扱いも異なります。

事業部から寄せられたのは、これらの操作をチャット内で行えるようにしたいという要望でした。ただし、チャット画面だけを見て設計すると、チャット外の予約機能や、サロン側が管理する情報との間に矛盾が生じかねません。

そこで開発チームと、送信時のフォーマット、操作の流れ、データの持たせ方について検討を重ねました。ところが、口頭やテキストだけでは、メンバーごとに想定している動きが少しずつ異なります。議論も、どうしても抽象的になりがちでした。

エンジニアとの打ち合わせで作成した初期のフロー図。飼い主からの相談、サロンからの提案、予約作成、承諾、予約確定までの流れと、双方の操作を整理しました

完成画面ではなく、議論できる「たたき台」をつくる

状況を動かすために、Figma上でチャットの画面フローとUIのたたき台を作成しました。

この段階で重視したのは、見た目を完成させることではありません。「誰が、どの操作をすると、何が表示され、その情報がどこへ渡るのか」。その流れを可視化し、関係者が同じものを見ながら話せる状態にすることが狙いでした。

画面として表すと、それまで文章の中に隠れていた疑問や検討事項が浮かび上がります。

飼い主向け画面(上段)とサロン向け画面(下段)の検討例。相談や予約をチャット内でやりとりし、飼い主から届いた内容をもとにサロンが提案を作成する流れを、双方の画面で確認しました

相談、予約、提案の違いを、利用者へどう伝えるのか。チャット内で入力された情報を、他の機能やサロン側の画面へどうつなぐのか。ひとつの画面だけではなく、利用者の体験とデータの流れ、その両面から機能全体を捉え直す必要がありました。

たたき台作成の前に、事業部は利用者の体験や業務上の要件を確認し、開発チームは実装方法やデータの流れを検討する。デザイナーは双方の意見を受け取り、フローと画面へ反映していきました。

一度の打ち合わせで答えを出そうとはしません。たたき台をつくる。確認する。修正する。この短いサイクルを繰り返しました。

チャット機能に関係する画面と遷移をまとめたFigma上の全体フロー。相談、予約、提案に加え、メニュー選択や愛犬情報、サロン側の状態管理など、関連する機能を横断して整理しました

画面を議論の起点にしたことで、抽象的だった要望は具体的な論点へと変わっていきます。関係者の認識をそろえながら、必要な判断を一つずつ積み重ねられるようになったのです。

加えて、検討段階からエンジニアと画面やデータの流れを共有していたため、デザインと実装の間に生じる認識のずれも抑えやすくなりました。

プロジェクトから得た3つの実践知

サロン向けUIの設計には約3カ月、飼い主向けUIには約3〜4カ月を要しました。両アプリを合わせたデザインは、2025年9月時点で625画面。これだけの規模のプロジェクトを振り返ると、前例のない新規事業を進めるうえで重要だったことは、次の3つに集約できます。

1.未確定事項を、止まる理由にしない

ゼロから事業を開始するプロジェクトはロゴやブランドカラーから決める必要があります。だからこそ、後から変更できる構造をつくれば、UI設計は進められます。不確実性がなくなるまで待つのではなく、不確実性を扱える状態を先につくる。これが、プロジェクトを止めないための鍵となりました。

2.共通言語を先につくる

デザインシステム、画面ID、確認依頼表、文言ルール表。いずれも、関係者の認識のずれを抑えるための仕組みです。制作物が増える前に共通の呼び方や確認方法を定めたことが、プロジェクト後半の進行を支えました。

3.たたき台を、議論の道具として使う

たたき台は、完成形を提示するためだけのものではありません。まだ答えが決まっていない段階で画面やフローをつくるからこそ、隠れていた論点を発見できます。

それぞれの立場から知識を持ち寄り、同じものを見ながら判断する。そのための共通言語としても、たたき台は機能しました。

もちろん、こうした仕組みだけでプロジェクトが前に進むわけではありません。専門的な制作スキルに加え、相手の話を聞くこと、背景を理解すること、互いの専門性を尊重すること。それらがあって初めて、仕組みはチームの中で機能します。

デザイナーはプロジェクトを推進する「起爆剤」にもなれる

今回のプロジェクトを通じて強く感じたのは、デザイナーが早い段階で手を動かすことの重要性です。

文章で共有されていた仕様を画面やフローとして表すと、それまで見えていなかった疑問や矛盾が表面化します。プロジェクトメンバーは同じものを見ながら話せるようになり、本当に時間をかけるべき議論へ進みやすくなります。

ただし、要望をそのまま画面へ置き換えればよいわけではありません。利用者が置かれている状況、事業部が実現したいこと、開発上の制約。それぞれを理解し、関係者が判断できる形へ整理する必要があります。

たとえば、今回のチャット機能。事業部の要望を画面へ反映するだけでなく、利用者の操作と開発側のデータ構造までつながなければ、機能として成立しません。Figmaでフローとたたき台をつくったことは、その間を翻訳する行為だったと言えます。

私は以前から、デザインを課題解決の手段の一つと考えてきました。今回の経験から、もう一つの役割も見えてきました。異なる立場の人たちの認識をつなぐ、コミュニケーションの手段としてのデザインです。

今回のように、経験の少ない領域で未確定事項も多いプロジェクトでは、「たたき台」が特に有効でした。関係者の認識がそろい、議論を具体化するきっかけになったからです。

また、事業部や開発メンバーと要件整理を進める中で、デザインは議論の起点をつくりやすく、関係者の認識をそろえるうえでも有効だと感じました。

大規模プロジェクトにおいてもデザイナーは言われたことをデザインするだけの受け身ではなく、こちらからも働きかけることで、プロジェクト全体をリードすることもできます。

AIをはじめとする技術によって制作が効率化されるほど、目的を理解し、異なる立場の声を聞き、チームが判断できる形へ翻訳する役割は重要になるでしょう。

新規事業におけるデザイナーの価値は、画面をつくることだけではありません。人と人、事業と技術、利用者とサービスをつなぎ、チームが前へ進める状態をつくること。そこにも、デザイナーが発揮できる大きな価値があると考えています。

著者プロフィール

木下 景太
株式会社マイナビ
デジタルテクノロジー戦略本部 CXマーケティング統括本部

コンテンツプランニング統括部 UXデザイン部

新卒でSIerに入社後、デザインの専門学校へ進学。Webデザインやコーディングの実務経験を経て、2022年にマイナビへ入社した。現在は、社内のさまざまな事業領域で、Webデザイン、コーディング、UI設計、デザインシステムの構築などを担当。2025年、全社顕彰にてプレイヤー賞を受賞。

  • URLをコピーしました!
目次