駆け出しPOへの処方箋

f:id:hito-link:20190812153934j:plain

こんにちは、HITO-LinkプロダクトのスクラムマスターGo(@goyoko5)です。

今回は初投稿で紹介したプロダクト開発勉強会の中で「正しいものを正しくつくる」の著者である市谷 聡啓さんに質問し、回答いただいた内容を共有します。

全国の悩めるプロダクト開発チームの課題解決の手がかりになればいいなと思います。

 

チームの境界線上の球を落とさないようにする方法

プロダクトの関係人数が多く、特に境界が曖昧な事柄に関してはボールが宙に浮いてしまうことがある。
各チームの役割は全うしつつも割りきれない問題をうまく巻き取っていってもらえるようにするためにはどうしたら良いか?

回答

◇ 流通経路の作成

問題が流通する経路がないと問題自体が流通しないのでそれを作る。

◇ 朝会の構造化

1週間1回のリーダー会だと距離が長くなってしまうので、日々の朝会を構造化する。
各チームの朝会で問題を拾い上げる。その後、チームリーダーを集めた朝会で吸い上げた問題をおろす。これで問題が流通する経路ができる。

◇ チームの視座をあげる

やりたいやりたくないについては、別の作戦。チームの視座を高めていくことが必要、全チームでプロダクトを世の中へ届けていく広く使ってもらうというミッションがあるとおもうが減衰していく時期があるのでしめなおす必要がある。全体チームを集めて合宿をしたりしてミッションに向き合う時間が必要がある。
手段はインセプションデッキを作成したり、ゴールデンサークルを書いたりというのがある。
ミッション締め直しの中で自分たちは何をやっているのかを問う。
UXはUXだけ、開発は開発だけやってればいいのかを問い直す。

◇ どのくらいの頻度でやるとよいか?

チームの気持ち次第だが、1か月に1回など定期化するか、期間(タイムボックス)を設けて3か月は全チームのミッションとしてこれをおくぞ(ユーザーを+何%伸ばす)とか作戦を立て、振り返りしていくというのはあり。

◇ ダサさを認識する

こぼれ球なんて誰かがやらなきゃいけない。ほったらかしにしたってうまくいかないことはみんなわかっている。ダサさに気付く。それぞれ、そもそも何のために仕事をしているか問いなおしたほうがよい。

関係者が多い中でのビジョン・ミッションの作り方

共通のゴール(ビジョン・ミッション)ってどうやって作るのがいいのか。
メンバーが増えるに従ってどうしても全員が完全に納得できるものが出来ない時に、全員が納得できるものを作りあげるまで頑張るのか、多数決等で決めるのか。どちらが良いか。

回答

◇ミッションの構造化を行う

チームがすべての原動力があり、プロジェクトがあり、プロダクトがあり、事業があり、組織がある。それぞれで目的・ミッションがある。UXチームはUXチームの目的・ミッション、DevにはDevの目的・ミッションがある。これは各チームで考える。プロジェクトレイヤーで3か月で達成したいミッションはある。プロジェクトはプロダクトのミッションにつながり、プロダクトは事業は組織のミッションにつながる。

◇ 制約を使う

各ミッションは下位のミッションに対しての制約になる。構造を意識したうえでミッションをつくれば、各メンバーの好き嫌いを入れ込む余地はなくなってくるはず。

PO業務の分担の仕方

PO業務(要素の言語化、UIの方針決め、ビジネスモデルの設計)のタスクを洗い出したらすごく多くて、他の人に振ろうにも振れない状況。どのように打開するのがいいのか?
回答

◇ POの役割分担

UIの方針決めはデザイナー的な人、デザイナーよりのPO、ビジネスモデルのほうはプロダクトマネジャーというかビジネスよりのPOをたてるような役割分担をする。
その間で理解の不足や意思疎通に問題があるのであれば3人で仮説検証を進めていき、ユーザーとは何で、問題とは何で、今の状況はどうだから何が大事という理解を揃える必要がある。ピラミッドではなく、フラットなPO体制。3人で仮説検証して理解を合わせる

◇ 開発チームへの依頼

開発チームに依頼することはやったほうがいい。
スクラムガイドでも言っているPOが手に余ることはチームでやっていく。開発チームで補完していく。開発チームに専念させたいという気持ちはわかるが、プロダクトとして大事なものの優先順位と形になっていくために必要な行為というのがあるので、コードを書くことに専念させる事だけやっていくと結果的に形にならない。気宇を持ってもらいたい、コードを書く役割ではなく、プロダクトというものを作りユーザーの状況を変えていく活動をしている。というミッションをおいていく。

◇ 開発チームの領域拡張

仮説検証をPO3人でやりましょうと言ったが、仮説検証の一部に開発チームも参加してもらいたい。例えばユーザーテストを企画し、その有様を開発メンバーも見て、こんなとこでこんなに困っているんだな、こんな使い方するんだなっていう理解を高めていってもらって開発チームが取れる役割、判断できる領域を増やしていったほうがよい。

◇ 開発チームの判断速度向上

すべてをPOに問わないとできませんだと即時判断できない。POに言われたこと、会話なのかドキュメントなのかは、かわりない。言語化されたものを頭に入れて判断することをやっている限りは、それ以上のスピードにも活動にもならない。逆にいうと自分の頭の中で想像がつかないといけない。POからのインプットに頼ることなく想像できるためには、開発者も体験をしなければいけない。ユーザーテストや検証の中に織り交ざって自分の中のイメージを持つことが必要となる。

POの育成方法

PO育成はできるのか?
POになりたいというキャリアがある、後任を育てるとかどういう方法があるか?
何ができるとPOなのか?

回答

◇ POに必要な能力

POに必要な能力はいっぱいある。一人でやっていくには難しいので、現実的には役割の分担は必要。後任を育てるのは、やって行ったほうがよい。
自論になるが、特にPOは「人の時を思う」のができたほうがよい。
まずはユーザーがどんなひとたち、どんな状況、何をやっているのか関心を持って、理解を高めていく。そこを開発メンバー、関係者に説明していく。エスノグラフィー的な活動をしていくのがPOの根底にある。

「正しいものを探す」と「正しいものをつくる」の同時並行の仕方

仮説検証のサイクルについて、正しいものを探す仮説検証と、正しく作る仮説検証の具体例をいくつか聞いてみたいです。 1プロダクト内でのサイクルの同時進行や、正しく作っている最中に、外部環境に変化があって正しいものを探すところに戻る、ということもあると思うが、その場合はどのようにPOが動きステークホルダーが動いていくのか。

回答

◇ 分けた方が良い

正しくつくっている最中に正しいものを探す。
開発としては難易度の高い課題になる。別の言葉にすると顧客開発になる。仮説検証と同じ言葉だが、これをやりながら並行して作るそしてその整合性を保っていくってのは結構ハードルが高い。自信がないのであれば同時にやるのは避けたほうがよい。
今は探すフェーズを多めにして、この後つくるっていうふうにプロジェクトを分けてやっていくほうが混乱が少ない。それを繰り返すことによって並行感をつくっていくほうが現実的と思う。探すと作るの間に立つ人間がしんどい。
探す工程でいろいろわかり、わかったことをバンバン開発チームに投げていくと開発チームが受け取りきれない。流量制御をしなければならない。そうなると開発チームの状態をわからなければならないが、POで両方わかるひとは稀有なので難しい。やるならある程度の経験を積んでからやったほうがよい。

◇ サイクルの同時進行やり方

どうしてもやらなければいけないのであれば、正しいものを探す人と作るっていう状態がわかる人の2人がかりでやっていく。

ユーザに公開するタイミングとその範囲、課金について

現在、仮説検証のためにクローズドで数社に無償提供しているが、なかなか使ってもらえていない。機能が充足していないのもあるが、無料であることも関係していると考えている。
課金をどう考えるべきか?新しい概念のサービスを提供する場合どのタイミングで課金を考えるか?

回答

◇ バケツの穴が開いているか?

プロダクトとして穴があって離脱していく穴が開いているなら、そこに課金してもそれは無理、まず穴をふさぐっていうことをしないと課金するのは早い。ユーザーテストや検証によって穴が開いているか、どんな穴があいているかを特定していく。

◇ 競合製品に対して機能が充足しているか?

代替製品があるのであれば、人事部は競合との比較検討するので競合との機能差を見られると考えるとその部分の充足を考慮する必要がある。
穴が開いているか、充足感というところで足りている足りてないを考えその先で課金を考える。

◇ プロダクトの有用性を感じるか?

ユーザーどういう心理で金を払うかとらえないと何とも言えないが、有用性を感じないと金を払わないというプロダクトとするのであれば、有用性というのはバケツの穴が開いていたら有用性が足りていないということだし、他との比較で機能が足りていないのであれば有用性が足りないという判断を組織としてしてしまう可能性があるのでそこは気にする。

新しくプロジェクトを立ち上げるときチーム編成の仕方

新しくプロジェクトを立ち上げるときチーム編成は何を考えてやってますか?

回答 

◇ 状態・段階によるチーム編成

たとえば仮説検証型のアジャイル開発の段階で左側の時間(探す)であれば、検証が中心になるのでプロトタイプが作れるデザイナーがあれば良い。

MVPを特定しましょうかってなると実現可能性とか規模間の見立てが必要になるので開発者が必要になる。

スプリントを回していくとなると開発メンバーが必要になる。そこを0からやっていくならフォーメーションに気をつかう。副業、リモートワークなどチームの状態によって役割定義を決めていく。

◇ 制約を設けるためのメンバー

0の状態から作るとなると制約をどう作っていくかを慎重にやっていく。制約がない状態だとチームメンバーが各々いい感じでやろうとしてバラバラになって前進まない。アウトプットがでない。あえてリード役をおくプロダクトとして技術選定どうあるべきか設計の方針どうあるべきか中心的に決める役割をおいてその人に走ってもらう。それで制約をつくっていく。一方でチームでやっていくのでチームのコミニュケーションだったり運営っていうを見ていくチームリーダ役をおいてその人がチームを見ていく。そういう風にやっていく。

肥大化されたプロダクトバックログの対処方法

プロダクトバックログが肥大化している。その数の多さから、誰も全容を把握できておらず、チケットの重複や、情報が古いままだったりするものがある。
適当なプロダクトバックログアイテムの数はいくつか?

回答

◇ バックログの棚卸し

どっかのタイミングでやり直す。100、200のゴミともなんともいえないバックログを選別するのは大変。今の状況を踏まえてバックログを出しなおしたほうが早い。
一回すべて捨てる。必要だったら声が上がるそれは拾ってあげればよい。

◇ 精査するタイミング

3か月に1回とか作り直してよい。500個なんてあっても絶対つくらない。断捨離が必要。

◇ バックログアイテム数

絶対的な数の基準はない。プロダクト、開発の状況によって変わる。

極端にいうと20個30個ぐらいでよい。それ以降は妄想でしかない。いつのタイミングどの順番でやるかは先々になってみないとわからない。そこまで考えずに直近3か月必要なものを準備する。

◇ スクラムの欠陥

ごみともいえないバックログがたまる。doneにしていくゲームをしていくと全体感

が失われる。プロダクトとして何が備わっているかを可視化するものが別に必要。

◇ ロードマップの活用

ロードマップを引いたほうがよい。粒度的に3か月単位、1年単位でおおまかな機能を置くぐらいでよい。近づいてきたときに30個ぐらいのバックログを終わらすほうがよい。
やってみた結果ユーザーの反応により全然だめだったら、違う方向に行かないといけない。
一番下のバックログは絶対やらない。捨てたとしても本当に必要だったら上がってくる。

「仮説検証」の検証の管理方法

何が正しいか分からないので、小さく機能を作り、リリースした。
これが正しいかどうかの検証をするには少々時間がかかる。
リリースから日数が経ち、変化が顕著になってきた頃には、
日々の業務に忙殺されて、検証することを忘れてしまった。
すぐに変化が現れないような仮説検証の「検証」はどのように管理するのが良いか?

回答

◇ 検証の管理方法

めちゃめちゃわかる。ちゃんと向き合う必要がある。
手段は何でもよい。ヌーラボのバックログでも、スプレッドシートでも、永続化し、定期的にメンテナンスできるようにしていく。世の中的には、MVPキャンバス、検証キャンバスがある。何のために?何を検証するのか?どうやって?いつ?っていうのを楔を打つというか言語化して残したほうがよい。これ見てるよね。追っているよねっていうのを振り返れるようにする。

◇ 仮説検証を行う単位

ユーザーストーリー単位よりはもう少し大きい単位で検証していくことになる。
仮説があって(仮説キャンバス)、検証があって(検証キャンバス)があってそれに必要なバックログはどれかっていう順番になるので、検証する単位はすでにあるはず。

◇ 検証計画が先

検証キャンバスとかをつかってあれとこれとそれのストーリーをまとめて検証する。ユーザーの行動を検証するということ。考え方としてはユーザーの何々を検証したいからユーザーストーリーは、あれとこれとそれというのを整理する必要がある。先に何を検証するかがあってからストーリーが立てられる。

甲乙付け難い2つのアイデアの採用方法

2つのアイデアがあり、甲乙つけ難い。
両者に共通する仕様だけでは機能として成立しないので、どちらかに決め、実装したい。 大抵、発言権の強い人の「とりあえず〇〇」で決着する。
だが最近、議論も深まっていないのに「とりあえず」を使っているように感じる。
まるで思考停止の免罪符のようだ。もっと議論したいが、なんと切り出せば良いか?

回答

◇ 同調圧力に注意

とりあえずなんとかしときましょう。何とか前進んだ気がするのでやっときましょうってのはやりやすいが、本当にそうなのか考えたほうがよい?

◇ コスト(時間)がかからなければ、すぐ検証

ものによるぱっとやって、ぱっと検証したほうがよいものもある。

◇ 判断に迷うものは検証

2案あってどうしようって話だったら検証したほうがよい。基準をつくらないと判断できない。基準作りが仮説検証、検証もどのくらい時間を使うのか?というのが次の判断、そこのバランスになる。決めるのに1か月ぐらいかかるのであれば、コストが高すぎるので、作ってみるとかはあり。基本としては検証してやってみるという姿勢がよい。
2案やらなきゃいけないか、1案やってみたらおのずともう1案になる可能性もある。内容による。

◇ ちいさく早くつくると、とりあえずつくるの違い
・とりあえずわからないので作ります(根拠がない、理由がない)
・これが必要だと思って小さく作っていく(根拠がある、理由がある)
経験も1つの根拠。

まずだしてみるっていのはアジャイル界隈でよく使われる言葉だがそこには思考停止があるので注意したほうがよい。

形にしたほうがコストが安い(時間がかからない)のであればそうしたほうがよい。そのほうがリアリティが一番高い。

形にしてみなきゃわからないは解像度があらい。ほんとにその手段をとらないとわからないのか?ユーザーのインタビューしたらわかるCSの意見を吸い上げるだけでわかるというのも、ものによってはあるので、何でもかんでも作って判断するべきではない。

プロダクトチームと顧客の越境方法

仮説検証を行いたいが、プロダクトや市場自体が大きく、使われ方も顧客毎に多種多様な状態なため、1つの機能を追加するだけでも、最小限の機能が大きくなりがち。
プロダクトチームと顧客の壁を越えて、調整するとこで、ある程度解決できると考えているが、良い越境方法はあるか?

回答

◇ 一番ピンの特定

トラディショナルな話、アーリーアダプターの特定がどれほど進んでいるか?顧客のはばが端から端まであって一気に答える必要があるか?プロダクトは問題解決や切実な要望をかなえるもの。こういう状況に置かれている人は、特にこの問題や要望がおきるというのを特定し、まずはそこから解決していく、なぜならその人たちは一番お金を払う可能性があるし、その人が使うことにより実績がどんどん残っていく。それを一番ピンにおいて一番ピンを倒してその次のピンを倒していきましょう。(教科書的)
ほんとに全部の顧客、市場は本当に大きいのか大きいかもしれないが、最初のピンは本当に大きいのかってのを見定めたほうがよい。
それを踏まえ、やったうえで顧客との壁を越えていくっていうのはやったほうがよい。

◇ 顧客の壁の越境方法

良い越境の方法は現場に行くこと、顧客の環境に自分の身を置くこと。

例)魚市場でせりをやっているおっさんやおばちゃんにとって必要なプロダクトとは?にこたえるためには、会議室にいるべきではなくて、せりをやっている市場に行くべき、行くといろんなことがわかる。朝4時から、冬だとすごく暗い、すごく寒い、プロダクトは手元で使われる。寒いから手袋をしている。細かいことはできない、テキストを入れることができない。だったらボタンを押すだけで前に進むようにするようなUIにする。これは行ってみないとわからない。

リリース前後の仮設検証方法

仮説検証をしたいのはやまやまだ。
しかし「この機能をリリースした前後で、ユーザの行動は〇〇となるはずだ」
とリリース前後の比較をしたくても、完全な相対実験ができるわけではない。
仮説検証の精度はどのくらい担保するのが良いか?

回答

◇ リリース前後の仮説検証

理想は限りなく現実に近いものを用意し、リリース前に検証しその後に現実のプロダクトを作って検証するというのをやっていくのが理想

◇ 仮説検証の精度

精度の話になると現実歪曲曲線の話をしたが、コスト(時間)をいかに下げ、現実感を高めるかになる。コストが低く、現実感が高いのは代替製品を使うこと。代替製品がない製品をつくろうとしている場合は本当かって思ったほうがよい。切実な問題があればあるほど、顧客は解決するための行為をとっているはず、手でやっているかもしれないし、他のプロダクトを使っているかもしれない。だからこそ不満がある。その不満を解消することにより我々が作るプロダクトが既存の代替手段を凌駕することができる。代替手段がすでにある競合プロダクトであればそれを使って検証すればリアルな反応を得ることができる。それに基づいて作って実際どうなのかってのは比較検証ができる。

「無理をしない」と「確約」の優先順位

チームのベロシティを把握するためには、規則正しい作業時間を常に心がけないといけないと思っています。やむ得ず、スプリント終盤で残pointの消化ができない状態になった際に、「残業」をして消化しようとしてしまいますが、これはスクラムとして、是なのか非なのか教えてほしいです。

回答

◇ フィードバックによりわかることが重要

コミットメントは大事、コミットメントの確度が高められるいろんな準備をしたほうがよい。
スプリントの終盤だといろいろ事情があるが早く形にしたほうがいろんなことがわかったりローンチが早まったり、いろいろいいことがあるっていうようなスプリントであればやったほうがよい。早くわかるっていうのは価値。

◇ スピード感を求められない場合は積み残す

そういうスピード感ではなく、ただ、プランニング通りできなかったねって話ならば積み残す。なんで積み残ったかってのを振り返ることが大事。次どういうトライにするかをやっていたほうがよい。

◇ 正しいやり方というより正しいものを

あまりスクラムとして是か非か考えないほうがよい。スクラムガイド読んだほうがいいし、教科書として学んだほうがよいが、極限な状態ではスクラムとして正しいかどうかより、ユーザーが感じられるか?とか、プロダクトが形になるか?とかビジネスがうまくいくか?っていうのが大事。

◇ チームファーストかプロダクトファーストか

チームの良い感じな状態をつくるのがスクラムの定義する状態と信じると、それを全うしなければいけないと思っていしまう人が少なくない。特にスクラムマスターやアジャイルコーチという文脈な人はそれを振りかざしてくる場合が多い。
チームファーストかプロダクトファーストは局面によって違う。
このプロジェクトはチームビルディングをしなきゃいけないっていうは絶対あるのでやらなければならないし、今このプロダクトを頑張らなきゃならないって局面はある、ずっとチームファースト、ずっとプロダクトファーストではない。状況、ミッションに合わせてファーストを変えるってのが大事。

◇ チームファースト、プロダクトファーストの使い分けはだれがやるか

気付いた人がやる。アラートをあげる。誰しもが気づけるわけではない。本来的にはスクラムマスターの役割、状態を見極める

VOCの優先順位

VOCから機能開発を行う際に、どのように優先順位を決定していますか?

回答

◇ 狩野モデルで判断(教科書的)

状況やプロダクトによって変わる
教科書的にいうと狩野モデル(当たり前品質、一時的品質、魅力的品質)があってどれが求められるかという話になる。

検証としては魅力的品質がささるかを最初にやりたい。バケツの穴が開いてますっている部分では当たり前品質が問われているところがあるので当たり前品質に対応する機能を作っていく。今どういう状態によって選ぶ。

◇ 当たり前品質は背骨の部分で、魅力的品質は血肉の部分なのか?

魅力的品質はプロダクトをつくる意味なので背骨にもなりえる。