スタートアップの成長とそれに伴うデザイナー組織の変遷

チームとしての形はなく個々が何でもやる

ペライチに参加した当初、私はフリーランスとして働いていたので業務委託として関わり始めました。
それまでにスタートアップで働いた経験はなく、またチーム開発の経験も殆どなかったので、サービス開発の手法や、チームでの開発などを学びながら手を動かしていました。

私の入る少し前に今までペライチに関わっていたデザイナーが抜けてしまったので、この時期はメインで働くデザイナーは私１人で、他にスポットで手伝ってくれるフリーランスのデザイナーの方が数人いました。
とにかく人手が足りないので、デザイナーという枠組みでしたができることは何でもやりました。
プロダクトのUI、サービスのwebページ作成、ペライチテンプレートの作成、印刷物・ノベルティの作成といった一般的なデザイン業務の範疇はもちろん、JavaScriptなども書いて小さな機能実装もしていました。明確なプロジェクトという単位はなく、デザインや開発は個々人で進めて、自分だけでは解決できないところは誰かの助けを借りていました。プロダクトもまだ未熟でソリューションフィットなども探っていた時期なので、とにかく世の中に早く届けることを優先してスピード感をもって進められる力が求められてました。

一方で、細部のデザインやUIなどは手が回らないこともあり、エンジニアの方ができる範囲で対応し、最低限のクリエイティブチェックで進めてました。ここは後々負債として残ってしまってます。

分業の体制ができ上がる

資金ができたので人を増やすことができるようになりました。このタイミングで私もフリーランスの業務委託から、正社員として働くことになります。
デザイナーはスポットではなく長期的に働いてくれるフリーランスの方に業務委託で入ってもらいました。理想は週4以上働いて欲しいところですが、即戦力の人を求めており、そのようなスキルのある人は大抵多忙なので、週2、3程度と稼働日数は少なめでした。

この頃はまだデザインチームはチームという感じではなく、基本的には業務委託のデザイナーの方には私が仕事を振ってましたが、個人の裁量で動いてもらうことも多かったです。マネジメントの意識も希釈で、個人で動くフリーランスの集まりといった感じです。

またエンジニアも増えてきたので、作業の分業が明確になってきました。例えばJavaScriptなどはフロントエンドエンジニアの範疇となり、私が書くことはめっきり減りました。その代わりよりデザインを見れるようになり、機能開発のサブプロジェクトもエンジニア+デザイナーで取り組めるようになりました。

関わる人が増えてきたので、コーディングルールなどを整えようとしましたが、機能開発、改善などの優先的なタスクに追われ、形骸化してしまいました。
最低限、現在のテイストやルールを加味してもらいながら進めてもらってましたが、細かいところで独自の判断となってたので、全体のクオリティにバラつきが生じるケースがでてきました。

デザインチームとしての体制づくり

業務委託のデザイナーの方が離れたり、一方で施策も次々増える中、デザイナーの数が足りなくなってきました。ペライチはページ作成に使うテンプレート作成もデザイナーの業務なので、他社よりもデザイナーの仕事は多めです。
一時しのぎ的な採用では会社の文化が根付きにくいと言うのもあり長く働ける方を探すようにしました。
即戦力の社員が採れれば理想なのですが、そこは簡単にはいきません。多少の作業時間を削っても育てていくことも視野に入れ、結果的にデザイナーのアルバイトが数人増えました。

今までデザイナーはそれぞれがバラバラに働いてるイメージだったのですが、この頃からチームづくりを意識しだしました。
1on1もこの頃から始めました。立場的に私は1on1される側とする側両方になるのですが、まずはされる側の経験を元に手探りで始めました。
最近は現場未経験のアルバイトが増えましたので、教育にも力を入れ始めました。1on1もコーチング、ティーチングなど相手のスキルやフェーズに応じて、やり方を変えたり工夫してます。

この頃から隔週でデザインチームでの勉強会も始めました。最初は各々の知ってること学んだことを発表する会にしてましたが、準備の負担の大きさやスキルレベルの差を吸収できなかった（スキル弱者がスキル強者の前での発表をためらう）ことなどにより一時期休止になりました。
その後、デザイン共有会という名前に変更して、各々の成果物をレビューしあったり、気付きや、疑問を聞く場に変更し、今も継続して開催してます。

会社視点でのチームとしては、小規模な機能開発・機能改善するチーム、グロースハックチーム、新規プロジェクト開発チームの3本が走っていて、縦割となってます。十分なリソースがある訳ではないので、私自身も8割は手を動かしています。

デザインチームの変革

縦軸のチーム体制はうまく回るようになりましたが、一方でそれぞれのデザイナーが何をやってるのか見えなくなってきました。また横断的に見る体制がないので、全体を通したUXや細かなデザインの差異を見れていないという感覚があります。
根底には「良いプロダクトを作りたい、世の中に価値を届けたい」という想いはありますが、今まではビジネス的な価値を優先していた為プロダクトの品質がおざなりになってる部分があります。
グロースハック施策で局所的なUI改善で数値が改善することはありますが、細かい改善の積み重ねで全体的なプロダクトの満足度を上げることは、数値として現れるには時間がかかり長期的な視点での改善となります。そこが着手できてないと感じており、ちょうどその時期に深津さんの記事を見て自分が抱えてたものが腹に落ちました。
決して止まらないカイゼン体制を作りたい｜深津 貴之 (fladdict)｜note
また時期同じくして、経営陣もプロダクトの課題を改めて認識するきっかけがありました。

全体を通したUXの改善など横断して動ける体制を作っていきたいと考えてます。ここはデザイナーが音頭を取って進めていくべきところだと思います。今は体制や時期的な要因もありすぐにそこに大量のリソースを避けるわけではないですが、まずやれることとしてデザインガイドラインの作成に取り掛かってます。

また会社のメンバー数も増えて、メディア運営や、マーケティング、営業などでクリエイティブが必要となるケースが増えてきました。今の人数で全てのクリエイティブをデザイナー一手に引き受けるとタスク量が爆発的に増え、優先すべきタスクも進まなくなりますし、ボトルネックにもなりかねません。なのでごく簡単なクリエイティブはそれぞれのチームで作れるようになって欲しいと考え、手始めとして社内向けのデザイン勉強会を開催しました。次回はHTML/CSS勉強会も開催します。こちらは勉強も兼ねてアルバイト主導で進めてます。

組織の中でのデザインチームの関わり方は、横軸か縦軸かという議論があります。他のチームにも関わるので単独では決められませんが、ペライチでは縦軸と横軸のハイブリットがうまくハマるのではと考えています。最近手に取ったこの本にもヒントが詰まっていたので、書籍や他社事例を参考に少しずつ改変に取り組んで行こうとしてます。

デザイン組織のつくりかた デザイン思考を駆動させるインハウスチームの構築＆運用ガイド

終わりに

その時その時で、ベストな方法を考えて働き方を変えてきましたが、もっとうまくできたな、とか、もっと早くああしてれば良かったのかな、と思うこともあります。
会社の方針や、フェーズ、組織体制によって最適な形は変わると思います。なので、こうするのがベストと一概には言えませんが、この私の経験が誰かの参考になれば幸いです。