昨日は [Schema by Figma](https://schema.figma.com/tokyo) という Figma が開催するデザインシステムのイベントに参加してきました。

その中で Figma の VP of Product である [Sho Kuwamoto](https://twitter.com/skuwamoto) 氏によるオープニング・キーノートが特に印象に残ったので備忘録を残しておきます。

（聞きながらリアルタイムに同時通訳をメモしていたため、もしかすると引用が微妙に間違っている可能性があります...ご容赦ください...）

---

Figma はこれまでフリーフォームなデザインと構造的なデザインをどちらもカバーすることを重要視してきたとのこと。

現在はデザインシステムが成長し進化するにつれ、その複雑さもどんどん増してきています。

その複雑化をレイアウトの複雑化、テーマの複雑化、プロセスの複雑化という 3 つのセクションにわけて説明されていました。

# レイアウトの複雑化

![Layout](https://user-images.githubusercontent.com/945841/199632761-e52ba373-2507-424c-9f75-53d4d62ecfd2.png)
_[Figma help center](https://help.figma.com/)より引用_

> デザインシステムで扱うレイアウトはアプリケーションの要件によってどんどん複雑化している。複雑なコンポーネントの例として、Card コンポーネントが挙げられる。 Card コンポーネントは中身のレイアウトが複数存在し、管理が非常に難しいので Nesting components を使う。

このあたりはまさに Card コンポーネントを例に、EightShapes の Nathan Curtis 氏が 「Subcomponents. Relinquish control, offer parts, and…」という記事で詳しく解説しているのを自分はよく参考にしています。

- [Subcomponents. Relinquish control, offer parts, and… | by Nathan Curtis | EightShapes | Medium](https://medium.com/eightshapes-llc/subcomponents-753ce9f6600a)

# テーマの複雑化

![Theme](https://user-images.githubusercontent.com/945841/199632982-685786d0-4f1b-493c-941b-9f7839cb020f.png)
_[Figma help center](https://help.figma.com/)より引用_

> 複数ブランドにライトモードやダークモードなど、様々なテーマが求められるようになり、複雑化している。
> その解決方法としては「Headless design system」が挙げられる。

Headless design system とはあらゆるテーマで使える"ヘッドレス"なデザインシステムを設計し、デザイントークンを置き換えることで、様々なテーマを一つのデザインシステムでまかなえるようにしたものです。

これは [Figma tokens](https://www.figma.com/community/plugin/843461159747178978/Figma-Tokens) のコミッターでもある Esther Cheran 氏が「Building a headless design system」の動画の中で説明している内容が参考になりそうです。

- [In the file - Building a headless design system - YouTube](https://www.youtube.com/watch?v=yvblQEPGPkM)

また、このトピックに関しては自分も前回の Config by Figma のセッションの「One design system for multiple brands」で話させていただきました。

- [One design system for multiple brands - Ryo Fukushima (Config 2022) - YouTube](https://www.youtube.com/watch?v=vWaePdvHEhE)

前職の [GMO ペパボ株式会社](https://pepabo.com/)の共通基盤デザインシステム [Inhouse](https://design.pepabo.com/inhouse/) のコンポーネントを設計するにあたって、まさにこの「Headless design system」にかなり影響を受けていて、現職の[家計簿プリカ B/43](https://b43.jp/) を運営する[株式会社スマートバンク](https://smartbank.co.jp/)においても現在、いくつかのクレジットカードのテーマや Brightness に対応できる Headless なデザインシステムを設計しています。

# プロセスの複雑化

![Branching in Figma](https://user-images.githubusercontent.com/945841/199632583-b3d57335-19fe-45df-bf34-c101b25f597c.png)
_[Figma help center](https://help.figma.com/)より引用_

> チームメンバーの増加に伴い、他の人が何をしているかわからなくなっていく複雑化がある。デザインシステムの更新は多くても月に 1 度程度だろうと考えていたが、実際に調査してみると平均して日に 1、2 回もの変更が加えられていることがわかった。

この問題に関してはドキュメンテーション、ブランチとマージや、コードの世界でいうテストコードのような VRT（Visual Regression Test）を整備して解決していく方法がよく用いられているとのこと。

VRT に関しては、[Storybook](https://storybook.js.org/) で [Chromatic](https://www.chromatic.com/) を用いたものは自分もよく活用していますが、Figma のコンポーネントにおいても簡単にできると確かに便利そう。

Figma のブランチとマージをまだ本番運用したことがないのであまり詳しくないのですが、GitHubのオニオンスキンのような形で比較できるようです。

- [Visual regression testing for design systems with Figma branches](https://honzatmn.substack.com/p/visual-regression-testing-for-design)

# まとめ

![Freeform Design & Structured Design](https://user-images.githubusercontent.com/945841/199633340-d979bac3-0659-4696-af32-ed3bbf17e010.png)
_[Figma のツイート](https://twitter.com/figma/status/1446143385748660231?s=20&t=xKTBnJP8btyJuPbrV6u_Cg)より引用_

> 現在のデザインシステムにおいては、これまで説明したように複雑なレイアウトのコンポジション、Headless design system、分岐とマージ、テストドリブンデザインなどコードの世界の考え方を参考にした手法が多い。

> このような考え方がコードの世界から来ているのは偶然ではなく、デザインシステムはより複雑な世界に進んでいるため、コードからのアイデアを借りている。

> しかしコードの考え方を借りることで、デザインが型にはまってしまう。デザイナーを型にはめたくない、柔軟性を失わせたくない。

> 冒頭で説明したように Figma はフリーフォームなデザインと構造的なデザインをどちらも大切にしたい。

> このような複雑性に対応するためには問いのフレーミングが重要。

> 間違いをしないようにデザインしようというのが昔は主流だったが、現在はデザインシステムがあるから間違えることはなくなった。ミスを避けるというのはクリエイティビティを制約する。デザインシステムを摩擦を減らすものと捉えている。

このような構造化されたデザインへの捉え方は自分もすごく同意していて、クリエイティビティを発揮するために、考えなくても良い摩擦を減らす、そして、もっと本質的なデザインに集中するためにデザインシステムを作っているよなぁと日々感じています。

また、エンジニアリングの世界を参考にした手法が多いというのは本当にそうで、デザインシステムを作る上でエンジニアリングに関する知識を蓄えることの重要性が日々増していっているのをひしひしと感じます。

今後どのようにエンジニアリングの手法によってさらなるデザインシステムのパラダイムシフトが起きていくかとても楽しみです。


Schema by Figma 2022の備忘録

はじめましての方ははじめまして。久しぶりの方はお久しぶりです。デザイナーの [putchom](https://twitter.com/putchom) です。

新卒から約 9 年間勤めた [GMO ペパボ株式会社](https://pepabo.com/)を退職し、2022 年 9 月に[家計簿プリカ B/43](https://b43.jp/) を運営する[株式会社スマートバンク](https://smartbank.co.jp/)に入社しました。

入社して 1 ヶ月経ったので入社エントリというものを初めて書いてみます。

# これまでの私

2013 年に新卒で paperboy & co.(現 GMO ペパボ株式会社)に入社し、これまで[カラーミーショップ](https://shop-pro.jp/)、[minne](https://minne.com/)、[SUZURI](https://suzuri.jp/) と 3 つの EC のサービスに携わってきました。

ネットショップ作成サービス カラーミーショップでは主に有料デザインテンプレートの UI デザイン、カラーミーショップ大賞の VI などを担当しました。また、ハンドメイドマーケット minne では iOS、Android アプリの UI デザインを担当しました。

そして、オリジナルグッズ作成サービス SUZURI ではリードデザイナーとしてサービスの成長期にプロダクトデザインからコミュニケーションデザインまであらゆることを経験させていただきました。

![works](https://user-images.githubusercontent.com/945841/195979737-01b00adc-8bef-4784-8e0f-fb572e341ccd.jpg)
*SUZURI でやったお仕事*

さらにサービス以外にもシニアデザイナーとして、新卒説明会などのコーポレート関連の仕事や、[全社共通基盤デザインシステム「Inhouse」](https://design.pepabo.com/inhouse/)の構築もさせていただきました。

![works2](https://user-images.githubusercontent.com/945841/195979872-bea4075e-aad6-4866-aad0-b31bf7cd05c5.jpg)
*採用関連のお仕事*

最後に退職直前には 「[Config 2022](https://config.figma.com/events/figma-config-2022/home)」 という Figma が行っているカンファレンス登壇して、これまでペパボで行ってきたデザインシステム構築の知見を共有させていただきました。

はじめてのグローバルカンファレンス登壇ということもあり、とても貴重な経験をさせていただきました。

![config](https://user-images.githubusercontent.com/945841/195979915-01f1c2b1-fe81-4c55-a43e-0966ca8124b7.jpg)

- [Figma Config 2022 に登壇しました - Pepabo Tech Portal](https://tech.pepabo.com/2022/06/15/config2022/)

# なぜスマートバンクを選んだのか

## 1. そろそろ EC ではないことをしてみたかった

上記のとおり、これまで主に EC の領域でデザインをしてきたこともあり、今後さらにデザイナーとしての幅を広げるために、EC ではない領域の会社で働いてみたいと考えていました。

そこで、まずは転職活動するにあたって、自分の日常生活の問題意識を掘り下げて、「自分ごと化」できそうな会社をピックアップして話を聞きにいきました。

その結果、[趣味で組み込みの開発をやっているうち](https://suzuri.jp/putchom/journals/2021-10-20)に興味が出てきたハードウェアを扱う会社や、これまでズボラにやってきつつ「なんとかしなきゃな」と感じていたお金のことをもっと良くしている会社を中心に選考を受けることにしました。

実際にはこれまでのスキルセットが活かせることもあり、EC の会社もいくつか受けましたが、最終的には[家計簿プリカ B/43](https://b43.jp/)を運営している[株式会社スマートバンク](https://smartbank.co.jp/)を選びました。

![b43](https://user-images.githubusercontent.com/945841/195978263-fa940a19-b627-4de5-a623-77723d3a8f04.jpg)

- [B/43（ビー ヨンサン）｜家計簿アプリ Visa プリペイドカードでお金の管理を簡単に](https://b43.jp/)

> 「B/43（ビーヨンサン）」は、Visa プリペイドカードと家計簿アプリがセットになった新しい家計管理サービスです。毎月の決めた予算をプリペイドカードにチャージして支払いを行うだけで、アプリ上に利用明細が記録され、家計簿を自動作成します。

スマートバンクはこの B/43 というプロダクトにおいて『**お金を「使う」「貯める」「増やす」を誰もが当たり前にできる未来をつくる**』というミッションを掲げています。

実際にアプリをインストールして使ってみると、買い物するだけで家計簿がつくなど、**非常に優れた体験とインターフェースにより自分でも簡単にお金の管理を行うことができる**とわかりました。

また、選考中にファウンダーの話をお聞きする中で、自分のようなお金にズボラな人たちでも簡単に資産管理・資産形成できる未来を「**本気で作りたい**」ということが伝わってきました。

これらの点が自分の直近の問題意識と合致したので、「自分ごと化」してプロダクトを一緒に作っていけそうだと感じました。

## 2. 自分が持つスキルセットを持ったデザイナーがまだ在籍していなかった

以下の図を元に、オファー面談時に、「デザインシステム と 実装面を専門とするスキルセットを持ったデザイナーがちょうど足りていない。putchom さんが入るとこんな感じになって、今足りていないスキルセットのピースが埋まるので最高のチームになる」といった説明をしていただきました。

![after-member](https://user-images.githubusercontent.com/945841/195978748-648227c5-0fcc-4070-a9de-8d316d81c63b.jpg)
*スマートバンクのプロダクトデザインチーム*

- [スマートバンクのプロダクトデザインチームをご紹介します - inSmartBank](https://blog.smartbank.co.jp/entry/2022/06/13/095515)

この面談で、自分が入社した後にどういうアクションを求められているか明確に理解することができましたし、「**このチームで活躍できそうかもしれない**」と感じることができました。

（余談ですがオファー面談を担当した CXO の [takejune さん](https://twitter.com/takejune)は入社後に「**テトリスの長い棒が来たと感じた**」とおっしゃっていました。）

実際に入社してからこのプロダクトデザインチームで稼働しているのですが、様々な有名スタートアップの CI や BI を手掛ける OH の[わりえもんさん](https://wariemon.com/)や、元 Cookpad デザイン戦略部マネージャーで現在 KRAFTS&Co.を立ち上げられた[倉光さん](https://transitkix.com/)など、全員がプロフェッショナルなスキルを持って働いているヤバいチームです。

自分のスキルセット以外の面でも一線級で活躍しているメンバーが在籍しているので「いるだけで成長できる」環境だと感じています。（そもそも大半の社員がもともと日本で初めてのフリマアプリを作ったフリル（現 楽天ラクマ）の創業メンバーなのでビジネス的な観点でも学ぶことが多いです。）

また、特にスマートバンクの一番の魅力としてはスタートアップの初期フェーズにも関わらず、専任の UX リサーチャーである[はろかさん](https://twitter.com/mawarisuru)が在籍していることです。

- [ゼロからのスタートアップ立ち上げにおけるリサーチ事例 (Research Conference2022 書き起こし)](https://takejune.com/posts/research-conf)

入社してからほぼ毎日のように自分が担当する新機能に関するユーザーインタビューに同席しているのですが、リサーチに関する書籍を読んで頭の中でしか理解できていなかった手法を、現場で実際のケースに応じて学ぶことができ、目からウロコが落ちっぱなしです。

これまで口ではユーザーファーストなどと言いつつ、正直プロダクトづくりにおいて「多分こうだろう」という部分が多いままリリースすることが多々ありました。

今でも完全に「多分こうだろう」が払拭しきれたとは言いませんが、なるべく不確定要素が少ない状態で日々のデザイン業務が行えていると感じています。

## 3. 一緒に働くメンバーと考え方が合いそうだった

自分が入社する直前にスマートバンクでは以下の 3 つのバリューが策定されました。

> Think N1
>
> - 対話と分析を重ねて、本当に重要な課題を発見しよう
> - 大きな成功から逆算して、チャレンジを続けよう

> Super Ownership
>
> - 職域を飛び越えて、自らリードしよう
> - 互いをサポートし合い、チームで成し遂げよう

> Be Open
>
> - 想いや情報を自分から共有しよう
> - 他者を尊重し、信頼されるよう振る舞おう

- [【Make it Transparent】資金調達特設サイト | 株式会社スマートバンク](https://smartbank.co.jp/transparent)

上記のバリューは在籍するメンバーがワークショップを行い、現状を踏まえて作ったもので、現在のスマートバンクのメンバーの考え方がリアルに反映されています。

これらのバリューが自分が働く上で大事にしていることや強みとしていることと合致していたので、一緒に働くメンバーともうまくやっていけそうだと判断できました。

# 今やっていること

私が入社してから行っている業務は主に UI デザイン、デザインシステムの設計、Web フロントエンドまわりの実装です。

## UI デザイン

来年の大きなリリースに向けた新機能の開発プロジェクトにアサインされ、全体の体験設計や、インターフェースのデザイン業務を行っています。

前述したとおり、様々なプロフェッショナルなスキルを持ったメンバーと一緒にリサーチを行い、確度の高い仮説を立てて「人々が本当に欲しいもの」をつくれていると思います。

リリースをお楽しみに！

![new-feature](https://user-images.githubusercontent.com/945841/195979245-ee36b011-bdbf-4070-9b8f-1d3fe6e210cc.jpg)

## デザインシステムの設計

自分が一番得意とする領域や、求められていることはデザインシステムの設計であり、現状の課題をチームにヒアリングしつつ、まずは現状整理を行いました。

その現状整理をもとにスマートバンクにおける理想のデザインシステムのアウトラインを提示し、そこに向かって優先順位の高いデザイントークンの定義から実装を始めています。

![design-system-architecture](https://user-images.githubusercontent.com/945841/195979456-6fabb23f-5dea-48c9-bad8-a59556298d11.jpg)
*スマートバンクの理想のデザインシステムのアウトライン*

デザインシステムに関しては、モバイルアプリにおけるデザイントークンの効率的な運用や、マルチサブブランド対応のデザインシステムについての知見が溜まっていきそうな気配がしているので、今後も引き続きアウトプットしてきたいと思います。

## Web フロントエンドの実装

B/43 は iOS、Android などのスマートフォンアプリのみで提供しているため、現在 Web アプリケーションは存在していません。

しかし、[サービスサイト](https://b43.jp/)では [Nuxt.js](https://nuxtjs.org/ja/) などのフレームワークが使われており、[ユーザーインタビューページ](https://b43.jp/interview/)の更新など、サービスのプロモーションを行う業務が定常的に発生します。

これらのコンテンツを作成する業務や、その業務自体を効率化するアクションを行っています。

具体的には Web コンポーネントを再利用可能な形に再構成したり、コンテンツの雛形を自動生成できる仕組みを整えたりしています。

# 一緒に働くコミュニケーションデザイナーを募集しています

現在スマートバンクでは今後のデザイン業務を進める上で、スキルセットでもう一つ足りないピースが見えてきています。

それは一緒にブランドを作っていってくれる**専任のコミュニケーションデザイナー**です。

上記のようにスマートバンクのデザインシステムのアウトラインを引き、プロダクトデザインを通じてブランドをつくることに関しては私が進めていますが、今のメンバーだけではコミュケーションデザイン領域まで手が回りそうもありません。

そこで、一緒にコミュニケーションデザイン領域で B/43 のブランドづくりを進めてくれる方を募集しています。

![recruting](https://user-images.githubusercontent.com/945841/195980635-fff25821-89d3-495b-8384-6e34de052dbb.jpg)

- [コミュニケーションデザイナー - 株式会社スマートバンク | SmartBank, Inc.](https://smartbank.co.jp/163ba6c98b01465a9ded6b3ebe8088b9)

会社のフェーズとしてもこれからという感じなので、正直まだ何も決まっていません。

「自分でリーダーシップを持ってブランドを作っていきたい！」という方の募集をぜひお待ちしています。


株式会社スマートバンクに入社しました

2021年に個人的に作ったものを年末でクソ忙しいのでクソ雑に箇条書きでまとめます。キャプチャ画像もクソ雑です。

## Three.jsでゲーム的ななにか

- 今年はじめにつくった[初詣オンライン](https://hatsumoude.online/)で使ったA-FrameはThree.jsをHTMLみたいに簡易的に使えるラッパーだったので、Three.js そのものをいじることに興味が出た。
- Blender のモデリングも SUZURI デザイナーの間で盛り上がってきた。
- Blender でつくったものを配置してゲームでも作ってみるかと思って作ってみた。
- 電車とか街とかつくった。
  - ![ExkmNsOU4AIo-Xo](https://media.git.pepabo.com/user/140/files/5c884800-cf84-11eb-94af-494774c67daf)
  - ![EyI7T9xUcAUjXuJ](https://media.git.pepabo.com/user/140/files/6447ec80-cf84-11eb-835d-5cd3a7fcb633)
- コントローラーに合わせてキャラクターを動かして、作った街を探検できるようにした。
  - ![](https://user-images.githubusercontent.com/945841/146636213-2df378eb-047a-4c41-a541-cf69707a0601.png)
  - ![](https://user-images.githubusercontent.com/945841/146636218-f6be5cf9-5adf-4cf7-96cb-9961f8305856.png)
- オブジェクト置きすぎてブラウザが死んだので作るのをやめてしまった。気が向いたらまた再開するかも。メタバースとかいうやつが盛り上がってきたしもうやめるかも。

## RustのWASMで動くSUZURI

![RustのWASMで動くSUZURI](https://user-images.githubusercontent.com/945841/146635866-145d4452-f65c-462c-8b5a-ec84f15a6485.png)

- https://github.com/putchom/yew-suzuri
- Rust の WebAssembly で動く SUZURI。
- SUZURIの画像合成サーバーでも一部Rustが使われててたのでどんなもんか興味があった。
- WebAssemblyはなんとなく聞いたことあるレベルだったのだけど、実際どんなもんなのか知りたかった。
- https://suzuri-5f36a.firebaseapp.com/ で見れる。
- Rustacean になって 40 年くいっぱぐれなくなりたい。
  - Ref: https://www.youtube.com/watch?v=A3AdN7U24iU

## Placeholder画像が指定したサイズで返ってくるサーバー

- https://github.com/putchom/placeaoiygw
- URLでサイズを指定するとそのサイズの矢川葵さんの画像が返ってくる。
- 推しアイドルグループ「Maison book girl」が[削除](https://www.maisonbookgirl.com/)されて泣きながら作った。
- Rubyで書いた。
- [PlaceCage](https://www.placecage.com/) からインスパイアされた。
- [ImageMagick](https://imagemagick.org/index.php)の素振り。

## Placeholder画像を挿入できるFigmaプラグイン

![Placeholder画像を挿入できるFigmaプラグイン](https://user-images.githubusercontent.com/945841/146635943-cfbc8880-8171-4215-889b-feaa1d28fed5.png)

- [仕事でFigmaプラグインを作る必要があった](https://suzuri.jp/putchom/journals/2021-12-08)ので素振り。
- 上のアイデアをFigmaプラグインにも応用した。
- https://github.com/putchom/aoiygw

## Rustでポケット○カチュウ

![Rustでポケット○カチュウ](https://user-images.githubusercontent.com/945841/146635990-54f77f4b-753c-4987-aa3f-be4b40b730b9.png)

- RustでWASMやったあとに、同僚に「組み込みRust」をおすすめされて始めた。
  - ![](https://user-images.githubusercontent.com/945841/146636156-2da0e0e2-2987-41c5-b4c5-3375794c8535.png)
- 一通り組み込みRustの本の内容やったら「ポケット○カチュウ」が作れる気がしてきたので作った。
- 今も大体毎週末やってる。

-----

2022年もいろいろ作るぞ。

この記事はSUZURI Advent Calendar 2021の記事でした。

- [SUZURI Advent Calendar 2021 - Adventar](https://adventar.org/calendars/6358)

2021年に個人的につくったものを雑に振り返る

[SUZURI](https://suzuri.jp/)というサービスでデザイナーをやっている putchom（[@putchom](https://twitter.com/putchom)）です。


GMOペパボ株式会社の共通基盤デザインシステムである[Inhouse](https://design.pepabo.com/inhouse/about/)の開発に携わり始めて1年くらい経ち、現在は開発をリードするまでになったので、どのような経緯でInhouseのプロジェクトに参加し、今リードとしてどんなことをやっているのかを紹介します。

そのために、まずInhouseとは何かを説明します。

# Inhouseとは

Inhouseとは、GMOペパボ株式会社の共通基盤デザインシステムです。

![Inhouseとは](https://design.pepabo.com/images/contents/inhouse/about/inhouse_fig_a.png)

デザインシステムとは、ブランドがタッチポイントを活用した体験設計を効率的におこなうために、あらかじめ原則やガイドラインを定めて、その実装としてカラーパレットやコンポーネントライブラリなどのアセットを用意したものです。その上で、各サービスが個別に考えていているような、原則やガイドライン、実装していたアセットのうち、重複しているものをすべてのサービスで使えるように一般化して、あらかじめ用意しておいたものが共通基盤デザインシステムです。ペパボでは、この共通基盤デザインシステムに、「Inhouse」という名前をつけて呼んでいます。

ペパボでは複数のサービスを運営していることから、Inhouseは複数のブランドで使用することを前提とする必要があります。そこで、わたしたちは「Flavor」という仕組みを採用しています。色や形など、ブランドによって上書き可能なデザイントークンをFlavorと呼んでいる変数にまとめておくことで、Flavorを差し替えることでブランドイメージを崩さないデザインができるようになります。

![Flavorの仕組み](https://design.pepabo.com/images/contents/inhouse/about/inhouse_fig_c.png)

さらに詳しく知りたい方は [Inhouseとは - Pepabo Design](https://design.pepabo.com/inhouse/about/)をご覧ください。


# 参加からプロジェクトをリードするまで

私はここ数年、SUZURIのデザインシステム及びコンポーネントライブラリである、[Nachiguro](https://github.com/pepabo/nachiguro)の開発を行ってきました。

Nachiguroについては昨年こちらの記事にまとめています。

- [「 SUZURIのデザインシステム「Nachiguro」について 」というジャーナル ∞ SUZURI（スズリ）](https://suzuri.jp/putchom/journals/2020-12-05)

その傍ら、デザイン部から上記のコンセプト、共通基盤デザインシステム「Inhouse」の開発が発表され、社内の各サービスのデザインシステムの開発リソースをできるだけ一元的に集約して、効率化及びブラッシュアップしていくことが示されました。

そこで、社内でいち早くNachiguroにおいて、Figmaのコンポーネントライブラリの設計を行っていた私はその知見を生かすことができると考え、InhouseのFigmaコンポーネントライブラリ作成に取りかかりました。

またNachiguroで、Reactコンポーネントの開発や、Flutterでのモバイルアプリのコンポーネント開発を行っていたため、InhouseのWebフロントエンドの開発にも積極的に参加していきました。

その結果、気づけばプロジェクトそのものをリードすることになり、現在に至ります。

# リードすることになってから感じた課題

Inhouseは上記コンセプトのとおり、あらゆるサービスに使われることが重要です。その点でまず私がこのInhouseプロジェクトのリードを任されてから感じた課題は2つです。

1. 実際のサービスのメンバーの積極的な参加を促せていない
2. 開発スピードが遅い

Inhouseを使うサービス側の当事者意識が低いとメンテナンスもされにくいですし、やらされている感が強くなってしまいます。また、開発スピードが遅いと、いつまでも実装されず、各サービスが各々デザインシステムを構築しなければいけません。

上記2つの課題のボトルネックになっているのは**ガイドライン策定や開発をInhouseのコアメンバーのみで行っていたこと**と、**明確なロードマップが示されていなかったこと**でした。

そこで、Inhouseプロジェクトチームでは今年、以下の目標を立て、具体的なアクションを行いました。

- バックログにあるガイドラインのステータスがすべて「確定」になっている
- ガイドラインのうち66%のWebコンポーネントライブラリが実装されている
- 主要なサービスのソースコードにWebコンポーネントライブラリがインストールされている

# 具体的なアクション

上記の目標をもとに行った具体的なアクションは以下の通りです。

## 1. 参加しやすい仕組みをつくる

これまで、きちんと外部に公開できるようなガイドラインの決定をコアメンバーが週一回の定例で草案を持ってきて決めていました。

しかし、これでは参加のハードルが高いため、精緻化していなくてもよい、ある程度**ゆるめの**ガイドラインの作成を当面の目標としました。

まず、各サービスからクリティカルパス（申し込みや購入などで辿る経路）に必要不可欠な機能要件やコンポーネントをヒアリングしました。

そこから、バックログを作成して、特に声が多かったものから順番に優先順位づけを行い、下期中に作成するガイドラインリストアップしました。

![リストアップされたガイドラインのバックログ](https://user-images.githubusercontent.com/945841/145670840-999213b4-0eaf-408b-9066-d6b79b6571ce.png)
*リストアップされたガイドラインのバックログ*

　

このバックログが上記の、

> バックログにあるガイドラインのステータスがすべて「確定」になっている

のバックログです。

さらに、Notion上にガイドラインのデータベース及びテンプレートを作成しました。これにより、ガイドラインの書きやすさが向上し、現在のステータスと担当者を可視化することができました。

![ステータスと現在の担当者を可視化した様子](https://user-images.githubusercontent.com/945841/145670844-c920b666-83b8-4b48-8ba3-47033fa58a19.png)
*ステータスと現在の担当者を可視化したガイドライン*

　

![ガイドラインのテンプレート](https://user-images.githubusercontent.com/945841/145670847-a6803bb3-7384-4101-b8c1-eed81d0b31ac.png)
*ガイドラインのテンプレート*

　

そして、各サービスの施策が行われる際に、上記でリストアップしたガイドラインの執筆に関係しそうな機能やコンポーネントの設計をデザイナーが行っているのを観測したらすかさず声をかけて担当者としてアサインしていきました。

担当デザイナーが作成したガイドラインの草案を元に、レビュー会でCDOやシニアデザイナーを中心としたInhouseコアメンバーでレビューしています。

このレビュー会では上記の通り、ある程度ゆるくやることを大事にし、仕様や名前付けなどの根幹に関するレビューは行うものの、ガイドラインの文章そのものに関するレビューは行いません。

その結果、シニアデザイナーだけではなく、**ジュニアデザイナーを含むより多くのメンバーがInhouseプロジェクトに参加することができました**。作業を分担でき、スピードが出ただけではなく、ジュニアデザイナーのデザインシステムに対する解像度が上がり、デザイナー全体の成長も促せたのではないかと考えています。

また、ゆるめでもいいのでスピード感を持ってガイドラインが整備された結果どうなったかというと、名前付けや仕様が細かく記されているため**実装コストが著しく下がりました**。

これは

> 上記ガイドラインのうち66%のWebコンポーネントが実装されている

の目標達成にも寄与しています。

## 2. サービスに導入しやすくする

> 主要なサービスのソースコードにWebコンポーネントライブラリがインストールされている

を目標に据えたものの、実際にインストールするには10年続くようなレガシーなサービスも多く、開発環境上の問題が立ちはだかりました。

デザイン部に所属するエンジニアがその問題を解決すべく動いていますが、全サービスにインストールするには当然時間がかかります。

また、ガイドライン上は存在するものの、Inhouse側の実装が追いついていないコンポーネントはそもそもライブラリに存在しないのでインストールすることができません。

そこで、「**Inhouseのコンポーネントライブラリがインストールされていなければ、Inhouseを使うことはできない**」という思い込みを捨てることにしました。

実際に何を行ったかというと、社内のデザイナー全員が集まるイベントで、上記で定義したゆるめのガイドラインを示して「Inhouseのガイドラインを使って、コンポーネントを**サービス側で**どんどん実装して行きましょう」と提案しました。

![社内イベントの様子](https://user-images.githubusercontent.com/945841/145671068-b23b74fa-fdbc-4a4c-b023-a04324a11f2a.png)

サービス側で実装したものがうまくワークして安定すれば、それを将来的にInhouseにバックポートできます。そうすれば他のサービスがそのコンポーネントの実装の恩恵に預かることができて大変お得です。

また、共通のガイドラインをもとにして実装すればインターフェースが揃うためサービス側の開発環境が新しくなってInhouse側からインストールすることになっても、マークアップの変更などのコストも最小限で済みます。

さらに、上記は主にWebコンポーネントの話でしたが、Figmaでプロトタイプを作るためのコンポーネントライブラリの各サービスの整備コストが高く導入しづらいという側面もありました。

そこで、Inhouseのプロジェクトで一元管理されているFigmaのコンポーネントライブラリを複製し、Local Styleを各サービスが用意した設定ファイルを用いて差し替えればそのサービスのコンポーネントライブラリをすぐに作成できるFigmaプラグインを開発しました。

![開発したFigmaプラグイン](https://dzdih2euft5nz.cloudfront.net/journals/covers/15368?1638944647)


# 今後やっていきたいこと

## 1. Webコンポーネントライブラリの開発者を増やす

現在上記の施策によりガイドライン執筆者は増えましたが、実装を行うメンバーは依然として限られているため、より開発者を増やしていきたいです。そのために実装のガイドラインやAPIドキュメントの拡充を進めていきたいと考えています。

## 2. Pepabo Design のアップデート

ペパボには[大切にしている3つのこと](https://recruit.pepabo.com/info/important/)の1つとして、「アウトプットすること」があります。そして、ペパボのデザインに関する取り組みをアウトプットする、[Pepabo Design](http://design.pepabo.com/)というサイトがあります。ゆるいガイドライン施策で執筆の敷居は下がったものの、精緻化できておらず、まだ外部にはこの知見を共有できていない状態です。早く外向きに公開できる状態にし、より多くのデザイナーのみなさんとこのPepabo Designのトピックを通してデザインシステムに関する意見交換をしたいと考えています。

## 3. モバイルアプリへの対応

現在Inhouseの開発はWebのコンポーネントを中心に進めていますが、ペパボではもちろんモバイルアプリも各サービスで開発しています。モバイルアプリでInhouseの各種Flavorを扱いやすいような何かをモバイルアプリのエンジニアと協力して考えています。


共通基盤デザインシステムInhouseの開発でやっていること

Ryo Fukushima

「3.1 Metallic / enosima」のアルバムアートワークを作成しました。

3.1 Metallic

SUZURIというサービスが成長して事業部化することが決まり、チームメンバーが増えてきました。しかしそれと同時に、「これってSUZURIっぽいよね」と言われているものが個々人の間でズレていることも増えてきました。  さらに、ユーザーとのコミュニケーションのタッチポイントもチームメンバーの増加と同時に増加しているものの、チームメンバーそれぞれの「SUZURIっぽい」で解釈しているため違和感が生じてきました。  そのため、私は「SUZURIっぽい」を言語化してブランドを明らかにしていくことにしました。

SUZURIのブランディング

自分のTumblrアカウントでリブログしたGIFアニメーションを使ってVJができるデスクトップアプリケーションを開発しました。

VJ Tumblr

SUZURIのアイテムプロモーション特設サイトのビジュアルデザインを行いました。

平成最後の夏、  あの娘と過ごすSUZURIの夏。

夢を忘れないように記録できるアプリ、「Yume」をiOS、Android向けに開発しました。

Yume

100人を超えるクリエイターの「夏」Tシャツを集めた特設サイトのUIデザイン及びフロントエンド開発を行いました。

100TEE

SUZURIで提供するコーチジャケットのプロモーションを行う特設サイトを作成しました。

Coach Jacket

OTARIBA Games.というサークルで「五〇度の真夏が巡る」という同人ゲームを作成しました。私はUIデザイン、動画、冊子の装丁やブースの装飾、ゲームの開発を担当しました。

五〇度の真夏が巡る

ほげちゃんのグッズを作成しました。

ほげちゃんグッズ

デザインシステムはブランドを実装するための一つの手段です。ブランドにはその世界観にフィットした体験があり、それをユーザーや将来的な顧客と共有することがブランディングです。そのデザインシステム中でも機能パターンを担うのがコンポーネントライブラリです。「Inhouse Components」はGMOペパボ株式会社の共通基盤デザインシステム「Inhouse」のコンポーネントライブラリでありGMOペパボのすべてのアプリケーションの共通化可能な機能パターンを構築します。

Inhouse Components

SUZURIではじめて提供するインテリア・アートアイテムであるポスターとアクリルブロックのプロモーションを行う特設サイトを作成しました。

Poster & Acrylic Block

SUZURI事業部に新しい人が増えたり、リモートワーク中心の働き方により、UIや広告などで使う用語の使い方に乱れが生じていました。サービスのブランド価値を最大化するためには、時間的・空間的に広がっていくあらゆるタッチポイントにおいて、一貫した意味や体験を提供し続けなくてはなりません。そのためにもサービスを提供する側が一貫性のある言葉を使う必要があります。私はこのような課題を解決するために、社内のNotion上に「SUZURIの用語集」というページを作成し、ユビキタス言語を運用することにしました。

SUZURIの用語集

タピオカミルクティーを顔に装着できるInstagramのフィルターを作成しました。

Bubble Tea

放課後作字クラブというプロジェクトで今まで作成した文字をアーカイブしています。

putchom

Works

3.1 Metallic

SUZURIのブランディング

VJ Tumblr

平成最後の夏、あの娘と過ごすSUZURIの夏。

Yume

100TEE

Coach Jacket

五〇度の真夏が巡る

ほげちゃんグッズ

Inhouse Components

Poster & Acrylic Block

SUZURIの用語集

Posts

Schema by Figma 2022の備忘録

株式会社スマートバンクに入社しました

2021年に個人的につくったものを雑に振り返る

共通基盤デザインシステムInhouseの開発でやっていること

3.1 Metallic

SUZURIのブランディング

VJ Tumblr

平成最後の夏、 あの娘と過ごすSUZURIの夏。

Yume

100TEE

Coach Jacket

五〇度の真夏が巡る

ほげちゃんグッズ

Inhouse Components

Poster & Acrylic Block

SUZURIの用語集

Schema by Figma 2022の備忘録

株式会社スマートバンクに入社しました

2021年に個人的につくったものを雑に振り返る

共通基盤デザインシステムInhouseの開発でやっていること

平成最後の夏、あの娘と過ごすSUZURIの夏。