食べログ仕入にJOINして1年2ヶ月でやったこと

この記事は 食べログアドベントカレンダー2022 の12日目の記事です🎅🎄

はじめに

こんにちは、食べログ仕入のエンジニア、山本（@shohei-y）です。

食べログ仕入には、2021年9月の入社と同時にJOINしました。 食べログ仕入にJOINして1年2ヶ月でやったことと題して、JOINから今日までを振り返って紹介させていただきます。

全部読んでいただけると嬉しいですが、複数の取り組みを紹介しています、お急ぎの人は、気になるタイトルにジャンプしてご覧ください。

---

---

1. チームメンバーと仲良くなりたい

「チームに馴染めるか」は、新しい環境にJOINした直後に多くの人が悩むポイントです。 私も、初めなかなか馴染めずに悩んでいて、私自身が働きやすい関係性にするべく、取り組みを行いました。

1.1. Fun／Done／Learn導入

初めて実施した時のFDLボード

今は、ずいぶん認知度の上がった振り返り手法です。詳しく知りたい人は、やっとむさんのブログに紹介されていますのでご参照ください。

本来、スプリントやプロジェクトなどの振り返りに利用するものですが、今回はチーム（主に私）のアイスブレイクのために導入しました。

チーム内での振り返りのテーマは、最近の出来事です。 なぜか毎回、食と健康の話が一番盛り上がります。飯テロも度々行われ、夕飯が決まることも。

FDLを実施したことにより、既存チームメンバー間でも新たな発見も数多くあったようで、コミュニケーション不足の解消にもつながりました。1年経った今も、不定期で実施しています。

✅ - CHECK
アイスブレイクできていますか？

💡 - HINT
もし、不安に感じることがあれば、たわいも無い会話をする場と、枠組みを使ってみてください。

1.2. マイクを購入

オンラインでは、マイクで届く音声が全てです。

入社後１ヶ月程度は、Macのマイクを利用していました。当時マイクの調子が悪かったようで...。聞き取れるギリギリ（聞こえませんの手前）の音声状態で届いていました。「山本さん、ちょっと声聞こえづらいんだよな。」と全員が感じていたようです。

私自身は、伝えた事に対する反応がなかったり、薄かったりすることが多くあり、「ハマってないな〜」と感じていました。

ある日、AirPodsで会話しているとチームメンバーの反応がビックリするくらい、ちゃんと返ってくる事から、マイクの調子が悪い事に気づきコンデンサーマイクを購入しました。

マイク購入後は、急にコミュニケーションが円滑になりました。 １ヶ月程度の悩みだった、「ハマってない」は杞憂に終わり、この件は大きな気づきとなりました。

✅ - CHECK
音声届いていますか？音声聞こえづらい人はいませんか？

💡 - HINT
勇気を持って、不安であること、聞こえづらいことを伝えましょう。

1.3. エンジニア作業場を設置

オンラインで気軽に相談できる場所が欲しく、Teamsに常時接続可能な作業スペースを設置しました。

当時のチームは

• 相談はDMでしている（っぽい）
• チャットが動いていない（業務連絡で数件流れている程度）

と、なかなか気軽に相談するには、ハードルが高い状態にありました。 今では、このエンジニア作業場が、オフィススペース代わりになり、「ちょっと質問いいですか？」「ちょっと聞いてほしいことが」のような自然なコミュニケーションが取れる場所となっています。

✅ - CHECK
作業で詰まって、一人で悩んでいることはありませんか？また、一人で悩んでいる人はいませんか？

💡 - HINT
困ったら「DMで」とか「チャットで気軽に」が、苦手な人もいるかもしれません。
相談ではなく、雑談ができる場を導入してみましょう。

1.4. セルフ歓迎会を開催

チームメンバーと、「円滑に業務を進める」「何より楽しく仕事をする」ために、業務関係なく話す場が欲しく歓迎会を開催しました。アルコールは好き嫌いがあるのでどちらでも良いと思いますが、やはり業務関係ない場でのコミュニケーションは非常に重要で、歓迎会前と後では、業務遂行における円滑さが１段上がったように感じています。

✅ - CHECK
業務と直接関わりのない人と、コミュニケーション取れていますか？

💡 - HINT
直接関わりなくても、相互理解をすることで円滑に進むことも多いです。積極的に攻めましょう。
会話ではなく、対話ができる関係を目指しましょう。

2. Ruby on Rails／Vue.jsと仲良くなりたい

JOIN時点での私の技術スタックは、React.jsとNode.js、Java、PHP、C、Docker、COBOL、PL/1など、レガシー技術も多くRailsもVue.jsも触ったことがない状態でした。エンジニアとして最低限のバリューを出すべく、取り組みを行いました。

2.1. レビュー千本ノック

おぼつかない実装を細かくチェックして、指摘コメントをたくさん出してもらいました。 初めの２週間は、死に物狂いで指摘コメントと戦っていました。 記述方法の指摘から、既存ロジックの活用など、さまざまな視点から指摘をいただき、なんとかRailsとVue.jsでまともなソースが書けるようになりました。 根気強く対応してくださったレビュアさんには、めちゃくちゃ感謝しています。

✅ - CHECK
初めから完璧を作ろうとしていませんか？

💡 - HINT
初めは、失敗していいんです。どんどん当たりにいきましょう。
しかし、当たり屋にならないように、同じ指摘をもらわないようにしましょう。

2.2. RailsとVue.jsの関係を図に落とす

既存エンジニアは以前から食べログ本体にて開発を行なっていたこともあり、アーキテクチャ図に相当する資料が存在していませんでした。 そこで、自らの理解のために図を作成し認識合わせを行いました。 これをやってから、実装の理解度、作業効率が格段に上がったのを記憶しています。

✅ - CHECK
今の環境や、仕組みを人に説明できますか？

💡 - HINT
一度、現状の理解を吐き出してみてください、理解の浅い部分、深い部分が見えてきます。
吐き出した内容を有識者に見せて、不明点を明らかにしましょう。

2.3. Vue.jsでアプリケーションを作ってみる

team-poker

欲しかったツールを、Vue.jsを使って作成しました。 ０から作ることで、理解をさらに深めることができました。

作成する上で気をつけたことは、1点です。

• ゴール（ツール完成）には遠回りでいいから、最短で使えるものを作る

具体的には、２段階で開発しています。 初めは知見のあった GoogleAppsScript で公開し、その後Firebaseに移行しています。

✅ - CHECK
新規に作るチャンスがないから、できない。難しいって思っていませんか？

💡 - HINT
自分で環境作って、手を動かしてみましょう。
可能であれば、有益なものにしたいので自分が使いたいものを作りましょう。
完全を目指すのではなく、MVPを目指して作りましょう。

無料でWEB公開することもできるサービスも多くあります。
- GitHub Pages / Firebase / AWSなど

3. ユーザーの事を知りたい

プロダクト開発に携わる上で、ユーザーのことを意識して取り組むのと、意識しないのとでは大きな差があります。 新規事業ならでは、小さなチームで取り組んでおりチャンスが多くありました。

3.1. ユーザーとのWEB会議に参加する

ある時、ユーザーと直接やりとりしているビジネスメンバーから、参加してみたい人いますか？と声かけがあり、オブザーバーとして参加しました。 そこから、定期的に参加するようになり、プロダクトを初めて操作するユーザーの操作方法やどこで躓くのかなどを知るために、半年間ほど参加を続けていました。 現在は、エンジニアも一次情報に触れるという文化が定着しています。

✅ - CHECK
ビジネスや営業、チームリーダーは、ユーザーとミーティングしていませんか？

💡 - HINT
オブザーバーとして参加できないか聞いてみましょう。難しければ、録画を配信してもらいましょう。
ユーザー理解が、プロダクトの品質に影響します。そこを押しましょう。

3.2. ユーザーへの訪問に同席する

卸事業者への訪問にも、同行していました。 実際にどのような業務・環境・タイミングで、作成したプロダクトを利用するのかを肌で感じることができています。 訪問すると、新たなプロダクト改善のアイデアなども浮かぶので、百聞は一見にしかずで聞いて知るより, 感じて知る方が何十、何百倍も良いことを肌で感じています。

✅ - CHECK
ビジネスや営業、チームリーダーは、訪問していませんか？

💡 - HINT
オブザーバーとして参加できないか聞いてみましょう。
しかし訪問することで、実業務が遅れてしまうと、理解を得ることが難しいです。
少しストレッチして、時間を作るのが良いです。

4. 振り返り効率を上げたい

食べログ仕入は、１週間スプリントのスクラムで開発をしています。 そこで、毎週やってくる振り返りの（時間・価値）効率を上げたくいくつか、取り組みを行いました。

4.1. Asanaの運用方法を設計・活用

食べログ仕入では、以前Jiraを利用していました。他チームで積極的に利用しているツールがAsanaだった事もあり、JiraからAsanaに乗り換えました。そこで、今までJiraを使って、できていた事をできるように、かつ効率を向上させ、快適にするために、さまざま調整を加えています。

Asanaの活用方法を紹介します。

• プロジェクト
  • PBL（プロダクトバックログ）
    • プロダクトの主要施策・案件がいつ出るか、前後関係はどうなっているかなど、タイムラインを利用してチャート管理しています。（よくある優先順に並べたバックログはGitHubで別管理）
  • SBL（スプリントバックログ）
    • スプリントで実施するタスクをためていきます。
  • EPIC
    • 施策・案件毎に要件〜リリースまでのタスクを管理しています。
  • TASK
    • 施策・案件に関わりのないタスクを管理していきます。
  • TOOL
    • さまざまな仕組みと組み合わせてツールとして利用しています。
• ポートフォリオ
  • レポートにまとめる単位でプロジェクトを束ねています。
  • EPICを束ねて、施策・案件毎に進捗レポートを作成しています。
• レポート
  • 予定時間と実績時間とのギャップや、消化状況などをグラフで確認します。

実は、まだ悩むポイントもあります。 使い方の問題な気もするのですが、どんどんEPICプロジェクトが増えていきます。 完了時にアーカイブしていますが、２、3年後が少し怖いです。

✅ - CHECK
今のプロジェクト管理ツール、使いこなせていますか？不満に感じるポイントはありませんか？

💡 - HINT
どうしたいかを、整理して、やりたいことが実現できる方法がないかを考えてみましょう。
どうしてもできない場合、何ならできるのかを調べて提案するのも良いです。

4.2. GitHubとAsanaのAPI活用

現在利用しているのがGitHubとAsanaです。上記で記載した通り、Asanaもいくつかのプロジェクトや用途で利用しているため、プロジェクト間の整合性など健全に保つのが結構骨が折れる運用となっています。 そこで、人力でやるのではなく、APIを使って自動で調整するような仕組みを自作して、導入しています。

✅ - CHECK
今のプロジェクト管理ツールやSaaSはAPIやWebhookを提供していませんか？

💡 - HINT
まずは出来ることを試してみて、どう活用できるかを妄想してみましょう。
何が出来るかがわかると、案外閃くことがあります。

5. 作業効率を上げたい

永遠の欲求であり、課題です。全ての作業は寝て過ごして、終わっている世界になればいいなと思っています。 少しでも理想に近づくために、取り組みを行なってきました。

5.1. CircleCI導入

当時、残念ながらCIが導入されていませんでした。 新規事業で「まずは動くもの」が急務というのもありますが、CIさえ導入していれば流出が防げたバグや、削減できた作業時間があったと考えると勿体無い状態です。

導入直後は、Rubocopや RSpec、JestなどをCIに設定するように対応しました。 現在は、CIで動かすラインナップも少し増えていますし、Rubocopの指摘数やRSpecをはじめとするテストコードも徐々に充実してきています。

✅ - CHECK
CI使っていますか？

💡 - HINT
導入しましょう！
導入できない理由がある場合は、課題を整理してみましょう。

5.2. StoryBook導入

デザインデータや共通部品をStoryBookに掲載するようにしました。共通部品の開発は、StoryBook上で行うこともあります。

バックエンドから一連の動作がなくとも、UI部分の開発が単体でできるようになり複数人での開発が楽になっています。

✅ - CHECK
デザインデータや共通部品、管理できていますか？

💡 - HINT
StoryBookなどの、UIコンポーネント管理ツールの導入を検討してみましょう。
フロントエンジニアやデザイナ以外が参照できるようになると、何か世界が開けるかもしれません。

5.3. 大きなプログラムのコンポーネント化

１つのファイルに色々なことを詰め込んでいるプログラムも多く存在し、メンテナンス性が悪いことも課題でした。 開発をしながら、徐々に既存プログラムを分割するように取り組んでいきました。 チーム全員で課題感を共有し今では行数の多いファイルがあらたに増えることは、なくなりましたし、共通化することで修正が１箇所で済むなど、良い効果が出てきています。

✅ - CHECK
同じ処理が３箇所以上に記載されていませんか？

💡 - HINT
３箇所出てきたら、共通化を検討してみましょう。仮に３箇所だけで未来永劫増える可能性がないのであれば問題ないかもです。
メンテナンス性も向上するので、共通化するルールだけでも決めておくと良いです。

5.4. その他

完了の定義設定、Branch運用の見直し、設計書テンプレートの作成...など、少しずつ改善を繰り返してきました。 改善しつつ、ドキュメントを作成し、新規参画者が困らないように取り組んでいます。

✅ - CHECK
人により、作業品質・速度にばらつきがありますか？

💡 - HINT
能力の差ではない箇所で差が出ている可能性もあります。一度何に詰まっているか整理して欠けている情報を探してみましょう。

6. 育休を取得したい

画像は、育休取得中のイメージです。

今年の夏、第二子誕生に合わせて、育児休業を１か月取得させていただきました。 入社後1年未満のタイミングだったのですが、2022年4月の法改正で取得が可能となったこと、何よりチームの理解があり、出産直後１ヶ月の、一番大変なタイミングで育業に入りました。

育児休業取得までに、やったことは４つです。

1. 上長に取得したい旨を相談
2. 社内のTeamsで人事担当に連絡
3. 人事担当から、制度の説明〜社内手続き開始
4. チームへの業務調整

と記載しましたが、業務上の報告の一環でのコミュニケーションのみで、取得することでき、ほとんど何もせずともとんとん拍子で育児休業まで取得できました。

法改正と、チームの協力、会社のスムーズな手続きなど、本当に助かりました。 無事、我が子は現在離乳食も始まりすくすく成長しています。

✅ - CHECK
育児休業を、休みと考えていますか？
育児休業に入る人を長期休暇取れていいな〜と思っていませんか？

💡 - HINT
育児休業を取るタイミングにもよりますが、激務です。
子供と一緒にいれて幸せ（お花畑）でいくとK.O.されます。
異業種転職する気持ちで挑むのがちょうどいいです。

7. なかなか進まないシステム課題を潰したい

必ず発生してしまう「システム課題」です。システムの運用期間が長くなれば、システム構成がレガシーになりますし、老朽化もします。 開発を繰り返すと、無理のある実装が増えることもありますし、性能の問題も出てきます。負の遺産がどんどん溜まっていきます。

7.1. 付箋から、タスクに切り替え

システム課題は、GitHubのissuesや、Miroの付箋でペタペタ溜めて、できることからやる状態から、Asanaのタスクやプロジェクトに変更し担当割り当て、スケジュール管理をするように変更しました。

管理するときに気を付けるポイント

• タスク分割を1日で終わる程度に分割
• スケジュールを設定して、ゴールを決める
• 立候補で主担当を決める

これだけのことですが、今は、システム課題のタスク消化が進んでいます。

どんどんやりたい事が積み上がっている状態で、メインの業務タスクがある場合、「見て見ぬ振り」や「取り組んでも、進んでいるかがわからない状態」になりモチベーションが下がってしまっていたのではないかと考えています。

洗濯物も、畳むことを１回放置すると、（私の場合は）１週間程度溜まり続けます。その状態と似ているなと思います。 逆に、今日は３枚畳むと決めていて、畳めたら褒めてくれる人が隣にいると、逆に５枚くらい畳みたくなります。

✅ - CHECK
後回しにして、何をやるのか分からなくなっている課題はありませんか？

💡 - HINT
定期的に棚卸しをして、やるタイミングなどを話し合ってみましょう。
感謝を普段から伝えて、褒める文化を取り入れてみましょう。

8. ビジネス依頼作業を自動化したい

食べログ仕入も、ユーザーによる問い合わせ対応や、ビジネスメンバーからの作業リクエストが多く発生します。 日々発生するものや、不定期のものまで対応する内容は様々です。対応は、手順を作成してから、作業を実施します。手順化されていても、作業は必ず発生してしまいます。プロダクト開発に専念できるように、かつ作業ミスの撲滅のために、自動化を行っています。

8.1. AsanaのフォームとAPIを使って半自動化

変更前

変更後

この対応では、同じ作業が難度も発生している状態でした。また、エンジニア作業後も後続の業務があり、待たせないように対応していく必要がありました。そこで、Asanaを活用しエンジニアの人系作業を最後の登録のみにすることで、依頼からのリードタイムを大幅に削減しました。

現在は、最後のエンジニア作業も自動化され、エンジニアが介入することなくリクエストが完了する状態までになっています。

✅ - CHECK
作業依頼で、半日潰れることはありませんか？それを勿体無いと感じますか？

💡 - HINT
単純作業や繰り返し作業は、改善のタネです。自動化、半自動化、簡略化できるポイントがないか考えてみましょう。
自分でやっていることをトレースして考えると見つかるかもしれません。

9. プロダクト課題にアプローチしたい

ユーザーのことを知っていき、業務、プロダクトの理解も深まってくると、プロダクト成長や課題にインパクトのある施策を考えて、届けたくなります。

9.1. ユーザーになりきったプロダクト操作会

この施策は、私が主導したものではなく、アドベントカレンダーに参加している @itayaさんが企画してくれました！

1. ユーザーの属性や利用シーンを決める
2. 操作者はユーザーになりきって、操作（イタコ的に憑依するイメージです）
3. 操作する中で気になったこと、もっとこうした方がいいこと、つまずいたこと、良かったことをMiroの付箋で書き出す
4. 操作後に、付箋についてみんなで共有し、分類分け（効果×難易度）

ここからプロダクトに潜在する課題を洗い出し、対応を行うことを定期的に実施しています。 ときには、オンボーディングなどのトークスクリプトを軸にした会もあり、プロダクト開発に没頭していると、忘れがちなユーザー視点を取り戻す会になっていたりします。

✅ - CHECK
プロダクトをテストや開発以外で触っていますか？玄人の操作をしていませんか？

💡 - HINT
ユーザーは、思いもよらない操作をするものです。一度憑依して空っぽになって操作してみましょう。
チーム開発の場合は、みんなでやると色々意見が発散されて、アイデアの種が見つかります。

9.2. プロダクト課題の要件定義

プロダクト操作会などで見つかった課題には、エンジニアアプローチで対応できるものも多くあり、そういった課題に対して要件定義から対応することもあります。

要件定義時の流れは、こちら

1. データ分析（対象の課題に陥っているユーザーと、課題を超えているユーザーの違いなど）
2. データで見えてきた差について、因果関係を探し仮説立て
3. 仮説検証（検証用の機能リリースや、別の視点でデータ分析し裏取り）
4. プロダクトでの対応方法を決定
5. 難易度と実現性を確認（問題なければプロダクトバックログに、再検討が必要なら前段に戻る）

ユーザーとの距離が少しあるので、可能な限りデータアプローチをするようにしています。それでも、根拠に欠ける場合は、ユーザーに確認しにいくなどが必要かなと考えています。

✅ - CHECK
ユーザーの気持ちになって、業務に取り組んでいますか？

💡 - HINT
ユーザーの気持ちになれば、困りポイントが自然とわかってきます。
そこにエンジニアのエッセンスを加えて、提案してみましょう。

10. まとめ

仕入チームにJOIN後のやったことを改めて振り返ると、チームや、システムに馴染めなかったところから、より良くしていく視点に変わっていき、この1年2ヶ月間でチームの一員になれた気がしています。 今回紹介させていただいた取り組みは、どれもちょっとしたことですが、ここまでやってきた取り組みの結果、今、入社当時比でチームの雰囲気や生産性が向上しています。

これからも、取り組みを続け、この小さな取り組みの積み重ねが、楽しく働ける環境、チームみんなのハッピーに繋がっていけばいいなと思っています。

10.1. 取り組みに対する効果一覧

記載の時間と効果は、あくまで私の所感です。 チーム状況や重視するポイントにより変わります。参考程度に、ご覧いただければ幸いです。

取り組み	かかった時間	効果
1. チームメンバーと仲良くなりたい	-	-
1.1. Fun／Done／Learn導入	1h	⭐️⭐️
1.2. マイクを購入	1h	⭐️
1.3. エンジニア作業場を設置	0.1h	⭐️⭐️
1.4. セルフ歓迎会を開催	3h	⭐️⭐️⭐️
2. Ruby on Rails／Vue.jsと仲良くなりたい	-	-
2.1. レビュー千本ノック	2w	⭐️⭐️⭐️
2.2. RailsとVue.jsの関係を図に落とす	2h	⭐️⭐️
2.3. Vue.jsでアプリケーションを作ってみる	3d	⭐️
3. ユーザーの事を知りたい	-	-
3.1. ユーザーとのWEB会議に参加する	2h	⭐️⭐️
3.2. ユーザーへの訪問に同席する	3h	⭐️⭐️⭐️
4. 振り返り効率を上げたい	-	-
4.1. Asanaの運用方法を設計・活用	2d	⭐️⭐️⭐️
4.2. GitHubとAsanaのAPI活用	4h	⭐️⭐️
5. 作業効率を上げたい	-	-
5.1. CircleCI導入	1d	⭐️⭐️⭐️
5.2. StoryBook導入	1d	⭐️
5.3. 大きなプログラムのコンポーネント化	3d	⭐️⭐️
5.4. その他	1w	⭐️⭐️
6. 育休を取得したい	4w	⭐️⭐️⭐️
7. なかなか進まないシステム課題を潰したい	-	-
7.1. 付箋から、タスクに切り替え	1h	⭐️⭐️
8. ビジネス依頼作業を自動化したい	-	-
8.1. AsanaのフォームとAPIを使って半自動化	3h	⭐️⭐️⭐️
9. プロダクト課題にアプローチしたい	-	-
9.1. ユーザーになりきったプロダクト操作会	1d	⭐️⭐️⭐️
9.2. プロダクト課題の要件定義	1w	⭐️⭐️

さいごに

エンジニア業務に関係あることから、関係のないことまで取り組んでこれたのは、食べログ仕入チームが変化に強く、挑戦を面白がって受け入れるマインドがあるからだと感じています。それは、新規事業に携わるチームだからということもあるのかもしれません。しかし、エンジニアがここまでユーザーに近い位置で業務にあたれているのは珍しいのではないでしょうか。

エンジニアだから、メンバーだから・・・といった役割で、やることを制限することもありません。プロダクトにとって、チームにとって、ユーザーにとって何が必要なのかを全員で考え越境していくことをミッションに掲げて取り組んでいます。

私が携わっている、食べログ仕入について知りたい人は、こちらから

次回予告

明日は @hrkmkjm の「未経験の新卒が食べログのプロダクト開発の最前線で学んだこと」です。お楽しみに!