この記事は、Retty Advent Calender 2021 Part1の11日目の記事です。
はじめに
こんにちは、Retty株式会社セールス部門広告コンテンツ部推進グループに所属している森田です。 好きな料理は、鶏肉料理（唐揚げや串焼きなど）です。 いよいよ2021年も残すところあとわずかになりましたね！！
今回のPdMを目指す者シリーズでは、僕が2021年2月から関わっている新規プロダクトである&BARにて、開発PjMをさせていただき開発ディレクション周りで悪戦苦闘した内容を記載させていただきます。
ちなみに前回のPdMを目指す者シリーズはこちらになりますので、合わせて読んでいただければ嬉しいです！
&BARとは
&BARとは、バーカテゴリに特化したグルメ情報サービスです。 WebサイトとSNS(公式LINEやインスタグラム)を組み合わせた情報メディア構成となっており、現在は東京都内約9000店舗のバー情報を掲載しています。
僕らは&BARサイトを通じて、バーが好きな人には新たなバーの発見、バーに行ったことがない人にはバーの魅力訴求を目的とし、バーの利用促進を目指します！！
&BARのシステム構成
&BARのシステム構成はざっくり書くと下記のようになります。
&BAR最大の特徴は、概要図の右側にあるFDPとのデータ連携にあります。 FDP(Food Data Platform)とは、Rettyが保有するグルメデータを外部サービスに連携することができるサービスになります。 FDPについて気になる方はこちらを参照ください！
つまり、&BARはRettyが持つバーカテゴリのお店データをFDP経由で連携することで大量にコンテンツを生成することを可能にしているということです！！
『世はまさにデータ時代ですね笑』
これらをふまえて、&BARのシステム構成を簡単に説明すると、大きく3つに分けることができます。
1つ目は、&BARサイトを提供するためのtoC向けメディアサービスになります。
2つ目は、&BARサイト上で掲載しているお店データを各お店のオーナーさんが編集することができるtoB向けお店管理画面サービスになります。
3つ目は、先ほども説明したFDPとデータ連携をするためのバッチ基盤になります。
これらは各サービスごとにDockerコンテナで稼働するようになっており、本番環境はAWS Fargate上で稼働しています！！
&BAR開発プロジェクトの進め方
&BAR開発は下記のような体制で開発プロジェクトを進めてました。
- 開発PM - 筆者（森田） - バックエンド(APIサーバー)・管理画面開発 - パートナー企業A - サイトデザイン・フロントエンド開発 - パートナー企業B - FDPと&BARのデータ連携基盤開発・デプロイフロー(CircleCI)構築 - 筆者（森田） - インフラ構築 - Rettyインフラチーム
大きな特徴としては、バックエンド・管理画面開発とデザイン・フロントエンド開発でそれぞれにパートナー企業の方々についていただいていた点になります。 これにより、社内だけの閉じたコミュニケーションだけではなく、社外のパートナーの方々にも伝わるコミュニケーションを取る必要がありました。
この状況を踏まえて、&BAR開発は一部のイベントを取り除いたスクラム体制を敷いて進めることにしました。
&BARのスクラム体制
毎日開催 - 朝会 週1開催 - スプリントレビュー - スプリント計画
取り除いたイベントは、「ふりかえり」になります（今にして思えば、このふりかえりイベントもちゃんと開催しておけば良かったなと思っております笑）
取り除いた理由は、パートナーの方々の拘束時間に限りがあったことになります。パートナーの方々は&BAR開発プロジェクト以外にも別企業さんのプロジェクトも受け持っていたりするので、スクラムイベントに多くの時間を割くことができませんでした。
それでも、朝会には毎日15-30分、スプリントレビュー・計画にも毎週60-90分参加してくださっていたので、かなり融通してくれてたと思います。
&BAR開発ディレクションにて巻き込み力に課題
&BAR開発プロジェクトにて、僕はやる気がありすぎて全部一人で頑張ろうとしたことが結局空回りして苦戦することになりました、、笑
プロジェクトの初期から中盤にかけて、あらゆるタスクを引き受けてしまいやばいときで下記のようなタスク状況となってしまいました。
- ビジネスメンバーとの連携 <= コミュニケーション必須 - パートナー企業の開発ディレクション <= コミュニケーション必須 - &BARサイト・管理画面の詳細設計 <= コミュニケーション必須 - インフラ構築ディレクション <= コミュニケーション必須 - ローカル開発環境(パートナー企業)と検証・本番環境(インフラチーム)の差異の解消 <= コミュニケーション必須 - FDPと&BARのデータ連携基盤開発 - CircleCIにてデプロイフロー構築 - 不具合調査・解消 <= コミュニケーション必須 - テストデータ準備 <= コミュニケーション必須 - etc...
あまりいい方法ではないですが、抱えこんでいたタスクが自分一人で解消できる系のタスクだったら最悪時間をかけまくればなんとかなります。
しかし、抱え込んでいたタスクの大半がパートナー企業の方々や社内メンバーとコミュニケーション必須のタスクとなっていました。（開発ディレクションなので当然ですが笑）
このようにコミュニケーション必須のタスクを多く引き受けたことにより、下記のようなコミュニケーションフローができあがってしまいました、、、
ビジネスメンバー ⇔ 僕 ⇔ パートナー企業 インフラチーム ⇔ 僕 ⇔ パートナー企業 パートナー企業A ⇔ 僕 ⇔ パートナー企業B
これにより完全に僕がボトルネックとなってしまいました
各コミュニケーションラインがそれぞれ活発に動いていたため、僕が捌けなくなりそして爆発しました、、、笑
どのように解消したか
まずは、周りの人達に相談しました。それにより、僕がタスクを抱えすぎていることに気づくことができました。
状況を共有するためにSlackのチャットで抱えているタスクを一つずつ書いていると「あれ？、抱えすぎなのでは？？」という気持ちになりました笑 渦中にいると全然気づけないものなんですよね笑
自分がタスクを抱えすぎていることに気づけたので、解消方法は簡単で抱えているタスクを他の方に任せるようにしました。
これにより、コミュニケーションフローは下記のように改善することができました。
ビジネスメンバー ⇔ 僕 ⇔ パートナー企業 インフラチーム ⇔ パートナー企業 パートナー企業A ⇔ パートナー企業B
僕というボトルネックがなくなり、コミュニケーションコストを下げることができました笑 これをしたことでなんとかプロジェクトを立て直すことができて、リリースに間に合わせることができました！！
もっと早く周りを頼れば良かったと学び
&BAR開発プロジェクトを通じて、誰かに頼ることの大切さを学びました。
人は自分のことを一番自分の思い通りに動かすことができるので、自分でできそうなこと・やりたいことを自分に抱え込みがちになるのかなと思います（僕だけだったらすみません笑）
しかし、自分1人でできることはたかが知れていますし、1日24時間しかないので生産性にも限界があります。
そのため、積極的に周りの人達に頼り、任せていくことができる人の方が大きな成果や生産性を上げることができることを学びました。
僕の場合は、特に周りの人たちが僕よりも優秀な方しかいなかったので、今にして思えば「なんでもっと早く頼らなかったんだろう？？」と思っています笑
また、除外していたスクラムイベントのふりかえりを実施しておけば、早い段階で僕がボトルネックになっていることを他の誰かが指摘してくれていたかもしれません。 やはりふりかえりは大事なんですね！！
今回学んだことを踏まえて、プロジェクトを動かしていく機会にまた出会えましたら、そのときは周りの人達に頼りまくるようにしたいと思います！！
