はじめに
こんにちは。freeeで人事労務開発部でエンジニアリングマネージャをしています。安斎です。 この記事は出張中のフィリピンで書いています。
2014年にfreeeに入社してから早8年が経ち、これまででもっとも長く働いている会社になっていました。 今年に入ってからグローバル開発のチームのマネジメントをするようになったので、グローバルなチーム作りへのチャレンジと課題についてお話します。
なぜドメスティックなプロダクト群なのにグローバル開発？
先日の高野の記事にもあったように、国内でのエンジニア採用に関わる方は年々強く感じていると思いますが、エンジニアの国内での採用が難しくなってきています。
freeeの成長速度に合わせて採用数も増やしていく必要がありますが、今の成長速度でfreeeが成長していくと、近い将来エンジニアの採用が追いつかない状況になるリスクがあります。 実際に国内でエンジニアの採用ができない状態に追い込まれてから海外で採用をして開発拠点を作っていくのでは遅いため、将来への布石として海外での開発拠点の立ち上げをしようとしています。
その布石の一つが、昨年のLikha-iT(フィリピンの開発会社)のfreeeグループへのジョインです。
海外拠点、というとオフショア的な開発をイメージされるかもしれませんが、freeeのグローバル開発で目指しているのは、 関西や名古屋に作った開発拠点と同様に一つの開発拠点として独立して、 他の開発拠点と同様の開発力を持って一定の領域を担当し自律的に開発を進めることができる組織の立ち上げです。
チームのミッション
チームのミッションはチーム発足時に話し合い、下記のようなものを掲げています。まだまだ弊社ではグローバル開発のノウハウを溜めていくフェーズであることもあり、課題や失敗についてもノウハウとして経験値を溜め、双方の会社へ展開していくことも意識しながら開発をしています。
Learn problems regarding global engineering and share the knowledge for freee and Likha. （グローバル開発の課題を洗い出し、freee/likha双方にナレッジを共有する）
Prove that global engineering teams are capable of developing features that require domain knowledge deeply. （コアなドメインに関係する分野もグローバルチームで開発ができることを証明する）
Contribute to the freee's rapid growth by enhancing the development productivity. （開発力を上げることでfreeeの成長に貢献する）
チーム名の由来
freeeでは開発拠点の名前に食べ物の名前をつけることがなぜか多いのですが、グローバル開発チームもkwek kwek（先日の高野の記事で紹介しています）と、lapulapuという食べ物の名前です。 lapulapuはフィリピンの英雄の名前でもあり、魚の名前でもあります。日本人に取っても、発音しやすく、響きの良さからチーム全員一致で決めた名前です。 出張中に何回か食べる機会がありましたが、淡白で鯛のような味でした。
ドメスティックな分野でのグローバル開発の難しさ
人事労務開発チームでは、日本の給与計算や書類など、ドメスティックな分野での開発を行っています。 これまでグローバルな開発体制を考慮して作られてきたわけではないこともあり、いろいろな課題と向き合っています。
―文化的な背景の説明
何気なく使っているハンコ、英語で説明しようとしたことありますか？実印の仕組み、印鑑証明書の説明を英語でしたことって恐らく多くの方は無いと思います。
こういった何気なく日本で行われている慣習からくる書類の構成や、書類提出の流れをある程度説明して、納得した上で開発したほうが良いと考えているのですが、 リモート環境下で物理的な書類やハンコやマイナンバーカードを見せながら実感を持って開発してもらうのは難しさを感じています。 このあたりは実際に同じ場所にいて、書類やハンコやマイナンバーカードを使いながら、実務の流れを一緒に体験できたほうが早いだろうと考えています。
―アーキテクチャとチーム間コラボレーション
グローバル開発をするにあたっては、設計段階でドメインに根ざしたロジックの部分と、それ以外のところをわける設計が必要だと感じています。 ただ、このドメインに関連するところとそれ以外を分ける、という方針はグローバル開発だから、というわけではなく、 通常の開発においても志向されるべき設計ポリシーなのではないかと感じています。
実際、私達のチームでは他のモジュール・チームとの関連はあるものの、参照のみでの依存関係になっているので、インタフェースさえ決まってしまえばあとはそこまで深くドメインを追わなくても開発を進めることができています。 もともとそういうアーキテクチャで作られていたこともあり、ドメインを深く追い続ける局面には追い込まれずに今のところは済んでいます。 もしアーキテクチャ的にも分離されておらず、チーム間のコラボレーションが濃密に必要な状態になったとしたら、それは設計から見直しをするべきなんだろうと考えています。 英語化されていないチームのほうがfreee内では多いので、チーム間でのコラボレーションが発生した場合にどうするかは今後の課題でもあります。
―行政関連の文章の日本語の難しさ
freeeが開発している分野は日本独自の仕様や文化に関連するものも多く、会計や人事労務では独特の用語が使われていたりします。 日本語ネイティブでもわかりづらく、読みづらいと感じる文章があります。
用語一つ取ってもそうで、たとえば「健康保険・厚生年金保険被保険者報酬月額変更届 厚生年金保険70歳以上被用者月額変更届」を英語に翻訳したとして、 "health insurance and pension insurance insured standard monthly remuneration report"、としたしても、英語になっていればスッとわかるようなものではありません。
英訳だと分かりにくいため、まずは月額変更届の概念を説明し理解してもらったうえで、日常的にも使いやすくするために月額変更届＝月変＝geppenといったように言葉を短縮し、口頭でのコミュニケーションでも"geppen"という言葉を使ってコミュニケーションをするようになりました。
「お年玉」みたいな言葉と同じで、概念として日本独自のものは、無理に翻訳せずにそのまま使ったほうが良いのではと考えています。 この"geppen"はコミュニケーションだけでなく、実装のコードでも同じように使うことでわかりやすいコードになるようにしています。
こういった用語や書類名のややこしさとは別に、行政関連の文章や仕様を読むケースがありますが、この場合には行政関連の文章の難解さには少し悩まされています。 日本語ネイティブが読んでも理解がすぐにできないことがある文章なので、英語力や英語の問題ではない別の課題として認識しています。 これらの書類の難解さは設計段階で噛み砕いてDesign Doc（設計書）に書いて、読み合わせとレビューを重ねることで理解を深めて開発に取り組んでいます。
その一方で、日本の制度の背景やカルチャーに起因する事柄については、 プロダクトマネージャからプロジェクトごとに都度インプットしてもらい、認識を揃えることで解決しています。 健康保険制度や、年金の制度、雇用保険の制度は当然違いますし、日本の特殊性も見えたりもするので、制度面の説明と共有については今後も継続して行っていく必要がありそうです。
―カルチャーやキャリア感の違いについての理解
これまで日本でずっと働いてきたので、日本のエンジニア圏のカルチャーやキャリア感についての肌感はあるものの、海外、特にフィリピンだとどのような違いがあるか、というのをよくわかっていませんでした。 今回のLikha-IT社がfreeeにジョインするにあたり、Likha-IT社の会長前田さんと、Engineering ManagerのNorrisがいろいろとサポートしてくれたので助かりました。
どうしても日本の感覚でコミュニケーションをしがちだったり、キャリア感の前提が日本のエンジニアのようにフルスタック志向はそれほど強くない、といった違いだったりといった面は現地での開発や経験がないとわからないところで、このあたりの橋渡しをしてくれる人がいないと立ち上げはもっと苦労するだろうと思います。こういった込み入った深い話をするのはやはり直接1on1することに勝るものはなく、滞在中に色々と相談できたのは収穫でした。
英語との向き合い方
「あー、英語話せるエンジニアもPMもいっぱいいたんでしょ」と思われるかもしれませんが、 今のチームのメンバーで英語での仕事の経験があったメンバーは一人だけ、 他のメンバーはグローバル開発チームにアサインされるまで英語での仕事の経験はありませんでした。
昨年11月に正式にチーム発足とアサインが確定したので、今年1月までに残された時間はわずか2ヶ月、 2ヶ月で私もチームのみんなも必死で英語を勉強して1月の発足を迎えました。
オンライン英会話をしたり、PROGRITで2ヶ月特訓したり、各自やり方は様々でしたが、 発足時にはそれなりに支障なくコミュニケーションができるレベルになっていました。 会社からも英語学習のための補助制度が整えられ、補助を使うことができたので金銭的な負荷も抑えて英語学習を進めることができました。
3月末でクォータが終わり、英語の勉強を始めてから5ヶ月が経過しますが、英語で困る、という局面はなくなってきています。 これはフィリピンのメンバーが我々日本人が話す英語を理解しようと努力してくれていることにも大いに助けられていますし、 日本側のメンバーも伝えよう、コミュニケーションをしよう、という熱意があるので困っていないのだろうと分析しています。
エンジニア同士の場合は、英語だけではなくコードを使ってコミュニケーションもできるし、UMLのような世界共通の図の描き方があることもコミュニケーションの補助になっているのでなんとかなっています。シビアな交渉やプレゼンで英語を使うわけではないので、特にエンジニアの場合は単語を並べて、コードと図を使いながらコミュニケーションを取るだけでも十分に開発は進められると思います。コードと図を使ってコミュニケーションを補助できるのはエンジニアの強みですね。
チームのマネジメントに関しては英語はできればできるほどよいのは間違いがなさそうなのと、 英語力のなさを言い訳にしてチームの成果が出ない、という事態にはならないよう、 今後も英語の勉強は続けていく必要がありそうだと感じています。
成長速度が鈍化すると言われて（？）いる40歳を迎えたエンジニアが、英語の勉強をすれば数ヶ月でなんとかなる、 なっているという一つの例として参考になれば嬉しいです。ガッツと根性と伝えようとするパッションがあれば英語は数ヶ月でなんとかなります。
チームではSlackもミーティングも当然英語というルールにしていて、日本人同士で日本語で話すこともほとんどありません。 稀にどうしてもややこしい仕様や実装について話す際に日本語で、ということはありますが、1月の発足以降そういう議論が必要になったことはほんの数回程度しか発生していません。
チャレンジを後押しする社風
英語経験がない社員の「やりたい」というモチベーションを重視し、 会社としては英語での開発経験や駐在経験があるメンバーを充てたほうがリスクがないであろう局面にも関わらず、チャレンジを許してくれる会社である、というのは成長へのプレッシャーもありますが、成長する機会を与えてくれる良い社風は8年前に入社してから会社は随分大きくなりましたが変わっていない良い文化だな、と思います [PR]。
グローバル開発チームへのアサインを打診されてから実際にアサインが決まるまで、 誰からも私の実際の英語力を確認されませんでした。 アサインして任せる、現時点でできるかどうかではなく、今後の成長を信じて任せる、そういった社風が出た決定プロセスだったと感じています。
リモート下でのチームビルディング
本当は、1月のチームキックオフから現地へみんなで行って、現地でチームの立ち上げをするつもりでいたのですが、 年末からコロナの感染状況の悪化があり、フライトが欠航となるとともに出国もフィリピンへの入国もできない状態になってしまったためリモートでのチーム立ち上げをしました。
グローバル開発のためだから、と特別なことをしていたわけではなく、1月に正式に発足する前からなめらかに組織社会化（自分がその集団の一員であるという認識になる）が 進むように準備を少しずつしていました。
具体的には週次で新しく発足するチームメンバーで話す時間を設け、オンラインで飲み会をして、 1on1をしながらそれぞれの期待値やこれから起きるであろうことについて話し合うことで予期的社会化を促し、 実際発足してからのギャップを少なくすることで組織社会化を早くする、ということを心がけていました。
ただ、これは日本でのチーム立ち上げ時や、新しいメンバー受け入れでも行うことなので、グローバル開発だから特別なこと、というわけではありません。 そういう意味だとグローバルだから何か特別なマネジメントの方法やスキルが必要だとはあまり感じていません。
時差とカレンダーの違い
時差はフィリピンとは1時間だけの時差なので、欧米やインドなどと仕事するようなときのように時差が問題になるようなことはありません。 時差の問題はないものの、カレンダーの違いは2月は影響が少しありました。 双方ともに祝日があったこともあり、スプリント内で働いている日がずれるという状況が発生していました。
プロジェクトのスケジュールマネジメント視点からすると調整しづらいな、と当初は考えたのですが、日本のカレンダーでは祝日であっても、フィリピンのエンジニアが動けるのでプロジェクトの開発が止まらず、むしろ良いことだと感じています。時差がある国とのコラボレーションだと24時間開発を継続する体制を作れたりすると思いますが、少しマクロな視点で日単位で開発が止まらない体制を作れるのはグローバルなチーム体制の場合のメリットだと感じています。
コミュニケーションの設計
心理的安全性を築く必要があるのは日本でのチームビルディングと同じだと考えています。 日本でのチームビルディングでやっているように、スクラムのミーティング群と合わせて、リモートでの飲み会、 毎朝コーヒーブレイクの時間として、「仕事の話題は禁止」というルールで雑談するためだけの時間を設けてコミュニケーション量を増やすようにしています。
この時間を使って、お互いの昔話をしたり、業務だけでは知り得なかった情報が得られたりするので、普段のコミュニケーションの改善にも役立っています。同じチームのMattは自分でCoolな壁紙を作っていたことがわかり、LGTM画像にしてもりあがったりしています。
これは今回グローバルチームになったから始めたわけではなく、2年前にリモート環境にいきなり追い込まれてコミュニケーション量が減ってしまったこと、 新しくはいってきたメンバーがチームに馴染むまで時間がかかるようになってしまったことへの一つの打開策として始めた習慣です。 オフィスにいれば雑談や、ランチへふらっと行ったりして発生していたコミュニケーションがリモートだとどうしても減るないしはなくなってしまうので、 意図的な雑談をする時間を設ける、というのはお互いを知るという意味でもとてもオススメです。
その他、1on1も日本のエンジニアと同じように、毎週行っています。 英語での1on1はテクニカルな話題に限らない幅広さがあるので、英語力の不足を最も感じる時間でもありますが、 英語だから、といって1on1をしないでいると十分な精神支援・業務支援・内省支援ができないので必須だと考えています。
物理で会うことの大切さ
コロナ後、2年以上リモートワークをしてきて、リモートワーク下でのチームビルディングも複数回経験してきました。それでも実際に会って話すこと、に勝るものはないな、と改めて思いました。 日本国内でも言えることですが、海外のメンバーとのチームビルディングでは直接会うことの効果は非常に大きいと感じています。
こちらを訪れるまでは、リモートでもなんとかなってるし、直接会うのはできればやったらいい、ぐらいの感覚でいたのですが、こちらに来てから考えを変えました。 海外のメンバーとチームを作るときには万難を排して直接会う機会を作るべきだと、今回の出張で感じています。直接あったことがあるかないかでコミュニケーションのやりやすさや、チームビルディングの深度が全く違うと感じています。業務以外でもコミュニケーションを取ることで、お互いをより深く知ることもできるし、そういった人間的なコミュニケーションがあったほうがチームはうまくいくと感じています。
コロナが続く中での出張となり、入国するときにも帰国するときにもPCRテストが必要で大変なプロセスではありましたが、そういった状況であっても安全が確保できる限りは行くのでも来るのでも構わないので出張をしてお互いに顔を合わせる、というのをチーム作りの最初のフェーズに置く必要があると感じています。
オンライン会議では欠落している情報も多く、直接会って話したときの情報量の多さと、コミュニケーションのしやすさに感動しました。 英語でのコミュニケーションも直接話したほうが圧倒的にやりやすいと感じます。 3ヶ月以上オンラインで話を重ねてきたので、初日から古くからのチームメイトのようなノリで非常に楽しい経験でした。
滞在中はLikha社のみんなに毎日いろいろとサポートしてもらい、大きなトラブルなく過ごすことができました。 フィリピンは日本と比べてコロナをうまくコントロールできている状況ではあるものの、やはりコロナ警戒中ではあるので現地でのPCR手配、 移動のサポート、屋台での食べ物のレクチャなどまでしてもらえて大変感謝しています。
むすび
日本で開発しているウェブ業界でも各社海外のオフィスや開発チームをすでに持っている会社がたくさんあると思うので、ぜひお話伺いたいと思っています。 カジュアル面談に行くのでお誘いお待ちしています！
freeeでも英語を使う環境で働きたい、第一言語が英語である、というエンジニアの採用も始まっています。 正直なところ制度的にも整っていない部分はまだ多くありますし、 実際の開発内容も試行錯誤をしながら失敗から学んで泥まみれになりながら進めていくようなカオスな状況ではありますが、 ここまでチャレンジングな状況もなかなかないと思いますので、興味ある方はぜひカジュアル面談にお越し下さい！
