00:03
TimeTreeラジオは、カレンダーシェアアプリTimeTreeで運営する私たちメンバーが、
仕事に関係することも、そうでないことも、大体15分ぐらいで話し切るインターネットラジオ番組です。
今日は、僕も含めて3名います。
まずは、好きなコーヒーチェーンは、米田のスティーブと、
好きなコーヒーチェーンは、米田のジャスと、
好きなコーヒーチェーンは、米田のりーです。
高吉か。
はい、揃いました。
揃っちゃいましたね。
皆さん、米田が好きな、今日はこの3人でお送りします。
でも、完全にこの米田っていうのは、タイムズ類に、たぶん引っ張られてるんじゃないかなって。
そう、オフィスの近くにできたら嬉しいですね。
米田の何が好きですか?
最近引っ越したんですけど、引っ越した時に米田があって、異次元のサイズ感。
嬉しくなりますね。
分かる。
感じが。
おいしいですしね。
おいしいですね。
僕はおつまみ的に出てくるしょっぱい豆が好きです。
それも分かります。
確実にビールが飲みたくなります。
ここがスタバとかじゃないあたりがタイムズ類っぽいんだよな、きっと。
オフィスの近くのスタバもよく行きますけどね。
スタバも好きなんですけどね。
オフィスの近くにできたので、また今度ちょっと米田ランチでもしましょう。
米田コーヒーブレイクでも。
いいですね。
じゃあですね、今日のテーマなんですが、
ルイとジャスティンをお呼びして、タイムツリーの特にエンジニアのお仕事の進め方についてお話ししてみたいなと思っています。
外向きには結構自由な開発スタイルとか、そもそもみんなこう自立して働いていて、かなり自由だよということは言ってるんですけど、採用面接で聞かれるんですよね。
そうですね。やっぱみんな興味がある場所というか。
特にエンジニアの仕事の進め方っていうのは本当に会社によって多分かなり様々だと思うので、ここでちょっといろいろ紹介していけたらなと思ってます。
そうですね。どこから話していきましょうかっていうところがあるんですけど、多くの会社でサービスを開発するときって、
ディレクターの方がいて、エンジニアがいて、デザイナーがいて、それぞれで役割を分担して、
物事を決めていって仕事をするっていうのが多くのスタイルですけど、ちょっとタイムツリーはそことは違うんですよね。
順番に企画の始まりから話していければいいなと思うんですけど、
GUIは今、もともとエンジニアとしてバックグラウンドを持ちつつも、今はわりと企画に尽力してやってますよね。
03:02
はい、そうですね。
どういう進め方で今やってたりするんですか。
大きな流れとしてロードマップがあります。
これは中長期のタイムツリーどうしていきたいとか、会社どうしていきたいという目標があって、そこから分解していくって感じですね。
それは経営会議とか、あるいはそれの文化会等で整備して作っていくって感じですね。
そこの経営会議って別に経営陣だけいるってわけじゃなくて、わりかしオープンに行われているものなんですけど、
そこから中長期のホワイを分解していって、今はこういうことをやっていこうっていう風にブレイクダウンして企画が生まれていくっていう風なスタイルが多いんですね。
僕も経営会議に参加してるんですよね。
僕も僕も。
本当にあれですね、聞きたい方がいたら誰でも参加でできる。
そうですね。参加してほしいって人は指定されているんですけれど、かつトピックによってはこの人に参加してほしいっていうのが追加されたりもしますけど、
基本的には興味ある人たちが参加しているっていう風な感じですね。
録画もあって後からでも見れますしね。
例えばみんなの使い方のリニューアルっていうのがブレイクダウンして生まれたものとしてありますけれど、
それはですね、いろいろな利用用途に、タイムツリーをいろいろな利用用途に広げていこうっていう風なホワイから生まれた企画の一つですね。
どういう形でその企画を詰めていったりしたんですかね。
そうですね。みんなの使い方をやりましょう。
ちょっとそれ具体的な企画のアイディアとして今言っちゃったんですけれど、
それももともとはいろいろな利用用途にその広げていこうっていう風なホワイが存在していて、
それをまずはみんなで理解を深めるっていうことをやっていき、
そのホワイをもとに企画を行う人ですね。この場合は自分なんですけれど、
それがどういった方法でそれが実現できるのかっていう風な叩きみたいなものを作るっていう感じです。
で、その叩きをもとに開発する人たち、デザイナーとかエンジニアも含めたみんなでわーっと集まって、
やり方の議論っていうのをしていくっていう感じですね。
企画が生まれる毎段階の議論の場っていうのは、どんなメンバーが議論に加わっていたのか。
そうですね、いろんなケースがありますね。
興味がある人たちがわーっと集まって、こういうことやったらどうだろうっていう風なアイディアに
自分も興味があるっていうふうに参加してくるパターンとか、
あとはそもそもこういう課題があって、それをどういうふうに解決していこうってところに人が集まってきて、
アイディアが生まれてくるみたいなパターンとか、いろいろなケースがありますね。
06:03
そもそもタイムツリーの組織ってあんまり部署みたいな分かれ方をしてないですよね。
本当に。
そうですね。
大きいトピックみたいな、正確には大きな検証したい仮説みたいなものがいくつかあって、
それごとにプロジェクトみたいな形でわーっと人が集まってるけど、
そこは特定の部署で、そこの部署に所属してる人がいてっていう形ではなくて、
その課題解決したいよって人が集まるケースもあれば、
スペシャリストというか、専門技術を持った人たちが問題解決して、
集まってるケースとか、そういう形でやってたりしますよね。
そうですね。
自分のやることを決めないというか、みんないろいろなところを触りに行く。
興味によってみんな触りに行くという傾向がありますね。
これ完全に創業時からこのやり方でした。
そのスタイルに行って、他の会社のやり方とは違いますけど、
どういったことを考えてこのスタイルに行ったんですかね。
まずは代表のスタイルみたいなのがありますね。
代表のフレッドのスタイルというのがあって、
もともとこういうやり方でやっていたんですよね。
それは全職のチームとかそういう段階からそういうふうなやり方でして、
自分はその時1エンジニアとして参加していたんですけれど、
これまでないぐらい生き生きできたやり方でして、
これすごい良いなというふうに思っていました。
決まったものだけを作るのではなくて、
サービスを作るというところにすごくとても興味があったので、
一緒に仕様を考えたりだとか、面白みを感じたという感じですね。
エンジニアのバックグラウンドを僕もRuiも持っていますけど、
持っているからこそ感じるこの決まったものを作るじゃなくて、
決まるところから自分が意見を言いながら作っていくというこの良さ。
納得して物事が進められるというか、
作る人もですね、各自が納得できるというのって、
すごいパフォーマンスに影響すると思っていて、
決まったものを綺麗に作るというのもそれはそれであると思うんですけど、
最大パフォーマンスでそれが出ないと思うんですよね。
プラスアルファが生まれないというか、
そこに自分の思いみたいなのが載せづらい、あると思っていて、
納得を持って仕事をできるというのが、
これの利点の一つかなというふうに思います。
エンジニア一人一人が細かく仕様を作るというところまで
関与しなくてもいいと思っていて、
もちろんそういうのが得意なエンジニアもいれば、
得意じゃないエンジニアもいるので、
一連の流れに一緒に加わって、
そのストーリーも理解することによって、
09:01
物作りって納得度がすごい高い状態で行われると思っていて、
その結果すごく良いものに仕上がるということが起きているんじゃないかな
というふうに思います。
もう一個あって、ここに参加することによって
自分ごと感が生まれるんですよね。
その自分ごと感って納得にも通ずるんですけれど、
役割を分けないというか、
ここからここまではあなたの仕事ですよねっていうのが分からない、
そういうふうなものだなと思っていて、
プロダクトに対する無関心とか、
仕事に対する無関心っていうのは存在しないんですよね。
それもセクショナリズムが生まれない、
チームの中においてもですね、外においてもなんですけど、
セクショナリズムが生まれないっていうところになっていて、
これも何かおかしいなっていうふうなことをすごく言いやすいというか、
そういう状態を作るっていう、
そういう意味でも自分ごと感を持つっていうところで、
このやり方がうまく採用してるんじゃないかなと思っています。
昔はチームも案件ごとに全てシャッフルしてたんですよね。
なるほど。
新しいものを作るたびにシャッフルというか、
やりたい人って言って手を挙げてて、
今こそプロジェクトが長期的にあったりとか、
例えば広告をやる人みたいな感じで、
ある程度決まっていたりするんですけど、
本当に初期の頃はこの案件やりたい人みたいな感じで、
バーッと挟まってくるというふうな感じでやっていて。
その時点でも既に自分ごとですよね。
そうですね。
本当に自分興味がない部分っていうのを作りたくなくて、
みんなプロダクターに対して最大の興味を持ってやれるっていう、
それをみんなで維持するっていうのがやりたくてって感じですね。
あとはここかな。
結構エンジニアの皆さんが気になる話題としては、
仕様をどうやって詰めていくのかっていう話。
よく面接でも聞かれるって最初ジャスティンが言ってたんですけど。
叩きをもとにどういうことをやっていこうっていうのを詰めながら話をしながら、
例えばその場でライブでモックを作ったりして、
ミーティング収入とかですね。
それで仕様として詰まっていくみたいなケースが多くてですね。
いわゆる仕様書みたいなのは結構ゆるかったりするんですよね。
下手したら存在しなかったりとかもして。
さすがに最近は人数も増えたので、
共有っていう意味では仕様書をなるべく残すようにはしてるんですけれど、
議論していく中で作られていくので、
なくてもみんなわかってるみたいな状態が生まれてくる感じですね。
プロトタイプ版みたいなものを社内で使って、
変わったりしてたりするじゃないですか。
そこでまた変わってみて、やっぱ違うねみたいなのもあったりしますよね。
しょっちゅうありますよね。
12:00
作ってみて、触ってから考えようかっていう風に、
そもそも仕様を決める段階でもあったりしますね。
結構そのやっぱ触ってて、
作ってるエンジニアから見落としてた点というか、
ここがおかしそうだから変えた方がいいんじゃないですかね、
みたいなのが上がってきて、
それで実際に変更したりだったりとかっていうのもよくありますね。
仕様が決まっててそれどおりに作るケースとかだと、
この仕様おかしくないですかってなった時に、
全部の整合性が合わないから、
どうしてもこれでいくしかないみたいな、
謎の仕様バグじゃないですけど、
そういうものを残したまま作らないといけないとかありますよね。
そうですね。
言っちゃえば仕様を作っているメンバーのうちの一人でもあるので、
エンジニアですね。
そういう意味ではここを変えた方がいいっていうのは、
すごく自然に話すことができるって感じですかね。
エンジニアの視点ががっつり仕様に入るというか、
例えばこれとこれだったらば、
こっちのほうが圧倒的には裏側はきれいになるんだけど、
言われたことを含むだけだと、
それっていうのはなかなか取り入れられなかったりとか、
そういうところがあったりしますね。
ありますよね。
この仕様を変えたら全然きれいに作れるようになるみたいな。
そうですね。
そういうのが圧倒的に言いやすいっていうか、
当然ながらその意見として反映されるっていう風な場だと思いますね。
それも単純に機能を減らしたいとかじゃなくて、
ユーザーさんにちゃんとパッチを届けるってことをしつつも、
早く届けるっていうのもやっぱり大事だったりしますよね。
そうですね。
早く届けるためにできることとかを提案できたりとかですね。
じゃあ今日はですね、
ジャスティンとルイを呼んで、
すごい大前提としてタイムツリーで大事にしている、
特にエンジニアのワークスタイル、働き方について話しました。
ありがとうございました。
ありがとうございました。
ありがとうございました。
