2024.12.19
システムの穴を運用でカバーしようとしてミス多発… バグが大量発生、決算が合わない状態から業務効率化を実現するまで
リンクをコピー
記事をブックマーク
カン・スニ氏(以下、カン):では改めまして、会社紹介皆さんありがとうございます。というわけでパネルディスカッションに移りたいと思います。
すでに皆さんご存知の通りここにいらっしゃる3社皆さん海外展開をしている企業さんです。YOYOの場合は開発拠点はマニラ。ほかにも複数ヵ国サービスを展開していて。
Quipperさんの場合開発拠点は東京、マニラ、ロンドンなど。ウォンテッドリーさんの場合は、開発は日本で世界に向けてサービスを展開している。というところで、三者三様のお話をしてもらえるんじゃないかなと期待しております。
ではさっそくなんですが、相川さんのお話にありましたようにウォンテッドリーさんは、海外はインドネシアに主に注力してらっしゃると思うんですが、言語の翻訳のことや実際現地のことをあまり知らない状態で開発をしていたりとか、そういう苦労話……翻訳だったらQuipperさんもいろいろネタはあるような気もするんですけど。そのあたり、おもしろいお話あります?
相川直視氏(以下、相川):あの仕組み、結構うまくいってるんですけど、やっぱり長さの問題が一番あるなと思っていて。インドネシア語、長いんですよ。本当にスタイル崩れるんですよね(笑)。
英語だったら長かったときに「ここ削っていいんじゃね」とか「この単語置き換えよう」ってできるじゃないですか。「インドネシア語、どれ削っていいのかわかんない」みたいな。
いちおうTransifexのオプションで短めにしてくださいみたいなこともできるんですけど、そこらへんを本当に「じゃあ1個ずつ短めに」みたいに言っていくのかというと結構難しいなと思っていて。そこが課題かなと。
定期的に日本にいるインドネシア人のバイトを雇って「これどうかな?」みたいなことをやったりして解決したりしています。
相川:アプリケーションの言語によって長さが違う問題ってQuipperでもまさに全くそのままのものがあって。デザイナーが英語をベースにしてつくったものに収まらないとか、はみ出てしまうとか。はみ出たことによってリフローが起こってガタガタになるみたいなのが本当に多いんですね。
なので、そのあたりはデザイナーも何度も痛い目を見ながらインドネシア語で長くなったときにも対応できるようなデザインを事前に先回りして考えるとか。
どうしてもだめだったら、僕らの場合もほぼ同じシステムでやっていて別の翻訳サービス、ASPみたいなものを使ってるんですが、僕たちの場合外部に委託するのではなくて各地のネイティブのインドネシア人がいるので彼らに頼んじゃうということができるんですね。
なので、翻訳が必要な文言ができたときにそのニュアンス等も含めて、基本的にはアップデートは彼らのもとに通知が飛ぶのでそこで埋めてもらって。それをプログラム的に引っ張ってきてインドネシア語完成、みたいな。それで出していくんですけど。
どうしても微妙な部分とかに関しては、もう直接やりとりをして、そこは英語のできるインドネシア人にお願いする、みたいな。そういうふうにして苦労しながらやっているという感じですね。
カン:YOYOも、最初フィリピンで英語でアプリを出しそのあとインドネシア、ベトナムそれぞれの言語でやってると思うんですけど、そのあたりどうです?
尾崎良樹氏(以下、尾崎):うちの場合は翻訳サービスを全く使っていなくて。基本的に英語のできるインドネシア人、ベトナム人を自社で雇っているので、人力翻訳みたいなことをしていて。
やっぱり翻訳サービスに出しちゃうと、うちの場合特にユーザーの目に直接触れるところがメインなので、あとはロックスクリーンだとか、ニュアンスが難しいので。
基本的には彼らに人力でお願いして、まあ量もそんなに多くないので、やってもらってるというのがうちのやり方です。いまのところまだそれで回ってるので。
相川:翻訳のクオリティがいいとかってどんな感じですか?
尾崎:1人ではやらせてなくて、ダブルチェックがあるという感じですね。現地人同士で。僕は全く判断できないですけど当然。
代蔵巧氏(以下、代蔵):ちょっとおもしろかったのが、フィリピンに出してるんですけど、端末のサイズがすごい小さかったり大きかったりまばらすぎて、いろんな対応をしてAndroidアプリをつくってたんですけど。そのおかげで、インドネシアで長くなろうが短くなろうが多少回収はできたんですけど。
ちょっとインドネシア人に見られると「ここで改行しない」みたいな苦情を言われて(笑)。そこの対策のためだけに改行を入れたテキストをつくったりしていて。改行とかどこで区切ればいいのかわからないというのが難しいなと。
カン:じゃあその多言語対応の流れで。開発拠点が複数箇所にあるQuipper、YOYOのほうにお伺いしたいんですが、時差があったりとかコミュニケーションをする上でQuipperさんだとマニラ、ロンドン、東京。YOYOだと開発拠点のメインはマニラ、だけど日本にリモートでエンジニアがいるという環境で、複数拠点にまたがることでの難しさとか逆におもしろさとか、何かそういう観点でお話いただけますか?
長永:なんと言っても時差が本当に難しいというか。僕たぶん時差って人類にはたぶんもう克服できない問題なんじゃないかなと身にしみて思ってるんですが(笑)。本当に特に東京からだとロンドンが8〜9時間遅れているので、東京の夕方がロンドンの朝なんですね。
そうすると、東京のほうではほぼ仕事が終わって投げていたものの、例えば質問とかコードレビューの返事が、翌日の朝なり昼なりにならないと見れないわけですね。ずっと残っていればいいんですけど。
そんなに急ぎじゃないときはなんとか回るんですが、かなり込み入った話をしなければいけないときとか、こちらとしてはその日までに出したいというデッドラインが迫っていて、だけどロンドンの開発者から物言いがついた、みたいな。
レビューにですね。「ここはどうなんだ」みたいな話をされて。確かに言うとおりなんだがいまその話をしてる暇はないんだ、みたいなことが、1日経っちゃうと本当に難しいみたいなところがあって。
そのへんは各々ちょっと粘るとか、直接チャットとかで相手がオンラインになったときにもうネゴってしまうみたいな。そういうふうな感じで各自頑張るみたいな形でクリアしていくのがいまのところですかね。
カン:拠点によっては、例えば「マニラのあの人には言いづらい」とか、そういうのあります?
長永:個人的な話だと、非常にあって。感情的に。特にロンドンのイギリス人の開発者はわりと書く英語が難しいんですね。詩みたいなんですよ。シェークスピアの国の人なので。
(会場笑)
長永:読めない。本当に単語とか辞書で引いても何を書いてるかわからなかったりするんですよね。なので「お前は何を言ってるんだ」という感じになっちゃったりとか。
あと逆に、例えばマニラで最初に入ってくれたデベロッパーの子とかは僕がメンターをやってたりで個人的なコミュニケーションが多かったりするので、なんとなくその子のレビューに甘くなっちゃうというか(笑)。
みんなに「早くしてくれ」ってメンションとかで突っつかれるんだけど、ちょっと無意識に優先して見ちゃうみたいなところがあって。あんま良くないなって思ったりしますけど。
そのへんはもろコミュニケーション、人と人のやりとりなのでそこはリモートだろうが相手が何人だろうが全く関係なくあって。それぞれとちゃんと関係を築いていくのが大事なのかなと日々感じてるところですね。
相川:関係悪くなったら日本でマージしちゃったりしないんですか?
長永:実際ですね、関係が悪くなっていなくとも、例えば日本の開発チームが主導で作っている機能。こっちがリードしてつくっている機能で、背景のいろんな事情とかを日本人同士とかだったら日本語でやりとりしちゃうので、そこを全部英語でいちから説明するのはちょっと難しいみたいな場合は、やっぱりマージしちゃうことはあるんですね。
もちろんほかの開発者にはメンション等で「こういう事情だからマージするよ」みたいなことを気を使ってやるんですけど、そこはやっぱりフィリピンの開発者同士でそういうことが起こってるのを見て、見に行ったらもうマージ済みというのを見ると、やっぱりちょっと「うーん……」という。
もうちょっとワンクッション見たかったな、みたいな。「事後だけど、ちょっとここはどうかと思う」みたいなことを書いちゃったりもするので。
相川:日本だとやっててもそれを怒ったりしないんだよね。
長永:ああ、なるほど(笑)。
代蔵:僕らはほとんがフィリピンで、数人がリモートで日本に戻ってきていたりするんですけど。僕、去年末ヨーロッパをぶらぶらしながらリモート開発をしていて。いまもリモート開発なんですけど。一番問題になったのは、クライアントサイドとサーバーサイドのバグがどっちになるのかわかりづらいという事例が結構フィリピンだとあって。
端末のネットワークが悪くてエラーが起きてるのか、それともサーバーとの通信中のエラーなのかというのが特定できなくて。
そのへんのやりとりをリモートでしているときに「ちょっとサーバーサイドをチェックしてくれ」と言ってチェックされるのにちょっと時間がかかって、さらにチェックした結果問題なかったよというのが来て、こちらでチェックして、という時差が。
日本とフィリピンに時差はないんですけど、確認の時差がどんどん生まれていって。1個のバグ修正に3日とかかかるみたいな。というのが結構ありましたね。
尾崎:そういうケースでは、僕が仲介して「お互いこういうことを見落としてるんじゃないの」とかを言ったりしますね。ちゃんと背景情報から伝えるとか、スクリーンショット貼るとか、調査結果をログまとめて貼るとか。
そういうのを、お互い英語なので、フィリピン人は英語できるんですけど言語だけでやりとりしてるとアレなので。
具体例を出すとか背景情報を伝えるみたいなことをちゃんとやったほうがいいよ、というのはたまに言ったりします。
相川:そのやりとりは何でやってますか? うちは、例えば営業の人とやってるんですけど、そのやりとりすらネットが悪くてディレイ、みたいな。
尾崎:それで言うとSlackか、チケットにちゃんとなってるときはRedmineでやるみたいな感じですね。
相川:書くってことですよね。
代蔵:テキストベースのコミュニケーションになるので、レスポンスがやっぱり同期はしないんですよね。だから今後は同期させてやるときは声かけて「いまからフィックスしよう」というふうにやっていこうという話に結果的になって。
カン:代蔵さんはさっきヨーロッパって言ってましたけど、それ何日ぐらい行ってたんですか?
代蔵:1ヵ月ちょっとぷらぷら。Airbnbで家を借りて、うろうろとして。
カン:プライベートで旅行を兼ねて、でも仕事もしつつ?
代蔵:はい。旅行を兼ねてなんですけど、ほとんどがコワーキングスペースに行って世界のコワーキングスペースで働くっていうだけだったので。あまり観光とかは特にせず、仕事をしに行っただけでした(笑)。飛行機に乗って。
カン:じゃあそこは海外でリモートで働いている今とさほど変わらない?
代蔵:そうですね。それでいくと家があってベッドがあるっていう今のほうがまだましな感じはします(笑)。
カン:それをマネジメントしていた尾崎さんとしては何か特に困って点とかありませんでした?
尾崎:まあさっき言ってた問題はたまに起こりましたけど。お互い書いて残してれば、反応は微妙に遅れるけれども、問題は解決することは多かったので大丈夫かなという感じです。
カン:じゃあ次はこちら。多国籍チームでのコミュニケーションやマネジメント。言語の問題はもちろんあると思うんですけど、それとはまた違う観点で何かこういうことがあるんだとか、こういうこと配慮しなきゃいけないんだとか、何かおもしろい話か苦労話などありますか?
尾崎:それで言うと僕が最初に行って一番思ったのは、日本人と働いた経験をもとにあっちに行ってマネジメントするとやっぱり当然違うところはあって。日本人って結構ハイコンテクストな感じで会話するし、空気を呼んで足りないところを裏でやってくれたりとか。そういうのがたぶん世界で一番得意な人だなって僕は海外で気づいて。
どういうことかと言うと、フィリピンの人たちは、フィリピンというかたぶん海外全般なんですけど、自分の守備範囲をちゃんと持ってて。これをやってくれって言わないと進まない、みたいなことが結構あったので。そこは一番最初に学んで気を使っているところですね。
ただエンジニアをマネジメントするときって、エンジニアの人ってやっぱり自分で問題解決をする生き物だと思うので、あまり手法まで細かく言わないようにはしてますけど。「こういう問題があるから君頼むよ。何日までにこれ絶対に解決してね」っていうふうに言うと、ちゃんと動いてくれるっていう。明示的に言うっていう。
長永:ほかの国でのコミュニケーションで言うと、まさに尾崎さんおっしゃったとおりに、僕も日本で日本人のほかの開発者と働いていて日々感じるのは、やっぱり日本人が一番小人さん的なことをやるんですよね。気付いたときにちょっとテストこけてたらスッと直しておくとか。そういうやつですね。ちょっとエラー出てたら直しておくとか。黙ってやるんですけど。
日本人的な感覚だとそれって美徳で。チャットとか帰り際に「あれやってくれて、ありがとね」とかいうので回るんですけど。これがこと相手がロンドンとかにいると、小人さん業って気づいてもらえないんですよね。全くわからない。
いつの間にか知らないうちにエラーが出ていて知らないうちに直っていた、というのだと、経緯知らないと何も起こってなかったのと同じになっちゃって。
そうすると、やっぱりやってる側としてはちょっとは認めてもらいたい気持ちあるじゃないですか。けど、気づいてもらえてないので、だんだん「なんだよあいつ、ひと言のサンキューも言わずに」みたいな感じに勝手になっちゃうし、逆にかたや別の拠点で働いてる人からすると、何やってるかわかんないけど急に機嫌悪くなった、みたいな。
相川:ヘッドクオーターはどこにあるんですか?
長永:ヘッドクオーターはロンドンです。
相川:だから一応ロンドンに知ってもらわないと(いけない)?
長永:というわけでもないんですけど。もうちょっと具体的な話で言うと、例えばアプリケーションのテストが不安定な場合。
特にタイムゾーンの問題で、ロンドンの開発者のマシンでは通るんだがCIだと通らない。なぜなら、日付の書式がイギリス式とアメリカ式で異なるから、みたいな。そういうのがあったときに、日本だと確実に落ちるので直してあげるわけですね。
だんだんそういう細かいところから不信感とか不透明さが出てきちゃうので、そのへんはロンドンにいるCTOの中野が、彼は日本人なんですけど、折にふれて「ちゃんと言おう。こういう問題があったから直したよ、とか。
そういうコミュニケーションはやった側が「誰かが気づいてくれるだろう」と日本語のチャットレビューでぶつぶつ愚痴っていて、誰かが気づいて全体にアナウンスしてくれるみたいなのを待つのは効率が悪いので、どんどん自分で言おう」っていう。
それってなんというか日本的ではなくて。どこの国の流儀なのか知らないけど、でもグローバルな考え方ですよね。ちゃんと言うことは言う。前に出ていく、っていう。そういう部分はやっぱりここへ来て「ああ、やっぱりこういうふうにコミュニケーションってやっていかないとうまくいかないんだな」と感じた部分ですね。
2024.12.20
日本の約10倍がん患者が殺到し、病院はキャパオーバー ジャパンハートが描く医療の未来と、カンボジアに新病院を作る理由
2024.12.19
12万通りの「資格の組み合わせ」の中で厳選された60の項目 532の資格を持つ林雄次氏の新刊『資格のかけ算』の見所
2024.12.16
32歳で成績最下位から1年でトップ営業になれた理由 売るテクニックよりも大事な「あり方」
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
PR | 2024.12.20
モンスター化したExcelが、ある日突然崩壊 昭和のガス工事会社を生まれ変わらせた、起死回生のノーコード活用術
2024.12.12
会議で発言しやすくなる「心理的安全性」を高めるには ファシリテーションがうまい人の3つの条件
2024.12.18
「社長以外みんな儲かる給与設計」にした理由 経営者たちが語る、優秀な人材集め・会社を発展させるためのヒント
2024.12.17
面接で「後輩を指導できなさそう」と思われる人の伝え方 歳を重ねるほど重視される経験の「ノウハウ化」
2024.12.13
ファシリテーターは「しゃべらないほうがいい」理由 入山章栄氏が語る、心理的安全性の高い場を作るポイント
2024.12.10
メールのラリー回数でわかる「評価されない人」の特徴 職場での評価を下げる行動5選
Climbers Startup JAPAN EXPO 2024 - 秋 -
2024.11.20 - 2024.11.21
『主体的なキャリア形成』を考える~資格のかけ算について〜
2024.12.07 - 2024.12.07
Startup CTO of the year 2024
2024.11.19 - 2024.11.19
社員の力を引き出す経営戦略〜ひとり一人が自ら成長する組織づくり〜
2024.11.20 - 2024.11.20
「確率思考」で未来を見通す 事業を成功に導く意思決定 ~エビデンス・ベースド・マーケティング思考の調査分析で事業に有効な予測手法とは~
2024.11.05 - 2024.11.05