2024.12.10
“放置系”なのにサイバー攻撃を監視・検知、「統合ログ管理ツール」とは 最先端のログ管理体制を実現する方法
リンクをコピー
記事をブックマーク
カン・スニ氏(以下、カン):では改めまして、会社紹介皆さんありがとうございます。というわけでパネルディスカッションに移りたいと思います。
すでに皆さんご存知の通りここにいらっしゃる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.10
メールのラリー回数でわかる「評価されない人」の特徴 職場での評価を下げる行動5選
2024.12.09
10点満点中7点の部下に言うべきこと 部下を育成できない上司の特徴トップ5
2024.12.09
国内の有名ホテルでは、マグロ丼がなんと1杯「24,000円」 「良いものをより安く」を追いすぎた日本にとって値上げが重要な理由
2024.12.12
会議で発言しやすくなる「心理的安全性」を高めるには ファシリテーションがうまい人の3つの条件
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.12.10
職場であえて「不機嫌」を出したほうがいいタイプ NOと言えない人のための人間関係をラクにするヒント
2024.12.12
今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは
PR | 2024.11.26
なぜ電話営業はなくならない?その要因は「属人化」 通話内容をデータ化するZoomのクラウドサービス活用術
PR | 2024.11.22
「闇雲なAI導入」から脱却せよ Zoom・パーソル・THE GUILD幹部が語る、従業員と顧客体験を高めるAI戦略の要諦
2024.12.11
大企業への転職前に感じた、「なんか違うかも」の違和感の正体 「親が喜ぶ」「モテそう」ではない、自分の判断基準を持つカギ