こんにちは！RSSでインハウスデザイナーをしているS.R.です。
プロダクト開発の現場で、「画面は綺麗だけどデータ構造とチグハグで実装しにくい」「仕様の認識合わせに時間がかかる」といった課題に直面することはありませんか？これらは、デザインと実装の間に「共通の言語」が足りないことが原因かもしれません。

チーム全体の設計力を底上げするため、「OOUI（オブジェクト指向UI）× Figma」をテーマにした全6回の実践型ワークショップを開催しました。今回はそのプロセスと得られた知見を共有します。

1. なぜ「OOUI」と「Figma」が必要だったのか

きっかけは、「みんなで手を動かす機会を作りたい」というシンプルな思いでした。その中でOOUIを選んだ理由は、「AIで誰でもUIが作れる時代がくるからこそ、根本の設計思想こそが差別化になる」と考えたからです。

情報設計に強いOOUIと、職種を問わずリアルタイムに作業できるFigma。この2つを掛け合わせることで、エンジニアとデザイナーが「ロジカルに対話できる場」を作れると考えました。

2. 「現場の納得感」を優先したカリキュラム設計

本来、OOUIの演習課題は厳密で複雑なものですが、今回は限られた時間内で「考え方の基礎」を体感してもらうことに特化。アカデミックな正しさよりも、チームの現状に合わせた再構築を行いました。

AI（Gemini）を「壁打ち相手」にした客観的な視点

企画を練る際、デザイナーとしての主観やバイアスを避けるため、AI（Gemini）を相談役に活用しました。自分の「教えたいこと」に、参加者のスキル分布やアンケート結果という「客観的なデータ」を掛け合わせ、以下のような工夫を行いました。

• スキル差への対応
  初心者向けの基本操作をベースにしつつ、上級者には「オートレイアウト」など発展的な課題を提示する「二段構え」の構成に。
• 思考の言語化
  無意識の操作（グループ化とフレームの使い分けなど）を、OOUIの文脈でどう説明すれば非デザイナーに伝わるか徹底的に言語化。
• 時間配分のシミュレート
  「あれもこれも」と欲張る気持ちを抑え、30分や60分という枠の中で本当に持ち帰ってほしい情報だけを絞り込みました。

「自分が当たり前だと思っていること」を一度Geminiに投げ、フラットなロジックとして組み立て直すことで、チームのみんなが迷わず参加できるワークショップを設計することができました。

3. プロセスと成果：NPSは「9.1」へ

ワークショップは全6回、前半を知識習得、後半を共同作業（グループワーク）として構成しました。

ワークアウトの流れ

• 第1-3回：OOUIの基礎とFigma操作、個人での画面作成
• 第4-5回：グループワーク（UIアイデア出しと共同実装）
• 第6回：最終発表会とフィードバック

回を追うごとに満足度（NPS）も向上し、前半平均 8.56 から後半平均 9.1 という高いスコアをいただくことができました。
もちろん、NPSという数字は判断材料のひとつに過ぎず、「数字が高い＝全てが成功」とは限りません。ですが、全6回という長丁場において、最後まで参加者の皆さんに前向きな満足感を持っていただけたことは、純粋に嬉しく感じています。

現場で見えてきた「変化の兆し」

参加者からの声を聞くと、単なるツール習得を超えた「気づき」が生まれていました。

• 「いきなり描かない」ことへの納得感
  オブジェクトを整理してから画面を作る手順が、「何が必要か」を明確にするロジカルなプロセスとして受け入れられました。
• 共通の作業場としてのFigma
  Figmaが単なる制作ツールではなく、職種を問わずその場でアイデアを形にする「議論の場」として定着しました。
• 共創文化の土壌
  他チームの視点に触れることで、自分一人では到達できないアイデアに価値を感じるというポジティブな反応が見られました。

4. 失敗から学んだ「難易度設定」の重要性

もちろん、すべてが順調だったわけではありません。振り返ると工夫できた点も多々あります。特に後半戦、業務に近い複雑なテーマを扱った際、私自身が「教え方の難易度」に頭を悩ませる場面がありました。

具体的には、「オブジェクトという抽象概念を、Figmaのどの機能（グループ、フレーム、オートレイアウト等）で表現させるのが正解か」という判断です。Figmaには一つの表現に対して複数のやり方があります。参加者のスキルが多様な中で、「思想（OOUI）を伝えること」と「ツールの仕様（Figma）」のどちらを優先すべきかのバランスが難しく、一部で設計への集中を妨げてしまう場面がありました。学習時はあえてシンプルな題材に固定し、まずは「プロセスの型」の習得に集中できる環境を作るべきだった、というのが大きな学びです。

また、オンライン開催という環境下で、スキルの異なるメンバーを混ぜてグループ分けをした際の影響も大きな学びでした。「詳しい人がいれば聞きやすくなるだろう」という意図で編成しましたが、実際には操作に慣れていない方が声を上げにくくなってしまったり、スキルの高い人のペースに飲み込まれてしまったりした場面もあったと感じています。物理的な距離があるオンラインだからこそ、グループ分けの構成やサポートの厚みをどう設計すべきだったか。考えればキリがありませんが、参加者一人ひとりの心理的安全性をもっと考慮できたのではないか、と痛感しました。
こうした現場での細かな難易度設定の難しさを痛感したからこそ、事前準備でのGeminiとの壁打ちがいかに重要だったかも、改めて実感する結果となりました。

まとめと今後の展望

今回の取り組みを通じて、チーム内には「UIはセンス（感性）ではなく、データ構造に基づくロジックである」という共通認識が芽生えました。エンジニアがデザインのロジックを理解し、デザイナーが実装の制約を理解する。この相互の歩み寄りこそが、これからのプロダクト開発の理想的なスタンダードになると確信しています。

一方で、このワークショップを企画・実施した時期は、今のようなAIの激しい波が来る少し前でした。現在の進化を踏まえると、また違った最適なやり方が数多くあるはずです。
社内でもエンジニアを中心にClaudeなどの活用が進んでいます。デザインとエンジニアリングの境界線がさらに変化していく中で、どのようなフローが今の私たちにとって最適なのか、これからも模索しながら「社内での正解」を見つけていければと思います。

RSSでは、こうした職種の壁を越えた技術共有を推奨しています。エンジニアリングとデザインの両輪でプロダクトを推進したい方がいれば、ぜひ一度お話ししましょう！

エンジニア募集中！

レイスシステムソリューションズ（コーポレートサイト）