自己紹介とRetty株式会社について
常松祐一氏：では「Go To Eatキャンペーンを支えたプロジェクトマネジメント」と題して、Retty株式会社の常松がお話しします。みなさんよろしくお願いします。
まず簡単に自己紹介です。Retty株式会社でWeb開発部門のマネージャーをやっています。ふだんはエンジニアリングマネージャーの勉強会や、アジャイル開発の勉強会などに、よく顔を出しています。今回はプロジェクトマネジメントの勉強会ということで、少しバックグラウンドが違いますが、ぜひよろしくお願いします。
初めての方もいると思うので、Retty株式会社の紹介を簡単にさせてください。Retty株式会社は、グルメサービスRettyを運営しています。実名の口コミを通じて、その人にとってベストなお店が見つかる、実名型のグルメサービスを運営しています。
例えば最近の私だと、毎日朝、近くのパン屋さんに行きます。そこのパン屋さんはすごくおいしくて、経歴もすごいです。昔あった「TVチャンピオン」というテレビ番組で優勝したことがある方が運営されているところで。
「ここのパン屋さんすごくおいしんだよ！ なぜならカレーパンがおいしくてね」みたいな、熱量のある推薦によって、ほかの人にいいお店をたくさん知ってほしい。そういったところをベースにしたサービスを運営しています。
Go To Eatキャンペーンはどういうものだったか？
みなさんも見たことがあるんじゃないかと思いますが、今日はGo To Eatキャンペーンの話をします。Go To Eatキャンペーン、いろいろな出来事がありましたが、今回はプロジェクトマネジメントの勉強会ということで、そこに絞った話をできればと思います。
まず簡単に、「Go To Eatキャンペーンってどんなものだっけ？」から説明します。Go To Eatキャンペーンは実は2つあり、Rettyが参画したのはそのうちの1つの、オンライン飲食に関するものです。
Rettyのようなオンライン飲食予約機能を提供するサイトを通じ、飲食店に予約して来店すると、それに応じて飲食で使えるクーポン、ポイントを付与するものです。
例えば、ランチだったら1人500円、ディナーだったら1人1000円。4人で行ったらまとめて4,000円みたいな。それを2回目以降のネット予約のときに使ってもらって、そのクーポン分だけ国がお金をサポートするというキャンペーンです。
こういったポイント、クーポンを付与することによって、コロナが落ち着いたあとでみなさんがまた飲食を楽しむようになって、それによってコロナ禍で苦しんだ飲食業界が支えられれば、助けになればということで始めたものになります。
Go To Eatキャンペーンのプロジェクト規模
このGo To Eatキャンペーンは、コロナが始まってしばらくしてからニュースなどで見聞きする人もあったのではと思いますが、はじめに「これくらいの規模のプロジェクトだったんだよ」ということを知ってもらったほうが話に入りやすいかと思うので、紹介します。
私は開発のマネージャーなのでエンジニアの数になりますが、Rettyでは最大、一番忙しいときで26名のエンジニアが携わっていました。社内のエンジニア数はマネージャーなども含めて40名くらいなので、ほぼ全員といえるような体制です。
開発期間は3ヶ月から4ヶ月ぐらいです。実際にキャンペーンが始まったのは2020年の10月1日からですが、私たちの準備は5月の半ばぐらいから行なっていました。
こちらに開発項目をあげています。すごくたくさんの開発項目がありました。見えるところだと、例えばキャンペーンページを用意して、お店で予約をするときに、ネット予約の機能解説する必要があります。例えば「クーポンがもらえます」とか、「いくらもらえます」「対象店舗です」みたいなものです。また、そのクーポンを使う仕組みも入れないといけません。
それ以外に、お店に対しては、例えば「これくらいクーポン立て替えました」「これくらいクーポンを使う客がこれから行きます」と。さらにそのお店にも、「Go To Eatキャンペーン参加しますか？ しませんか？」と確認する必要があります。
その際には、例えば「どこにお金を振り込めばいいでしょうか？」みたいな、そういう仕組みを全部これから作る必要がありました。
Go To Eatキャンペーンのプロジェクトの難しさ
そんなプロジェクトの難しさを、短く3つにまとめてみました。まず1つ目が、スケジュールが最優先です。私たちもこのキャンペーンをやることは知っていましたが、実はいつからかがわからなかったんです。いつ始まるかわからないけど、準備はしておかないといけない。
なぜなら、「やりたい」と言ってどの業者でもできるわけではなくて、審査があります。審査のときに「間に合いません。ちょっと遅れます」となると、弾かれてしまうかもしれないとか。
キャンペーン全体の予算枠が決まっているので、早く参加した業者がたくさん使ってしまったら、減ってしまうかもしれない。そういうところもあり、「始まりが明確になったら、すぐに開始できるように準備しておきたい」と、スケジュール最優先でした。
スケジュール最優先でありながら、コロナの感染状況や要件や、新しくわかった事実に基づいて、「こういうふうに感染症対策をとります」などによって、仕様が日々変わっていきました。
さらに、開発や企画だけでは閉じず、ステークホルダーが多岐に渡ります。開発、企画以外に、例えばお店さんに周知するための営業や、新規の参加の店舗を募るためにも、営業に動いてもらいました。
支払いのときには経理のサポートも必要ですし、実際にクーポンがもらえなかった、もらえた、使い方がわからない場合には、カスタマーサポートの人も巻き込んで動いてもらう必要があります。
アクション1：情報を1ヶ所に集める
そんな難しい中で、どうやって解決したのかです。今回このプロジェクトをちゃんと完遂するために、例えば誰か1人が全体を把握してマネジメントする、WBSを引くやり方では、きっと破綻してしまうだろうと考えていて。メンバーが自律して動ける仕組みを整備することに注力しました。
このあと紹介する5つを工夫してやることで、メンバーが自律して動ける仕組みを実際にやりました。少しずつ紹介していきます。
具体的なアクション5つです。まず1つ目です。今回のプロジェクトを始めるにあたり、情報をとにかく1ヶ所に集めるように、かつ、集めた情報は社内の誰であってもオープンに見られるようにしました。
具体的にどういうことかというと、弊社では今メールではなく、Slackで社内の情報を管理しています。Go To Eat開発チャンネル、Go To Eat全体チャンネル、Go To Eat経理チャンネルではなく、Go To Eatチャンネルは1個だけあり、すべてそこでやりとりする。
そのため、やりとりが抜けていたり、「どこで話したかな？」というものがありません。必ず1つ。議事録もGo To Eat開発議事録、Go To Eat企画議事録ではなく、Google Docを使い、1ファイルの追記型でとにかく書いていきました。
決まったこと、設計資料も Googleスプレッドシートの1ファイルで、社内でQ&Aをまとめた結果や画面のUI、あとはキャンペーン上、守らなければいけない仕様、要件などが全部整理されていました。
ステークホルダー間で会議することもありました。弊社はGoogle Meetを使っていますが、ROM専、聞き専オーケーにしました。ステークホルダーは当然顔を出して話もしますが、ちょっと興味がある、今どんな状況かを知りたい人は、聞きながら仕事できるようにしました。
これによって、どこになにがあるか探すのが簡単だし、必要であれば経緯も追える。あとはステークホルダー、責任者が判断するときにも「こういう情報に基づいて判断したんだな」ということが、ちゃんとたどれるようにしました。すべてオープンにする、1ヶ所にまとめるところが、まず1つ目の工夫です。
アクション2：初期ミーティングを高頻度で実施する
2つ目です。実際に開発を始めるにあたり、初期ミーティングをすごく頻度高く実施しました。「大きいプロジェクトやります」と言うと、よく「じゃあ開発合宿でみんなで集まってやるぞ！ おー！」と言って、1日や2日でプロジェクトキックオフ合宿などをやったことがある方もいるかと思います。
“リモートだから”は置いておいて、今回、違うやり方をしてみようと思ったのは、けっこう大きいプロジェクトで、要件も複雑で、やることも多岐に渡る。「合宿をして、濃度高く話をしたら、すべてわかるんだっけ？」というと、けっこう怪しいんじゃないかなと思ったんです。
そのため、毎日夕方、1時間固定でとって、頻度高くやりましょう、と。1時間話をして、持って帰って、その翌日の同じ時間までにそれぞれの頭の中で、「あれ、これってどういうことなんだろう？」「これって話したっけ？」「ここすごく心配だな」と整理してもらって、また翌日話す。とにかく頻度高く話をしました。
さらにここで開発だけではなく、企画、カスタマーサポートなども含めて、キャンペーンが始まったら具体的にどういう問題が起きるかについてすごく丁寧に話しました。例えば「お店が間違った予約処理をしちゃったらどうしよう」とか、「お客さんがお店に現れなかったらどうしよう」「サービスが落ちたらどうしよう」とかです。
そういった話を1個1個、すべて指差し確認することによって、開発者だけじゃなく、企画も、カスタマーサポートも、営業も、関係する人がちゃんと挙動をわかるように整理してから開発に着手しました。
アクション3：プロジェクト全体の進め方をそろえる
3つ目です。プロジェクト全体の進め方をそろえました。アプリもあれば、 Webもある。toB向け、レストラン向けのシステムもあり、どこから作っていきましょうか、と。当然、もともとの持ち場所があるので、みんな一斉に作れはしますが、会社として、プロジェクトとしてリスクが大きい順に着手することを明言しました。
Rettyにとって今回一番チャレンジングだったのは、お金に絡むクーポンのところ。ここがリスクヘッジできていないと、ほかがどんなに早く開発できていても、キャンペーンが始められません。
その次が、キャンペーン申し込みとお店への支払い管理です。クーポンを配ったはいいけれど、辻褄が合っていないと大変な事故になってしまうので、リスクが高いと思いました。それから最後にキャンペーンの訴求です。「リスクが高い順ってこういうのだよね」と社内でちゃんと話をして、その順番にやりました。
さらに、例えば同じメディア開発であっても、利用者の多い順、例えば「スマホを優先しましょう」「iOSアプリを優先しましょう」と最初に明言して、プロジェクト全体として、部分的にでも始められるように、みんなで意識をそろえました。「それぞれの持ち場はあるけれど、持ち場を越えて協力し合ってきましょう」というところは、きちんと明確に謳っています。
アクション4：決定はチームに委ねる
4つ目です。決定はできる限りチームに委ねました。こういった事前の共有があることで、それぞれが判断に必要な情報をきちんともっているはずです。そうであれば、決めなければいけないことを、開発責任者の私や、プロジェクトの責任者に相談するのではなく、できるだけチーム、実担当者に決めてほしい、どんどん進めてほしい。
これは私がSlackで投稿した、実際の文面のキャプチャです。今回のプロジェクトはリリース時期が最重要で、それでもやはり不確定なところがあり、ある程度見切りで進めなきゃいけない。
手戻りがあったら当然工数がかさみますが、それはみんなのせいではなく、開発責任者の私のせいである。そのうえで、ある程度決めなきゃいけない時期が来たものは、自分たちの判断で進めてほしい。
それでも、どうしてもステークホルダー間で決められないものがあったら私が決めるので、必ずエスカレーションしてね。エスカレーションを受けたらちゃんと私が責任をとるので、エスカレーションなしであとで燃やすのはやめてね、というお願い。
プロジェクト終わってから見ると、こういったお願いをするの当たり前だと思うかもしれませんが、きちんと明言して伝えました。
アクション5：進捗の表示を工夫する
5番目、進捗の表示です。すごくシンプルですが、横軸が時間、縦軸が開発規模で見積もりをしたポイントになっていす。バーンアップチャートで示しました。
オレンジ色が、実際に開発が終わったものです。プロジェクトが終わるまでにやらなければいけないこと、それに対して少しバッファも積んだものが、薄い青です。この矢印の傾きによって、プロジェクトがいつぐらいに終わるかが、だいたいわかるようになっています。
オレンジと青が交差したところが、プロジェクトの終了です。これを見ると、最初はゆっくり開発が始まって、途中から加速したのが誰が見てもパッと見でわかるようになっているかと思います。
全体で示したことによって、全社で今開発状況がどうなのか、進捗がどうなのかをわかりやすく示しました。これは当然toB向けのもの、toC向けのもの、アプリのものなどいろいろありましたが、とにかく合同で規模を見積もって、ここでは値の正確性は求めませんでした。
ちゃんと全体として、全プロジェクトとしてどうなの？ 進捗どうなの？ が、ちゃんと見えるところにフォーカスをさせています。
さらにこの図を使って、「ちょっとまだスピードが出ていませんが、これからこういう挽回策でスピード上がります。大丈夫です。」「リスクが高いところをやっているから、ちょっとまだ進捗出ていません」といったところを、丁寧に社内の関係メンバーやステークホルダーにフォローすることで、開発の初期の頃で焦って足並みが乱れてしまうところを止めることを実際に動いていました。
Go To Eatキャンペーンのプロジェクトの結果
その結果になります。まずプロジェクト自体の成否ですが、このキャンペーンを主管する、農林水産省側の準備状況を見ながら進められました。当初はけっこう厳しい納期だなと思っていて、残業や休日時出勤も避けられないかと思っていましたが、ほぼ発生することなく終えられました。
リスクが高いところから開発を開始しましたが、序盤にそこを潰しておいたおかげで、後半になるにしたがってスピードが出るようになりました。実際に一番忙しかったのは、7月の上旬と8月の下旬です。プロジェクトの締め切りギリギリですごく忙しいのではなく、かなり余裕をもって終えられました。
メンバーが実際に自律して動けたのかというと、こんな事例があります。キャンペーン途中で仕様変更があるときにも、メンバー主体で調整して迅速に対処できました。例えば、「ランチとディナーでクーポンの金額を変えてください」とか、「人数がたくさんだと感染拡大するかもしれないので上限を加えましょう」とか。
こういったときにも、例えば連絡をもらって「こういう仕様変更が入ります」「どこを直さなきゃいけませんね」「誰が動きましょう」「いつ直しましょう」といった話がメンバー間で主体的に進んで、その日のうちにはだいたい「では、ここ直せばいいです」「スケジュールには影響ありません」といった確認が取れるようになりました。
リリース後に起きたこととして、問い合わせが急に増えたり、負荷が増えたりと大変なことはありましたが、ここも最初に全社でちゃんと意識をそろえていたおかげで、きちんと順序立てて対処することで、それほど大きな問題にならずに乗り切れています。
Go To Eatキャンペーンのプロジェクトの2つの反省点
反省を2つあげます。まず1つ目が、“経験しておけばこういうことも起こり得たかな”ということを想像しておくのは大事だと思いました。今回だったら「このキャンペーンルールなら、みんなこんなふうに動くよね」という話だったり。
今回はCSなどにけっこう負荷がかかってしまいましたが、もう少しわかっていたら、いろいろな対策が取れたよね、というところですね。このあたりは、プロジェクトの経験を組織にちゃんと植えつけていかないといけないなとは思っています。
もう1つ、プロジェクト全体感の共有です。プロジェクトの全部の情報を1ヶ所全部集めて把握はしやすかったと思いますが、理解しやすかったかというと、やはりまたそれは違う問題だと思います。
全体感を押さえつつ、気になるなら簡単に調べられるようにはまだまだできていないので、ここは課題かなと思っています。
自律して動ける仕組みでプロジェクトは成功する
本日の私の発表、最後まとめです。スケジュール最優先、要件・仕様が変わる、ステークホルダーが多い、複雑な難しいプロジェクトだとみなさん思われると思います。ここでメンバーが自律して動ける仕組み5つを整備することで、無事に、成功裡に終われました。
プロジェクトの学びを組織に蓄積していく動きはまだまだこれから課題もあるので、世の中のみなさん、飲食業界のみなさんに価値が届けられるように、今後も引き続きがんばっていきます。以上で私の発表を終わります。ありがとうございました。
