見出し画像

もうかりまっか?デザインシステム

こんにちは!まいどおおきに!

健康管理システムCarely(ケアリィ)の導入を通じて働くひとの健康を世界中に創る事業を展開している株式会社iCAREの高橋名人 (@zouzei8to10)と申します!

いま、iCARE開発部ではCarely機能開発(COVID-19ワクチン接種管理特殊健康診断管理ストレスチェック80問対応など)に日々邁進しているわけなんですが、私はその中でも特に「デザインシステム」の構築を進める旗振り役を担っており、デザイナーとフロントエンドエンジニアの橋渡しをスムーズにするため、noteや社内ドキュメントにその意義や進め方などをルール化する作業を進めております。

以下に関連noteを貼っておくのでまずは是非ご覧ください!

もうかりまっか?デザインシステム

さて、今回はデザインシステムの意義を開発者以外の方にもお伝えするべく、「もうかりまっか?」という視点からお話したいと思います。

「デザインシステムがお金になるのか?」という視点だとやや狭義的になってしまう恐れがあるので、ここではもう少し広い視野で「デザインシステムの経済的な合理性」をお伝えいたします。

同じ部品は何回も作りたくない。

どのようにしてチームはデザインを体系的に考えるようになるのでしょうか。通常は、現在のワークフローの問題に気づくところから始まります。デザイナーは、いつも同じ問題を解決しなくてはならないことや、デザインを適切に実装できないことにいら立ちを感じています。
開発者は、コンポーネントごとにカスタムスタイルを作成したり、乱雑なコードを処理することに飽き飽きしています。

Design Systems

これは「Design Systems」の7章「計画と実践」の冒頭にある一文ですが、組織が大きくなり新たなメンバーが順次入ってくる中でも同じような部品を何度も作らなくていいように、componentのルールを決めたことが実際に「もうけたで〜!」と思うことも増えてきました。


弊社の新人フロントエンジニアの投稿を転載させていただきましたが、プロジェクトを進める上で、デザインシステムを指針とすることでかなりいい感じに開発が進んでることを実感しています。

GitHubの「デザインシステム」関連のissue

component化されたパーツは実装の意図が明確化されているので入って1週間のエンジニアが次の週のリリースで実際のプロダクトに適用することもありますし、オンボーディング的にデザインシステムの背景と意義を共有することでプロダクトの理解のスピードも上がっている気がしています。

また、最近ではcomponentの実装だけではなく、設計のバリエーションの提案や考慮漏れの部分を入って間もないエンジニアからボトムアップで提案してもらえることも増え、チームで同じ目的を持って進められていることをありがたく思っています。

デザインシステムは儲かります!

さて、
今回はデザインシステムの経済性について書いてきましたが、結論は「もうけもん!」だと実感しています。

もちろん、お客様からのアップセル(追加受注)などに直接影響することは(まだ)ありませんが、Carelyの開発が非常にClearでVisionalになってきたことは間違いなくいい効果として現れてきてます!!

以上、
株式会社iCAREではデザイナーをはじめ、各ポジションにて求人をしております。デザインシステムの設計やドキュメントの拡充にご興味のある方はまずはカジュアル面談からでもお気軽ご連絡ください!

このnoteが面白かったら「スキ」や「フォロー」や「コメント」をしていただけると大変嬉しいです!

この記事が気に入ったらサポートをしてみませんか?