POとPOじゃない人の勉強会 第11回

第11回は、インフラグループマネージャである tamon が27章から29章までをまとめました。

第27章 ウォーターフォールプロセスを使いこなす

ウォーターフォールはちゃんと定義があるが、大抵の場合はそこまで厳格で行われていない。

ウォーターフォールの問題で上げられている「市場に反応してしまう」とは？

  • ウォーターフォールで進めるということは、それが売れる製品となることが前提である。しかし、実際にはリリースしてから、もしくはする前から市場の変化に反応せざるおえない、ということを伝えたいのでは。

第28章 ベンチャー企業のプロダクトマネジメント

ペパボでは新しいサービスを作るときにできているだろうか？

  • 実際のターゲットユーザーと一緒にやるというのができていない。アーリーアダプターや社内の人
  • 作ったほうがよくない？はある。思い込みリリース。
  • 方向性はよかったけどタイミングが悪かった。運がわるかった。

(ここで死んでいったサービス達の供養のターン)

第29章 大きい会社でもイノベーションは不可能ではない

「会社の看板背負ってだすからには…」そういう雰囲気は感じる。

最大の要因2つは、著者もそれ以上詳しくは書いてない。

観察によるイノベーションの対象は、アーリーアダプターじゃないほうがいいのは「アーリーアダプターは寛容だから」というのが前の章にあった。

いきなり札束で叩くんじゃなくて、ちゃんと関係性を作るように。

イノベーションとはなんだったのか。今ある問題を新しいやり方で解決すること！みんなハイライトして！

スマホタイムはイノベーションを起こしたかったのではのではないだろうか。

イノベーションから収益に結びつきにくいので、仕事の頭のまま起こすのは困難という考え方も。仕事はnクリックをn-1とかn-2にすることを考えがち。

http://www.otsune.com/diary/2008/09/11/1.html#200809111世の中というか生活というか

イノベーションを感じたものリスト

  • SUZURIの画像合成
  • 大相撲アプリの速報性
  • リターゲティング広告
  • LINE スタンプ
  • LINE 既読通知
  • マルチタッチ
  • nasne
  • フリック入力

おまけ

モンテッソーリ教育というものがある。Googleの本に出てた。

Twitterはこうやって作られたの？そんなかんじじゃない。

最近のPOたちの活躍

ECでのユーザインタビュー。

テスト用のアカウントで使ってもらったら、自分達の思っていたこととは違うところがたくさんあった。

新規の説明だけして使ってもらう。 > ナビゲーションの問題がわかった「そこにあると思うんだ」とかいうやつ。

文章で伝えられる要望は、その人が知っている概念で説明しようとするので、本当に欲しいものから離れてしまうことがある。

口で説明してもらうと情報量が増える。

30daysでベータ版アプリを入れた端末を持って社内を歩いた話。同じようにナビゲーションの問題がみつかったり。

これらかユーザテストをしたり、インタビューをしていく上で、ユーザに依頼メールをだしたりすることが沢山あるはず。

どういうメールが返信率がよいか、などそういう知見を貯めていけるとよさそう。

POとPOじゃない人の勉強会 第10回

第10回は、発表者が一周したので @kenchan が24章から26章をまとめました。

第24章 ユーザーにやさしい緩やかなバージョン移行

  • ユーザーは変更は求めていない。よくできた新しい機能は使いたいが、今できていることはそのままやりたい。
  • 一部のユーザーから始めるなど緩やかなバージョン移行が大事。

第25章 迅速な対応

  • 製品の発売はゴールではない！
  • 発売しないとわからないことがある！
  • 製品開発の中で一番ROIを改善できるのは発売直後なんすよ
  • すばやくバグを解決するとむしろ好印象・高評価になる

しかし現実は…

「開発直後にそのプロダクトの優先順位がダダ下がりになる」「リリース後に問題が多発する」→「あるある〜 (´・ω・`)」

なので…

「すぐに開発チームを解散しないで！」「リリース後も定期的にモニタリングしよう！」

第26章 アジャイルな開発手法を使いこなす

  • POとデザイナーは、製品開発チームよりも1,2スプリント先行すること（開発チームの協力も必要）
    • 「これ大事ですよね！！」
  • 重厚な仕様書ではなくプロトタイプとユーザーストーリーを作ろう
  • 開発者の環境でなく、ステージング環境で製品の品質を確保しよう
    • ローカル環境ではさくさく動いたのにステージングでは重い…とかになりがちなので
  • スプリントの最後には、現状のデモと次に開発するプロトタイプのデモをしよう
    • 次のスプリント用のデモまでできてないなー
  • 全員にアジャイル開発のトレーニングを受けさせよう
    • ちゃんとしたコンサルを雇おう！共通認識を持とう！

補講：スクラムを「ちゃんと」やろう！

☆みんな、アジャイルソフトウェア開発宣言読んでる？

1
2
3
4
　プロセスやツールよりも「個人と対話」
　包括的なドキュメントよりも「動くソフトウェア」
　契約交渉よりも「顧客との協調」
　計画に従うことよりも「変化への対応」

左にも価値があるけど、右はもっと価値があるね！

☆スクラム、「ちゃんと」できてる？

  • スクラムを知らない人・自己流でスクラムやってる人が多い。
  • バックログのリファインメントをやってないチームが多い。
    • プロダクトバックログがただのめんどくさい事案の塊になっていたりする。

▼スクラムガイドを全部読んで、まずはその通りにやろう！！
https://github.com/kdmsnr/ScrumGuide/blob/master/2013-07a/Scrum_Guide_2013_ja.pdf

▼その名もスクラムという本が出た！
著者はスクラムの生みの親ジェフ・サザーランド。
http://www.amazon.co.jp/%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0%E3%80%80%E4%BB%95%E4%BA%8B%E3%81%8C%EF%BC%94%E5%80%8D%E9%80%9F%E3%81%8F%E3%81%AA%E3%82%8B%E2%80%9C%E4%B8%96%E7%95%8C%E6%A8%99%E6%BA%96%E2%80%9D%E3%81%AE%E3%83%81%E3%83%BC%E3%83%A0%E6%88%A6%E8%A1%93-%E3%82%B8%E3%82%A7%E3%83%95%E3%83%BB%E3%82%B5%E3%82%B6%E3%83%BC%E3%83%A9%E3%83%B3%E3%83%89/dp/4152095423/

POとPOじゃない人の勉強会 第9回

第9回は、カラーミーショップ のディレクターである @_gasyadokuro が21章から23章をまとめました。

第21章 製品仕様の検証

私たちが「仕様」というとき、本書ので「製品仕様」とはだいぶ違うものを差しているように思うので、言葉を整理したほうがいいだろう。

フィージビリティはやってないことが多くて、「もちろんできるよね？」という感じで決まることが多いのではないだろうか。

だいたいのことはできるけどそれは

  • 人を増やす
  • 時間を増やす(期限をのばす)

のどちらかで解決していることも多い。

「ユーザービリティテストとは技術であり科学である」つまり習得可能で、再現性があるということ。ここテストに出ます。

本書でのユーザーはサービスを利用する人一般、顧客はその中からお金をはらってくれている人、というくらいの理解でよさそう。

ユーザを顧客にしていくのがグロースハック的なものでは。

最初の方にあった、評判がいいけど売れなかったやつは「価値があるかどうか」の検証がたりなかったのではないだろうか。

第22章 製品プロトタイプの検証

ユーザビリティとは使用感のことである。

製品のアイデアを実際のユーザーと一緒にテストすることは、プロダクトマネージャーの大切な仕事の1つ。みんなやってる？

第23章 現在の製品を改善する

改善とは機能追加ではない。これテストに出ます。

問い合わせ多いから注意書き足しとこうとか、他がやっているからとか、そういうやつは改善なのか？

では改善はどういうことかというと、製品の出来を表す数値を狙った方向に動かすこと。そのためには、仮説をたてること、それを検証することが大事。

ディレクターが数字を見ることがここに繋がる。

また、仮説をたてる上で、実際のユーザに聞いてみるというのは効果的。ただし、質問やアンケートの作り方で、自分達の期待する答えを誘導しないように作るのが難しい。

アンケート等では、直接の解決方法のよさを判断するのではなく、その根底にあるユーザの不満や疑問をほりおこすことが大事なのでは。

POとPOじゃない人の勉強会 第8回

第8回は、JUGEM の yuriwo が18章から20章をまとめました。

プロトタイプとユーザテスト

ここで言うプロトタイプやベータ版は、本開発とは別のもの。何度かでてきたハイファイプロトタイプと呼ばれるもの。

その結果を受けて、プロトタイプを捨てて本開発をするんだよ。プロトタイプの定義を関係者で合意しておかないと、不幸な未来が見える。

ユーザテストでのアクシデント

ユーザテストでもし未完成の部分をユーザが操作したらどうする？

続きになにがあると思いましたか？と聞くと価値ある情報が得られることがある。

ペパボでの製品要求仕様は?

ペパボでは製品要求仕様やハイファイプロトタイプを作っているか？

XXプロジェクトでは、一番最初にUXをイメージできる動画を作ったよ。

ただ、実際に動くようになると触り心地がだいぶ違ったようなので、ハイファイプロトタイプってのはそういうところまで再現できたほうがいいのかもしれない。

minneではスマホアプリ用にWebの機能からペーパープロトタイプを作ったりした。

製品要求仕様やハイファイプロトタイプで解決しようとしている課題は何か

解決すべきユーザの課題は決まっていて(これは市場要求仕様の範囲かな？)、その解決方法が

  • 問題を解決できているか
    • うまく解決できているか

という部分を低コストで判断したいのでは。

市場要求仕様の部分とあわせて考えると

  • 問題があっているか
  • 解決方法があっている
  • いい解決方法か

という3段階があって、これを素早く検証しなければならないのだ。

ユーザテストのコスト的な問題

モックを作って、テストのシナリオを考えて、ユーザに会いにいくの大変だよ。そんな高速にまわせるのかな？

そういうことをやった結果、「スピード感がない」と思われてしまったりしないか？

結果的にはきっと無駄が少なくなるはず。それをどう説明するかの問題では。

一発でいいものができることもあるだろうけど、それは宝くじにあたるのと一緒で運(とセンス)でしかないのでは。

ユーザテストをやればよかったと思ったことは

ユーザからものすごい反感をかったり、出したけどすぐひっこめた経験はけっこうある。

人間の心情として、出してみたけど駄目だから引っ込めるというのは納得できるが、正式に出す前になかったことにするのは納得感がないと感じるかもしれない。

第三者の意見は圧倒的な根拠になってしまう。

ユーザテストの結果でころころと仕様を変えてしまうと、手戻り感を感じるかもしれない。そのあたりの価値観と進め方を事前に共有しておく必要はありそう。

サービスの提供側とユーザの心がズレていってしまうのはどうしてなんだろう。

サービスの提供側では利用者になりきれない場合が多い。そのためにリファレンスカスタマーを探すんだ。

何がきっかけでユーザテストをやるようになったか

職種間で意見が食い違った。じゃあインタビューをしようという話になった。

これは製品要求仕様のまえの市場調査をやったということになるのではないだろうか。

スクラム、ユーザテスト、アジャイル開発

わからないということを前提にしているのがよい。スクラムとユーザテストの共通点ではないか。

最初から答えがあるならウォーターフォールが最強。

どちらがよい、というわけではなくて、自分達が解こうとしている問題の性質にあわせてプロセスや道具を選択、改善していくことが大事。

ペパボのプロダクトマネージャの将来像

以前と比べると、ユーザテストやインタビューの必要性や有効性が理解されてきたように感じる。

一方で、熱意とテクニックのバランスの取れたプロダクトマネージャーの育成や学習が次の課題になるのではないだろうか。

そういった活動の一つがこの勉強会。

結局はいいプロダクトが早く開発できて、それで儲かれば文句ない。

「ユーザテストやってる間にどれだけ新機能作れるのか」という問いは間違っている。そういうことを説明しなくてもいいような組織作りが大事。

ミドル層がキーマンと言えるので、リーンスタートアップを読んでおしまい、から一歩前に出よう。

まずは本を読む。世の中には同じことで悩んでいて、いろいろな方法で解決している人達が既に沢山いる。

この読書会で共通認識が作られるつつある。もっと広げていきたい。

雑談

製品だけじゃなくて人間が成長する。チームの成長。それがさらに製品に返ってくる。

POとPOじゃない人の勉強会 第7回

第7回は、今をときめく minne(ミンネ) ハンドメイドマーケット 手作り作品の通販 の のりぞー が15章から17章をまとめました。

15章 ユーザーモニター制度

「お客様の声」みたいなことをやると、不満がたくさんでてくる。その人達はリファレンスカスタマーではないと考えられる。(普通のカスタマー)

リファレンスという言葉を日本語にするとしたら何が適当か。

アンバサダーという制度もありますよね。ただ、リコメンドしてくれるだけではなく、指摘してくれる人だからリファレンスという言葉を使っているのでは。

ユーザーモニターをする製品は特注品ではない(あなたのためのソフトウェアではな)ことをちゃんと説明する。そう考えると、クラシコムの青木さんはリファレンスカスタマーっぽい。

アーリーアダプターはユーザーモニターの対象とはだいぶ違うことを忘れないように。

16章 市場調査

アンケートとってますか？とってるけど難しい。回答から設問を作りがち。

あるといいと思います？よりは、いらないですよね？と聞くと本心がききやすいこともある。あえて間違っていることを言うというテクニックもある。

狩野モデルの「当たり前品質要素」はKPIがとりにくい。継続率とか?

また、あの3つをどうバランス良くやっていけばいいのか、なにか考え方はないだろうか。1つは自分達が今どこに力を入れているかを意識すること。

身も蓋もないことを言うと、そのバランスをとるのがプロダクトマネージャーの仕事では。

プロダクトのフェーズによっても、どこに力をいれるべきかは変わってきそう。

30daysのユーザインタビューの話。オフィスで考えていてもでてこない考え方が見えてきた。

データ計測の問題。適度なデータがたまったら教えてくれるサービスが欲しい。ビジネスチャンスだ。

ペルソナは個人じゃなくて集団を代表する人格を想像する

一度細かくして、そこから抽象化するといいのでは。ざっくりやると、無意識に暗黙的に仮説を作ってしまいそう。なので、詳細なペルソナをまず作るのもよさそう。

17章 プロダクトマネジメントのためのペルソナ

だれのための製品化を決めることは、ターゲットから外れているユーザを定義するという意味もある。

ペルソナをたてることで、「自分」と「顧客」の意識を分けることができるようになりそう。

万人のための製品は、ペルソナを考えているサービスに負けてしまうのでは。

某社の強さはそのあたりにあるように見える。

ペルソナを定義することで、競合を明確にできるのではないか。プロ向けのサービスとアマチュア向けのサービスは競合となりえるのか。

パズドラのペルソナってどうだったんだろう？今や老若男女問わずだけど、初期はおそらくあったのでは？

minneのペルソナできたら、のりぞーさんに全サービスを渡り歩いてペルソナ作ってほしい。