00:01
アサヒさん、今日も宜しくお願いします。
宜しくお願いします。
このポッドキャスト、London Tech Talkは、時々名前の通りイギリス話とか海外転職とか、時々技術トピックをつまみ食いするような感じで話してきているんですが、
今日は、前からずっと呼びたいと思っていた最高のゲストの方に、ついに来ていただけることになりました。
簡単に、簡単に僕の方から紹介させていただくと、僕が前職で日本のオフィスからグローバルのオフィスに転職した際に、
転職先のSREチームのリードとして、僕のオンボーディングをサポートしてくれただけではなくてですね、
その後もことあるごとに、一緒にプロジェクトをさせていただいて、大変多くを学ばせてもらった同僚のお一人なんですけど、
私と大体同じタイミングで、
前職から転職されて、それまではSREとして長らくキャリアを積まれてきたんですけど、
その後、ソフトウェアエンジニアにですね、一種ジョブチェンジをしながらも、登壇されたりだとか、アウトプットされたりだとか、
活躍を続けられて、会社は別ですけど、いつも刺激をもらっている、エンジニア仲間でもある方なんですけど、
ということで、長くなっちゃいましたが、渡辺孝之さんです。今日はよろしくお願いします。
よろしくお願いします。
よろしくお願いします。
よろしくお願いします。
よろしくお願いします。
よろしくお願いします。
ということでですね、じゃあ簡単に、タカさんの方から、キャリア、自分の今までやってきたこととかについて自己紹介してもらってもいいですか?
はい、わかりました。名前は渡辺孝之で、タカさんって、我が妻さんが、我が妻さんっていうのはあれ面白いですよね。
私はケンって呼んでたんですけど、日本語だと苗字でさん付けになる現象、これの現象はちょっとなんていうかわからないですけど、
はい、ケンって呼んでたんで、ちょっと我が妻さんと呼ばせていただくんですけど、私の自己紹介としては、新卒ではNTTコミュニケーションズっていう国際通信のキャリアの会社で、サイバーセキュリティとかクラウドのPaaSとかIaaSみたいなのを主に開発していました。
イメージすると、社内の技術基盤みたいなのをよく作っていたチームで、データセンター、マルチセンターとか、そういうのを作っていたチームで、
データセンター、特定の場所は言っちゃいけないと思うんですけど、いろんな場所にデータセンターがあるんですけども、そこにサーバーをめちゃめちゃ持ち込んで、ストレージめちゃめちゃ持ち込んで、サーバーをラックにいっぱいねじ込んで、配線とか全部して、
それをその中にハイパーバイザーとか、ハイパーバイザーインストールしたりとか、その上にオープンスタックとかクラウドスタックとかを入れて、社内向けのPaaS、IaaSを構築するチームとかに所属しています。
03:07
で、その後は、それが2年、3年弱ぐらいだったんですけど、その後はCookpadでインフラ部とかSREチームに所属していて、最初の1年とか本当にいろんな事業、例えば料理教室とかCookpad Babyとか、あと広告事業部のインフラを見させていただいたりしてたんですけども、
2年、3年目ぐらいからはもう海外事業部に集中させてほしいということを期待して、
その2年、3年目ぐらいからはもう海外事業部に集中させてほしいということを期待して、その2年、3年目ぐらいからはもう海外事業部に集中させてほしいということを期待して、
その2年、3年目ぐらいからはもう海外事業部に集中させてほしいということを期待して、
そこからはずっと海外事業のSREとして働いていました。
で、その中で若妻さんと巡り合った、5円があったので一緒に働くことができて、今はそこから転職して、ロンチャブルという会社で普通にソフトウェアエンジニアをしています。
ロンチャブルに転職されたのが2022年のちょうど1月1日とかからでしたっけ?
いや、1月の中旬だったんですね。1日ではないですね。
まあ、中盤ぐらいだった。まあ、些細な違いですけど。
じゃあ、ちょうど1年半ぐらいですね。
うん、1年半ぐらい。
お二人が出会ったのは、このCookpadの国際事業部とかの時ですか?
そうですね。日本でちょっとなんていうか、名前忘れちゃったんですけど、海外事業部だったかな?みたいな名前だったんですけど、
日本でCookpadっていうとイメージするCookpadのサイトがあると思うんですけど、
それとは別に、
イギリスを拠点とした海外チームっていうのが、まあ、約100人弱ぐらいいたんですけど、私が所属してたときは。
あって、そこの開発チームで、私と若狭さんは一緒に働いてたという感じですね。
はい、そうですね。だから本当に、お世辞抜きで多分グローバルSREをゼロから立ち上げた人で、もちろん技術的とかに、他にも技術部とかインフラ部とか結構サポートしてくれた人がいるんですけど、カルチャー面というか、
ワークフローとか、まあ、なんだろう、マネジメント的な意味で、多分SREチームをグローバルの立ち上げた人。もうほんと一人目とかですよね、たしか、高さ。
そうですね、一緒に。
メンバーの採用とか、採用フローとかも作り上げていったんですよね、たしかね。
あ、そうですね。その、採用要項、募集要項みたいなのをゼロから作り上げたりして。
海外事業部がまだない中で、海外やりたいって思われたきっかけとかは、どこにあったんですか、ちなみに。
まあ、なんか海外事業部がないっていうのは、ちょっと違って、海外向けのプロダクトを作ってたエンジニアと、人が、まあ、何人かいて、まあ、それをもっと大きく広げようということで、まあ、そういう事業部ができたっていう感じで。
最初はね、あれなんですよね。我が妻さんちょっとご存じか分からないですけど、私が最初に携わった時は、日本。
06:05
東京のオフィスで。
アメリカとかいろんなところから人を採用して
海外事業を作ってたんですけど
2,3年経ったところぐらいで
イギリスに機能を完全に移して
イギリスのブリストルで
そこからはまた採用とか
一からやり直して
あの規模になったっていう感じなんですよ
だから私が転職するときも
タカさんにインタビューしてもらいましたよね
そうですね面接しましたね
僕の面接官ですよ
そこが最初の絡みですか
飯とか食べに行ってましたよね
そういうのが
いいですね
だからクックパッと転職するまでは
ずっとインフラ畑というか
ネットワークとかもやりつつ
インフラ畑をしてきてってことですよね
そうですね
なんかその
転職
転職するときに
ジョブチェンジをしようという気持ちと
ロンチャブルに行こうという気持ち
なんかどっちが先だったんですか
なんか自分の中では
あんまジョブチェンジしたっていう
いや周りからどう見えてるか分かんないですけど
ジョブチェンジしたと思ってなくて
っていうのは
ちょっとご存知だと思うんですけど
クックパッとのSREチームの人たちって
めちゃめちゃコード書くんですよね
ソフトウェア書くんですよね
でまあその
社内向けのソフトウェアとかも
それほど
そういうのが
それこそすごい書いて
それがいろんなチームに使われて
みたいな感じになってると思うんですけども
なんかそれと比べて
なんかやってること変わったかっていうと
別にそんな変わってなくて
もちろんそのオンコールが
スタートアップなのでオンコールがなくなったとか
運用の比重が少なくなった
みたいなことはあるんですけども
なんかこう
ジョブチェンジっていうほど
大それたものでもないかなという
お客さんが言ったら
社内の
エンジニアから
外の会社のエンジニア
世界中のエンジニアになった
ぐらいの違いかなと思ってますね
クックパッドのグローバルSRE
タカさん含め結構コード書いてましたもんね
そうですね
クックパッドのインフラ部の
インフラとかSREのチームの方たちは
基本めちゃめちゃコード書いてる人たちなので
サーバーそのラックに入れてみたいなのとは
程遠いですねイメージでね
その中でロンチャブルを選んだきっかけというか
他にもいくつかソフトウェア
サービス系の受けたりしたんでしたっけ
その中で決めた理由みたいなの
ちょっと聞いてみたいですね
そんなすごいめちゃめちゃ理由が
09:04
理由はあるんですけど
尊敬されるようなことではなくて
単純に2Cの
ソフトウェアを書くことが
ソフトウェアというかビジネスに
携わることが多かったので
次は2Bに行きたいなと思ってたことと
自分の専門がSREはもちろんなんですけども
CICD上の試験
ソフトウェアだとか運用だとかの試験が
自分の専門だと思ったので
CICD上の運用とかコード化に興味があって
それらの課題を解析するような
取り組みをしている会社を探していて
なおかつ機械学習をそこで使っていたらいいな
ということで探してました
なるほど
全てのピースがハマったような感じですね
ロンチャブルで
そうですね
ロンチャブルだけじゃなくて
あとは自分は結構グローバル志向というか
海外の会社で働くことを志向している
タイプのソフトウェアエンジニアなんですけど
イギリスの方では結構働いて
ヨーロッパの人たちとかも
アジアの人たちとかとはよく働いていたので
じゃあ今度は違うところ
違うカルチャーとか
アメリカの方に本社機能を持つ会社を探して
3,4社を応募して
全部オファーをもらえたんですけど
結局ロンチャブルに入社したという感じでした
ロンチャブルは日本の粒揃いのソフトウェアエンジニアが
日本で開発組織を作って入っていくみたいなイメージですけど
西海岸のソフトウェアエンジニアが
アメリカ側の
バーチャルオフィスなんで
物理的なオフィスがあるとは言えないんですけど
アメリカ側もないんですか
どうなんだろうな
多分ないと思うんですけどね
三ノ瀬に一応ヘッドクォーターのアドレスはあるんですけども
間違いなく日本にはないですし
ミートアップとかするときに別にそういうとこに行ったことないから
別にないんじゃないかなと
勝手に思ってるんですけど
一応住所は
三ノ瀬になっていて
ビジネス機能とかプロダクトオーナーとかは
アメリカにいますね
エンジニアは日本からも参加したりしてるんですけど
多分入社されたときは
ちょうどコロナの後半って感じだったと思うんですけど
実際にアメリカ側のメンバーと会う機会っていうのは
まだないんですか
ありましたか
いやありますあります
去年コロナ開けてないんですけど
リスクとかも鑑みて
ただ一回も会ってないんで
仕事するのはどうなのって思って
っていうのが多分あって
会った方がいろいろスムーズになるしっていうことで
二回オールハンズみたいなのをしました
一回はアメリカでやって
もう一回は京都でやりました
なので全員と会ってます
12:00
いいですね
アメリカ側にビジネスサイドの方がいて
日本にエンジニアがいるみたいな感じなんでしたっけ
そうですね
そういうふうに分けてる理由みたいなのってあるんですか
アメリカで売ってくから
アメリカを中心に売ってくから
アメリカに結構ビジネスサイドの方がいるみたいな感じですかね
そもそも共同のCEOが二人いるんですけども
その方々がそもそもアメリカに住んでるっていうことで
その投資家とかはアメリカにいますし
ビジネスも日本向けにやるっていうのではなくて
世界向けにやってるものなので
アメリカでビジネスとプロダクトとかを揃えてるのってのは
そういう理由ですね
CEOの一人に
ジェンキンスを作った川口さんという方がいらっしゃるんですけど
その方が日本とアメリカをつなげて
もっと日本と他の世界をつなげていきたいみたいな思考の方なので
私もどっちかというとそっちに近い思考を持ってるんですけど
そういう思考の方なので
エンジニア機能を日本に持ってるっていうのはそういう理由ですね
はい
川口さんが多分2020年ぐらいに
2010年ぐらいに
2010年ぐらいですかね
ランチャブルからこんにちはみたいなブログを書いて
ジェンキンスも作られた偉大な方で
その次のチャレンジとしてこんなのやってきますみたいなブログが
なんかちょっとバズった記憶があって
それがすごいパッションあふれるというか
それあふれるすごいブログで
それ見て僕も結構感動したんですけど
日本のエンジニアが技術力あるけれども
そこを主体として
こうしたチームを作りたいみたいな
なんかそんな感じが書かれていたようなことを
読んだことはありましたそれ
川口さんのブログ
いいですよね
感動しました
基本的にはそのランチャブルのプロダクトとしては
一つ大きなプロダクトとしてあって
その中に例えばいろいろな機能がついているって感じなんですかね
プロダクトラインとして
そうですね
プロダクト名は多分ランチャブルでいいんだと思うんですよね
ランチャブルというサースがあって
その中に
もしかしたら今日紹介するかもしれない
PTSっていう機械学習の機能だったりとか
テストの可視化
テスクのメトリックスの可視化の機能だったりとか
通知とかいろいろな機能が入っているっていう感じだと思います
結構周りの日本のスタートアップとかでも
ランチャブル使ってますみたいな
Twitterとかでたまによく拝見するようになってきたんですけど
そうなんですか
スタートアップで使っているのか
なるほど
スタートアップという語弊がありますね
ちっちゃいところでは使わないですもんね
そうですね
あんまりちっちゃいところでは使わないかもしれない
もともとがメタで
あれはメタ発祥ということっていいですか
15:02
PTSとかは
発祥はどうなんだろうな
多分ビッグテックと言われている
例えばGoogleだとかFacebookだとか
マイクロソフトとか
Facebookというかメタ社ですね今
そういうところは
なんだか
そういう共通の課題を持っていて
手値の手札を使って解決するみたいな
解決しているっていうところだと思うんですけど
その中でメタ社はその方法の一つを
Predictive Text Selectionということで
論文とかブログに出して紹介してるんです
どうやってやるかみたいな
そのPredictive Text Selectionを機能の一つとして
SaaSで提供しているという感じになりますね
ランチャブルは
うん なるほど
じゃあビッグテックが各社
機械学習を使ってテスト効率化するっていうのは
アイデアとしては誰もが考えそうなところ
ちゃんとパブリックに形あるように出したのが
メタでそれを元に広まっていったという感じなのかな
そうだと思いますね
ただもっと高度なことをやっている
と思いますけどね
実際出てきてないだけで
ということで徐々に
ロンチャブルのプロダクトの話に入っていったんですけど
改めてロンチャブルって何?みたいなリスナーの方もいると思うんで
タカさんの口から簡単に
プロダクトについて教えてもらってもいいですか?
はい ロンチャブルは
テストですね
ソフトウェアのテストですね
テストを最適化したりとか
あるいはテストにまつわる課題を解決するための
いろいろな機能を提供しているSaaSです
SaaSなので
こう
サインアップしてログインして
CLIの形式で
CICDパイプラインにインストールする形で
使ってもらうタイプのサービスなんですけども
簡単に使えるようになっていて
一応言語
どんな言語でも使えるように
ランゲージアグノスティックな感じで使っているので
例えばRubyを使っているプロジェクトでも
Goを使っているプロジェクトでも
ロンチャブルを入れれば
そのテスト関連のメトリックスが可視化できたりとか
機械学習を使ってこのテストの実行
実行の仕方を最適化したりとか
そういうのができたりできるサービスですね
なのでテストを書いてないとかっていうところだと
あんまり価値がないですし
テストが例えば
10個しかないみたいなところでも
あまり価値がないようなサービスですね
なので逆に言うとテストがいっぱい
例えばE2Eがいっぱいあるとか
テストの時間がいっぱいかかって
どこでどういうふうにかかっているかみたいな
回も検討つかないし
メトリックスとして
ヒストリーとして欲しいみたいなところだと
すごい役に立つサービスですね
18:01
例えばGitHub Actionとか
サークルCIでテストを回している中で
その結果とかプロセスの中で
かかっている時間とかを読み取って
それをAIで分析する
機械学習で分析するみたいな感じになるんですか
そうですね
一つ例を挙げると
多分GitHub ActionとかサークルCIが
いろんな方に身近だと思うんですけど
GitHub Actionのステップの一つで
LaunchableのCLIを実行するところを入れる
みたいなのがインストールの
インテグレーションのポイントだと思ってください
そのCLIに渡すのに
テストの実行結果みたいなのをLaunchableに渡すと
LaunchableのCLIが勝手にそれをAPI経由で
Launchableのサービスにどんどん蓄積していくので
それを使って
もしマシンラーニングのモデルを構築したりだとか
送ったレポートからMetricsを収集して
可視化する
時系列情報として可視化する
みたいなことをしていたりします
テストとランナー自体は何でもいいんですよね
何でも大丈夫ですね
サークルCIだろうが何でもよくて
ランナー自体は提供しなくて
そこのテストの結果とか
実行すべきかどうかみたいなレスポンスをAPI経由で返す
CLIの中のバイナリが通信して返すみたいな
ステップの一つに挟んでる感じですよね
正確に言うと
JNITレポートみたいなXMLのレポーティングの
仕様じゃないんですけど
有名ないろんなテストランナーで採用されてる
レポーティングのフォーマットがあるんですけども
それを採用してる
例えばRSpecとかCoreTestとか
そういうのはITestとかね
そういうのは普通にレポーティングをその形で出力するみたいなのを
オプションで指定するとそのファイルが書き出されるので
その中身をロンチャブのCLIに渡せば
勝手にデータが飛んできます
ロンチャブのSaaSに貯められますし
それをテストランナーが対応してない場合も
別にこのフォーマットで書き出せば
ロープロファイルっていうフォーマットで提供してるんですけど
そのフォーマットに書き出せば
ロンチャブ側でヨシナに蓄積しますよということになってますね
なのでやろうと思えばどのテストランナーでもできますっていう感じです
JUnitとか決められたスペックだけじゃなくて
ローデータでも対応してるっていうのはなかなか面白いですね
それは本当に
でもある程度こう求める
ある程度フォーマットはこれに従ってくださいみたいなのはありますね
なるほどね
なんかそのJ例えば
メジャーなね
メジャーな言語のメジャーなフレームワークは対応してると思うんですけど
Language Agnosticということで
言語対応言語を広めていく的な意味で
例えばちょっとマイナーな言語の有名なフレームワークに
21:04
JUnitのサポートを入れるみたいなのは
ランチャブル的には
いや別にそうか
ローデータも対応してるから
そこにプロアクティブにやっていくというか
って感じはなくても全然いいのか
まあそのUpstreamに貢献するっていうのはもちろん
コミュニティ的にも
会社的にもやってもいいかと思うんですけど
今のところなんだろう
普通に
結構対応してるんですよね
そのJUnitフォーマットっていうのは
だいたい対応してるみたいな感じで
お客さんが必要じゃないなら
別に喫緊でやる必要もないので
やってないっていうだけなんですが
もし必要があればやるかもしれないですね
なんかその今ロンチャブルの体制的には
そのお客さんに売り込んでいくセールスの方とかがいて
あと本体機能開発タカさんたちみたいな
多分ソフトエンジニア部隊がいるってと思うんですけど
ソリューションエンジニア的なポジションってあるんですか
ソリューションエンジニア
ちょっとあの逆があったらあれなんですけど
カスタマーサクセスみたいなチームはあるんですけども
例えばAWSのソリューションアーキテクトとか
あるじゃないですかそういう
よくある外資のソフトウェアのソリューションアーキテクト
みたいなポジションはないですね今は
カスタマーサクセスチームはどこら辺がスコープなんですか
カスタマーサクセス
ちょっと難しいんですけど
一部エンジニアがオーバーラップしてやってたりもしてるので
ちょっと難しいんですけども
基本的にはお金を払ってくださってるユーザーとか
直近で払ってくれそうなPOCの機関で
お金を払ってくれそうな会社のファーストコンタクトとして
対応してます
一番最初のプライマリーコンタクトで
そこでなんかこうもし深く技術的にわからないことがあったら
エンジニアにボールが来ることもありますし
いろいろやり取りするっていう感じですね
なるほど
面白いですね
なかなかこうCICDテストっていう業界によっては
かなりエッチの聞いたことをやってる印象なんですけど
例えば自社でテスト書き溜めてみましたと
テストの実行時間がだんだん伸びてきて
例えばロンチャブルみたいなツールを検討しようかなってなった時に
テストのケース数というか
自分たちこれをロンチャブルの
モデルを入れると利益になるのか
それともテスト数が少ないみたいなのって
何か目安となるようなテストケース数なのか
何なのか実行時間なのかってありますか
それともそういう時はとりあえず
ロンチャブルの中の人に連絡して
24:01
見てもらって
これはメリットがありそうだね
そうじゃなさそうだねみたいなのを
判断してもらう感じになるんですか
いやなんだろう
テストの待ち時間って
結構主観的だと思うんですよね
絶対値っていうよりは
例えば私が1時間待っても全然大丈夫なエンジニアだったとしても
我が妻さんが1時間は長すぎるっていうエンジニアかもしれませんし
朝井さんはいや1日だとか1週間だとか待てるよテスト実行
みたいなエンジニアかもしれないじゃないですか
それって別に共通の普遍の価値観ではないと思うんですよね
人によって違う
だからテストチームとかメンバーによるんじゃないですかね
もしテストの実行時間が自分の開発プロセスの中で長いと思ったら
一向の余地があるっていう感じだと思うんですね
例えばうちのチームって10人もエンジニアいないんですけども
年間で言うとロンチャブル使ってるんですけど
自分たちで使ってるんですPTSのロンチャブル内で
年間で言うと多分
何時間だっけな
2000だか3000時間だかわからないですけど
テストの削減してるんですよね
テスト時間10個時間
それが大きいかどうかは人それぞれっていう感じですし
マニュアルサイズの次第ですね
実際にマシン
例えばサークルCIとかGitHubアクションズとかって
重量課金なので
マシンリソースマシン時間使っただけ課金されると思うんですけど
その分お金を払わなくて済むんですよね
ロンチャブルを使うと
ロンチャブルの課金モデルって今のところは
コンピューティング時間
マシンアワーズって言ってるんですけど
削減したマシンアワーズかける0.7だっけな
ちょっと忘れちゃったんですけど
具体的な計算はわからないんですけど
それに対して課金するので
減らした分の何パーセントかもらえますよみたいな感じなんですよね
だから損することは絶対ないんです
ウィンウィンですね
いわゆる成功報酬モデルみたいな形ですね
そうですね
なのでEC2で1000ドル払ってて
その分をロンチャブルに700ドルくださいみたいな感じなんです
削減1000ドル削減したら700ドルくださいみたいな感じのモデルなんですよね
いいですね
必ずどちらにも利益が出るみたいな削減されれば
削減されてなかったらもちろんお金は取らないですし
すごい
ちなみにテストの結果を見て
このテストは削減できるねってなった時に
その後次以降のテストで削減されるテストを決めるってことですよね
どうやってその次以降のテストで削減する提案をするんですか
そこが機械学習を使ってるところで
27:02
ある一定期間テストの実行結果みたいなのを送ってもらう必要があるんですよね
過去の実行結果とか
過去どれくらい時間がかかってただとか
あるいは変更があったとか
そういう情報を全部送ってもらうので
機械学習にそのデータをもとに機械学習がトレーニングされます
それを使って推論するので
このテストを実行したらどれくらい時間がかかるとか
このテストを実行したらこのくらいの確率で失敗するみたいなのが
蓄積されてるんですよね過去のデータから
なのでスキップしたのもこれくらい時間かかるから
これくらい削減できましたよねみたいな
そういうのが推論できるっていうことですね
あとはLaunchableでオブザベーションモードっていう機能を提供していて
それを使うと実際に例えば80%だけ実行したら
どれぐらいの効果が期待できますかみたいなのを
可視化できるモードがあるんですね
実際には100%実行するんですけど
全てのテストを実行するんですけど
全てを実行するんじゃなくて
80%その中で実行したときにどれぐらい削減できたりとか
どれぐらいテストのフェイルをキャッチできますかみたいなのを
可視化するモードをオブザベーションモードと
Launchableで言ってるんですけど
そういうモードがあって
それをすれば
混ぜ込めばこれが効いてるんだ
Launchableが効いてるんだなとか
Launchable効いてないからやめようとかっていう判断は
そこでできるという感じです
なるほどなるほど
だから100%実行しつつ
裏側でLaunchableの数量も動かして
結果を見比べることができるみたいな
ABテストというか
そうですね
ABテストっていうか
まあそうですね
意地的にやるみたいな
意地的にやるみたいな
便利ですねそれは
入れる前にどれぐらい効果があるか分かると
そうですね
だいたい入れる前に
つべこべ言わずに入れろっていう人もいるんですけど
そうではないことが多いので
効果測定みたいな
どれぐらいの効果が期待できるかみたいなのを
オブタレーションモードを使って
可視化して
いろいろして
めちゃめちゃ効くねとか
あんまり思ったより効かないねとか
っていう話をしてますね
それやってみたいですね
ちょっと気になります
手軽に入れられそうなんで
めっちゃいいですね
なんか個人的にこれすごい
気になってるんですよね
個人会社を代表した意見じゃ
基本これ全部
個人会社を代表した意見じゃないですけど
ほんとそっちが長いんで
なんかいいなと思って
そうですよね
そのさっき言った
その私なんか20分でも長いと思ってるぐらい
PR上だったら
30:00
言い継ぎとか20分だったらめちゃめちゃ早いと思うんですけど
PR上で20分待てって言われたら
なんかもう違うタスクに始めちゃうじゃないですかきっと
なのでコンテキストスイッチが増えるので
減れば減るほど嬉しいですよね
プログラミング言語は何でも関係ないっていうことだったんですけど
プログラミング言語のランタイムによって
特徴があったりするじゃないですか
例えばGoだったらルーチのテストがあるとか
スナックトレースとか
そういったものを逆に例えば
じゃあGoはGo専用のモデルにちょっとこう
なんだろうね
追加でちょっと手を加えることによって
そこのその推論の最適化できるみたいな
そういうケースとかもあるんですか
基本的には
いやどう
なんだろうな
いやその
これこのテストスイートが
Goですっていうのは
もちろん機械学習側は理解してます
なのでそれが貢献するかどうかは
ちょっとわからないんですけども
一応使ってますそういうの
多分ここら辺の分野っていうのを
マシンラーニングにおいてもこう
今まさに研究したり
それをプラクティスに入れて
試してみたりみたいな
本当に最先端の領域
みたいな感じなんすかね
ちょっと LLM とか
そこもはやっているような
機械学習の分野とは違うんですけども
それでも その
購買ブースティング
ディシジョンツリーみたいのを使ってるの
で
機械学習の一種まあ
LLMだけじゃない
機械学習っていうのは
タカさんはこの
BTSプレディキティブティションの
部位にかかわっていらっしゃるんですかseldk.slds.net
перcenta o
したくて
あの負けの同士は
なるべく
そうですね基本的に全メンバー関わっていると思いますけど
私も最近変わってますね
じゃあ特にチームとかがあるわけじゃなくて
自分ができる分野にやるみたいなそういう感じですか
開発体制としては
開発体制はエンジニア分けるほどでもない人数なので
だいたいプロダクトオーナーとかエンジニアリングチームのボスが
月に1回このマンスリーサイクルって言ってるんですけど
この月はこれをやっていくぞみたいなのを議論して
最初の月の初めにリストを書かせてくれるんですけども
これを元にここはこの人がやっていこう
ここはこの人がやっていこうみたいなタスクのアサインのされる方をするので
その時に応じてやることが変わるっていう感じですね
自分は幸いいろんなことをやらせていただいているので
フロントエンド書く時もありますし
フロントエンド書く時もありますし
インフラはもちろんやりますし
API書くこともあるし
最近はマシンランニングのモデル周りをいじってたりしますね
かなり幅広いですね本当に
フロントからSREみたいなところまで
全部対応していくみたいな感じなんですね
33:02
そうですね
あとはこれは過去の実績的に仕方がないところであるんですけど
私なんかクパッと似た時にGDPRの対応とかしてたんですけども
それに似たようなSOC2っていう
GDPRのコンプライアンスのフレームワークがアメリカにあるんですけど
それを対応してないと契約がスムーズに進まないみたいなケースがあるんで
それの対応とか
最近なんかやったかみたいなフェーズに来たので
他の人たちは何をやってたか多分知らないんだけど
めっちゃ大変じゃないですか
やったかっていうところまで来ましたね
それははい
なんか僕もどこの会社とは言えないですけど
過去それで1回申請ミスっていうことを経験してるので
なかなかSOC2大変ですよね
なんかスタートアップシリーズABあたりの
何でもやれることは手当たり次第にするみたいな
本当楽しい
人によっては楽しい時期ですよね
そうですね
逆にそれが嫌いな人はちょっと合わないフェーズじゃないですかね
多分ね
分からないけど
それはなんか大きなところと小さいところの良し悪しだと思いますけど
高さんもクックパッドにいらっしゃいましたけど
グローバルの立ち上げみたいなもので言うと
実質ゼロから作り上げていくみたいなフェーズだったと思うので
もしかしてそういうのがお好きなんですかね
どうなんでしょうね
嫌いではない気がしますけどね
機械学習をやりたいみたいな思いがあって
ミスした
というのも一つあったと思うんですけど
機械学習とかってもともとそういう開発をされてたんですか
その反映される前から
それとも反映されてから結構主に始められたんですか
機械学習の
機械学習のロジックとかモデル構築みたいのは
入社する前はやったことなかったです
ただ海外チームで機械学習すごい人たちがいっぱいいたんですけども
その人たちと身近で働くっていうのはありましたし
私なんか数学学研は
結構好きなんですけど
そういうのもあって別にやらせてくれっていう感じだったので
そういうところを探してたっていう感じです
じゃあ実際にやってみたいなっていうのかなり思いが強かったから
結構すんなり入れたっていうところはあるんですかね
そうですね
ただできて
派手なイメージはあるので
いやだからでもあれですよ
私はペイペイなので
まだ修行中みたいな感じですよ
すごいね
ちゃんとすごい方がちゃんとやってるので
その辺はその人と一緒にやりながらっていう感じですね私は
そういう方々も日本でやられてるんですかね
その機械学習の開発とかも
36:00
そうですね
そうです
すごいな
何かのエリアのプロフェッショナルが集まって
お互い教えないながら
刺激を与えながらやっていく超楽しいフェーズな
外から見てそういう印象を持ってますね
うんうんうん
皆さんはインフラも強かったけど
機械学習とか新しいところも学びつつ
そうですね
プロダクト的にはインフラっていうよりは
プロダクトのフィーチャーだとか
運用周りの行動確保がよっぽど重要な価値があることだと思うので
そっちの方に大幅に時間を使ってますけどね
私はSREという都会インフラをやるっていうよりは
決定義というかXGBOOSTとかね
LightGBMみたいな機械学習手法みたいなのが
アドテックでも使ってたんでちょっと懐かしい
あーそうですよね
僕アドテッククックパッドのグローバルSREに入る前は
アドテックやってたんで
なるほど
アドテックのロジックまでは知らなかったけど
そっかバンデットとかでやってて
そういうところまでやってたんですね
バンデットもありましたね
うん
よく使われるやつだと思うけど
どの広告を出すのが一番クリック率
CTRが高いかみたいな話なんで
実際にね
あのやっ
試作と成果がこう
見れるから面白い分野ではありますよね
測定可能であるから
数字としてもろに出てくるんでね
面白いですよね
これ
以前もタカさんとチラッと雑談したときに
触れたと思うんですけど
結構そのテストを
あの
不要なテストは走らせないっていう
一つこう
なんて言うんでしょう
メンタルモデルを大きく切り替えるというか
そうですね
それが結構
メンタル的な
ハードルになる開発者も
なかなかいるんじゃないかなと思って
そちらの方が多い
数字を見せて
論理的にはこれ意味ないからスキップする
というのがメイクセンスだよね
もちろん分かるとはいえ
でも全部テスト走らせた方が
安心するんだよねっていう
エモーショナルな部分を乗り越えていくのって
結構難しいのかなと思ってるんですけど
実際難しいと思いますね
はい
いやなんか
いや走らせろよって感じじゃないですか
そうですよね
いやそれはそう思いますよ私も
実際そう
ただまあ
それをケアする方法とかも別に
ありますし
そもそもこう
こういう処方が生まれてきた背景として
想像できないかもしれないんですけど
全部の実行が
そもそもできないっていうところあるんですよね
いっぱい
多分いっぱいあって
自分の今の
多分お客さんのロゴに書いてあるから
大丈夫だと思うんですけど
そのBMWさんとか
そういうところだと
39:00
すごいテストの量多いんで
そもそも全部実行すると
もう何日も何週間もかかっちゃうみたいな
とかあるんですよね
それを待てるか待てないかって話です
だから例えば
私はなんかこう
年に2,000〜3,000円とか
何時間削減できてハッピーですみたいなこと言ったけど
そういう話じゃないですよね
そもそも
待ってたら開発進まないみたいな
そういうペインがあって
そういうところで使われる機能だと思いますね
メインはそういうところ
でただまあ
その普通の開発のプロセスの中でも
例えばプロデュクションの中では
こうPTS使って
そのリリースブランチみたいなところでは
全部のテスト実行すれば
そこでセーフティーネットを確保できるんで
うん
そういう使い方もありますよね
プロデュクションの中での
リードタイムが減る
そのマージまでのテストを待つことによる
リードタイムが減って
で
その
アクセシティっていうか
何だって
テストをこう
網羅的に回すのは
リリースブランチでやるみたいな
のを
そういう方法を使えば
運用の仕方ですよね
CICDの運用の仕方で
そういう風な戦略を取れば
いいとこ取りできるみたいな
モデルもあるので
そこはなんかこう
どうしても使ってみたいとか
そういうセーフティーネットがあるんだったら
使ってもいいかなみたいな
ところだと
ピタッとはまるかもしれないですね
そうですよね
これ逆に
なんだろう
メンタル的なハードルはあるとはいえ
数字としてがっつり出ちゃうんで
エンタープライズとか
大きい会社に入れるってなった時には
トップダウンでは入れやすい
提案しやすいかなと思うんですよね
多分トップダウンで
うん
数字としてこんなに出るし
売り上げレベルに対して
こんだけコスト減らせるんだから
入れましょうっていう風に
提案をしやすい気はする
多分
CICDのパイプラインを
いじる必要があるので
その辺に明るい人とか
あるいはその辺の
トップダウンで意思決定できる人だと
入れやすいかもしれないです
逆にめちゃめちゃ遠いと
CICDパイプラインは
他のチームが管理していて
その人とネゴシエーションしなきゃいけない
みたいになってくると
ちょっと売ってなしくなってしまう
社内政治がね
必要になりますよね
社内の
例えばCICDチームが
例えばインフラチームみたいな
参加にいて
そこがコストも持ってたりすると
多分動きやすいと思うんですよね
インフラコスト持ってるから
モチベーションがマッチするじゃないですか
だけどインフラ全体のコストを見る部隊と
テストインフラ部みたいなのが
また別のデパートメントでとかになると
ちょっと
いやそうですね
だから
組織の形とかにもよりますよね
だから入れやすい入れにくいとか
42:01
みたいな
削減するテストの中に
もしかしたら
本当は
実行しなきゃいけないテストみたいなのが
ないことはないと思う
もちろんありますね
そういう場合のフィードバックみたいなのって
受けることはあるんですか
本当はこれしなきゃいけないんですか
これしなかったなみたいなのを
より精度を高めていくために
フィードバックを受けて
みたいなことはするんですかね
一応
マシンラーニングのモデルの
コンフィデンスっていうのを出して
ちょっと回答になってるか分かんないですけど
100%は
全てのテストを実行する
90%は90%のテストを実行する
そのコンフィデンスのパーセンテージを
いじるのは
入れた人の
その
責務なんですよね
外れたときは
10%に入って
10回だったら9回は成功するけど
1回はスリップするんで
見つけられないので
そういうものなんですよ
それを検知したい場合は
さっき言ってたオブザベーションモードみたいなので
本当は
実行したほうが
よかったんだけどスリップしました
実行しなかったから
テストのフェイルを
検知できませんでしたみたいなのを
可視化することで
その組み合わせですかね
なのでリスクもある程度
許容してもらう必要もあるし
オブザベーションモードみたいなので
可視化しながら
納得してもらうみたいな感じ
実行してないテストの結果を
もらうことはできないので
不可能なので
それはできないという感じです
理解しました
そのコンフィデンスっていうのが
つまりリスク許容度みたいなことですよね
そうですね
それを選んでもらうっていう感じです
だから99%
例えばでも
99%にしただけで
めちゃめちゃほとんどのテストを
カバーできるみたいなケースもあるんですよね
だから1%実行しなかっただけでも
ほとんど
99%っていうのは
99%キャッチできるっていうのがあって
99%テスト実行するっていうのじゃなくて
だからポーションは変動するんですけど
実行する
だから99%でも
もしかしたらテストを1%のテストで
コンフィデンスが99%かもしれないケースもあるんですけど
稀なんですけど
そういうケースもあって
その場合はめちゃめちゃお得です
便利ですね
そのコンフィデンスレベルは
ランチャブルCLIのフラグかなんかで
簡単に変えられるんでしたっけ
そうですね
オプションで渡せますね
いいですね
ハイファンフィンコンフィデンスみたいなのがあって
確かに
それで渡せる
いいですね
なんかテストの実行って別に
プルリコマージする時とかだけじゃなくて
いっぱいあるから
例えば
なんか考えてたのが
プルリコマージする時は
コンフィデンスレベルを落として
つまりその
なるべく早くするんだけど
45:01
例えばそのテストを
同じテストスイートを
例えばなんかカナリーでデプロイするみたいな時とかには
なるべくこうたくさんのテストを一応ね
セーフティーネットとして実行させつつみたいな
なんかそこら辺も
どこでテストを実行させるかで
コンフィデンスレベルを上げ下げすることによって
まあ
複数のポイントにおいて
まあ全体的の
なんだろう
レジリエンシーをそこまで損なわせずさずに
でもインフラコストも削減するみたいな
なんかできるんだろうなっていうのなんか
今聞いててちょっとワクワクしながら聞いてたんですけど
そうですね
まあその辺はなんかこう運用者のこう
さじ加減ってか
あの力の腕の見せ所っていう感じだと思いますね
これいろいろできそうだな
本当面白い
だからパフォーマンステストで
これ使いたい
みたいな人もいて
例えば
確かにね
パフォーマンステストを毎回
なんだろう
なんか100%やると大変じゃないですか
めちゃめちゃ時間もかかるし
サーバーリソースもめちゃめちゃ食うし
だけど
なんか毎回全部やるんじゃなくて
なんかこう
こけそうなやつをやるみたいな
まあそういう風にも使えるんですか
そうですね
そうですね
使います
このLaunchableのプラットフォーム側にある
その機械学習のモデルを
ユーザーが何らかの
形でリードしたり
ライトしたりできることってある
例えばですけど
Launchableを導入した企業の中に
機械学習エンジニアがいて
彼らが例えば
ドメインコンテクストを入れて
もっとチューニングしてみたいみたいな時に
はいはい
ファインチューニングみたいな時に
そういうのはないですね
そういうのはないです
今のところはそのCLI経由で
入れたデータを元に
トレーニングしてそれを使ってもらう
お客さんごとに使ってもらう
っていう感じになってます
確かにね
そういう要望はあるかもしれないですね
そうそれができると
できる会社そんなないかもしれないですけど
それをしたところで
本当に良くなるのかは知らないですけど
なんかできたら面白いというかかなと思って
あとは面白いところで言うと
あのテストのデータをもらってるんで
あんまり気にしてないこととかも
Metricsとしてもっと
やってるんですよね
例えば過去にこうなんかなんだろう
例えばですけど
過去半年1回も失敗してないテストがありますとか
でそれがなんか1回実行に1時間かかります
とかだったら
それ実行する必要あるんですか
みたいなあるじゃないですか
ほぼ100パー通るけどみたいな
そういうのは別に削除するなり
実行頻度を減らしたりとかできると思うんですよね
まあそういうMetricsをこう
可視化したりとか
48:00
あるいはこう
なんか異常に時間がかかってるテストみたいなのを
なんかロンゲストテストって言うんですけど
そういうそのランキングテーブルみたいなのを
まあ公開したりしてるんで
まあそういうMetricsをこう
もらったデータから
こう炙り出すみたいなこともやってたりするんで
まあそういうところもちょっと面白かったりします
まあその中には
改正もできるみたいなその結果をもとに
そうですね
あとなんかその
これは機械学習
とは言わないんですけど
そのフレイキー
フレイキーテストって言ってあって
そのテストを実行したら
成功したり失敗したりするテスト
フレイキーテストって言うんですけど
ユニットテストレベルだともしかしたら
そういうのあんまりないかもしれないんですけど
インフラ周りのソフトウェア書いてたりとか
あるいはいついいテストとか書いてたりすると
フレイキーなテストってよく
まあないのが理想なんですけど
よく出てくるんですよね
でそういうのって
まあなんだろう
人によってそれがフレイキーなテストって言うと
フレイキーじゃないテストかって
分かると思うんですけど
まあ初めて触った人とか
初めてなんかオンボードして
それフレイキーだから無視していいよ
みたいなことってよくあるじゃないですか
あるんですけど
それってかなりドメイン知識が要求される
というか知らんよっていう感じなので
テストこけたら
なんでこけてるのって見ちゃうじゃないですか
そういうのをスコアとして可視化していて
CLIとしてはそのスコアが
これ以上だったら無視する
実行しないようにしてくださいみたいなのとかもできたりしますね
いやありがたいですねそれは
初めてチームに入った人でも
ああこれ無視していいんだっていうのが分かったりして
いいですね
なんかこれ思ったんですけど
こう開発者が書いてテストスイート書いて
ロンチャブルを入れてみたけど
なんかいつも自分の書いたテストがロンチャブルにスキップされるんだなってことは
そのテスト書いてあんまり意味なかったってことですよね
そういうことです
ただ書いた直後は
実行結果も少ないし実行されますね
でこの人
例えばTDDとかで踏襲してると
実装の前にデザインテストデザインして
こういう動作を期待して書くじゃないですか
その通りにコードを変えて実行して取ったら
Goみたいなフロー
TDDを使ってる人はやると思うんですけど
その時に書くコードってユニットテストだから
のことが多いからそんなに時間かからないかもしれないけど
ほぼ失敗しないんですよね
私の経験でそれほぼ失敗しないです
一回書いてあったら
なんかこうロンチャブルさんに
どうぞどうぞ
なのでそれは多分さっき言ってた
ネバーフェイリングテストにカテゴライズされるテストですね
一回書いたらもう一生失敗しないテスト
消しても良くないみたいな判断ができたりします
実際は消さないんですけどね多分ね
51:01
まあね
だからスキップしたいとかですね
それ実行する必要ないからみたいな
結構そのいろんな各社のスキップできるできないのテストのパターンとか
見えてくると思うんで
なんかそこら辺でもなんかロンチャブル中長期的には
なんかポジション取れそうですよね
なんかこういうテストはもういらないから書かなくてもいいよみたいな
提案とかできそう
もしかしたらできるかもしれないですね
まあただ現実はこうなんか
CICDとかこれがなんかゴールデンパターンですみたいな
こう机上のセオリーみたいなのあるけど
実際各社全く違うのが面白くて
全く違うんですよね
全く違ってこうなんか
よくあるとか言っちゃうともう良くないよみたいな
そんなパターンよく別にないからみたいな
実際を見てみると実際はそうです
現実を見るとその
あのまあ各社
異なるCICDパイプラインとかテストのフローを
フローで運用しているので
まあいろんな試験はやられるんですけど
まあ共通化はちょっともしかしたら難しいかもしれない
結構お客さんから要望を受けて
新たな機能を開発することとかもあるんですか
こういうのが欲しいなって言われて実装してみる
それはすごいありますね
お客さんのフィードバックは一番
機能追加としてはすごい重要なので
すごい効いてますね
ですしそれを元にもうさっと
直せたりさっと追加できるものが
エンジニアの方でさっと実装したりしますし
ちょっと難しいものはプロジェクト立ち上げてやったりとか
あるいはまあ普通にユーザーインタビューとかして
お客さん既存のお客さんに
こういうペインはありますかとかそういうのを聞いて
実際に次のプロダクト開発に生かすみたいなのをよくやってます
なるほど
いやー面白そうだな
これ絶対入れたい
入れてくださいよ
私が押しかけるんで
絶対入れたい
英語英語で全然
英語日本語両方対応してるんで
日本語はうちの場合は必要なんでもう英語で大丈夫です
そうですねはい
いやーいいなー
めちゃくちゃ面白いですねこのプラットフォームランチャブル
確かに入れて損することないって感じでしたもんね確か
ましいといえばその
CICDパイプラインをいじるパワーがないときついっていう感じですが
あーそうですね確かに
まずはテストをかけって言われるかもしれない
馴染みがないからあとはこう説得するのが難しいかもしれないですねだから
なんなんそれみたいな感じかもしれない
うん
なんか本当にこうテストの知見が溜まっていく場所だと思うんで
54:01
なんかこうランチャブルのプロダクトがどんどん大きくなって
世界全体のこうソフトウェア産業に大きく貢献していくっていうのが
なんかこうロンチャブルのプロダクトがどんどん大きくなって世界全体のこうソフトウェア産業に
大きく貢献していくっていうのが
無駄を省いてなんか地球にも優しそうなビジネスですねこれは
そうですねなんかマシンラーニングとかもこうなんか
とりあえず買って回せみたいな感じになってるじゃないですか
そのハギングフェイスとかはこうなんか
ここで共有することでそのCO2を削減してみたいな書いてあるけど
現実は多分そうではないので
そうですよねその地球に優しくありたいですね
エコエコうん
そうですよねその地球に優しくありたいですね
最近のトレンドですけど環境に優しい
まぁそこはあんま主張してないんですけど
そこはあんま主張してないですけどはい
間接的にはそういうところもあるかもしれない
いやー素晴らしいいやロンチャブル
なんか聞けば聞くほどもうこれは使うしかないという感じになってきたんですけど
なんか浅井さんの方でもう少し聞いておきたいことはありますか
そうですねあのまあ海外とかに興味があるというか海外志向がかなりあるということで
今後なんですかね今日本で働かれてて
海外に行こうとかもしくはもっとなんですかね英語を使っていこうみたいな
そういうなんか展望みたいなのがもしあれば教えていただきたいです
なんか場所は今のところあんまりこだわってないんですけど
基本的にはなんかあんまり英語で働くことは
まぁ一番重要、重視してますねっていうのはまぁ
LLMとか出てきてるからその壁ももしかしたらもうすぐなくなるかもしれないですけど
いえいえ一番使われてる自然言語は英語か中国語だと思うんで
ソフトウェア界隈では産業では
なので英語使っててしょうがないっていう感じなので
英語を使える会社しか多分選ばないと思いますね私は
今も結構じゃあ基本的には英語を使うんですか
開発する時とかも
日本人と話す時はもちろんチャットとかは
チャットとかスタンダップとかは英語でやってるんですけど
なんか別にワンオンとかオフサイトで
日本人しかいないんだったら別に日本人でも
確かにそれはそうですね
そうですねそこで英語喋ってたらおかしいんで
なのでただ公用語は英語なので
普通にスラックとかコンフレンスを使ってるんですけど
うちはブログとか試験共有で
そこは全部英語で書いてます
いいですね
なんかキャリアの展望としてはしばらくICとして
活躍していくぞって感じですか
そうですね
そうですねなんか
リードとかもやって
ICによくある振り子モデルっていう
呼ばれてるやつがあると思うんですけども
自分もリーダーとかマネジメントとかもやってきたので
一回しばらくICで集中して
57:03
もしなんかマネージャーとかリードのレイヤーをやるんだと
多分自分は起業するんじゃないかなと思いますけどね
いいですね
いやー素晴らしい
最後にタカさんのキャリアの展望も聞けたというところで
そろそろクロージングに向かっていこうと思うんですが
最後に枠を使ってもし宣伝したいこととかあれば
そうですね
ロンチャブル絶賛売り出し中ですが
ロンチャブル絶賛売り出し中ですからね
ロンチャブル絶賛売り出し中ですので
SaaSなので日本の企業でも普通に使えるので
もしちょっと試してみたいとか
本当にちょっと試してみたいとかでもいいので
もし興味がある方は私にご連絡ください
TwitterのDMでも
多分自分のサイトでメールのアドレスも公開してると思うんで
何らかの手段で私に声をかけていただければ
普通に気軽に導入の支援させていただきますので
ご連絡くださいっていうのと
あとはロンチャブルが
実は1年ぶりにソフトウェアエンジニアのポジションをオープンしたんですよね
それまで私が入った後はもうずっとクローズしてたんですけど
ただ最近ポジションをオープンしたので
もし英語でソフトウェアを書きたい
日本にいながら英語でソフトウェアを書きたいっていう方がいらっしゃったら
すごい楽しい環境だと思うので
ぜひぜひ応募くださいっていう感じですね
後でリンクは共有しようかな
多分ただ枠は多分そんなにないと思うんで
それだけははい
ご了承くださいっていう感じで
めちゃくちゃ熱いですねそれは
たかさんと6回働けるチャンス
じゃあたかさんの連絡先とか
ジョブロールとかぜひ上のとにも貼らせてください
ツイッターでいいのかな
DM受けれるようになってるから
多分ツイッターでもいいと思う
はい分かりました
じゃあ今日はですね
たかさんをお呼びしてロンチャブルについて
詳しくお聞きできました
じゃあそろそろ
今日はこれぐらいにしようかなと思います
はいじゃあたかさん今日は出演してくださって
本当にありがとうございました
ありがとうございました
はいお疲れ様です
