1. London Tech Talk
  2. Machine Learning でテスト運..
2023-07-08 59:17

Machine Learning でテスト運用を高速化する Launchable とは? (Takayuki Watanabe)

spotify apple_podcasts

Launchable で Senior Software Engineer をされている Takayuki Watanabe さんをゲストにお呼びしました。NTT Communications、Cookpad を経てからLaunchable への入社された経緯や、Machine Learning を用いた PTS (Predictive Test Selection) プロダクトについての詳細、開発体制等についてお聞きしました。

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

コメント

スクロール