店舗検索APIにページネーションを追加した話

トレタ Advent Calendar 2019 の14日目の記事です。

こんにちは。ニュージーランドで1週間息抜きをしてきた2日後に、ボケボケの頭のまま 社内テックトーク で決して得意とは言えない競技プログラミングに関して話すことになってしまい、自分の計画性のなさを恨んでいるモバイルアプリエンジニアの大野です。 帰国した2日後に火山が噴火して驚きました。
本Advent Calendarには実に3年ぶりの登場となります。

---

私が主に関わっている Toreta now では、先日公開されたver1.2.0 から店舗を検索する機能にページネーションが追加されました。ページネーションが必要なほどサービスが成長してきたんだなーと思うと嬉しい限りです。
が、そのページネーションを実現するためのAPIの設計で一悶着あったので、本記事ではそのことについて紹介します。

登場人物

• 私
• サーバサイドエンジニア (以下 「サ」)
• 私とは別のモバイルアプリエンジニア (以下「モ」)

なお、GETのAPIなので実際にはリクエストパラメータはqueryで渡していますが、可読性のためにここではjson形式で表示することとします。 また、実際のAPIとはパラメータやデータのフォーマットなどが異なります。

最初期のバージョン

私「店舗検索は(中略) な感じだし、offsetベースよりはcursorベースのページネーションのほうが良いですよね。ってなわけで、こんな感じでリクエストパラメータとレスポンスを考えてみたんですがどうでしょ。」

---

北緯45°, 東経135°の位置にいるユーザーが、付近の店舗を検索する場合

最初のリクエストには、席数と予約の開始時間とユーザーの現在地を入れる。

# 1回目のリクエスト
{
    "seats": 4,
    "starts_from": "2019-12-14T21:00:00+09:00",
    "location": {
        "latitude": 45.0,
        "longitude": 135.0
    },
    "next_token": null
}

最初のリクエストへのレスポンスには、店舗一覧の情報と次回の検索用の next_token が入る。 next_token がnullだったら、ページネーションが完了したと判断する。 next_token には次回の検索の先頭のindexが入る。

# レスポンス
{
    "restaurants": [
        {
            "name": "レストラン1"
        },
        {
            "name": "レストラン2"
        }
    ],
    "next_token": "5"
}

2回目以降のリクエストでは、next_token 以外には最初のリクエストと同じ値を入れる。 next_token には前回のリクエストへのレスポンスに入っていた値をそのまま入れる。

# 2回目以降のリクエスト
{
    "seats": 4,
    "starts_from": "2019-12-14T21:00:00+09:00",
    "location": {
        "latitude": 45.0,
        "longitude": 135.0
    },
    "next_token": "5"
}

next_token の実装がどうなっているかはクライアント側では意識せず、単に受け取った値をそのまま使うだけです。 こうすると、UI以外のページネーションのロジックを全てサーバ側に押し付けることが出来るので、クライアント側では楽ができます。

サ「頭の中では大丈夫そうという気持ちになっています」 (原文ママ)
私「あざっす」

モさんによる指摘

モ「ちょっと待ってそれだと最初のリクエストと2回目以降のリクエストで location の値が違ったらどうなんの。ユーザーの位置が変わったら出てくる店舗も変わっちゃうでしょ。」

私「確かに。必ず同じ値のlocationを入れるようにする、って制限を付けるのもAPIとしては微妙っすね。じゃあこんな感じでどうでしょ。」

---

北緯45°, 東経135°の位置にいるユーザーが、付近の店舗を検索する場合 改

最初のリクエストには、席数と予約の開始時間とユーザーの現在地を入れる。

# 1回目のリクエスト 改
{
    "seats": 4,
    "starts_from": "2019-12-14T21:00:00+09:00",
    "location": {
        "latitude": 45.0,
        "longitude": 135.0
    },
    "next_token": null
}

最初のリクエストへのレスポンスには、店舗一覧の情報と次回の検索用の next_token が入る。 next_token がnullだったら、ページネーションが完了したと判断する。 next_token には、次回の検索の先頭のindexと検索のlocationが入る。

# レスポンス 改
{
    "restaurants": [
        {
            "name": "レストラン1"
        },
        {
            "name": "レストラン2"
        }
    ],
    "next_token": "5, latitude=45.0, longitude=135.0"
}

2回目以降のリクエストでは、seats, starts_from には最初のリクエストと同じ値を入れる。 next_token には前回のリクエストへのレスポンスに入っていた値をそのまま入れる。 サーバ側では next_token の値をparseして使う。

# 2回目以降のリクエスト 改
{
    "seats": 4,
    "starts_from": "2019-12-14T21:00:00+09:00",
    "next_token": "5, latitude=45.0, longitude=135.0"

}

私「というかこれだと2回目以降のリクエストに必要なパラメータがどれかわかりにくいし、いっそのこと全部 next_token に入れちゃっていいんじゃね？ 」

サ, モ「確かに」

---

北緯45°, 東経135°の位置にいるユーザーが、付近の店舗を検索する場合 改々

最初のリクエストには、席数と予約の開始時間とユーザーの現在地を入れる。

# 1回目のリクエスト 改々
{
    "seats": 4,
    "starts_from": "2019-12-14T21:00:00+09:00",
    "location": {
        "latitude": 45.0,
        "longitude": 135.0
    },
    "next_token": null
}

最初のリクエストへのレスポンスには、店舗一覧の情報と次回の検索用の next_token が入る。 next_token がnullだったら、ページネーションが完了したと判断する。 next_token には、次回の検索の先頭のindexと全ての検索条件が入る。

# レスポンス 改々
{
    "restaurants": [
        {
            "name": "レストラン1"
        },
        {
            "name": "レストラン2"
        }
    ],
    "next_token": "5, latitude=45.0, longitude=135.0, seats=4, starts_from=2019-12-14T21:00:00+09:00"
}

2回目以降のリクエストでは、next_token に前回のリクエストへのレスポンスに入っていた値をそのまま入れる。 サーバ側では next_token の値をparseして使う。

# 2回目以降のリクエスト 改々
{
    "next_token": "5, latitude=45.0, longitude=135.0, seats=4, starts_from=2019-12-14T21:00:00+09:00"
}

私, サ, モ「良さそう」

---

というわけで最終的にはこの内容で落ち着きました。

サーバ側のロジックがちょっとややこしいことになってしまい、実際に実装途中でいろいろバグりましたが、仮にバグがあった場合サーバ側はすぐに直して反映させることが出来るのに対し、モバイルアプリは審査の期間が挟まれたり何よりユーザーが最新版にアップデートしてくれるとは限らなかったりするため、クライアントにモバイルアプリが含まれることがわかっている場合にはややこしいロジックをサーバー側に押し付けるのは正しい設計だと信じています。

加えて、こうすることでサーバ側、クライアント側ともに状態を持たずにやりとりが出来るので何かと都合が良いことに気付きました。 (クライアント側は一旦 next_token を保存しないといけませんが。) 何となく、関数型プログラミングと近い考え方なのかな、と思ったりしています。

終わりに

ややこしいロジックを正しく実装してくださったサさん、及び的確な指摘でver1.2.0をリリースまで導いてくださったモさんに、この場を借りてお礼申し上げます。 明日はフロントエンドエンジニアの上垣がなにか書いてくれます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

マインドマップ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

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年前との感じ方の変化からエンジニアとしての成長という観点で語っていこうと思います。
(他のエンジニアの方の役に少しでも立てれば、とても嬉しいです。)
タイトルの"圧倒的成長"は一昔前のバズワードを使ってみたかっただけです。

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

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年前に思ったのですが今読んでもやはりそう思います。
これからもクリエイティブで楽しいエンジニアライフを送りたいと思います。
今後は自分が成長するのは勿論ですが、チームとしての成長にも貢献出来るように自分のバリューを発揮していきたいです。
ゆくゆくは自分の技術の腕で皆を引っ張っていけるように。

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