00:12
はい、TimeTree Tech Talkを始めます。 TimeTree CTOのスコットです。
この番組、TimeTree Tech Talkは、TimeTreeのCTOのスコットが、カレンダーシェアアプリ、TimeTreeを開発しているエンジニアのメンバーに、日々の開発の話をザックバラに言っていく番組です。
はい、ということでね、ちゃんと今回は前向上を言えました。
ここ数回の収録では、実は私が編集をしてるんですけど、編集してて気づいたのが、自分自身の自己紹介は全くしないっていうことに気づいてしまい、急遽収録前にAIに前向上を作ってまいりました。
後撮りで差し込んでもいいんじゃない?
確かに後撮りで差し込んでもいいかもしれない。
はい、それで今回はですね、前回はですね、TimeTreeのリニューアルのプロジェクトのiOSのメンバーにその裏話について聞いたんですけども、
今回はですね、Androidのメンバーにそのリニューアルプロジェクトの苦労話というか、開発裏話みたいなものを聞いてみようと思っています。
Androidメンバーの3人に来ていただいてます。はるとみんぐとしゃびですね。
じゃあ、この順番でそれぞれ自己紹介をお願いしていいでしょうか。
はい、はると申します。Androidエンジニアです。よろしくお願いします。
そうね、Androidエンジニアだね。
はい、創立メンバーでずっとAndroidを担当してます。時々Webもやったりしてます。
なんか出てくるじゃん、言えば。
はい、じゃあ続いて、よろしくお願いします。続いて、りんぐお願いします。
はい、2020年5月入社のりんぐです。ずっとAndroidです。はい、お願いします。
はい、よろしくお願いします。
じゃあ最後にしゃびお願いします。
はい、しゃびです。自分は去年の8月入社です。なので今回のこのプロジェクトの途中から参加するような形になってます。よろしくお願いします。
はい、よろしくお願いします。タイムツリーのリニューアルですね。前回のiOSのときにもお話ししたんですけれども、
1月の末にリリースしまして、よりタイムツリーは共有カレンダーっていうカレンダーの軸からユーザーさん一人一人の時間みたいなものを起点にしたUI UXにアップデートしたというような形ですね。
03:06
その変更に伴って開発の裏側では本当にいろいろあったそうなので、それについて聞いていきたいなと思っています。
はい、じゃあちょっとありきたりな質問ですけど、開発で大変だったことって何ですか、はる。
はる。そういう感じのフリ。
そう、そういう感じで振っていきます、今回は。
iOSの人はちょっとラジオ慣れしてるからさ、そのペラペラ喋ると。
Androidはもう社員の集まりだから、ちょっといい感じにフリをしていただけると助かります。
まだまだ、そんなこと言ってハードルを上げちゃっていいんですかね。
本当に下げたつもりなんだ。
Android、いろいろありましたよね。
いろいろあったんですけど、大変だったの結構iOSと似てて、コードを見ながらこういうところを変えていかなきゃいけないよねって最初、雑にタスクを出したんですけど、結構iOSと課題が被ってて、
構造とかも結構似てるんだなと思って、その辺は面白かったんですね。
iOSの時は画面上に一つしかカレンダー出さない前提があったっていうのも、Androidだと同じですか。
そうそうそう、そういうのが一緒で、元々カレンダー一つしか表示しないから、それをシングルトンで管理してて、
各画面とかゲームモデルではそのシングルトンを見て表示するカレンダーでデータをロードしたり、データ取得したりみたいなものを実装してたんだけど、
その辺りのコードがガラッと画面がレイヤーが増えたことで、前提が崩れちゃって、これどうしようってなります。
やっぱiOSもAndroidも前提が崩れてしまい、大変みたいなところは一緒なんですね。
あとこれもiOSと一緒だと思うんですけど、ベータテストっていう形で両方が動くような形で提供するっていうところもやっぱ大変でしたかね。
そうおっしゃる通りで、元のUIでも動くようにしながら、例えばアプリ起動時のダイアログとか、通知からの起動とかカスタムスキルからの起動とか、
そういうのを全部移植しながら元のUIでも動くようにっていうのが大変で、
テストもコースが新UI、リニューアル後、両方でやらないといけないのでテストコースも2倍かかっちゃいますし、
久しぶりに触るような実装もあるので、古い実装で仕様わかんなかったり、実は動いてませんでしたみたいなものも発見できたりで、
06:05
思ったよりコースがめちゃくちゃ大変だったっていうよりコースが思ったよりかかったって感じですね。
なんか久しぶりに触るみたいなところも触る、回収の対象になってきたから、なんだこれみたいなやつとか、
なんかこういうふうに書いてあるけど全然そんなふうな実装になってないんだけどみたいなやつがいっぱい出てきた。
そんな感じですね。技術的に難しいっていうよりは、確認するコースとかそういうところが大変だったかなという印象でございます。
その辺はずっと開発長いこと続けてきたからこそ、ならではの起こるトラブルなのかなという感じで、やっぱり見積もりが難しかったかね。
見積もりすごい難しかったですね。なんかやりながらどんどん出てくるタスクもあったりで、思ったよりスケジュールも時間かかっちゃいましたね。
なるほどね。この辺はやっぱり基盤部分に手を出すとそういうことになりがちというか、大幅にコンセプトから変えるってなるとやっぱりそういうことになっちゃうよねっていうところですよね。
そうですね、その通りです。
なるほどですね。
後半はそう、結構タスクがいろいろ出てきちゃってスケジュールきついってなってたんですけど、最初の方はもっと希望に満ち溢れてる時間もあって、ちょうどリニューアル版実装始めようって思ったときに、
ナビゲーション3っていうのがグーグライオーなんかで発表あって、画面遷移の管理の仕方をライブラリーでできるよっていうやつなんですけど、
今までタイムツリーって昔ながらのアクティビティフラグメントの画面遷移だったんですけど、ちょうどよく出てきたもので、まだアルファ版だったんですけど、検証して導入をしましたね。
なんかあれですね、ここぞとばかりに入れてみたみたいな感じ。
すごいタイミング良かったっていうのと、タイミング良かったっていうのは、ライブラリーがリリースされたっていうのもあるんですけど、大きく画面構成変えるっていうタイミングなかなかなかったり、
あとはタイムツリーって縦の画面しか対応してなくて、スマホ横にしても向き変わんないと思うんですけど、そのあたりの横画面とか大画面、タブレット対応とかが近々必須になるんですよ。
09:09
それはもうGoogle側の方針で。
その準備にもなるなと思って、導入をしましたね。
なるほど。将来的にはこのナビゲーション3でいうやつで画面の遷移なんかを管理するようになるんだっていう方針を察知して、そのタイミングだったら入れちゃおうかって感じですね。
そんな感じでございます。
なんか宿題的にこう、年8月ぐらいからだったかな。
ターゲットSDKバージョンっていうのがあって、それをAndroid16にすると、もう大きな画面、タブレットでは勝手に向きを横にしたらタイムツリーも横になっちゃう。
それ対応しなきゃいけなかったんですよね。なので、それを対応しやすくするためにも導入しました。
確かに、そのレガシーな仕組みを使っているとより苦労するだろうっていうところもあるし、
動いているところに手を入れるっていうこともあんまりしないだろうから、この際一挙にやることで、そういったところも未来の投資も技術的なところも入れられたんで。
そういうところでございます。
なるほどですね。見積もりも難しくて、結局伸びちゃうっていうところもすごいわかるし、この際だから新しい仕組みを。
リリースのタイミングも良かったっていうのもあるだろうけど、この際だから入れてしまおうという気持ちもエンジニア的にすごいわかる感じですけど。
いろいろ盛り盛りにやるってなると、リリースがドカッと出すことによって死んでしまうみたいなことっていうのは、プラットフォームに限らずあることだと思うんですけど、リリース面で工夫したことってリングありますか?
リリース面、画面全体で作り出す部分は先には出せないんですけど、自分は結構カレンダーの目玉になるフィルター機能だったりとか、先に出してもいい機能があるので、そこはもうユーザーさんのフィードバックを先に得たいということで、なるべく先にリリースするっていうのをやってました。
なんかこう部分部分で細かく分割していって要件っていうんですかね、これは先に出してもいいだろうみたいなのを出していったっていうことだと思うんですけど、これはチームで議論したんですか?
チームでそう
この機能出したいみたいな話をエンジニアから出したのか、それともPDM的にも早くフィードバック欲しいから出したいみたいな話で出てきた話なのかというとどうなんでしょう?
12:13
出しはPDMの方だった記憶があります。途中でこれも出せる、これも出せるっていうのはエンジニアからも提案してた記憶があります。
なるほどですね、この辺りはプロダクト開発のあるあるで部分部分から先に出していってフィードバックもらうっていうのをやりつつ、エンジニア的にこういうのを先に出せるよみたいな話を提案してどんどん出していったみたいなことですかね。
そうですね。
ただとはいえ、大きなリニューアルの前後とかでデータがコンフリクトするみたいなことってなかったんですかね。
前の画面と新しい画面で長尻が合わないところはあるので、そこはどこまでフォローするかだったりとかを考えながらやってましたね。
結構その辺がもうなんていうか、一個一個細かくやらないといけない作業で膨大な数があって途方にくれるみたいな感じだと思うんですけど、ここはもう本当に一個一個やっていくしかないみたいな感じでした。何か工夫とかありましたか。
事前に洗い出して、ここまでは妥協できる、妥協というかここまではリリース後でもリニューアル後でもいいねっていうのは話しながら進めてました。
りんぐが詞をすごい洗い出してくれてめちゃくちゃ助かりましたね。結構メインで自分詞を書いたりしてたんですけど、まあまあ抜けがあって、そのあたりりんぐが改めてテストしてくれたり、
iOSのトレバーとかもいろいろ突っ込んでくれて、仕様がだいぶ細かく起こすことができたのは良かったですね。
やっぱり一人だとなんぼ創業メンバーでも漏れる。
もう覚えてないんですけどね。フォローからここから起こすしかなくて、すごい助かりました。
まあなんかそのあたりはチームでフォローし合ったことで、カバー率みたいなものが上げられたんで。
それで出てきたタスクも、どこまで本リリースまでやるのか、後半は結構スケジュールカツカツだったので、捨てる部分、必須で実装する部分っていうのをちゃんとPDMと確認取りながら進められたのも良かったとこですかね。
なるほどですね。で、あとシャビは自己紹介のところでもあったけど、このプロジェクトの半ばぐらいから参加したんでしたっけ。
15:07
そうですね。自分は先ほど話された設計とかがある程度完了して、後はもう手を動かして実装するぞっていうようなフェーズでの参加になりました。
なるほど。受け入れた二人もそうだと思うんですけど、シャビも本人ももっとあれだと思うんですけど、入ったばっかりで大規模プロジェクトに投入されて、率直にどうなんですかね。不安だったりとかそういったことはなかったんですか、みんな。
いや、不安はもちろんありましたよ。
だよね。
結構今回のって、これまでのアプリの構造をガラッと変えるものなので、やっぱりこれまでの経緯を知ってる人の方がやはりなんでこれやるんだろうと分かると思うんですけど、
自分はそういう背景を何も知らない状態だったので、やっぱりそこのキャッチアップとかは大丈夫かなっていうのはすごい思ってます。
受け入れた二人はどうでしたか、シャビの活躍ぶりは。
そうですね、自分はその見積もり、出したタスクの見積もりと、あとスクラムしてたんでそのベロシティから、これスケジュール結構厳しいなっていうのも分かってて、二人でやってたとき。
で、新しく人を入れようって話にはなったんですけど、もうすでにこのやってるチームが他のチームから人を引っ張ってきて作ったチームだったので、新しく引っ張る余力が他のチームもないんですよね。
だから無理ってなって、じゃあ新しく入るシャビを入れようかって話にはなったんですけど、やっぱりそのなんでしたっけなんとかの法則とかありますよね、ブルックスの法則とか。
なんか難しい言葉出てきた。
新しい人入れてもそのスケジュールは別に早くなんないよって、初期投資の方がでかいからっていうのがみんな予想してたんですけど、もうそんな予想はどこへやらもう即すぎる戦力だったイメージですね。
りんぐがシャビのメンターしてたと思うんですけど、りんぐってどうでした。
でも全く同じです。即戦力だなって思いますね。
入社したばっかりのメンバーがいきなり活躍するって確かに本人の能力もあるかと思うんですけど、色々周りのサポートもあるかなと思っていて、シャビから見た時にどういう風にしてくれて、どういうことが助かったとか、そういったことってありましたか。
18:18
そうですね。一番大きいところだと、やっぱり二人ともすごい列が早いと言いますか、分からないところがあったらいつでも相談できる場を受けていただいて、主にスラックでのやりとりとかになるんですけれども、そちらの方で分からない点があって、それを質問するとすぐに答えてくださったり、
一時的にすぐハドルで会話したりとかをしてくださったのが、自分であんまり抱え込まずにスムーズに作業できたなっていうのがあったのと、あとタスクも入ったばっかりの人でも分かりやすいようなものを見つけようっていただいていたのかなと、自分としては感じてました。
そうですね。やっぱりすぐコミュニケーション取れるの、特に今リモートでみんなやってますよね、だったりするので、即レスをもらえるっていうのは、やっぱり抱え込まなくていいっていう意味で言うと、すごく助かる予想なのかなと思いますし、そこはみんな結構スラックのメンションとかもらうと、すぐ早く反応してくれる人も会社的にも多いのかなと思ってたりするので、
その辺は確かに、いきなりタスクフォースにシャビを放り込んだ側ではあるんだけど、みんながすごい助けてくれたおかげで、シャビもうまく軌道に乗れたのかなと思いますし、シャビもそれがあったからこそ、自分の力を発揮しやすかったみたいなところがあるのかなと思ってて、
本当に外から見てるだけでしたけど、すごいタスクをこなしてるっていう話は聞いていたりしたので、その辺の秘訣っていうかところで言うと、そういうコミュニケーション面のサポートっていうのはすごい重要なのかなっていうところと、あとナレッジをためるために分かりやすいタスクから順々にやっていって、どんどん深いところに入っていくっていうところができてたのかなみたいなところなのかなと思って、
そんななんか素晴らしい何かのチップスがあるってわけじゃなくて、普通のことを普通にやってただけと言われるかそうかもしれないんですけど、それを普通にやるのがやっぱりすごい大変ですよね、特にスケジュールがカツカツなチームだったりすると、そういうことができてたのが良かったなと思うし、おかげさまでシャビは一人前のAndroidエンジニアになったと聞いておりますので、
おかげさまです。
まだまだ。
1人前って言うと、何目線なんだって感じやけど。
本当にシャビ助かって、なんか既にある共通モジュール、共通コンポーネントとかもここあるんですよね、よくそれ見つけてきたなみたいのも使ってくれてて、本当になんか全然何も教えてないのにすごいなと思って助かっておりました。
21:07
おだしょー じゃあ コードは結構 読んでたんですか シャビは
しばやん すごく気になる どうやって 見つけたんだろうと
しばやん それで思ったのは AIを 結構 コードリーディングのほう
に使ってて
おだしょー 今どき
しばやん 今 会社の環境としても AIがすごい使える環境が整って
たので バリバリ実装とかは まだ AI使ってなかったんですけど
そういうコードの固有機能どこにある みたいなのは 結構 AI使って調査
してたんですか
しばやん 半年前だから 今 2026年の3月で だいぶコードも書けるんじゃない
みたいな話とかになってきますけど まだ半年前とかだと 微妙なコード
もたまに吐き出すとか あったり するような状況だけど やっぱり
リーディング周りですごいたすか ったりとかした感じですかね
おだしょー そうですね
しばやん なるほど いや これは あれじゃないですかね 新しいプロジェクト
に入った人にとって すごく有益な 話で AI使ってコードをたくさん
読めば 何だろう 何でこれ知ってる のみたいになるみたいな
おだしょー ね
しばやん っていくかもしれない ですね
おだしょー 既存のメンバーに聞かな くても 進むっていうのは楽ですよ
ね
しばやん また 本当に分からない ことがあれば チームメンバーに
聞けるっていう環境もやっぱり あったと思うし その総合をうまく
活用して すごくオンボーディング で機能に乗れたところなのかな
って話聞いてて思いました じゃあ ここまでAndroidのメンバー
にいろいろ話聞いてきましたけど やっぱり アプリとしてはほぼ似た
ような機能を提供してたので 課題 も似てはいたんだけど やっぱり
新しいタイミング出てきた新しい 技術を導入したりだとかっていうこと
を積極的にやってきたりだとか あとは新しいメンバーですよね
予算化にもうまく起動に乗せながら やってきたみたいな感じで 結構
プロジェクト自体は何だろう その 要件だけじゃなくて 周りの環境
的にも難易度が高かったのかな と思って 本当に無事リリースして
本当に皆さんお疲れさまでした じゃあ 今回のTechTalkはこんなところ
にしましょうか Androidエンジニア のハルとシャミとウィングに来て
いただきました 皆さん ありがとうございました
ありがとうございました