トレタ開発者ブログ

飲食店向け予約/顧客台帳サービス「トレタ」、モバイルオーダー「トレタO/X」などを運営するトレタの開発メンバーによるブログです。

トレタでチームリーダー始めて半年が経ちました

この記事はトレタ Advent Calendar 2019の13日目です。Friday the 13th q(-::-)

どうもどうも!先週ボウリングたったの1ゲームで腰を痛めて歩けなくなったサーバーサイドエンジニア 石谷です! ちょうど先週はトレタリモートウィークのトライアル期間だったので家から出ず、ちょくちょく休暇も頂きつつ乗り切りました! 安静にしていたおかげで今週は元気に出社しております (´ω`)

自己紹介的なのは以前社員インタビューして頂いたものがあるのでご参照下さい。

さて今回のお題ですが、僕はトレタで「メディア連携開発チーム」というチームのリーダーを任せて頂いています。チームリーダーを始めてちょうど半年くらい経つので、来期に向けての振り返りなど書いていければと思います。 記事の中から少しでもトレタの職場の雰囲気が伝われば幸いです。

メディア連携開発チームってなに?

「飲食店と飲食法人の繁盛のためにトレタを介してあらゆるメディア活用を実現する」というミッションを担っているのがこのチームです。店舗の繁盛最大化のためには広告メディアも非常に大事な集客元になってきます。

ひとつの例として想像してみて欲しいのが、もしあなたが複数の友人から断続的にメッセージが送られてきて、それぞれのメッセージを確認してカレンダーに24時間365日みっちり予定を登録することを考えたらどうでしょう?僕なら発狂しそうです (ヽ´ω`)

この例は実際に店舗が抱える課題としてチームが取り組んでいるものの一つです。ある飲食店が広告メディアとして5つの予約受付が可能なグルメサイトを使用している場合、それぞれのグルメサイトから入った1予約に対して1件ずつメールが送られてくるとしたら、それを予約台帳に転記するのってかなり大変そうですよね。 トレタは台帳アプリを中心とした予約管理システムを飲食店に提供しています。広告メディアとトレタがシステムとして連携していれば、わざわざ転記する必要がないので楽ちんですね。 そういった広告メディアの活用のためにシステムを開発・運用するのが「メディア連携開発チーム」です。

チームリーダーってなにするの?

なにをするんでしょう?そこを考えるところから始めました。

トレタの技術組織がチーム体制を敷いたのは今年に入ってからのことで、初めは複数チームを1人のマネージャーが管理する体制でした。しばらく運用して次第に課題が見え始めたので1チーム1リーダーの体制へと移行しました。僕がチームリーダーになったのもこのタイミングです。もともとチームが担当するプロダクトは決まっていて、4つのプロダクトをうちのチームで開発・運用していました。僕を含め4人のチームメンバーのうち3人は入社日が浅く、自分自身も習熟度が低いなかでチームリーダーとして何をするべきか考えました。

もともとチームに所属していたメンバーはみんなめちゃくちゃ優秀だし、自走できるし、お互いフォローし合える人たちなので「いやいやチームリーダー要らないのでは?」っていうのが頭をよぎった瞬間もありました。でもいろいろ考えたり、HIGH OUTPUT MANAGEMENTを読んだりした結果「チームのアウトプットを最大化できる状態を作る人」がチームリーダーの役割だなと考え、そのために何が必要かを逆算していくと、色々と必要な要素が見えてきました。ちなみに「チームのアウトプットを最大化できる状態を作る人」というのは今振り返ってもチームリーダーの役割としては間違っていないかなと思います。

またこのときマインドマップを使って思考を整理していました。整理の仕方としては「目指したい事柄」に対して「正の要因」と「負の要因」をリストアップしていくと大体なにが大事か見えてきます。 最近はwhimsicalでマインドマップ書いてるんですが、使いやすくてめっちゃ良い感じです!

f:id:issuy:20191211194241p:plain
マインドマップ

チームのアウトプットを最大化できる状態を作るために必要なことって?

思考を整理した結果「本人が動機をもってタスクに取り組めていること」と「判断基準が合っていること」さえクリアしていれば、それ以上の余計な管理は不要かなと考えました。

例えばあなたが資料作成のタスクを担当しているとします。あなたは1時間の集中タイムを取っていてこの時間は筆が乗る貴重な時間です。そんな中、10分に1度「どう?捗ってる?」ってリーダーに聞きに来ます。どうですか?すごく嫌ですよね?僕がもしプログラミングに集中できてる時間にそれをやられたら「あれ?どこまで考えてたっけ?」とか「うっ、、、今ノッてたのに。。。」とか「ま、また来たのですか?」ってなっちゃうと思います(ヽ´ω`)

この例ではなにが起こっていたのでしょうか?まず「筆が乗る状態」について考えてみると、本人が「自分が何を書きたいか、何を書けば良いかを分かっている状態」だと思います。つまり「動機をもって取り組んでいる状態」にあって、このような「集中できている状態」を作ることがリーダーのメンバーに対する最大の仕事だと考えました。

次になぜリーダーは「どう?捗ってる?」って聞きに来るのでしょう?9割くらいは「期待するアウトプットが出そうか、本人が何か課題を抱えていないか、タスクが納期までに終わりそうか」などのチェックだと思います。 チームリーダーはチームのミッションに責任を持っているので、メンバーのアウトプットはそのミッションを果たせるものである必要があります。そのためにクオリティラインがズレないように軌道修正し、課題を抱えていそうであれば解決を一緒に考え、納期に間に合わなそうであれば改善策や納期の調整・交渉などを検討するのもリーダーの仕事です。このときリーダーとメンバー本人が「同じ判断基準」を持っているとしたら、アプローチは違えど同じ結果がアウトプットできそうです。それならばリーダーは「どう?捗ってる?」って聞きに行く必要がなくなるので、メンバー本人は「集中できている状態」をより長く保つことができるはずです。

つまり「集中できている状態」を作ること、そしてその時間をより長く保つことが「チームのアウトプットを最大化できる状態を作るために必要なこと」になりそうだなと整理しました。

※ちなみに「どう?捗ってる?」って聞きに来るのの残りの1割は恐らくコミュニケーション取りたいだけです。。。いつも雑な話ばっかで申し訳ない( ˘ω˘)

実際にやってみてどうだった?

チームとして結果が出せたし、体感では7割はうまくいったのではと思っています。本当に余計な管理を必要とせず、自走できるチームだったと思います。むしろチームメンバーの皆さんに助けてもらう方が多かったことに感謝しかないです(´ω`)

[Good]みんな動機をもってタスクに取り組めていた

そもそもみんな優秀だしモチベーションが高かったのがあります。今期の注力プロジェクトではみんな主体的に考え行動してくれていたし、かなり複雑な仕様のものをなんとか運用に乗せることができたのはメンバーの皆さんが主体的にチーム内および隣接するチームの皆さんと連携してくれていたからでした。隣接するチームの皆さんにも感謝です。僕が貢献できたところと言えば「誰が何をやるか?」や「どうやったら課題を解決できそうか?」を理由とセットで提示できた部分でしょうか?

[Good]判断基準を合わせる動きが上手く回っていた

「必要なタイミングでガッツリ会話し、方針が固まったら手を動かすだけ」というワークフローが自然とできており、それがうまく作用して質の高いアウトプットが多かったなと思います。また、来期に向けた新しいプロジェクトを開始するタイミングでも「なぜやるのか?なにを大事にするのか?」など認識を合わせながら始動できており、実際そのプロジェクトはいま軌道に乗って開発を進めてくれています。先頭に立って進めてくれているみなさんに感謝。みんな優秀なので判断基準を揃えるのに大したハードルを感じなかったように思います。むしろそうしたやり取りの中でみんなが持つ知識や知恵が共有できてすごく学びが多かった。

[Bad]チームリーダーである自分自身が集中できる状態を構築するのに出遅れた

チームリーダーである僕自身もメンバーとしての役割も持っているため、急な状況の変化に対応しきれなかったタイミングがありました。トレタはまだまだ発展途上というのもあり、短い期間に状況が変わることもあります。組織の構成が変わったり、人の配置が変わったり、チームが持つプロダクトが変わったり。その変化に合わせてチームメンバーの役割分担などを考えるのですが、1人が持つプロダクトの数が増え過ぎると「集中できない状態」を作ってしまいます。これは先程の「10分に1度進捗を聞かれる」を「10分に1度問い合わせが来る」に置き換えたイメージです。実際にプロダクトが増えたことがあり、今のチームの状態に沿わないと判断したため委譲手段を模索しつつ僕自身が担当することに。今期の注力プロジェクトも担当していたことも相まって、見事に「10分に1度問い合わせが来る」状態に陥りそれ以外のことに手が付けられなくなってしまいました。これはチーム外からの助力もあり現時点では徐々に解消している部分もありますが、状況が変わればまた起こるので継続的に対策を打っていく必要がありそうです。

[Bad]一部のメンバーに集中できる開発環境を用意できなかった

社外から協力頂いているメンバーもおり、開発環境の制約などの関係で万全の開発環境を用意できていない現状があります。前述の理由もあり時間を取って整備する余力がないタイミングだったので、これは来期改善したい項目です。折角協力してくださっているのに「本人も最大の力が発揮できない、こちらも解決したい課題をお任せできない」という状況ではお互い不幸ですよね。優先度高く対処すべきだと認識しています。

[Bad]隣接するチームの負荷を把握できておらず、そのメンバーにある期間高い負荷をかけてしまっていた

これは個人的にかなり反省しています。今期の注力プロジェクトの繁忙期に、自分のチームと連携して動いてくれている隣接するチームのメンバーに高い負荷をかけてしまっていたこと、そしてそれをちゃんと認識できていなかったことがありました。まず把握すること、そしてケアや改善策を検討できていることが理想だと思うので、以後注意しなければと思っています。

[Bad]一部のメンバーが手持ち無沙汰なタイミングを作ってしまった

今期の後半、チームメンバーの人数が自分を含めて7人になった辺りに起こった現象です。タスクはガンガン消化されるのですが、将来に向けた新規プロダクトの要件検討や既存プロダクトのタスク整理が進んでおらず「手が空いたので次は何をしましょうか?」に即座に対応できなかったことがありました。「やることがない状態」が「集中できている状態」と最もかけ離れているので、チームリーダーとしては見事に責務を果たせていないことになります。なので常にタスクの残弾を持った状態にすることが来期の目標です。

まとめ

こうやって書き出してみると、半年チームリーダーをやってみて上手くいった部分もそうでない部分も色々とありました。もちろんここに書けなかったこともまだまだあります。その中で色々と学ぶ部分もあり、思考整理することで沢山の気付きもありました。 来期に向けての課題も整理できたので、(自分も含め)みんなが集中できる環境を作り出してチームがより高いアウトプットを出せる状態に持っていければと思います!

ここまで読んで頂けたみなさん、いかがでしたか?少しでもトレタの職場の雰囲気が想像できたでしょうか?僕はもうすぐトレタに入社して1年が経ちます。入社後数ヶ月の僕がリーダーを任せてもらえてやってこれたのも、来期に向けて頑張っていこうと思えるのも、トレタで一緒に働くみなさんのお陰だなぁとつくづく思うばかりです。 そんな職場に少しでも興味をもって頂けたなら、是非みなさんのお力を貸して頂ければ幸いです。 募集職種一覧はコチラ

5年目エンジニアの考えるエンジニアとして"圧倒的成長"する方法

始めに

皆様、こんにちは!
Toretaのサーバサイドエンジニア兼佐久間まゆちゃんのプロデューサーの@hiroki_tanakaです。
この記事はトレタ Advent Calendar 2019の11日目の記事です。
他の方がテクニカルな記事を書いている中、私は"想い"を投稿します。

自己紹介

  • 社会人歴:5年目
  • 新卒で独立系SIerに4年間在籍。ITコンサルタントとして設計〜リリースまでの一気通貫PJに従事し慌ただしい日々を過ごす。
  • 2019/11/1よりToretaにサーバサイドエンジニアとしてJoin。
  • 大手企業の基幹系システム構築からWeb系自社プロダクト開発に変化し、全てが新鮮で色々戸惑いながらも日々邁進中。
  • Ruby歴:1年半・Java歴:2年・SQL歴:4年。

記事の目的

新人エンジニア Advent Calendar 2016文系出身の2年目エンジニアが『情熱プログラマー』を読んで新人に伝えたいことという記事を投稿したのですが、3年ぶりの続編です。
2019年は人生初の転職もあり自分のエンジニアとしてのキャリアを見つめ直したことや、久々に『情熱プログラマー』を読んだ時の3年前との感じ方の変化からエンジニアとしての成長という観点で語っていこうと思います。
(他のエンジニアの方の役に少しでも立てれば、とても嬉しいです。)
タイトルの"圧倒的成長"は一昔前のバズワードを使ってみたかっただけです。

情熱プログラマー ソフトウェア開発者の幸せな生き方

情熱プログラマー ソフトウェア開発者の幸せな生き方

  • 作者:Chad Fowler
  • 出版社/メーカー: オーム社
  • 発売日: 2010/02/26
  • メディア: 単行本(ソフトカバー)

1. スペシャリストになろう

ほかに何も知らないことがスペシャリストだって勘違いしているんじゃないか
何かのスペシャリストであるということを、単にほかのことを知らないという意味で使っている人が多すぎる。その技術的な知識には深みがないんだ。
スペシャリストは他に何も知らないことの言い訳ではないんだ。

自称「Javaエンジニア」だった私にはとても刺さりました。
Rubyを1年半・Javaを2年書いていますが、じゃあ、「何故、Rubyプログラムは動くのか?」や「Javaのコンパイルの仕組みは?」と聞かれたら、私は答えられません。
そもそもプログラミング言語やOSという普段当たり前に使用しているアプリケーション実装の下位の部分を詳細に理解しようとしたことがありませんでした。
1~2年目は目の前のアプリケーションをプログラミング言語という道具で自分の開発すべき機能を実装するが精一杯でした。
しかし、5年目にも関わらず、その次元に居ては技術的に深みのない自称スペシャリストになってしまいます。
「プログラムは何故動いているのか」というそんな当たり前の質問にまず答えられるようになりたいと思います。
そして、自分が使用しているライブラリやFWといった道具の原理原則や設計思想は説明できるようになって、初めてスペシャリストの第一歩だと思っています。

2. オレ、作文的なのは得意っすよ

文章を書くことが仕事の一部になるとすれば、もっと作文技術を磨いたほうがいい。
たとえプログラマとして優秀であっても、自分自身を言葉で表現できなければ、グローバルに分散したチームではあまり有能な人材とは見なされない。
そもそも母国語で自分の考えを他人にわかりやすく組み立てられないのに、どうしてプログラミング言語ならできるって言える?
アイディアを言葉にして論理的な結論に導く能力は、将来の保守担当者に理解できるように明快な設計とシステム実装を生み出す能力とそれほど違わない。

言葉で自分のしたいことを説明するのはとても難しいですし、私はとても苦手です。口頭ではなく、文章なら尚更です。
なので、私は「プログラムで表現して、動く機能を見せれば良い」と考えていました。
ですが、母国語で自分の考えを他人にわかりやすく組み立てられないのに、どうしてプログラミング言語ならできるって言える?とある通り、 どうして日本語で説明出来ないことがRubyやJava・SQLでなら説明出来るようになるのでしょうか。
(今思えば、謎です…)
また、様々な働き方が増えてきた今、コミュニケーション手段が文章のみという場面も多くなり、トレタでも毎週リモートワークの日を設けています。
(先日は全社員が一週間全てリモートワークのリモートウィークも試験的に行いました。)
チーム全員が別の場所で働いている中で自分が何をしたか、どのように設計したか、チームに何をしてほしいかをしっかり出来る説明できるスキルは技術力と同じくらい重要なスキルだと実感しています。

3. 一番の下手くそでいよう

どんなバンドで演るときも一番下手なプレイヤーでいろ。チームで一番下手くそでいるのは、バンドで一番下手くそでいるのと同じ効果がある。
チームで一番下手くそでいると、どういうわけか自分自身が賢くなるんだ。
自分の生み出すコードや設計が以前よりエレガントになり、難しい問題をますます創造的なソリューションで解決できるようになる。

実は上記の文章に私の言いたいことは全て集約されています。
IT業界は移り変わりの激しい業界なので4〜5年目となるともう会社では中堅でチームを任せられたりマネジメント側に回ったりします。
マネージャーとしてのキャリアを積んでいくならば、それでも良いと思います。 ですが、エンジニアとして技術を深めていくならば、そのタイミングでもう一度自分が一番下手くそな環境に行くのが良いと思います。

私は3~5年目の時に100人規模のPJに所属していたのですが、気づくと私より技術が出来る人は数える程でした。
非常に忙しかったのですが、自分が技術的に優れていると思える&周りからそう思われているので正直、居心地良かったです。
「技術力あってマネジメントも出来るようになってきてるオレ、スゲー」状態でした。
ただ、技術的に成長できたかと言うとNOです。 そうです、技術の自己研鑽を止めてしまっていたのです。
そんな中でわずかに残っていたエンジニア心から自分の技術力を高めていない状況に危機感を覚えました。
(自分のRailsの知識が4.2で止まっていることを自覚した時、本気でまずいと思いました。)

現在はまさに自分が一番下手くそで周りは皆出来る人ばかりなので、正直、会話一つ一つから自分の知識不足を痛感します。
ただ、追いつこうとして2年前に止まったエンジニアとしての成長曲線が再度動き出したことも同時に感じます。
一番下手くそな環境に行ったことは正解でした。

最後に

『情熱プログラマー』の最後に書かれていることがエンジニア生活の全てを表しているのではないか、と3年前に思ったのですが今読んでもやはりそう思います。
これからもクリエイティブで楽しいエンジニアライフを送りたいと思います。
今後は自分が成長するのは勿論ですが、チームとしての成長にも貢献出来るように自分のバリューを発揮していきたいです。
ゆくゆくは自分の技術の腕で皆を引っ張っていけるように。

ソフトフェア開発はやりがいがあって、しかも報われる仕事だ。
芸術活動のようにクリエイティブでありながら、芸術とは違って、具体的で数量化出来る価値を生み出せる。
ソフトウェア開発は楽しい!

CSからエンジニアにジョブチェンジしました

この記事は トレタ Advent Calendar 2019 の10日目です。

こんにちは。iOSエンジニアの@yukimura03です。

気づけばトレタで働き始めて2年が経ちますが、エンジニア歴は8ヶ月くらいの初心者です。
今日のアドベントカレンダーでは、他職種からジョブチェンジしてみてどう感じたか、という話をしようと思います。

前提

最初に書いた通り、エンジニア歴は1年未満の初心者エンジニアです。
今年3月まではトレタのCS(カスタマーサクセス)部に所属する派遣社員でした。
実際にトレタの台帳を使っている店舗の方と電話をして、使い方の説明をしたり、トラブルシューティング的な対応をしたりしていました。

よかったこと

プロダクトにより深く関わることができる

これまではCSでユーザーのサポート的なことをしていたため、実際のユーザーの声をたくさん聞いてきました。
自然と台帳の使い方にも詳しくなりますし、自然と愛着も湧いてきます。
そうなると、これはどうやって動いてるんだろう? 作ってる人すごいな? 裏側が知りたい、私もこれを作りたい! という気持ちになることも自然なはず(?)です。
今エンジニアになって実際のコードを触るようになって、当時は知らなかった仕組みなんかを知って日々感動しています。

知っている人たちの中で新しいことに挑戦する

緩い考え方かもしれないですが、新しい環境で新しいことに挑戦する、ってとてもハードルが高いと思うんですよね。
部署が変わるとはいえ、同じ社内なので顔見知りは多い環境で新しいことにチャレンジさせてもらえたのは、私にとってとても良いことでした。
また、独学ではじめた勉強をサポートしてくれる頼れる先輩エンジニアがいたり、分からないところがあればすぐに質問できるあたたかい環境であることも、とてもありがたいと思っています。

困ったこと

Swiftしかわからない(けどSwiftもわからない)

私は去年からSwiftを勉強しはじめました。他の言語? わかりません。
Swiftも勉強中の私ですが、実際のプロダクトのコードはObj-Cで書かれている部分もかなり多く、「読めない…」が最初のつまずきでした。
なので異動当初にObj-CのコードをSwiftに書き換えるタスクをもらって大苦戦…
「Obj-Cの通りにSwiftを書いてるはずなのに、違うclassが返ってきてしまって動かないんです」と先輩に泣きついて、
「これはObj-Cだから動いてただけだね。Obj-Cは型キャストしたときに違うclassが返ってきてても、同じプロパティがあれば動いちゃうんだよ」と聞いてポカーン。なんだそりゃ…ゆるふわ…
なんとか苦戦しながらSwiftに書き換えた、今となってはとても貴重な経験です(あれでObj-Cがだいぶ読めるようになりました)。

ユーザーの声が聞こえにくなった

あんなに毎日電話でユーザーと話してたのに、当たり前ですが開発に移ってきたら電話をしなくなります。途端に使っている人の現状が分からなくなりました。
今までなら黙ってても情報が入ってきたのに、積極的にとりに行かないと分からないんだ……当たり前のことですが、思ってたよりわかんない。
今までの約1年分のユーザーの利用状況は知っていますし、大きな変更が加わらない限りその知識も役に立つだろうとは思っていますが、これからもユーザーの現状は把握しながら開発に臨める人でありたいなぁと思っております。

最後に

なんだかただ私の想いをしたためた感じになってしまいましたが、総合すると、CSからエンジニアに移ってきてよかったよ!という話です。
使う人の声を知りながら作ることもできる人になったらすごくない? 万能なの? かっこいい! という雑な気持ちで締めさせていただきます。
未経験でもエンジニア職に興味を持った人はぜひ挑戦してみたらいいと思います! 楽しいよ!
ありがとうございました!

© Toreta, Inc.

Powered by Hatena Blog