Cloudbase株式会社でデザイナーをしている成塚です。
Cloudbaseのデザインチームは2024年2月現在では、フルタイムメンバーとコラボレーター (業務委託メンバー) を含めて、合計4名のチームとなっております。
私はCloudbaseに1人目のデザイナーとして入社したあと、2022年3月にリリースしたクラウドセキュリティサービス「Cloudbase」のプロダクト開発や、コミュニケーションデザイン、デザイナー採用、デザイン組織立ち上げなどに幅広く取り組んできました。
急拡大するスタートアップで、どのように1人目のデザイナーとして立ち振る舞っていくべきか、私の経験をもとにまとめます。
私はCloudbaseに6人目の社員として入社しました。前述したように、自分が入社するまでは、組織内にデザイナーがいない状態だったので、私が入社するまではCEOがプロダクトの開発とデザインの両方を行っていました。
私がCloudbaseに入社するに至った理由や背景については、こちらに詳しくまとめられています。
Cloudbaseに入社した直後から、Cloudbaseでデザイン組織を立ち上げることが必要だと確信していました。その理由は大きく2つあります。
Cloudbaseは、AWS・Microsoft Azure・Google Cloud などのパブリッククラウド利用時における設定ミスや脆弱性を網羅的に監視・管理できるセキュリティプラットフォームサービスを提供しています。
現在では、スズキ株式会社、出光興産株式会社、パナソニック株式会社、エヌ・ティ・ティ・スマートコネクト株式会社をはじめとした日本のエンタープライズ企業のお客様に導入していただいています。
セキュリティ領域のプロダクトは、機能の数やリスクを検知できる項目のカバー範囲で比較・検討されることが多く、機能は多いが、作業者にとっては使いにくい製品になってしまっているケースが多いです。
そんなセキュリティ領域にプロダクトを提供するうえで、「使いやすさ」「分かりやすさ」を磨くことは、競合製品との大きな差別化要素になり、受注率の向上・チャーンレート低下に大きく影響します。
Cloudbaseでは、プロダクトの使いやすさや分かりやすさが要因となって、お客さまに導入していただいたり、UI/UXの面でポジティブなご意見をいただけることがとても多いです。
そのため、Cloudbaseがデザインを強みにできれば、直接的に事業の成長につながると考えました。
2022年3月のCloudaseベータ版リリース以降、Cloudbaseを導入していただけるお客さまが徐々に増えていき、事業は右肩上がりで成長していきました。
私がフルタイムでジョインした当時は、既存の画面を再設計するところから始めていきました。プロダクトの導線の変更や、基本的なコンポーネントやスタイルの定義など0から行っていきました。
また、シード期では、プロダクト以外にもコミュニケーションデザイン領域でもやらなければいけないことが無数にあり、それぞれのタスクや施策に対して、時間をかけすぎずに高いクオリティのものを作れるように工夫していました。
1人目デザイナーとして、これらのデザイン領域の無数のやるべきことに優先度をつけてスピード重視で取り組みつつ、Cloudbaseがよりデザインを強みにできるようにデザイン組織づくりの取り組みを始めました。
創業メンバーの全員が過去にデザイナーと連携して仕事をした経験がなかったため、社内的にもデザイナーの役割や業務範囲、期待値、どのような体制を作るのがベストかを理解している人はいない状態でした。
そのため、デザイナー1人体制で動いている時は、デザイナーの役割やどんなことに取り組んでいるかを意識的に全社に示しながら、2人目以降のデザイナーが入るための土台づくりや準備に取り組みました。
具体的に行ったことをいくつかまとめていきます。
まず、Cloudbaseのデザイン組織がどのような体制を取るべきかを定めて、経営メンバーと議論をしながら定めていきました。
1人目のタイミングからデザイン組織の体制を決めることが必要だったのは、デザイナーという職種は機能部門をまたがって事業に価値貢献する特殊な職種であるということを非デザイナーである経営陣に伝えるためです。
エンジニアであればCTOレポートラインでプロダクト部門に所属、セールスであればCOOレポートラインでレベニュー部門に所属するなどシンプルですが、デザイナーの場合はプロダクトやレベニュー、コーポレートなど部門を跨って動く必要があります。体制が定まっていない状態でデザイナーを集めてしまうと、組織の中でデザイナーが浮いている状態になり、それぞれのデザイナーのレポートラインや責任・役割が不明瞭になってしまいます。
なので、Cloudbaseのデザイン組織はデザイナーが1 ~ 4名の少人数チームの場合までは「分権的埋め込み型組織」、5人を超えたフェーズで「集権的パートナーシップ型組織」を目指すという体制に定め、下記のように図解をして全社定例の場などで共有しました。（※全社定例の場で共有したものから、資料のデザインはアップデートしています。）
「分権的埋め込み型組織」と「集権的パートナーシップ型組織」の特徴とメリット・デメリットについても下記のようにまとめて共有しています。
さらに、Cloudbaseのデザイナーの体制や役割を定期的に言語化していく目的で、社外向けにも役割を発信する機会を増やしていきました。
社外向けにも発信を増やしたことで、社内外からCloudbaseのデザイン組織の体制や役割に対する理解が深まっているように感じています。
1人目のデザイナーとして最も意識していたのは、最初にデザイナーの役割や立ち回り方、アウトプットのクオリティラインなどの原型となる”型”を作ることでした。
立ち上げ初期は、デザイナーがどのようにプロジェクトメンバーと連携していくのがベストか、どのようなアウトプットが必要なのかは実際に取り組んでみないと分からないことが多いです。
そんな中、自ら取り組まずに、その領域に必要なスキルセットを持ったメンバーを採用して任せるケースもあると思いますが、デザイン領域に関してはそのやり方は上手くいきづらいと考えています。
その主な理由は下記の4つです。
その領域でのデザインによる事例が0の状態だと、専門スキルを持ったデザイナーに興味を持ってもらいづらく、そもそも採用することが困難であること
プロジェクトメンバーとの関わり方やデザイナーの責任範囲や役割が明確になっていない状態で、デザイナーを採用すると、アサイン後立ち上がりに大きな時間がかかってしまう。
必要なスキルセットや役割が明確になっていないため、採用ミスに繋がりやすく、会社側と候補者側の両方で不幸が生まれやすい。早期離職に繋がってしまう。
特定の専門スキルを持ったデザイナーを採用することへの、経営陣からの理解と承認が取りづらい。（自ら取り組んでその領域で実績を出し、信頼を勝ち取った後なら経営陣もイメージしやすく、承認が取りやすい）
なので、まず自らでその領域に取り組み土台を作る、その領域に必要なスキルセット、適任なデザイナー像の解像度が上がったタイミングで任せられるデザイナーを採用する、手離れして空いたリソースでまた次の領域へと進んでいく...というのがデザイン組織立ち上げの理想的な流れだと考えています。
自ら先陣を切って、こうすればうまくいくという”型”を見つけ、そこを任せ、また次の領域へ...と続けていく
具体的には、私はデザイナー1人の状態の時には、プロダクト側の既存画面の改善と新機能の開発をメインで担うようにしていました。
セキュリティ領域のドメインはデザイナーにとっては理解しづらい部分が多いため、コラボレーターメンバー(業務委託)にタスクを切り出して依頼することは、依頼コストやレビューコストがかかるため難しく、1人目のフルタイムメンバーとして自ら手を動かし続け、土台を整えていく必要がありました。
自分の運用のしやすさだけを考えるのではなく、2人目が入ったあとに任せていくことを見越して、下記の内容も意識的に行っていました。
マスターファイルの更新
コンポーネントやスタイルなどをまとめたデザインシステムページの作成
Notionのデザインタスクボードの作成
Figmaのファイル管理ルールを定め、適切に運用
当時はMaster、 Design System、 Draftの3つの最小限のファイルで運用していました。
2人目が入ってからスムーズに任せられるように、コンポーネントやスタイルを丁寧に作り込んでいた
また、体験設計についてもプロダクトチームで共通認識を作る目的で、Cloudbaseのペルソナや、リーンキャンバスを作りチームに共有しました。他にも、コラボレーターメンバーにCloudbaseのプロダクトや事業についてのキャッチアップをしてもらう際にも共有しています。
このシートは定期的に見直し、アップデートを行う予定です。また、今後ユーザータイプ別のカスタマージャーニーマップも制作する予定です。
ある程度、プロダクトデザインについての動きや役割、他職種との連携の仕方などが整ってきたところで、できるようになった部分を他の人に任せていくための投資も行っていきます。
その一環として、デザイン組織としてのロードマップを設計しました。（2023年4月当時に作成したものからデザインはアップデートを行っています）
この段階で、2人目のデザイナーとして、私がメインで担っていたプロダクトデザインを担える人を採用することを決めています。
さらに、プロダクトデザインや、採用活動に集中していけるよう、下記のようなタスクは一度デザインを作った後は、テンプレート化や依頼から制作までのプロセスを定めて、コラボレーターメンバーの方でも行える体制を作りました。
名刺のデータ作成と発注
新メンバーのバーチャル背景の作成
イベント等で使用するノベルティの作成と発注
インタビュー記事のバナー作成
上記のような一度デザインを作った後に、繰り返し依頼が発生するものに関しては、コラボレーターメンバーの力を借りて、出来るだけ自分で手を動かさないような工夫をしていました。
デザイナー社員2人体制になった時に意識したのは、すでに整いつつある領域は任せ、デザイン組織としてできることを広げていくということです。
2人目のデザイナーとして入社したHeyさんには、今まで私が担っていた、アプリケーションチーム（ソフトウェアエンジニア・PdM・デザイナーが所属する機能系のプロダクト開発を行うチーム）のプロダクトのデザイン業務を完全にお任せしています。
ジョインして直ぐに100%任せるというわけではなく、徐々にプロダクトデザイン側の工数を減らしていき、様子を見ながら任せていきました。Heyさんは業務委託時代からCloudbaseに関わってくださっていたこともあり、大きな障壁もなく安心してお任せできました。
私が、プロダクトデザイン、コミュニケーションデザイン、デザイナー採用などを全部1人でやっていた時は、他の案件や施策がブロッカーになり、プロダクトデザインの進行が遅れることがありましたが、専任のプロダクトデザイナーをアプリケーションチームにアサインしたことにより、それがほとんどなくなり、より開発速度が向上しました。
また、HeyさんにはUIデザインの他にリリースノートや仕様書の作成、CSと連携してお客様に機能説明を行うなど、プロダクトデザイナーとして関わる領域を広げて活躍してくれています。
2人目デザイナーのHeyさんに今まで私が担っていたプロダクトデザインの領域をバトンタッチすることができたタイミングで、デザイナー採用やコミュニケーションデザインなど、これまで優先度を落としていた領域に注力し始めました。
ここでも、まず自分がその領域を開拓し、土台となる”型”を作り、次のメンバーにバトンタッチしていくためにクオリティに妥協をせず事例を増やしていきました。
コミュニケーションデザイナーの活動範囲を社外に示すためにも、直接的な事業成果には繋がらないが、オリジナルIPAビールをCTOと一緒にラベルから自作して制作。
コミュニケーションデザイン領域は、事業ドメインや会社によって関わる範囲や求められるアウトプットのレベルは様々です。なので、社外の方がCloudbaseのコミュニケーションデザイナー職に対して、興味を持ってもらえるように、社外向けに公開するクリエイティブに関しては全て妥協せずに制作し、出来るだけアウトプットのレベルを落とさないよう意識しています。
最初に妥協をして、クリエイティブのレベルを落として社外に公開してしまうと、将来的にコミュニケーションデザイナーの採用に苦戦すると予測しました。アウトプットの低いデザインを許容する会社として、社外から認知されますし、一度下げたアウトプットのレベルは後から上げにくいという理由からです。
なので、記念品として作成したビールのラベルのデザインやオフィス移転パーティのOGPなど、一時的にしか使わないデザインに関してもそれなりの時間をかけて制作をしました。
また、Cloudbaseが求めるアウトプットのレベルやデザインの方向性などを社外に発信することにも繋がるので、Cloudbaseが求めるクリエイティブを得意とするコミュニケーションデザイナーを採用しやすくなるメリットがあります。
結果として、Cloudbaseでは1年半ほどでデザイン組織に対する信頼が、社内外ともに生まれるようになってきました。
前述したように、お客さまからも「使いやすさ」や「分かりやすさ」が理由となってCloudbaseを導入されることが増えています。
また、社内のメンバーからもデザインチームの取り組みに対して下記の画像のようなコメントをいただいています。Cloudbaseにはwaiwaiチャンネルというメンバーへ賞賛を送るチャンネルがあり、そこでいただいたコメントを抜粋しています。
前述したように、Cloudbaseにはデザインの力が不可欠で、そのためにデザイン組織を作ることはマストだと考えています。私が、1人目のデザイナーとしてCloudbaseにジョインしてからは、どのようにして、それを社内外に伝えデザイン組織を作っていくかを考えていました。
私が一番意識したのは、1人目デザイナーとしてまず先陣を切り、失敗や成功を経験しながら地道に正解を見つけにいくことです。デザイン組織立ち上げの初期フェーズはそのような地道な取り組みで、将来的に組織を拡大できるかどうかや、社内外への認知や信頼などに大きな差が生まれると思っています。
これからも、まずは自身で道を切り開き、新しく入ったメンバーにその道を譲り、自分はまた別の道を開拓していく動きを意識して動いていきたいと思います。
また、これからCloudbaseにジョインする方も同じように、新しく入ったメンバーに道を譲り、その方が最大限パフォーマンスを発揮し、組織全体で成長できるようにと考えられる方にジョインしてもらいたいと思っています。
最終的にデザイン組織の介在価値を広げていき、デザインの力で事業を後押しする存在にできたらと思っています。
