テクトーク始める
自由に始めてもらって大丈夫ですか?
はーい。
じゃあ、どうも〇〇から始めよう。
はーい。
どうも、ジールです。
どうも、スコットです。
スティーブと、僕、ジールとで、テクトーク始めたんですけど、
ちょっと前回のね、やってから間開いて、
最近、これ、スコットに変わるのどうかなって思ってて、
これ、あんまりちゃんとした、なんていうんですか、
僕からのオファーとかは特にしてないんですけど、
なんか、人づてにオファーをしてもらったみたいな感じのところもありますけど、
そんな感じでね、今日ちょっと一緒にやって、
次回からスコットにいろいろやってもらえたらいいなと思ってやってる感じですね。
はい、あのあれですね、前回ラジオの方に出たときに、
スティーブに外堀を埋められた件です。
あ、ラジオでね。
そう。
あ、なるほど。公開の場で?
そうそう。
あ、そうだったんですね。
そうですね、ちょっと今日裏方で出ないつもりだったんですけど、
たびたび名前が出ちゃったんですね。
技術ブログのマーケティング
いや、なんかスコットからDM来て、
エンジニアの、なんかね、前からブログとか、
技術ブログとか、なんかエンジニアの候補PRの採用に向けての、
なんかやりたいみたいな話はあったけど、
まあやっぱりラジオってなんか話すだけだったらなんかいいんじゃねみたいな。
はいはいはい。
そうそうそう。いろいろ考えすぎるという。
で、スコットからそういうDMが来て、
あ、これは機運だと思って。
おおー。
あ、もうすぐこれ晒そうと。
晒されちゃいました。速攻で晒されちゃいましたね。
スコットからこういう相談が来たからやってみます。
1分か2分後ぐらいのスラックで晒されちゃってましたね、確かね。
機制に難しくて。
で、での今日でした。
での今日で。
はい。
お邪魔しました。
はい。
テクニカルの込みったことはやっぱりラジオで話してもなんかわけわかんなかったりすると思うんで、
まあざっくりと会社の中でエンジニアはこういう感じで働いてるとか、
ちょっとテクニカルの話とかができればいいなぐらいの気持ちでしたね。
なるほど。
細かいことは何話すか全然考えてないんで。
まあ雰囲気、エンジニア的な、エンジニアの方で興味持ってくださる方が
人たちなんだろうとかね、働き方とかわかるといいなと。
そうですね。
込みった話もしましょうよ。
もうちょっと込みった話しますか。
込みった話しようとするとほらもうなんかスラッシュインクルードなんてわかったらみたいな話になっちゃって。
それを放送で伝えるのはなかなかあれですけど。
まあその辺はね、全然やってもいいのかなと思うんだけど。
膨大な予定データ量と開発
そうですね。
あとあれですね、社外の方から見たときにタイムツイートエンジニアチームはどんな感じなのかっていう。
主にはそこを共有したいなってところですかね。
なるほど。
人となりみたいなところを作って。
なるほど。
やっぱあれじゃないですか、組織みたいな話もチームとかでそのメンバーの話とかもあるけど、
やっぱりちょっと気になること聞いてもいいですか。
はい。
やっぱ不細じゃないですか。
技術的不細じゃないですか。
技術的不細ね。
そんな気になるんじゃない。
気になるんですよね。
それをどう取り扱っているのか難しいじゃないですか。
そうですね。
エンジニアに行き合わなきゃいけないし。
そうですね。
いきなりチームとか組織関係ない話してるでしょ。
関係あるっちゃあるか。
そうですね。
技術的不細っていう単語があんま良くないと思う。
なるほどね。
そうするとなんかエンジニアのものみたいになっちゃうんですけど。
確かに確かに。
本当はプロダクトのものであるべき。
そうですね。
プロダクトの不細になる。
そうですね。
なので、まだちょっと本格的に動けてはいないところではあるんですけど、
プロダクトの課題として、プロダクトのやることリストに入れて、
スケジュールを取って取り組むっていうことをやっていきたいなと思っていて、
何割くらいやればいいのかみたいな話とかはプロジェクトの段階とかによると思いますし、
ケースバイケースだと思うんですけど、
何割かは技術的不細というタスクに取り組むっていうことをちょっと継続的にやっていかないと、
巨大な不細がいつまで経っても解消されないっていうところが、
これまでタイムツリーの中でもずっとやらなきゃね、やらなきゃねって言うけど、
やらないといけないことをずっとやってたら、
いわゆる緊急度は高くないんだけど重要度が大きいことが見過ごされがちというか、
手がつけられない状態っていうのがずっと続いていたので、
そこにちゃんと取り組まなきゃねっていうことを啓蒙していくことが必要かなみたいな感じですね。
緊急度高くて、重要度も緊急度も高いものは割とやらなきゃって言って立ち上げてやるってことはまだできるけど、
結構ね緊急度低くてっていうのってサービス視点とかで見られるとどうしても優先度が下がっちゃいますよね。
なんかよくある例で言うと、まだユーザーさんに影響は出てないけど将来影響出るのは間違いないであろうみたいな感じとかは緊急度そんなに上がんないんだけど重要度が高い。
例えばですけどタイムツリーだと予定のデータ数がすごい多くて、
データベースの中に予定のデータを入れてるんですけど、
それのサイズがどんどんどんどんタイムツリーで予定をどんどんどんどん登録していただいて積み重なっていって、
それがサービスの価値だけど、それをどうパフォーマンスよく届けるか、ユーザーさんに届けるか、いかに正確に届けるかとかそういうことが課題になってくると思うんですけど、
今今そんなにユーザーさんにめちゃくちゃサービス使えないレベルでも遅いなっていう影響は出てないと思うんですけど、
僕は特にサーバーサイトのエンジニアによくそういうこと言う。将来ヤバそうみたいなそういうことを思ったりするので、
そういうことがいわゆる先ほどの話の緊急度はそんなに高くないけど、重要度が高いということの例だったりするのかなと思いますね。
データがやっぱ大きいと、ちょっとしたことがしづらくなるとか、そういう感じですよね。
そうですね。サービス開発してると、ちょっと見た話になりますけど、
データベースのスキーマっていってデータの定義とかを変えるっていうことがあると思うんですけど、
タイムツリーだと今ね、予定のデータが66億件ぐらいあって、
66億。
66億。データのサイズとしては4テラバイトちょっと。データベースとしては結構大きい方だと思うんですけど、
それに対して、例えばですけど企画のアイデアとして予定にこういうデータを付けたいってなった時とかに、
データのスキーマ定義を変更するってなったら、66億のあるデータに対してどうやってやんねんみたいなそういう問題があって、
普通に何も考えずにやるとサービス止まっちゃうんですよね。
列を追加するのにロックされてみたいな。
それをいかにしてユーザーさんに影響がないような形でデータを追加したり削除したりするみたいなことっていうのが、
サービス開発する上では機能を追加する時にいかに簡単に追加するかみたいなところだと思うんですけど、
データサイズが大きくなることで結構難しくなっていることかなって思うんですね。
よくね、Layers、Layersも使ってますけど、LayersとかでDBのマイグレーションのスキーマ変更しようってなったら、
なんか軽々しくね、あの列追加みたいなマイグレーションを書いて、ファイル書いて、
ドーンみたいな、リリースドーンみたいなのやってたけど、あれは絶対やっちゃいけない。
そう今はちょっと、今はちょっとご発動ですね。
そうですよね。一応ね、もちろんレビューとかもするから絶対止まるんですけど、
ただやっぱりそんなレベル感はもうとうに越してるし、
結構そのスキーマ変える時の手順、おさほみたいなのね、結構ありますよね。
そうですね。結構それだけ、特に予定のテーブルなんか、この間やったけど2週間くらいかかるのかな。
はいはいはい。
それでやってるっていう感じですけど、
2週間の間はサービス当然利用できるようにして、
そうですね。
スキーマを変えるみたいなことはよくやってる感じですね。
メンテとかそんな簡単にできないんですよね、私たちのサービスって。
そうですね。
日本だけだったら例えばね、深夜に3時とか2時とか、多分少ない時間帯に変えましょうとか、
多少定期的にやってもそんな影響ないと思うんですけど、
世界中でやっぱり使われてるので。
そうですね。昔はそれこそもうね、結構夜中の2時とかにちょっとメンテナンス10分入れてとか
っていうのをやったりとかしてましたけど、
今とかだとね、本当2時とかだとどこかのお昼になったりして、
そこで使っていただいてるユーザーさんがいるっていうのもあるので、
どこかで止めないといけなかったりすることもあったりするので、
ゼロはね、やっぱ難しいですけど。
なるべく短く、なるべくアクセスの一番少ない時間帯にみたいなことで意識して作業してます。
結構パフォーマンス的な、さっきパフォーマンスの話も出ましたけど、
パフォーマンスでもやっぱ出てくるもんですか?
やはりテーブルのサイズがすごく大きくて、
まだマスタースレーブで運用してるところもあるので、
その書き込み一つのデータを一つのところに書き込んでるみたいなところがやっぱり、
長期的に見るとどこかで上限が来ちゃうんじゃないかなっていう不安があるところですね。
そんなに目に見えてガーンって上がってるパフォーマンスが悪くなってるとかじゃないけど、
徐々に徐々にね。
徐々に来るんじゃないかっていうところですね。
そこで考えてるのは、今マスタースレーブって一つの書き込みデータベースで、
複数の読み込みデータベースっていうことなんですけど、
マスターデータベース
そこを複数のマスターのデータベースに、
例えばですけど、僕のカレンダーの予定は一番のデータベースに書き込んで、
そっちで僕はカレンダーのデータを2番に書き込むみたいなことをやって、
置き場所をちょっと変えることで、
例えばデータベースをたくさん横に並べれば、
パフォーマンスが並べた分だけ増えるっていうことができるようになってくるので、
そういったアーキテクチャの変更みたいなことを、
今これ計画しているっていうことですね。
なるほどなるほど。
いわゆるシャーディング。
いわゆるシャーディングですね。
シャーディングはどうなんでしょうね。
いろんな大きい会社とかだったりすると、いろいろ苦労されてると思うんですけど。
はいはい、そうですね。
インフラ周りももうちょっと技術の進化がすごいじゃないですか。
その要は、もともと単一データベースでやる限界って、
もっと当の昔にね、本当は切っててもおかしくない、
なかったけど、なんか進化しちゃってて、
逆にまだ後ろまで行けましたみたいなね。
そうですね。
感じでここまで来たって感じですもんね。
具体的に言うと、タイムツリーではAWSのAuroraっていうデータベースサービスを使ってますけど、
ストレージとかがね、分散されていて、
正直なところ言うと詳細の実装はわからないところがあるんですけど、
なんか全然パフォーマンスが落ちないしすごいっていう、
語彙がちょっとあれなんですね。
まあちょっとその状態も良くないなと思って、
社内で今論文読んだり、Auroraの論文読んだりとか、
そういう輪読会やったりして、理解を深めようっていうことはやってたりしてるんですけど、
まあ論文読んだだけでは実装はわからないんですけど、
何とか思想はわかるかなって感じですね。
なるほどなるほど。
そういうとこを深めつつも、
まあとはいえ、分散管理っていうか、
みたいなところも進めて、
スクラム開発と見積もり
そこに備えようって感じですね。
そうですね、去年とかは特にいくつかのプロジェクトとかで、
スケジュールの問題とかが出たりして、
リリースがなかなか予測できないっていうか。
そうですね、難しい。
やっぱり予測しづらいものとしてね、
言われてはいますけど、とはいえね、
やっぱりコントロールできなさすぎてもちょっと大変というかね、
事業的にもっていうのはあって、
何かそこで取り組みがスタートしてたりするんですかね。
そうですね、今具体的に言うとスクラム開発みたいなのを取り組んできたりしてて、
今何回ぐらい回したんだっけな、スプリント、
1回教科書通りにやってみましょうという形で、
しっかり本何名かで読んで、
教科書通りっていう形で始めて、
今ちょうどスピード5回か6回回したのかなっていう感じで、
毎回毎回やり方変えるみたいな感じで、
やり方変えるっていうかここが良くなったから、
ここはこうしようって改善していくっていうスタイルでやってて、
その中で見積もりはこうしたほうがいいんじゃないかとか、
もうちょっとミーティング時間こうしたほうがいいんじゃないかみたいな話とかを、
いろいろ改善しているっていう形ですかね。
で、まだちょっと見積もりに関してはすごい議論がいっぱいあって、
全然さらまってはいないんですけど、
それの議論自体はできていることは良いことかなと思います。
そうですね。
いろんなやり方でとりあえずいろいろ試してみてはいるっていう感じなんですけど、
なんか結構でもやっぱりチームとして合ってると思うことが結構重要なのかなと思ったりしてて、
だから会社タイムツリー全体でスクラムを取り組みましょう、
こう見積もりましょうみたいなことはやらないと思います。
なるほど。
どちらかというと自分たちに合った見積もりのやり方とかも全然変わってくると思って、
具体的に言うと今、
チームの中でiOSとかAndroidとかそれぞれである意味スクラムチームみたいな形で回して、
バックログが共通みたいな形で今回したりするんですけど、
AndroidチームとiOSチームで見積もりのやり方全然違うし、
全然スケールも違うみたいなところがあって、
Androidチームの1ポイントとiOSチームの1ポイント全然違う。
けどそれはそれで合っているという形でやっている感じですね。
その中で課題がどう出てくるかまだ分からないですけど、
出てきたら出てきたらまた議論するという形で進めていければなと思っている感じですね。
スクラムには結構あれですか、プロダクトマネージャーとかも普通に入ってって感じですか?
そうですね。
巻き込んでやれてる感じですか?
基本的には巻き込んでやるっていう感じですね。
なるほど。
スクラムマネージャーの人とかもあんまり馴染みのない、
スクラム開発の馴染みのないメンバーとかもいたかもしれないですけど、
その辺りとのコミュニケーションとかはどんな感じとかあったんですか?
そうですね。スクラムって用語がカタカナじゃないですか。
そうですね。
何言ってるか全然わからない。
独自用語というかね、スクラムっていうものを見ればわかるかもしれないけど、
そこでしかあんまり馴染みのないものが多いですね。
そうなんですよね。そこら辺の名前を変えるっていうことになったり。
なるほど。
例えばレトロスペクティブって言われたんですけど、
英語でレトロスペクティブって言われても僕はパッと意味が出てこなかった感じなんですけど、
開発プロセスを振り返る回ですよねっていうことで、
日本語にして目的をはっきりさせてやるっていうことになったりとか、
なんとなく今までレトロスペクティブ、KPTみたいな感じでやってたんですけど、
だからこう、Kが何々できたみたいな。
プログラムが何々できなかったみたいな、そういう話になりがちで、
そういうKPTじゃないんだよみたいなことを、
開発プロセスの振り返り回っていう名前に変えて、
開発プロセスについてKとPを挙げましょう、
トライをできる範囲でやりましょうみたいな感じで、
名前を変えることでちょっと理解がしやすくなるようになるんじゃないかなと思って、
ちょっとチャレンジしてみたって感じですね。
名前大事っすよね。
目的を表す、ちゃんと名前になってるかみたいなね。
結構大事ですよね。
テクトークTTTTですか?
TTTTですか、このタイムツリーテクトークは。
ちょっと役称が分かってないですけど、
TTTTをよろしくお願いします。
頑張っていきたいと思います。
そんなね、肩肘張らずにゆるーく、
ゆるーく長く続けていきたいなと思います。
そうですね、その感じがすごい出ると思います。
ありがとうございました。
はい、頑張っていきます。ありがとうございました。
