00:08
はい、TimeTree Tech Talkです。今回は、 先々月1月末にリリースしたTimeTree
のリニューアルがあったんですけども、 それの開発苦労話を聞こうかと思い
まして、iOSの開発メンバーのシオン とガッツとトレバーに来てもらって
ます。では順番に、シオンから自己紹介 お願いしてもいいでしょうか。
シオン はい。iOSエンジニアのシオン です。よろしくお願いします。
おだしょー お願いします。じゃあ 続いてガッツ。
ガッツ はい。同じく、iOSエンジニア のガッツです。よろしくお願いします。
お願いします。最後トレバーお願いします。
おだしょー はい 同じくトレバー です よろしくお願いします
おだしょー じゃあ どういう機能 をリリースしたのかみたいなところ
から入っていければなと思います けれども リニューアルは1月の
末ですね 社内では構造改革プロジェクト というふうに呼ばれていて 開発
開発はいつからでしたっけ
おだしょー 去年のそうですね 5月 から
おだしょー 去年の5月からですね だ から7ヶ月ぐらいですかね 開発
してたという感じでして リリース したタイミングでプレスリリース
も打ってるんですけれども その 辺のリンクは概要欄にあっておき
ますと思います どうしてリニューアル をしたのかみたいなところもプレスリリース
に乗ってはいるんですけれども Time Treeではコンセプトとして共有
とコミュニケーションっていう ものをコンセプトにした共有カレンダー
をこれまでサービスとして提供 してきたんですけれども より個人
の時間っていうのにフォーカス した体験っていうのも作っていく
ためにリニューアルをしたという ような感じですね 大丈夫ですか
ね 合ってますかね 開発してた 皆さんの意見を
おだしょー 合ってます 大丈夫 自信持ってCTO
おだしょー 大丈夫そう よかった よかった リニューアルしたポイント
としましては これまではそれぞれ の共有カレンダーを別々に見る
というのがメインの使い方だったん ですけれども いろんなカレンダー
を横断して見渡せるようになる ホームカレンダーというものを
作って 複数の一人のユーザー さんでも いろんな共有カレンダー
に参加されてるっていう場合だったり 共有しつつ 個人用のカレンダー
をやってたり っていうようなことが あったりすると思うんですけど
そういう複数のカレンダーを見 渡せるようになってるっていう
03:01
ところが大きなポイントなのかな と思っていたり あとは 見つける
っていう機能があるんですけども タブの真ん中に見つけるっていう
タブがあるんですけど そこでタイム ツリーの中でトレンドになってる
予定だったりとか おすすめのイベント だったりっていうのが見れるよう
になっていて これからやってくる 未来の予定を探すようなきっかけ
だったり 自分の興味 関心がある 予定っていうところを見つけられる
ようなものもタイムツリー上で 提供できるようになってるという
ようなところになってるという ところですね こういう目的で
リニューアルしたというふうになって いるんですが この開発はとても
大変だったというふうに聞いて おりますので 現場の人から現場
の声を聞いて 技術的に難しかった ところだとか 大変だったところ
聞いていこうかなというのが 今回の趣旨でございます
おだしょー はい ということで 雑に聞いちゃいますけど どういう
ところが大変でしたか
吉田 はい まず そもそもUIの構造 が全然別なものになるっていう
ところで 画面の作り替えが発生 するところが大変なんですけども
そもそものUIの前提が変わる部分 がありまして もともとのUIだと
必ずカレンダーが画面上に一つ 存在していて ユーザーがカレンダー
を切り替えると その別のカレンダー にUI上も変わるっていうふうになって
いたんですけども 今回の構造改革 で ホームレイヤーと個別カレンダー
のレイヤーって呼んでるんです けど ホームカレンダーの上に家族
カレンダーとか仕事カレンダー みたいな 1個1個のカレンダーが独立
して表示されるみたいな状況が 生まれるんですね なので 画面
に常に選択されたカレンダーは 一つだけっていう前提が崩れる
ので そこの設計を変えなきゃいけない だけど 同時に 新旧のUIを並行して
存在する ユーザーが切り替えて 新しいUIにしたり また戻すって
いうこともできるっていう状態 で最初にリリースするので その
辺 共存した状態で出さなきゃいけない っていうところから いかにもともと
の設計を残しつつ 新しい画面を 実現するかみたいなところで かなり
なんだろうな 悪い言葉で言うと その抜しのぎのやり方で一旦は
作ってる部分が多かったっていう 感じですね
おだしょー なるほどですね 最初 リリースはベータで出すみたいな
感じだったんで ユーザーさんが 設定画面で切り替えて 新しいUIを
06:01
試すみたいなことをするとできる っていう感じなので プログラム
的には両方 ちゃんと動くように しとかなきゃいけないみたいな
ことが必要で 何で例えればいいん だろう 建築とかで例えるのすごい
難しいんだけど 家の上に新しい 家を建てるみたいなことをやらない
といけないみたいな 謎な感じ になるんですよね そうですね
さっきしおんが言ってくれたように もともとは1個のカレンダーしか
表示しないっていう設計でプログラム を全部組んでたので 重ねて表示
できますっていうふうにすると その辺のカレンダーを描画する
ためのデータの管理 全部作り直し だったら一番楽だったんだけど
それも動くようにしながら別で 作るみたいなところが よりゼロ
から作るよりも難易度が高いっていう 感じですよね
おだしょー そうですね
わかりにぎや この辺はエンジニア あるあるな気がして 聞いていただける
方は首が燃えるほどうなずいて いただけるんじゃないかと僕は
思ってますけれども そうなんですよ ね 両方動かすっていうのはめちゃ
めちゃ大変なんです 実際 エンジニア だと感覚で両方作るの難しそう
って思うんですけど 具体的に作って いて 難しさが出るみたいなところ
は もうちょっと詳しく聞くと どういうのありますかね じゃ ガッツ
に聞いてみるか 今度
おだしょー そうですね 自分は ホームカレンダーだと今日主に担当
してたんですが そこについてい っていくと 本当 さっきスコット
が言って ゼロから作るんだったら 楽な部分もあったと思うんですけ
ど 新しいカレンダー ホームカレンダー あそこを作るのもゼロから作る
と カレンダー10年作ってて すごい 仕様が膨大なので 1から作るのは
あんまり現実的ではなかったところ があるんですね なので 既存のカレンダー
のコードっていうのを利用しながら 作っていく必要があったっていう
のがありました 既存の実装の中でも カレンダーを一つ表示するっていう
前提にすごく依存しているところ が多くて そこを一つ一つ剥がしながら
でも既存の機能は壊さないように ホームカレンダーでやりたいこと
に適合させながら作っていくっていう ところが大変でしたね 絡まった
紐をちょっとほどきながら 別の ところに別の結び目を作っていく
みたいなことをしてました
おだしょー 網を取って その場で また別で作らないといけないみたいな
感じなのかな
おだしょー そうですね タイムツリー も最初リリースしてから10年ぐらい
経ってるんで 何だろう 開発者も もう忘れてるような仕様とか いっぱい
あるんですよね でも それはやっぱり そのままユーザーさんを使ってる
09:01
わけで そのまま動かさなきゃいけない けど それはそれでまたゼロから
作るっていうのも また逆に大変 なので なるべく流用して動かしたい
が さっきの話で 別のところに作ら なきゃいけないみたいなところ
ですよね
おだしょー なるほどですね そうなると あれですよね コード
はどんどん複雑になっていって 書いているここに 今 今日 喋ってる
三人でも もうわけ分かんないみたいな ことにはなったんじゃないかな
と思うんですけど 実際 開発してる 中で 何やねんみたいな もうわけ
分かんないみたいなってことって ありますか 取ればどうかな
おだしょー そうですね 自分は 後から参戦して ガッツとしおん
が最初から設計を考える段階から 参加して ある程度設計が決まって
共存できる状態になって 既存の UIと共存ができる状態になって
から開発に参戦したので すごい そこが大変だったみたいな経験
はしてないんですけれど 二つ共存 している状態で 新しいほうにコード
追加していくにあたって 別のチーム との連携がすごい大変だったっていう
記憶があります 新しいUIではこういう ふうに動くようにするけれど 大丈夫
そうみたいな確認を すごい他の 人にした記憶があります
おだしょー なるほど これも結構 さっき話したように 7カ月ぐらい
開発してたので その間にも他の チームでは別の機能を実装していく
わけで
おだしょー そうですね 逆に新しい チームじゃない 既存のUIのほう
にどんどん新しい機能を作って いくってなったときに 逆に新しい
ほうにもそれを同時に載せない といけなかったりしたので その
面はすごい 新しいほうと既存の ほうとで 両方考えるのがすごい
大変でした
おだしょー なるほどですね その 辺の仕様とか コードの調整っていう
んですかね
おだしょー そうですね
おだしょー バッティングとかあった りとか 新しいほうでは ある何て
いうんですかね 新しい機能を実装 するときに想定してた画面がリニューアル
すると消えちゃうみたいなこと とかがあったりするんですかね
おだしょー さっきトレバーは 途中から参加したっていう話が
あったと思うんですけど 逆に 途中参加するメンバーとして なんて
いうんですかね なんでこんなこと になってるのとか なんでやるの
みたいな そういうモヤモヤみたい なのっていうのは感じなかった
ですか チームとしてはやるって なってる中で 後から参加すると
その辺ってどうなんだろうなって 気になるんですけど
仕様とか そういう決まった設計 みたいな 設計じゃない 仕様かな
仕様をこういうふうに作ります っていうのを見ていて なんでとか
12:05
すごいそういう気持ちは湧いて きたんですけども もうこれは議論
を尽くした結果で出てきている ものだっていうのを 決めてくれた
人たちを信じて ある程度 その辺は 時間を優先で考えないように淡々
とタスクをこなすみたいな感じ でやってました
おだしょー なるほどですね 難しい ですよね 自分もこうしたほうが
いいんじゃないかと思いつつも みんながすごい考えた上で決まっている
ことだから 変に虫返したりする ことで
そうですね 進捗がどちらか というと こっちのほうが同じ仕様
で何着陸できるんじゃないのか とか こっちのほうが同じ仕様
でもっと早くできそうとか そういう ふうなことに考える時間を使った
曲があります
おだしょー なるほどね 作り方で もっと楽できるんじゃないか 早く
できるんじゃないかとか 実装方法 のほうで提案することに集中した
みたいな
そうですね
おだしょー なるほどですね 確かに 開発始まった去年のときは スケジュール
感がわりともやっとしてたと思 うんですけど リリースする前後
になって 急にパパパッとここまで にリリースみたいなのが決まって
たと思うんですけど それってどういう 経緯で決まっていったんですかね
これはしおに聞いたほうがいい かな
しお はい 最初にまず こういう 設計でやりますってなって 一応
見積もりしたんですけど これは PDMに一旦見積もるけど 全然信用できる
数字じゃないよっていうのをすごい 念を押しながらやってたと思います
というのも マジでやってみる まで分かんないっていうところ
が多すぎて やりながら考えてっていう 部分が大きかったので 普通の案件
よりもすごく見積もりが難しかった なっていうのがありますね 一旦
ラインを決めてやるんですけど やっていくうちに どんどんそれが
後ろ直しになっていくんですけど とはいえ 終盤になるにつれ ある
程度見えてきて さすがにここまでは やろう 逆にここまででできるように
しようみたいな感じでやってい ったのと もう一つが 見つける
タブのほうは われわれとは別の 公開カレンダーをやってるチーム
が開発をしていたので そちらの スケジュールは別であって そちら
がここまでにリリースしますって なったら 逆算して ここまでには
われわれやらなきゃいけないみたい になって それでお尻が決まって
いくみたいな感じになりました ね
おだしょー なるほどですね 先ほど 話したとおり このリニューアル
15:00
の目玉の一つでこれ 見つける機能 みたいなところが 別のチームで
作ってたんですよね UIのメイン の構造部分を変えるところとは
別で動いていて 並行して開発 してたので そっちのスケジュール
も影響したというような感じで 決まっていったっていう感じなん
ですね そこら辺の最後の調整という か 調理合わせみたいなところが
めちゃくちゃ
おだしょー そうですね リリース のパターンもいろいろ考えていて
できれば見つけると一緒のタイミング で出したかったんだけど 見つける
が結構 後ろ倒しになるよっていう 話になったので なので 構造改革
見つけるタブなしバージョンを まず ベータ版という形で出しましょう
っていうふうになったんですよね それで進めてたんですけど だんだん
この構造改革自体が後ろ倒しになって きて このままだと見つけるの
リリースの前にベータリリース 期間がなくなっちゃうみたいな
感じになって そこを何とか間に合わせる みたいな感じで 優先度を下げた
機能は後ろ倒しにしたりみたいな 感じで調整してたっていう感じ
ですね
おだしょー そうですね リリース も半年以上開発して UXの変更だから
なかなかちょっとずつっていうより かは 結構 ドラスティックに変わる
部分だったから 半年開発してドカン とリリースするっていうフロー
しかなかったと思うんですけど その辺りって 工夫とかガッツ
ありましたか
おだしょー そうですね スコット が言ったとおり ビッグ版リリース
になるというところはありました とはいえ 全部やっぱり出すっていう
のは非常にリスクが高いし ユーザー さんへの負担も大きいところ なんで
出せる機能 独立して出せる機能 っていうのは 先日出していこう
っていう工夫はしていました 自分が やっていたホームカレンダー
っていうところで もともと全ての カレンダーっていう画面がほど改革
前ではあって そこで複数のカレンダー っていうのを見ることができて
たんですね ホームカレンダーっていう のは カレンダーの上のほうにカレンダー
名があって 載っているチップっていう のを出して それを押すことで 表示
するカレンダーを切り替えることが できるんですけど それを全ての
カレンダーにくっつけて 先に出し ちゃおうっていう形で 構造改革
の前に ホームカレンダーの主要 になる機能っていうのは 先行し
リリースっていうことをしていました
おだしょー 本当にがらっと体験 は変わるけど そこを本当に部分
部分を見て出せるところからは 先に出していくことで リスクを
もちろん 体験上のリスクもある と思うし プログラム上のリスク
っていうんですかね のもあります よね どこが不具合になっている
のか分からないっていうような 話とかも でかっと出しちゃうと
18:02
大きいので分かんなかったりする ので そういったリスクを回避する
ために 本当に厳選して ちょい出し できると ほら やっていったっていう
感じなんですね なるほどです ありがとうございます っていう感じ
で 何て言ったらいいんだ すごい 大変そうだなっていうのがうまく
伝わってればいいんですけど ちょっと 話してる途中に思ったのは
あれですかね 家とかで言うと 家 ってこだてだと基礎の部分ある
じゃないですか あそこを置き換える 気持ちですよね
おだしょー まさに
おだしょー 建物は大体そのまんま
おだしょー そうですね
おだしょー それ 他の人に説明 するときにその例え使いました
おだしょー 弟が建築関係の仕事 やってるんですけど 基礎のところ
作るとき 地面 掘り返すらしいん ですよね 掘り返す前に 以前 そこ
に何があったのかっていう 過去 からの図面を引っ張ってきて それ
で計画を立てるらしいんですよ これだけ缶が埋まってるかなとか
ただ 掘ってみた結果 別の缶とか が出てきたら 計画がすごいとん
ざするらしいんですよね そういう のも感じました コードを掘って
みるまで 何が出てくるか分からん っていうのをすごい感じてました
おだしょー そもそもタイムツリー のこれまでのアプリの大前提となる
基礎の部分を折り返して入れ替える っていう大事業だったので すごい
大変だったのかなと思います まず 本当リリースしてお疲れさまでした
っていうのと リリースしたのが スタートっていう ソフトウエア
開発のつらいところではあるんですけど ここからもどんどんユーザー
さんからのフィードバックもある と思いますし 企画メンバーでこういう
ことやっていきたいとか もちろん エンジニアとしてもこういうこと
直したいとか 実装面ではめちゃ くちゃありそうですよね 古い実装
がまだ残ってる状態でやってた ので 変な依存を解消していくこと
で コードをアーキテクチャ的には シンプルになって より開発しやす
くなるとか そういうふうにして いくみたいなところは ユーザー
さんには見えないところですけど 大事なところだったりもするので
そういうところを引き続きやって いってもらえるのかなと思って
います 最後 じゃあ みんなに一人 ずつ 一言ずつなんかもらって この
プロジェクトに関するものを一 言ずついただいて 終わりでしょう
かなと思います じゃあ しおんから お願いしていいですか
おだしょー はい そうですね Time Tree 歴史上 こういうリニューアル
っていうのは何度かやってるんです けど その中でも今回は一番大変
だったかなっていう気はしてます あとは 今 絶賛リファクタリング
中でいらなくなったコードを消す みたいなことを進めてるんですけ
と なので まだもうちょっとやる ことはあるなと思いつつ まずは
そうですね 無事リリースできて よかったなと思ってます 以上です
21:05
おだしょー 重みがある ありがとうございます じゃあ 続いてガッツお願いします
おだしょー そうですね 構造改革 もリリースできて まずはその体験
面で一人一人の時間のためのサービス 上の基盤っていうのが整えられた
かなと思っています あと コード 面でも 確かに作ってる途中は
大変だったんですけど 割とその 基礎のところは 絡まって紐を解く
ことで 結構 すっきりとなった かなと思っていて なので 今 前より
作りやすい状態にはなったのかな と思っています なので サービス
面でもコード面でも 今 新しい 価値っていうのを提供しやすい状態
になっていると思って から より とプロダクトをスピーディーに
進化させていけるように頑張って いきたいなと思っています 以上
です
おだしょー はい 期待してます ユーザー の一人として期待してます
任しとけ じゃあ 最後取れば いや もう しよんとガッツが全部言って
くれちゃったから あんまり言う ことはないんですけど やっぱでっ
かい変更だったので そうですね ユーザー さんからのいいフィードバック
も あと もうちょっとこうしてほしい っていうフィードバックもいっぱい
届いていて それは都度テーブル に挙げて 今後 この構造改革とどう
折り合いをつけていくかみたいな 話はずっとしていて 今 ちょっと
いわゆる古いコードとか そういう ものを削除するのでとか 解決したり
するので忙しいんですけど それが 終わり次第 このまた新しくなった
構造の上に ガッツが言ったように スピーディーにいろいろ改善とか
開発とかしていけると思うんで 今後も新しいコンセプトというか
そういうのを基にサービスをどんどん 進化させていきたいなと思って
おります
おだしょー はい みんな頼もしい ですね 期待しております そうですね
今回のTechTalkはこんなところで 終わりにしたいかなと思います
今日は iOSエンジニアのしよんと ガッツとトレバーの三人に来て
いただきました ありがとうございました
ありがとうございました
しょうた ありがとうございます
おだしょー ありがとうございました
