Tweet
Tweet

Slide 1

Slide 1 text

© 2012-2020 BASE, Inc. 1 #1 BASE PM meetup リモート化でのMove Fastな プロダクトマネジメント MeetUp

Slide 2

Slide 2 text

© 2012-2020 BASE, Inc. 2 テイクアウトという異質な新機能を なぜ素早く出すことができたのか？

Slide 3

Slide 3 text

© 2012-2020 BASE, Inc. 3 BASE株式会社 Product Division Product Management 麻雀とジンギスカンが好き。 2013年にLINE株式会社へ入社し、toBの営業・事業企画・マーケティングを担当。 2018年初頭に退社後、複数スタートアップにてエンジニア・事業企画を経て、 2018年12月にBASE株式会社に入社。Eコマースプラットフォーム「BASE」の企画・ ディレクションを担当。PM歴は2年目 大内田 喜一 （おおうちだ よしかず） 自己紹介：経歴

Slide 4

Slide 4 text

© 2012-2020 BASE, Inc. 4 なぜBASEに？ - 人生への関与度が大きいか？ 薄く・広くではなく、深い課題解決をしたい。 - ターゲットの課題解決難易度は高いか？ 自分たちが解決しないと、当事者では難しい問題を解決したい。 - 事業内容に共感できるか？ 個人のエンパワーメントをしたい。 市場性があると思っていたし、身近な知人に困っている人が多かった。

Slide 5

Slide 5 text

© 2012-2020 BASE, Inc. 5 BASEのプロダクト開発 基本機能 拡張機能（BASE Apps） 全てのオーナーに影響する機能 特定のユースケースを解決する拡張機能 社内制作App パートナー制作App テイクアウト オプション Appify AYATORI など など

Slide 6

Slide 6 text

© 2012-2020 BASE, Inc. 6 テイクアウト商品の販売と事前決済をBASEのネットショップ上で可能にするもの。 コロナを機に深い課題を抱えた飲食店オーナーさんをより強くサポートしたいと考え6月にリリース。 テイクアウト Appとはそもそも何か 購入者 オーナー

Slide 7

Slide 7 text

© 2012-2020 BASE, Inc. 7 とある日の1on1（緊急事態宣言中） そもそもどういうきっかけだったか 飲食店の課題に対して、もっ と何かできないかな？ テイクアウトとか含めて、 ちょっと考えてみようか。 マネージャー 大内田（me）

Slide 8

Slide 8 text

© 2012-2020 BASE, Inc. 8 とある日の1on1（緊急事態宣言中） そもそもどういうきっかけだったか EC以外もやりたいですね。 BASEとしてはだいぶ異質で すが、やる／やら含めて考え てます！ マネージャー 大内田（me） 飲食店の課題に対して、もっ と何かできないかな？ テイクアウトとか含めて、 ちょっと考えてみようか。

Slide 9

Slide 9 text

© 2012-2020 BASE, Inc. 9 とある日の1on1（緊急事態宣言中） そもそもどういうきっかけだったか おkです！（え、今週あと2日 じゃんw） マネージャー 大内田（me） 今週までに方針だして、開発 キックオフしよう。 EC以外もやりたいですね。 BASEとしてはだいぶ異質で すが、やる／やら含めて考え てます！ 飲食店の課題に対して、もっ と何かできないかな？ テイクアウトとか含めて、 ちょっと考えてみようか。

Slide 10

Slide 10 text

© 2012-2020 BASE, Inc. 10 今後の飲食ビジネスのあるべき姿から逆算。やることを決意。 Eat in + 3つのポートフォリオの追加 非対面領域ポートフォリオの追加 ツールのバンドリングの必要性 購入者・オーナー共に利用するツールが異なる煩雑さ テイクアウト(A社) デリバリー(B社) EC(C社) EC テイクアウト デリバリー 購入者 オーナー

Slide 11

Slide 11 text

© 2012-2020 BASE, Inc. 11 これまでのBASEとは異質な機能をスピーディーにリリース 従来のBASEは物販で横断型のAppのみをリリースしてきたが、全く異なるテイクアウトを約半分程度でリリース。 どのようなことをかんがえ、リリースしていったか。 商品形態 カテゴリ 企画期間 開発／QA 期間 通常のApp 物販 横断型 約10営業日 約50営業日 テイクアウト サービス 特化型（飲食のみ） 約2営業日 約30営業日

Slide 12

Slide 12 text

© 2012-2020 BASE, Inc. 12 どうして早くだせたのか？ - 社内カルチャー - 多くのリリース・改善の中でプロダクトを作ってきた鶴岡が代表であることで、素早く出すことへの理解があ る。BASEの行動指針にもMove Fastがある。 - プロダクトの性質 - Appという性質上、既存サービスと切り離して考えられることが多いので出しやすい。 - 開発体制の強化 - PM業務 - 「いつ」出したいかにこだわる - メインストーリーだけ決めて、サブストーリー（メイン予備軍）はTBDとして開発中のPM検証タスクにする。

Slide 13

Slide 13 text

© 2012-2020 BASE, Inc. 13 どうして早くだせたのか？ - 社内カルチャー - 多くのリリース・改善の中でプロダクトを作ってきた鶴岡が代表であることで、素早く出すことへの理解があ る。BASEの行動指針にもMove Fastがある。 - プロダクトの性質 - Appという性質上、既存サービスと切り離して考えられることが多いので出しやすい。 - 開発体制の強化 - PM業務 - 「いつ」出したいかにこだわる - メインストーリーだけ決めて、サブストーリー（メイン予備軍）はTBDとして開発中のPM検証タスクにする。

Slide 14

Slide 14 text

© 2012-2020 BASE, Inc. 14 どうして早くだせたのか？ - 社内カルチャー - 多くのリリース・改善の中でプロダクトを作ってきた鶴岡が代表であることで、素早く出すことへの理解があ る。BASEの行動指針にもMove Fastがある。 - プロダクトの性質 - Appという性質上、既存サービスと切り離して考えられることが多いので出しやすい。 - 開発体制の強化 - PM業務 - 「いつ」出したいかにこだわる - メインストーリーだけ決めて、サブストーリー（メイン予備軍）はTBDとして開発中のPM検証タスクにする。

Slide 15

Slide 15 text

© 2012-2020 BASE, Inc. 15 プロダクトのリリース時期はどうやって決めていますか？

Slide 16

Slide 16 text

© 2012-2020 BASE, Inc. 16 プロダクトのリリース時期はどうやって決めていますか？ - 通常 課題の特定→解決策の選定→工数見積というプロセスで、リリース時期を決めていた。 要するに、必要な機能を開発するのに必要な時間。

Slide 17

Slide 17 text

© 2012-2020 BASE, Inc. 17 いつ必要なのかに応える - 今回 課題の特定→いつまでに出す必要があるか？→解決策の選定、というプロセスで行った。 コロナウイルス 顧客（飲食店） 政府 来年まで長引く寄りの論調 サービスモデルの転換が急務 非対面事業への支援

Slide 18

Slide 18 text

© 2012-2020 BASE, Inc. 18 いつ必要なのかに応える - 今回 課題の特定→いつまでに出す必要があるか？→解決策の選定、というプロセスで行った。 コロナウイルス 顧客（飲食店） 政府 来年まで長引く寄りの論調 サービスモデルの転換が急務 非対面事業への支援 →期限は、1ヶ月。(=4月末要件定義、6月上旬リリース目処）

Slide 19

Slide 19 text

© 2012-2020 BASE, Inc. 19 「いつ」にこだわったことで。 - 「最低限の仕様」というものを考えざるを得なくなる - （これまでもそうしてきたつもりだけれど）より研ぎ澄まして考えるように。 - 他のPJでも、来月リリースするとしたら何を捨てられるか？という問いは常にあっても良いかもしれない。 - この仕様いらないかな？っていう質問をメンバーからたくさん受ける - 初期リリースからスペックアウトした仕様がたくさんありました。zoomやドキュメントを通して納得感ある形で 現状の仕様になった背景はその都度認識を合わせたが、断り続けるのにも信念と忍耐力が必要だなと思った。　 （途中で自信がなくなっていく..）

Slide 20

Slide 20 text

© 2012-2020 BASE, Inc. 20 どうして早くだせたのか？ - 社内カルチャー - 多くのリリース・改善の中でプロダクトを作ってきた鶴岡が代表であることで、素早く出すことへの理解があ る。BASEの行動指針にもMove Fastがある。 - プロダクトの性質 - Appという性質上、既存サービスと切り離して考えられることが多いので出しやすい。 - ディレクション - 「いつ」出したいかにこだわる - メインストーリーだけ決めて、サブストーリー（メイン予備軍）はTBDとして開発中のPM検証タスクにする。

Slide 21

Slide 21 text

© 2012-2020 BASE, Inc. 21 期限を決めたら何をしたか？ - 企画時間の効率化 ミニマムな仕様を速やかに構築し、PMのプロセスを効率化できないかと思った。 通常、課題特定→要件定義のプロセスにおおよそ2w-3wかけていた。　どこにどんな時間がかかってるんだろう？　 PM デザイナー エンジニア 課題特定 要件定義 実装 ・他社調査 ・定性調査 ・定量調査 ・仮説の立案 ・ワイヤー作成 ・仕様の整理／絞込 ・要件定義書の作成　 ・要件の共有 ・開発進行管理 ・ステークホルダー対応 ・ワイヤー作成 ・作り込み ・工数見積もり ・開発 ・テスト

Slide 22

Slide 22 text

© 2012-2020 BASE, Inc. 22 時間を要する理由を探る - 定性調査：顧客ヒアリング（顧客選定・スケジューリング・ヒアリングのプロセス） - 定量調査：社内データ分析や、アンケート調査（調査設計・配信面調整・回収期間・分析） PM デザイナー エンジニア 課題特定 要件定義 実装 ・他社調査 ・定性調査 ・定量調査 ・仮説の立案 ・ワイヤー作成 ・仕様の整理／絞込 ・要件定義書の作成 ・要件の共有　 ・開発進行管理 ・ステークホルダー対応 ・ワイヤー作成 ・作り込み ・工数見積もり ・開発 ・テスト

Slide 23

Slide 23 text

© 2012-2020 BASE, Inc. 23 開発とパラレルで検証できるユーザーストーリーに時間を費やしていた 課題の深さ 対象の多さ ？ メインのユーザーストーリー（①）は早めに決めやすい（＝なぜなら共通項を採用するので）が、 ②や④の可能性が高そうだが①になる可能性がある、メイン予備軍の調査に時間かけていたことが多かった。 ① ② ③ ④ ※①＝Day1、②④がDay2以降の ユーザーストーリー ？

Slide 24

Slide 24 text

© 2012-2020 BASE, Inc. 24 開発とパラレルで検証できるユーザーストーリーに時間を費やしていた 課題の深さ 対象の多さ ？ メインのユーザーストーリー（①）は早めに決めやすい（＝なぜなら共通項を採用するので）が、 ②や④の可能性が高そうだが①になる可能性がある、メイン予備軍の調査に時間かけていたことが多かった。 →一定数の定性調査でメインのユーザーストーリを決めたタイミングで、①の要件定義／開発着手と②④の検証を パラレルで進行した。※②④が①になる可能性については予めメンバーに共有し設計上のリスクは減らすこと。 ① ② ③ ④ ※①＝Day1、②④がDay2以降の ユーザーストーリー ？

Slide 25

Slide 25 text

© 2012-2020 BASE, Inc. 25 Before / After PM デザイナー エンジニア - 全体の企画に要する時間は変わらないが、メイン予備軍の検証をパラレルで進めることで開発着手タイミングが早 まり、結果リリースを早められた。　PMがボトルネックになる時間を短縮した。 - ただし、設計の出戻りがないような密なコミュニケーションが必ず必要。 PM デザイナー エンジニア t Before（フロー） After（パラレル） t 課題特定 課題特定 メイン 要件定義 メイン 課題特定 予備軍検証 要件定義 予備軍検証 UI/UX 予備→メイン 開発 予備→メイン UI/UX メイン 開発 メイン 要件定義 UI/UX 開発

Slide 26

Slide 26 text

© 2012-2020 BASE, Inc. 26 学び、伝えたかったこと（なぜ早くリリースできたか？） - 「いいものを早く」ではなく、「いつ」リリースする必要があるのかを先に決める。 ユーザーに必要な機能→どれくらいかかるか？というステップも重要だが、それに加えて「いつまでに必要なのか」 も同じぐらい重要。　※国の政策、顧客、社会（コロナ）、他社状況などの観点。 - メインストーリーを素早く定義・開発着手し、メイン予備軍は開発とパラレルで検証していく。 ただし、エンジニアとデザイナーとの事前の密なコミュニケーションが必須。　※「いつ」が急務ではない場合はそ こまで重要ではないかもしれない。

Slide 27

Slide 27 text

© 2012-2020 BASE, Inc. 27 UXの底上げによく効く、 日々の細かい改善の進め方

Slide 28

Slide 28 text

© 2012-2020 BASE, Inc. 28 BASE株式会社 Product Division Product Management 2017年にフラー株式会社へエンジニアとして入社。 webアプリケーションの開発を担当。 2018年末からディレクター職に転向し、モバイルアプリの企画・ディレクションを 行う。 2019年9月にBASE株式会社に入社、Eコマースプラットフォーム「BASE」の企画・ ディレクションを担当。 打楽器が好き。 船坂 拓海 （ふなさか たくみ） 自己紹介：経歴

Slide 29

Slide 29 text

© 2012-2020 BASE, Inc. 29 ● 自社サービスを作りたい ○ 新卒で入った会社でクライアントワークを経験したので、事業会社でPM（またはディレクター）を経験したかっ た ● サービスを愛せる ○ 過去に自分のiPhoneの１ページ目にアプリアイコンが並んだことがある企業から候補を選んでいた ● 人 ○ 一緒に働くことになる人をとにかく重要視して会社を選んでいた ○ 会社を見学したときに、優しい人が多い会社な気がした ○ 採用面接で話した神宮司さんはじめPMの人たちと波長があった BASEに入ったきっかけ 素敵なPMメンバーズ

Slide 30

Slide 30 text

© 2012-2020 BASE, Inc. 30 こんなこと思い当たらないですか？ さっそくですが

Slide 31

Slide 31 text

© 2012-2020 BASE, Inc. 31 ● プロダクトを作っていると、無限にでてくる、課題、課題、課題..... ○ そこかしこから発生する ○ 把握はできていない ● いつやるの？ ○ 今ではなくない？になりがち ● 誰やるの？ ○ それだけのためにプロジェクト化する判断も実際難しい 積まれっぱなしの課題・タスク

Slide 32

Slide 32 text

© 2012-2020 BASE, Inc. 32 積まれっぱなしの課題・タスク そこで...... ● プロダクトを作っていると、無限にでてくる、課題、課題、課題..... ○ そこかしこから発生する ○ 把握はできていない ● いつやるの？ ○ 今ではなくない？になりがち ● 誰やるの？ ○ それだけのためにプロジェクト化する判断も実際難しい

Slide 33

Slide 33 text

© 2012-2020 BASE, Inc. 33 ● 正式名称は「PJ化されないような粒度の細かい改善を行うPJ」 ● 目的：現在のプロダクトが抱える課題の中から、改善することでオーナーのためになるものをなるべく多く実行し ていく ● プロジェクトメンバー ○ PM：１人 ○ デザイナー：３人 ○ エンジニア：３人 ○ とはいえ、増えたり減ったり ● 開始４ヶ月でリリース済みが４つ / 現在進行中のものが５つ 細かい改善プロジェクト

Slide 34

Slide 34 text

© 2012-2020 BASE, Inc. 34 細かい改善プロジェクト：改善例１ ● 「納品書ダウンロード App」のアップデート ○ もともとのBASEとして不足していた機能 ○ 課題 ■ お届け先と購入者が異なる注文の納品書で、購入者の情報のみが 印刷される ○ 改善内容 ■ 納品書にお届け先と購入者の情報を記載する。 ■ 情報の追加に伴い、レイアウトの変更 ■ フォントを見やすいものに変更 納品書ダウンロード App

Slide 35

Slide 35 text

© 2012-2020 BASE, Inc. 35 ● 注文一覧や商品一覧のスクロール位置を保持する ○ 課題 ■ 一覧→詳細をクリック→一覧へ戻る、のような動きをすると、その都度スクロール位置がリセットされていた ■ 頻繁に行う作業なので、都度行うスクロールがかなり面倒 ○ 改善内容 ■ ユーザーの導線として多いと想定できる移動パターンにおいて、スクロール位置を保持するように変更 細かい改善プロジェクト：改善例２

Slide 36

Slide 36 text

© 2012-2020 BASE, Inc. 36 課題のプールを作る 課題の優先度を判断 メンバーのアサイン 解決策を考える（要件定義、仕様策定） 開発 QA・リリース 細かい改善プロジェクトの全体の流れ

Slide 37

Slide 37 text

© 2012-2020 BASE, Inc. 37 課題のプールを作る 課題の優先度を判断 メンバーのアサイン 解決策を考える（要件定義、仕様策定） 開発 QA・リリース 細かい改善プロジェクトの全体の流れ

Slide 38

Slide 38 text

© 2012-2020 BASE, Inc. 38 ● 細かい改善PJでターゲットになるかもしれない課題を、あらゆるところから集める ○ お問い合わせ ○ CX（ショップフォロー）チームの担当ショップからの要望 ○ CSチームにヒアリング ○ 過去のアンケート調査 ○ 社内QAフィードバックの積み残し ○ 改めて社内に聞いてみる ● 一覧できる場所にまずは全てを集める→ ○ miro（オンラインホワイトボードツール）にすべて記録 ○ 並べたら、プロジェクトメンバーみんなで眺めながら 工数感やモチベーションを把握 課題のプールを作る

Slide 39

Slide 39 text

© 2012-2020 BASE, Inc. 39 課題のプールを作る 課題の優先度を判断 メンバーのアサイン 解決策を考える（要件定義、仕様策定） 開発 QA・リリース 細かい改善プロジェクトの全体の流れ

Slide 40

Slide 40 text

© 2012-2020 BASE, Inc. 40 ● 評価の軸は大きく３つ ○ 課題の重さ ■ どれだけ困る？ ■ 影響をうけているショップ数 ■ 各種KPIへのインパクト ■ どれだけの時間が奪われているか ○ 今やらなければ負債になる？ ■ このプロジェクトでも拾えなかった課題は、当分寝かされる可能性がある ■ 長期的な視点で見て、課題を評価する ○ 今いるメンバーでどれだけ早く出せる？ ■ メンバーのスキルセットとのマッチ具合 課題の優先度を判断

Slide 41

Slide 41 text

© 2012-2020 BASE, Inc. 41 課題の優先度を判断 最近のSNSのアカウント の情報を載せられるように したい 一覧画面のスクロールが いちいちリセットされる 納品書にギフトの際に お届け先が記載されない 特定のページのUIパーツが 古い 例

Slide 42

Slide 42 text

© 2012-2020 BASE, Inc. 42 課題の優先度を判断 最近のSNSのアカウント の情報を載せられるように したい 一覧画面のスクロールが いちいちリセットされる 納品書にギフトの際に お届け先が記載されない 特定のページの UIパーツが古い このとき考えること ● 大きな課題感は今はないが、 アクセスの多いページ ● 今後、更に大きな課題を生む ことが想定される ● 今抱えているリソースで取り 組む意義がある ● 現時点での課題感：大 ● 今抱えているリソースで取り 組むことができる ● 「納品書ダウンロード App」 を使っているショップが多 く、インパクトが大きい ● 会社として進めていく方針 ● 現時点での課題感は小さい ● 工数は多い ● 広い範囲から要望を受けた ● 発生頻度が高い ● すぐに解決できる

Slide 43

Slide 43 text

© 2012-2020 BASE, Inc. 43 課題の優先度を判断 最近のSNSのアカウント の情報を載せられるように したい 一覧画面のスクロールが いちいちリセットされる 納品書にギフトの際に お届け先が記載されない 特定のページの UIパーツが古い ① ② ③ ④ このとき考えること ● 大きな課題感は今はないが、 アクセスの多いページ ● 今後、更に大きな課題を生む ことが想定される ● 今抱えているリソースで取り 組む意義がある ● 現時点での課題感：大 ● 今抱えているリソースで取り 組むことができる ● 「納品書ダウンロード App」 を使っているショップが多 く、インパクトが大きい ● 会社として進めていく方針 ● 現時点での課題感は小さい ● 工数は多い ● 広い範囲から要望を受けた ● 発生頻度が高い ● すぐに解決できる

Slide 44

Slide 44 text

© 2012-2020 BASE, Inc. 44 課題のプールを作る 課題の優先度を判断 メンバーのアサイン 解決策を考える（要件定義、仕様策定） 開発 QA・リリース 細かい改善プロジェクトの全体の流れ

Slide 45

Slide 45 text

© 2012-2020 BASE, Inc. 45 ● Move Fastにすすめるにはメンバーがモチベーションを持てることが必須 ● メンバー自身がやりたいことと重なり、当事者意識を持てるものを メンバーのアサイン

Slide 46

Slide 46 text

© 2012-2020 BASE, Inc. 46 課題のプールを作る 課題の優先度を判断 メンバーのアサイン 解決策を考える（要件定義、仕様策定） 開発 QA・リリース 細かい改善プロジェクトの全体の流れ

Slide 47

Slide 47 text

© 2012-2020 BASE, Inc. 47 ● day1は小さく小さく切り出す ○ 本当に必要な最低限の機能単位のみ ● オーナーからの要望＝解決策ではない ○ オーナーは自分が本当に欲しい機能はわからない ○ 何ができるとオーナーが解決したかった課題が解決するのか？ ● 要件が決まったらデザイナーと一緒に仕様策定とワイヤー作成を同時に進めていく 解決策を考える（要件定義、仕様策定）

Slide 48

Slide 48 text

© 2012-2020 BASE, Inc. 48 課題のプールを作る 課題の優先度を判断 メンバーのアサイン 解決策を考える（要件定義、仕様策定） 開発 QA・リリース 細かい改善プロジェクトの全体の流れ

Slide 49

Slide 49 text

© 2012-2020 BASE, Inc. 49 ● 必要以上にリッチなプロジェクト体制をしかないように気をつける ● 細かい改善のような小さな案件の場合、殆どのケースにおいて「システム化されたタスク管理」よりも「密なコ ミュニケーション＋最低限の進捗管理」のほうが効果的。 ○ 細かい改善の中でも比較的大きなものに関しては、チケットで開発進捗を追っている ○ BASEの中では特殊。ほぼすべてのプロジェクトはしっかりと管理されている ● Slackを止めない ○ 何かあったらすぐ話す ○ とはいえ集中モードに入ったクリエイター（デザイナー、エンジニア）の邪魔はできるだけしないように 開発

Slide 50

Slide 50 text

© 2012-2020 BASE, Inc. 50 課題のプールを作る 課題の優先度を判断 メンバーのアサイン 解決策を考える（要件定義、仕様策定） 開発 QA・リリース 細かい改善プロジェクトの全体の流れ

Slide 51

Slide 51 text

© 2012-2020 BASE, Inc. 51 ● QAのケース出しはPMが叩きを作る。（その方が早い） ● チームメンバーにそれぞれの観点で不足しているケースを追記してもらう ● 実際のQA作業はメンバーみんなで。QAは最高のコミュニケーションチャンス。 ○ 「ここバグがあるので直しておいてください」ではなく、 ○ 「うおお〜バグが出てしまった！辛い！一緒に頑張って直しましょう〜！」 ● リリース後は、その改善を待っていた人に伝えてあげることが大事。 ○ 課題・要望を伝えてくれたユーザーや社内チームなど QA・リリース

Slide 52

Slide 52 text

© 2012-2020 BASE, Inc. 52 ● 特殊な形のプロジェクトであるため、全員での共通目標が立てづらい上にメンバーがガンガン入れ替わる ○ 週に一度の定例では進捗だけでなくこのプロジェクト以外での動きをヒアリング ● プロジェクト全体で、「このプロジェクトから早くたくさんリリースする」ことを共通の目標として伝える。 ○ あっちも頑張れこっちも負けるな、イケイケGOGO、な雰囲気。Move Fast。 ● 各メンバーの主体性を大事に ○ 常に「メンバーがやりたいこと」「メンバーができること」「メンバーにお願いしていること」の重なりが最大 になるように意識 ● メンバー同士の距離が近づけば、だいたいうまくいく ○ たくさんのラフなコミュニケーション、思いやり ○ リモートワークの脅威はコミュニケーションミスによる部分が大きい チームづくり

Slide 53

Slide 53 text

© 2012-2020 BASE, Inc. 53 ● プロダクトサイドとビジネスサイドの距離がより縮まった ○ ビジネスサイドから上がっていた要望を拾ってリリースという形で見せられる ● 今までならその場で黙って飲み込んできたであろう小さな不満が埋もれなくなった ○ パスする先が明確にあると、その場で伝えてくれるようになる 社内にもこんな良いことが

Slide 54

Slide 54 text

© 2012-2020 BASE, Inc. 54 ● 細かい改善をする専門のプロジェクトを走らせてみた ● 課題はそこかしこから集めて、みんなで評価してから優先度判断！ ● Move Fastにすすめるにはメンバーのアサインが大事。メンバーのモチベーションはどこにむいてるか？ ● リリースは小さく、早く ● 共通の目標が作りにくいときは、「早くたくさん出す！」みたいな目標設定は意外とアリ ○ それぞれの案件の目標設定は別途PMが意識するのは大前提 ● プロダクトサイドとビジネスサイドの距離が縮まったり、適切に要望が集まるようになった ● 距離が近いチームはリモート下でも強い まとめ

Slide 55

Slide 55 text

© 2012-2020 BASE, Inc. 55