ログインアカウント登録

ブログ

TimeTreeエンジニアのワークスタイル——TimeTreeラヂオ vol.012

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

今回のテーマは「TimeTreeエンジニアのワークスタイル」。この3人で話しました!

  • Chief Product Officer 松田(Louis @lciel

  • バックエンド エンジニア 大政(Justin @_eurk

  • ブランド コミュニケーション 渡部(Steve @ShinyaWatanabe_

ラヂオを聴く👂🏻 https://open.spotify.com/episode/4HmkBvMM6TMTl8aAFzdhRi

ラヂオを読む📝 配信の内容を文章でお読みになりたい方はこのままお進みください


(01:41〜)

企画の進め方

Steve 今日のテーマなんですが、LouisとJustinをお呼びしてTimeTreeの特にエンジニアのお仕事の進め方についてお話ししてみたいなと思っています。外向けには結構、自由な開発スタイルとか自律して働いていて自由だよってことは言っているんですが。採用面接でよく聞かれるんですよね?

Louis そうですね。やはりみなさん興味がある場所というか。

Steve 特にエンジニアの仕事の進め方は会社によってかなり様々だと思うので。ここで色々と紹介していけたらと思っています。

Justin 多くの会社でサービスを開発するときはディレクターがいて、エンジニアがいて、デザイナーがいて、それぞれが役割を分散して物事を進めて仕事をするっていうのが多くのスタイルですけど。TimeTreeはそことは違うんですよね。順番に企画のはじまりから話していければと思うんですが。Louisはもともとエンジニアですがいまは企画に注力していますよね。どういう進め方でやっているんですか?

Louis 大きな流れとして(サービス・会社の)ロードマップがあります。これは中長期のTimeTreeをどうしていきたい?とか、会社どうしていきたい?とか目標があって。そこから分解していくって感じですね。経営会議とかその分科会などで整理して(企画を)つくっていくって感じですね。経営会議は経営陣だけじゃなくてオープンに行われているものなんですけど、中長期の「Why」を分解していって「いまはこういうことをやっていこう」ってブレイクダウンして企画が生まれていくってスタイルが多いですね。

Justin 僕も経営会議に参加しているんですよね。

Steve 僕も! 聴きたい方がいたら誰でも参加ができる。

Louis そうですね。参加して欲しいってひとは指定されているんですけど。トピックによっては「このひとに参加して欲しい」って追加されたりしますけど。基本的には興味ある人たちが参加しているっていう感じですね。

Justin 録画もあってあとからでも観れますしね。

Louis たとえば「みんなの使い方」のリニューアルが(経営会議の話題から)ブレイクダウンして生まれた企画であります。TimeTreeを色々な利用用途にひろげていこうっていう「Why」から生まれた企画のひとつですね。

Justin どういう形で企画を詰めていったんですか?

Louis もともとは「(カレンダーを)色々な利用用途に裾野を広げていこう」って「Why」が存在していて。それをまずはみんなで理解を深めるってことをやっていき、その「Why」を元に企画を行うひと——この場合は自分なんですけど、どういった方法で実現できるのかっていうタタキを作るって感じです。そのタタキを元に開発するひとたち——デザイナーとかエンジニアも含めたみんなでワーッと集まってやり方の議論をしていくって形ですね。

Steve 企画が生まれる前段階の議論の場って、どんなメンバーがその議論に加わっていたんですか?

Louis いろんなケースがありますね。興味があるひとたちがワーッと集まって「こういうことやったらどうだろう」ってアイデアに(さらに)興味があるって参加してくるパターンとか。そもそも課題があってそれをどう解決していこう?って場にひとが集まってアイデアが生まれてくるパターンとか。色々なケースがありますね。

創業当時から変わらないワークスタイルはだれの影響……?

Justin そもそもTimeTreeの組織って部署みたいな分かれ方をしていないですよね。大きいトピック——検証したい仮説がいくつかあってそれごとにプロジェクトみたいな形でワーッとひとが集まっているけど。そこは特定の部署で所属しているひとがいてって形ではなくて「その課題を解決したい」ってひとがあつまるケースもあれば専門技術を持ったひとたちが「その問題解決していこう」って集まるケースとか。

Louis 自分のやることを決めないというか。みんな色々なところを触りにいく。興味によってみんな触りにいくって傾向がありますね。これ完全に創業時からこのやり方でした。

Justin そのスタイルって他の会社と違いますけど、どういうことを考えてこのスタイルになったんですか?

Louis まずは代表のFredのスタイルっていうのがありますね。もともとこういうやり方でやっていたんですよね。前職の段階からこのやり方でして。自分はそのときエンジニアとして参加していたんですけど、これまでにないくらいイキイキできた働き方でして。「これすごい良いな」と思っていました。決まったものだけを作るのではなくて、サービスをつくるってところにとても興味があったので。一緒に仕様を考えたりだとか。面白みを感じましたね。

Justin エンジニアのバックグラウンドを僕もLouisも持っていますが、持っているからこそ感じるこの「決まったものをつくる」じゃなくて「決まるところ」から自分が意見を言いながらつくっていくこの良さ……!

Louis 納得して物事が進められるというか。つくるひともですね。各自が納得できるのってすごいパフォーマンスに影響すると思っていて。決まったものを綺麗につくるっていうのもそれはそれであると思うんですけど。最大パフォーマンスって出ないと思うんですよね。プラスアルファが生まれないというか。そこに自分の思いを乗せづらい。納得を持って仕事をできるっていうのがこれ(TimeTreeのワークスタイル)の利点のひとつかなって思います。

エンジニア一人ひとりが細かく仕様をつくるってところまで全員が関与しなくてもいいと思っていて。もちろんそういうのが得意なエンジニアもいれば得意じゃないエンジニアもいるんで。一連の流れに一緒に加わってストーリーも理解することによってものづくりって納得度が高い状態で行われると思っていて。その結果すごく良いものに仕上がるってことが起きているんじゃないかなって思います。

もういっこあって、そこに参加することによって自分ごと感が生まれるんですよね。自分ごと感って納得にも通ずるんですけど、役割を分けないというか。「ここからここまでがあなたの仕事ですよね」っていうのが分かれない。プロダクトに対する無関心とか仕様に対する無関心が存在しないんですよね。それも、チームの内においても外においてもセクショナリズムが生まれないってなっていて。「何かおかしいな?」ってことを言いやすいというか。そういう状態をつくる。その意味でも「自分ごと感を持つ」ってところで、この(TimeTreeのワークスタイル)やり方がうまく作用しているんじゃないかなと思っています。昔はチームも案件ごとにシャッフルしてたんですよねー。

Steve おー、なるほど!

Louis 新しいものをつくるたびに「やりたいひと?」って手を挙げていて。いまでこそプロジェクトが長期的にあったりとか。「広告事業をやるひと」みたいな感じである程度決まっているんですけど、初期の頃は「この案件やりたいひと?」みたいな感じでバーッて集まってくる感じでやっていて。

Steve その時点ですでに「自分ごと」ですよね。

Louis そうですね、それですね! 興味がない部分をつくりたくなくて(笑)。みんなプロダクトに対して最大の興味をもってやれるっていう、それをみんなで維持するっていうのがやりたくて!

エンジニアの仕様の詰め方

Steve あとはここかな……? エンジニアのみなさんが気になる話題としては、仕様をどうやって詰めていくのか。よく面接でも聞かれるってJustinが言ってたんですが。

Louis タタキを元に「こういうことやっていこう」って詰めながら話しをしながら、たとえばその場でライブでモックをつくったりして、仕様として詰まっていくケースが多くてですね。いわゆる”仕様書”みたいなのは結構ゆるかったりするんですよね(笑)。下手したら存在しなかったり。さすがに最近は人数も増えたので共有って意味で仕様書をなるべく残すようにしているんですけど。議論していく中でつくられていくので「なくてもみんな分かっている」って状態が生まれてくる感じですね。

Justin プロトタイプを社内で使って、そこで「やっぱり違うね」もあったりしますよね。

Louis しょっちゅうありますよね(笑)。つくってみて触ってから考えようかって、そもそも仕様を決める段階でもあったりしますね。触っていて、つくっていたエンジニアから見落としていた点とか「ここおかしそうだから変えた方がいいんじゃないですかね」みたいなのがあがってきて、それで変更したりもよくある。

Justin 仕様が決まってそれ通りにつくるケースだと「この仕様おかしくないですか?」ってなったときに「整合性がとれないからこれでいくしかない」みたいな謎の仕様バグを残したままつくらないといけないとかありますよね……(笑)。

Louis そうですねえ……。言っちゃえばエンジニアは仕様をつくっているメンバーの一人でもあるので「ここを変えた方がいい」っていうのはすごく自然に話すことができるって感じですかね。エンジニアの視点ががっつり仕様に入る。たとえば「これとこれだったらこっちの方が圧倒的に綺麗になるんだけど…」って、言われたことをつくるだけだとなかなか取り入れられなかったりだとか。

Justin ありますよねえー。「この仕様……ここ変えたら綺麗につくれるのにな!」みたいな(笑)

Louis そういうのが圧倒的に、当然ながら意見として反映されるって場だと思いますね。

Justin それも単純に機能を減らしたいとかじゃなくて、ユーザーに価値を届けるってことをしつつも早く届けるってことも大事だったりしますよね。

Louis そうですね! 早く届けるためにできることを提案できたりですね。

Steve 今日はJustinとLouisを呼んで、すごい大前提としてTimeTreeで大事にしている、特にエンジニアのワークスタイルについて話しました! ありがとうございました!

Louis, Justin ありがとうございましたー!

TimeTreeラヂオ 📻

TimeTreeを運営する私たちメンバーが、ふだんの仕事に関係することも、そうでないことも、だいたい15分でひとつのテーマを話しきるインターネットラジオ番組です。 今後も定期的に放送を配信してきますのでぜひ試聴ください! ご意見・ご感想・話してほしいテーマなどぜひTwitterハッシュタグ #TimeTreeラヂオ でお待ちしてます。 過去の配信はこちらから聴けます

© TimeTree, Inc. All rights reserved.