Tokyo to Saigon ― 二つの国で、ひとつのチームになる

私たちのチームは、東京とホーチミンの二つの国に分かれている。Goldrush Computing（東京）と、2023年7月にホーチミンに作った子会社 Goldrush Studio。海を挟んで手分けして開発する体制だ。立ち上げてみて難しかったのは、技術ではなく、二つの国のメンバーが「ひとつのチーム」になることだった。

定例ミーティングが苦手な私

正直に言うと、私は定例ミーティングが好きではない。打ち合わせは、必要な議題が出たときに、その議題に集中してやるのが好きなのだ。タスクはGitHub Issuesで管理し、日々のやりとりはSlackでメンバー同士が直接とっている。だから改めてZoomで話し合う議題も、そんなにない。

それでも週1回の定例を始めたのは、東京都主催のベトナム進出セミナーで登壇したベトナム人の社長の言葉がきっかけだった。「毎日、5分でも10分でもいいからZoomで繋いで、お互いに挨拶する。これが大事です」。彼は何度もそう繰り返していた。議題がなくても、顔を合わせることそのものに意味がある——そう考えを改めた。

ただ、グループでZoomを繋ぐと、どうしてもコミュニケーションが、東京の私とベトナム側のリーダーであるヘクターの2人を結ぶ1本の線になり、その向こうにそれぞれのチームが控える、という形になってしまう。本当はメンバー一人ひとりと、何気ない雑談がしたいのに。ここが悩ましいところだった。

毎週、誰かが質問を考える

第一回の定例は、お互いに挨拶したあと、近況をランダムに話して終わった。案の定、ほとんどの時間を私とヘクターが喋って終わってしまった。

これではよくないな、と思っていたところ、弊社の若手エンジニアのLさんが提案してくれた。毎週だれか一人が質問を考えて、その質問にみんなで答える時間を作ったらどうか、と。私には到底思いつかない、実に若者らしいアイデアだった。

もしプログラマー・エンジニアを辞めないといけないとしたら、どんな職業を選ぶ？

家でも職場でもない、自分にとって大切な「第3の場所」はどこ？

毎回、面白い質問が出てくる。その答えを聞くと、メンバーの知らなかった一面が見えてくる。「週末の過ごし方は？」という質問へのHくんの答えは、海に行ってドローンを飛ばすこと。Hくん、けっこうリア充だった。

最初は子供っぽいアイデアだなと懐疑的だったが、この子供っぽさこそがポイントだったのかもしれない。

もうひとつ、思わぬ副産物があった。ベトナムチームの英語力は、読み書きはTOEIC800点以上あるが、ヘクターとPくんを除く4人はリスニングとスピーキングが苦手だ。ところが定例を重ねるうちに、その4人のスピーキングが少しずつ上達していった。もともとオライリーの原書を読んで勉強しているような連中だ。話す機会がなかっただけで、彼らの伸びしろは無限大なのである。

サイゴンの朝と、互助の精神

ホーチミンに行くと、朝の風景に見入ってしまう。至るところにコーヒーショップがあって、軒先の低い椅子に腰掛けた男たちがコーヒーを飲みながら話し込んだり、ぼーっと通りを眺めたりしている。ある朝、私もメンバーのVくんに教えてもらったベーカリーでパンを買い、近くのカフェに入って、ココナッツコーヒーを飲みながらサイゴンの朝の風景の一部になってみた。

そのとき、宝くじのような券を売り歩く男性がカフェに入ってきた。手を少し上げて「いりません」と伝えると、彼は他の客にも順番に声をかけていく。店のウェイターも、奥にいるオーナーらしき女性も、まったく気にする素振りがない。黙認しているのだ。

これが日本のカフェだったら、別のものを売り始める人は即座に注意されてしまうだろう。ベトナム社会に残る寛容さ、互助の精神のようなものを感じた。おそらく日本ほど充実した社会保険の仕組みはないだろうが、市井の人々の間にこうしたセフティネットが生きている。戦後の日本にも、きっとこういうものがあったのだろうと想像した。

働く場所が違えば、暮らしの手触りも違う。その違いごと受け止めることが、二つの国でひとつのチームになる、ということなのだと思う。

音声を、みんなで学ぶ

チームで成長するために、勉強会も開いた。

最近、私たちはマシーンラーニング×音声のプロジェクトをやっていた。このとき、ベトナムチームが音声技術に強くないことがわかった。MLモデルを適切に配置してAPIを実装し、音声を生成することはできる。ところが、生成したものを評価する段階で、音声そのものに関する技術的な知識が足りず、正確な評価ができていなかったのだ。

私は独立する前、ソニー・エリクソンで働いていた。ソニーはその名の通り”音”の会社で、ウォークマンで知られているが、実はCDの規格を作ったのもソニーだ。そんな環境にいると、音響が専門でないエンジニアでも、一定以上の音声の知識を持っている。だから私は、それをエンジニアなら当たり前だと勘違いしていた。ハッとした。これはメンバーの責任ではなく、必要な教育をせずにプロジェクトを始めてしまった私の責任だ。

奮起して、2時間ほどで音声のコーデックとファイルフォーマットを一から理解するための資料を作った。厳密にしすぎると理解の障壁が上がってしまうので、専門家が見てもギリギリ怒らない——いや、若干怒るかもしれない——くらいの、ざっくりした資料にした。ちょうど生成したての音声データがあったので、勉強会はとてもリアリティのあるものになった。

ソフトウェアエンジニアというのは、コンピュータとプログラムに精通しているだけでは十分ではない職業だ。対象となるドメインやデバイス、データへと、どんどん知識を広げていかないといけない。そこが大変で、面白いところだ。

一年目を振り返る

チームができてしばらくは案件がなくて困っていたが、そこからなんとか4つのプロジェクトを受注し、2023年はこの4つを完了できた。

1つ目はFlutterを使ったiOS/Androidアプリ。ベトナムチームがFlutter側を、東京チームがSwiftとKotlinのネイティブ側を担当した。2つ目のRubyOnRailsとReactのプロジェクトは、Railsが得意なベトナムチームが主軸となった。3つ目はnode.jsとVue.jsでデザインからインフラまで一気通貫でやったもの。4つ目のOpenAIを使ったPoCでは、AI的な部分を東京が、フロントエンドとDevOpsをベトナムが担当した。

振り返ると、我がチームには、フロントエンドが得意な人に負荷が集中し、逆にバックエンドやインフラが得意な人が時間を持て余す傾向があった。理由のひとつは、一つひとつのプロジェクトが少し小規模なこと。バックエンドやインフラは、プロジェクトが大きいほどやることが増えていく。

Goldrush Computing（日本）とGoldrush Studio（ベトナム）で、UX/UIデザイン、スマホアプリ、Webフロントエンド、バックエンド、インフラ・DevOpsまで、すべての設計と開発ができる。この力をフルに発揮できる、もう少し大きなプロジェクトと出会うこと。それが2024年の私のミッションだと、強く感じている。

二つの国に分かれたチームが、毎週の他愛ない質問や、朝のコーヒーや、音声の勉強会を通じて、少しずつひとつになっていく。その手応えこそが、この一年でいちばんの収穫だったのかもしれない。