スマレジ・デベロッパーズのstorybookを作成してみて
７月半ばくらいから、スマレジ・デベロッパーズでstorybookを作成し始めています。ver.1.2.0くらいからstorybookで作成したコンポーネントをインポートしてそのままデプロイするようになります。
smaregi-developers-ui
権限つけてないので、まだ見れないと思います。
Sample
個人用storybook
メリット
少し順不同感が否めませんが、思いつくまま列挙してみました。
1. 複雑な環境の操作をデザイナーに強いることがない。
これまではデザイナーに複雑な環境の操作を要求していました。エンジニアの目線からではだいぶ簡単になった操作（Docker操作）も、デザイナーにとっては未知の領域です。
少なくとも、デザインと言う仕事するにあたって、
- Docker for Macをインストールする必要がなくなります。
- MySQLクライアントツールなど、余計なソフトをインストールする必要がなくなります。
- それに応じて、そのソフトの勉強コストがなくなります。
- 別プロジェクトなので、管理が比較的楽になります。
という、デメリットを削除することができます。
2. エンジニアがデザイナーに依頼しやすくする。
ちょっと誤解を招くような内容ですが、デザインはエンジニアの仕事ではありません。（エンジニアがデザインをしている人が入ればその人はエンジニア兼デザイナーというだけです。）
エンジニアがしばしばデザイナーの領分に侵食して口を出したりします。意見を言うのはとても良いことだし、大事にしていきたい文化なのですが、なぜか（エンジニア＞デザイナー）のような構図で最優決定権はエンジニアサイドが持っています。
上記の問題を 「デザインの仕事が別のプロジェクトになること」 で、明確な役割分担を推進することができます。つまり、デザインに関する業務はデザイナーの責務というのをエンジニアが直に感じることができます。
更にその副産物として、フロントのビジネスロジックの分離を行う事ができますが、これは後述します。
3. エンジニアがデザインで悩むことがなくなる。
ほとんどのエンジニアはデザインに興味なんてなく、
「大体同じ感じでいいから。」
とか、
「他のページがそうだから〇〇みたいな感じが良いんだけどなぁ。」
という感じになります。これはエンジニアが怠惰というわけではなく、デザインに割く（関心的、業務的）リソースがないだけだと思います。
それらをすべて本来の持ち主であるデザイナーに渡し、自分は本来すべき業務に集中できるようになります。
4. デザイナーとエンジニアの架け橋になる
storybookというプロジェクトはデザイナーとフロントエンジニアの責任で進むプロジェクトなので、デザイナーの意思が反映しやすく自発的に良いものが仕上がっていきます。
なのでエンジニアもデザイナーへの依頼がしやすくなり、これまでの外注的なやり取りではなく、フロントエンジニアとデザイナーの架け橋になるようなものになります。
例えばボタンをstorybookに作成したとして、クリックしたときの挙動をフロントで記載したとすると、そのボタンをクリックしたときそのコンポーネントがどうなるかをデザイナーとフロントで相談するでしょう。
このとき重要なのはプロジェクトとして、その動作がどうなるかではなく、そのコンポーネントがどうなるかを検討するのです。プロダクトを支えるコンポーネントをデザイナーとフロントエンジニアが協業して作成するようになるので意欲が湧いて来ると思います。
5. ビジネスロジックとイベント関係を分けることができる
ここの内容はフロントに処理を書くとき、フレームワーク内で処理は書かない方がいい気がする
ここの記事と言いたいことはほとんど同じです。
具体的に言うと、storybookは正確には別のプロジェクト、パッケージの扱いになるので、よっぽどの専用コンポーネント以外にはビジネスロジックに関わる処理を書きたくありません。
その思想の元作成すると、自然とコンポーネント内でAPI呼び出しを行うなどの設計が解決します。
6. 本番のコードと同じ内容でデザインレビューができる
これはこれまでのプロダクトそのものをデザイナーに見せてレビューする方法と何が違うのかと疑問を持つ方が居ますが、その回答は火を見るより明らかです。
- デザイン単体でレビューが可能
- storybookにPRを投げることになるので、機能的観点のレビューが必要ないです。 だから素早くマージまで行う事ができます。
- デザイナーが自身の環境で「動き」のレビューをすることができる
- 一度コンポーネントを作成すると、自作コンポーネントの使いまわしができる
- 新しく作り直したり、コピペじゃない
- 俯瞰して（先入観なしで）デザインできる
デメリット
1. デザイナーのstorybook学習コストが増える
storybookはNodeパッケージなので、デザイナーもある程度のnpmコマンドの知識を保つ必要があります。しかし、デザイナーのすべてがNodeの知識があるかと言われればそうではないので、勉強するコスト、または教育するコストが発生します。
2. エンジニアのプロジェクト管理コストが増える
バックのプロジェクトだけではなくフロント用のプロジェクト（しかも厳密にはプロダクトと関係無いもの）を管理する必要が発生します。
プロダクト自身に導入するパッケージにはより一層慎重にならなければなりませんし、フロントの構成についてもっと考慮する必要が発生します。
例えば、導入するStorybook側にBootstrap5が入っているとして、プロダクト側はまだBootstrap4の場合、デグレーションを起こす可能性がないと言い切れません。（特にCSSの観点から見ると。）
3. 既存のプロダクトに導入するコストはやっぱりある程度ある
すでに画面レイアウトが完成仕切ってるプロダクトに改めて導入するにはコストが発生します。
もちろん導入することでボタンの変更を一括で管理できるようになったりするのは便利ですが、すでにリリースされている画面のコンポーネントをすべて揃えるまでかなりの時間を要するでしょう。
スマレジ・デベロッパーズは一般公開してまだ１ヶ月ですが、すでにしんどい面があります。
特にこのプロダクトはオフショア開発で画面によっては全く違う実装をされていた経緯があるので。
今後どうしていきたいのか
CSS(デザイン) / HTML・javscript(フロント) / PHP(バック) を完全に分解し、適宜その中から必要なパッケージを呼び出して使えるようにしていきたい
Style - CSS
デザイナー・フロントエンジニアが担当。CSSをデザイナーが書かず、エンジニアが書く。
Styleのほとんどはすべてのプロダクトで共通。イメージは
- POSテーマ
- Waiterテーマ
- Timecardテーマ
で別れているというイメージで、コンポーネントが全く違うわけではない。（専用コンポーネントは当然存在するが、共通コンポーネントに差異が無いという意味で。）
ここで作成されたCSSはNodeパッケージ / CDNなどで共有できるようにする。
┏ pos.min.css
┣ waiter.min.css
┣ timecard.min.css
┗ smaregi.min.css
StoryBook
各プロダクト、ないしは共通で存在する。コンポーネントの目的と仕様を記載するプロジェクト。
パッケージ化されたCSSを読み込みテーマ切り替えができるようになっている。
ビジネスロジックを持たずに、機能だけを持つ。
Nodeパッケージ化され、簡単にコンポーネント共有できる。
View
各プロダクトのページ / 画面。
Storybookで作成したコンポーネントと、ビジネスロジックモジュールを読み込みページの要件を満たす。ここで、ビジネスロジックをパッケージ化するのかという議論がありそうだが、そこまでしなくていいんじゃないのかなとは思っています。しかし、ビジネスロジックモジュールはできるだけバニラで書かれるかTSで書かれるかするのがベターです。（スマレジ・デベロッパーズはバニラ）
一部バックがHTMLをレンダリングする場合もあります。
Back
Viewを返さない、APIサーバーであるのが理想です。さらにドメインレベルでマイクロサービス化され、必要に応じたパッケージ群で構成されているとさらに良いです。
以上のことができれば、一つ一つの責務を小さくすることができて、開発がとても楽ちんになるはずです。
Storybookを一般公開したい
スマレジ・デベロッパーズはこんなので作成されていますと自信を持って公表できるなら、採用にも使えるはず。「こんなデザインしてみたい」「こういう働き方してみたい」という需要は必ずあるはずです。
サボりたい
もう一からHTML書くの嫌だ。デグレも嫌だ。一回書いたら二度と書きたくないです。
最後に
今回は社内向け資料としての記事でした。 内容を精査したら限定公開ではなく一般公開となっているかもしれません。
storybookが必須というわけではありませんが、似たようなデザインマップがある以上あった方が良いと思います。
今回は概論でしたので、技術的な導入方法も少しずつ書いていこうと思います。その時はよしなに。
.
