00:04
はい、ということでゼロトピックですね。今回は、メルカリからNXにジョインしてくれたソフトウェアエンジニアの北さんに来てもらいました。こんにちは。
はい、お願いします。こんにちは。
じゃあ北さん、早速なんですけど自己紹介お願いします。
はい、NXの北雄介です。
前職はメルカリで働いてて、基本的にはメルカリのUSのアプリを2、3年ぐらい携わってて、その後に最後にメルカリの方に移動して働いてました。
職種的にはソフトウェアエンジニアで働いていたことも長いし、途中エンジニアリングマネージャーをやったこともあります。
役割的にもテックリードをやったり、いろんなことをやってきて、最後のメルペだとデベロッパーリレーションズみたいなところもやってたので、結構幅広く浅く携われたかなと思ってます。
どこから、自己紹介。
まず、そもそもメルカリでソフトウェアエンジニア、EM、テックリード、デブレルってこれ経験した人って他にいるんですかね。
デブレルは絶対いないですね。これは特殊なチームなんで、そもそも僕の最後の所属してたチームはまずプラットフォームに1人しかいないんで、全員で僕含めて3人だから。
メルカリでも少ないし、単純なデブレルっていうチームじゃないので、そもそも他の会社に同じ役割の人はいないんですね。
デブレルっていう名前じゃなくてエキスパートチームっていうんですけど、コミュニティをグロスするのが目的のチームなので、
そういう意味ではデブレルみたいな勉強会の支援とか、あと作業の手伝い、社内の情報発信の手伝いもやるし、
あと僕はどっちかっていうと既存のiOSチームの基盤開発とかアーキテクチャを整えるっていう仕事もやってたんで、
社内外含めたコミュニティのグロスっていうのをやってます。
なのでそんなに広く携わっている人は、というかチームは多分そのエキスパートチームがそもそもないので結構特殊ですね。
なるほど。
でもデブレル自体が特殊だっていうのもあるけど、エンジニアリングマネージャーとテックリード両方やったみたいなのも結構特殊じゃないですか。
チームによりますね。
USは少なくともエンジニアリングマネージャーはテックリードできる人にしか任せてないんですね、現実は。
03:08
そうなんだ。
JPだと多分ちょっと違うと思いますけど、JPとメルペは。
それはなんかあれですよ、つよつよな人って感じですね。
そうですね。
USはまだスタートアップに近いんで、そういう環境が違うからこそ必要とされる能力もちょっとまたJPとメルペとは変わっているので、その辺は面白さもあり大変なところもあるって感じですね。
うん、なるほど。
ちょっと今触手軸の話でしたけど、業務軸でいうとUSのアプリ2,3年、結構長い期間だと思うんですけど、この時って何やられてたんですか?
最初はUSエンジニアとして機能実装とか修正をずっとやってて、
そもそも最初はソースコードのJPと共通のソースコードだったので、間接的にはJPの機能も一時的にちょっとやったりしてました。
それで、プロダクト自体がUSだとそもそも翻訳してローカリゼーションが完了っていうプロダクトではなくて、機能ごとのローカリゼーションっていうのが必要で、
例えば配送とか日本だと大和とか郵便局があるけど、USだとFedExとかUSPSなので、そういう機能自体をローカリゼーションしてました。
それが進むにつれてやっぱりソースコードを共有するっていうのが非常に難しくて、
単純にUSの方をいじったりJPの方で壊れてないか確認しないといけないっていうのが結構コストが高くなってきたので、
それである程度のタイミングでソースコードを分けて、USのアプリは作り直すっていう決断をしてて、その作り直しも担当してました。
サーバーサイドは全部作り直してなくて、ちょっとラッパーを構えてるだけなんですけど、
基本的にはUS独自にできるだけ特化したコードベースにするっていうのをやってました。
その後は人数も増えて規模がでかくなって、規模がでかくなったって言ってもプラットフォームに10人もまだ全然いないんで、
バイオエンジニアが4人とか、アンドロイドもそれぐらい、サーバーが10人ちょっとぐらい結構ですけど、
ちょっと増えてきたので、増えてきたのと後は本格的に日本とUSで2拠点で同じぐらいの人数で開発するようになりました。
06:00
以前は例えば初期の場合だと結構日本にしかエンジニアがいないって語っておってて、
逆にもうちょっとした後はUSの方が人数増えてUSにしかエンジニアがあんまりいないっていう結構アンバランスな感じでやってたんですけど、
ちょっと成熟してきて拠点も2つに分散していろいろ役割も分けてやってきました。
そのタイミングでやっぱりテクニックリードみたいな人が必要になってきて、
例えばコミュニケーションするだけでも意思決定する人は基本的にUSにしかいないんで、
そういう人にどういう機能を作るべきかとか、どれぐらいのリソースあるので何を目標にしましょうみたいな話、
結構上位概念の話もそうだし、
エンジニアにとってだと今こういうコードベースでここが問題なんでリファクタリングしましょうとか、
あとはアーキテクチャちょっとUSは複雑だったので、
例えばモバイルだとReact Nativeっていうクロスプラットフォーム10Xで今やってるプラッターみたいなものを使ってたりとか、
サーバーサイドももともとベースはPHPなんですけど、
Goのラッパーの準備して、その上でマイクロサービスを展開してたので、
GoとPHPが混ざった状態になってるところだったので、
そういうアーキテクチャ的にも結構複雑になってたので、
それを理解しつつプロジェクトマネジメントでできる人っていうのが必要でした。
なのでテックリードっていうのが必要で、
別にあんまりテックリードはもともと目指してる、
意図的に目指してたキャリアプランじゃないんですけど、
単純に僕は台席してなくて、ドメイン知識がいろいろ溜まってたのと、
あとはサーバーサイドにも興味あったんで、いろいろできそうだなと思って、
テックリードみたいなことをしてたっていうのが大体の流れですかね。
なるほど。ということで、ちょっと北さんにマイクを直してもらって中断したんですけど、
そのUSのアプリをJPから始めない、いろんな人が出張して作る、
そこから2拠点になってくる、さらにコードベースが同じでみたいな、
その中で辛さとかどういうチャレンジがあったのかとかお聞きできますか?
一番辛いのはQAのコストが2倍になるので、
例えばUSで作ったアプリのせいで、作った機能のせいでJPにバグが出る、
それの逆もしかりっていう状況が全プラットフォームで起きるので、
それの確認が一番大変ですね。
それめちゃくちゃ大変ですね。
これが特に大変になるのが、
09:04
どれくらいのタイミングから始めたか覚えてないんですけど、
A,Bテストを始めだした時期があって、
その条件分岐がすごい複雑になってきてますよね。
特にそれがUI側、要はWebとかアプリでだいぶ難しくなってきてて、
具体的に言うと、まずリジョンの分岐があるんで、
if JP、if USだとこうするっていう処理もあるし、
ifの中でif A,BテストがAだったら、
LSBだったらっていうような分岐が至る所に出てきて、
ロジックだとそういう分岐の処理しても結構書きやすいんですけど、
UIのコードってそんなにまだ綺麗に書けてないので、
単純な分岐だけでもバグが生まれやすい要因になっちゃうんですよね。
それも含めると正直QAコストは全然2倍じゃなくて、
3倍とかに実質になってます。
指数関数的なイメージがありますね、それは。
僕らも書いてる側も正直全部のコードの動きは把握できないので、
だいぶ難しいで、最後にUKも入ってきたんで。
それはあれですね。
よくその状態で開発進めたなって感じがしますね、むしろ。
そうですね、だいぶ頭使って実装しないと本当にぶっ壊れるっていう状態だったので、
そこはだいぶ難しかったですね。
逆に開発者目線でワンソースで多国展開を始めたことによって、
今振り返った時にこれはメリットだったなって思った部分ってありますか?
メリットなのは当然何個かあって、
一つはやっぱりすぐアプリを出せるっていうところがメリットですね。
1から作り直してるとすごい時間かかっちゃうんで、
スタートアップなのでとりあえず出してみて改善するっていうフローを早めから実現できるのはすごい良いことですね。
もう一つはやっぱりビジネスロジックの資産を有効活用できるのは良かったと思います。
さっき言ったように配送とか購入はUSではコアな実装自体は全然違いますけど、
ペイメントゲートウェイも違うんで、
ただその購入だったり配送だったりの基本的な機能の概要っていうところの資産の再利用っていうのはすごい大事で、
そこは多分結構良かった点なんじゃないかなと思ってます。
12:02
結果的に半分作り直してはしてますけど、
それは別に全部捨てたわけじゃなくて、
JPの良かったところも多分取り入れてると思うんで、
そういう点はすごい良いと思います。
検証をしっかりして、
ラーニングを経た上で刷新をしてるんで、
次の精度が高いとか、
そういうメリットはすごく得られてるのかなってお聞きしております。
そうですね。新しく作っても既存のクオリティー以下には絶対しないんで、
それはそうですね。
それはさすがというか。
あとは、向こうの拠点と開発するとか、
USで開発するっていう時期もあったんでしたっけ?
そうですね。僕は特に赴任して、
アメリカで開発してた時があるので、
例えば、USで仕事してる人は、
現地のカスタマーサポートの人の声も聞けるので、
バグ修正とか、
小雪の予防がありますよっていう対応が結構多いですね。
逆に日本だと、
じっくり時間を進めて、そんなに現場の声は入らないんですけど、
逆に時間を使って、
コアな機能とか、
っていうのに集中して取り組めますね。
そういう意味では、今のコロナで、
リモートワークで集中して、
リモートでできることもあるし、
お室に行って、
効率がよく進められるものもあるっていうのを、
当時はコロナ関係なしに、JPとUSで分けて進めてたっていうところに近いかもしれないですね。
確かに、それ結構面白い気づきですね。
日本だと腰を据えて仕事ができるって、なかなか気づかないというか、
やっぱ現地に行った方がいいんじゃないって、単純に思っちゃいそうな気がしますけど。
もちろん、めちゃくちゃ出張で現地に来てた人は当然多いですけど、
それでも、一旦その現地の声聞いて、
日本で開発するっていうのも全然できなくないんで、
多分、ほぼ初期ぐらいからは日本の拠点はずっとありますね、一応。
初日ではありますけど。
あとは、PMとかとのやり取り、
プロダクトマネージャーとか、もしくは意思決定者が経営人だったのかもしれないですけど、
そことのやり取りはすごい大変そうなイメージがあるんですけど、
そこって何か工夫とかされてたんですか?
僕が最終的にやった工夫としては、
その意思決定には入れないですけど、プロセスには入れないですけど、
もう早い段階でエンジニア、テクリードが、
その仕様作成の話に入るっていうのを進めてました。
何でかっていうと、拠点が多いので、
15:01
承認決定のプロセスも当然増えるんですけど、
早い段階の仕様の漏れとか、
レビューによる出戻りで行ったり来たりするコストがすごい高かったので、
それをできるだけなくすために、
テクリードが基本的にはアーキテクチャとか技術方面のレビューを最初からして、
あとは僕は個人的にはQAの人にも入ってもらってて、
仕様はQAが一番詳しいので、
EMよりエンジニアよりQAが一番詳しいので、
QAの人にもちょっと入ってもらって、
仕様の漏れとかを指摘してもらって、
結構早い段階で入れてやってもらいました。
当然これは僕らにとってプラスアルファのコストにはなるんですけど、
全体的に見たら全然効率よかったかなと思ってます。
でもスタートアップ、フェーズとしてはUSはスタートアップっていう話だったけど、
結構開発の仕方とかは日本の影響だったり大きいものの影響を受けるって意味だと、
結構大企業の開発に近いプロセスだったり工夫が必要だったような印象がありますね。
そうですね、今の状況だと成熟したスタートアップぐらいのやり方ですね。
なるほど。
じゃあそこからTenXに聞いていただいたわけなんですけど、
TenXに入社したのは、そろそろTenXなんで知ってたんでしたっけ?
それは石川さんとずっと前からiOS界で知り合いだったので、
そっかそっか。
あと山本さんも会ったことはないけどメルカリないで。
確かに。
知ってます。
かぶってないですもんね。かぶってないというか。
僕はアメリカ行ってた時なんでね。
そうですよね。
で、なんだろう。
転職活動してたんでしたっけ?
いや、積極的には全然してないです。
そうですよね。
改めて、なぜTenXに来ていただいたんでしょう?
まとめると、個人の力をもうちょっと最大限に伸ばして、
それをチームとか組織のアウトプットにつなげたいなと思ってます。
どういうことかっていうと、
前職の最後の方にやってたテックリードとかEMっていうのは、
結構僕の技術力がどうこうっていうよりかは、
どっちかというとチームとしてどうアウトプットを高めるかっていうところに
一番力を入れてました。
で、当然すごい優秀なエンジニアも何人かいるんですけど、
別にそういう人がいなくてもチームとして、
どうやってアウトプットを出せるようにするかっていうのを工夫して、
結構それが意外に効率よくできるし、再現性がある仕組みとかも作れたので、
18:07
それはすごい良い学びだったし、良かったなと思うんですけど、
ただそれをやっぱりTenXに持っていくには、
当然チームとしての総合力も大事だけど、
それを生かす個々の技術力っていうのもすごい大事で、
僕は技術力はそんなに高くないので、
そこを伸ばすのが結果的にチームのアウトプットを一番高くするところかなと思ってて、
それがTenXですごい自分も勉強できるし、
それがちょうどプロダクトにも活かせるかなと思ったので、
良い環境かなと思って職活を考えました。
なるほど。
僕らちょうど良い環境がたまたまTenXに揃っていたみたいなところが大きい。
そうですね。
実際に入社していただいてみて、期待値と今働いてみてて、
印象とかギャップとかってどんな感じですか?
印象はそんなに勝手に抱いてた印象とそう言わないです。
ちょっと面白いしびっくりしたのは、
あんまり自立しすぎててプールリクエストをレビューし合う文化はないので、
当然大事なところはありますけど、
そこは個々人が格好をみんな信頼してるっていうプラの意図があるんで、
別に悪いことじゃないんですけど、それは面白かったですね。
なるほど。
今まで結構大企業、アメリカなんかはほとんど大企業扱いなんで、
結構大きいところでチーム割りキーでしか働いてなかったんで、最後の方は。
その点は全然スタートアップ感がないことに慣れちゃったから、
そういう意味で面白かったです。
そのうちのレビュー文化って、もうちょっと深掘りすると、
一切してないわけではないじゃないですか。
どういうところは抑えてて、どういうところは良しとしてるんですか?
2つぐらい観点はあって、やっぱりサーバーサイドの大事な実装はもちろん見てもらえますね。
コアな機能に関わるところとかは基本的には見てもらえます。
1つは、やっぱりプラットフォームの、人それぞれプラットフォームで強みを持ってる人は当然いるので、
例えばWebに強い人、日立屋さんとかは絶対Web強いし、
日立さんAndroidとか全員はそれぞれの強みがあるんで、
それに関することを業務をやるときは、プリクエストじゃなくても事前にアドバイスもらったりとかしてます。
21:05
なるほど。
全然してないだけじゃなくて、ちゃんと大事なところは聞くって感じですね。
一番大事な機能幹はしっかり、プロが横にいるからプロの力を借りて早打ちに対処して、
逆にコードベース単位ではそんなに細かく見ていくってことはしないみたいな感じですかね。
そうですね、特にそういうのは石川さんも確か言ってた気がするけど、
アーキテクチャーとかプラットフォームの特性を生かして、できるだけ仕組みで解決したいっていう思想はあって、
簡単に言うとFlutterとかは結構UIを宣言的に書けるっていうのがいい特徴の一つなので、
今までみたいにぐちゃぐちゃなコードを書いて、マグの面白いになるみたいなところは少なくなるんですよね。
そういうところはそれを活かせばレビューをそんなにガチガチにしなくても全然問題ないので、
大事なんですけど、仕組みで解決できるところはそれで活用して、
大事なところだけはレビューなりをして品質を高めるっていうやり方をしているだけな気がしますね。
確かに。そもそも人のミスが起きる余地をなくすための仕組みを作るみたいなのは、
うちのいろんなところに発揮されている部分ですよね。
そうですね。ただ、TenXにいる人はそもそもそれに気づく感度もすごい高いし、
なおかつ気づいた上で勝手に自分で直せるっていう技術力が高い人がいるから、
別に菱川さんが親切にそういうレールを用意しなくても気づいたら直ってるみたいな人が多いので、
そういう意味ではみんながテックリードだし、テックリードをわざわざ別にいなくても勝手に成り立つっていうすごいチームですね。
なかなかないのかな、こういうチームは。
そうですね、あんまり見ないですね。
これはなんかユニークで面白いですね。
ちなみにそのFlutterのさっきの事例のところで、多分これ聞いてる方にはエンジニアじゃない方の方が多いんで、
宣言的ってどういう意味なんですか、宣言的にUIが構築できるみたいな。
コードの書き方の話で、コードを読むだけでUIのどういう構成になっているか、
例えばここはボタンが表示されます、ここはダイアログが表示されます、
表示するコンテンツのテキスト内容がこういう情報ですっていうのが、かなりストラクチャーがコードにそのまま反映されるように書けるんですよ。
24:02
従来のやり方だとそんなには綺麗に書けないので、
例えば表示するコンテンツとどんなビューを表示するかっていう、書く場所がそもそも違ってたり、
あと場所が一緒でも書く量が多すぎて全然見にくかったりっていうのがWebとかアプリで問題になるところ。
それを解決したのが宣言的UIですごい見やすいっていうところですね。
なるほど、僕もXコードでちっちゃいアプリを自分で作ってみたことがあるんですけど、
GUI上でUIを描写できるっていう、おそらく開発の波動を下げるっていうメリットはあれにあったと思うんですけど、
複雑になればなるほど多分難しいんだろうなっていうのは素人目にも分かったから、
そういうところが解消されているのかな。
あと大事じゃないおまじないみたいなコードの量も当然多くなるので、
そういうのも結果的に少なく書けてるっていうのが宣言的UIっていうふうに一般的に言われてます。
なるほど、それは何か。
文字通り宣言した通りのUIになるっていう、それがコードにも反映されてるっていうふうにベストな状態ですね。
なるほど、ソースコードでいろんなものをちゃんと表現できてるってことになるわけですね、UIも。
それはなんかすごい聞いてるだけでも、新しい人が入ってきやすい。
あの口が減らせる。
オンボディングコストも当然減りますね。
そうですよね、すごい良いなと思いました。
あとはテイクスっぽさというか、バリューと業務のひも付きみたいなのを聞こうかなと思ったんですけど、
まさにさっきちょっと自立とかそういう言葉の仕組みの中に出てきてましたよね。
そうですね。
その辺がやっぱり開発している中で一番感じる部分ですかね。
開発、そうですね。基本的には3つのバリューは当然開発以外にも随時見られるので、
特に気にしてみなくても勝手に見えてるっていうところは多いですね。
なるほど。
一番どっちだろうな、テイクスからの逆算か、もしくは自立する、
もしくは背中合わせるのがどちらかがよく見られるかな。
北さんだと割と開発チームとのコミュニケーション、もしくはソフトウェア作っていくってところのプロセスに携わってる時間が95%ぐらいだと思うんですけど、
27:04
シリーズ定例とかいろいろある中で、事業開発とかViz側の動きってある程度納得できる形に見えてはいますか。
そうですね。まずこの会社で初めてなのはゲームミーティングの技術力が見えるので、
Viz以外でも事業の方向性とか、そもそもの2,3年のプランっていうのがまず見えるのが一番大きいです。
そこからいろいろ逆算してプロダクトとか事業開発の方向性が見えるじゃないですか。
なので全体の方向性が見えるっていうのがまず一番大きいと思ってるのと、
あと事業開発自体の話でも、今の場合だとStaylerのプロダクトすごい密接にひも付いてるので、すごい想像しやすいですね。
ちょっと聞いただけで、確かにこういうことは必要だなとか、こんなことをやらないといけないなっていうのはすぐ分かるので、結構透明性も高いし納得感も高いかなと思ってます。
確かに、事業開発とプロダクト開発はほとんど同じ車輪ですよね、2つっていうよりは。
あと意外だったのは経営ミーティングの技術力が公開されている会社、メルカリとかは公開されてないんでしたっけ?
僕がいたチームでは公開してないですね。
そうか、そうなんだ。
僕はこんなに数車でしか当たれたことないんで分からないんですけど、基本的には僕は見たことないですね。
僕らも始めから書いて残して後から振り返るようにするっていうのが基本的なすべての情報に対する態度で今まで取り組んできたから、
隠すものが、何を隠すべきかっていうのがむしろ分からないっていう感じなんですよね。
そうですね、僕が最後にいた会社とかだとやっぱり人数が多いんで、単純にそれがノイズになるっていうのがすごい多いんですよ。
2,3年の動きを知ってそれを考える時間より、もうとりあえず直近の1クォーターとか2クォーター分で自分たちで作った目標達成するのに集中するっていうのも大事なフェーズがあるんで、
そういう意味ではノイズになりうるかもしれないっていう意図で隠していることはあるかもしれないけど、
ただ僕がエンジニアリングマネージャーやってた時は上司はCTOだったりして、その立場でも経営ミーティングは見れないんで、今まで見たことはないですね。
30:00
なるほど、でもそうですね、一個付け加えるとやっぱり全員が長期のところに全別途してほしいなっていうのがありますよね。
今言われて思ったけど、そのデイリーとかウィークリーとかの積み上げでしかないから目の前を集中するのは大事なんだけど、
その向かう先が3ヶ月後のKPIをNにするとかではなくて、長期的に大きいビジョンが達成される状態にまっすぐ進んでいるかどうかっていうところを意識してほしいから、
あとその全体の方針というか、できるだけ多くのものが見えている状態にしたいなっていうのはありますよね。
そうですね、あとTENXでそれが成り立っているのは多分変化に強い、もしくは変化が好きな人が多いのが要因で、
やっぱり一般的にそういう結構スタートアップなんで当然方向転換も多分あるんですよ。
そういうのを日々メンバーに伝えると当然びっくりするし、自分の方向性と考えているのとちょっと違ってきたっていうズレとかも発生しているので、
それがマイナスの情報になったりも全然すると思うんですね。
でも別にTENXはちゃんとそれの意味も理解できる人がいるし、逆に変化するのは好きっていう人もいるかもしれないし、
そういう意味ではメンバーの体制というか、メンバーとしても多分透明性高いっていう状態がマッチしているので、そういう意味ではすごい良い環境ですね。
いやー、それ確かに。僕もすごく思うんです。自立とかにもあるんですけど、やっぱりみんなの経験と後は好奇心に助けられてるなと思うんですよ。
この会社どうなんだろうとか、この授業やってたらめちゃくちゃワクワクできるんだろうみたいな、たぶんその好奇心が下支えになってるなっていうのを感じることはあって、
それを満たせるのであれば、今作っているものを捨てることになるとか、あとは違うものを作ることになるとか、そのままにチャレンジするっていうのは、
その手段としてすごい楽しんでくれてるっていうのを結構感じる部分があったんで、
それは今来たさんで、あっ!って思いましたね。
確かに。僕自身そこはまだ慣れてないというか、あんまやったことないんですよ。
そういうことはそこまで多くなかったんで、今までないですけど、
でも今のフェーズだと全然あり得る話なんでね。
そこはやっぱり、特に例えばソフトエンジニアにとっては、やっぱり自分で作ったものを捨てるっていうのは悲しい時は当然あるんで、
それを理解した上でも、ちゃんと捨てて楽しんでるっていう人が多いなっていう印象ですね。
そうですね。僕も可能な限り何も捨てたくないんですけど、
時に捨てたことの方が、3ヶ月後の喜びに変わってるみたいなのはあり得る。
リファクターが少なく済むとか、ある気はするんで、
33:04
そこはちゃんといい意思決定できるといいなと思ってるし、
そこを意思決定できる石川さんがいたり、
それが妥当だって飲み込めるみんながいるっていう状況が、
うちの社員としての強みかなっていう気がしますね。
そうですね。結構面白いメンバーが元々いそうだなと思ってたし、
入社しても今でもそう思います。
そこはCodexに惹かれた一つのところなので、すごい楽しい環境だなと思います。
めちゃくちゃいい話で締まった気がします。
ありがとうございます。
そんなところかな。
今回そんなところで北さんと話しました。ありがとうございました。
ありがとうございました。
