https://gyazo.com/8ab4e1c4aeb2b96111276ad1edb8cd77
SmartHRの開発組織
エンジニア30人
うち6人フロントエンド
プロダクトサイドのデザイナーは4人
チーム
Core
SmartHR
Plus
DBを使った単機能なアプリケーションをつくる
オンライン雇用契約
カスタム社員名簿
らくらく分析レポート
フロントエンド
SmartHR本体
Plusアプリ
Rails API
共通コンポーネント集
SmartHR-UI
理想
本体機能をプラスアプリ化
プラスアプリの資産を本体へ
デザインシステムを持たない組織のこれまでの取り組みと今後を考える
デザイナレス時代があった
2019年現在、デザイナ2人＋エンジニア8人体制に
原則
ユーザへの提供する価値をドキュメント化
形状
形状に落とし込むアプローチを具現化・言語化
実装
コードに落とし込むためのアプローチを具現化・言語化
チームのベストプラクティスを凝縮して良い評価基準がもてるように
2016年当時のワークフロー
フロントエンドの作業領域を分担して組み込みの一部をデザイナが担当
リリースこそ正義
2017〜2018年
デザイナーはコードを触らないように
ゼロイチ開発
綺麗な構造よりもユーザーに届けることが最優先
リリースこそ正義
コンポーネント志向と向き合うように
課題
コンポーネントの粒度
いかに効率よく実装するか
統一されたコードが参照できる
メンテナンスはどうするか？
ワークフローに組み込むコスト
チームでデザインするためのハブにする
single source of design
事実上、信頼できる唯一のデザインリソース
設計
UIを指標にしてエンジニア的設計の粒度で実装
キッチハイクのこれから
今まで：効率よく実装するか？という視点
デザインが属人化しがち
スキルや特性・リソース配分でワークフローは変わる
これから；デザイナとデザイナをつなぐもの
地図・コンパスを構築するフェーズ
デザイナがカバーできる生産量を超えつつある
エンジニアもデザイナの役割がもとめられる
デザインシステムはまだ必要ない
デザイナが増えて、組織が拡大したときが検討のタイミング
パネルディスカッション（SmartHR + ヤフー + メルカリ）
パネラー
モデレータ
古川
デザインシステム懐疑派
かつて失敗してるので
存在意義は肯定してる
費用対効果が疑問
議論のゴール
デザインシステムの疑問について意見をぶつけて回答を得る
デザインシステムの落とし所
そもそも論
うまくいってるか
はるけん
運用１年
イエスといいたいが言い切れない
プロダクト側に導入してもらえた
その後「やっぱ辞めます」というのもあった
徐々に認知はされつつある
当事者意識のある人がいるのもある
モチベーション自体は高い
デザインの統一目的はあるのでビジネス目的はそこまでない
うさぎ
運用半年
成功したかと言えるか評価できない
作って空中に浮くのはやめよう
ゴールを作る
小さく作って、実際に使ってもらう
おうじ
運用３ヶ月
お金に跳ねてないのでうまくいってない
＝成功していない
まだ走り出しの期間
どこで定量化してる？
解約率
プロダクトの品質にフィードバックしていきたい
デザインシステムを最初から手を付けるならどこ？
おうじ
お行儀よくやってない
パターンの洗い出しはしない
トップダウンのあるべきデザインをつくる
現状のコンポーネント洗い出ししてボトムアップをする
プロダクトのFBをもらってすくい上げる
うさぎ
あるべき姿はあるが
システマチックな動きは入れたい
現状の設計とは別枠にする
ページのスクショをしてアナログ的に話し合う
完璧は目指さない
カラーパレットはガンガン変更くる
はるけん
整っているところをどこが統一できるか調べる
パーツごとで作っていく
デザインシステムはどこまでやってる？UI Kit, Styleguide, ドキュメント化？
はるけん
Styleguiideもドキュメント化
React Componentの提供
うさぎ
UIソースコード
ドキュメントつくり
デザインのドキュメント化はまだできてない
ブランドデザインに当たる？
おうじ
Sketchのライブラリ
Reactのコンポーネント化
説明するガイドライン作成
Sketchとコンポーネントとの整合性はどうとってる？
みんなでやってる
ルールがあったほうがやりやすい（命名規則とか）
組織論
デザイナーとエンジニアとの協業・温度感はどうしてる？
うさぎ
ワイヤーフレームはデザイナーが考えるべき領域
熟知する人がやるべき
スクラムやるならデザインシステムを全員が理解すべき
実際はできてなかった
はるけん
デザイナーだけでやってる
エンジニアとの協業はやってない
おうじ
現職は期待値は善意がもってる
前職について
プロパガンダの政治
ひょうきんなアウトプットをまじめなアウトプットにつなげる
vibesという名前
バージョンがあがると「ぶち上がる」
Storybook腐りやすい問題
おうじ
絶賛腐ってる
運用していくしかない
SmartHRはここに投資していく
前職では
OKRにデザインシステムのメンテナンス目標に入れる
うさぎ
バージョンニングしてデプロイしてた
＝バージョンが違うと差分がある
ライブラリのアップデートはしていかないといけない
どんな人でもコミットしてよい
社内OSSをするのは無茶だったのでメインメンテナを入れるようにした
はるけん
Storybook警察やってる
警察を置くのは大変？