スリーシェイクで非公式オンスクリーンプロダクトデザイナーをしているたふみです！

「デザインチーム（？）」「非公式」…？🤔 一体どういうことでしょう？
曖昧な書き方をしているのは、どれもスリーシェイクの組織体制上に正式に存在するものではないからです。

そう、今回は存在しないデザインチームの紹介をしにきました！

• デザイナーの採用がうまくいかない中でデザインと向き合わなければいけない時

• 組織体制の枠組みを超えた活動が必要な時

上記のような課題を抱えているチームには参考になるかもしれません。1人目デザイナーのそこのあなた、ぜひ最後までお付き合いください！

株式会社スリーシェイクについて

「インフラをシンプルにしてイノベーションが起こりやすい世界を作る」をテーマに、社会に蔓延る労苦〈Toil〉をなくすため日々奮闘しています。
事業としては、SRE (Site Reliability Engineering) の支援事業を核として、その周囲で主にエンジニアリング領域におけるToilをなくすサービスを展開しています。

デザイナーが直接関わるプロダクト（一部）

• Securify Webアプリケーション診断
  URLを入力するだけでセキュリティ診断ができるプロダクト

• Securify SaaS診断
  使っているSaaSで危険な設定や権限がないかを診断するプロダクト

• Relance
  フリーランスエンジニアに「今よりいい案件」を紹介するサービスの社内向け人材・案件管理プロダクト

デザインチーム（？）について

※ 以下は2024年5月時点での話です

正社員プロダクトデザイナーは驚異の「0人」

現在スリーシェイクには正社員ではコミュニケーションデザイナーが1人（全社員120人超え）しかいません。プロダクトデザイナーに至っては0人😱です。
じゃあこの記事を書いている人は、という話になりますが、私は正式にはRelance事業部のエンジニアインターンです（とはいえ実態としては業務時間のほとんどがプロダクトデザイン業です！）
つまり、業務委託やインターンで大枠のプロダクトのデザインを回しています。
現在は私ともう1人の2人体制で、複数のプロダクトを支え…きれていませんが😂、なんとかやっています。

デザインチーム（？）の正体

この体制だと、次のことが必然になります。

• 1人のプロダクトデザイナーが複数のプロダクトを横断してデザインする

• プロダクトデザイナー以外がプロダクトのデザインをする

ただ、私はこれが悪いとは決して思っておらず、デザイン組織づくりの成功と紙一重であると捉えています。
仮に100人のプロダクトデザイナーを抱えていたとしても、私はこの2つを目指すと思います。デザインは具体と抽象の反復横飛びであり、「デザイナーだけに任せるには重要すぎる」ので。

今はプロダクトデザインに関わる (関われる) エンジニア等を巻き込んでデザインチームとして社内で暗躍しています。
いわば組織自体が密造酒であり、これがデザインチーム（？）の正体です。

ここで少し私信を挟みます。
インターンという立場上、普段は組織体制やスキルエリアには口を出しづらい（しかしプロダクトには組織体制がじわっと染み出るので実は重要😇）のですが、いい機会なので…😂（社内の人間関係は超良好なので安心してください！！）

私は今後、スリーシェイクは総プロダクトデザイナー化を目指すべきだと思っています。
言い換えれば「さらば全てのプロダクトデザイナー」です（全てというのは何も言っていないのと同義である、と同じ話です。むしろ0人なので一周回って既に理想に近いです😂）

スリーシェイクの無意識的な強みとして、プロダクトのドメイン知識がエンジニア向けに偏っていることがあります。これはデザイナーの採用が難しい理由にもなってしまっていますが、つまり社内のエンジニアは既に深いドメイン知識があり、あとはプロダクトデザインの一般的な知識さえあれば… あれば…

プロダクトデザイナー以外がプロダクトデザインをするために

スリーシェイクのデザインシステム「For Design System」

ここで登場するのがデザインシステム「For Design System」です。
デザインシステムには様々な定義がありますが、スリーシェイクではプロダクトデザインを誰でも高速に行うための一般工具箱と見ています。
詳しくはまた別の記事で説明したいと思いますが、一般的なデザインシステムから見るとかなり狭い定義です。目標はプロダクトの道具として信頼性を高めることにあります。

……誤解を恐れずに言うと、コンポーネントとデザイントークンを用いてプロダクトデザインをある程度それっぽく簡単に行えることを重要視していて、逆にスリーシェイクらしさはできる限り削ぎ落としています（この観点とリソースの問題でコミュニケーションデザイン周りはごっそりFor Design Systemの範疇からは外れています）。
そもそもFor Design Systemはプロダクト群が個別に持つデザイン基盤の上にある存在 (コンポーネント等もコンポーネントフレームワークと呼んでいるぐらい) で、スリーシェイクらしさを担保というより、一般的なプロダクトデザインの品質やアクセシビリティの担保が目的です。

またプロダクトごとにモデリングや施策の管理等を模索しています。ここらへんはぜひ別の機会に書きたいと思っています。

デザインチーム（？）として発信していきたいこと

ここまで読んでいただきありがとうございます。
今後、スリーシェイクのデザインチームでは内外ともに取り組みの認知度を上げていきたいと考えていて、今回からnoteを書くことになりました。

• 整理・展開・実装しやすいFigmaデータの作り方

• For Design System設計の舞台裏

• UIのモデリング手法

今後、こんな記事を書いていく予定ですので、ぜひ気になる方はマガジンをフォローしてお待ちください！