担当領域を越えて学び合う― 「LegalOn」のDesigner BootCamp
こんにちは。LegalOn Technologiesでプロダクトデザイナーをしている安達です。
最近、私たち「LegalOn」のプロダクトデザインチームでは、デザイナー同士の知識や経験をより効果的に共有するため「Designer BootCamp」という取り組みを始めました。
この記事では、その背景や狙い、実際に取り組んだ内容、そして取り組みを通じて得られた学びについてご紹介します。
担当領域を越えて学び合う
「LegalOn」のプロダクトデザインチームでは、「ユーザー理解の徹底的な深化」を大きな方針のひとつに掲げています。
ですが、契約審査や電子締結、契約管理など製品がカバーする業務領域が多岐に渡るため、一人でプロダクトすべてを見るのは現実的ではありません。そこで開発組織としては、領域ごとに担当を持つ仕組みを取っています。私たちはその単位を「モジュール」と呼んでいます。
ちなみに「LegalOn」がサポートしているモジュールの一覧はこちら。

この体制は専門性を高めたり、仕事をスピーディに進めるにはとても合理的。
一方で、ドメイン知識や知見がモジュール内にとどまりやすくなるという悩ましさもあります。
たとえば、「自分が担当している範囲では正しい判断だったけど、他のモジュールと並べるとちょっとちぐはぐかも」といったことが起きる。
そのまま放っておくと、プロダクト全体の一貫性が崩れたり、ユーザーにとって「なんか使いにくい」状態に。
こうした課題をふまえ、私たちは知識や視点をモジュールの枠を超えて流通させる仕組みをつくることにしました。
Designer BootCamp、はじめました
取り組みの名前は「Designer BootCamp」。
ちょっと強そうな名前ですが、内容はもっとゆるやかです。
週に1回1時間ほど「LegalOn」のプロダクトデザイナーが集まって、担当しているモジュールを他のメンバーに紹介して、実際に触ってもらったり。
逆に、自分の担当外の機能についてアイデアを出し合ったり。
特に決まった形式を持たない、プチワークショップ的なものになっています。
この場の面白いところは、普段関わらない領域だからこそ出てくる素朴な質問。
「この機能ってどういう時に使うの?」
「これはユースケースとしては〜〜という時を想定してて…」
「なるほど、だから次のアクションがこういう風になっているのか」
「ここってなんでこういう設計になってるんだっけ?」
「それはこういう事情があって」
「うーん、可能ならこういう風にした方がいいんじゃないかな」
質問から話が広がり、「じゃあ別のモジュールでは?」「全体で見るとこう繋がってるのか」といった会話に広がることも。
気づけば、普段あまり触れない領域への関心が自然と芽生えてくるのです。
情報共有から一歩進んで、ひらめきにつながる場に
最近のBootCampでは、直近の生成AIの動向を受けて「エージェンティックな体験とはどのようなものか?」というテーマでアイデア出しをしました。
つまり「もっとシームレスで賢い体験にするには、どんな工夫ができるか?」というお題。
miroを使いながら、「ここにAIが入れば負担が軽くなりそう」「ここは判断を自動化できるかも」といった案を自由に出していきました。
「作業はAIに全部やってもらって確認だけにしたい
「確認も都度やるんじゃなくて、最後にまとめてやりたいよね」
「そうしたら、法務の負担すごく減りますね」
他のメンバーのアイデアを見ながら進めていくことで、自分のアイデアの幅も広がる。
「自分の領域だったらこういう風にできそう」と連鎖的に思いつくのです。
単なる知識共有にとどまらず、新しい発想のきっかけにもなっていて、チーム内でも好評でした。
こういった場があることで、機能開発の方向性をチーム全員でしっかり合わせることができます。
結果として、プロダクト全体の一貫性を実現することにもつながっているのではないのでしょうか。


やってみてどうだった?
BootCampのあとにアンケートを取ったところ、嬉しい反応がいくつも返ってきました。
特に多かったのが、次のような声です。
「以前よりも他モジュールへの理解が深まった」
「他の人の取り組みに刺激を受けた」
「これまで関心のなかった領域にも興味が湧いてきた」
これまで他モジュールのことを知るには、直接担当者に聞くしかなかったのですが、BootCampなら自然と情報が入ってくる。
また、「同じデザイナーだけど、XXさんが何をしているのかわからない」といった状態も減りました。
自然とそれぞれの取り組みを知るきっかけが生まれたからこそだと思います。
中には、「ファシリテーションの進め方が参考になった」という声も。
ナレッジの中身だけでなく、伝え方からも学びがあったようです。
「もっと知りたい」が自然に出てくる場に
面白かったのはナレッジを共有したことで、新たに「これも知りたい」がたくさん出てきたことです。
たとえば、こんな内容が寄せられました(具体的な機能名は伏せています):
最近のユーザーヒアリング、どんな課題が見えてきてる?
「LegalOn」導入時のユーザー体験がどんな感じなのか知りたい。
XXX関連のユーザー体験をもっと良くしたいのでアイデア出ししたい
XXXという機能って実際どう使っている?
Figmaの新機能、使ってる人いたらコツとか教えてほしい!
こうした声が自然に出てくるということは、情報が「伝わる」だけでなく「つながる」状態になってきている証拠かもしれません。
また、直近では日々感じている課題を解決するためにハッカソンを開催しました!
ハッカソンでのアウトプットの一例はこちらです。
「UIの文言ってデザイナー(人)が毎回悩んで決める必要ある?」「人が考えてると一貫性無いよね」
— UXマン/ AI Product Manager (@yoshinaga2015) September 2, 2025
…という課題感から、社内ハッカソンで、テキストガイドラインに沿った文言を一気に書いてくれるFigmaプラグイン作りました。
「ボタンは"送信"? "送信する"?」 的な悩みから解放された😭 pic.twitter.com/5VnsY20lhY
担当領域を越えて知ることの価値
BootCampを通じて、あらためて感じたのは「担当領域を横断した学び合い」の大切さでした。
プロダクトはひとつの大きな体験であって、モジュール単体でジャーニーが完結することはほとんどありません。
それぞれの領域がどう繋がり、どう補い合っているのかを知ること。
そうすることで結果として自分の担当範囲はもちろん、全体としてより良いプロダクトを作れるのではないでしょうか。
また、デザイナー間でのコミュニケーションのきっかけにもなっています。
私自身、「これはあの人に聞いてみようかな」といったアクションが取りやすくなり、動きもスムーズになりました。
枠を越えて学び合えるチームであり続ける
ナレッジの共有は、単なる情報のやりとりではなく、視点を広げるきっかけになります。
「自分の範囲」から一歩外に出てみることで、見えてくるものがたくさんある。
そして、それは自分の仕事の深みや幅を広げてくれることにもつながります。
これからもモジュールの枠を超えて学び合いながら、プロダクト全体としてユーザーに素晴らしい体験を届けていきたいです。
