2人目デザイナーの入社前にやったこと

こんにちは、こちらはestieのアドベントカレンダー8日目の記事になります！
担当は、estieでVP of Designをしている荒井（@rakenarai）です！estieではデザイン全般とフロントエンドの一部実装を担当しつつ、最近はデザインチームの構築に注力しています。
趣味はラジオを聞くことで、ハライチのターン！とおぎやはぎのメガネびいきのヘビーリスナーです。ラジオメールを送るレベルで好きです。

私は、2019年3月にestieの1人目デザイナーとして副業として携わり、2020年11月よりフルタイムへ切り替え今に至ります。ヤフー株式会社に新卒で2016年に入社し、estieでフルタイムでジョインするタイミングで退職しました。
estie創業から長きに渡り1人デザイナー体制で必要なデザインタスクに対応してきましたが、サービスとチームの成長もあって限界が見え始めたため、2021年からデザイナー採用を開始しました。その甲斐あって、1名の入社と2名の業務委託が決まり、現在デザイナーチームは4名体制になっております！

今回は2人目デザイナーが入社する前に私が行なったことを4点記したいと思います！

ライセンス契約
ドキュメンテーション
振り返り文化の土壌作り
タスクの見通しが良くなる仕組み作り

ライセンス周り

今年Figmaのプランに一部変更があったので振り返りも兼ねて、まずはそちらに触れておきます。

Figmaのライセンス事情

2021/4/21にFigmaのStarterプランに変更がありました。

↑ 出典：https://help.figma.com/hc/en-us/articles/360061769534-Starter-plan-updates

公式ページでアナウンスされているアップデート内容は要約すると以下のキャプチャの通りと理解しています。FigmaにはDraftsとTeamという概念、Teamが内包するFileという概念、Fileが内包するPageという概念が存在しており、それぞれに新たな制約が加わりました。

↑ FigmaのHOME画面

↑ FigmaのFile内画面

いざプラン変更・ライセンス契約

1人しかいなかったときはUIデザインをする時はFigmaのDraftsにひたすら量産するスタイルで何も不都合はなかったのですが、2人目デザイナーJOINとStarterプランの変更があったのでFigma Professionalに切り替えました。何とかコストかけずにしのぐ方法はないかと考えましたが、結論、無さそうでした笑

先のキャプチャの通り、Drafts量産スタイルでは共同編集ができない問題があり、Starterプランで1チームで運用するにはestieが持つデザインファイルと各ファイルが内包するページ数のそれぞれが上限を上回っていました。

一方、FigmaはUIデザインする上で欠かせないものなので惜しむ気持ちは全く無く、素直にProfessionalに移行しました。

また、estieではUIデザインだけでなくイベント出展する際のパネルやプレスリリース用のバナーをデザインする機会も多いため、PhotoshopとIllustratorも必須ツールです！そのため、Cleative Cloudの新規ライセンス契約も行いました。

初っ端から地味ですが、これらのツールはestieでデザインする上で不可欠なツールなので真っ先に対応したことです！
個人的にはFigmaをStarterからFigma Professionalに切り替える瞬間、慣れないツイートするくらいエモかったです…笑

Figmaの整理

恥ずかしながら、ずっとFigmaのファイルがグチャグチャでした…

Pagesの使い分けも明確なルールがなく、あちこちにUIが散らばっていましたし、何なら本番で動いているけどデザインファイルがないページもありました。

これからチームで働く上でそんな状態ではアカン！と思い、Figmaの整理を空いた時間でちょこちょこ対応しました。Pagesはサービス内のページと対応させて管理しています。まだまだ道半ばではありますが、最低限見通しが立つようにしておきました。

その後、2人目デザイナーのなーさん（@sai_fan_3）が圧倒的に綺麗にし始めてくれていて感謝が止まりません…！

↑ 現在のFigmaの様子

ドキュメンテーション

estieではWikiツールとしてConfluenceを採用しており、プロダクトやチーム単位でスペースを持っています。プロダクトのデザイン関連のドキュメントは該当するプロダクトのスペースに紐づけて管理していたものの、チーム横断で動くPR対応時のデザイン関連のナレッジやこれまでのクリエイティブの集積が全くできていませんでした。

それに対応するため、新たにデザイナー用のConfluenceスペースを作成し、これまで頭の中に溜め込んできた知見を一気に吐き出しました。

会社の方針や勤怠ルール、使用ツールの紹介等を記したオンボーディング記事から、新規名刺の作成方法、コーポレートサイトや会社説明資料の更新方法など、これまで自分だけが理解してよしなに対応してきたもろもろをドキュメント化しました。

デザイナー1人時代は極限まで属人化させることでスピードを出していましたが、チームで働く上でそれの解消に動けたのは良かったかなと思います。また、私のドキュメントでは足りない部分を補う動きをどんどんしてくれており、日々改善されるドキュメントが集まった良いスペースになっているかと思います！これを継続するぞ…！

振り返り文化の土壌作り

知見のドキュメント化と同時に、クリエイティブの集積も仕組み化すべく動き出しました。具体的にはDesignBaseというページの下にプレスリリースやイベントのバナーといったプロダクト開発以外のデザインに関して以下をまとめる運用を始めました！

なぜやったか
なにをやったか
いつやったか
誰がやったか
制作物
参考URL
得られた効果

↑ デザイナー採用資料作成時の例

プロダクト開発のデザイン関連の試行錯誤は該当スペース以下で効果検証等を行うので、それ以外の主にコーポレート系のデザイン関連をまとめています。

DesignBaseの目的は次の2点があります

estieがこれまで世に発信してきたデザインをまとめ、estieらしいクリエイティブを醸成したい
なぜやるかを明確にし、その目的の達成度合いがどうだったか（デザインがどう寄与したか）をデザイナー中心に振り返り、チーム全体で投資したコストに対するリターンを振り返る意識を高めたい

余談ですが、デザインの集積所だからDesignBaseや！と命名したら株式会社ユーザベースのB2B SaaSに特化したデザイン組織の呼称と偶然にも被ってしまいました…笑

タスクの見通しが良くなる仕組み作り

estieではタスク管理ツールとしてJIRAを採用しています。主に開発タスクを管理するためにJIRAを利用することが多いのですが、デザイナーも新たにDesignプロジェクトを作りました！

開発に関するタスクは各プロダクトのJIRAのチケットで管理できていたのですが、開発以外のプレスリリースやイベント出展、コーポレート文脈のデザインタスクの量や進捗はこれまで可視化されておらず、都度都度、追加的に対応してしまっていました。
個人的にもタスク管理ツール使っていなかったので記憶と気合いで頑張る不健全な体制でした…笑

デザイナーの稼働が必要なタスクがあった場合はテンプレートを複製し、テンプレートの項目に沿って「なぜやるか」と「なにやるか」を中心に起案者に記載してもらう運用をスタートしました！