リクルートのプロジェクトから学ぶ!大規模プロジェクトでの注意点!
はじめまして、細野です。
今回は過去にあった「ホットペッパーグルメ」と「レストランボード」というリクルートの持つプロダクトの予約管理機能を共通化するという大規模なプロジェクトのマネージャーを担当した柴田さんにインタビューしました。
大規模なプロジェクトにおいてもミスや停滞が発生しないようにできるような参考になるポイントがたくさんあったので、皆様にもぜひ共有できればと思います!
はじめに:プロジェクトの概要
リクルートには「ホットペッパーグルメ」と「レストランボード」という飲食店の予約を管理するためのサービスが2つ存在しています。
ホットペッパーグルメで受け付けた予約とレストランボードで受け付けた予約をそれぞれ別々に管理しなければならず、利用店舗にとって操作が煩雑な部分がありました。
これらを統合することで、店舗が一元管理できるようにするのが、今回のプロジェクトでした。
柴田さんはそのプロジェクトマネージャーとして、本件に参加していました。
統合に際してのこだわり
2つのプロダクトにまたがり、機能を統合することに際してこだわった部分は、なによりも店舗が「これまでと同じように予約業務ができる」ことでした。
「機能の統合に際して、この際だからより便利なものを作ろう、という空気がはじめはありましたが、最終的には元々の機能をこれまで通り利用できることに注力することにしました」と柴田さん。
これまでと同じモノを作るという難しさ
空席などの予約在庫の設定画面などは、これまでとほぼ同じような見た目にすることにこだわって開発しました。
また、使用感を理解してもらえるように利用者向けのFAQの作成も行いました。
ドキュメント量は膨大で、ページ数で言えば600ページ程度、FAQ記事自体も200記事に及び、特に現場の営業などにヒヤリングしつつ、どのような情報が必要かを常に精査しながら、作成しました。
例えば、操作方法の動画や資料もipadなどだけではなく、全ての端末ごとに作成してどの店舗にもわかりやすくすることにこだわりました。
それはすでに「ホットペッパーグルメ」の利用者は我々の想像するよりも多く、業態も多様化しており、リテラシーも様々な中で全員がこれまで通りに利用ができるようにとこだわった部分です。
資料の作成に関しては各飲食店の営業担当の方々からも意見をもらいました。
資料のレビューや機能のレビューに参加してもらい、大規模な開発の中でも細かい修正が発生しないように心がけました。
結果的にこの取り組みは現場の方々の意見が開発内容にダイレクトに影響するということになり、営業のメンバーのモチベーションにもなったと思います。
時代に応じて必要要件が変わる難しさ
それでも、このコロナの影響で当初の想定から大きく要件が変更されることもありました。
昨今の緊急事態宣言などの影響で店舗は月ごと、あるいは週毎に休業となったり、営業時間を変更しなければならず、その都度予約在庫を操作する必要が発生しました。
今回のプロジェクトはコロナ以前から進んでおり、コロナが流行するころには大部分の開発が完了している状況でした。
そのため、コロナによる飲食店への影響を考慮しきれずリリースを迎えてしまいました。
リリース後に機能の重要さに気づいて急いで対応したものの、大きなプロジェクトは時間がかかるからこそ、対応している間に社会情勢が変化することもあります。
なので定期的に「この要件でよかったのか?」とメンテナンスすることが重要だと感じました。
最後に
大型のプロジェクトは参加者が多い分、情報の伝達が特に重要になります。
誤った情報を伝えすると、それらの修正に時間を取られ、プロジェクトの進みが悪くなります。
なので、情報の確認には徹底しました。
また、プロジェクトが長期間だったこともあり、メンバーの入れ替わりも発生していました。
そのため、過去の誰かが決めたことを自分が進めないといけない場合もありました。
その際過去の決定に納得できない部分があったとしても、ただ過去を否定するのではなく、「当時の状況ではこれが最適な判断だった」と過去を認めた上で、どう進めるか検討することを心がけました。
大規模な開発だからこそ、店舗にも、メンバーにもそういった思いやりが大事なのかもしれないですね。
みなさんも、今後の自分の取り組みの際にはぜひ参考にしてみてください!
それでは!