大山 奈津妃

課題

開発チームごとにUIの確認方法が異なり、知見も蓄積されていなかった。

自分の担当

UIレビュー制度の発案・設計と定着、n8nでのナレッジ収集・Confluenceへの文書化、AI一次レビューの設計・検証と導入。

結果・到達点

開発案件として管理されているUI変更は、すべてレビューを通してリリースされるように。四半期約70〜80件を継続運用。150件以上の指摘をナレッジ化し、6件を全社ガイドラインに反映。シニアデザイナーの工数は約50%減と推計。

案件情報

複数のプロダクトで共通利用される基盤領域で、UIレビューを制度化しました。運用の中で見えた課題に対し、指摘のナレッジ化とレビュー負担の分散に取り組みました。

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一次レビューで参照できるようにし、他のプロダクトにも共通する内容は全社デザインガイドラインの改善候補にしました。

3-2. n8nによるナレッジ蓄積の自動化

ナレッジの収集と文書化は、n8nとAIで自動化しました。週に1回、レビュアーの指摘を集めて、AIが判断基準に照らしてナレッジにする候補を選び、Slackのリストに登録します。人が内容を確認してナレッジにすると決めたものだけ、AIがカテゴリや関連するガイドラインの項目を付けて、Confluenceに文書を作ります。ナレッジとして残すかどうかは、人が判断します。

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%減と推計した

課題

外部の管理画面は誤設定を防げず、編集や比較もしにくい。運用はスプレッドシートと人の確認に頼っていた。

自分の担当

業務整理と画面構造の提案、情報設計・UI設計。運用担当者やエンジニアとの検証と、AIを活用した実装。

結果・到達点

閲覧・編集・承認を分離し、変更リクエスト単位の画面構造を設計。フェーズ1の8画面を実装し、検証環境で運用担当者が実際の作業を試せる状態に（退職に伴い、リリース前に引き継ぎ）。

案件情報

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. 主な設計判断

4-1. 閲覧・編集・承認を分ける

プロトタイプは、閲覧画面からそのまま編集して保存する作りでした。実際の業務には申請・承認の流れがありますが、その機能はありませんでした。業務の流れを整理し、その切れ目に沿って画面を閲覧・編集・承認の3つに分けることを私から提案しました。

• 閲覧：スプレッドシートのような表で一覧する。階層をたどるツリー表示にも切り替えられる
• 編集：複数の変更をまとめて作る。新規作成はウィザードから始める
• 承認：承認待ちの変更を並べた承認インボックスで確認する

閲覧のテーブル表示。1行に1つの課金アイテムを表示し、商品からの階層を横に並べる

閉じる

閲覧のツリー表示。商品の下に販売形態が並び、選んだ販売形態の詳細が右側に表示される

閉じる

変更リクエスト一覧。編集中・申請中・差戻しなど、状態ごとのビューで絞り込める

閉じる

承認インボックス。1段目と2段目の承認待ちに分け、対象・申請者・申請日だけを並べる

閉じる

変更リクエストの作成。ステップ1で変更リクエストに名前を付ける

閉じる

変更リクエストの作成。ステップ3で課金形態のパターンを選ぶと、作る商品が決まる

閉じる

4-2. 変更リクエストという単位

価格改定のように、実際の業務では複数の商品をまとめて変更します。そこで私から、変更したい対象をまとめた変更リクエストを作り、1つの変更リクエストにつき1回承認する形を提案し、この単位で申請・承認する仕組みにしました。

運用担当者は、変更前後を比べて見られるという理由でCSVを使い続けており、複数の商品をまとめて編集したいという要望もありました。そこで私から提案し、編集画面を商品ごとの表でセルを直接書き換える形にしました。テンプレートと販売形態ごとに行をまとめ、申請前の確認画面では変更前後の差分と、目視で確かめる項目を並べています。運用担当者からは「スプレッドシートの代わりに使える」という反応がありました。

作り直した編集画面。変更リクエストに含まれる商品ごとに表があり、テンプレート・Web経由・営業経由ごとに行がまとまっている。セルを直接書き換えて編集する

閉じる

申請前の確認画面。価格の変更前後と、目視で確かめる項目が並ぶ

閉じる

4-3. 誤設定を防ぐ仕組み

外部サービスの管理画面で起きていた、組み合わせてはいけない商品を組み合わせるミスへの対策は、フェーズを分けて入れました。フェーズ1は、今の外部サービスからそのまま業務を移せることをMVPとしていたので、次の2つにとどめました。

• 選択肢は、外部サービスで定義されている値だけを選べるようにした
• 入力チェックを入れ、誤りはその場でエラーとして表示する

セットで販売できないプランの組み合わせを、あらかじめ設定しておく機能はフェーズ2に回しました。

5. 検証で変わった設計判断

検証で変更した主な設計判断は、次のとおりです。

判断の変化を表す画面

2段階承認：1段目の承認記録を残したまま、2段目の承認を待つ

閉じる

環境反映：検証環境と同じ内容のまま、本番に反映するタイミングだけを選ぶ

閉じる

6. 成果

• 閲覧・編集・承認を分けた画面構成と、変更リクエストの仕組みを提案・設計し、フェーズ1として8画面を実装した
• 検証環境で運用担当者が実際の作業を試し、フェーズ1の仕様とスコープが固まった
• 作り直した編集画面を見た運用担当者から、「スプレッドシートの代わりに使える」という反応を得た
• 退職に伴い、リリース前に引き継いだ

7. 振り返り

• 言葉では出てこなかった要求も、動くものを見せると運用担当者が具体的に指摘してくれた。先に業務を整理し、そのうえで動くもので確かめる進め方が、この案件に合っていた
• 環境反映や編集画面の設計は、運用担当者やチームの指摘を受けて途中で変え、最初の案より業務に合う形になった。次の案件では、変えた理由と決めた人をその都度記録し、後からも経緯を説明できるようにしたい
• コードの生成をAIに任せた分、何を作るか、どれを選ぶか、どこで止めるかの判断に時間を使えた。あわせて、仕様をチームと詰める時間も増えた
• フェーズ1で引き継いだため、リリース後の使われ方は見られていない。次の案件では、リリース後の使われ方まで見て改善を続けたい

課題

タブを使いたいという要望は増えていたが、使ってよい場面が決まっていなかった。

自分の担当

タブコンポーネントの実装と、使い分けのガイドライン作成。

結果・到達点

タブコンポーネントと、ビュー・タブ・ページ分けの使い分けの基準を作った。判定フローは、ほかのデザイナーも判断に使っている。

案件情報

1. 背景

プロダクト側から、関連する複数の一覧をまとめて設定したり、切り替えて見たりするためにタブを使いたい、という要望が増えていました。

vibesには以前からタブコンポーネントがありましたが、新しい画面テンプレートのデザインに合うタブはありませんでした。そこで、新しいタブコンポーネントを実装することになりました。

ただ、タブを使ってよい場面が決まっておらず、問い合わせも多くありました。コンポーネントだけを作ると、タブが乱用されて情報が隠れる画面が増えます。そのため、コンポーネントと、使い分けの基準をセットで作ることにしました。

2. タブコンポーネントの実装

タブは、特定の画面専用ではなく、どの画面でも使える汎用のコンポーネントとしてReactで実装しました。どこに置くか、新規作成ボタンとどう並べるかといった使い方のルールはコンポーネントに持たせず、ガイドラインに書きました。コンポーネントはシンプルに保ち、ルールだけを後から見直せるようにするためです。

実装したタブコンポーネント。3つのタブが並び、選択中の1つ目は背景色と枠線で区別される

閉じる

3. 画面ごとの使い分けの基準

ガイドラインを読めば、問い合わせなしで使い分けられることを目標にしました。

一覧画面

一覧画面での使い分けは、一覧に並ぶオブジェクトの種類と、表示する列をもとに、次のように定義しました。

• ビュー：同じオブジェクト・同じ列で、絞り込みの観点だけが違うもの
• タブ：同じオブジェクトでも表示する列が変わるもの。または、1つの業務のまとまりが2種類以上のオブジェクトにまたがり、頻繁に行き来したり、初期設定でまとめて設定したりするもの
• ページ分け：どちらにも当てはまらないもの。業務のまとまりごとに画面を分ける

ほかに、タブは最大5個まで、ラベルは短くし、ユーザーが入力した文字列は使わない、と決めました。ガイドラインはエンジニアのレビューを受け、専門用語を利用者に伝わる言葉に直すなどしてから公開しました。

詳細画面

同じ時期に、あるプロダクトのチームから「詳細画面で、タブを使って情報を分けて保存したい」という相談を受けました。周辺の画面も含めて調べたうえで、そのプロダクト固有の情報設計の課題と、詳細画面でタブを使う基準がないという課題に分け、後者の基準を作りました。

詳細画面では、メインの情報そのものはタブで分けません。作業しながら横に並べて見たい情報があるときはSplit viewにし、その情報が複数あるときだけ、サブ側をタブで切り替えます。

振り返り

• コンポーネントの追加要望には、使い分けの基準もセットで用意する。今回はコンポーネントとガイドラインを同時に作り、乱用と問い合わせを防ぐ形にした。今後コンポーネントを追加するときも、この進め方を続けたい
• コンポーネントは汎用のままにし、使い方のルールはガイドラインに分けたことで、ルールだけを後から見直せる形にできた