ことの経緯

「がっくん、リーダーやらない？」

当時、自分をいれて6人のデザインチームに所属していました。そこでデザインディレクターとして配属して半年ほどした頃、現場のリーダーから急なお話がありました。妊娠を機に休職に入られるため、 デザインチームのディレクターとして、リーダーも兼任して欲しいとのことでした。当時、初めてのディレクターとしての業務に邁進していた私は、正直言うと、プレッシャーをとても感じていました。なぜかというと、 その頃のデザインチームはチームとして課題がまだまだ山積みだったからです。

ディレクターとして、デザインチームのアウトプットを向上するだけでなく、それに加えて、チームのマネージメントをしていく という事は、当時の自分にとっては、実際どういう事なのか未だわかっていませんでした。それでも、元来、なんでもチャレンジしてみる！という性格のため、やります！と、ふたつ返事で承諾しました。

取り組んだこと①

前提の整理

まず、デザインチームには前述した通り、課題が山積していました。離任前のリーダーは、デザイナーやディレクターの経験がないエンジニアだったため、チームの管理のみで、具体的なデザイン面の課題にはアプローチ出来ていませんでした。課題を列挙すると以下の様なことがありました。

デザインチームのメンバーの教育もしながら、これらをクリアにしていかない限りは、チームとして正常に機能が果たせないと思い、まず、ひとつずつ課題を解決していくことにしました。

取り組んだこと②

・デザイナーにチームで動いていることを認識してもらう

まず、チームのタスクを全員が把握すること、自分の持っているタスクについて責任を持ってもらうための試みをしました。
チームはシングルプレイヤーの集合体ではなく、全体で課題を解決する組織でないといけないはずです。
 当時は、自分の今日やることを簡単に説明するだけで終わっていましたが、以下の様にフォーマットを作って、Teamsのチャンネルにそれぞれのタスクを、着手中・確認待ち・FIXのどのステータスなのか明確にしてもらい、出席するMTGも記載してもらいました。

タスクマネージャーはDevopsを使っていましたが、新規のタスクや更新のあったものを私が読み上げて、全員に認識してもらうことでタスク忘れを防止するのと同時に、自分が担当しているタスクだけではなく、チームとしてタスク全体を消化していかなければならないと言うことを再認識してもらいました。 また、体調によってパフォーマンスの落ちてしまうメンバーもいたので、絵文字で今日の気分を言ってもらうなどの工夫をし、タスク量をコントロールすることにしました。 当たり前のことかもしれませんが、まずここからスタートしようと思いました。

・チケットには必ず進捗があったら記載。要件は必ず

次に徹底したのは、要件、修正指示、タスクの進捗フローを必ずチケットに記載してもらうことです。POBAやエンジニアからの修正指示もTeamsなどのコミュニケーションツールで来たとしても、それぞれの担当のデザイナーに必ずチケットにも流れを記載してもらうことにしました。これによってタスク担当の属人化を防ぎ、担当のデザイナーが休みでも対応を可能にしました。また、タスク期限の延長や忘れをなくし、担当のデザイナーに小さなタスクでも責任を持って対応してもらえる様になりました。

・それぞれが何をしているのか、それぞれのメンバーが把握していなかった。

・タスクの忘れや、期限延長が多発していた。

の課題を解決しました。

取り組んだこと②

・明確な意思決定をするためにレビューをするときの観点を決めた

配属されていた企業では、UI/UXを重要視していました。UXの実現には一つの機能、簡単なデザイン修正でも、できるだけ多くの人数で考えるのが一番大事なことだと思っていました。 なぜならば、ユーザーはデザイナーやそれに関わるメンバーの何百倍もいるからです。そのためまずチームでのデザインレビューの時間を2倍に増やしました。

最終決定はディレクターの私がしますが、どのアウトプットでも全員の目を通して、デザインチーム全体で出来るだけ納得した物だけをアウトプットとして提出したい、そんな思いがありました。そのために、デザインレビューを効率的に行う必要がありましたし、いつまでも会議が長引いてしまう状態も同時に改善する必要がありました。レビューする際に以下の観点でそれぞれレビューしてもらう様にしました。

四原則は基本のキなので、出来ているメンバーも多かったのですが、文脈と要素の優先順位に関しては、経験者でもデザインをみる観点として持っていないメンバーが多い状態でした。要素のグループごとの優先順位、更にグループの中の細かな優先順位まで、とにかく優先順位を全ての要素につけてデザインを見ること、上から読んだ時に、人に伝える時に正しい文脈なのか、そもそもそれは伝わっているのかなど、観点ごとにレビューをしてもらうことにしました。また、私も含めて、それを聞いた若手のメンバーが成長できる様に、レビューの意見を出す時は感想で終わらず、必ず理由まで話してもらうことにしました。

・デザインレビューをするときの心構えやルールを決めた

デザインレビューに対して、全員の認識を同じにする必要も同時にありました。特に、他の人に自分のアウトプットに真逆なコメントをされると自信をなくしてしまったり、消極的になってしまうメンバーもいたからです。デザインレビューは否定し合う会ではないし、アウトプットは自分の化身ではなく、会社の資産です。そのことを理解していないと、いつまでもデザインがユーザーに向かないと考え、チームの振り返りの時間やコミュニケーションを取れる場所で、そのことを繰り返し説明し、そのマインドとルールを浸透させることにしました。 


また、良いアイデアはデザイナーのクラスに関係なく素直に受け入れて欲しいことも話しました。作った人がシニアデザイナーか、ジュニアデザイナーか、ディレクターなのかはユーザーには関係ありません。大事なのは、デザインがユーザーにとって、わかりやすく、効果的なことです。これはディレクターである私も率先しており、新卒のメンバーからの意見でも、自分のアイデアより有効だと思う場合は、当然、そちらを採用しました。そうすることで、キャリアの短いメンバーにも積極的にレビューで発言してもらえました。 


加えて、デザインはユーザーにだけ向いていればいいわけではなく、他のデザイナーや、POBA、エンジニアに対してもわかりやすいものでなければいけません。そのため、人にデザインデータを見せる時は、デザインデータ全体を整理して、”初めて見た人でも伝わる状態、わかりやすい状態”にしてもらう様にお願いしていました。

以上の方法で、

・デザインレビューをしていても、各々の感想を言いあうだけで終わっていた。最終決定を指揮するメンバーがいなかった。

・新卒のメンバー含めて経歴的にキャリアの浅いメンバーが多かった。レビューでの発言も少なかった。

の課題を解決しました。

問題の発生

・厳しいと言われてしまった

デザインチームのリーダーになってから、半年ほど経った時に、思ってもなかった事が起こりました。常駐先の会社の上長から、社員メンバーから私が厳しいと感じるとクレームが入っているとのことでした。当時、メンバーの中には、キャリア的には短くないものの、figmaなどのツールが使い方が1年経過しても十分ではなかったり、ケアレスミスが多かったり、デザインのアウトプットのクオリティも低いメンバーがいました。そのメンバーに対して、学習できるサイトを教えて、ツールの使い方を学んできて欲しいことを伝えたり、指示漏れが発生しない様にメモをとることを伝えたり、ケアレスミスが発生した時に、注意することが度々ありました。 


その当時は、自分としては正しいことをしているつもりでした。”出来なければ、できる様にしてくるのが当たり前”そんな考えが自分の中にあったからです。というのも、業務委託と言う契約上、高いパフォーマンスを維持しいなければ、契約を切られてしまう環境にいたため、それが当然の環境にいたからです。しかし、これは大きな間違いであったと今では思います。

・リーダーとは何か。それを今一度考え直した。

そんな状況で悶々と悩んでいた時に、自社の同期にその話を相談する機会がありました。その時にもらった言葉が考えを改めるきっかけになりました。「今は出来る人じゃなくて、出来ない人に合わせる時代でもある。」そんな言葉をもらいました。これは皮肉ではなく、実際に今の時代にあった考え方だと思いました。出来る人に合わせるならば、実際にそのチームの一番できる人に合わせればいいのかもしれませんが、それでは付いて来れるメンバーしか残らなくなります。

デザインチームは一つのチーム、全員で課題をデザインの力で解決していく組織です。どのメンバーも大切な組織の一員であり、リーダーと言うのは、その組織を力で動かすのではなく、導くための工夫や知恵を出すことを求められているんだと、自分の中で考えを改めることが出来ました。
その思考にたどり着いてから、窮屈な思いをさせてしまったメンバーと話合い、謝罪しました。
そしてチームを導くために下記のことを実践しました、

まず、ありがとうをメンバーに沢山伝える様にしました。任せていたことを終わらせてくれた時、MTGの終わりにも、必ず、ありがとうを伝えました。そうすると、メンバー同士でも、ありがとうを言い合う文化が自ずと出来、チームの雰囲気がさらに良くなりました。

ミスがあっても、”注意してください”とただ言うのではなく、”次は〜するといいかもしれません！一緒に頑張りましょう！”など、否定ではなく、肯定の言い方に変えました。タスクの割り振りもメンバーの得意不得意を把握して、得意なことを出来るだけ、得意な人にやってもらう様にしました。

それによって、デザインレビューでも自信のあるアウトプットを各メンバー出せる様になり、一つのタスクに対して、それがスキル的に得意な人と苦手な人をセットでアサインすることによって、スキルを教え合う環境も作ることが出来ました。

・本当の意味で”チームを率いるには優しさが必要”という事を学びました。

取り組んだこと③

・小さく貢献して、大きな成果を出す

当時のデザインチームはエンジニアチームとのコミュニケーションが上手くいっていませんでした。と言うのも、エンジニアにとって完全性のないデザインを提出していたり、デザインシステムで新しく定義したデザインを実装に取り込んでもらうために、デザインチームからエンジニアチームへの要求ばかり多くなっている状態でした。また、他の部署にも、デザインチームの存在や活動が上手く伝わっておらず、デザインチームのタスクは、アプリの継続的改善のみに限定されていました。そのため以下の事を実施しました。

まず、すぐに出来ることとして、デザインデータをエンジニアにとって完全性の高いものにする必要がありました。私が参画前のデザインチームのデザインデータには、UIスタック(コンポーネントの状態変化)が用意されていなかったり、デザインの仕様(端末幅が変わった時に要素が横に伸びるか、端末縦幅が広い時に上下に固定になる要素があるか等)に関して、エンジニアがわかる状態になっていませんでした。 これでは、エンジニアがデザイナーに問い合わせることが多く、ストレスを与えてしまいます。UIスタックの問題に関しては、デザインシステムにそれぞれのコンポーネントの状態変化を用意し、それを参照してもらうことで解決しました。 デザインの仕様部分に関してはfigmaのコメント機能を利用して、必ず担当のエンジニアさんにお知らせするようにしました。



しかし、ただ、デザインデータの完全性を上げるだけでは、エンジニアとのコミュニケーション取るには、十分ではありません。 
そこで、エンジニアと隔週でデザイン定例を設けることにしました。この定例では、デザインチームからエンジニアに取り入れて欲しい事を要求するのではなく、エンジニアが今デザインで困っていること、エンジニアからのデザインへの要求を吸い上げる ために時間を使いました。こうする事によって、デザイナーがまずエンジニアのパートナーになることを目指しました。まず、こちらが要求する事を取り入れてもらうには、デザイナーがエンジニアからの信頼を勝ち得ること、エンジニアとデザイナーが一 つのプロダクトを良くするために協業する共同体として認識が必要だからです。まず、相手の要求を聞いて、小さく貢献する事を繰り返すことで、信頼を勝ち得て、徐々にこちらの提案や要求を聞いてもらう様にする。こうすること、デザインと実装の差異を徐々に取り込んでもらう流れが出来ました。

上記の考え方は、エンジニアに対してだけでなく、他部署に対しても行っていきました。デザインチームのプレゼンスを高めるために、他部署にロゴの提案をしたり、時には紙媒体の依頼など、幅広く、出来る事をどんどん提案し、実行していきました。その結果として、デザインチームは組織の中で認識され、大きく評価を得ることができ、依頼されるタスクの幅も増えたため、当初6人だったメンバーも8人まで拡大することが出来ました。

振り返り

初めてチームのリーダー兼、ディレクターを任されて約1.5年ほど経験して感じたのは、実際にやってみると当然、一筋縄では行かず、苦悩の連続だったことです。しかし、その中でやはり仕事というのは人と人とのつながりだと再認識しました。どんな時も素直に柔軟に、人と接して、その経験値を持って人を導いていくことは、とても素敵な仕事であり、やりがいをすごく感じていますし、目に見える部分でなくとも、チームの課題を解決していくこともまた、デザインなのだと思い知りました。これからも、誰かを導けるリーダーであり続けたいと、改めて思いました。

最後にですが、今回の転職活動のため、職場を離れることになった時、チームメンバー全員からメッセージを頂きました。リーダーとして完璧ではなかったかもしれませんが、自分がメンバーに伝えてきたことが、どれも伝わっていたと確信できる内容で、このチームで本気でデザインに向き合ってこれたこと、この経験が出来たことは本当に幸運だなと思いました。もらったメッセージは、ずっと宝物です。以下、メンバー7名からのメッセージを紹介します。