ep.81 『UIT meetup vol.12 リニューアル戦略発表会』 After show | UIT INSIDE

2021/04/02 に公開1008 views

このエピソードについて

ゲストにサイボウズ株式会社より @pirosikick、株式会社カカクコムより @osunu を招待し、イベント運営の @potato4d、社内登壇者の @naoto.ikuno を含めた 4 人で、 UIT meetup vol.12 のアフタートークの延長戦を行いました。

UIT meetup vol.12 のアーカイブはこちらから

ゲスト紹介

@pirosikick

サイボウズ株式会社
フロントエンドエキスパート

@osunu

株式会社カカクコム
食べログフロントエンドエンジニア

食べログのフロントエンドリプレース戦略 from Tsuji Yuko

Refs

LINE 新卒採用 2022
- https://linecorp.com/ja/career/newgrads/engineering/
キャリア採用はこちらから
- https://linecorp.com/ja/career/position/475
BGM&SE
- 魔王魂/騒音のない世界/OtoLogic

採用について

使用素材・クレジット

BGM&SE

音声書き起こし

1. オープニング 00:00

Guest 00:04
こんにちは、UITのpotato4dです。ユーザーインターフェースとテクノロジー、アイスル開発者のためのウィークリーポッド、キャストUIT INSIDE。

Guest 00:13
今週も始めたいと思います。え、今回はですねえ、UITミートアップボリューム、ティエルブのアフターショーとして、

Guest 00:22
3月10日に行われたUITミートアップ、ボリュームテレビに登談。いただいた。LINEいくのさんえ、サボーズえあいさんえ。そして

Guest 00:31
食べ。ログフロントチームの辻さんの

Guest 00:33
3名をゲストにお呼びして、えー。アフターショーということで、ニートアップの内容をさらにえ、深掘りして語っていきたいと思います。

Guest 00:41
皆様どうぞよろしくお願いいたします

Guest 00:44
よろしくお願い

Guest 00:45
よろしくお願いします。

2. ゲスト紹介 00:50

Guest 00:50
それではですねえ、まずですね。ま、社内メンバーのいくのさんは、一旦えースキップとして、今回ライブから2名ゲストに来ていただいてるんでえ、簡単に自己紹介していただこうと思います。

Guest 01:01
では、まずえさぼさん、あいさんからお願いしてもよろしいでしょうか。

Guest 01:05
はいと、サイボズ株式会社で、フロンテンデスパチームというところに所属しております。あいです。ピロシキックっていうidで、twitterとかギットハーブはいます。普段は福岡

Guest 01:18
しおあ、福岡県大野城市ってとこに住んでまして、リモートでと仕事しているという感じです。はい、よろしくお願いいたしますはい、

Guest 01:27
よろしくお願いいたしますはつりさんもお願いできますでしょうか。

Guest 01:32
はい

Guest 01:33
辻優子と申しますえ、株式会社価格コムのえ、食べログaで、フロントエンドチームのリーダーをやっています。

Guest 01:43
ま、普段実装にやることもあるんですけど、ま、リーダー業務というのが結構多いので、採用だったりとか、後、チームビルディングだったりとか。その後、リクレースプロジェクトをまどう進めていくかみたいなところを中心に

Guest 01:57
お仕事をしております。今日はよろしくお願いします

Guest 02:01
はい、よろしくお願いいたします。

Guest 02:05
では、ゲストの2名をえ交えてま。社内から2人ゲストにえー2人というところで、え、4名体制でえ、本日は始めていきたいと思います。

3. Renovate について 02:16

Guest 02:16
ではですね、早速アフテンショーとして、アフタートックをしていきたいところではあるんですけれど、もえ、その前にですね。tミートアップボリュームテール部について、簡単に振り返ります。

Guest 02:27
UITミートアップ、え、ボリmtllvですけれどもえ、先月ですね。3月10日に、開催したUITミートアップの1、2回目のオンライン配信となります。

Guest 02:38
今回ですね

Guest 02:40
テーマといたしましては、リニューアル戦略発表会っていうところになっておりまして。まあ、技術的なアップデートや作品といったところに、え、焦点を当ててですね。ま、どのように各社がえ取り組んでいるかっていうところを中心に話しました。

Guest 02:55
youtube配信のアーカイブはですねえ、すでにyoutube上にあげられておりますので、え、是非是非まだ見ていない方は

Guest 03:02
小ノートの下にあります。え、リンクよりえ、youtubeのアーカイブの方をご覧いただければと思います。え、今回はですね、その内容を踏まえて、より深掘りしていければと思います。

Guest 03:16
では、早速もえ、アフターショーというところで、フタートに入っていきたいと思うんですけど、なんかこう結構あの時

Guest 03:23
だは聞きそびれちゃったけど、なんかこういうこと聞きたかったみたいなのとか、ま、こういうこと話したかったみたいなのって、皆さんあったりしますかね。

Guest 03:31
そうですね、僕ちょっといいでしょうか。

Guest 03:34
はい、どうぞ。

Guest 03:35
はい、

Guest 03:38
その先月のUITミートアップでアイさんの発表受けて、今プロダクト内でも、実際にlivliの更新頻度を上げたいなっていう話は今出てるんですよ。

Guest 03:49
で、そこでリノベート入れて、ライブラリンアップデートしやすくしようかなって検討しているんですけど。でも、こう、マイナバージョンのアップデートとかも入れると、すごい数になって、実際に全部休営するっていうのは大変だと思うので、

Guest 04:02
なんかどうやって消していこうかなとか考えているんですけど、その辺はないさんやつさんについて、ご意見をお伺いしてみたいです。

Guest 04:13
そうっすね、なんか

Guest 04:15
こう自分が出したこれなんかあんなんですよね、なんか、こうしてったらいいんじゃないか、みたいな感じで、まだこう実践に至ってないから、こうなんとも言えないとこもいっぱいあるんですけど、

Guest 04:26
どうがいいんですかね。りのベトとかだと、多分パッチバージョンだったら、もうマージしちゃうみたいなオプションとか、多分確か設定できるですよね。なんで、はい、

Guest 04:36
多分こうそんなに気にしなくていいものとは気にしたいってやつを分けて、こう

Guest 04:44
もう勝手にマージしていかないと、結構きついかなっていうのはありますね。あの、サボsはその外にoss結構出してるんですよね。その、あの、

Guest 04:54
こうパートナーさんとかがプラグイン作ったりとかま、そういったのに使うsdkとかを提供してるんですけど、

Guest 05:01
ま、なんかいくつかま管理して、応援スがあった時に、ま、そこにイノベート入れて、まあこう僕たちで見ていくんですけど、やっぱ結構大変で

Guest 05:11
こうなので、基本的にはなんかこう。マイナーまパッチバージョンがのアップデートは、基本的にもう即ママというか、

Guest 05:20
プリック作らずにもうマジしちゃうように設定してますね。ま、一応テストとかはちゃんと書いてるんでま、テストは最低限通ってるって保証はあるんですけど、

Guest 05:30
なんかなんでプロダクトとかでもな。多分やっぱそうしてかないと結構もうなんかすごい領土依存が多分モドジェスとかあるんで、

Guest 05:39
多分無理だろうなって気はしてます。あとは、まあそもそもossをまあボンボン入れないみたいな。多分、

Guest 05:47
判断もしなきゃいけないのかなって気がしますね。

Guest 05:52
そうですね、なんか今言おうとしたことは大体言われてしまい、すいません、

Guest 05:57
すいません。

Guest 05:58
あの、いいあのまただだから、食べログではリノベとまだあの導入でちゃんと運用までも合わせてなくて、まおっしゃる通り、そのいっぱい出るだろうな。どうしようかなっていうのは、ま、

Guest 06:10
まだ運用した実績っていうのはないんですけど、もま、やっぱりたくさん出るっていうのは予想できるので、パッチとかほんと警備なものであったら、テストとってれば

Guest 06:20
まま味しちゃうくらいにしないと難しいのかなとは思ってます。あと、

Guest 06:26
これもその特にまだ運用実績も何もなくて申し訳ないんですけど、まあ、重要なページ

Guest 06:31
であれば、まeeのテストの自動化とかしてもいいと思うので、まそこだけ動いてれば大丈夫

Guest 06:39
みたいな部分でま担保していかないと、ま、なかなか手で全部テストするとか、クロスブラウザで見るって

Guest 06:47
っていうのをパッチレベルまでやるのは、やっぱり現実的じゃないのかなとは思ってます。

Guest 06:52
難しいですよね、どこどこでLINE引いていいのかという、

Guest 06:59
なかなかメイクかな。基然作りが大変そうですよね、そういうの

Guest 07:04
そうですよね、

Guest 07:05
まさに悩んでるんですけど、

Guest 07:08
シノベドの場合、基本的にま、試合通ったら、オートマジっていう風にするとしても、そのちゃんとじゃあ、ほんとに全部テストされてるんだっけってはな、

Guest 07:16
そうなんですよね、いや、難しいっすよね、

Guest 07:22
そうです、何何をこう基準として問題ないとするかっていうところって結構いやそうです。突き詰めると、多分その差分まで見て

Guest 07:32
こう正しいかで、多分動作確認もしないとほ本来は多分いけないんですけど、そこは無理ですよね。もう多分

Guest 07:42
多分無理な量がで出ますよね。ま、規模にもよるとは思いますけど、

Guest 07:46
結構きついので、どこがいいんですかね。

Guest 07:50
なんか、昔、そのos使ってるossに対して、こうテストを書くっていう人とかもいましたけどね。あの、

Guest 07:57
使ってるライブには、インターフェースは正しいかとか、そのそういう単体テスト入れとく、ほんとになんだろう。こう

Guest 08:04
結合を見たいようなララとかと、そういう手法もあるみたいですね。そういうのを単体スペス混ぜ混ぜといて、

Guest 08:11
あ、その期待してる動作がオセス変わっちゃったら、その手落ちるみたいな風にするっていうのも1個あるかもですね。

Guest 08:19
まけ、全部全部それにができるとは思えないですけど、そうですよね、いや、難しい。

Guest 08:28
なんか、自分は結構その自社でオイセスどんどんオイスってっていうか、どんどん作っちゃうみたいのもまありなのかなって気はしますけどね。なんか、

Guest 08:37
ある程度エンジニアがいるんだったら、

Guest 08:42
なんか、今は割とこう車輪の再開は、絶対ダメっていうような風潮が多いのかな。気がするんですよね。こう

Guest 08:50
お設であるものは、なるべく施設で使うっていうんだけど、やっぱそういうリスクとかま、ライセンスとかの話もあるし、まあ、なんか

Guest 08:59
ま必ずしもじゃないですけど、こう選択肢の1つとして、

Guest 09:03
まあ、自社で作るっていうのはあってもいいのかなとかふんわり思ってますけど、ま、そううまくはいかないと思いますけど。はい、

Guest 09:13
そうですよね。なんか、あんまりそのパッケージをそもそも入れ、まあ、あのフレマーク入れるだけでも、そのデップスのデップのデップスで、どんどんノードモジュールって化すると思うんで。ただでさえ多い中で、めちゃめちゃ入れないっていうのを、そもそもあるかもしれないですね。

Guest 09:32
確かに、

Guest 09:33
うちの会社も最近リノベとあのギターエンタープライズのあのセルフ、ホスティングの方なんで、あのサーズ版使えなくて、自分たち用にあのリノベともossなんで立てたんですけど、なかなかまだ

Guest 09:46
使いこなしきれてるわけではないんで、ちょっとうまく使っていけると、

Guest 09:51
やっぱりその膨大に提案されてくるという状態なんですか。

Guest 09:57
あ、そもそもなかなかそれが予期されるんで、プロ入れられるプロジェクトがまだまだ多くないというか、

Guest 10:03
まだまだ入れられる状態のプロジェクトに入れていくって感じ、その非大化しすぎてないプロジェクトでの事例しかまだないみたいな状態。

Guest 10:13
ああ、なるほどま小規模であれば、まあ対応していける

Guest 10:16
そうですね。そうですね、小規模もしくはまだ最近立ち上がったばっかりで、これから大きくなるかもしれないけど、現状は小さいみたいなものを

Guest 10:23
だと入れられるけど。っていうのが、今のうちの会社の

Guest 10:26
状態。なるほど思います参考になります

Guest 10:30
あ、食べログはま非大化しているので、もちろんま全体に入れるのは結構難しい。

Guest 10:38
正しいですよね。

Guest 10:39
はい、リプレースしたところであると、まだそんなに大化してないので。あの、最初の方は大丈夫だと思うんですけど。ま、途中から

Guest 10:48
あのおおっしゃる通り大化してな。パッチバージョンがめちゃくちゃ出てっていうのは、予期されることではありますね。

Guest 10:56
そうですよね、

Guest 10:59
そうなんですよね、なんか、必ずしもパッチバージョンがその破壊的じゃないかっていうのはわかんないですもんね、さらにこうせすのね、ガバナンスに多分よると思うんで。

Guest 11:08
そうですよね、お作法を守ってない可能性とかを考えると

Guest 11:13
は。じゃあ、全部ちゃんとテストしましょうか。みたいになると、やりきれないですね。

Guest 11:19
なんか、無意識に全部がセ場にのっとってると思いがちですけど、別にそうとは限らないですもんね。

Guest 11:27
そうですよね、な、

Guest 11:29
このバージョンでそんな破壊的なことするみたいなのがないっていうのは、別にどこでも確かめられない。結局、ソース見ないとわからないです。

Guest 11:38
そうですね、それも結構難しい問題ではありますよ、次の話題でも行きますか。

4. リニューアルについての説得ってどう？ 11:49

Guest 11:49
とた、多分あの同じく長期的なま、リプレースには着手していると思うんですけども。やっぱりその

Guest 11:57
ちょあまりにも長期にわたるとまどこまでで何の成果を出すとか、ここまではリプレースできます。みたいなこう、マイルストーンを切っていくのが結構難しかったりとか、まあ、予測通りにならないま思ったより、時間がかかったりと

Guest 12:13
っていうことも結構多いと思うんですけど、何かそのまチーム外にも分かるような、そのリプレースのマイルストーンを切っていくと、

Guest 12:22
時にま。例えば、そのきこの機能ごとだったりとかまこのページはできるようになりますよ。とかま、色んなま区切り方とかあると思うんですけど、

Guest 12:31
なんか、その長期のプロジェクトになんか携わる上で、

Guest 12:37
どういう風にこう、タイムボックスを切って進めているのかっていうのは、聞いてみたいなと思っていました。

Guest 12:43
いや、これ、僕が聞きたいぐらいです

Guest 12:47
同じ悩みをお持ちだったかもしれない

Guest 12:50
そうなんですね、結構その自分がフロンテのエキスパーチームとして、その脱れがししてた時、その最初の方針ていうのがなるべくこうプロダクトチームに迷惑をかけず、迷惑じゃないですけど、こう

Guest 13:03
フラクトチーム手を煩わせずに、

Guest 13:06
いかに自然とやっていくか、みたいなことをずっと考えてやってた時期があったんですけど、はいはい、なんかやっぱそういう実際こうリリースしてくってなると、

Guest 13:15
なんかやっぱ

Guest 13:17
もっとなんて言うんですか。大きい範囲で話していかないといけなく、どんどんなっていってるなって気がしていて、その今のその多分、どういうタイミングでリリースしていくかっていう

Guest 13:26
話も、多分そういう風な感じになると思うんですよね。なんて言うんだろうこう。やっぱり、お客さんの体験が変わってしまったりとか、

Guest 13:34
うんする可能性があるじゃないですか、そうなってくる

Guest 13:38
とくなったらいいんですけども、

Guest 13:40
そうそうよくなった

Guest 13:41
よが、微かに変わる場合もまあ多分ありますよね。

Guest 13:45
そうなんですよね、なんか、それでバグがなくなりますとかだとすごく説明がしやすいし、多分ま。むしろ説明しなくてもどんどんやっていいと思うんですけど、こうななんだろ。

Guest 13:55
jkから例えばこうリアクトに行きます。みたいなところって

Guest 14:00
こう、それが必ずしもできないじゃないですか。なんか、パフォーマンスがま良くなるかって言われると、まあ、多分そのjkに比べると多分団体も大きくなるし、とか

Guest 14:12
まその開発速度上がるかもしれないですけど、それってこう目に見えて上がるわけじゃないからな。結構そのの時は

Guest 14:20
ま金等の事例ですけど、金等はそのがっちり。そのアイルでスクラムでやってるチームなんですけど、

Guest 14:28
キトのもpmに半た時にpmが結構がっつり決めてくれましたね。そのpmは、割とそのお客様とか

Guest 14:36
かなり詳しいんで、その多このリリースがその納得感得られるためには、多分これだけだとダメみたいな、そのリアとかしましたっていうリリースは多分通らないみたいな。

Guest 14:47
だから、多分今これをやろうとしてるんで、これに被せて出すのは、多分そのユーザー的に納得されるだろうから、

Guest 14:56
そうしましょう。みたいな、なんで今は割とその設定ページが今なんて言うんですかね。こう、デザイン的に統一されてないところがあるんですけど、ま、それを今統一しようとしてます。みたいな

Guest 15:06
もあったから、多分それにリアクトかせてやると、まあリリースすないくんじゃないかみたいなま、リリース時の説明とかなる

Guest 15:16
だ、結構その僕らの場合はあれですね、pmが割と決めてくれた感じでしたね、なので、そうですね、

Guest 15:26
割となんかそういうま食べログしなんだ。btbもあるけど。ま、btcが多いと思うんですけど、なんかなんか、やっぱりその

Guest 15:36
サービスで大事にしてるとこにどれくらい今行くかとかにも多分よるから、

Guest 15:42
なんか実際決めるときは、まあ、フロントエンドだけじゃなくて、そのプロダクト

Guest 15:48
まpmとか、そういう人たちも含めて考えた方が、なんかすんなり行くとこもあるだろうなって気はしますね。うん、うん、

Guest 15:57
うん、うん、なるほど、

Guest 16:00
いや、その必ずしもその実はリアクトに変えるだけだったら、多分デザインとか変えずにリリースできるとは思うんですけど、まわざとその機能修正とかも取り込むことによって、

Guest 16:12
まそのリリースで何ができるのかを分かり易く示すっていうことなんですかね。

Guest 16:18
そうですね、なんかこう体験が変わる、多少変わっちゃうみたいなことが多分あると思うんですよね。ジェクエとまりまだかうまくやれば、もしかしたら、全く体験を変えずに

Guest 16:28
こう行くこともできると思うんですけど、なんて言うんだろう。それをするために、例えば、

Guest 16:33
コストがかかっちゃうかもしれないじゃないですか、こうそうですただね、jクルそのまま再現するっていう

Guest 16:40
はいはいはい、うん。

Guest 16:43
それで、例えば伸びちゃうくらいだったら、

Guest 16:47
ま。なんかうまく説明がつくタイミングで、こうどかってやっちゃった方がいいんじゃないかっていう話をpmとかしてましたね。

Guest 16:56
けど、これは多分サービスとかにもよる気がします。なんでまあなんかほんとは多分コツコツ出していけるのが多分1番

Guest 17:04
いいとは思うんですけどね。うん、うん、うん、結構btbだと、その

Guest 17:08
どうしても使ってくれてる人もび業務で使ってるんで、その仕事が立ち行かなくなるとか、あとは、その例えばuiがちょっと変わっちゃうだけで、そのなんだろう。導入してる会社さんで、マニュアルとか作ってるケースとかあるらしいんですね。

Guest 17:21
なんで、

Guest 17:22
ああ、それ

Guest 17:23
が変わっちゃうってなると、その結構音なんらしいんですよ。そう

Guest 17:29
そうですね、スクリーンショット取り直しても、取り直してもらってか

Guest 17:32
も接するかもしれならしくて。

Guest 17:36
なので、なんか結構まけたプロダクトによると思うんですけど、サイボズみたいなbtbのプラットは、割とそのリリースとかは結構

Guest 17:46
なんかこっちからしたら、なんかそんな大したことないじゃないかって思うもん。でも、あと、センシティブな面はありますね。なるほど、

Guest 17:53
うん、うん、うん、うん、

Guest 17:55
そうっすね、どうがいいですかねね。いや、難しいですよね、なんか、決めづらいのはすごくわかりますね。なんか、

Guest 18:03
うん、

Guest 18:04
トーストンとかね、ちょっと

Guest 18:07
あ、フロントエンドの視点から見ると、また分、もちろんそのジェイクエリーからリアクトになったら、こう色んな使いやすいツールも揃うし、

Guest 18:16
めっちゃ良くなったじゃんっていうのがこう分かると思うんですけど、ま、なかなかそれをフロントエンドに普段触ってないま、サーバー側の人だったりとか、ま、インフラーだったりとか、ま、企画のを考えている人とか

Guest 18:28
だと、なんか、何をやっているのかわからなくなっちゃうじゃないかっていうのは、まあ、普段結構考えてることではありますね、

Guest 18:39
すごくすごくわかりますね。

Guest 18:43
だから、そこをどうととはいえ、まあ意味はあることはやっているはずなんですけど、その

Guest 18:50
フロントエンドに携わる人以外にも見えるところまでたどり着くのが結構遠いので、どうしてます。なので、そこの間の

Guest 19:00
なんかどうどう周りに説明をするのかっていうのは、長期プロジェクトと、皆さん苦労してるんじゃないかなと思います。

Guest 19:08
大変大変ですよね、なんか、うん、結構僕らだと明らかじゃないですか。そのねェクエリからリアクト、絶対ょェク書きたくないですよ。書きたくない、絶対いいんですけどね、こういざ

Guest 19:22
説明するってなると、なかなか難しいんですよね、そうなことですね、

Guest 19:30
なんか、逆にそこでちょっと個人的に気になっているところがあって、ま。その逆にじゃないないかもしんないですけど、なんかその

Guest 19:37
なんでしょう。ある程度おっきな変更を伴ないとというか、例えばそのなんでしょう。uiのえ変更します。みたいなところを伴う次いでに、リアクトに移行できるっていうところもえあるかなと思うんですけど、一方で、今回の例えば、

Guest 19:50
あのつさんの食べログの時代であったりすると、ま、小さいところから変えていくっていうところがあるかなと思って。なんか、あのあないさんの発表でもそのなんでしょう。すぐに、マジできるぐらいのリードで

Guest 20:01
変えていくっていうところ、結構勤めてるって話があったかなと思うんですけど、結構それを意識すると、どうしても

Guest 20:08
ぱっとみ。ただ、フロントンドエンジニアがそうしたいだけに見えるような変更って増えてしまうのかなと思っていて、なんか、本質的には何も変わらないけれど、も、まちょっとコードベースが良くなります。みたいなのって、すごく

Guest 20:20
あのいすぐにマージできる単位にすればするほど出てくると思っていて、そのあたりのジレンマみたいなんて、やっぱり

Guest 20:27
あるんですかね。それとも、そういうのって、結構やっぱりそのエンジェアリングとして必要だよね。って自然と受け入れられたりはするんですかね。

Guest 20:34
それで言うと、

Guest 20:40
そうですね、例えば、例えばその今回の食べログの時代で言うで、あの言うと、そのページの右下の

Guest 20:47
ここの部分をリアとして出しました。って話がったかなと思うんですけど、多分結構それって、あの、まずそこだけリア化するにも。例えば、そのビルド設定を変えるところから始まって、で、その後その環境が生まれた後にま、それを

Guest 21:01
つか、それをのイニシャルのセットアップというか、そのリアとコンポーネントを少しずつマウントできるような仕組みを整えて、その後に予約リアとコンポーネントを実装するみたいな風になる

Guest 21:12
な。流れになると思うんですけど、やっぱり、そのリアとコンポーネントまでをまとめて、デプロイすると、多分これだけでも結構おっきな変更になってしまうと思っていて、なんかそうなると。例えば、

Guest 21:22
そのビルドのフロントエンドのビルド環境を整えました。みたいな、直接的にゆうエンドユーザーの

Guest 21:29
のプロダクションに乗ることには、一切関係がないけれども、なんか、フロンテナの開発整備みたいなところで、ちっちゃく

Guest 21:35
作業を区切っていかないといけないかなと思うんですけど、なんか、そういうのってこう理解って結構得られてる感じなん

Guest 21:43
ですかね。それともも、なるほど、っていうところが結構なんか、なかなか。それって説得がむず、難しいところでもあるようなと

Guest 21:50
素直に感じてて、どういう風なやり方をしてるのかなと。ちょっと気になった次第でありま。

Guest 21:56
それは、そのフロントエンドの人

Guest 21:59
じゃない人から見たらす影響もしないし、何なんだろう、このデプロイみたいな、なんだろう、このリリースみたいなのが増えちゃうっていうこと

Guest 22:07
増えちゃうみたいな方ですね。そうです、そうです、

Guest 22:10
なるほどまそうですね、今のところ、そこに何かこうツッコミが入ったりっていうのはないんですけど、まあ、確かにおっしゃる通り、その

Guest 22:20
ユーザーに影響するのは、本当に最後のちょっとしたリリースのみで、

Guest 22:25
もうそれまではユーザーには一切見えないですけど、ま、ちょっとずつこう裏で準備をするというか、あの、

Guest 22:32
最後ほんと切り替えのプルリだけなんですよね、あのユーザーに影響するのは

Guest 22:38
そうですよね、今まではもう本当に多分チーム外から見たら

Guest 22:43
こな何だろう。これみたいなのがあるのはあるんだろうなと思うんですけど、ま、特にそのまそれをやることによって、さえユーザー

Guest 22:53
でま、最後のちっちゃいスイッチだけでユーザー影響するっていうな仕組みにすることで。ま、最後、

Guest 23:00
あの、もしバグった時とかあ、やばいってなった時に、まそのswitchのプルリだけ戻せば、まあ戻る

Guest 23:06
っていうためにまやってるので、ま、それまで有罪居しないものがずっとあるでっていうところに関しては、まあまりその今まで社内で

Guest 23:15
なんか話したとか、何か問題ですね。ってなったことはないです。

Guest 23:19
あ、あ、じゃ、結構自然に受け入れられて、

Guest 23:22
あ、そうですね。まさ、ユーザー影響の部分をすぐに切り戻せることっていうの、あの、かなり重要視しているので、

Guest 23:32
あの、むしろそっちの方がいいと思ってます。あ、

Guest 23:37
なるほど、なるほど、ありがとうございます。確かに、何か影響があったとき、1度中断できるというか、まあそこで

Guest 23:45
そうですね、その前に戻せるっていうところはすごい大切ですしね。はい、

Guest 23:50
で、なんか一気に出しちゃうと、ほんとにユーザーから見えなかったらいいだけなのに、全部巻き戻っちゃうので、

Guest 23:57
それだともう何もかも。じゃあ、もう一度出してってなってしまうので、まあ、もちろんそのユーザー影響がないリリスが万々されるっていうのはあるんですけど、

Guest 24:07
まそこはまあしょうがない

Guest 24:10
とか持ってもらってるっていうとこ、なんはい。ああ、なるほど、ありがとうございます。結構それってなかなかこう

Guest 24:18
としても、他のフロントエンド以外のえー人から見たら、その変更がどうい

Guest 24:25
た。そのプラスに影響を及ぼすのかってイメージしてもらいづらいところかなと思ってたんで。あ、

Guest 24:30
そうですね。ま、ただ、食べログすごく大きいプロジェクトになっていても、

Guest 24:36
あの日々めちゃくちゃいろんなチームがプルリック出して、え、リリースしてっていうのをやってるので、まあ、なかなかその全てのプルリックを見て、

Guest 24:46
これは何のリリースだっていうのをこう突き詰めて見てる人見れるっていう人っていうのは、かなり元々少ないのかなと思います。もう、チーム外のリリースだと、

Guest 24:57
ま、タイトルから色んなこう案件の名前とか書いてあって、うん、多分あれのことなんだろうみたいなはいるんですけど、あの行動量も多かったりすると、全部見ることはなかなか難しいですし、まな全部見てる人が

Guest 25:10
なかなかいないっていうのもあると思います。

Guest 25:13
逆に言えば、そのチーム内でちゃんとみ見られていれば、ま、そこに関してのそのリリースの開発以外の消費みたいなのは、あんまりないっていう感じ。

Guest 25:22
あ、そうですね、チーム内であのまフローが決まってるんですけど、ちゃんとこうコードレビを通ることだったり、あのリーダーのチェックを通らないといけないとか。ま、フロア決まってるんですけど、そのフローさえちゃんと踏んでいれば、あの特に問題なくリリースはできます。

Guest 25:37
なるほど、ありがとうございますちょっとここが気になっていた、これでもあったんで、ありがとうございます。

5. pirosikickさんの質問1 25:47

Guest 25:47
ちょっと今回あいさんに聞いてばっかりになっちゃってますけど、あいさん側からここに話したいみたいなのあったりします。

Guest 25:53
それはですね、当日その自分の発表めっちゃ緊張しすぎて、はい、終わった後、もうめっちゃ気抜けちゃって、辻さんの発表なんか、最初の方全然覚えてないんです。更新状態になっちゃったね、

Guest 26:10
そうっすね、けど、なんですかね、

Guest 26:14
やっぱなんか同じような苦労すごいしてるだろうなって思ってるんですよね。なんか、それでそれで言うと、

Guest 26:23
まけど話したようなことが多いかもしれないですけど。

Guest 26:26
そうですね。なんか、そのプロダクトチームや、まあ、そのフロントエンド外の人ですね。と人たちとなんかどういう風にコミュニケーションとってるかとか、

Guest 26:38
あとは、例えばリアクトに移行します。みたいな話のコンセンサスとかを、なんかどういう風に

Guest 26:46
なんかと取りましたか。たのか、すごい気

Guest 26:48
なるほど、あそ、そもそもリプレースに着手しますっていう時に、まな何でとか。

Guest 26:56
あ、そうそうそうなんかそういうのが実際あったのかなかったのかとか

Guest 26:59
かな。あ、なるほど

Guest 27:01
た純粋にいましたあとは、そ、そもそもリプレースするぞってななったこうキーとか、

Guest 27:07
はいはいはい、

Guest 27:09
そういう話を聞きたいな。あ、

Guest 27:11
そうですね、ま、リプレースをするぞってだったのは、その例えば上司から言われたとかではなくてま、チーム内でえま話していて、元々その

Guest 27:21
えーま、色んなバージョンの管理だったりとか。ま、コード契約コーディング契約の整備だったりとか。っていうのは、チーム内で行なってたんですけど、

Guest 27:30
ま、そのまあるタイミングでま。今後

Guest 27:34
どう色んなま課題がある中で、何の優先順位が高いのかとか。ま、あれのバージョンが低くて、凄い使いづらいだったりとか、ここの構造がおかしいからとかま、何か色んなのを上げた時に、ま、やっぱり

Guest 27:47
なんていうか、ジェイクエリのままだと、どれもこれもどうにもならないのでは。っていうのが、まあのっていうのを、みんなでは話し合うタイミングがあって、

Guest 27:58
でえ。まあ、やっぱりそのその時はリアとってはっきり決まってなかったんですけど、まあ、やっぱりhtmlをjsでま管理するような、フロントとサーバー

Guest 28:09
がま、癒着してない世界にしないと。えーま、やっぱりフロントエンドをこうな扱い易いメンテナンスしていけるような、

Guest 28:18
アーキテクチャにはならないんじゃないか

Guest 28:20
っていうのをえ、チームで話し合ったっていうのがまきっかけではありますね。でえま、その後、

Guest 28:29
技術選定をして、リアとタトタイプスクリプトでやろうっていうのは決まったんですけど、え、その時にそうですね、コンセンサスですよね、

Guest 28:38
ま、まずは勿論上司とかあのにはこういうのをやります。っていうのは相談して

Guest 28:49
で、そうですね、ま、理由として言ったのはま色々あるんですけど、やっぱりメンテナンス性

Guest 28:57
のためにやりたいっていうのはありましたね。ま、あの、

Guest 29:02
今も結構モジュールには分かれてたりはするんですけど、やっぱちょっと修正するだけでも、なんか

Guest 29:10
ま、まだ影響範囲が読めたらいいんですけど、そもそも影響範囲がを読み取るのすら、難しいようなところもまあったりだとかえ

Guest 29:20
とかですね。まあるんですけど、ま、それらをどうにかこう良くしようと言うか、

Guest 29:26
もっと簡単にコストを抑えて、メンテナンスしようってなった時に、ま、ジェイクエリでま。

Guest 29:33
このままやっていくのは無理があるっていうのはせ言ったのとま、もう一つはえ。食べログ的にはやっぱsoがかなり重要視されているので、

Guest 29:44
えーまい。

Guest 29:47
今現時点では、あの、そんなに凄く順位が下がってきたりとか、そういうことはないんですけど、え、ま、最近だと、アウェコアウェブバイタルをえーちゃんとしないと駄目ですよ。っていうのがま発表されたりだとか、

Guest 30:02
結構そのパフォーマンスっていう部分にもえ厳しく見られつつある環境かなと思うんですけど、ま、それをどうにかしようとした時に、やっぱり

Guest 30:12
ジェイクエリーで、レイズでレンダリングした1tmlの上でインターラクションを実装してっていう構造だと、ま、やっぱりどこかこう限界があるというか、あの

Guest 30:22
打てる限界があるというか、まあ打った手でうまくいったらそれでいいんですけど、こう打てる手がすごい少ないんですよね。やっぱり、あの

Guest 30:31
きゃキャッシュしとこうって思っても、え、どこをどうやってみたいなのとか。あのま、ssrと言えばssあるんですけど、あのま、例えばあんまりあの

Guest 30:44
更新がないところだったら、性的にま、なんか作って置いとけばすごい早いのかもしれない

Guest 30:51
ですけど。ま、レールズ乗った状態で、それをやるのは結構難しいですし。

Guest 30:55
でま打てる、手が凄い、少ない中戦っていかないといけないことになるので、まそこは増やしておいた方が

Guest 31:03
いっていうのは、説明した気がしますね。っていうのを何かそれなそれらをまとめて、インセプションデッキを作って、

Guest 31:12
それを元にやりますっていうのを説明しに行きました。

Guest 31:16
なるほど、アジャイルド。

Guest 31:18
あ、そうですね、我々はなぜここにいるのかみたいな

Guest 31:22
をまベースにしてま。今こういうのが問題でまやらなかったら今後どうなるのか、今ここでこれをやるとどうなるのかっていうのは、比べて説明したっていうのは覚えてます。

Guest 31:36
それえと、はい、その例えば開発時間ってこう、その分、機能追加の時間が持ってかれるじゃないですか、イ行に

Guest 31:44
移行するため、あ、

Guest 31:45
そうですね、その時間でサービス開発することも可能ですもんね。

Guest 31:50
なので、そういうなんか、バランスを取るというか、そういう部分て、企画とどうコミュニケーションをとって決めたのかなっていう部分が気になります。

Guest 31:58
あ、なるほど、そ、

Guest 32:02
全部100で、その移行の方にかけるわけにはいかないじゃないですか。

Guest 32:06
あ、そうですね、

Guest 32:08
まも元々そのリファクタリングをえま開発の方で進めていくっていうところに関しては、まあ任せられてる部分もありますしま、すごく細かいリファクタリング

Guest 32:22
えまでなんというか、まこ細かいところまでコテってるかって言って、そうではないので、ま、ただ

Guest 32:32
今後そのもちろんおっしゃる通り、

Guest 32:35
ひゃ百リファクタリングをやってしまうとまサービス。今までそのサービスを開発していた人達がいなくなってしまう

Guest 32:44
っていう部分は勿論あるかと思うんですけど、まあ、元々あの、ある程度リファクタリングをしたりだとか、まあの統括業務みたいなのをしていた

Guest 32:53
チームでもあるので、ま、元々100パーセント。そプロジェクトをなんか開発していたわけでは

Guest 33:00
ないので、ま、あんまりそこに引っかかりはなかったのかなとは思ってますね。ま、ただ、もちろん、あの何の説明もなく、突然この人たち何もやらなくなったなってなると困るので、あの

Guest 33:14
が最初の方にえーまき。そのさっきも話した通り、なかなかその

Guest 33:20
フロントエンドに携わらない人まで成果が出るのが遠いところが心苦しいところであるんですけど。え

Guest 33:32
みたいな時に、ジェイクエリーでできないことないですけど、まかなり難しいですし。

Guest 33:39
まあ、それをやるなら多分リアクトだったりとか、ビューとか、え、アンギャラとか入れるんじゃないかなと思うんですけど、なんですけど、ま、そうやろうとした

Guest 33:49
時にそこから入れてると、まめちゃくちゃ時間掛かるじゃないですか。なので、まあの今後色んな

Guest 33:57
企画ま要件と言うか、こういうuiをやりたいです。とか、まあのこうこういう動きにしていきたいです。

Guest 34:06
みたいな時に、え、そこから始めると、もう土台作りからやらないといけないので、めちゃくちゃ時間かかるので、でま。世間的にはspaみたいなのを結構

Guest 34:15
あの一般的にはなってますしま。将来的にそういうのがま出るっていうのは予測されますし、ま、あの、元々もっと早く動くようにしたいっていう要件とか

Guest 34:26
あったと思うので、ま、それらの準備の為に、はま土台作りが必要なんですよ。っていう説明は、

Guest 34:34
ちょちょっと説明したのが前で、記憶が曖昧な部分はありますが、した気がします。なので、ま、どうしてもそのじゃあ、

Guest 34:44
じゃあ3ヶ月後全部spaになるの。って言ったら、全然そんなわけではないんですけど、まあ、将来的にいろんな手を打てるように

Guest 34:52
っていう部分は説明したと思いますね。

Guest 34:57
ありがとうございます。なんか、結構似て似てるというか、

Guest 35:01
うん

Guest 35:02
たかjク。自分自分たちもなんかクロージャーライブラリとか、ま、あとは今やってるなんかあるんていうプラッタとジェクリモバイルから一行しようとしてるんですけど、

Guest 35:12
なんか、そこからリアクトとかだと、

Guest 35:15
なんか意外ともしかしたら説明はしやすい方なのかなって、ちょっとなんか話聞いてて思ってきました。なんか、結構今リアクトとかビューとかは割と受け入れられてるじゃないですか。こう

Guest 35:26
あ、そうですかね、採用できませんとか、なんか。例えばパフォーマンスチュニックできません。とかとは、そう採用できない。結構おっきいなと思ってて、

Guest 35:36
なんか誰も触れなくなりますよ。みたいな話とか結構しやすいんで。あ、

Guest 35:41
そうですね、それはあの理由の1つに入れてました。ま、今後そのスキルあるエンジニアを採用したいとは思ってるんですけど、

Guest 35:50
まあの今後ずっとジェイクイリーしか触れません。って言ったところに、なかなかスキルある。フロントエンドエンジニアが来るとは思えないっていうところもあるので、

Guest 35:59
あの理由の一つとして入れてましたね。

Guest 36:04
なんか、そういうのは刺さり刺さりますよね。なんか、こうエンジニアじゃない人とかには、なんかあ、そうなんやすいっていうな気が、なんか説明しやすいですよね。なんか、こう、

Guest 36:14
パフォーマンスが良くなります。とか、そういうのはなんかあんまりこうめ。明確な数字としては、言いづらいとこがあるんで

Guest 36:23
けど、まあ、採用は結構わかりやすく、うん説明できるなって気がしました。

Guest 36:31
ちなみに、アナさんのところも、その始めるぞってなった時に、そのチーム外とのコンセンサスとか。あの、まだ誰かを説得するみたいなタイミングはあったんですか。

Guest 36:43
なんか、2回ぐらいあったんですよね。そのフロンテンで、キスパチーム内で、まあちょっとやってた時期があって、

Guest 36:52
で、それやってた時に、そのまあ実はそのプロダクトチーム内にやりたいって人がいるってことがわかって、

Guest 37:00
じゃあ、一緒にやりましょう。ってなってま、ちょっとやってたんですけど、そのあと多分あれかな。そのま、実際そのリアクトで行くかどうか

Guest 37:09
はまだ決まってなかったんですけど、そん時はまあある程度こうプロトタイプが作っていく中で、

Guest 37:14
いや、全然リアクトで行けるなってなった時に、まあ、じゃあその一緒にやってくれてる人いたち以外にもエンジニアいっぱいいるんですけど、プロダクトに

Guest 37:22
人たちにまリアクトで置き換えましょう。って話をしに行ったタイミングと、あとは、最初の方に行ったそのpmに実際話に行って、じゃあいつそのリリースするかとか、

Guest 37:33
その実際、こうチームの人にどれだけ時間割いてもらうか、みたいな話をしに行ったま、その2回多分せ説得じゃないですけど、

Guest 37:44
意見伺いに行った時があって、で、エンジニアの時は

Guest 37:49
そのまあ、キトンはそのクロージャライブラリーっていうま、ほんとにあの、あんまり多分知られてないようなやつを使ってるんで、なんか

Guest 37:59
ま、そのオンボーディングすごい大変だし、その採用もめっちゃ大変だし、とかいうのは。確かにその時に言った記憶は今もとかとか、

Guest 38:09
あとはそうです。何言ったかな。そうですね、ま、なんか色々そうめっちゃ準備していったんすよ、めっちゃ準備していって、で、なんでやるのかとかまでめちゃくちゃこう

Guest 38:19
準備していったけど、なんかさ、サイボズ結構理解がすごいできる人多いんすよね、なんでなんか全然すんなりなんかもう別に反対もなく

Guest 38:30
いいよ。ぐらいの感じで両方ありました。なんか、なんかなんかほんとにカスかし食らってたぐらいな感じでしたね。

Guest 38:37
あか、構えた割にはそんなにそう、全然刺されなかった

Guest 38:42
な、pmの時もほんとめっちゃ緊張していったんすよね、そのpmと話したことはほとんどなかったし、

Guest 38:49
ピム3人いるんですけど、うんま結構重鎮って感じですかね。そのもうさい細胞いる歴も長いし

Guest 38:56
でま、1人はもう開発本部長さてっぺいさんって人なんで、もうすごい偉い人だから、めっちゃ準備して

Guest 39:03
で、こういう多分質問されるよね。じゃあ、こういうこういう質問されたら、こう返そうとかをそう事前にちならしてまでしていったら言ったけど、

Guest 39:11
ややりました。やりました、

Guest 39:13
やりますよね、そうやりはい

Guest 39:15
やります

Guest 39:17
もう実際行ったらま、なんかその僕らが持ってったんは、それじゃあちょっとダメです。ってなったんですけど、ああ、これ終わったと思ったんですけど、ま、こういう方向だって行けるとか

Guest 39:26
は、あはあはあじゃ

Guest 39:27
いついつぐらいに行くかとか。あとは、もうほんとはもうこれもうすぐやりたかったんですよ。みたいな話とかをその逆にpm側からもらったりとかして、

Guest 39:35
うん、うん、うん、うん、

Guest 39:36
なんかすんなりいってほんとなんだったんだって感じですね。最初にぴえ話していけばよかったんじゃないかぐらいの

Guest 39:44
最初から巻き込んでおけば、こんなに

Guest 39:50
そう。最後は意外と今んとこうまくいってるんですけど、やっぱけど進めてる中では結構なんかちょっと迷いながらやってますね。ほんとにこれでいいのかとか、

Guest 40:01
こうプロダクトのなんていうの、今後の方針に関わることを、そのぼ僕らで決めてるみたいな感じのちょっと。なんか、プレッシャーみたいなもありますし。

Guest 40:11
うん、うん、うん、

Guest 40:13
あ、そうそうですよね。なんかこう。フロントエンドのそのなんていうか、単なる書き換えだと、そんなことないと思うんですけど、やっぱりジェイクエリーからとか、

Guest 40:22
結構その大きく仕組みが変わるってなると、なんというか。

Guest 40:27
ま、フロントエンド領域内だったら、まあ、フロントエンドチームで、もちろんちゃんと責任を持ってま。

Guest 40:33
決定していくべきだとは思うんですけど、なんかちょっとずつこう微妙なラインって出てこないですか。なんか、こここここの空きテクチャまで、

Guest 40:42
フロントエンドとして決定していいのかどうかみたいな。

Guest 40:47
いや、わかりますね、それ、次聞きたかったですね、なんか、そういうプロダクトの設計とかに関わるようなところって、なんか皆さんどうしてますか。みたいな、なんか、その

Guest 40:57
ちゃんと設計チームがあるのかとか、ま、それとも結構お皿になっちゃってるのかとかかなんか気になりますね

Guest 41:08
なんかどどうですか。なんか、あんまりサイボウズだと、例えば、今その

Guest 41:14
モノリスからマイクロサービスっていう本を輪読しながら、こうま、すごいモノリスなんですよね。あのさ、サイボのプロダクトって、

Guest 41:22
それをどうするかみたいな。みんな問題意識はあるんですけど、

Guest 41:26
ま、実際、そのトラクトチームには別にその設計するみたいなチームとかないので、なかなかこう。この先、例えば、この本を読みあった後に、こうどうプロダクション活かしていくか、みたいなとこなると、

Guest 41:37
いや、難しいなみたいな、すごい思うことが多くてですね。

Guest 41:40
うん、うん、うん、

Guest 41:41
なんか結構おっきい。その移行とかだと、割となんかみんなでちゃんと考えないといけないとこも結構あると思うんですよね。

Guest 41:50
ま、トマークのせん選択とかも1つ多分大事ですし、

Guest 41:57
そうです。そうよね、

Guest 41:58
うんど、どうしてますか。

Guest 42:04
そうそうですね、ま、確かに、だから、フレームワークの選定とか、もま、もちろん、リプレイスを始めていく人たちが、最初に1番触るものではあるんですけど、

Guest 42:13
やっぱり運用に乗ってくると、チーム内だけじゃないじゃないですか。いろんな人がま、その

Guest 42:20
大小はあると思いますけど、まあ、もちろんデザイデザインを触るだけでけど、やえー。リアクトのビの部分を触んないといけないだとか、

Guest 42:31
ま、あとは、今までレイルズに

Guest 42:34
レイルズがhtml持ってたのに、突然レイルズはAPIでジェイソン返すだけでいいです。ってなって、で、じゃあ、じゃあビューワってなったら、やっぱりフロントエンドのファイルを触っていかないといけない

Guest 42:47
っていうのがあるんで、まや、なかなかその何だろう

Guest 42:52
ま、決めた直後は自分たちだけなんですけど、最終的に結構ちょっとしてから、みんなが触るみたいになるので、

Guest 43:01
なんていうか、多分決めた直後にその触ってない人たちから、なんかつ

Guest 43:08
こう突っ込むのは結構難しいのかなと思っていて、うん、なんかやっぱり触ってみて、ああ、使いやすいなとかあ、ちょっと微妙だなっていうのが見えてくるとは思うんですけど、

Guest 43:21
ま、それにチーム街がま気づくというか、まあ触ってみるのがやっぱりちょっと1段階あじゃないですか。

Guest 43:28
うん、うん、うんうん、

Guest 43:31
最初からリアクトで開発してくださいってなってるわけではないので、私たちが作って、土台を作ってから、

Guest 43:40
あの、じゃあ、もうちょっといろんな人に触ってもらいましょう。ってなっていくと思うんですけど、その時にやっぱりその時になって、

Guest 43:50
なんでリアクトなの。って思う人が出てくるのかなと思っていて、イズ選定とかだと。

Guest 43:56
ってなった時にまちゃんと説明できるようにだけはしとこうと思ってま。そのなんで、ビーじゃないのかとか、なんでアンギュラーじゃないのか。なんでタイプスクリプト入れたのか

Guest 44:08
っていうのは、まそそそのちょっと遅い段階で気づかれても、多分もう

Guest 44:15
ひっくり返せないんですけど、うん、まなんでこの選択でこうなってきたのかっていうのは、まあログを取るというか、こういう

Guest 44:23
考えで、当時はこういうことを思って、こう入れて今こうなってるんですよっていうのがま、常に説明できる状態には

Guest 44:31
しとこうと思います。まあ、説明した上でなんでって思われる可能性はもちろんあるんですけど、まっていうぐらいしか

Guest 44:37
なかなかその最初まだ全然触ってもないし、あの、どんなものか見たこともない人に

Guest 44:45
いいかなって聞いていいよって言ってもらっても、お互い多分ちゃんと納得感がそうですね。得られてるとは思えないので、

Guest 44:55
まだからしょう。将来何かあれって思った時に、ちゃんと説明できるようにしておくっていうことくらいしかまできてないですし、何か

Guest 45:04
ま、むしろ私も何かいい案があったら聞きたいっていうのはありますね。

Guest 45:11
いや、そうなりそうですよね、確かに確かに触らないとわかんないですからね。そうです、そうですよね、

Guest 45:19
なんか、良さそうとかいうのはわかるとは思うんですけど、やっぱ細かい使い勝手とかは

Guest 45:25
偽装してみないと触ってみないとわかんないと思いますね、

Guest 45:33
ありがとうございます。ふんわりした質問で、

Guest 45:35
あ、いえ、こちらこそまり答えてしまいましたが、あ、あってましたがい、

Guest 45:39
参考になりますか。LINEさんそのまUITsって、めちゃくちゃチームがあるんですよね。確か

6. pirosikickさんの質問2 45:42

Guest 45:48
なんかそ感でこうなんか統一してることとか、逆になんかどうしてんのかなと思いました。なんか、その

Guest 45:58
なんだろう、各々が勝手にどんどんこうプラクの説教してってるのかとか、ま、それともある程度こう。まあ、何チームいるか

Guest 46:07
ちょっとわかんないですけど、10チームとかいたとして、ある程度こう統一して、こう。こういうアーキテクトでLINEはやるんだって決まってんのか

Guest 46:16
とか、なんかちょっと気になります。

Guest 46:18
それ言うと、多分全部フリーダムだと思い、ま

Guest 46:22
あ、それはそれでいいです。その

Guest 46:24
プロジェクトのリードとなっている人が、

Guest 46:27
あの最終的な責任を持つ。ただ、ぜあの、誰も触れないもの明らかに誰も触れないし、今後もないようなものは使わないみたいなところはま、

Guest 46:38
暗黙知としてはあるかなとは思いますね。例えば、将来的にこれが使えるようになるだろうっていうので、まあ例えばなんでしょう。

Guest 46:46
あのま、今だと結構当たり前ですけど、じゃあ、例えばあのネクストジェースが流行ってなくても、ネクストジェをつ使うみたいなのは、全然選択肢としてありだと思っていてま。それは多分、リアクトの

Guest 46:57
開発者がみんな使えるだろうし、その延長線上にあるっていうところで問題ないと思うんですけど、じゃ、

Guest 47:03
例えば、全然関係ない技術を始めて、基盤にしましょう。みたいなやつは、多分、あの基本的には誰も行わないようになっているっていうところなんでま、基本全部

Guest 47:15
お任せ、そんと、そこのプロジェクトのリードの人にお任せっていう感じにはなってますけど、まあ、大体技術的には担ってくるみたいなのは

Guest 47:24
あるかなと思いますね。採用技術とか、あと、アキテクチャの形は。でも、結構プロジェクトによって違う気はしますね。

Guest 47:32
なんで、ま、そこはお互いのスペシャリティーを尊重する

Guest 47:37
と言えば、聞こえはいいけれども、まるみたいな感じではあるかもしれないですね。うん、うん、

Guest 47:42
いや、こう同じ会社にいても、ま、例えばチームを移動したりすると、あれ、全然違うっていうのがまありうるっていうことですね、

Guest 47:50
こう頻繁にある気がします

Guest 47:52
あ、なるほど、そこを統一するよりは、もういろんなえ技術に挑戦していってほしいっていうことなんですかね。

Guest 48:02
ですね、なんか、あのデザインシステムみたいなものを統一しようって話はやっぱり上がっているんで、ま、そういったところで、デザインシステム用のコンポーネントみたいなのもあったり

Guest 48:11
がするんですけど、まあ、それはルックアンドフィールの話であって、アーキテクチャとか採用技術っていうところで言うと、まあ基本的に

Guest 48:18
裁量に委ねられているま、その時で1番良いと思う選択を取りましょう。っていう風に、

Guest 48:23
うんうん、うん、

Guest 48:24
やっぱり統一するとなんでしょう。時間の最新とのラグみたいなのって、絶対に生まれてしまうと思うんで、共通化するっていうところは、

Guest 48:32
うん、うん。その新しくいいものができたときに、それが共通企画として反映されるまでのラグっていうのは明確にあるかなと思うので、まあ、そこは

Guest 48:41
まあ、あの、そこの住所を第一にするよりはま

Guest 48:47
うん。そのそれぞれの技術、えそれぞれのプロジェクトの中で、技術の何か、採用技術の差とかがあったとしても、まそん時1番

Guest 48:54
その時点での最新で1番いいと思うものを取り入れましょう。っていう風になっていると思いますね。

Guest 49:02
なんか、こうす、なんかりリプレースだったりとか、すでに

Guest 49:07
お結構多くの人が触ってるもののま、何かリファクタリングとか。でも、あんまりその何て言うか、こう

Guest 49:16
こういう統一にしましょうとか、こういう技術にしましょうみたいなは特にないですか、

Guest 49:22
それで言うと、ニュースとかどうですか。いのいくのさん

Guest 49:26
そうですね、多分、

Guest 49:28
統一もニュースプロジェクトの中だけですよね。基本的には

Guest 49:33
そうですね、なんか、ほと

Guest 49:37
そもそも兼務してる人もいないので、他の事情がよくわかってないっていうのもあります。そうですね、ニスに完全に完結して

Guest 49:47
ますね、

Guest 49:48
うん、うん、うん

Guest 49:50
たいな感じかなと思います。ま、ただあの最近去年から開発ガイドラインの制定を始めていて、あの、そこは一応あったりはしますけど、それはアーキテクチャとかには、

Guest 49:59
まあ、そんなにこう深くは立ち入らないようにしてますね。

Guest 50:04
うん、なんか、もっとファンダメンタルな。例えば、すごい簡単でででと、タイプスクリプトのガイドラインには、

Guest 50:10
ストリクトアにしましょう。とかえにはやめましょうって書いてあるような、そのそういうその守ってほしいよねっていうリテラシー的な話は書かれているけれども、ま、あとはいえ、そのアーキテクみたいな。その時のその

Guest 50:22
その開発者自身の実力の見せどころみたいなところには、一切言及してないっていう風なガイドラインになってますね。

Guest 50:29
うん、うん、うん、

Guest 50:31
というところでございます。この辺は、結構各社によって方針も変わりそうなんで、ちょっといろんなところ、このメンバー以外でも聞いてみたいですよね。

Guest 50:41
そうですね、なんかまけど、結構結局そうなっちゃう。今話してたような感じに落ち着いちゃってるのが多いのかなって気は

Guest 50:49
ああまあまあそうですね。

Guest 50:51
結構そのあと茶とかの本とか読むの好きでよく読んでるんですけど、なんか、それをこう実践に落とし込む時に結構帰りがある気がするんですよね。そのあの、

Guest 51:03
モノリスからマイクロサービスとかもそうだし、進化的アとかもそうなんすけ。はいど、はい、

Guest 51:08
なんかああいうの書いてるようなこう、がっつり考えられてるような、アキテクチャーみたいなをやってるとこ。でも、やっぱほほとんど聞かないし、

Guest 51:17
なんかま、やっぱ実際そうなんないよなっていうのが、なんかやっぱどんどん確信に近づいていってる気がします。

Guest 51:28
いやけど、やっぱそうですよね、

Guest 51:30
そうですね、ま、そんな感じかなとじゃあ

Guest 51:40
ま、これをお聞きくださっている。皆さんもぜひぜひ、ハッシュタグUIT、アンダースコアインサイドで、各社の事例を教えてください。っていうところで、今日めましょうか。

Guest 51:53
なんか、統一してる会社とかあったら、ぜひ教えてほしいですよね。なんか、こういう風に統一することにしましたみたいな、

Guest 51:59
うん、そうですね、だから、ルールとかできっちり。

Guest 52:03
なんか、イエスニートとかルルとかま、細胞は結構共有してますけど。はいはいはいはい、なんかそれ以外でもなんかルール作ってますとか、そういう事例はなんか聞いてみたいですね。ぜひ、確かに、

Guest 52:12
なんか、リントのレイヤー以上のところのルール化って、どうやってるかとかあったら聞きたいですね。うん

Guest 52:19
すね、なんか、プロジェクトストラクチャーとか、ファイル構成とか。うん、なんま、それ以上でもいいですけど、うん、なんか気になります。最近、

Guest 52:30
ぜひお聞きくださってる皆さんはハッシュ、タグえ、ハッシュ、ティアンダースコアインサイドでぜひつぶやいていただければと思います。

7. クロージング 52:44

Guest 52:44
というわけでえ、今回はですね。えいくのさん、え、あいさんつさんの3名とともに

Guest 52:50
UITミートアップ、ボリューム、ティエレブのアフターショーとして話していきました。え、

Guest 52:57
今回のようにですねえ、フロントエンドに関する議論やその他

Guest 53:03
意見交換みたいなのを、実はLINEは社内でも結構頻繁に行っておりましてま。そういった内容をえ、普段のeitサイトで公開していたり、えしております。

Guest 53:12
是非ですね今回に限らず、他のエピソードもええお聞きいただければと思います。

Guest 53:17
またですねえ、エピソードを聞きなくなっている中で、え、もし、ラインに興味が出るって出た方がいらいらっしゃいました。らえ、ぜひぜひョノートの下の方にですね

Guest 53:27
今、中途採用、新卒採用へのインクを貼っておりますので、お気軽にご連絡いただければと思います。

Guest 53:34
最近はですね、ズムでのカジュアル面談も行っておりますので、ぜひぜひえーよろしくお願いいたします。

Guest 53:41
というわけでえ、本日はえ、エピソード81、えーUITミートアップボリーム、テレブのアフターショーでした。えあいさん、つさんえ、ありがとうございました、

Guest 53:50
ありがとうございました。