2020年8月19日に開催した「BASE PM meetup #1 -リモート下でのMove Fastなプロダクトマネジメント -」の登壇資料です。 https://base.connpass.com/event/184712/
© 2012-2020 BASE, Inc. 1#1BASE PM meetupリモート化でのMove FastなプロダクトマネジメントMeetUp
View Slide
© 2012-2020 BASE, Inc. 2テイクアウトという異質な新機能をなぜ素早く出すことができたのか？
© 2012-2020 BASE, Inc. 3BASE株式会社 Product Division Product Management麻雀とジンギスカンが好き。2013年にLINE株式会社へ入社し、toBの営業・事業企画・マーケティングを担当。2018年初頭に退社後、複数スタートアップにてエンジニア・事業企画を経て、2018年12月にBASE株式会社に入社。Eコマースプラットフォーム「BASE」の企画・ディレクションを担当。PM歴は2年目大内田 喜一 （おおうちだ よしかず）自己紹介：経歴
© 2012-2020 BASE, Inc. 4なぜBASEに？- 人生への関与度が大きいか？薄く・広くではなく、深い課題解決をしたい。- ターゲットの課題解決難易度は高いか？自分たちが解決しないと、当事者では難しい問題を解決したい。- 事業内容に共感できるか？個人のエンパワーメントをしたい。市場性があると思っていたし、身近な知人に困っている人が多かった。
© 2012-2020 BASE, Inc. 5BASEのプロダクト開発基本機能 拡張機能（BASE Apps）全てのオーナーに影響する機能 特定のユースケースを解決する拡張機能社内制作App パートナー制作Appテイクアウト オプション Appify AYATORIなど など
© 2012-2020 BASE, Inc. 6テイクアウト商品の販売と事前決済をBASEのネットショップ上で可能にするもの。コロナを機に深い課題を抱えた飲食店オーナーさんをより強くサポートしたいと考え6月にリリース。テイクアウト Appとはそもそも何か購入者 オーナー
© 2012-2020 BASE, Inc. 7とある日の1on1（緊急事態宣言中）そもそもどういうきっかけだったか飲食店の課題に対して、もっと何かできないかな？テイクアウトとか含めて、ちょっと考えてみようか。マネージャー 大内田（me）
© 2012-2020 BASE, Inc. 8とある日の1on1（緊急事態宣言中）そもそもどういうきっかけだったかEC以外もやりたいですね。BASEとしてはだいぶ異質ですが、やる／やら含めて考えてます！マネージャー 大内田（me）飲食店の課題に対して、もっと何かできないかな？テイクアウトとか含めて、ちょっと考えてみようか。
© 2012-2020 BASE, Inc. 9とある日の1on1（緊急事態宣言中）そもそもどういうきっかけだったかおkです！（え、今週あと2日じゃんw）マネージャー 大内田（me）今週までに方針だして、開発キックオフしよう。EC以外もやりたいですね。BASEとしてはだいぶ異質ですが、やる／やら含めて考えてます！飲食店の課題に対して、もっと何かできないかな？テイクアウトとか含めて、ちょっと考えてみようか。
© 2012-2020 BASE, Inc. 10今後の飲食ビジネスのあるべき姿から逆算。やることを決意。Eat in + 3つのポートフォリオの追加非対面領域ポートフォリオの追加ツールのバンドリングの必要性購入者・オーナー共に利用するツールが異なる煩雑さテイクアウト(A社)デリバリー(B社)EC(C社)EC テイクアウト デリバリー 購入者 オーナー
© 2012-2020 BASE, Inc. 11これまでのBASEとは異質な機能をスピーディーにリリース従来のBASEは物販で横断型のAppのみをリリースしてきたが、全く異なるテイクアウトを約半分程度でリリース。どのようなことをかんがえ、リリースしていったか。商品形態 カテゴリ 企画期間 開発／QA 期間通常のApp 物販 横断型 約10営業日 約50営業日テイクアウト サービス 特化型（飲食のみ） 約2営業日 約30営業日
© 2012-2020 BASE, Inc. 12どうして早くだせたのか？- 社内カルチャー- 多くのリリース・改善の中でプロダクトを作ってきた鶴岡が代表であることで、素早く出すことへの理解がある。BASEの行動指針にもMove Fastがある。- プロダクトの性質- Appという性質上、既存サービスと切り離して考えられることが多いので出しやすい。- 開発体制の強化- PM業務- 「いつ」出したいかにこだわる- メインストーリーだけ決めて、サブストーリー（メイン予備軍）はTBDとして開発中のPM検証タスクにする。
© 2012-2020 BASE, Inc. 13どうして早くだせたのか？- 社内カルチャー- 多くのリリース・改善の中でプロダクトを作ってきた鶴岡が代表であることで、素早く出すことへの理解がある。BASEの行動指針にもMove Fastがある。- プロダクトの性質- Appという性質上、既存サービスと切り離して考えられることが多いので出しやすい。- 開発体制の強化- PM業務- 「いつ」出したいかにこだわる- メインストーリーだけ決めて、サブストーリー（メイン予備軍）はTBDとして開発中のPM検証タスクにする。
© 2012-2020 BASE, Inc. 14どうして早くだせたのか？- 社内カルチャー- 多くのリリース・改善の中でプロダクトを作ってきた鶴岡が代表であることで、素早く出すことへの理解がある。BASEの行動指針にもMove Fastがある。- プロダクトの性質- Appという性質上、既存サービスと切り離して考えられることが多いので出しやすい。- 開発体制の強化- PM業務- 「いつ」出したいかにこだわる- メインストーリーだけ決めて、サブストーリー（メイン予備軍）はTBDとして開発中のPM検証タスクにする。
© 2012-2020 BASE, Inc. 15プロダクトのリリース時期はどうやって決めていますか？
© 2012-2020 BASE, Inc. 16プロダクトのリリース時期はどうやって決めていますか？- 通常課題の特定→解決策の選定→工数見積というプロセスで、リリース時期を決めていた。要するに、必要な機能を開発するのに必要な時間。
© 2012-2020 BASE, Inc. 17いつ必要なのかに応える- 今回課題の特定→いつまでに出す必要があるか？→解決策の選定、というプロセスで行った。コロナウイルス 顧客（飲食店） 政府来年まで長引く寄りの論調 サービスモデルの転換が急務 非対面事業への支援
© 2012-2020 BASE, Inc. 18いつ必要なのかに応える- 今回課題の特定→いつまでに出す必要があるか？→解決策の選定、というプロセスで行った。コロナウイルス 顧客（飲食店） 政府来年まで長引く寄りの論調 サービスモデルの転換が急務 非対面事業への支援→期限は、1ヶ月。(=4月末要件定義、6月上旬リリース目処）
© 2012-2020 BASE, Inc. 19「いつ」にこだわったことで。- 「最低限の仕様」というものを考えざるを得なくなる- （これまでもそうしてきたつもりだけれど）より研ぎ澄まして考えるように。- 他のPJでも、来月リリースするとしたら何を捨てられるか？という問いは常にあっても良いかもしれない。- この仕様いらないかな？っていう質問をメンバーからたくさん受ける- 初期リリースからスペックアウトした仕様がたくさんありました。zoomやドキュメントを通して納得感ある形で現状の仕様になった背景はその都度認識を合わせたが、断り続けるのにも信念と忍耐力が必要だなと思った。 （途中で自信がなくなっていく..）
© 2012-2020 BASE, Inc. 20どうして早くだせたのか？- 社内カルチャー- 多くのリリース・改善の中でプロダクトを作ってきた鶴岡が代表であることで、素早く出すことへの理解がある。BASEの行動指針にもMove Fastがある。- プロダクトの性質- Appという性質上、既存サービスと切り離して考えられることが多いので出しやすい。- ディレクション- 「いつ」出したいかにこだわる- メインストーリーだけ決めて、サブストーリー（メイン予備軍）はTBDとして開発中のPM検証タスクにする。
© 2012-2020 BASE, Inc. 21期限を決めたら何をしたか？- 企画時間の効率化ミニマムな仕様を速やかに構築し、PMのプロセスを効率化できないかと思った。通常、課題特定→要件定義のプロセスにおおよそ2w-3wかけていた。 どこにどんな時間がかかってるんだろう？ PMデザイナーエンジニア課題特定 要件定義 実装・他社調査・定性調査・定量調査・仮説の立案・ワイヤー作成・仕様の整理／絞込・要件定義書の作成 ・要件の共有・開発進行管理・ステークホルダー対応・ワイヤー作成・作り込み・工数見積もり ・開発・テスト
© 2012-2020 BASE, Inc. 22時間を要する理由を探る- 定性調査：顧客ヒアリング（顧客選定・スケジューリング・ヒアリングのプロセス）- 定量調査：社内データ分析や、アンケート調査（調査設計・配信面調整・回収期間・分析）PMデザイナーエンジニア課題特定 要件定義 実装・他社調査・定性調査・定量調査・仮説の立案・ワイヤー作成・仕様の整理／絞込・要件定義書の作成・要件の共有 ・開発進行管理・ステークホルダー対応・ワイヤー作成・作り込み・工数見積もり ・開発・テスト
© 2012-2020 BASE, Inc. 23開発とパラレルで検証できるユーザーストーリーに時間を費やしていた課題の深さ対象の多さ？メインのユーザーストーリー（①）は早めに決めやすい（＝なぜなら共通項を採用するので）が、②や④の可能性が高そうだが①になる可能性がある、メイン予備軍の調査に時間かけていたことが多かった。①②③ ④※①＝Day1、②④がDay2以降のユーザーストーリー？
© 2012-2020 BASE, Inc. 24開発とパラレルで検証できるユーザーストーリーに時間を費やしていた課題の深さ対象の多さ？メインのユーザーストーリー（①）は早めに決めやすい（＝なぜなら共通項を採用するので）が、②や④の可能性が高そうだが①になる可能性がある、メイン予備軍の調査に時間かけていたことが多かった。→一定数の定性調査でメインのユーザーストーリを決めたタイミングで、①の要件定義／開発着手と②④の検証をパラレルで進行した。※②④が①になる可能性については予めメンバーに共有し設計上のリスクは減らすこと。①②③ ④※①＝Day1、②④がDay2以降のユーザーストーリー？
© 2012-2020 BASE, Inc. 25Before / AfterPMデザイナーエンジニア- 全体の企画に要する時間は変わらないが、メイン予備軍の検証をパラレルで進めることで開発着手タイミングが早まり、結果リリースを早められた。 PMがボトルネックになる時間を短縮した。- ただし、設計の出戻りがないような密なコミュニケーションが必ず必要。PMデザイナーエンジニアtBefore（フロー） After（パラレル）t課題特定課題特定メイン要件定義メイン課題特定予備軍検証要件定義予備軍検証UI/UX予備→メイン開発予備→メインUI/UXメイン開発メイン要件定義UI/UX開発
© 2012-2020 BASE, Inc. 26学び、伝えたかったこと（なぜ早くリリースできたか？）- 「いいものを早く」ではなく、「いつ」リリースする必要があるのかを先に決める。ユーザーに必要な機能→どれくらいかかるか？というステップも重要だが、それに加えて「いつまでに必要なのか」も同じぐらい重要。 ※国の政策、顧客、社会（コロナ）、他社状況などの観点。- メインストーリーを素早く定義・開発着手し、メイン予備軍は開発とパラレルで検証していく。ただし、エンジニアとデザイナーとの事前の密なコミュニケーションが必須。 ※「いつ」が急務ではない場合はそこまで重要ではないかもしれない。
© 2012-2020 BASE, Inc. 27UXの底上げによく効く、日々の細かい改善の進め方
© 2012-2020 BASE, Inc. 28BASE株式会社 Product Division Product Management2017年にフラー株式会社へエンジニアとして入社。webアプリケーションの開発を担当。2018年末からディレクター職に転向し、モバイルアプリの企画・ディレクションを行う。2019年9月にBASE株式会社に入社、Eコマースプラットフォーム「BASE」の企画・ディレクションを担当。打楽器が好き。船坂 拓海 （ふなさか たくみ）自己紹介：経歴
© 2012-2020 BASE, Inc. 29● 自社サービスを作りたい○ 新卒で入った会社でクライアントワークを経験したので、事業会社でPM（またはディレクター）を経験したかった● サービスを愛せる○ 過去に自分のiPhoneの１ページ目にアプリアイコンが並んだことがある企業から候補を選んでいた● 人○ 一緒に働くことになる人をとにかく重要視して会社を選んでいた○ 会社を見学したときに、優しい人が多い会社な気がした○ 採用面接で話した神宮司さんはじめPMの人たちと波長があったBASEに入ったきっかけ素敵なPMメンバーズ
© 2012-2020 BASE, Inc. 30こんなこと思い当たらないですか？さっそくですが
© 2012-2020 BASE, Inc. 31● プロダクトを作っていると、無限にでてくる、課題、課題、課題.....○ そこかしこから発生する○ 把握はできていない● いつやるの？○ 今ではなくない？になりがち● 誰やるの？○ それだけのためにプロジェクト化する判断も実際難しい積まれっぱなしの課題・タスク
© 2012-2020 BASE, Inc. 32積まれっぱなしの課題・タスクそこで......● プロダクトを作っていると、無限にでてくる、課題、課題、課題.....○ そこかしこから発生する○ 把握はできていない● いつやるの？○ 今ではなくない？になりがち● 誰やるの？○ それだけのためにプロジェクト化する判断も実際難しい
© 2012-2020 BASE, Inc. 33● 正式名称は「PJ化されないような粒度の細かい改善を行うPJ」● 目的：現在のプロダクトが抱える課題の中から、改善することでオーナーのためになるものをなるべく多く実行していく● プロジェクトメンバー○ PM：１人○ デザイナー：３人○ エンジニア：３人○ とはいえ、増えたり減ったり● 開始４ヶ月でリリース済みが４つ / 現在進行中のものが５つ細かい改善プロジェクト
© 2012-2020 BASE, Inc. 34細かい改善プロジェクト：改善例１● 「納品書ダウンロード App」のアップデート○ もともとのBASEとして不足していた機能○ 課題■ お届け先と購入者が異なる注文の納品書で、購入者の情報のみが印刷される○ 改善内容■ 納品書にお届け先と購入者の情報を記載する。■ 情報の追加に伴い、レイアウトの変更■ フォントを見やすいものに変更納品書ダウンロード App
© 2012-2020 BASE, Inc. 35● 注文一覧や商品一覧のスクロール位置を保持する○ 課題■ 一覧→詳細をクリック→一覧へ戻る、のような動きをすると、その都度スクロール位置がリセットされていた■ 頻繁に行う作業なので、都度行うスクロールがかなり面倒○ 改善内容■ ユーザーの導線として多いと想定できる移動パターンにおいて、スクロール位置を保持するように変更細かい改善プロジェクト：改善例２
© 2012-2020 BASE, Inc. 36課題のプールを作る課題の優先度を判断メンバーのアサイン解決策を考える（要件定義、仕様策定）開発QA・リリース細かい改善プロジェクトの全体の流れ
© 2012-2020 BASE, Inc. 37課題のプールを作る課題の優先度を判断メンバーのアサイン解決策を考える（要件定義、仕様策定）開発QA・リリース細かい改善プロジェクトの全体の流れ
© 2012-2020 BASE, Inc. 38● 細かい改善PJでターゲットになるかもしれない課題を、あらゆるところから集める○ お問い合わせ○ CX（ショップフォロー）チームの担当ショップからの要望○ CSチームにヒアリング○ 過去のアンケート調査○ 社内QAフィードバックの積み残し○ 改めて社内に聞いてみる● 一覧できる場所にまずは全てを集める→○ miro（オンラインホワイトボードツール）にすべて記録○ 並べたら、プロジェクトメンバーみんなで眺めながら工数感やモチベーションを把握課題のプールを作る
© 2012-2020 BASE, Inc. 39課題のプールを作る課題の優先度を判断メンバーのアサイン解決策を考える（要件定義、仕様策定）開発QA・リリース細かい改善プロジェクトの全体の流れ
© 2012-2020 BASE, Inc. 40● 評価の軸は大きく３つ○ 課題の重さ■ どれだけ困る？■ 影響をうけているショップ数■ 各種KPIへのインパクト■ どれだけの時間が奪われているか○ 今やらなければ負債になる？■ このプロジェクトでも拾えなかった課題は、当分寝かされる可能性がある■ 長期的な視点で見て、課題を評価する○ 今いるメンバーでどれだけ早く出せる？■ メンバーのスキルセットとのマッチ具合課題の優先度を判断
© 2012-2020 BASE, Inc. 41課題の優先度を判断最近のSNSのアカウントの情報を載せられるようにしたい一覧画面のスクロールがいちいちリセットされる納品書にギフトの際にお届け先が記載されない特定のページのUIパーツが古い例
© 2012-2020 BASE, Inc. 42課題の優先度を判断最近のSNSのアカウントの情報を載せられるようにしたい一覧画面のスクロールがいちいちリセットされる納品書にギフトの際にお届け先が記載されない特定のページのUIパーツが古いこのとき考えること● 大きな課題感は今はないが、アクセスの多いページ● 今後、更に大きな課題を生むことが想定される● 今抱えているリソースで取り組む意義がある● 現時点での課題感：大● 今抱えているリソースで取り組むことができる● 「納品書ダウンロード App」を使っているショップが多く、インパクトが大きい● 会社として進めていく方針● 現時点での課題感は小さい● 工数は多い● 広い範囲から要望を受けた● 発生頻度が高い● すぐに解決できる
© 2012-2020 BASE, Inc. 43課題の優先度を判断最近のSNSのアカウントの情報を載せられるようにしたい一覧画面のスクロールがいちいちリセットされる納品書にギフトの際にお届け先が記載されない特定のページのUIパーツが古い①② ③④このとき考えること● 大きな課題感は今はないが、アクセスの多いページ● 今後、更に大きな課題を生むことが想定される● 今抱えているリソースで取り組む意義がある● 現時点での課題感：大● 今抱えているリソースで取り組むことができる● 「納品書ダウンロード App」を使っているショップが多く、インパクトが大きい● 会社として進めていく方針● 現時点での課題感は小さい● 工数は多い● 広い範囲から要望を受けた● 発生頻度が高い● すぐに解決できる
© 2012-2020 BASE, Inc. 44課題のプールを作る課題の優先度を判断メンバーのアサイン解決策を考える（要件定義、仕様策定）開発QA・リリース細かい改善プロジェクトの全体の流れ
© 2012-2020 BASE, Inc. 45● Move Fastにすすめるにはメンバーがモチベーションを持てることが必須● メンバー自身がやりたいことと重なり、当事者意識を持てるものをメンバーのアサイン
© 2012-2020 BASE, Inc. 46課題のプールを作る課題の優先度を判断メンバーのアサイン解決策を考える（要件定義、仕様策定）開発QA・リリース細かい改善プロジェクトの全体の流れ
© 2012-2020 BASE, Inc. 47● day1は小さく小さく切り出す○ 本当に必要な最低限の機能単位のみ● オーナーからの要望＝解決策ではない○ オーナーは自分が本当に欲しい機能はわからない○ 何ができるとオーナーが解決したかった課題が解決するのか？● 要件が決まったらデザイナーと一緒に仕様策定とワイヤー作成を同時に進めていく解決策を考える（要件定義、仕様策定）
© 2012-2020 BASE, Inc. 48課題のプールを作る課題の優先度を判断メンバーのアサイン解決策を考える（要件定義、仕様策定）開発QA・リリース細かい改善プロジェクトの全体の流れ
© 2012-2020 BASE, Inc. 49● 必要以上にリッチなプロジェクト体制をしかないように気をつける● 細かい改善のような小さな案件の場合、殆どのケースにおいて「システム化されたタスク管理」よりも「密なコミュニケーション＋最低限の進捗管理」のほうが効果的。○ 細かい改善の中でも比較的大きなものに関しては、チケットで開発進捗を追っている○ BASEの中では特殊。ほぼすべてのプロジェクトはしっかりと管理されている● Slackを止めない○ 何かあったらすぐ話す○ とはいえ集中モードに入ったクリエイター（デザイナー、エンジニア）の邪魔はできるだけしないように開発
© 2012-2020 BASE, Inc. 50課題のプールを作る課題の優先度を判断メンバーのアサイン解決策を考える（要件定義、仕様策定）開発QA・リリース細かい改善プロジェクトの全体の流れ
© 2012-2020 BASE, Inc. 51● QAのケース出しはPMが叩きを作る。（その方が早い）● チームメンバーにそれぞれの観点で不足しているケースを追記してもらう● 実際のQA作業はメンバーみんなで。QAは最高のコミュニケーションチャンス。○ 「ここバグがあるので直しておいてください」ではなく、○ 「うおお〜バグが出てしまった！辛い！一緒に頑張って直しましょう〜！」● リリース後は、その改善を待っていた人に伝えてあげることが大事。○ 課題・要望を伝えてくれたユーザーや社内チームなどQA・リリース
© 2012-2020 BASE, Inc. 52● 特殊な形のプロジェクトであるため、全員での共通目標が立てづらい上にメンバーがガンガン入れ替わる○ 週に一度の定例では進捗だけでなくこのプロジェクト以外での動きをヒアリング● プロジェクト全体で、「このプロジェクトから早くたくさんリリースする」ことを共通の目標として伝える。○ あっちも頑張れこっちも負けるな、イケイケGOGO、な雰囲気。Move Fast。● 各メンバーの主体性を大事に○ 常に「メンバーがやりたいこと」「メンバーができること」「メンバーにお願いしていること」の重なりが最大になるように意識● メンバー同士の距離が近づけば、だいたいうまくいく○ たくさんのラフなコミュニケーション、思いやり○ リモートワークの脅威はコミュニケーションミスによる部分が大きいチームづくり
© 2012-2020 BASE, Inc. 53● プロダクトサイドとビジネスサイドの距離がより縮まった○ ビジネスサイドから上がっていた要望を拾ってリリースという形で見せられる● 今までならその場で黙って飲み込んできたであろう小さな不満が埋もれなくなった○ パスする先が明確にあると、その場で伝えてくれるようになる社内にもこんな良いことが
© 2012-2020 BASE, Inc. 54● 細かい改善をする専門のプロジェクトを走らせてみた● 課題はそこかしこから集めて、みんなで評価してから優先度判断！● Move Fastにすすめるにはメンバーのアサインが大事。メンバーのモチベーションはどこにむいてるか？● リリースは小さく、早く● 共通の目標が作りにくいときは、「早くたくさん出す！」みたいな目標設定は意外とアリ○ それぞれの案件の目標設定は別途PMが意識するのは大前提● プロダクトサイドとビジネスサイドの距離が縮まったり、適切に要望が集まるようになった● 距離が近いチームはリモート下でも強いまとめ
© 2012-2020 BASE, Inc. 55
base
takmin
yu4u
leekwangsoo1995
goyoki
soracom
trycycle
spinscale
ymty
nenonaninu
hosimesi11
yuya4
iselegant
akosma
brad_frost
chriscoyier
sferik
reverentgeek
jcasabona
malarkey
bluesmoon
destraynor
sstephenson
jasonvnalue
ammeep