大山 奈津妃 プロダクトデザイナー
エンジニアとして約5年の開発経験を経て、プロダクトデザイナーへ。freeeでは複数のプロダクトで共通利用される基盤領域を中心に、業務UIの設計、デザインシステムの設計・実装、UIレビューの仕組みづくりに取り組みました。
経歴 2017年4月〜2019年7月｜シアトルコンサルティング株式会社（現：METATEAM株式会社） システムエンジニア として、従業員エンゲージメント調査システムのAPI開発（Ruby on Rails）、大規模ECサイトの商品管理・決済機能開発（Java）、家具ECサイトの法人向け機能開発（PHP）などを担当。2019年8月〜2022年6月｜freee株式会社 フルスタックエンジニア としてfreee人事労務の勤怠管理・給与計算・年末調整機能の開発を担当。要件定義から設計・実装・運用保守まで従事。勤怠管理の手当計算ロジックの新規開発 年末調整の控除額・税額などの計算処理、法令改正に伴う仕様変更 React / TypeScriptによるフロントエンド開発、Ruby on Railsによるバックエンド開発 2022年7月〜2026年11月（退職予定）｜freee株式会社 プロダクトデザイナーへ転向。 複数のプロダクトが共通利用する基盤領域を担当。アカウント管理、認証（SAML設定、パスキーなど）、マスタ管理、ワークフローなどのUI/UX設計 業務アプリ向けデザインシステムの改善。Reactによる共通UIコンポーネントの実装、設計・利用ガイドラインの作成 デザイナー3名のチームのマネージャー（1年間） 基盤領域のUIレビュー制度の構築・改善 料金プラン管理ツールの業務理解、情報設計・UI設計、AIを使った実装と検証 専門領域 専門領域 内容 DesignOps UIレビューの制度設計と運用、デザインシステムの利用ガイドラインと使い分けの基準づくり、コンポーネントの実装（React / TypeScript）、ナレッジの蓄積と自動化 プロダクトデザイン 業務理解と要件整理、情報設計、画面構成・UI設計、ユーザーへのヒアリング、デザインシステムとAIで実装した画面による検証
CASE 01 DesignOps
UIレビュー制度の構築・改善 プロジェクト情報 項目 内容 概要 開発チームごとにUIの確認方法が異なり、ナレッジも蓄積されていなかった。UIレビューを制度化し、指摘のナレッジ化とAI一次レビューを導入した。開発案件として管理されているUI変更は、すべてレビューを通してリリースされるようになった。四半期約70〜80件を継続運用し、150件以上の指摘をナレッジ化、6件を全社デザインガイドラインに反映。シニアデザイナーの工数は約50%減と推計。 期間 2025年8月〜2026年9月（約1年） 対象 複数のプロダクトで共通利用される基盤領域。アカウント管理、承認ワークフロー、通知などのUI変更すべて 担当領域 企画・立案：UIレビュー制度の発案と設計 運用設計：依頼フロー・相談窓口・3名体制 業務の自動化：n8nとAIによるナレッジ収集とガイドライン改善PRの作成 AI活用：AI一次レビューの設計・検証（オーナーはチームのデザイナー）
1. 背景：UI品質の確認体制 基盤領域には、デザイナーがアサインされていない開発チームもあり、PMやエンジニアが直接UIを設計・変更し、デザインの確認を受けずにリリースするケースがあった 基盤領域全体で、UI品質を確認する共通のルールや体制は整備されていなかった UI品質の確認は各開発チームの判断に委ねられ、属人化していた まずレビューの制度をつくり、運用の中で出てきた2つの課題（チームをまたいで同じ指摘が繰り返されること、レビューが特定の人に集中すること）に順に取り組みました。
2. 課題①：UIレビュー対象とリリース条件の統一 2-1. UIレビューの制度化 根本にあったのは、UI品質を確認するかどうかが各チームに任されていたことです。そこで私が発案し、すべてのUI変更をレビューに出し、承認（LGTM）をリリースの必須条件とする制度 を設計しました。
デザイナーが担当する変更も、PMやエンジニアが直接行う変更も、同じ条件でレビューを通してからリリースします。
2-2. レビュー依頼・相談窓口の整備 すべての変更をレビューに出してもらうには、依頼しやすさも必要でした。依頼はSlackの専用チャンネルにまとめ、フォームから送る形にしました。依頼ごとの対応状況はSlackのリストで管理し、依頼者が自分で確認できるようにしました。
その後、四半期ごとの依頼者アンケートで出た声をもとに、次の3つを追加しました。
職種別のテンプレート：デザイナー向けと、PM・エンジニア向けに分けた AIによる資料作成の支援：レビュー資料の下書きをAIで作れるようにした UIの壁打ち窓口：レビューの前に、設計の途中で相談できるようにした 壁打ち窓口ができてから、PMやエンジニアが設計の途中で相談してくれるようになりました。デザイナーがいない案件でも、小さな変更ならFigmaを作らず、Slack上のテキストのやり取りで意思決定でき、開発のスピードが上がった例もあります。
導入時には、レビューによって開発のリードタイムが延びることへの懸念もありました。開発組織の責任者と制度の目的をすり合わせて周知し、依頼が開発の終盤に集中しないよう、設計の途中から相談を受けました。レビューへの回答は原則1〜2日以内を目安にしました。
2-3. レビュー運用実績と依頼者評価 四半期あたり約70〜80件のレビューを継続して運用しました。指摘で多かったのは、文言やエラーメッセージ、コンポーネントの使い方、状態設計の漏れです。背景や目的に対して、そのアプローチ自体がよいのかを問い直すこともありました。四半期ごとの依頼者アンケート（4点満点）では、レビューの進めやすさが3.48点、UI品質向上への評価が3.44点と、どちらも高い評価でした。
一方、レビューを続けるうちに、異なる開発チームで同じ指摘が繰り返されていることが分かってきました。
3. 課題②：レビュー指摘の蓄積と再利用 3-1. レビュー指摘のナレッジ化 個別のレビューで終わっていた判断を、文言・情報設計・コンポーネント・状態設計・アクセシビリティなどの種類ごとに整理し、組織内で再利用できるナレッジとして残すことにしました。
人が採用を判断したナレッジはConfluenceに文書化してAI一次レビューで参照できるようにし、他のプロダクトにも共通する内容は全社デザインガイドラインの改善候補にしました。
UIレビューの流れとナレッジの再利用 UIレビューの依頼は、AI一次レビューのあと人がレビューして最終判断し、LGTMを得てリリースする。人のレビューの指摘はナレッジに蓄積し、他のプロダクトにも役立つ内容は改善PRとしてガイドラインに反映する。AI一次レビューはナレッジとガイドラインを参照する。 UIレビューの依頼 PM・エンジニア・デザイナー AI一次レビュー ナレッジとガイドラインを参照 人のレビュー 最終判断・3名で分担 リリース LGTMが必須 AIが参照する 知識 ナレッジ 基盤領域内で種類ごとに整理 ガイドライン 全社。管理チームが採用 指摘を蓄積 改善PR 参照 UIレビューの依頼は、AI一次レビューのあと人が最終判断し、LGTMを得てリリースする。人のレビューの指摘はナレッジに蓄積し、他のプロダクトにも役立つ内容は改善PRとしてガイドラインに反映する。AIは両方を参照する 3-2. n8nによるナレッジ蓄積の自動化 ナレッジの収集と文書化は、n8nとAIで自動化しました。週に1回、レビュアーの指摘を集めて、AIが判断基準に照らしてナレッジにする候補を選び、Slackのリストに登録します。人が内容を確認してナレッジにすると決めたものだけ、AIがカテゴリや関連するガイドラインの項目を付けて、Confluenceに文書を作ります。ナレッジとして残すかどうかは、人が判断します。
毎週月曜日 10:00 n8nを定期実行
↓ 過去1週間の指摘を取得
↓ AIが蓄積の可否を判定 事前に定めた判断基準に照らす
↓ 蓄積候補をSlackのリストに登録
↓ 人がナレッジ化の可否を判断 採用する場合に2つ目のワークフローを手動起動
↓ AIがカテゴリ・関連ガイドラインの参考項目を設定
↓ Confluenceにナレッジ文書を作成 2つ目のワークフローの完了地点
↓ AI一次レビューがナレッジを参照 次のレビューで再利用
n8nによる候補収集から、人の承認、Confluenceでの文書化、AI一次レビューでの再利用まで。APIの細かな処理は省略 3-3. ガイドラインとの重複チェック・改善PRの作成 自分が整備したのは、AIを使った既存ガイドラインとの重複チェックから、改善PRの自動作成までです。蓄積したナレッジがすでにガイドラインに書かれているかをAIで確認し、書かれていなければ改善PRを作って、ガイドライン管理チームへ提出します。
既存のガイドラインは十分に整備されていたので、すべての指摘を追加するのではなく、まだ書かれていない内容で、ほかのプロダクトにも役立つものだけを提案しました。採用するかどうかは、管理チームのレビューで決まります。
3-4. 全社デザインガイドラインへの改善案の反映 基盤領域のConfluenceには、150件以上のナレッジを蓄積しました。初期運用では、ガイドラインに足せそうな候補をAIで絞り込み、レビューする側の負担も考えて11件の改善PRにまとめて提出しました。管理チームのレビューを経て、そのうち6件が採用されました。
4. 課題③：レビュー担当者への負担集中 4-1. 3名体制への移行 当初は、別チームのシニアデザイナー1名がすべてのレビューを確認していました。
そこで、自身と、自分のチームのデザイナー1名がレビューに加わり、3名体制にしました。
4-2. AI一次レビューと人による最終判断 あわせて、Confluenceのナレッジとガイドラインを参照してAIが一次レビューを行い、その結果を見て人が最終判断する流れにしました。
AI一次レビューのオーナーはチームのデザイナーで、私は2人で打ち手を検討しながら、本格導入まで一緒に進めました。主に担当したのは、試験運用までの設計・検証と、AIが正しく動作しないときの対応方法の整理です。
4-3. 体制変更・AI導入後のレビュー工数 AI一次レビューの本格導入と、レビュー担当者の3名体制への移行の後、シニアデザイナーのレビュー工数は従来比で約50%減 と推計しました。
※約50%減はシニアデザイナーへのヒアリングを踏まえた推計値です。参考として、レビューコメント1件あたりの対応時間を10分と仮定し、導入前後のコメント件数から工数を試算しました。実測時間による比較ではありません。レビュー担当者の増員とAI一次レビュー導入など複数の施策があり、各施策単独の効果は切り分けていません。
5. 成果：継続的なレビュー運用とナレッジ活用 デザイン確認なしのリリースの解消： 開発案件として管理されているUI変更は、すべてレビューを通してからリリースされるようになったレビューの継続運用： 四半期あたり約70〜80件のレビューを運用し、依頼者アンケートでも高い評価を得たナレッジの蓄積・再利用： それまでほとんど蓄積されていなかったレビュー指摘をn8nとAIで週次に収集し、人の確認後にConfluenceへ文書化する仕組みを構築。150件以上のナレッジを蓄積し、初期運用で提出した11件の改善PRのうち6件を全社のガイドラインへ反映した負担の分散： AI一次レビューと3名体制を導入し、シニアデザイナーのレビュー工数は従来比で約50%減と推計したプロジェクト情報 項目 内容 概要 外部の課金サービスの管理画面では誤設定を防げず、運用はスプレッドシートと人の確認に頼っていた。業務の流れを整理して閲覧・編集・承認を分けた画面構造を提案し、デザインシステムとAIで実装しながら設計を固めた。フェーズ1の8画面を実装し、検証環境で運用担当者が実際の作業を試せる状態にした（退職に伴い、リリース前に引き継ぎ）。 期間 2026年5月〜9月（設計 → フェーズ1 実装） 対象 料金プランのカタログを閲覧・変更申請・承認・環境反映する内製ツール（8画面） ユーザー プランを登録・変更する運用担当者と、2段階の承認者 担当領域 業務整理・要件整理：運用担当者の業務の流れと必要な情報の整理 情報設計・UI設計：閲覧・編集・承認の画面構造の提案 ユーザー検証：運用担当者へのヒアリングと検証環境での検証 フロントエンド実装：デザインシステムとAIを使った実装 意思決定 要求と構造はPM・運用担当者・エンジニアと一緒に決めた。スコープの最終決定はPM/エンジニア。個別の仕様は、内容に応じて開発チームで決めることもある
1. 背景と課題 料金プランのカタログは、外部の課金サービスの管理画面で登録・変更していた その管理画面には入力チェックがなく、組み合わせてはいけない商品を組み合わせるなどのミスが起きていた。編集の操作もしにくく、変更前後を比べて確認することもできなかった そのため運用担当者は、スプレッドシートで書き換えてCSVでアップロードしていた。スプレッドシートなら、変更前後を並べて確認できるからだった 確認は担当者の目と経験に頼っており、属人化していた 2. 目的 誤りのない料金プランのデータを社内で作れるようにし、そのうえで外部の課金サービスに連携することを目的にしました。
3. 進め方：動くもので要求を固める 3-1. プロトタイプからの要求整理 エンジニアとPMが生成AIでプロトタイプを作り、運用担当者に見せて要求を集めていました。私はこのプロトタイプができた段階で参加しました。
プロトタイプには、見積もりの作成、代理店販売、販売ステータスの自動遷移、予約、版管理など、考えられる機能がひととおり載っていました。私が参加したあと、MVPの機能リスト（31項目）をチームで合意しました。これを上限に、業務ができることを優先して、これらの機能を外すことをチームで議論して決めました。
進めるうえで、次の3つを方針にしました。
プロトタイプへの反応は要求を知る材料にし、画面の構造は業務から設計し直す 先に、業務の流れと切れ目、業務ごとに必要な情報を整理する 画面を分けるか、同じ画面に何を並べるかは、その整理をもとに決める 3-2. AIを使った実装と検証 この案件では、Figmaで画面を作らず、freeeのデザインシステムを使ってClaude Codeでフロントエンドを実装しながらデザインを固めました。社内の検証環境へのデプロイも自分で行い、運用担当者に実際に触ってもらい、フィードバックを受けて改善するサイクルを回しました。
実装は、私が仕様と指示を書いてAIにコードを生成させ、生成されたコードを読んで直し、画面を動かして確かめてから、PRを出してエンジニアのレビューを受ける流れで進めました。計画と実装では、別のモデルを使い分けました。
特に時間をかけたのは、次の3つです。
何を作るか ：業務の要求と、チームで決めたことを、AIに渡せる仕様に落とすどれを採用するか ：AIに複数案を作らせ、比べて選ぶ。動くものを運用担当者やエンジニアに見せ、意見をもらうどこで止めるか ：仕様や議事録の記述をうのみにせず、確かめてから進めるAIで実装が速くなったので、動くものを見せてフィードバックを受け、構造を見直すサイクルを何度も回せました。5章の判断の変化の多くは、このサイクルから生まれました。
4. 主な設計判断 料金プラン管理ツールの画面遷移 カタログ管理から新規作成し、ウィザードで変更リクエストを作り、編集、申請前の確認へ進む。申請すると承認インボックスに入り、承認されると検証環境、本番の順に反映する。差戻しされると編集に戻る。 カタログ管理 表・ツリーで閲覧 変更リクエスト作成 ウィザードで作る 編集 商品ごとの表 申請前の確認 差分と目視で確かめる項目 承認インボックス 1次・2次の承認待ち 承認 差分を見て承認・差戻し 検証環境に反映 変更リクエスト一覧から 本番に反映 タイミングを選ぶ 申請 差戻し 画面遷移。差戻しされると編集に戻る 4-1. 閲覧・編集・承認を分ける プロトタイプは、閲覧画面からそのまま編集して保存する作りでした。実際の業務には申請・承認の流れがありますが、その機能はありませんでした。業務の流れを整理し、その切れ目に沿って画面を閲覧・編集・承認の3つに分けることを私から提案しました。
閲覧：スプレッドシートのような表で一覧する。階層をたどるツリー表示にも切り替えられる 編集：複数の変更をまとめて作る。新規作成はウィザードから始める 承認：承認待ちの変更を並べた承認インボックスで確認する プロトタイプから3空間へ 閲覧画面からそのまま編集・保存する作りで承認の機能がなかったプロトタイプを、業務の切れ目に沿って閲覧・編集・承認の3つに分けた。 Before：生成AIのプロトタイプ 閲覧画面からそのまま編集・保存 承認の機能はなかった 業務の切れ目で分ける 閲覧 表・ツリーで確認 編集 変更リクエストを作る 承認 承認インボックス After：各空間を、業務ごとに必要な情報と操作で構成する 業務の切れ目に沿って、画面を閲覧・編集・承認の3つに分けた 閲覧：テーブル表示。1行に1つの課金アイテムを表示し、商品からの階層を横に並べるクリック・タップで拡大 閲覧のテーブル表示。1行に1つの課金アイテムを表示し、商品からの階層を横に並べる
閉じる
閲覧：ツリー表示。階層をたどり、選んだ項目の詳細を右側に表示するクリック・タップで拡大 閲覧のツリー表示。商品の下に販売形態が並び、選んだ販売形態の詳細が右側に表示される
閉じる
編集：変更リクエスト一覧。状態ごとのビューで絞り込むクリック・タップで拡大 変更リクエスト一覧。編集中・申請中・差戻しなど、状態ごとのビューで絞り込める
閉じる
承認：承認インボックス。1段目と2段目の承認待ちに分け、対象・申請者・申請日だけを並べるクリック・タップで拡大 承認インボックス。1段目と2段目の承認待ちに分け、対象・申請者・申請日だけを並べる
閉じる
作成：どの導線から始めても、まず変更リクエストに名前を付けるクリック・タップで拡大 変更リクエストの作成。ステップ1で変更リクエストに名前を付ける
閉じる
作成：課金形態のパターンを選ぶと、作る商品が決まるクリック・タップで拡大 変更リクエストの作成。ステップ3で課金形態のパターンを選ぶと、作る商品が決まる
閉じる
4-2. 変更リクエストという単位 価格改定のように、実際の業務では複数の商品をまとめて変更します。そこで私から、変更したい対象をまとめた変更リクエストを作り、1つの変更リクエストにつき1回承認する 形を提案し、この単位で申請・承認する仕組みにしました。
編集画面は、商品ごとの表でセルを直接書き換える形 にしました。テンプレートと販売形態ごとに行をまとめ、申請前の確認画面では変更前後の差分と、目視で確かめる項目を並べています。最初の形からこの形に変えた経緯は、5章に書いています。
作り直した編集画面（ダミーデータで再現）。商品ごとの表で、テンプレートと販売形態ごとに行をまとめ、セルを直接書き換えるクリック・タップで拡大 作り直した編集画面。変更リクエストに含まれる商品ごとに表があり、テンプレート・Web経由・営業経由ごとに行がまとまっている。セルを直接書き換えて編集する
閉じる
申請前の確認画面（ダミーデータで再現）。価格の変更前後と、目視で確かめる項目を並べるクリック・タップで拡大 申請前の確認画面。価格の変更前後と、目視で確かめる項目が並ぶ
閉じる
4-3. 誤設定を防ぐ仕組み 背景で挙げた、組み合わせてはいけない商品を組み合わせるミスへの対策は、フェーズを分けて入れました。フェーズ1は、今の外部の課金サービスからそのまま業務を移せることをMVPとしていたので、次の2つにとどめました。
選択肢は、外部の課金サービスで定義されている値だけを選べるようにした 入力チェックを入れ、誤りはその場でエラーとして表示する セットで販売できないプランの組み合わせを、あらかじめ設定しておく機能はフェーズ2に回しました。
5. 検証で変わった設計判断 検証で変更した主な設計判断は、次のとおりです。
最初の判断 変えたきっかけ 変更後 外部の課金サービスの検証環境から本番環境へ反映する機能は作らない 運用担当者へのヒアリングで、検証環境で動作を確かめてから、公開のタイミングに合わせて本番に反映したいと分かった。私から提案し、PMの確認を経て採用 検証環境に反映したあと、本番に反映するタイミングを選べる2段階の手動反映にした 承認は1段階 開発チームの定例で、業務内容の確認と、課金システムへの影響の確認を分けることになった 運用担当者と、課金システムを管理するチームの2段階承認にした 編集画面はカード表示を既定にし、テーブル表示にも切り替えられるようにする 運用担当者へのヒアリングで、複数の商品をまとめて編集したいと分かった カード表示をやめ、商品ごとの表でセルを直接書き換える形にした。私から提案した（画面は4-2）
判断の変化を表す画面
2段階承認：1段目の承認記録を残したまま、2段目の承認を待つクリック・タップで拡大 2段階承認：1段目の承認記録を残したまま、2段目の承認を待つ
閉じる
環境反映：検証環境と同じ内容のまま、本番に反映するタイミングだけを選ぶクリック・タップで拡大 環境反映：検証環境と同じ内容のまま、本番に反映するタイミングだけを選ぶ
閉じる
6. 成果 閲覧・編集・承認を分けた画面構造と、変更リクエストの仕組みを提案・設計し、フェーズ1として8画面を実装した 検証環境で運用担当者が実際の作業を試し、フェーズ1の仕様とスコープが固まった。入力できる項目は運用担当者・承認者と決め、残りは次のフェーズに回した 作り直した編集画面を見た運用担当者から、「スプレッドシートの代わりに使える」という反応を得た 退職に伴い、リリース前に引き継いだ 7. 振り返り 言葉では出てこなかった要求も、動くものを見せると運用担当者が具体的に指摘してくれた。先に業務を整理し、そのうえで動くもので確かめる進め方が、この案件に合っていた 検証の中で、環境反映や編集画面の設計を途中で変えた。次の案件では、変えた理由と決めた人をその都度記録し、後からも経緯を説明できるようにしたい コードの生成をAIに任せた分、何を作るか、どれを選ぶか、どこで止めるかの判断に時間を使えた。あわせて、仕様をチームと詰める時間も増えた フェーズ1で引き継いだため、リリース後の使われ方は見られていない。次の案件では、リリース後の使われ方まで見て改善を続けたい プロジェクト情報 項目 内容 概要 タブを使いたい要望は増えていたが、使ってよい場面が決まっていなかった。タブコンポーネントをReactで実装し、ビュー・タブ・ページ分けの使い分けの基準を作成した。ガイドラインは初版のまま現在も使われ、判定フローはほかのデザイナーも判断に使っている。 期間 2025年5月〜7月（約3か月） 対象 freeeの業務アプリ向けデザインシステム vibes 担当領域 コンポーネント設計・実装：Reactでのタブコンポーネントの実装 ガイドライン作成：使い分けの基準と判定フロー 体制 一人で担当。ガイドラインはエンジニア、コンポーネントはデザインシステムのメンテナーのレビューを受けた
1. 背景 プロダクト側から、関連する複数の一覧をまとめて設定したり、切り替えて見たりするためにタブを使いたいという要望が増えていた vibesには以前からタブコンポーネント があったが、新しい画面テンプレートのデザインに合うタブはなかった タブを使ってよい場面が決まっておらず、問い合わせも多かった そこで、新しいタブコンポーネントを実装することになりました。コンポーネントだけを作ると、タブが乱用されて情報が隠れる画面が増えるため、コンポーネントと使い分けの基準をセットで作ることにしました。
2. タブコンポーネントの実装 タブは、特定の画面専用ではなく、どの画面でも使える汎用のコンポーネントとしてReactで実装しました。どこに置くか、新規作成ボタンとどう並べるかといった使い方のルールはコンポーネントに持たせず、ガイドラインに書きました。コンポーネントはシンプルに保ち、ルールだけを後から見直せるようにするためです。
実装したタブコンポーネント。選択中のタブを背景色と枠線で示すクリック・タップで拡大 実装したタブコンポーネント。3つのタブが並び、選択中の1つ目は背景色と枠線で区別される
閉じる
3. 画面ごとの使い分けの基準 ガイドラインを読めば、問い合わせなしで使い分けられることを目標にしました。
一覧画面 一覧画面での使い分けは、一覧に並ぶオブジェクトの種類と、表示する列をもとに、次のように定義しました。
ビュー ：同じオブジェクト・同じ列で、絞り込みの観点だけが違うものタブ ：同じオブジェクトでも表示する列が変わるもの。または、1つの業務のまとまりが2種類以上のオブジェクトにまたがり、頻繁に行き来したり、初期設定でまとめて設定したりするものページ分け ：どちらにも当てはまらないもの。業務のまとまりごとに画面を分ける一覧画面のビュー・タブ・ページ分けの判定 一覧に並ぶオブジェクトが1種類で列が同じならビュー、列が異なればタブ。複数種類のオブジェクトの一覧を頻繁に行き来するか、初期設定でまとめて設定するならタブ。それ以外はページを分ける。 一覧に並ぶオブジェクトは1種類？ はい いいえ 列は常に同じ？ 一覧の間を頻繁に 行き来する？ はい いいえ ビュー タブ はい タブ いいえ 初期設定で まとめて設定する？ はい いいえ タブ ページを分ける 同じオブジェクト・同じ列で、絞り込みの観点だけが違う場合はビュー 一覧画面で、ビュー・タブ・ページ分けを使い分けるための判定フロー ほかに、タブは最大5個まで、ラベルは短くし、ユーザーが入力した文字列は使わない、と決めました。ガイドラインは、レビューでの指摘を受けて専門用語を利用者に伝わる言葉に直すなどしてから公開しました。
詳細画面 同じ時期に、あるプロダクトのチームから「詳細画面で、タブを使って情報を分けて保存したい」という相談を受けました。周辺の画面も含めて調べたうえで、そのプロダクト固有の情報設計の課題と、詳細画面でタブを使う基準がないという課題に分け、後者の基準を作りました。
詳細画面では、メインの情報そのものはタブで分けません。作業しながら横に並べて見たい情報があるときはSplit viewにし、その情報が複数あるときだけ、サブ側をタブで切り替えます。
詳細画面の表示構成の判定 一覧から開く詳細画面でなければページを分けグローバルナビゲーションで移動する。作業中に同時に見るサブ情報がなければ、セクションと項目が多いときはページ内に目次を置き、そうでなければ目次なしで縦に並べる。サブ情報が1つならSplit view、複数ならSplit viewのサブ側にタブを使う。 一覧から開く詳細画面？ いいえ はい ページを分ける グロナビで行き来 業務上、作業しながら同時に 見るべきサブの情報がある？ いいえ はい セクションが多く 項目も多い？ 同時に見たいサブの情報が 複数ある？ はい いいえ ページ内に 目次を置く 目次なしで 縦に並べる いいえ はい Split view Split view ＋サブ側にタブ メインの情報そのものはタブで分けない タブは、複数のサブ情報を切り替えるために使う 詳細画面の表示構成を選ぶ判定フロー。タブはSplit viewのサブ側で使う 振り返り コンポーネントの追加要望には、使い分けの基準もセットで用意する。今後コンポーネントを追加するときも、この進め方を続けたい その他のUI設計 主要な3事例のほか、複数のプロダクトで共通利用される基盤領域で、マスタ管理などのUI設計を担当しました。
共通基盤 / UI設計
取引先マスタ管理 freee会計で管理されていた取引先マスタ を、複数のプロダクトで共通利用できるように独立させるプロジェクトに参加しました。登録・編集画面の再設計、一覧の検索・絞り込み、各プロダクトからの導線の検討を担当しました。また、登録・編集・削除や一括インポートなど、マスタ管理に関わるUI設計にも携わりました。
共通マスタとしての登録・編集画面の設計 取引先には、顧客・請求先・入金元・仕入先・支払先など複数の関係があり、利用するプロダクトによって必要な情報が異なります。既存の販売・調達の分類や、複数の関係を設定できる仕様は踏襲しつつ、登録・編集画面の構成を見直しました。
すべての設定項目を常に表示する案、販売・調達で画面を分ける案、関係に応じて必要な項目だけを表示する案を比較しました。そのうえで、設定画面の複雑さを抑えるため、選択した取引先との関係に応じて必要な設定項目を表示するUI を採用しました。
自身が画面構成とUI案を作成し、PMによる業務要件・優先順位の整理や、エンジニアによる実装可否の検証を踏まえて、関係者と協議しながら最終案を決定しました。
取引先の登録画面。左の目次から各セクションへ移動できるクリック・タップで拡大 取引先の新規作成画面。左の目次から、基本情報・取引先住所・書類に使用する名称などの各セクションへ移動できる
閉じる
取引先との関係。販売・調達それぞれの関係をチェックボックスで設定するクリック・タップで拡大 取引先の新規作成画面の「取引先との関係」。販売設定（顧客・見込顧客・請求先・入金元・送付先）と調達設定（仕入先・支払先・送付先）をチェックボックスで設定する
閉じる
取引先一覧。状態や取引先との関係などで絞り込めるクリック・タップで拡大 取引先一覧。上部に、状態・取引先コード・自社担当者・取引先との関係・適格請求書発行事業者の絞り込みが並ぶ
閉じる
標準UIの導入と、リリース後の改善 本プロジェクトは、一覧・登録・編集などの画面パターンを共通化する「標準UI」の初期パイロットケースでもありました。自身は標準UIを利用する側として、デザイン面での適用可能性を検討しました。実装可否はエンジニアと確認し、標準UI自体の開発は別チームが担当しました。
設計した画面はリリースされ、freee会計、freee販売、freee請求書、freee経費精算などで共通の取引先マスタとして使われています。一方、標準UIの導入で従来の画面から見た目や操作体験が大きく変わり、罫線が少ないことで情報のまとまりを把握しづらいといった課題が生じました。
リリース後にプロダクト上へフィードバックフォームを設け、寄せられた意見に優先度を付けて対応しました。また、標準UIチームにもフィードバックを共有し、情報のグルーピングや余白の改善は標準UI側にも取り込まれました。 あわせて、一覧の検索・絞り込みの改善や、不具合修正、細かなUI調整にも取り組みました。
これから 今後も、業務アプリのUI/UX設計とDesignOpsの両方に、プレイヤーとしてプロダクトに深く関わりながら取り組みたいです。
AIによって、デザインの作業はこれから効率化が進むと考えています。そのぶんデザイナーは、職種を越境する必要があります。私はこれまで、デザインシステムの開発やフロントエンドの実装など、エンジニア寄りの仕事にも関わってきました。今後は、「何を作るか」の判断にも責任を持てるデザイナーになりたいです。
料金プラン管理ツールでは、Figmaを使わずに、デザインシステムとAIで実装しながら設計を固めました。AIでデザイナーの働き方が変わっていくことを、実際のプロダクト開発の中で形にしていきたいです。
画面キャプチャはダミーデータで撮影しています。社内用語・人名は、一般的な言葉や役割名に置き換えています。
© 2026 大山 奈津妃
