1. TimeTreeラヂオ
  2. 81 iOSチーム雑談! #TimeTree..
2024-09-23 18:36

81 iOSチーム雑談! #TimeTreePeeps

Steve
Steve
Co-host

「TimeTreeラヂオ」はカレンダーシェアアプリTimeTreeを運営する私たちメンバーが、ふだんの仕事に関係することもそうでないことも、だいたい15分でひとつのテーマを話しきるインターネットラジオ番組です。


TimeTreeをつくる同僚も、TimeTreeをつかう世界中のユーザーも、みんなTimeTreeのたいせつな仲間たち! #TimeTreePeeps はTimeTreeを盛り上げてくれる多彩でナイスな仲間たちとお話しするポッドキャストシリーズです。


今回の #TimeTreePeeps はiOSチームのTrevor, Baxとチームについて雑談しました!


◎TimeTree Company Deck(会社案内資料) ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠

⁠⁠⁠⁠⁠⁠⁠⁠⁠https://bit.ly/3IyEEWt⁠⁠⁠⁠⁠⁠


◎一緒に働く仲間を募集しています!(採用応募ページ) 

⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://bit.ly/3MyqZjE⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠


番組の感想・コメント・ご要望はハッシュタグ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠#TimeTreeラヂオ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ でつぶやいてください!

サマリー

このエピソードでは、iOSチームのメンバーが好きな筋トレについて話し、その後Time Treeでの働き方や開発環境についての詳細を共有します。特に、iOSアプリのリリースサイクルや自動化の仕組み、コミュニケーションツールとしてのSlackの利用について触れています。また、iOSチームのリリースプロセスやテスト手法について詳しく語られ、チームの協力や雰囲気の良さが強調され、プロフェッショナルな姿勢が際立っています。

筋トレメニューの共有
好きな筋トレのメニューは、オーソドックスな腕立て伏せですかね、のスティーブです。
好きな筋トレメニューは、ランニングのトレバーです。
好きな筋トレメニューは、胸のトレーニングです。主にチェストプレッサーになってます。バック。
よろしくお願いします。
なんか一人苦労とかいたな。
知らない言葉が出てきたら。
テストプレッサー。
でもなんか英語だけ聞いたら、スティーブの言ってる腕立て伏せみたいな、そう感じに聞こえますね。
どんなトレーニングなんでしょう?
部位的には同じだと思うんですけども、
チェストってあれですよね、胸トレプレってのはオフィってことなので、
大体みんながわかる英語で構成されてるので。
内容全然教えてくれんや。
でも要するに腕立てではあるんですけど、腕立てってうつ伏せになる形でやるんですけども、
チェストプレッサーは椅子に座って、椅子というかシートに座ってですね、前に寄せるという種目になるんですね。
仰向けっていうのもあって、仰向けになるとこれはベンチプレッサー。
実は胸っていうのはいろんな方向からオフってことをやらないといけなくて。
勉強になります。
ちょっとその辺にしときますか、深淵を覗いた気がする。
一人だけ苦労とかいた?
筋トレやり始めるとこれが当たり前になってくるんで、そっかそっか。よろしくお願いします。
Time TreeのiOSチームの紹介
お願いします。
今日は2人ともですね、iOSチーム、iOSエンジニアなのかお二人、トレバー、アルバックスをお呼びして何を話すかというと、
iOSチームの普段の働き方ざっくりなんですけど、普段どんな働き方をしているのかというところをお二人にいろいろ聞いていこうかなと思います。
はい、よろしくお願いします。
お願いします。
時期的にはiOS DCってイベントが終わったあたりかな?になるのかな?これは配信は。
Time TreeのiOSチームについてちょっと気になってくれた方とかが聞いてるんじゃないかなと思っております。
トレバーです。今ちょっと調べてたんですが、2018年の11月にTime Treeには入社しました。
もうTime Treeに入ったのはだいぶ前になるんですが、今のところチームの中では今年31歳なんですが、最年少ということになっております、まだ。
ということで、iOSチーム、高年齢化が日本社会と同じで進んでおりますので、ぜひぜひ若い方、別に切ってるわけじゃないですけど、若い方来ていただけるとフレッシュな風がiOSチームに吹くんじゃないかなと思っております。
バックスです。
そうですね、トレバーが2018年ということだったんですけども、自分はその1年前に、時期的にはその時期に入社したということになります。
その時ですね、自分はまだiOSエンジニアとしてやっていたわけではなくて、1回その会社ではiOSエンジニアとしてやっていたんですけども、
そこから1回iOSから離れていたという経緯があって、Time Treeに入社する時にもう1回iOSエンジニアをやろうということで、
入社と同時にもう1回iOSエンジニアの、iOSの勉強を始めたという、そういった経緯があります。
そうですね、簡単にその時の状況を説明しますと、以前はObjective-Cという言語で開発していたんですけども、
今はもうSwiftという言語になっていたりして、ある意味ですね、もう一度フレッシュな状態でですね、
Swiftから勉強してという感じだったので、すごく新鮮度を持って開発をしてきたという、そういうエンジニアになっています。
なるほどね、じゃあSwiftがTime Treeの中でも機運が高まってきたタイミングでVAXは入社されて、
その後1年ぐらい経ってから取ればほぼ同期みたいな感じですね。
そうですね、入社当時からVAXにはお世話になっていて、技術的にも筋肉的にも頼れるパイセンかなという感じでございます。
素晴らしい。
一体だけですね。
いやいやいや、これは本当に困った時にどこからでも駆けつけてくれる頼もしい先輩でございます。
でもそういう意味では、僕も入社した時はほとんど分かってなかったので、
それこそSTATとかSEONとかにすごくいろんなことを教えてもらったっていうのがあって、
えー、意外。それは意外な一面でした。
いや、本当にスイフトの本は読んで勉強してたんですけども、
全然業務レベルじゃなかったんで、ここはこう書くんだよっていうレベルから本当にSTATとかに教えていただいたっていうのがあって、
なんていうんですかね、STATとか言ってた、自分が技術を作っちゃったみたいなことをおっしゃってたかもしれないんですけど、
でもその当時っていうのはやっぱりスイフト出たばっかりの時っていうのは、やっぱりみんなが手探りでやってるっていうところが大きかったと思うので、
そこはもう、なんていうか、新しい言語を触るというのは必要な選択肢っていうのがあって、そこをうまく選んでいくっていう作業が必要だったので、
ここは全然僕は、逆になんていうか、挑戦的にスイフトをちゃんと使っていたっていうところが本当にいいところだと思うので、
本当になんていうか、先人には感謝しても好きでないっていう、そういう気持ちではいますね。
マックス優しいなあ。
そんな感じだった、いや全然そんな想像できなかった、ずっと助けてもらってたから、入社当時から。
それがうまく入ってくる頃にはもうだいたい知ったかできるようになってたんで。
知ったかだったんかい。
いやいやいや。
それを感じさせなかったらもう知ったかじゃないですよ。
いやいや、まだわからないことが多いつつ、知ったかできるようになったんで。
開発環境とリリースサイクル
何から聞いていこうかな。
すごいスタンダードな標準的な情報として、まずチームの開発環境ですかね。
基本的な情報を取れば聞いてみたいなと思います。
最初にどういうスケジュールで働いているかみたいな。
まずそこね。
ちょっと紹介したいなと思うんですけど、
基本的にTime TreeのiOSアプリは1週間に一度コンスタントにリリース、バージョンアップをしておりまして、
それに合わせてiOSって、これを聞いてるiOSエンジニアの方だったらご存知かもしれないんですけど、
すぐにアップデートっていうのができなくて、一回Appleに審査に提出しないといけないんですよね、ソフトの。
その審査に提出するのを毎週金曜日にやってます。
で、土日に審査がだいたい終わって、次の週の月曜日に段階リリースといって、
少しずつその新しいバージョンをユーザーさんに届けるっていうことをしてます。
で、もともと金曜サブミットじゃなくて、
なんか機運が高まったらなんとなくその時に審査するみたいな感じだったんですけど、
それだと何か問題が発生した時に、例えば金曜日にリリースしたりして、
何か問題がそのバージョンで発生したってなった時に、
次の日は土日だと、みんな休みだってなった時にバダバダしちゃったりするので、
チーム全体で合意を取って、金曜リリースは危険だということで、
いろいろ対応ができる月曜日にリリースをしようということになって、
そこから逆算して金曜日に審査に出すという体制になってます。
1週間ごとに動くチーム、開発もそうだし、
割といろんな会議台とかチームのコミュニケーションも1週間単位でいろいろ動いてるってことですね。
そうですね。会社全体がその1週間ごとにコンスタントにアプリとかサービスを更新できるような体制になっていると思います。
コンスタントに1週間に1回リリースをするために、
自動化できるところはどんどん自動化していこう。
人間が触らなくていいところはどんどん自動化していこうっていうことになってて、
現在はGitHub ActionsっていうものとBitriseっていうものを使って、
基本的には自動的にビルドから審査に出すところまで自動化されております。
あとはそうですね、リリースの前に例えば社内の人たちにたくさん触ってほしいなっていう時には、
FirebaseのApp Distributionというサービスを使って、
指定したバージョンとか指定したブランチのビルドを社内に配布できるような仕組み作りができております。
そのテストで試したいよっていう人も、
エンジニアにいろいろやってくださいっていうそういう依頼をしなくても、
社内にドキュメントがちゃんとあって、
SlackでBotでこの端末登録してみたいな感じで言うと、
端末が登録されて、その端末でテストができるような環境が整っております。
あれめっちゃ便利ね。
あ、使ってます?スティーブも。
あれめっちゃ便利ですね。
登録もそうだし、テスト版をこうインストールして自分で試すみたいな仕組みも。
最近別のメンバー、Meganが導入してくれたんですけど。
そうですね。MeganがFirebase Distributionは導入してくれました。
めちゃくちゃいいですね。
かなり過去のバージョン、たくさんのバージョンをスタックできるのがいいですね。
あとは会社のコミュニケーションの、テキストコミュニケーションのベースがSlackにあるんで、
大体のことはSlack基点でできるようになってます。
なってますって偉そうなこと言ってますが、
大体さっきから名前がかかってるスタッドとかが整えてくれております。
審査に出すときも審査に出して、みたいなことを言うと審査に出したりしてくれますね。
リリースプロセスとテスト
そんなところですかね、環境全体の環境で言うと技術的なところ、コミュニケーションのところ。
リリースの流れはさっき言ったように1週間ごとなんですが、
この辺りからバックスに話を聞いてみますか。
そうですね。リリースの流れ自体はCIでほとんど処理ができていて、
リリース後の話になるんですけども、これはですね、段階リリースっていうものを、
これはApp Storeの機能としてあるもので、この段階リリースっていうものを使ってやってますね。
なぜ使ってるかっていうことなんですけども、これいきなり100%ってことにもできたりするんですけども、
やっぱりタイムツリーすごく多くのユーザーさんにご利用いただいてるっていうこともあったり、
あと新しい機能とかを入れると、それが原因で実は起動しなくなるみたいな、
そういうインパクトが起きてしまうことがあるんですね。
そういうことを防ぐために、1%くらいのユーザーから段階リリースを始めて、
そこでクラッシュログなどをモニタリングしながら問題がないっていうことが確認できてから、
どんどん浸透を高めていくという、そういった流れになっています。
こちらもですね、過去にいろいろ一気に100%にしてしまった方がユーザー的には嬉しいんじゃないかとか、
こっちが借りしやすいんじゃないかみたいなこともあったんですけども、
やはりいろんなことをやっていくときに、どうしてもリスクの方が大きくなってしまって、
そういったことを考えると、やはりちょっとずつ浸透させていくっていうことが、
安全な方に倒すっていうことでは有効なんじゃないかってことで、今そういう形になっています。
なるほど。
金曜リリースっていうところも、さっきの話に関わってくるんですけども、
例えば金曜に段階リリース開始してしまうと、土日挟んで浸透が高めてしまうっていうことがあるので、
金曜日にサブミットして月曜日に段階リリース開始っていう風にやっておくと、
平日を挟むので、そういった意味でもここがいいんじゃないかってことで、
月曜段階リリース開始という風に選んでいるっていうのも理由がありますね。
サブミット審査に出す前にのテストも一応チーム全体で触ったりとかしてますよね。
これも安全な方向に倒すっていうやつに絡んでくるんですけれど。
そうですね。最初は何となく触ってみて大丈夫かどうかっていうところだったんですけども、
やっぱりそれじゃちょっとまずいっていうことができて、どんどんブラッシュアップしていって、
今はなんかテストシートみたいなのがありますよね。
ありますね。もう退職しちゃったんですけど、Syncっていう、
タイムツリーに対応するチームのメンバーの人が、今でもコミュニケーション取ったりしてるんですけどSyncとはいろいろ。
その人が取り入れてくれた仕組みがあって、タイムツリーのコア機能はテストシートで網羅して審査に出す前に必ずテストをする。
対応しているiOSバージョンと、あとは端末でテストしてからリリースしようという風になってます。
iOSチームの雰囲気
これもかなりバランスがよくできたシートで、1から10まで全部テストしてると毎回のリリースが遅くなっちゃったりとか、
我々の作業コストがリスク回避によって得られるメリットを上回ったりしちゃうんですけれど、
その辺をコア機能かどうかみたいなところで段階的に分けて、通常のリリースの時はこの範囲だけやろう。
あとはiOSのメジャーバージョンアップとか大きな影響がありそうなものに関しては全部やろうと、いくつか段階に分けてテストシートが組まれています。
最後、チーム自慢で終わりましょうか。iOSチーム自慢をそれぞれ一言ずつぐらいいただこうかな。
一言で言うと仲がいいっていうことにつけると思います。
仕事の相談も、それとは関係ない趣味とかその辺の雑談もすごいしやすいっていう。
なんかこの前よなよなオフィスでファミコンやってましたもんね、みんなで。
やってましたね。みんなでボンバーマンやってました。
みんなでやってました、お疲れかいということで。
あとは困っている人がいたら助けましょうみたいな雰囲気があるのもすごい大好き。
それは本当そう。チームのみんなだけじゃなくて、iOSチーム、他のエンジニアもそうですけど、基本的にどの社員にも訳隔てなく助け合いの精神がありますよね。
そうかも。これはチームの特性じゃなくて会社の特性かもしれない。会社のメンバー全員の特性かもしれない。
ワックスどうでしょう?
今トレーバーが挙げてくれたところは僕も分析しているところで、
そうですね、それとはまたちょっと違った視点にはなるんですけども、
やっぱりみんなこう割と緩い雰囲気、なんか和やかな雰囲気でやっている中でも、
みんなそれでも本当にプロフェッショナルな気概を持ってやっているなというところをすごく感じてはいて、
僕がすごく感じるのは、やっぱりユーザーさんに影響のあるバグとかが起きてしまった場合に、
すごくみんなでそれに、担当とかだけじゃなくて、みんながそれに関して解決しようというのがすごく感じることがあって、
まずはそういうことが起きているということがどこかのチャンネルとかで発覚したりはするんですけど、
そこからもうIOSチームが一丸となってそれに対して解決しようというのを担当者とか関係なく、
みんながそこで一丸になってやって、できるだけ早く解決しようみたいな、
そういう団結力みたいなのをすごく感じる場面があって、
そういったみんな緩い雰囲気でやっているけど、やるときはやるという、
そういったプロフェッショナルな気概を感じるということが、
いいところでもあるから。
だったん物発してもらって、なんかふわふわな感じで遊んでいるだけじゃないかみたいな気になるところだった。
確かに。
ちゃんと技術的なキャッチアップとかもみんなでして、
共有とかもしてますよね。
だいたい新しいメジャーバージョンが発表されたIOSのいち早く対応して、
Day1、そのIOS新しいメジャーバージョンが世間にリリースされるよってなった時にはもう対応が終わっているっていうのがほとんどだったりとか、
新しい機能をどうタイムツリーに取り入れていこうかみたいな話とかもみんなでしたりとか。
そういった一面もちゃんとありますっていうのをちょっとここで言っておきたいです。
よかった。最後閉まったワークスで。
ありがとうございます。
じゃあこんなところでですね、IOSチームのお二人、トレバーとワークスをお呼びして、
簡単にチームの紹介、雰囲気の紹介とかをしてみました。
ありがとうございました。
ありがとうございました。
ありがとうございました。
18:36

コメント

スクロール