【メモ書き】【freee×ビズリーチ】急成長Techベンチャーのプロダクトマネージャーが語るPMの仕事・魅力に行ってきた

行ってきた。

 

d-cube.connpass.com

 

発表者はfreeeの轡田さんとビズリーチの織田さん。

資料自体は公開されているので、発表の内容を細かく書くのではなく、

印象に残ったことや発表後の質疑応答の回答を書いていこうと思う。

 

ちなみに、お二人の発表資料はこちら。

 

www.slideshare.net

 

www.slideshare.net

 

 

印象に残ったこと

プロダクトマネージャーはユーザーの本質的な課題と、事業戦略を深く理解して正しいプロダクトの方向性を導かなければならない。

 

プロダクトのフェーズなどによって役割は急激に変わる。織田さんの場合、1年間で2回ぐらい役割が変わったらしい。

 

フェーズによるが、プロダクトマネージャーは課題の提示だけで解決策の提示はしない。

解決策は何を作るか、どうやって作るかのスペシャリストであるエンジニアの方が最適なものを選択できるという考えがある。

だから例えば、「残業時間を労務担当者、上長、従業員にメールで送信する。」という依頼の仕方はダメで、「残業時間を労務担当者の工数をかけずに上長に直感的に気づかせる」という依頼の仕方をするべき(前者の書き方をすると、ビズリーチでは他のプロダクトマネージャーとの相互レビュー時にリジェクトされるとのこと)。

 

プロダクトマネージャーに求められるスキルは多岐にわたり、しかも絶えず変化する。

いかに気持ちを落とさずに必要なスキルをキャッチアップできるか、が鍵になる。

 

質疑応答の内容

toB向けの製品のユーザー理解をどうやっているか?

 定量・定性両方の観点から調査している

 freeeの場合は実際に税理士事務所に行ってヒアリングしたり、エンジニアがカスタマーサポートチームに「留学」して使われている現場を感じられるようにしている。今でも社長もたまにカスタマー応対をやって、現場を感じる機会を意識的に設けているとのこと。

 

どうやったら気持ちよくエンジニアやデザイナーに動いてもらえるか?

 織田さんは(ビズリーチとして?)フォーマットがあるので、それに則ってドキュメントを書いている。

  •   課題の定義・課題の背景を伝える
  •   リリースの時期
  •   誰からの要望か
  •   (toB製品なので)法律的な背景

 

 

所感

  • 製品の正しいビジョンを定義する、ユーザーの課題を発見・定義するという根本的な部分以外は、事業フェーズやプロダクトマネージャのバックグラウンドによって仕事内容が本当に変わってくる。
  • 織田さんの話を聞いていると、(もともとが自社内でのみ使う人材管理システムを作る、だったとはいえ)最初期とか正しいビジョンを定義する、ユーザーの課題を発見・定義とかもない様子だった。まさしく何でも屋、という趣。
  • 正解なんて誰もわからない、求められている役割も頻繁に変わる、という環境では開発技術などの特定スキルよりもいかに早く必要な知識を仕入れて正解を見つけるか、という「瞬発力」が大事であるように感じた。
  • ただ、他のプロダクトマネージャーとの差別化だったり、エンジニア、デザイナーと円滑なコミュニケーションができた方がいいから、何かしらの職種のバックグラウンドがあるのは利点ではある。
  • あとは、いかに正しいビジョンを語れてもエンジニア、デザイナーが付いてきてくれないと元も子もないから人間力・コミュニケーション力が大事。ジョブズは例外。

 

 

 

 

書評:Q思考

先日のブログで紹介したQ思考の書評

 

三行書評

 ・美しい質問とは私たちが物事を受け止める、あるいは考える方法を変えるきっかけになる質問のこと
 ・美しい質問をするためには、質問の内容を「なぜ?」「もし〜だったら?」「どうすれば?」という3つの過程に分解して考えるといい
 ・専門知識や客観的事実・データの価値は、少しづつ落ちてきている。大事なことは問いに対する回答を考えるときに、その知識を生かせるかどうか

 

要約(1)

美しい質問とは私たちが物事を受け止める、あるいは考える方法を変えるきっかけになる質問のことだ。

こうした質問はググって見つけることができるような類のものではない。答えを探すことは難しいが、答えを見つけることが不可能なわけではなく、もし答えることができればゲームのルールを変えてしまう可能性を秘めた問いのことだ。

多くの画期的イノベーションは、一つ、あるいは一連の美しい質問と、それに対する回答が出発点になっている。良い製品を作るには良い疑問、投げかけるべき正しい質問や解決すべき正しい問いが何なのかを理解する必要がある。

 

 

要約(2)

美しい質問をするためには、質問の内容を「なぜ?」「もし〜だったら?」「どうすれば?」という3つの過程に分解して考えるといい。

なぜか。美しい質問を探すプロセスでは、様々な不明な点に遭遇する。ただ、それぞれの段階で何を問うべきかについて一定の感覚を持っていれば、何が良い質問かわかっていなくても、何をするべきかはわかっていられるからだ。

 

 専門家が問題に対処する様子を観察しているうちに、私は彼らの物語には一つのパターンがあることに気づいた
 ・主人公が理想とは程遠い状況に遭遇し「なぜ?」と問う。
 ・改善策/解決策のアイデアを思いつき始める。多くの場合、それは「もし〜だったら?」という仮説のかたちで現れる
 ・主人公はそれらの可能性の一つに注目し、それを現実に移そうとする。多くの場合、この段階には「どうすれば?」を見つけ出すプロセスが入っている

 

要約(3)

専門知識や客観的事実・データの価値は、少しづつ落ちてきている。大事なことは問いに対する回答を考えるときに、その知識を生かせるかどうか。

テクノロジー(ここでいうテクノロジーとは主に情報技術を指している)の進歩によって、人間は一瞬で莫大な量の知識やデータ、情報資源にアクセスできるようになった。

ある技術が一部のプロだけが使える特殊なものから、一般の人が使えるものになるまでの期間(コモディティ化)までの時間もどんどん短くなっている。だが、技術に精通していると美しい質問に対して革新的で驚くような答えを提供することができる。

 

所感

パナソニックソニー東芝などの日本を支えてきた大企業に元気がなくなると、誰かがおきまりの文句のように「技術では外国に負けていないのに」というのがずっと気になっていた。

では、これらの大企業には何が足りていなかったのか。その技術が良いプロダクトを生むための「良い課題」「良い問い」を見つけ、答えとなる技術と繋げることができる人材が少ないことが問題なのではないかと思った。

 

私はエンジニアなので、一般的な世間の人と比較すると技術に詳しいと思っている。また、この技術が一体どんな課題を解くのに役立つかわからないが、何かに役立ちそうという技術に触れることもよくある。そしてこの感覚は、自分以外の多くのエンジニアも1回や2回ぐらいは感じたことがある感覚だと思う。

 

この状態はTaka Umadaさんが、自身のブログで「答えが問いを待っている状態」という言葉で表現されている。

通常、先に問いや課題があって、それに対する答えや解決策を探します。つまり「問いが答えを待っている」のが普通です。その答えを求めて、解決策や技術を探します。


しかし一方で、技術系スタートアップや工学部の学生の皆さんと会っていると、先に答え(技術)があって、それに最適な問い(課題)を探しているパターンに出会います。つまり、使いたい技術が先にあってアプリケーションを探す、というパターンです。

 

最近までこの「答えが問いを待っている状態」というのは、手段と目的が入れ違っていて、良いプロダクトを作る上ではアンチパターンになるのではないかと考えていた。

だが、このブログで紹介されているレーザーの例やiPadの例は、問いが先にあって、後から解となる技術が出てきたわけではない。基盤となる技術が先に出てきていて、後からこの解が使える美しい問いが見出された。

大事なのは、コモディティ化されていない解を解自身とは一見何の関係も見えない美しい質問と紐付けることができるか、ではないだろうか。

 

技術者である以上、一般の人に比べて「解」に精通しているのは当たり前だ。技術が陳腐化する速度が早い現代にとって、技術者の価値は技術がハマる良い課題、良い問いを誰よりも早く見つける力ということになっていくのではないか。

 

あとは、これらの本で紹介されている「なぜ?」「もし〜だったら?」「どうすれば?」のプロセスでそれぞれ大事なことや、具体的な良い質問を作るための手法についての紹介が、かなり参考になった。

 

 

 

 

 

シン・UX 2017 ~プロダクトマネージャー・プロダクトオーナーにとってのUXのイマとミライ 行ってきた

なぜ行ったのか

 

 もともと良いものを作りたいというモチベーションでエンジニアになったが、業務を続けていくうちに良いものを作るには、良いもの(=ユーザーにとっての理想の状態・課題が解決された状態)を定義できなければ話にならないということを感じ始めていた。

 

おそらく良いもの≒良いUXだと思っているので、自分には良いUXを設計していく力というものが足りていないということになる。良いUXを作るため、どういうことが必要なのか、まずはそれを自分なりの言葉で定義できるようになる必要があると考え、その示唆を与えてくれることを期待してこの勉強会に参加した。

 

所感

そもそもUXを自分の言葉で定義できない

まず最初にイベント主催者の関さんから開場の言葉があった。この時会場全体に、「UXとは何かを自分なりの言葉で説明できる人は挙手してほしい」と呼びかけがあった。挙手した人にはその場でUXとは何かを説明してもらう、という太い釘が刺されていたのもあるだろうが、誰も手を挙げず皆自分と同じようにUXとはなんだろう、というモヤモヤ感を持って集まっている様子だった。

私も御多分に洩れずUXというものがなんなのか、自分の言葉で説明できないクチだった。良いUXを作りたい、と言っているのに良いUXとはなんなのか、説明できないなんて笑い話なので、まず第一の目標として講演を聴き終えた時点で自分なりのUXの定義を持つこと、を設定した。

個人的に一番参考になったのが、松田大介さんが言っていた、UXとは「なぜそれを利用し続けたいのか、の問いに回答できる個人の体験」という定義だった。

自分なりにこれを噛み砕くと、UXとは

なぜ【ここにあなたがユーザーにやってもらいたいことを入れよう!】と思ったのか、の問いに回答できる個人の体験

ということになるし、良いUXとは

なぜユーザーは【ユーザーの欲求が満たされた理想の状態を入れよう!】と思ったのか、の問いに回答できる個人の体験

ということになるのではないだろうか。

ひとまずは上に書いた定義で自分の中で腹落ちしたので、この定義の上でUXを作る・考える(設計する)ということは何なのか、考えていくことにした。

 

UXを作るためのHowにとらわれてはいけない

今回の講演でも、様々な人が自分たちが使っているUX設計の手法について発表してくれていた。

思い出せる限りでも、

・バリュープロポジションキャンバスを作って検証する

・悩んだら体験を細かく要素分解する。細かく要素分解すると、本質的な価値ではない部分が見えてくるのでそこを省いたり改善する

・検証手法としてのHi-fiプロトタイピングの取り入れ

・顧客開発の指標としてProblem/Solution FitやProduct/Market Fitを取り入れ

・リーンキャンバス

・プロトペルソナ

・6up sketches

 

などの手法が挙げられていた。

ただ、これらの話を聞いていても、正直腑に落ちないことが多かった。

この時点ではまだうまく言語化できていなかったのだが、これらの方法はあくまでUXを設計するための手法(How)の部分であって、手法をなぜ使うのか、どうしてこの手法を選んだのか、という部分が抜け落ちるとただ手法を使っただけになってしまうのではないか、という不安感のようなものがあった。

 

これらの手法を体系的に学び、実践できるようになることには間違いなく価値があるだろう。

ただ、これをただ持ち帰っても根本的になぜこの手法を選ぶのか、という視座が抜け落ちてしまうのではないかーーーあるいはこれらの手法で作り出される最終成果物を出しただけで自分は満足してしまうのではないかーーーそんな不安を拭いきれずにいた。

 

そんな違和感を抱えてこの記事を書いていたのだが、ちょうどこれらの手法についてgoogle検索をかけていると、今回の講演の最終発表者だった坂田さんのブログにたどり着いた。

ちょうど自分が感じていた違和感が綺麗に言語化されていたため、冒頭のみ引用する。

 

ハウツーが豊富な実用書ばかりを手に取るくらいなら、Q思考という書籍を推奨します。もともと当ブログでも何度も言及しているとおり、首題となる人間中心設計や UX デザインと呼ばれている手法体系は「問題解決」に重きを置きがちです。問題を解決するための手段として徐々に普及していますが、正しくモノをつくろうとする(正しい答えを求めようとする)意識が先行してしまうが故に、正しいモノの追求(正しい問いの追求)という本質が抜けてしまっているように思えて仕方がありません。

 

sprmario.hatenablog.jp

 

この時点で、自分が知りたかったもの、学びたかったものは『正しいモノ(正しい問い)を追求するためのものの考え方』だったのだと考えるようになった。

もちろん、人間中心設計やUXデザインといった解決の手法に価値がないといっているわけではない。ただ、そういったHowと同じくらい、あるいはそれ以上にWhyという部分は大事だし順番としてはまず先に正しいモノを定義することが必要になると思う。

 

自分の中でUX設計というのものを考えた時に、

・なんのために作るのか(Whyの部分)

・何を作るのか(Whatの部分)

という部分が不可分で切り分けできていなかったので、手法の話だけ聞いても片手落ち感が拭えなかったのだと思う。両方大事で、両方自分には足りていない。

 

何を身につけるべきか、というのを自分の中で具体化できただけでも、今回の講演を聞きにいった価値があったと思う。主催者さん、講演者のみなさん、本当にありがとうございました。

 

これから

早速だが、この後「Q思考」を読んでみようと思う。

後、ちょうど登壇者の人が過去に産業能率大学の人間中心デザインの講義を受けていたと聞いた。

http://aiit.ac.jp/certification_program/hcd/

半年間に渡って人間中心デザインについて体系的に、かつ演習も含めた形で講義をしてくれるらしい。先ほど書いたHowの部分に当たる技術だと思うが、過去の記録を見ると自分と似たような悩みを持つエンジニアの人が受講しているように見える。今年の出願で応募してみようと思う。

 

 

 

 

Think User First#3 サービスデザイン手法のワークショップに行ってきた

 

なにこの記事

CookpadとFablic共催のThink User Firstというイベントに行ってきたので、久しぶりのアウトプットがてら内容の要約と感想をメモする。

 

ワークショップということもあって、最初30分だけクックパッドのサービス開発で行っている手法の紹介があって、その後は実際にその手法に則ってどんなにショボくてもいいからアウトプットしてみましょう。という会だった。

 

発表された資料を何枚か撮ってきたが、斜めからの写真で見づらいのと、あとあと資料も公開される(と思う)ので講義中にとったメモだけ残しておく。

 

紹介があった手法は以下の4つ

・価値仮説

・EOGS

ユースケース

・プロトタイピング

 

(プロトタイピングについてはなんかあんまりメモが残っていないので、上3つについてだけ)

 

 

価値仮説

 ・LeanStartupで紹介されているシンプルなフレームワーク

 ・【ユーザー】は【欲求】(し)たいが、【課題】(ない)ので、【製品の特徴】に価値がある という文章に当てはまるように【】の中身を埋めていくことで、プロダクトの価値を明文化する手法

 

 探したらクックパッドの人が作った別資料があった。

speakerdeck.com

 

 

EOGS

・キャスト(ステークホルダーみたいなもの)ごとの

・疑いようのない欲求を立てて

・それらを満たす解を導くフレームワーク

・クックパッド謹製のフレームワークで一番歴史があるらしい

・価値仮説とは異なり、目的や利害が異なる複数の登場人物・組織が存在するときに各登場人物がWinWinになるようにサービスを設計するために使う

・コツは、書いてる本人がワクワクするような登場人物全員がハッピーな「背伸び」をした目標を描くこと(ただしKPIは別にきちんと設定する必要がある)

 

これも探したら資料が出てきた。

ブログ中段の図がEOGS 

techlife.cookpad.com

 

 

ユースケース

・別名ユーザーシナリオとかストーリー

・ユーザーの行動フローを書き出す

 

これはググってもいい実例がなかったので、資料で紹介されたユースケースを転載する

 1)セールで、狙っていた服を買い逃してしまった

 2)諦めきれず、フリマで売りに出ているものを探す

 3)運良く服をみつけ、状態も新品であることを確認

 4)が、販売価格が高いのでひとまず保留にしておく

 5)一週間後、さらに値下げされたことを知る

 6)他の人に狙われないうちに、急いで購入の手続きをした

 

上記の例でポイントになるのは、

・開発者目線で書かないこと。例えば、「さらに値下げされたことを知る」を「値下げされたことをプッシュ通知で送信する」と書いてはならない。さらに値下げされたことを知るという欲求を満たすための方法は1つではないしその場面で何を提供できるといいのか選択肢も含めて考えられるようにするため。機能名を書くと選択肢について思考停止してしまう。

 

・本当にユーザー目線で書けている(=開発者目線の書き方ではない)と別にアプリを使うという文脈でなくても成立するストーリーになっている(上記ユースケースは5あたりを除けば一般的なフリーマーケットでも成立する)

・ユーザー視点で記述することでそのサービスに既存の代替手段との優位性があるかがわかる

・あえて画面外の行動も書く

・これがしっかり書けるようになると開発者目線とユーザー目線の思考が切り離せるようになる

 

実際のワークショップ

 限られた時間ということもあって、ワークショップでは与えられたペルソナを元に生活に関する新規事業の企画のためにアイデアの有用性について議論できるレベルのスマホアプリのプロトタイプを製作する。というお題が与えられた。

 

最初は6チームに分かれてアイデア出ししたり価値仮説やEOGS、ユースケースを作成した。決まったテーマをざっくり説明すると「余った食事を近所でシェアするCtoCサービス」。わりと他のチームとは毛色の違うアイデアだったので、チーム内では密かに自画自賛していたw

作った価値仮説とユースケースはこれ。

 

 

この時言われたポイントとしては、

・あやふやな定義の言葉はその言葉を構成する要素を分解して本質的なターゲット像や課題、サービスの価値を突き詰めたほうがいい。最初自分のチームのターゲット像は「非リア充」というふわっとしていて特定の世代しかわからないような言葉だったが、突き詰めて自分たちが考えたアイデアが刺さりそうなターゲットは「食生活を改善したいめんどくさがり屋」というところまで具体化した。

ユースケースを作る時はまず1つ使用開始から使用終了までの流れを1本作った後に、その一部分を変えてみたりして複数作ってみるといい(って言っていた気がする)

・手詰まりになったり、前に作った価値仮説やEOGSと矛盾が発生するようなら、前に作った資料を修正してもいい。

 

プロトタイプ作り

・ここから個人作業だったが、自分が作ったものはひどい出来栄えだった。

・最初は簡単なプロトタイプだし、Cookpad本体から画像とかUIとかパクればいいやん!とか思っていたが、甘かった。「これクックパッドと変わらなくね?」と当たり前のツッコミをくらい。ほぼ全ボツとなった。

・ペルソナはとんでもないめんどくさがり屋ということに再度焦点を絞り、「ワンコインで購入できる」「帰り道で受け取ることができる」といった導線を作成し、アプリ起動から3タップで購入できるような設計をしたら、これは以外と好評だった(未完だったけど)。

・既存のUIを最初からパクっても、ユーザーの課題解決にはつながらないといういい教訓になった。

・チーム内で1人代表を出して発表してもらったのだが、うちのチームの代表者が作ったモックはSketchやらで書いたカッコイイモックではなく、手書きのポンチ絵であった。それでもサービスの価値は十分伝えられており、短時間でサービスの価値を伝える上ではモックのかっこよさはあまり重要でないことを学んだ。

 

その他なるほど、と思ったポイント

・調査や手法はすべてユーザーの課題解決のための手段なので、手段を開発組織に取り入れることそのものを目的にsないこと。組織にフィットした形で取り入れること。

・1〜2人とかの少人数で開発している場合は価値仮説やEOGS、ユースケースを書く必要はない。これらはあくまで複数名で開発しているときにサービスの目標や価値を共有したりメンバー間で考えがぶれたときの立ち返り先として使うものであって、チーム内で完璧にユーザー像や課題を共有できている場合は不要

・正しいやり方で正しいものを作ってもヒットするかは時の運だから多くのトライを打つことが合理的

現場の状況を目に見えるようにする 反省レポート

ちょっと前に新卒システムエンジニア見習いを集めた開発演習があり、ホワイトボードによる情報共有を試してみたのですが、いろいろやらかしてしまったのでその振り返りを行いたいと思います。
 
この反省は、今月参加したアジャイルサムライ横浜道場の「現場の状況を目に見えるようにする」で伺った意見を元に作成しています。
 

忙しい人向けの要約

・現場の状況を目に見えるようにするとは、チーム全体の進捗状況の共有・相談したり、メンバーが次にどんな仕事をすればいいか指示を仰がなくても判断できるようにすることなどを目的に、情報を整理し、容易に現在の状況を閲覧共有できるようにすることです。
 
見える化を推進するとき留意するべき点として、
 ①掲示する内容はシンプルに保つこと
 ②現場の現在の状況を常に反映すること(この情報古い!ということをなくす)
 ③掲示しただけで満足しないこと(チームが見える化する意義を理解し見える化した情報を確認・活用してもらわなければ意味がない)
 が挙げられます。
 
・開発演習での見える化に挑戦した反省として、
 ①メンバーが見える化する意義を理解していなかった
 ②開発進捗状況の共有に有効利用できなかった。
 ③作成したTODOに関して、一つ一つの仕事の粒度が大きく、進捗状況の変更がほとんど行われなかった(この情報最新じゃない!な事態が起こっていた)
 
 が挙げられ、その結果使われない仕組みとなっていました。
 
・以下のような改善案が考えられます。
 ①メンバーに対する見える化の意義の説明を事前に行い、共有すること。
 ②毎朝の進捗状況の確認時に、全体の進捗状況(工程が遅れているか、進んでいるか)を更新・共有しスケジュールに対する認識共有やアクションを共同で考える
 ③タスクの粒度をチームメンバー全員で相談して決定することで一日以上進捗がないように見えるタスクを作らない(タスクの内容を細かく分解する)、タスクの開始日時と終了までにかかる時間の見積もりを記入することでチームメンバーがタスクの遅れに気づけるようにする。
 

現場の状況を目に見えるようにする とは

・ホワイトボードや電子タスク管理システムを使って開発中のコミュニケーションに必要な情報を共有すること
 
・個人個人が現在行っている作業、作業の進捗状況であったり計画から見てどれくらい進捗しているかであったり、チームのルールや大切にすると決めた価値観などを貼っていく
 
・一人の人に管理を任せるのではなく全員がオーナシップをもって情報の更新管理を担当する必要がある
 

なぜやるのか、やると何を解決するのか(教科書的には)

・チームがやるべき仕事をTODOリスト形式でリストアップすることでどんな仕事が残っているかを一目瞭然にできるので、メンバーが次に何をすればいいかを指示を仰がなくても理解できるようになる
 
・それぞれの仕事の進捗状況が可視化することでどこが遅れていてヤバいか・リカバリする必要があるか理解できる
 
・仕事の透明性が増す(良くも悪くも成果がはっきり見える)ので、仕事に対する責任感が増す
 

実際にやってみたこと

・ホワイトボードにチームメンバーの名前と今何をしているか、やっている仕事の進捗状況(未着手、着手、完了)を記入してもらうことにした
 
・変更を加えたソースファイル、変更を加えた人の名前、変更を加えた理由を記入してもらった
 

うまくいかなかったこと

・書籍の登録機能を作る、といったレベルでTODOを作っていたが、いつまでも進捗が着手から終了に変化せず進捗の変化がわからない(現在の進捗状況がわからない)
 
・ホワイトボードに情報を書き出すことの意義やメリットが浸透しない
 
・チーム全体の進捗の確認に使えていない
 

勉強会で聞いた事例やアドバイスをもとに反省したこと

①メンバーに対してなぜ見える化を行う必要があるのか見える化を行うことでなにをチームが得ることができるのかに対する十分な説明がなかった
 
見える化を行った時の一つ一つのタスクの粒度が大きすぎ(実装に1日以上かかるレベル)、開始日時と予想消費時間などの情報がないため、進捗の確認という目的を果たすのに不十分な見える化であった。リーダーのみがタスクを作成していたため、他のメンバーが一日で終えることのできる作業の見積もりを誤っていた(自分が実装すれば3時間で終わるけど、ほかのメンバーが実装すれば1日以上とか)。
 
見える化した情報を、開発全体の進捗が遅れているのか、進んでいるのかの共有に活かすようなミーティングをしていなかった。結果チーム全員でフォローや対策を考えるツールとして使用できなかった。
 

反省点を改善するためにできそうなこと

①メンバーにたいしてなぜ見える化を行う必要があるのか、開始前に資料などを配布して説明する機会を設け、目的や効果、個々人がやるべきことに対する合意を得る
 
見える化を行う際のタスクの分割をチーム全員で行うことで進捗のリアルタイムの確認という目的を達成できるレベルにタスクの粒度を分割する。開始日時、予想消費時間などの情報を記入する。
 
③毎朝の進捗確認の共有に使うことで、計画の進みや遅れを全員で共有しプロジェクトの状況確認に利用する。
 
 
 

Rails + Reactでサンプルアプリを作ってみたお話

 

Qiitaにも投稿したのですが、Rails + Reactの構成で簡単なアプリを作ってみました。


URLはこちら

qiita.com



構成とか技術的な部分最低限のことはQiitaに書いたので、こちらでは作った動機とか
所感とかについて書きたいと思います。


作った背景

もとからUIとかUXに興味があって、クライアントサイドの開発技術を高めたいという思いがありました。
そんな折にRails APIについて話していたGinza.rbやhtml5部のJSフレームワークの勉強会に参加して思うところがありました。
具体的には下記みたいなこと。

・Rails5でRailsAPIが正式にRailsに導入されるらしいし、サーバーサイドのフレームワークはどんどんAPIとしての役割が求められていくのが世の流れのような気がする。

・JSフレームワークの話聞いたけど、Reactが一番しっくりきた。
 1) 毎回新しくDOM作って差分を上書きすれば各DOMの状態とかいちいち考えなくていいよね!という考えはMVXのモデルに比べてシンプルで共感できた。

 2) あくまでViewのみを担当するライブラリで簡単そう。

 3) 最近流行りなので手を出してみたかった
(Angularの話も聞いたけど、すでに使ってる人向けの講演みたいな感じでついていけなかった)

そんなわけで、習うより慣れろ式で実際に作ってみることにしました。

 


構成

・DBと連携してデータを取ってきたり登録・更新・削除ができるCRUDなアプリケーションとして作りました。
・クライアント側は完全にjsが担当している。Railsのreact-railsとかは使わないこととしました。

最初はreact-railsを使ってrailsのgemからReactを使う方法も考えました。
ただ、RailsはあくまでAPIに徹してもらったほうが、あとあとサーバーサイドのFWだけ変えるとかクライアントサイドだけ変えるとか移植性が高くなるのではと考えたので明確に分離するようにしました。(別にRailsのViewにちょくせつ吐き出させたって実害ないのかもしれませんが・・・・・・。そこらへんはあまり評価できていないです。)


作っててはまったところ

そもそもNode.jsわかんない

Node.jsとかnpmで入れたライブラリに関する根本的な知識がたりていませんでした。というかはじめてnpm使いました。brouserify? 食べ物ですか?

require('./app-routes.jsx'); とかできない!とか1時間以上ハマって、原因が module.exportsしたファイルじゃないとrequireできないってことだと知った時は頭を抱えたくなりました。


ルーティングがわからない

ReactでSPAを作る時のルーティング方法にもいろいろ種類があるらしいと聞き、某所で紹介されていたのでなんとなくreact-routerを採用しました。
よくわかってないまま使っていたので(今もよくわかっていない部分がありそうです)、肝心な時にうごかなかったり、うごかない原因がわからなかったりと難儀しました。

いろいろ調べてたのですが、参考になったのはここらへんのサイトです。
React.jsでserver-side renderingにも対応したRouting

http://qiita.com/koba04/items/737c783f1189355e053f
React初心者のためのreact-routerの使い方

http://beck23.hatenablog.com/entry/2015/02/20/054900#2



作成してみての所感

・巷で言われていますが、Reactは大規模なアプリケーション向けのライブラリである気がしました。特にコードの記述量が減るわけではありませんでした(というかこれぐらいのサンプルアプリだと確実に増えるし)。

・ただ、DOMの状態を考えなくて済むようになるというのは大きな利点だと思います。DOMの状態を変えるロジックをいちいちJQueryで書くのは大変だし、書いたとしてもどのJSに書いたっけ?みたいな状況が減らせるのはサービスが大規模になればなるほど楽になるのではないでしょうか。

・気になったのは使っててちょっと書きづらいな、と思うことが多々あった点です。JSとHTMLを分離させないことの意義は理解しているつもりなのですが、デザイナーさんとの協業とかを考えた時、jsxの中にHTMLのようなものが記述されているあのスタイルはとっつきにくいのではないかなと思います。

・今Reactが流行ってるけど半年か1年後には別のFWが席巻してて、「まだReactで消耗してるの?」ってなりそうという意見を勉強会だったり記事だったりで散見するのですが、このReactのエンジニア以外へのとっつきにくい感からしてありえそうだなーと思いました。

・ただComponent化とかDOMの差分更新とかの考え方はおそらくこれから出てくるライブラリやFWに取り入れられていくと思うので、今のうちにそういった概念を学ぶことができたのはよかったです。

・React以外にも言えることですが、アタラシイギジュツだからって銀の弾丸にはなり得ないんだなということを改めて身をもって体験しました。そこらへんのことはユーザベースさんの技術ブログのこの記事がとても納得できたので最後に紹介したいと思います。

http://tech.uzabase.com/entry/2015/03/02/180612

 

TECH VALLEY#4グロースハックパーティ! イベントレポ

geechs, vasily, Willgate, UZABASEの人が公演するイベント、TECH VALLEYグロースハックパーティーに行ってきました。
 
TECH VALLEYというのはgeechsという会社がやっている技術イベントのことで、
過去にもいろいろな会社のエンジニアやディレクターの方を呼んで公演をしてもらっているイベントだそうです。
 
今回はそれのグロースハック版で、vasilyやUZABASEといった個人的にかなりいいと思っているアプリやサービスを作っている会社の人たちが登壇するということで、参加することにしました。

学生時代に既存のサイトのUIの改善・実装をやったことはあったけど、成果も出せず悔しい思いをしたので、何か知見が得られるといいなと思っていました。

特にサービスができあがって数年経ったフェーズで行うグロースハックとサービス立ち上げ直前からサービス立ち上げ直後のプロダクトマーケットフィットといわれる部分で行うグロースハックはほぼ別物といってよく、立ち上げ前からサービスが軌道に乗るに至るまでの過程をどう詰めていくかというところに具体的なイメージがわかなかったため、講演ではそこらへんの話が聞ければいいなと思っていました。

参加からだいぶ時間が経ってしまったけど、内容はかなり衝撃的でグロースハックに興味がある人はもちろん、これからサービス・事業を立ち上げようという人や、何かアプリを作ってみたいという人まで勉強になる内容だと思ったので、レポートを作成しました。

4社それぞれの人がディレクター、エンジニアなど様々な立場から会社でやっている手法や技術、マインドセットなどを説明してくださりとても興味深かったです。
ただ、今回は中でも一番印象に残った(自分にとってタイムリーな話題だった)Vasilyの梶谷さんのお話を要約していこうと思います。


残りの3社の方の講演については、需要がありそうだったら書き起こそうと思います(コメントか何か残してください)。


もしグロースハックとはなんぞや、というかたがいらっしゃいましたら、下記記事を参照してください。(というより、ググッた方がわかりやすい答えが見つかると思います)
http://suidenoti.hatenablog.com/entry/2015/04/26/225955
 


イベント要約

 
梶谷さんいわく、グロースハックをする上で下記2点をまず考える必要があるということでした。すなわち、

・マクロレベルの話
 自分のサービスが今どのフェーズ(AARRRモデルでどこを重視してやっていくべきところにあるのか)
 どのフェーズにいることがわかったら実際にどのKPIを見ていけばいいのか
・ミクロレベルの話
 各フェーズで具体的にどういった施策・計測を行えばいいのか
  AARRRモデルで一体なにをすればいいのか

といった点です。
 
マクロ・ミクロの内容についてそれぞれ要約していきます。


グロースハックのマクロレベル
第一声でAARRRモデルをA→A→R→R→Rの順番でやろうとすると確実に失敗するという主張から始まりました。

AARRRモデルは着手すべき順番で並べているのではなく、あくまで顧客視点でどのように行動が変化しているか時系列で並べているにすぎない。したがって、プロダクトをこの順番で成長させようとすると100%失敗する、ということだそうです。

AARRRモデルを順番通りやる最大の問題点として、

・存在しない課題を解決しようとすると製品にコストを使ってしまう
・継続されない製品にコストを使ってしまう
・収益を全く産まないコストに時間を使ってしまう

ということが挙げられ、正しいグロースの順番は下記のARRRAモデル、すなわち

アクティベーション(Activation) そもそもその価値は求められているか、初回訪問時にしっかり伝わっているか
リテンション(Retention) 使い続けてくれるくらい、製品の価値に満足してるか
レファラル(Refallal) 友人に伝えたくなるほど満足してるか
レベニュー(Revenue) お金を払ってくれるほど製品の価値に満足してくれているか
アクイジション(Aquisition) 製品の価値を広めるために、正しいチャネル・訴求軸を選べているか

であるとのことでした。

体感的には最初のActivationとRetensionが重要でこの2フェーズに注力すれば残り3フェーズは勝手に結果がついてきているとのこと。

では実際にミクロレベル(実務レベル)に落とし込んでARRRAモデルを行うとすると何をするべきか?ということで、ミクロレベルの話ではアクティベーションのフェーズに絞ってお話がありました。

ミクロレベルの話
アクティベーションのフェーズで行うべきことはプロダクト開発前とプロダクト開発後で異なってくるのだそうです。
すなわち、

・プロダクト開発前はプロブレムソリューションフィット(PSF)、要するに誰の何をどうやって解決するのか、そもそも課題が存在しているのかの検証を重視する。
・プロダクト開発後はユーザーオンボーディング、プロダクトを使ってもらってこのサービスめっちゃいい!て思ってもらうことを重視する。

ということでした。順番に見ていきましょう。
 

アクティベーションの前行程(プロダクト開発前)
まず、プロダクト開発前はPSFのために課題が存在し、顧客がそのプロダクトを求めている証拠を事前に得ることが重要だそうです。

ここで事例としてZapposという靴のECを初めて行ったサービスについて話がありました。
アメリカでは靴を買いたい人が、わざわざそれを買いに行くのは土地が広くて大変だし、セールもきいていないから高い。そこでZapposの創業チームはECで靴を販売すれば売れるのではないか?というアイデアを持っていました。しかし、本当にオンラインで靴が売れるのかが心配されていた。
そこで創業チームはまずECサイトフロントページだけ作成し発注発送は人力でやる形でサービスを開始しました。
これによってそもそもECで靴を買ってくれる顧客が存在するかを検証し、無事多くの人がサービスを利用してくれることがわかったのでバックエンドを作り込んで行ったという事例を紹介してくれた。

実際にはここまでうまくいく話ばかりではないだろうということでVasilyで行っているジャベリンボードというフレームワークを使った仮説検証方法の紹介がありました。

ジャベリンボードは日本語で検索しても出てこないがjavelin boardで検索すると画像が出ててきます。
 

こんなやつです。

gyazo.com

 

 

 

ジャベリンボードでは顧客と課題と解決方法をまず仮説として提示し、それに対するもっとも大きなリスク想定(間違っているかもしれない仮説)を考えることから始めるのだそう。

講演で挙げられていた例示だと、大学生向けの荷物預かりサービスを立ち上げようと考えている時、もっとも間違っている可能性のある仮説は一人暮らし大学生は荷物をたくさん持っているということ。(預けるほどたくさんの荷物をもっている学生はほとんどいない、ということがもっともリスキーな想定となる)

これに関して質問方法と仮説が正しいか検証するための判断基準をまず書いていく。
ここでは一人暮らし大学生に荷物が家の何%を占めているかを聞き、80%を占めている大学生が10人中6人いたらその課題は存在すると結論づける、としていました。

さらに下のセルの結果と判断では、検証結果や検証を通して学んだことを書いていく。
最初の仮説はほとんど外れているため、顧客や課題、解決方法などを更新して二回目の最大リスク想定、検証、結果確認といった形で、検証の結果、その課題が存在するという判断ができるまで仮説を反復的に磨き上げるということをVasilyでは行っているそうです。


アクティベーションの後工程(プロダクト開発後)


プロダクトができあがったあとのアクティベーションでは使ってもらってこのサービスいい!とすぐに思ってもらうことが大事で、それを実行するための考え方としてユーザーオンボーディングというものがあるのだそう。ユーザーオンボーディングは下記に挙げる3つの要素からなっている。



① ヴァリュープロポジション

プロダクトがどのような価値を提供するのか、わかりやすく伝えること。

ランディングページなどでそのサービスの本質的な価値を説明する、といった方法がある。



たとえばPinterestはLPでユースケースを伝えることで、ユーザーがPinterestを使ってどんなことができるか、どんな体験が得られるかを表示している。



たとえばこんな感じ

 

gyazo.com

 

② 利用方法の理解

どんなに価値のあるサービスでもユーザーがそのサービスの使い方を理解できなければ意味がない。

ユーザーがサービスの使い方を簡単に理解できるような何かが必要。

使い方の説明であったり、チュートリアルを自分で操作できるインタラクティブデモがこれにあたる。

 

③ Aha体験

実際のサービス利用開始後数アクションでこのサービスいい!と思わせること。

Twitterは登録と同時に5人フォローさせることで、開始後すぐにTwitterのよさを理解してもらう戦略をとっているというのは有名な話。

 

以上3点であげたような要素がユーザーオンボーディングの要素として重要で、

Vasilyではグロースキャンバスというフレームワークを使ってユーザーオンボーディングを達成しようとしている。

斜めからの画像で申し訳ないのですが、こんな感じの独自フレームワークを作成して使用しているのだそうです。

 

グロースキャンバスのフレームワーク画像

 

f:id:suidenOTI:20150427210048j:plain

 

使い方は、まず右上の鍵となる指標を決めてから定性的な分析と定量的な分析を行って最初の発見(5×6の正方形の一番左上)に記入できる気づきを探すことから始める。

たとえばVasilyのプロダクトであるiQONで今までよりユーザーの再訪率を高めたいとしたら、

 

・定量的な分析では初回登録から引き続き使用してくれているユーザーのデータと、逆に初回登録から使用してくれていないユーザーのデータを確認することで気づきを探していく(ずっと使用してくれている人の共通点と、あるいは逆に初回登録以降使用してくれていないユーザーの共通点を分析するということだと思われる)。

・定性的な分析では初回登録から引き続き使用してくれているユーザーへのインタビュー、逆に初回登録から使用してくれていないユーザーへのインタビューによって気づきを探していく。

 

・発見した気づきに関してはフレームワーク右上の、4象限のに別れた部分に一つ一つプロッティングしていく。

4つの象限を分割している二軸は、画像には記入されていないが縦軸は再現性、横軸はそれが実現された時のインパクトを表していて、再現性とインパクトが大きい順に重要度が高い気づきとしてフォーカスする、といった感じで使うそうです。

 

続いて発見した気づきに関して、表中央から下の発見、因果関係、MVP、評価指標、計測結果の部分を順次埋めていくことで検証を行っていくのがフレームワークの下側。

 

たとえば、再現性とインパクトが優れていた気づきとして「再訪してくれる人はコーディネイトを1件アップロードしてくれている」といったものがあったとする。

 

まずはこの気づきに対して再訪とコーディネイト一件作ってもらうことの間の因果関係を分析する(コーディネイトを作ってくれたから再訪してくれたのか、逆にそもそも再訪してくれるぐらい熱心な人だからコーディネイトを投稿してくれたのか。あるいは因果関係は存在せず相関があるだけなのか)。

 

これを確かめるためのMVPとして登録時にコーディネイトを一つ投稿することを強制する機能を実装し、一週間後の残存率を計測する形で仮説を検証する。

 

もし残存率が予想を下回っていたら仮説が間違っていたということであり、発見をアップデートする(フレームワークでいうと、右側にいっこずらして同じように記述をしていく。「他の人のコーディネイトを見て、自分でもコーディネイトを作ってくれているひとは再訪している」など)。

 

以上のようなフレームワークなどを駆使して因果関係をハック、検証してして本質的なグロースハックをしよう!

ということでした。