リモート下でスピーディにプロダクトをリリース・改善するには?「BASE PM meetup」イベントレポート

こんにちは!Recruiting Groupの高橋です!

今回は、「BASE PM meetup #1 - リモート下でのMove Fastなプロダクトマネジメント -」 と題して行われた、プロダクトマネージャー向けの会社説明会の様子を当日の資料を一部抜粋しながらレポートしていきます!

当日の登壇資料はこちらからご覧いただけます。


会社・サービスについて紹介

まずは、執行役員VP of Productの神宮司さんが会社・サービスの紹介や直近の新型コロナウイルスの事業への影響についてお話ししました。

f:id:aiyoneda:20200910121058p:plain
神宮司さんのプロフィール

神宮司:まず、最近ではショップ開設数、GMVとも急激に伸びている状態となっています。コロナの影響で開設されたオーナーさんだけでなく、過去に登録されたオーナーさんも、この時期にすごくアクティブになられて、GMVも伸びていきました。

f:id:aiyoneda:20200910121212j:plain

神宮司:ここからはBASEのカルチャーやプロダクト組織の体制やについてご紹介します。プロダクトBASEの行動指針として、「Move Fast」というものがあり、早く価値提供を行うため適切に役割分担をしています。

BASEのプロダクト組織は、Product Devという開発チームの組織と、Product DesignというUI/UXデザイン等を行う組織に分かれています。

f:id:aiyoneda:20200910121522j:plain

次のLTでは、このProduct Designの中のProduct Management Groupの2人から発表してもらいます。


PMによるLT

今回LTでは、おふたりにそれぞれ下記のタイトルで発表してもらいました!

「テイクアウトという異質な新機能をなぜ素早く出すことができたのか?」
「UXの底上げによく効く、日々の細かい改善の進め方」

それでは早速LTの内容にいってみましょう!

テイクアウトという異質な新機能をなぜ素早く出すことができたのか?

f:id:aiyoneda:20200910121643p:plain
大内田さんのプロフィール

大内田:6月25日に、ネットショップ作成サービス「BASE」の拡張機能である「BASE Apps」の1機能として、テイクアウトの事前注文/決済ができる「テイクアウト App」をリリースいたしました。僕はその開発プロジェクトのPMをやっていました。

まずそもそもBASEのプロダクト開発の全体像を、軽くお話しできたら思います。

f:id:aiyoneda:20200910122626j:plain

大内田:BASEのプロダクト開発には、全てのオーナーさんに影響する基本機能への開発と、特定のユースケースを解決する拡張機能「BASE Apps」の開発があります。テイクアウト Appは、「BASE Apps」の一つになります。

テイクアウト Appの具体的な機能についてはこちらになります。

f:id:aiyoneda:20200910123025p:plain
テイクアウト Appの概要

大内田:このテイクアウト Appが誕生したきっかけは、マネージャーとの1on1で、「コロナ禍で、EC以外で何かオーナーさんをサポートできないかな?」という提案が出たことがきっかけでした。

通常のAppは3ヶ月程度でリリースされます。しかしコロナ禍でお困りの事業者さんがたくさんいらっしゃる状況の中、テイクアウト Appを3ヶ月後にどんなに良い状態でリリースしても、オーナーさんに十分な価値提供ができないなという考えがありました。

その上でマネージャーと相談を重ね、まず先に「1ヶ月以内」というリリース期限を確定させ、テイクアウト Appの企画の検討に入りました。 

スピーディーにリリースするために、時間がかかっている箇所を探る

大内田:いつまでに?を決めたら次は「何を?」の部分になりますね。課題特定とリリース期間に合うミニマムな要件定義を行うのがPMの仕事です。

期限が1ヶ月と限られている中、どこのプロセスの時間を削ることができるか?と考えたときに、自分のPMの業務で削れる部分があるのではないかと思いました。

f:id:aiyoneda:20200910123212p:plain

大内田:今までのプロセスを見返してみると、「課題特定→要件定義」のところに平均的に2~3週間の時間を要していたことがわかりました。

課題特定の中で時間を使っていた箇所はどこか?

f:id:aiyoneda:20200910131952j:plain

大内田:なぜ、課題特定の段階で時間がかかってしまっていたのかを調べてみたところ、開発とパラレルで検証できるユーザーストーリーに時間を費やしていたことがわかりました。

f:id:aiyoneda:20200910132037j:plain

大内田:そこで、メインのユーザーストーリを確定できたタイミングで、要件定義/開発着手を先に進めてしまい、図の②④の部分に関しては初期リリースに入れるべきか現時点で判断が難しいため、事前にエンジニアとデザイナーへ共有した上で、パラレルで検証していく方針をとるようにしました。

この方針により、開発着手までにかかる時間を短縮しつつ、効率的な企画・開発を行うことができました。

改善前と改善後のフローをまとめると、以下のスライドのようになります。

f:id:aiyoneda:20200910132116j:plain

まとめ 学び、伝えたかったこと

大内田:今回のLTのまとめになりますが、必要な機能からスケジュールを決めるのではなく「いつリリースするのか?」を先に厳しく決めることで、最低限必要な要件に対する開発にフォーカスすることができました。

もう1点は、メインのユーザーストーリーを素早く定義し開発に着手しつつ、まだメインかわからない部分に関してはパラレルで検証することで、効率的かつスピーディな企画・開発を行うことができました。


以上が、大内田さんからのLTになります。

続いては、船坂さんのLTです!


UXの底上げによく効く、日々の細かい改善の進め方

f:id:aiyoneda:20200910132222p:plain
船坂さんは自身が運営する事業に専念するため2020年8月末で退職されましたが、イベントレポートの掲載を快諾してくれました!

船坂:皆さま、今日はよろしくお願いいたします。皆さまはプロダクト作りに携わる中で、このような状況になったことはありませんか?

f:id:aiyoneda:20200910132319j:plain

船坂:BASEでもこのような状況がありました。そこで発足したのが、「プロジェクト化されないような粒度の細かい改善を行うプロジェクト」です。

長くて変な名前のプロジェクトなのですが(笑)このプロジェクトは、名前の通り日々の細かい改善をガンガンやっていくプロジェクトです。

f:id:aiyoneda:20200910132347j:plain

船坂:長くプロダクトを運営していると、プロダクトには無限に改善したいポイントが出てきますよね。まずはそ改善ポイントを、細かいものでも徹底的に集めます。

集めたら、以下のスライドの流れで改善を進めていきます。

f:id:aiyoneda:20200910132423j:plain

船坂:課題の優先度の付け方などは、PMであれば一度は悩むと思います。

今回のプロジェクトは評価軸を主に3つ決めて、優先度の判断をしやすくしました。

f:id:aiyoneda:20200910132500j:plain

船坂:この細かい改善プロジェクトを進めた結果、「プロダクトサイドとビジネスサイドの距離がより縮まった」「今までならその場で黙って飲み込んできたであろう小さな不満が埋もれなくなった」といった良い点もありました。

チームづくりやモチベーションも大切に

船坂:プロジェクトをMove Fastにすすめるにはメンバーがモチベーションを持てることが必須だと思うので、僕が意識していたチームづくりや、メンバーのモチベーションについてもお伝え出来たらと思います。

メンバーのアサインにおいては、メンバー自身がやりたいことと重なり、当事者意識を持てる役割を割り当てることを意識しました。また、このプロジェクトはメンバーの入れ替わりが多かったので、主にコミュニケーションを増やすことを意識していました。

f:id:aiyoneda:20200910132551j:plain

まとめ 学び、伝えたかったこと

船坂:今回のLTのまとめると下記になります。

f:id:aiyoneda:20200910135540p:plain


以上が、船坂さんからのLTになります。

ここからパネルディスカッションに移ります。


パネルディスカッション

Product Managementマネージャーの山田さんをファシリテーター、神宮司さん、大内田さん、船坂さんをパネリストとしてお話ししてもらいました。

ここでは、事前に参加者の方にお答えいただいたアンケートに回答していく形で進めました。レポートでは当日取り上げたテーマの中からいくつかに絞ってご紹介していきます。

f:id:aiyoneda:20200910135358p:plain

リモート下でのプロジェクトの進め方、工夫しているポイント

山田:BASEではコロナ禍になるまでリモートの経験はなかったので、知見はない状態でした。その中で、どのようにプロジェクトを動かしていたのか、聞いていきたいと思います。

大内田:リモートワークでは、雑談と対面でのコミュニケーションが無くなったことで、認識齟齬のリスクがあるのではないかと感じました。

ですので、なにげない内容もアクセスのしやすいストック型のドキュメントにする、何か話がある際はプロジェクトのSlackチャンネル内でZoomを立てて誰でも参加できるようにする、Zoomミーティングの際はリアルタイムで画面共有しながら議事録をとる、といったことを意識していました。

船坂:僕は、キックオフの段階でそのプロジェクトの雰囲気は決まると思うので、オンラインであってもなごやかで楽しい雰囲気を大切にしましたね。

神宮司:ほとんどSlackでコミュニケーションをとることが多いのですが、例えば障害が起きた時など、緊急性が高く重要度の高い話題についてはチャットではなくZoomで即座に話せるようにしました。

PMの職責(PdMとPjM要素どちらを求められるのか)

神宮司:今のBASEでは、PdM(プロダクトマネージャー)とPjM(プロジェクトマネージャー)の両方を担っているという感じです。プロジェクトによっても、粒度は結構異なります。

現状では、プロジェクトのメンバーは大体10人もいかないくらいの規模なので、PdMとPjMを同一人物にすることがほとんどなのですが、大規模なプロジェクトで開発設計の難易度が高い場合は、開発ディレクターを入れて、精度向上などを行う場合もあります。

デザイナーやエンジニアとの役割分担、それぞれの責任範囲

山田:具体的なプロジェクトの経験から、このあたりをどのようにしているか伺っても良いですか?

船坂:僕は基本的には専門家であるエンジニア、デザイナーに任せていて、一部、コーディングやデザインで壁打ち相手になることがありますね。プロジェクト内容によっては、UXを検討するためにワイヤーは自分が叩きで作ることもあります。

大内田:デザインとエンジニアリングの「How」の部分に関しては、僕よりもエンジニアやデザイナーの方が良いものができると思っているので、僕は、誰のどんな課題をどういう状態にしたいのか?というところに対してきちんと調査しドキュメントに起こす、進行管理とKPI管理をするというところにフォーカスしています。


イベントレポートは以上です!

Product Managementグループのミッションは、「BASE」に関係する全てのユーザーを対象に、ユーザーがどのような課題をもち、どのような解決方法が最適なのかを考え抜いてプロダクトを作り続け、素敵な価値をつくっている方々がその価値に合ったしっかりとした対価を受け取ることができる未来をつくることです。

ミッションに向かってPMが普段行っているマネジメントの業務を、少しでもお伝えできましたら幸いです。

BASEではPMを積極的に募集しています!募集は下記よりご覧ください。

BASE_プロダクトマネジメント - BASE株式会社

BASE_プロダクトマネジメント※マネージャー候補 - BASE株式会社

INFORMATION

BASEの最新情報やエンジニアをはじめとした
メンバーのインタビュー動画は以下の媒体でも発信しています。

RECRUIT

BASEでは、価値の交換が最適化された未来を
ともに実現するメンバーを探しています。