Go To Eatキャンペーンを支えた
 プロジェクトマネジメント
 常松祐一
 2021/3/13


自己紹介
 ● 常松祐一 (つねまつ ゆういち) 
 ○ Engineering Manager 
 ○ Software Engineering Coach 
 ○ Agile Development
 ● SNSアカウント
 ○ tunepolo : 
 ○ tune : 
 
 ● 顧客にとって価値のあるプロダクトを、チーム一丸 となって協力し、短期間にリリースする開発体制の あり方を模索しています。 


3 自分にとってBESTなお店が見つかる 
 日本最大級の"実名型"グルメサービス
 レビューよりもレコメンド。 
 Rettyは他人におすすめしたい 
 美味しいお店を投稿するサービス！ 
 食の好みは人それぞれ。 
 自分と嗜好が合う人をフォローして、 
 BESTなお店を見つけられるSNS型！ 
 実名制の口コミだからこそ 
 「信頼できる」「ポジティブ」な 
 情報が集まっています！ 
 批評ではなくオススメの口コミ 
 自分と好みが近い人から探せる 
 顔が見えて信頼できる実名制 


Go To Eatキャンペーン


※農水省キャンペーンページより転載 https://gotoeat.maff.go.jp/ Go To Eatキャンペーンの概要


プロジェクト規模
 ● 携わったエンジニア数 : 26名
 ● 開発期間 : 3〜4ヶ月
 ● 開発項目
 ○ [toC]キャンペーンページの用意
 ○ [toC]キャンペーンの仕組みに合わせたネット予約の改修
 ○ [toB]ポイントの管理・発行・消化
 ○ [toB]お店からのキャンペーン申し込み画面
 ○ [toB]お店側がみる管理画面の修正。来店確認・支払管理など
 ・・・とにかく”たくさん”


プロジェクトの難しさ
 ● スケジュール最優先
 ● 要件・仕様が日々変わりうる
 ● 全社が関係、ステークホルダーが多い。
 ○ 開発・企画・営業・経理・CS
 Photo by Christian Erfurt on Unsplash

メンバーが自律して動ける仕組みを整備
 Photo by Hannah Busing on Unsplash ● 情報を一箇所に集めオープンにする
 ● 初期ミーティングを頻度高く実施
 ● プロジェクト全体の進め方を揃える
 ● 決定はできる限りチームに委ねる
 ● 進捗は全体のバーンアップチャートで示す


具体的なアクション


情報を一箇所に集めオープンにする
 ● Slackのチャンネルは1つ。
 ● 議事録はGoogle Docで1ファイル。
 ● 設計資料はGoogle Spreadsheet 1ファイル。
 ● 会議(Google Meet)はROM専OK、気になる人は参 加できる。
 ● →探すことが簡単、経緯が追いやすい。どんな情報 に基づいて判断したかも知ろうと思えばできる。


初期ミーティングを頻度高く実施
 ● プロジェクト開始後は毎日1時間ミーティングを設定
 ○ 半日・1日でまとめてやるより、考え直す時間を設けた方が見落 としが減ると考えた。
 ○ 具体的な実装に入る前にユースケースを洗い出し、データの流 れ・システムの挙動を十分に話した


プロジェクト全体の進め方を揃える
 ● リスクが大きい順に着手
 ○ クーポン管理→キャンペーン申し込み・支払管理→メディア (Web/アプリ)キャンペーン訴求
 ● メディア側開発は利用者の多いスマホWeb・iOSを優先
 ○ キャンペーン開始が早まった場合に部分的にでも始められるよ うに。
 ● toCよりもtoB、AndroidよりもiOSを優先し、専門・持ち場を超えて協 力して欲しいことを明確にした


決定はできる限りチームに委ねる
 ● 必要な情報は十分共有・話せているはず。
 ● 決定は開発チーム・実装担当者に基本委ねる。
 ● 決められないものはエスカレーションしてもらう。


進捗は全体のバーンアップチャートで示す
 縦軸は 開発工数 横軸は期間 ゴール(青)と 実績(オレンジ)を 折れ線で表現

進捗は全体のバーンアップチャートで示す
 ● プロジェクト全体に意識が向くようにグラフはまとめて1つ。バッファ は全体に対して50%を想定。
 ● 開発見積もりはWeb(toC) / アプリ / toBシステム合同で行い、規 模を相対で粗くつけた。値の正確性は求めなかった。
 ● 開発外との期待値調整は丁寧にフォローした。スピードが出てない ことは素直に認め、改善策があることを伝えるなどして焦りが開発 側に波及することを止める。


結果


結果1 - プロジェクト自体の成否
 ● 農水省側の準備状況を見ながら進めることができた。
 ○ 残業・休日出勤が避けられないと考えていたが、残業上限にひっか かった人もなく、休日出勤もプロジェクト全体で2人日のみ。
 ● 狙い通り後半になるに従って開発リスクが下がり、スピードが出るプロジェ クト推進ができた。
 ○ 7月上旬に1度目の負荷ピーク(toBシステムの開発佳境)
 ○ 8月下旬に2度目の負荷ピーク(全体を連結してのリリース前検証)


結果2 - メンバーは自律して動けたのか?
 ● 仕様変更が何度かあったが、メンバー主体で調整 し、迅速に対処できた。
 ○ 例) ランチとディナーでクーポン金額が変わる
 ○ 例) クーポンの付与上限が加わる


リリース後に起きたこと
 ● ユーザー問い合わせ数の急激な増加
 ● システム負荷の急激な増加
 ● キャンペーン予算消化のため11月上旬にクーポン付与が終了
 ● → 全社で優先順位を共有し、順次対処


反省 - 経験に基づく想像力の発揮
 ● リリース後に何が起きるか、もう少し想像できた気もする。
 ○ キャンペーンルールに基づくとどんなユーザー行動が増えるか
 ○ ユーザー問い合わせが増えたらどうなるか
 ○ キャンペーン終了が早まったらどうなるか
 ● 経験があれば想像を膨らませやすかったのかも。
 ○ プロジェクトで学んだことを個人でなく組織に蓄積していかないといけ ない。


反省 - プロジェクト全体感の共有
 ● 1箇所に情報を集めたが、プロジェクト全体感が把握しやすかったかは別 の話。
 ● 個人的には一人が隅々まで目を光らせて全てを把握することはできなかっ たと思う。
 ● 「全体感をなんとなく押さえ、持ち場に注力できる、気になるなら関連情報 は公開されているのでいつでも”簡単に”調べることができる」こんなのが 理想だけどなかなか難しい。


まとめ
 Photo by Hannah Busing on Unsplash ● スケジュール最優先 & 要件・仕様が変わる & ステー クホルダーの多いプロジェクトで「メンバーが自律して 動ける仕組みを整備」して対処
 ● プロジェクトの学びを組織に蓄積してく動きはこれか ら