こちらは [CSS Advent Calendar 2022](https://qiita.com/advent-calendar/2022/cascading_style_sheets) 22 日目の記事です。

----

こんにちは、[家計簿プリカ B/43](https://b43.jp/)を運営する[株式会社スマートバンク](https://smartbank.co.jp/)でデザイナーをしている putchom です。

CSS Advent Calendar ではありますが、今回は **Sass** のテストコードを書くと便利という話をします。

普段私はデザインシステムを設計する仕事をしています。

家計簿プリカ B/43 は iOS・Android アプリでプロダクトを提供していますが、サービスをプロモーションするページ（ https://b43.jp/ ）の Web アプリケーション向けには、ブランドを反映したコンポーネントライブラリを用意する必要があり、そのためにわりと複雑な Sass の関数を書くことがあります。

そのような場合、より正確なロジックを組み立てたり、何か実装に変更があった場合にバグを検知したくなります。

そんなときに便利なパッケージが [assert-sass](https://github.com/gyugyu/assert-sass) 及び [sassunit](https://github.com/gyugyu/sassunit) です。

assert-sass は Dart Sass 向けの値の一致などを検証してくれるアサーション関数のライブラリ、sassunit は Dart Sass 向けの単体テストフレームワークです。

# 基本的な使い方

公式の [README](https://github.com/gyugyu/sassunit/blob/master/README.md) にあるとおりです。

例えば以下ような 2 つの数を足し合わせて返す Sass の関数があったとします。

```scss
// _functions.scss

@function sum($a, $b) {
  @return $a + $b;
}
```

assert-sass を使うと以下のような 2 + 3 は 5 になるべきという旨のテストコードを書いてこの関数の正しさを検証することができます。

```scss
// _functions.test.scss

@use "functions";
@use "@gyugyu/assert-sass" as assert;

@function test-sum() {
  @return assert.equals(functions.sum(2, 3), 5);
}
```

`assert.equals($expected, $actual)` は `$expected` に渡した値と `$actual` に渡した値が一致する場合にテストが成功します。

`npx sassunit` を叩くと、テストを実行することができます。

```bash
$ npx sassunit

> sass-test@1.0.0 test
> sassunit

.
passed: 1
failed: 0
```

`passed: 1` となっているのでテストが成功しています。

今度はわざと失敗するように、 2 + 3 の計算結果が 10 になるべきといった旨のテストコードに変更してみます。

```scss
// _functions.test.scss

@use "functions";
@use "@gyugyu/assert-sass" as assert;

@function test-sum() {
  @return assert.equals(functions.sum(2, 3), 10);
}
```

`npx sassunit` を実行するとこのようになるはずです。

```bash
$ npx sassunit

> sass-test@1.0.0 test
> sassunit

x
passed: 0
failed: 1
src/example/_functions.test.scss:
": assert-equal failed. expected: 5 actual: 10"
  ╷
5 │     @return assert.equals(
  │ ┌───────────^
6 │ │     functions.sum($a: 2, $b: 3),
7 │ │     10
8 │ │   );
  │ └───^
  ╵
  src/example/_functions.test.scss 5:11  test-sum()
  stdin 12:14                           root stylesheet
```

`: assert-equal failed. expected: 5 actual: 10` とあるので、本当は 5 にならなければならないが、10 にしたことによってテストが失敗していることがわかります。

普段からテストコードを書いている方にはお馴染みだと思いますし、これが Sass でできることにもメリットが感じられるかもしれません。

しかし、「わりと Sass は書いていて、『テストコード』という名前は聞いたことあるけど、 いまいちテストコードを書くメリットがわからないな...」という方のために、どのように Sass でテストコードを書いていくのか、どのようなメリットがあるのか具体例を交えてご紹介します。

# どのように書いていくのか？

今回は Sass で Hex color であるか否かを判定する関数を用意したいとします。

Hex color とはお馴染みの `#a9d3dc` みたいな 16 進数で表現されたカラーコードです。

まず Hex color は先頭の文字が `#` になるはずなのでそれをテストするコードを書きます。

```scss
// _functions.test.scss

@function test-is-hex-color() {
  // 先頭が # なら Hex color である
  @return assert.equals(functions.is-hex-color("#a9d3dc"), true);
}

@function test-is-not-hex-color() {
  // 先頭が # でないなら Hex color ではない
  @return assert.equals(functions.is-hex-color("a9d3dc"), false);
}
```

そして実際に関数を書いていきます。

まずは、どんな値を渡しても true を返す関数を用意します。

```scss
// _functions.scss
@function is-hex-color($value) {
  @return true;
}
```

絶対に true を返すので、false が返ってくることを予期している `test-is-not-hex-color()` のテストは失敗します。

```bash
$ npx sassunit

.x
passed: 1
failed: 1
src/example/_functions.test.scss:
": assert-equal failed. expected: true actual: false"
   ╷
14 │     @return assert.equals(
   │ ┌───────────^
15 │ │     functions.is-hex-color('a9d3dc'),
16 │ │     false
17 │ │   );
   │ └───^
   ╵
  src/example/_functions.test.scss 14:11  test-is-not-hex-color()
  stdin 12:14                             root stylesheet
```

失敗してはいますが、現時点ではこれは失敗するのが正しく、このテストが成功するようになれば要件を満たすような関数になっていると言えそうです。

なので、実際にテストが成功するように関数を修正していきます。

```scss
// _functions.scss

@use "sass:string";

@function is-hex-color($value) {
  @if string.slice("#{$value}", 1, 1) != "#" {
    @return false;
  }

  @return true;
}
```

sass:string の slice 関数を使うと、文字列の一部を取り出すことができます。

- [参考: Sass: sass:string](https://sass-lang.com/documentation/modules/string#slice)

1 文字目を取り出し、`#` に合致しない場合は false、合致する場合は true を返すように関数を修正しました。

無事にすべてのテストが成功し、先頭の `#` の有無によって Hex color かどうか判定できるようになりました。

```bash
$ npx sassunit

..
passed: 2
failed: 0
```

しかし、「先頭が `#` であること」のみでは正確に検証できているとは言えません。

`#a9d3dc00000000000` のように桁数がべらぼうに多い場合も Hex color ではないと判定されてほしいです。

これを検証するテストコードを書いてみます。

```scss
// _functions.test.scss

@function test-is-not-hex-color-when-too-many-digits() {
  // 桁数がべらぼうに多い場合は Hex color ではない
  @return assert.equals(functions.is-hex-color("#a9d3dc00000000000000"), false);
}
```

しかし、このテストは `is-hex-color()` 関数から true が返ってきて（#a9d3dc00000000000000 は Hex color であると判定されて）失敗してしまいます。

```bash
$ npx sassunit

..x
passed: 2
failed: 1
src/example/_functions.test.scss:
": assert-equal failed. expected: true actual: false"
   ╷
19 │     @return assert.equals(
   │ ┌───────────^
20 │ │     functions.is-hex-color('#a9d3dc00000000000000'),
21 │ │     false
22 │ │   );
   │ └───^
   ╵
  src/example/_functions.test.scss 19:11  test-is-not-hex-color()
  stdin 12:14                             root stylesheet
```

この関数はまだ Hex color を上手に判定できていなそうなので、規定の桁数ではない場合は false を返すように関数を修正します。

```scss
// _functions.scss

@function is-hex-color($value) {
  $length: string.length("#{$value}");

  // 先頭の文字列が # かどうかチェックする
  @if string.slice("#{$value}", 1, 1) != "#" {
    @return false;
  }

  // 文字数が # を含めて正しい桁数になっているかをチェックする
  @if $length != 4 and $length != 7 and $length != 9 {
    @return false;
  }

  @return true;
}
```

sass:string の `length($string)` を用いると `$string` の文字数をカウントできます。

- [参考: Sass: sass:string](https://sass-lang.com/documentation/modules/string#length)

今回 Hex color は `#000` のような three-value syntax、 `#000000` のような six-value syntax、または透過を含めた `#000000000` のような eight-value syntax の場合を考慮することにし、それぞれに `#` を含めた桁数に `$length` が一致しなかった場合は false を返すようにしました。

```bash
$ npx sassunit

...
passed: 3
failed: 0
```

これで、テストが無事成功するようになりました。

ちなみに桁数が少ない場合もテストしてみます。

```scss
// _functions.test.scss

@function test-is-not-hex-color-when-few-digits() {
  // 桁数が少ない場合は Hex color ではない
  @return assert.equals(functions.is-hex-color("#a9"), false);
}
```

```bash
$ npx sassunit

....
passed: 4
failed: 0
```

これも無事にテストが成功しました。

これで桁数の問題はクリアできていそうです。しかし、まだこの関数には問題があります。

Hex color で有効な文字列ではない文字列を渡した場合にも Hex color ではないと判断されてほしいです。

`#ああああああ` という日本語のかなを含む文字列を渡して、Hex color ではないことを検証してみます。

```scss
// _functions.test.scss

@function test-is-not-hex-color-when-japanese-chars() {
  // Hex colorとして有効な文字でないものが含まれる場合はHex colorではない
  @return assert.equals(functions.is-hex-color("#ああああああ"), false);
}
```

このテストは `is-hex-color()` 関数から true が返ってきて（#ああああああは Hex color であると判定されて）失敗してしまいました。

```bash
$ npx sassunit

...x
passed: 3
failed: 1
src/example/_functions.test.scss:
": assert-equal failed. expected: true actual: false"
   ╷
26 │     @return assert.equals(
   │ ┌───────────^
27 │ │     functions.is-hex-color('#ああああああ'),
28 │ │     false
29 │ │   );
   │ └───^
   ╵
  src/example/_functions.test.scss 26:11  test-is-not-hex-color-when-japanese-chars()
  stdin 12:14                             root stylesheet
```

そこで、渡した文字列が Hex color で扱える文字に合致する場合のみ Hex color であると判定されるように関数を修正します。

```scss
// _functions.scss

@use "sass:string";
@use "sass:list";

@function is-hex-color($value) {
  $length: string.length("#{$value}");
  $available-hex-chars: "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "a",
    "b", "c", "d", "e", "f", "A", "B", "C", "D", "E", "F";

  // 先頭の文字列が # かどうかチェックする
  @if string.slice("#{$value}", 1, 1) != "#" {
    @return false;
  }

  // 文字数が # を含めて正しい桁数になっているかをチェックする
  @if $length != 4 and $length != 7 and $length != 9 {
    @return false;
  }

  // Hex color で利用できる文字で構成されているかチェックする
  @for $i from 2 through $length {
    $char: string.slice("#{$value}", $i, $i);

    @if list.index($available-hex-chars, $char) == null {
      @return false;
    }
  }

  @return true;
}
```

渡した値の 2 文字目（ # 以降）から文字数分の文字を取り出し、Hex color で扱える文字に合致するか検証していきます。

ちなみに Hex color で扱える文字は数字の 0〜9、英字の a〜f、A〜F です。

sass:list の `list.index($list, $value)` を使うと `$list` に渡した配列内に `$value` で渡した値が存在すればその値の位置の番号を取得できます。しかし、配列内に合致する値が存在しない場合は null を返します。

- [参考: Sass: Lists](https://sass-lang.com/documentation/values/lists#find-an-element-in-a-list)

そのため、 `$available-hex-chars` の配列に対して値から取り出した文字列を照合していき、番号ではなく null が返ってきた場合は Hex color で扱える文字ではないと判定できます。

もう一度テストを実行してみます。

```bash
$ npx sassunit

.....
passed: 5
failed: 0
```

無事すべてのテストが成功しました 🎉

このように「この場合は正しく動かないかもしれない」という予想をもとに用意した値を渡してテストコードを書き、そのあとにそのテストが成功するように関数を組み立てるといったサイクルを回していくことで、より強度が高い関数を書いていくことができます。

これは人間が手動でチェックするよりも実装の漏れを防ぐことができ、たとえ今後関数の実装が変更されたときも、再度テストを実行することで、壊れたりしていないかを自動でチェックすることができます。

# まとめ

今回は `assert.equals($expected, $actual)` のみ紹介しましたが、assert-sass には他にも null ではないことをチェックする `assert.not-null($value)` や、配列で指定した key が指定した map の key にすべて含まれているかどうかチェックする `assert.contains-all-keys($map, $keys)` などが用意されているので、うまく組み合わせてテストコードを書いていくと便利です。

今回書いたコードは以下の GitHub リポジトリで公開していますのでご参考まで。

- https://github.com/putchom/sass-test

# さいごに

私が働く家計簿プリカ B/43 を運営する株式会社スマートバンクでは各方面で積極採用活動中です。

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

特にデザイナーの中では現在はコミュニケーションデザイン領域のデザイナーを募集中です。

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

選考とは別に、「気になるけど選考に進むか悩んでいる」という方向けに会社の雰囲気や気になる職種の業務内容をお話しする「カジュアル面談」も用意しているので、ぜひお気軽にご連絡ください。

- [カジュアル面談への応募 - 株式会社スマートバンク | SmartBank, Inc.](https://smartbank.co.jp/de1f8d3093a64bcd99e2487352cf5f56)


Sass のテストコードを書くと便利

こちらは [Figma 開発 Advent Calendar 2022](https://qiita.com/advent-calendar/2022/figma-development) 14 日目の記事です。

---

こんにちは、[家計簿プリカ B/43](https://b43.jp/)を運営する[株式会社スマートバンク](https://smartbank.co.jp/)のデザイナーであり、自称オンラインお年賀デザイナーの [putchom](https://twitter.com/putchom) です。

これまでに、年末年始に[初詣オンライン](https://hatsumoude.online/)や[餅つきオンライン](https://mochituki.online/)といったお年賀ネタサービスを作ってきました。

ところで皆さん年賀状作ってますか？

私はめんどくさいのでもうかれこれ 10 年以上は自分の年賀状を作っていません。

しかしデザイナーなら誰しも年末年始帰省した際にこのような経験があるかもしれません...

母「あんたデザイナーでしょ。ちょっと年賀状作ってよ。」

私「もう 31 日なんだが...？」

年賀状作成専門の使い慣れないソフトを渡され、見慣れない UI を駆使しながら宛名印刷をして年を越したくはありません。

そこで使い慣れたデザインツール Figma のプラグインを自作して年賀状の宛名面のデータを作成してみたいと思います。

# 完成品

こういうものを作ります。

![完成品](https://user-images.githubusercontent.com/945841/207402494-bcadcc8e-b9ca-4301-b253-dcdeea766188.gif)

Figma コミュニティに公開するには明らかな機能不足なので、とりあえず GitHub に公開しました。

https://github.com/putchom/atena-figma-plugin

# つくりかた

## 1. セットアップ

今回は 「Figma デザイン」のみで実行できるもので良さそうで、スターターキットの「UI とブラウザ API を使用」を選択して作成します。

![](https://user-images.githubusercontent.com/945841/205423971-372eb863-11a7-4ff9-b0e8-caaf7d9515b4.png)
![](https://user-images.githubusercontent.com/945841/205423978-6b2a7c2f-55c1-437d-a5e0-88150544be89.png)

Figma プラグインの詳しい作り始め方は他に以下のような良質な記事があるので端折ります。

- [Figma プラグインの作り方 - Zenn](https://zenn.dev/ixkaito/articles/how-to-make-a-figma-plugin)

## 2. 年賀はがきサイズの Frame を作成する

サンプルのプラグインを実行するとオレンジの Rectangle を指定した数作成するプラグインが立ち上がります。

![オレンジの Rectangle を指定した数作成するプラグイン](https://user-images.githubusercontent.com/945841/207388323-ad4cefae-b122-4cda-aa11-687bfc85503a.png)

まずはこれを改造して「指定した数の年賀はがきサイズの Frame を作成する」ようにします。

```html

<h2>年賀はがき宛名ジェネレーター</h2>
<p>Count: <input id="count" value="5" /></p>
<button id="create">作成</button>
<script>
  document.getElementById("create").onclick = () => {
    const textbox = document.getElementById("count");
    const count = parseInt(textbox.value, 10);
    parent.postMessage({ pluginMessage: { type: "create", count } }, "*");
  };
</script>
```

```ts
// code.ts
figma.showUI(__html__);

figma.ui.onmessage = (msg) => {
  if (msg.type === "create") {
    const nodes: SceneNode[] = [];
    for (let i = 0; i < msg.count; i++) {
      const frameWidth = 1181;
      const frameHeight = 1148;
      const frame = figma.createFrame();

      // 20pxずつ間隔を開けて配置する
      frame.x = i * (frameWidth + 20);

      // Frameを年賀はがきのサイズにリサイズする
      frame.resize(frameWidth, frameHeight);

      figma.currentPage.appendChild(frame);
      nodes.push(frame);
    }
  }
};
```

Rectangle を作成する `createRectangle` 関数を `createFrame` 関数に置き換えると、Frame を指定した数分作成できるようになります。

- [参考: createFrame | Plugin API](https://www.figma.com/plugin-docs/api/properties/figma-createframe)

また、`frame.resize(width, height)` で年賀はがきのサイズにリサイズします。

※ 年賀はがきが 10cm x 14.8cm なので 300dpi で px に変換して 1181px x 1748px にしました。

ひとまず、作成ボタンを押したら、年賀はがきサイズの Frame が指定した数並ぶようになりました。

![](https://user-images.githubusercontent.com/945841/205424253-aa0fb19b-aa08-4a17-bada-2c4b9204e954.png)

## 3. アップロードした CSV からテキストレイヤーを作る

次に UI に `<input type="file" />` を設置して csv をアップロードできるようにし、そのデータをそれぞれの Frame に入れ込みたいと思います。

今回は雑にこのような住所と名前が入った CSV を用意しました。

（数字が半角だと後で折返しで問題が起こるので全角にしています。本当はどんなのが来ても変換するなどしたほうがいいのですが本筋からそ逸れるので一旦これで...）

```csv
送り先郵便番号,送り先住所,送り先氏名,差出人郵便番号,差出人住所,差出人氏名
1234567,東京都渋谷区渋谷１ー１ー１ 渋谷ビル１０１,渋谷　太郎,1111111,東京都港区港１ー１ー１ 港ビル１０１,港　太郎
1234567,東京都渋谷区渋谷１ー１ー１ 渋谷ビル１０１,渋谷　太郎,1111111,東京都港区港１ー１ー１ 港ビル１０１,港　太郎
1234567,東京都渋谷区渋谷１ー１ー１ 渋谷ビル１０１,渋谷　太郎,1111111,東京都港区港１ー１ー１ 港ビル１０１,港　太郎
1234567,東京都渋谷区渋谷１ー１ー１ 渋谷ビル１０１,渋谷　太郎,1111111,東京都港区港１ー１ー１ 港ビル１０１,港　太郎
1234567,東京都渋谷区渋谷１ー１ー１ 渋谷ビル１０１,渋谷　太郎,1111111,東京都港区港１ー１ー１ 港ビル１０１,港　太郎
```

まずは、UI スレッド側の処理です。UI スレッド側はユーザーの入力を受け付けたり、ブラウザ API を叩いたりする役割を担っています。

```html

<h2>年賀はがき宛名ジェネレーター</h2>
<div>
  <label for="address">CSVファイルを選択</label>
  <input id="address" name="address" accept=".csv" type="file" />
</div>
<button id="create">作成</button>
<script>
  document.getElementById("create").onclick = () => {
    // CSVファイルを取得
    const CSVFile = document.getElementById("address").files[0];

    // Promise化したFileReader API
    const fileReaderPromise = new Promise((resolve, reject) => {
      const fileReader = new FileReader();

      fileReader.addEventListener("error", () => reject(fileReader.error));
      fileReader.addEventListener("load", () => {
        const { result } = fileReader;
        resolve(result);
      });

      fileReader.readAsText(CSVFile);
    });

    fileReaderPromise.then((CSVRaw) => {
      const endOfFirstLineIndex = CSVRaw.indexOf("\n");
      const rowsRaw = CSVRaw.slice(endOfFirstLineIndex + 1);
      const rowsNoCells = rowsRaw.split("\n");
      const rows = rowsNoCells.map((row) => row.split(","));

      parent.postMessage(
        { pluginMessage: { type: "create", rows: rows } },
        "*"
      );
    });
  };
</script>
```

最初に、FileList から CSV ファイルを取得します。

そして、不要な Header を CSV から取り除き、改行をもとに行の文字列を抽出します。

最後に、それらの行を句読点で分割した配列のデータを `postMessage` でサンドボックススレッド側へ送信します。

次にサンドボックススレッド側の処理です。サンドボックススレッド側は Figma のレイヤー操作などを行う役割を担っています。

```ts
// code.ts
figma.showUI(__html__);

figma.ui.onmessage = async (msg) => {
  // TextNodeのプロパティを変更するにはまずこの関数を呼び出す必要がある
  await figma.loadFontAsync({ family: "Inter", style: "Regular" });
  await figma.loadFontAsync({ family: "Zen Antique", style: "Regular" });

  // TextNodeを構築する関数
  const composeTextNode = (props: {
    fontSize: number;
    characters: string;
    x: number;
    y: number;
    isPostalCode: boolean;
  }) => {
    const textNode = figma.createText();

    textNode.x = props.x;
    textNode.y = props.y;
    textNode.characters = props.characters;
    textNode.fontSize = props.fontSize;

    // 郵便番号とそうでない場合で場合分け
    if (props.isPostalCode) {
      // 文字間を調整
      textNode.letterSpacing = {
        value: 55,
        unit: "PERCENT",
      };
      // フォントはデフォルト
      textNode.fontName = {
        family: "Inter",
        style: "Regular",
      };
    } else {
      // 縦書きにする必要がある
      textNode.lineHeight = {
        value: props.fontSize,
        unit: "PIXELS",
      };
      textNode.resize(props.fontSize, props.characters.length * props.fontSize);
      // フォントは明朝体にする
      textNode.fontName = {
        family: "Zen Antique",
        style: "Regular",
      };
    }

    return textNode;
  };

  if (msg.type === "create") {
    for (let i = 0; i < msg.rows.length; i++) {
      const frameWidth = 1181;
      const frameHeight = 1748;

      const frame = figma.createFrame();
      frame.resize(frameWidth, frameHeight);
      frame.x = i * (frameWidth + 20);

      // 送り先郵便番号
      const destinationPostalCode = composeTextNode({
        fontSize: 72,
        characters: msg.rows[i][0],
        x: 540,
        y: 150,
        isPostalCode: true,
      });
      frame.appendChild(destinationPostalCode);

      // 送り先住所
      const destinationAddress = composeTextNode({
        fontSize: 56,
        characters: msg.rows[i][1],
        x: 1037,
        y: 300,
        isPostalCode: false,
      });
      frame.appendChild(destinationAddress);

      // 送り先氏名
      const destinationName = composeTextNode({
        fontSize: 128,
        characters: `${msg.rows[i][2]}　様`,
        x: 600,
        y: 400,
        isPostalCode: false,
      });
      frame.appendChild(destinationName);

      // 差出人郵便番号
      const returnPostalCode = composeTextNode({
        fontSize: 48,
        characters: msg.rows[i][3],
        x: 80,
        y: 1460,
        isPostalCode: true,
      });
      frame.appendChild(returnPostalCode);

      // 差出人住所
      const returnAddress = composeTextNode({
        fontSize: 32,
        characters: msg.rows[i][4],
        x: 360,
        y: 700,
        isPostalCode: false,
      });
      frame.appendChild(returnAddress);

      // 差出人氏名
      const returnName = composeTextNode({
        fontSize: 64,
        characters: msg.rows[i][5],
        x: 180,
        y: 920,
        isPostalCode: false,
      });
      frame.appendChild(returnName);

      figma.currentPage.appendChild(frame);
    }
  }
};
```

最初に、`onMessage` で UI スレッド側から、CSV から抽出した`rows`のデータを受け取ります。

そして、受け取ったデータを `composeTextNode` 関数で TextNode に変換していきます。この際、郵便番号は文字間を調整し、それ以外は縦書きのスタイルを適用し、フォントを明朝体にします。

最後に、それらのテキストレイヤーを Frame に入れ込みます。

完成しました！

![](https://user-images.githubusercontent.com/945841/205484277-68e930d2-1425-4ad5-8789-083b7c7f3165.png)

![](https://user-images.githubusercontent.com/945841/205484648-e2b64741-5a6d-45da-9359-8c047e65b423.png)
_実際にはがきを当ててみたところ_

## まとめ

ここまで読んだ方はお気づきかもしれませんが、このプラグインはとりあえずシュッと作ったため以下のような点に対応できていません。

- 文字列が長くなった場合のフォントサイズ縮小や改行
- 連名
- 縦書きのスタイル（ハイフンが横向きのまま etc...）
- etc...

文字列が長くなった場合のフォントサイズ縮小や改行
、連名は頑張ればアップデートできそうですが、「縦書きのスタイル」に関しては、API から Text Node
の Vertical alternates の設定を触れないため、いまいま自動化の対応はできなそうです...

ちなみに Figma から手動で Vertical alternates の設定を変更するとこのようにハイフンを縦向きにすることができます。

![FigmaからVertical alternatesの設定を変更したところ](https://user-images.githubusercontent.com/945841/207390663-b53be038-f49c-4208-a401-eb5a55adf82c.png)

自分でプラグインを作ってみたことで、年賀状専門ソフトの偉大さを知りました。いつもありがとうございます！

# さいごに

私が働く家計簿プリカ B/43 を運営する株式会社スマートバンクでは各方面で積極採用活動中です。

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

特にデザイナーの中では現在はコミュニケーションデザイン領域のデザイナーを募集中です。

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

選考とは別に、「気になるけど選考に進むか悩んでいる」という方向けに会社の雰囲気や気になる職種の業務内容をお話しする「カジュアル面談」も用意しているので、ぜひお気軽にご連絡ください。

- [カジュアル面談への応募 - 株式会社スマートバンク | SmartBank, Inc.](https://smartbank.co.jp/de1f8d3093a64bcd99e2487352cf5f56)

CSVでアップロードした住所録から年賀はがきの宛名面を作成するFigmaプラグインをつくった

昨日は [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を扱いやすいような何かをモバイルアプリのエンジニアと協力して考えています。


putchom

Posts

Sass のテストコードを書くと便利

CSVでアップロードした住所録から年賀はがきの宛名面を作成するFigmaプラグインをつくった

Schema by Figma 2022の備忘録

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

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

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