グローバルチーム、立ち上げ1年目の振り返り
この記事はfreee Designers Advent Calendar2日目の記事です。
こんにちは、はるたんです。社内バリスタをしつつ、グローバルデザインチームのDesign Leadを担当しています。チームのWeekly MTGでは、オフィスのキッチンでコーヒーを同僚に振る舞ったりしています。
この記事ではグローバルチームの1年間の振り返りを紹介します。
※freeeは今年の1月にグローバルチームを立ち上げました。チーム立ち上げの話に関しては以前記事を書いています。
2022年12月現在、freeeのグローバルチームでは日本のスモールビジネス向けにいくつかのプロダクトの開発を担当しており、既存プロダクトの改善を担当しているチームもあれば、グローバルチームだけで新規のプロダクト開発を担当しているチームもあります。
グローバルチームはフィリピン拠点と日本拠点に在籍するメンバーから構成されています。東京オフィスに在籍している外国人のエンジニアもいれば、フィリピンオフィスに在籍している日本人のエンジニアもいます。現状、デザイナーとプロダクトマネージャーは日本人のみですが、プロジェクトマネージャー、QA、エンジニアは外国人なので、開発に関するコミュニケーションは全て英語で行われています。
デザイナーの僕も毎日何かしら開発チームと話す機会はあるので、1年前と比べると英語でのコミュニケーションは不安なく行えるようになってきました。3年前にIELTSを受けるために死ぬ気で英語を勉強していた時期がありますが、その時よりも実務で英語を使うようになった今の方が飛躍的に英語力の伸びを実感しています。
グローバルチームで目指していること
僕がグローバル開発に参加した理由の1つでもありますが、多国籍チームの強みはそれぞれのバックグラウンドの違いだと思ってます。バックグラウンドの違いは、時に仕事を進めづらい部分もあると思いますが、その違いを活かすことで偉大なチームが作れると信じてます。
認識のズレを捉え、抽象的な概念を可視化し、議論を活性化させることがデザイナーの強みの一つでもあると思うし、このチームでやっていきたいことの1つでもあります。日本のメンバーで考えたことを実装してもらうではなく、メンバー全員が自ら検証・改善のサイクルを回せるチームづくりに貢献したいです。
freeeのグローバル開発チームを「マジ価値のために自ら検証・改善のサイクルを回すことができている」という状態にしていくために、いくつかのことに挑戦してみました。
認識の齟齬が起きづらい仕様書作り
「メンバー全員が自ら検証・改善のサイクルを回せるチームづくりに貢献したい」と意気込みつつも、グローバルチーム立ち上げ当初はfreeeのプロダクト開発に慣れてもらうことを目指しました。仕様書が確定する前の段階からエンジニアをいきなり巻き込んでも良いとは思いますが、まずは決まった仕様を認識齟齬なく伝えていくことに集中しました。僕がデザイナーとして取り組んだのは丁寧な仕様書作りで、以下の観点を意識した仕様書を作成しました。
仕様書内で頻繁に使う用語や認識ずれが起きると困るので、用語説明のセクションを作って、用語に関連する画像とともに説明を書く。
要件を描くときもデザインのスクショとともに対応表を作って書いていく
使う用語はできるだけ普段からエンジニアが使う用語を意識して使う
プロダクトの機能名であれば、現状拡張機能のGoogle翻訳機能を使って理解していると聞いたので、Google翻訳を使って訳された用語を使うようにしている。
イケてる設計資料を作成する
イケてる設計資料につていは、去年のアドベントカレンダーで同僚のデザイナーが紹介しています。
日本語がわからないエンジニア向けに要件とFigmaのデザインの対応表を用意する必要があったんですが、それ以外の観点は英語を使うことによって問題が表面化しやすくなっただけで、日本語で行うプロダクト開発の時でもチーム内での認識を揃えていくために大事な観点だな、とは感じました。
ユーザーの声を届け続ける
開発メンバーの大半はフィリピンにいるので、日本の市場向けにプロダクトを作っているとプロダクトの目的やユーザー理解に関して、日本のチームだけで開発するよりもギャップは大きくなりやすかったと感じています。要件を固めたものを実装してもらうだけでは大きな問題は起きないと思いますが、マジ価値を届け切るためにはデザイナーやプロダクトマネージャーが想定している解決策だけではなく、エンジニアの視点も重要になってくるので、開発に関わる全ての人とユーザー理解を深めていくための取り組みを実施しました。
デザインチームでは、定期的にユーザーインタビューをおこなったり、カスタマーサクセスのメンバーが実施している導入支援の場に同席しています。これらのリサーチ結果を開発チームに共有するようにしているんですが、もちろんリサーチは日本語で実施されているので、開発チーム向けに共有するときは一度翻訳したり、日本の商習慣などの背景を補足して説明する必要がありました。
リサーチ結果の共有を始めた当初はリアクションも少なめで、共有会の後に有益な会をありがとう、とSlackで言われるくらいでしたが、何度か繰り返していると自分が関わっている機能で問題が起きたケースを聞いて改善するモチベーションが上がったエンジニアも出てきたり、共有した課題に対する解決案を提案してくれるエンジニアが出てくるようになりました。
継続して共有し続けたことで、一定の効果は出ていたのかなと思います。ただ、現状は僕がユーザーの声を代わりに届けているだけなので、いずれは通訳の方を入れて（もしくは自分が通訳となり）、エンジニアもインタビューに同席してもらえないか？などと妄想しています。
初めてのフィリピン出張で行ったワークショップ
チームを立ち上げて半年ほど経つとエンジニア中心で機能の改善案を出してもらい、それらの機能をリリースするケースも出てきました。少しずつチーム全体でマジ価値を意識したプロダクト開発ができるようになっている実感が持てました。
この動きをさらに加速させたいと感じていた頃に、フィリピン出張に初めて行く機会がありました。
フィリピンで働く同僚のために、15人分のコーヒー淹れた pic.twitter.com/bvcVoxrzFH
— Hal (@hrtnde) June 22, 2022
その出張では、担当プロダクトのビジネスオーナー、プロダクトマネージャー、エンジニアマネージャーも参加することになっていたので、開発チームと一緒にビジネスゴールの認識を揃え、次の1年間の注力領域を一緒に考えていく場としては最適だと考え、ワークショップを行いました。
ワークショップを始める前は、「初めて英語でワークショップのファシリができるのか？」「フィリピンにいるエンジニアがそもそもユーザー理解を進めるより開発に集中したかったらどうしよう？」みたいな不安を抱えていたんですが、結果的には大成功でした。ワークショップ後、エンジニアが主導となってスプリントレビューの最初にプロダクトのOKRを振り返り、今開発している機能がOKRにどのように貢献しているかを意識して振り返りを行うようになりました。
※執務室の大きいホワイトボードがあるエリアでワークショップをやっていたので、他のチームのエンジニアも興味を持って参加してくれて、大盛況。最終的には20~30人くらいでワークショップをしてました！
難しいところ
グローバルチームを立ち上げてうまくいき始めていることも出てきていますが、当初の目標である「マジ価値のために自ら検証・改善のサイクルを回すことができている」開発チームを目指す上で、まだまだ課題に感じていることあります。
例えば、
企画をするメンバーのなかに英語が得意ではないメンバーがいるので、日本語で企画をして、それを翻訳してエンジニア毎回伝えている
翻訳する段階で情報が抜け落ちやすい
情報の共有のスピードが落ちてしまう
議論の過程を共有しづらいので、後からエンジニアが全体像を掴みづらく、仕様共有時の認識ズレも起きやすい
英語があまり理解できないメンバーのために仕様書に日本語も併記していると、仕様書を更新した時に日英両方で伝える必要があって大変
Figmaのデザインが日本語になっているため、デザインだけを見て仕様を理解しづらいので仕様を説明するドキュメントがかなり膨大になって、更新しづらい
英語でエンジニアとコミュニケーションできるプロダクトデザイナーが限られているので、一部のデザイナーにグローバル開発に関わる仕事が集中しがち
根本的には英語力によるところが大きいとは思いますが、仕様共有のフローやデザイン仕様書の作り方など、仕組みとして解決できそうな部分もあると思います。
10月からデザイン組織内にもグローバル開発に関わる専門のチームができたので、解決していきたい課題は山積みですが、一つずつ解決できるように頑張っていこうと思います。
おわりに
まだまだグローバルチームとして、成功しているといえる状態ではないですし、課題は山積みな状況です。しかし、この1年でfreeeのグローバルチームの可能性を感じることができました。
freeeのグローバルチームを一緒に成長させていきたいデザイナーを絶賛募集中です、ご応募お待ちしております。
明日はデザイン組織についてCEOにインタビューした内容をkambeさんが紹介するそうです。たのしみです。
この記事が気に入ったらサポートをしてみませんか？