デジアンシステムとは何か?

「デザインシステムからはじめない、デザインシステムの考え方」に参加してきました

デザインシステムからはじめない、デザインシステムの考え方
https://flexy.connpass.com/event/289496/
に参加してきたので、そのときのレポートです。

登壇者

  • 小木曽 槙一さん|株式会社SmartHR プロダクトデザイングループ プロダクトデザイナー @kgsi
  • 金森 悠さん|株式会社SmartHR プロダクトデザイングループ プロダクトデザイナー @uknmr
  • sakitoさん|サイボウズ株式会社 Design Technologist @__sakito__

デザインシステムとは何か?

デザインシステムとは何か?
デザインシステムとは何か?
  • デザインシステムは変数的なもの。プログラミングでいう箱で、そこに何をいれるか。
  • 会社によって、スタイルガイドをデザインシステムと言ってたり、コンポーネントをデザインシステムと言っていたりする。
  • デザインもシステムも言葉が大きい。
    仕組み化までしてシステムなのかなと思っている。
  • デザインシステムって楽な単語だと思う。すべて説明するよりは、大きな「デザインシステム」というラベルを使うと会話が楽。
    言うのは楽なんだけど、作りますってなるとちゃんと会話しないといけない。
    個々人の考えているデザインシステムは、コンポーネントのことだったり、デザイン原則だったりすることがある。
スタイルガイド
スタイルガイド

SmartHR

  • デザインシステムを作ることが目的で始まったわけではない。
  • コンポーネントライブラリやUIガイドラインが当時あったが、内部ではドメインが20個くらいに分かれていてデザインの違いがあり、ユーザーを混乱させてしまうことがあったのでその課題解決で始めた。
  • 社内でもデザインのドキュメントが散らばっており、「ここを見れば分かるよ」という状態にしたかった。

サイボウズ

  • デザインの歴史の継承をしたくて始めた。
    歴史の継承をしていない(デザインの移り変わりの背景を知らない)ために、同じ繰り返しをしてしまうことがあった。
  • そこで、10年溜まった知見を活かすことができるようにしたいと思った。
    当時、ドキュメント自体は残ってたが、まとまっていなかった。
    データがなくなることもあるが、人もいなくなると更に難しくなる。経緯を誰も知らない状態になる。

質問:「受託制作はデザインシステムをどう作るのが最適か?」

  • 何を解決したいデザインシステムなのか。
    仮にスタイルガイドを用意してそれが機能するのであれば、それはシステムだといえるのだと思う。
  • 何をしたいのかが大事で、丸投げしたらうまくいかないし、伴走してくれたらいいかもしれないし。
  • どう作るのが最適かと言われたら、現場によるかも。
    現場の人はデザインシステムが欲しいわけではないと思うので、デザインシステムを作ることを目的にしないほうがいい

質問:「サイボウズ社ではデザイン変更の履歴を現在どのような仕組みで残されているのでしょうか。」

  • まだ TRY 中だが、ストーリーブックに全部まとめてる。
  • ので、ブランチの履歴を見ればわかるようにしている。Figma に変更履歴のリンクを残したり。

デザインシステムの立ち上げ方

目的・課題を明確にする

目的・課題を明確にする
目的・課題を明確にする

課題

SmartHR

  • 20個くらいのプロダクトのUIのばらつきがユーザーの混乱の原因になってる。
  • 横串でレビュー会もやってるけど、対処しきれず難しかった。
  • コミュニケーションコスト増大。例えば、エンジニアからしたら「この余白の違いは意図してるのかどうか」などの質問への対応とか。

サイボウズ

  • 歴史の継承ができていない。
  • デザイナーしかデザインに関わらない。
  • ボタンの色や配置を変えて終わりならPMでもできるので、デザイナーはもっと難しいことに注力したほうがいい。

課題対処へのことはじめ

SmartHR

  • 歴史があったため、当時スペースがずれてるところとか気になっていて、パターンを統一したいと思っていた。その課題を解決するためにやるという姿勢だった。
  • 明確にデザインシステムを作ろうぜという感じで始めた訳ではなく、レガシーなものを整理したいという課題から始まった。

サイボウズ

  • デザインを言語化するチームを立ち上げ、アクセシビリティ、エンジニア、デザインを変えたい方、等デザイナーだけではなく色んな方面に強い人が集まったチームで始めた。
  • 過去を直すのは制約が大きいから、新しいところから始めようとなった。
  • デザイン室で、デザインとは外部にアウトプットするもの全てをデザインと定義。

便利なコンテンツから作る

便利なコンテンツの3つのポイント
便利なコンテンツの3つのポイント

SmartHR

  • デザイントークンの定義
  • 地道にタイポグラフィを考えたり。

サイボウズ

  • ボタンのコンポーネントを1つ用意するだけという、一番ミニマムなところからやった。これから増やしていくが、まずは既存のボタンのコピペだけ。
  • だんだん、それを使ってプロダクトを作ることで、こことここは共通だとなっていったりした。
  • 少しずつ移行していく。

まとめ

  • 便利なものを作る。作っても使ってもらわないと意味がない。
  • 最初は読み物だけでもいいかもしれない。
  • プロダクト立ち上げ当初だとデザインシステム作るの難しいと思うから、当初どうしてこのデザインにしたかを残しておけると、後から役に立つかもしれない。

デザインシステムをみんなが使えるようになるために

「みんなのもの」にするための3ステップ
「みんなのもの」にするための3ステップ

最初は地道な草の根活動

  • SmartHRもサイボウズも、最初は草根の根活動
  • 日本だとデザイン原則という言葉を使っていて、それはよくないかもしれない。英語だとフィロソフィーやファンダメンタルと言っているが、日本では直訳して原則と言っている。
  • デザイン原則をやると永遠に時間がかかるので、それより先に浸透していくことをしている。
  • 未だに浸透のための草の根活動は続けている。
  • だんだん、ファンがついてきてドキュメントを読み込んでくれたりしてくれる。

組織浸透時に課題

SmartHR

  • デザインシステムがデザイナーだけのものになってしまう。

サイボウズ

  • デザインシステムが浸透することで、やることが増え、開発の妨げになってしまう恐れ。これは現在進行形で起こっている。
  • 組織は大きくなっていくので、それを追いかけるように浸透させていかないといけない。

課題に対するアクション

SmartHR

  • エンジニアがデザインシステムを知らないので説明したり啓蒙したり

サイボウズ

  • 機能追加やリリースするものがあれば早く察知するようにする。デザインシステムが原因でリリースを遅らせるわけには行かない。
  • 最初は中央集権的にチームを立ち上げたが、分散的なチームに移行
  • 今はコアメンバーは、本当に大事なところだけやりますとか。

質疑応答

質問:デザイン素養のない開発者だけでは手詰まりを感じている。
デザインシステムについて見識があるパートナーを得たい。どこで見つければよいのでしょうか。

  • 自分がこの会社いいなって会社に話を聞きにいくのがいいかもしれない。

質問:プロダクトの開発を始めてからどのくらいのフェーズの時にデザインシステムを作り始めるのがいいのでしょうか?

  • デザインシステムというよりはドキュメント(さっきも話したけど)に、なぜこのデザインにしているのかというのを書いていくところから始めた。
  • デザインシステムを作ることが目的じゃないよって話。

質問:サイボウズ社ではstorybookがsingle source of truthになっていて、デザイナーもstorybookを参照して都度figmaにパーツを取り込みながらデザインを作成しているということでしょうか?

  • Yes

質問:社内的にデザインシステム化をする工数が承認されてない場合の「ことはじめ」は
結局ゲリラ的(時間外作業とか)にやるのが良いのでしょうか?

  • デザインやってる人は、なぜこのデザインにしたのかを説明する責任がある。なので、そのゲリラ的な作業でことを為せられたらよいけど、それで失敗したら…とかある。
  • エンジニアのリファクタリングと同じで、業務時間でしれっとやるのもありかもしれない。
  • ドキュメントから始めていって、作業効率が良くなったら「実はデザインシステムがあるんですよ」とかで広めていくとか。

質問:SmartHRさんが基本的にFontAwesome(Free)を使うことにしたのはどういう理由でしょうか。

  • 入ったときからそうだった。また、いまそれが課題になっていないので、課題になったらまた考えていこうという話になっている。

質問:ドキュメントが苦手とか、忙しくて実務の中でちゃんと読んできてくれない人はいましたか?
地道に普及活動やるしかないんでしょうか?

  • 基本読まないと思ったほうがいい。
  • 読まれなくてもあるのが大事で、何かあったときにスッと出すことができる。そこでの共通認識を持つのが早い。
  • 課題になってないから読まないだけだと思う。

質問:細かすぎるフィードバックや要望に対する、対応方針などは決めてますか?

  • 場合によるが、優先度で考えると思う。
  • 他にも、何度も同じ話をしてたら対応コストもあるから言語化しようとかある。
  • ただ、意見をくれたことに大してはめちゃめちゃ感謝している。

参加して個人的な感想とかまとめ

  • デザインシステムはあくまでツールであって作ることが目的ではなく、デザインシステムを使って課題を解決するのが目的
  • デザインシステムという言葉は人によって色んな解釈があるので、場面によっては具体的に何を指してるかを話すようにしたほうが良い
    • 「システム」と言われるので、具体的な物や行動というよりは、仕組みという解釈のほうが近いかもしれない。
  • デザインシステムを取り入れるとなった場合には、小さく部分的に始めると比較的やりやすいかも。かつ、周囲の人がメリットを感じる(これあると便利だな)ことも並行して進めると受け入れられやすいかも。
    • この辺りはデザインシステムによらず、システムリプレイスとか業務刷新とかする場合と似たような考え方だなと思った。
  • 登壇者の方は、事例を交えながらフランクな雰囲気で対談をしていただけたので、聞いていてとても分かりやすく、内容や現場感のイメージもしやすかったです。また、一貫してデザインシステムを作ることが目的ではなく課題解決の手段だというのもおっしゃっていて、改めてそうだよなと思いました。とても良いイベントでした。

Cybozu Meetup #7 セキュリティに行ってきました。

イベントページ

https://cybozu.connpass.com/event/63652/

イベントの趣旨(引用)

サイボウズでは製品セキュリティの品質向上をミッションとして PSIRT( Product Security Incident Response Team ) が活動しております。
PSIRT では 2014 年 6 月より、「脆弱性報奨金制度」を運営しております。 ご報告いただいた脆弱性情報を適切に評価し社内にフィードバックしております。

脆弱性報奨金制度のインパクトが大きいために他の活動はあまり目立っておりませんが、実は報奨金制度の運営以外にも様々な取り組みを行っています。
この Meetup では、実際にサイボウズの PSIRT がどのような取り組みを行っているかをお伝えしようと思います。

以下、講演内容を聞きながらのメモ

もしかしたらところどころ間違っているかもしれないので

その際はご指摘ください

講演1つ目

PSIRT の取り組み

講演者:ヤマニシさん

品質保証部に所属している

脆弱性評価などを日頃やっている方

CY-PSIRTとは?

製品のセキュリティ品質向上を目的にしたチーム

脆弱性情報の受付、評価、公開を行なっている。

脆弱性の検出について

  • 社内検証
  • 外部検証
  • 外部監査

が主にある。

ソフトウェア属性情報管理

扱っているサードパーティ製品の情報をDBにまとめている。

→サードパーティ製品に脆弱性があった場合に製品担当に連絡できるようにしている。

kintoneのアプリで脆弱性情報を集約している。

情報の公開

脆弱性認定ガイドラインを定めている

サイボウズで利用しているサードパーティ製品に脆弱性が見つかった場合に

サイボウズは問題ないですよという情報を発信している。

脆弱性検査のために

本番環境とはネットワークを分離した環境を用意している

セキュリティテストの実施

各製品の試験期間中にアクセス権が正しいかなどのセキュリティテストを取り入れている

社内検証はどのようにやっている?

試験仕様書を用意している

セッション・リクエスト・パラメータ等で網羅的に検証を実施。

脆弱性検証用のアプリを用意していて、それを元にテストを実施している

 (聴きながら思ったこと)AppScanのようなものを自前で用意しているのだろうか?

webアプリケーション診断ガイドラインというものが世の中にある

https://www.owasp.org/index.php/Pentester_Skillmap_Project_JP

今後はそれに合わせて脆弱性検査用アプリの内容を設定しようとしている。

外部検証について

社内とは別で、社外に検証を委託している

サイボウズのHPの検証は外部検証を行なっている。

外部監査について

外部の監査期間に、攻撃者の視点で脆弱性をつけないか監査をしてもらっている。

→(聴きながら思ったこと)監査結果を、パブリックに公開している?

CY-PSIRTの工夫

情報の管理

管理する情報が多い。

  • バグハンターの人からの問い合わせ
  • 報奨金の用意

などなど、やることが多い。

そこで、kintoneを使っている

脆弱性の情報は、脆弱性boxというアプリを使っている。

どこから報告された脆弱性か、脆弱性についての詳細などを書いている。

そこから、CVSSという計算機をつかって脆弱性を評価

業務内容

業務の内容が多いので、アプリを使って管理している。

  • 主担当やフロー
  • ドキュメントの場所など

そうすることで、誰が何をやっていて、誰に聞けば良いかというのが管理しやすい。

→(聴きながら思ったこと)画面を見せてもらったが、アーカイブ機能に優れていそうなツールだった。

業務の提案

品質向上のための取り組みをいろいろやりたい

自動検証ツールや、報奨金がといった要望があるが

そういった要望に対してサイボウズは割とすんなり通る社風

思いついたらとりあえずやる風潮

気軽に取り組める環境が大事

→(聴きながら思ったこと)そういう風潮が社内に根付いているのは、行動を起こす上でも、周りの理解を得る上でもとても大事だと思った。

ただし、人員不足がネック

調整事が多い

製品に対する決定権を持っていないので、プロダクト側との調整が大変。

脆弱性情報をいつ公開するか、など

バグハンターからの問い合わせも、問い合わせ管理アプリを使っている。

 問い合わせ管理アプリの画面見せてもらったが、写真などのシェアはNGだった。ただ、記載することなどが、あとから見てもとても明瞭になるような工夫がされているなと感じた。そういったやりとりのエビデンスを残す場所は、何をどう書くかを明確にしているととても書きやすそうで分かりやすいと思った。

メールのやりとりはメールワイズ。

どこで誰と調整するかを明確にする。

調整して、どこを折衷案とするかを考えるのが大変。

質疑応答

質問

社内検証・外部検証などはいつやるか?

答え

新機能を出すたびにやります。
ただ、外部監査については定期


講演2つ目

報奨金制度の近況

講演者:オオツカさん(オオツカさん不在のため、1つ目の講演のヤマニシさんが代わりに登壇)

報奨金制度を主に担当している。

2014年に報奨金制度スタート

現在で4年が経った

バグハンター合宿なども実施している。

延べ、240名が参加

年を追うごとに、システムは堅牢になりつつある。

最近、報告件数が減っているので、報奨金を上げている(5倍に上げている)

報告された内容が緊急レベルのものだと、50万くらいもらえる。

報奨金ランキングを見えるようにした。

ハッシュタグ:#CybozuBugBounty

制度の英語化をしている

海外バグハンターへのアピール

脆弱性評価の裏側

着信→受付→評価→クローズ連絡→クローズ

評価の流れ

CVSS V3に基づいて評価→レビュー→社内告知を作成→告知レビュー

今後について

バグハンターにとって魅力的な制度に保つ

質疑応答

質問

脆弱性報告件数が少なくなったなった理由だが、製品が堅牢になったと評価できる?

答え

そう思いたいが、きっとそうではない。
社内検証でもたまに出てくる。
また、報奨金を上げたら報告件数も上がった。

質問

バグの報告があって、クローズまで、平均どのくらい?

答え

最短だと1週間以内。長いと、1ヶ月とかかかる。1ヶ月かかるのはひどい話。

質問

アクティブなバグハンターはどのくらい?

答え

計測していないので分からないが、おそらく直近だと10~20人くらい。


公開された資料