FigJamとREADMEでコンポーネント設計をしてみた
こんにちは!
スペースマーケットでフロントエンドエンジニアをしている原口です。
現在スペースマーケットでは旧環境のフロントエンドのコードをNext.jsに移行しています。
移行作業は、施策、チームでの活動、個人活動など様々な活動を通して行われているのですが、今回は個人で移行を行うための準備をしました。
その際にやったことついて記事を書いてみました。
旧環境からの移行についての詳細は弊社佐伯さんの記事をご覧ください。
※移行ついては上記の記事に書かれているため、この記事では移行に関しての具体的な技術などには触れていません。今回移行のための準備をした対象のページについて
今回移行を行ったページの情報は以下の通りです。
- 基本的に静的なページ
- 一部ログイン状態をpropsで受け取りコンポーネントの表示/非表示を行う
何を準備したか
基本的に静的なページであったので、準備自体もそこまで大変なものではありませんでしたが、準備として以下を行いました。
- FigJamで既存ページのデザインと各コンポーネントの情報の洗い出し
- 新規作成コンポーネントを情報を記載したREADMEファイルの作成
1.FigJamで既存ページのデザインと各コンポーネントの情報の洗い出し
今回移行する予定のページが10ページ以上あったため、まずは既存ページのデザインチェックと移行に伴い作成するコンポーネントの情報を洗い出しました。
使用したツールはFigJamです。
FigJamとはFigma社の提供しているオンラインホワイトボードツールのことで、スペースマーケットではスプリントの振り返りや、弊社で行っているチャプター活動などで活用されています。
大分見づらいのですが、このような感じで移行予定のページのPC、スマホ用キャプチャを用意しました。
もう少し寄るとこんな感じです。
既存ページの洗い出したあとに、共通化できるコンポーネントについての洗い出しを行いました。
このページでは共通コンポーネントを5つ作成する必要があることがわかりました。
FigJamはホワイトボードツールであるため、付箋機能を使用できます。
なので付箋を使ってコンポーネントに必要な情報、気付き、実装前に相談することなどを付箋にまとめました。
またFigJamではコードブロックを作成する機能があるため、型情報などもここで定義しました。
2.新規作成コンポーネントを情報を記載したREADMEファイルの作成
コンポーネントの情報の整理ができたので、実装...をしようと思ったのですが、今回は少しやり方を変えてみました。
スペースマーケットではSlackとGitHubが連携されているため、基本的にはGitHub上で行われているやりとりはSlackのチャンネルに飛んでくるのですが、以前エンジニアメンバーがコンポーネント設計を行う際に、READMEファイルを用いたコンポーネント設計書を作成しているところをSlack上で発見しました。
はじめにも書いた通り静的なページの移行だったため、そこまでやる必要があるか悩んだのですが、せっかくなので自分もREADMEファイルを用いたコンポーネント設計書の作成を行ってみることにしました。
具体的な作業としては以下の通りです。
- 新たに作成するコンポーネントのディレクトリ構造を作成。
- 各ディレクトリにREADMEファイルを作成。
- READMEファイルには、そのコンポーネントに関わる情報を記載する。
以下は実際に作成したREADMEファイルの一例です。
# src/components/pages/serviceGuide/shared/GuideMainVisual
ご利用ガイド配下のページで使用する共通メインビジュアルコンポーネント。
## 機能
- 基本的にご利用ガイドページ配下のコンポーネントで使用します。
- ただし、以下のページではメインビジュアルの作りが異なるため、このコンポーネントは使用しません。
- [あと払い(ペイディ)について](https://www.spacemarket.com/about/paidy)
## Input
- タイトル
- サブタイトル
- 背景画像
## Output
- Inputで受け取ったpropsを表示するメインビジュアルコンポーネント
## 参考画像
![PC](https://user-images.githubusercontent.com/xxx.png)
![SP](https://user-images.githubusercontent.com/xxx.png)
READMEファイルに記載した情報としては以下の通りです。
コンポーネントを置くディレクトリの情報
機能
- どのように使用するか
- どのようなUI・情報を表示するコンポーネントか
Input
- 受け取るpropsの情報
Output
- Inputの結果どのような表示をするか
参考画像
- 実際のデザインデータのキャプチャ
このような内容を記載したREADMEファイルを実際のディレクトリ構造と合わせて作成しました。
今回、自分は記載していませんでしたが、他の方でAPIの情報や補足、備考などの情報を追加している方もいました。
良かった点
それぞれ良かった点について書きたいと思います。
1. FigJamで既存ページのデザインと各コンポーネントの情報の洗い出し
まず付箋による情報の整理がしやすいと感じました。
Figjamの付箋機能を使った情報の整理については、毎週行っているペアプロでも行っているため、今回の作業で初めて行ったものではないのですが、デザインと付箋によるコメントの位置関係が近しいため、個人的にはドキュメントなどにまとめるより直感的でわかりやすいと改めて感じました。
また上の方にも書きましたが、コードブロックを用いて事前に型の情報を整理できることも良かった点でした。
2. 新規作成コンポーネントを情報を記載したREADMEファイルの作成
こちらは今回初めて行ってみたのですが、情報の整理はもちろん、このREADMEファイルがそのまま仕様書となる点が良かったと感じました。
今回の移行は一気にすべてのページを自分で行うわけではないため、READMEファイルを残すことにより、自分以外のメンバーが作業を行う上でもスムーズに作業に入れるのではないかと感じました。
以上となります。
最後に
スペースマーケットでは以下の職種を絶賛募集中です!
ちょっと話を聞いてみたいといったようなカジュアルな面談でも構いませんので、ご興味のある方は是非ご応募お待ちしております!
その他採用についての情報はこちらをご覧ください!
採用技術スタックについてはこちらをご覧ください!
スペースを簡単に貸し借りできるサービス「スペースマーケット」のエンジニアによる公式ブログです。 弊社採用技術スタックはこちら -> whatweuse.dev/company/spacemarket
Discussion