小さなごちそう

プロダクトマネジメントや日々の徒然について

日本でフリクションレス・ペイメントを実現するにはどうすれば良いのか

このところ「お金を支払う」という行為をどうすれば簡便にできるのか、ということをいつも考えている。Apple WatchApple Payを使うようになってから財布を持ち歩かなくなった。iDかSuicaが使えるところを選んで買い物をする。店員に「iDで」と伝えてApple Watchのボタンをダブルプッシュし、カードリーダーにかざせば支払い完了だ。ポケットから財布を出し、小銭を数えて手渡し、お釣りを受け取る、という現金での支払い方法と比べると格段に手間が少ない。Apple Payに慣れると、財布を持ち歩くのも面倒だし、クレジットカードを財布から出すという行為すら手間に感じる。

それまでは特にペインを感じていなかったが、一度キャッシュレスの便利さを体験してしまうと、以前の状況には戻れなくなる。iPhoneのTouch IDに慣れるとパスコード入力が面倒でたまらなくなるし、Face IDに慣れればボタンをタッチする事すら面倒になる。こうした欲求とその実現の間にある行為を極限まで無くすユーザ体験の進化は、一度慣れてしまうと以前の状態に戻ることがペインになる。

ただ残念ながら日本ではこうしたキャッシュレスな支払い体験ができる場が限定されている。飲食店や地元のスーパーなどキャッシュオンリーの所に行く時は現金をポケットに入れて行くようにしている。WeChatやアリペイを使えば露店ですらキャッシュレスで決済できる中国が羨ましい。

日本では都心ですら飲食店のクレカ決済導入率は40%程度だという。AirPayや楽天Payなどのサービスを利用すれば安価な導入コストでクレカ決済や電子マネー決済を導入できる。ただ、導入申し込みをしたが審査が通らなかった、というケースもあれば、そもそも決済手数料(3.25%〜)を支払いたくない、キャッシュフロー上支払いサイトが遅いと困る、といった店側の都合もある。過去の中国がそうであったような「偽札が多いからキャッシュレスの方が安心だ」といった事情もない。クレカ決済導入には、持ち合わせが少ない来店者を逃す機会損失が減る、顧客単価が上がる、精算を簡略化できる、といったメリットがあると言われているが、高単価商品がなかったり利益率が低い店舗にとってはクレカ決済導入の後押しにはなりにくい。つまり販売側にとってキャッシレス化を進める強い動機を作らないと、キャッシュレスのカバー率は上がらない。取引実績に応じた融資(トランザクションレンディング)を提供する決済代行事業者も多いが、小規模事業者にとって実際どれくらい強い導入動機になるのだろうか。導入動機を作るという観点でうまい仕組みだなと感じたのはOrigami Payだ。Origami Payでは決済とロイヤリティプログラムがセットになっている。導入店舗から過去に購入した顧客のスマホに割引クーポン券を配布できる。このCRM機能の活用が来店頻度の向上に繋がるという。キャッシュレス決済だけでなく、何種類ものポイントカードを持ち歩かなければならない、というロイヤリティプログラム乱立による消費者のペインも同時に解消している。(そういえば自分は財布を持ち歩かなくなったのと同時に、各種ポイントカードを破棄してしまった)

WeChatやアリペイを使えば店舗での支払いだけでなく個人間の送金もできる。米国ではPaypalやVenmoを使えば同様に個人間送金が可能だ。日本では店舗決裁のキャッシュレス化以上に、個人間送金のキャッシュレス化が進んでいない。日本でも例えばLINE PayやYahoo!マネーを使えばユーザー間で送金できる。だがそのための事前手続きとしてオンラインバンキング口座による本人確認(KYC/Know Your Customer)のプロセスが必要だ。この敷居が高い。利用している銀行が対応外だったり、対応銀行であってもオンラインバンキングの2要素認証にサービス側が対応していなかったりする。KyashやPaymoなどのKYCが不要のサービスもあるが、用途に制限がある。要は事業者には資金移動業の登録、ユーザーは本人確認の実施が必要で、技術的な制約といよりも法律上の制約で簡単には個人間送金を実現できない。

日本では「AからBにお金を移す」という行為において、手間や手数料という摩擦が生じる。この摩擦、フリクションを販売側からも購入側からも限界まで減らすにはどうすればいいのか。フリクションレスなペイメントをどうすれば実現して、広く普及させられるのだろうか。

ビットコインなどの暗号通貨を決済や個人間送金に使うのはどうか。暗号通貨ならウォレット間で第三者を介することなく送金が可能だ。導入審査も存在しない。ただ円を暗号通貨に交換するためには、やはり取引所で本人確認をを行って口座開設しなければならない。価格変動が大きいこともあり、投機的な値上がり期待でホールドしてしまうし、現状の税制では決済時に値上がり分に対して課税されてしまうこともあり、日常的な支払いに利用しづらい。その点、NEMは利用者にマイニング報酬の一部を還元するインセンティブプログラムがあり、ホールドするのではなく積極的に利用させる設計を内在させている点が面白い。アリペイの余額宝で利子がつくように一定量XEMを保持しているとXEMが増える、XEMで取引すればさらに報酬の分配率が高くなる。

なお取引所を開設する事業者は金融庁に登録が必要で、さらには立ち入り検査を求められる。また取引所で取引できる暗号通貨は、金融庁ホワイトリストに登録されたものに限られる。Ethereumを使えば簡単に独自の暗号通貨(トークン)を発行できるのだが、ホワイトリストに登録されなければ日本の取引所で取り扱ってもらうことができない。技術的にはインターネット越しにお金(価値)をやりとりする仕組みが確立しているのだが、やはり法律の制約で簡単には実現できない。利用者保護やマネーロンダリング防止のために法律は必要だが、新しい産業の発展という観点からすると規制緩和が望まれる。主体者の存在なしに暗号通貨の取引が可能な分散型取引所(DEX/Decentralized Exchange)の開発も進んでいるが、交換可能なのはトークン同士で法定通貨-トークン間の交換はできない。暗号通貨と法定通貨をCtoCで直接交換できるOTC取引の仕組みは、現行法では仮想通貨交換業に相当するのだろうか?

などど様々な観点で日本のフリクションレス・ペイメントの実現可能性について考えていると、手詰まり感を感じてしまう。現状の制約についてばかり考えていると堂々巡りになるので理想から逆算して考えてみる。

  1. 一定金額以下であれば本人確認無しで利用開始でき、スマホだけで支払いができる
  2. クレジットカードやコンビニで簡単にチャージできる
  3. 販売者に必要なものはスマホもしくはタブレットのみで導入時に審査不要
  4. 決済手数料/支払い手数料が安い
  5. 1円単位のマイクロペイメントが可能
  6. 個人間の送金ができる
  7. ネット上の決済に利用できる
  8. 単一企業のサービスの境界を越えて利用できる
  9. 販売者と消費者を繋ぐロイヤリティプログラムを備える
  10. トランザクションログは匿名化して企業がマーケティングに利用できる

もし仮に上記のような要件を満たすペイメント・インフラが実現できたら、その上でどんなアプリケーションを作れるだろうか。ブロガーやYouTuberという新しい職業が生まれたように、これまで存在しなかった職業が生まれるだろうか。

良いテックリード、悪いテックリード

本記事は、下記の記事の翻訳です。著者の許可を得て翻訳しました。


この記事はフォースクエアの技術的リーダーシップを簡潔に説明したガイドだ。
ベン・ホロウィッツの「良いプロダクトマージャー、悪いプロダクトマージャー」からインスピレーションを得ている。

チームワーク / Teamwork

良いテックリードはチームの一員として振る舞い、自分の成功とはチームが成功することだと考える。面倒で退屈な仕事の一部を担って障害物を取り除き、チームが100%のパフォーマンスで稼働できるようにする。チームの技術的能力を拡大し、システムの重要な知識が属人化しないように務める。

悪いテックリードは注目の集まる仕事で自分の成果を示すことを好む。その成果は部分最適に留まり、開発チームのアウトプットを増やすにはエンジニアの人数を増やすしかない、という状況から脱することができない。

技術的ビジョン / Technical vision

良いテックリードは技術の方向性について俯瞰したビジョンを持ち、それをチームが正しく理解できるように努める。良いテックリードは他のチームメンバーに権限を委ね、主要な事項に関してはメンバー自身の意思決定を促す。良いテックリードはチームメンバーは賢く信頼に足ると信じてプロジェクトの重要な部分の取り扱いをチームメンバーに委ねる。

悪いテックリードは説明責任を果たしたり方針を言語化して伝えることを嫌がり、自分の決定にただ従うように命令する。彼らは組織で共有すべき知識を抱え込む。ドキュメントを作って知見を広め、自分と同じくらい効率的に仕事を進められる人材を増やす、といったような活動をしない。

議論 / Discussion and debate

良いテックリード聞く耳を持ち、議論を促す。チームの議論が紛糾して収集がつかないときは、問題を解決するための考え方やフレームワークを示し、チーム自身で解に到達できるように助ける。過去の議論を蒸し返すようなことはせず、チームの出した結論の方が自分のアイデアより優れていると思った時はそれを認めて受け入れる。

悪いテックリードは結論がなかなか出ない議論をそのまま放置して、チームの生産性を損なう。あるいは「それはもう議論済みで結論が出てる」と言って議論を途中で遮る。悪いテックリードはチームが正しい結論に到達することよりも自分が議論に勝つ事を重要視する。

プロジェクトマネジメント / Project management

良いテックリードは先を見越して行動する。彼らは技術課題の解決が予定通り進捗していることを確認する。良いテックリードはチームと一緒に見積もりを行い、中間マイルストーンをたてる。懸念事項を予め明らかにし、問題が実際に起こる前に言及する。技術的な障害を特定してチームで問題解決に当たれるようにする。全体を見て同じタスクを重複して行わないようにし、逆に、注力できていない部分を見つけ出してリソースをきちんと振り分けられるようにする。

悪いテックリードは問題が起こってから対処する。彼らは権限を委譲するがその後進捗に問題ないか確認してフォローしようとはしない。中間ゴールを設定しないし、ちゃんと良い結果が生まれるかどうか気にかけず、複雑なエンド・ツー・エンドのテストを行う直前まで何もしない。興味深いものだがさして重要ではない仕事に時間を浪費することをチームに許してしまう。

f:id:tannomizuki:20180222175113j:plain
@blackmadによる素晴らしい漫画化

悪いテックリードは「その問題は解決済みだ」と言う 良いテックリードはディスカッションを促す
悪いテックリードは手柄を自分のものにしようとする 良いテックリードはチームの能力向上に努める

現実主義 / Pragmatism

良いテックリードは現実主義で、正しい事を行うことと仕事を片付けることのバランスを心得ている。時には近道を通ろうとするがそれは怠惰だからではない。最低限必要な仕組みをローンチするために、全体の進捗の妨げになっている問題を回避したり一時的に棚上げすることをチームに推奨することもある。良いテックリードにとって細部はとても重要である。コードの品質、コードレビュー、そしてテスト。こうしたことを製品を予定通り出荷するのと同じくらい重要だと考える。

悪いテックリードは短期的な視点で時間を短縮しようとして技術的負債を蓄積し、後からその分のツケを払うことになる。彼らはその場しのぎで良い状況と完璧を期さなければならない状況の区別がつかない。

コミュニケーション / Communication

良いテックリードは自分の役割がコードを書く以上のものだとということを知っている。効果的なコミュニケーションが自分の仕事に必要不可欠であり、チームがより効率的に働けるようにすることに自分の時間を割くことが求められていると理解している。チームで働く上でコミュニケーションの重複は発生してしまうものだし、チーム全体の生産性を上げるために個人的な生産性を多少犠牲にするのはやむを得ないことだと思っている。

悪いテックリードは自分自身がコードを書くことが最も生産性が高いことだと考え、コミュニケーションすることは集中の妨げになると考える。チームの生産性を最適かすることではなく自分の仕事を最適化することを重視し、チームを引っ張らなければならないことをフラストレーションを感じる。

プロダクトとの関係 / Relationship with Product

良いテックリードはプロダクトマネージャーやデザイナーとプロダクトがどうあるべきかについて会話する。同意できない意思決定に反論することを厭わないが、プロダクトのゴールを達成できるよう落とし所を意識している。良いテックリードは技術的な成約に対して独創的な回避策を見つけ、より技術的な要求が緩いプロダクトの構成を代替案として提示し、プロダクトマネージャーやデザイナーが技術的な課題を理解してトレードオフを受け入れられるよう手助けをする。

悪いテックリードはプロダクトの意思決定に無関心で、プロダクトについてオーナーシップを持とうとしない。技術的な制約があればそれは不可能だといって拒否し、代替案を提示したり理由を説明しようとしたりはしない。

柔軟性 / Resiliency

良いテックリードは仕様の変化に対して柔軟で、突発的な出来事にも穏やかに対応する。彼らは変化を予期し、変化に対応できるように設計する。

悪いテックリードは仕様変更に苛立つ。あるいは、仕様の変更が発生しそうにないところまで汎用的な設計しようとする。

性格 / Personality

良いテックリードは寛大だが自己主張ははっきりしている。悪いテックリードは対立的な態度で攻撃的だ。良いテックリードは技術的な能力や経験によって自然と尊敬を勝ち得ていく。悪いテックリードは与えられた肩書や権威によって尊敬が得られるものだと思っている。

良いテックリードは常により良くする方法を探す。悪いテックリードは他人からフィードバックを受ける時に防衛的になる。

良いテックリードは謙虚であり、自分以外のチームメンバーが確信を持てるように後押しする。悪いテックリードは傲慢であり、チームメンバーに「自分はテックリードより劣る」と認識させることに喜びを感じる。

Product Manager 1on1、その後の経過報告

昨年11月から開始したプロダクトマネージャーの方々との1on1ですが、おかげさまで沢山のお申込みを頂き、約2ヶ月で18名の方とお会いして1on1させていただきました。1年間で100回の1on1実施を目標としていますので、2ヶ月で18/100はまずまずのペースではないでしょうか。

語学レッスンアプリを提供する株式会社フラミンゴの若きCTO濱田さんからはこんな嬉しいコメントも。

 Twitterのようなオープンな場でこうしたフィードバックをいただけることは、とても励みになります。濱田さん、ありがとうございます。

お聞きした内容は決して口外しませんが、皆さんが悩まれるポイントにはいくつか共通点があるなと感じていまして、パターンを抽出して言語化してみたいと思っています。

まだ10名近くの方にお待ちいただいている状態で、これからお申込みいただいた方と1on1できるのは4月以降になる見込みですが、ご興味のある方はぜひご連絡ください。
お申込み方法や趣旨については以前の記事をご覧ください。よろしくお願いします。念のため書いておくと無料です。

しかし日程調整が本当に大変ですね😅
Twitterでご連絡いただいてやりとりしているのですが、沢山の方と平行してやりとりしているとカオスになります。。
(もし返信が漏れている方がいましたら、大変恐縮ですがご連絡ください。)

空き時間を公開してお申込みいただく方式にしたいんですが、何か良いサービスがあったら教えてください🙇

【追記1】日程調整ですが、Eventbriteでイベント作って申し込んでもらえばいいような気がしてきました。

【追記2】公開投稿でいただいたフィードバックを追記していきます。

 

「今年こそ英会話力を向上させたい!」そんなあなたにお勧めする5つのYouTubeチャネル - 2018年版

あけましておめでとうございます!
(すみません、お察しの通りタイトルはホッテントリ入りを狙った釣りです。)
さて突然ですが、今年の夏にサンフランシスコで開催されるプロダクトマネージャーのカンファレンス、Mind the Product Conferences 2018に参加したいなーと思っていまして、ちょっと英会話力を強化することにしました。(ちなみに12月のEarly Birdでチケット購入しようとしたら一瞬で売れきれてしまい購入できず、1/11からの一般販売でチケットを購入予定です)

昨年11月からオンライン英会話を始めまして、1日2レッスン受講してます。僕が利用しているのは、DMM英会話NativeCamp。DMM英会話はセルビア人の先生にBritish Englishを、NativeCampではフィリピン人の先生にAmerican Englishを習っています。
NativeCampはレッスン予約不要で、空いている時間にさっとレッスンを受けられるのがとにかく便利。毎日英語を話す、という習慣を作る上では欠かせないサービスになっています。講師は個人宅ではなくレッスン専用のオフィスに出勤しているみたい。皆んな白シャツの制服?を来ていて、講師として一定のトレーニングを受けている模様。ネット回線も安定していて通話品質についても全くストレスがありません。

nativecamp.net

フィリピンの先生は日本のアニメが好きという人が多く(社交辞令かもしれませんが)、よくNARUTOの話がでます。残念ながら北斗の拳ドラゴンボールをリアルタイムで読んでた世代なのでNARUTOは読んだことがなく、いっそこの機会に大人買いして読んでみようかと思っています。

さて、オンライン英会話だけでは語学力は向上しないので、その他の方法でも勉強をしています。最近のお気に入りは、YouTubeの英会話関係チャネル。通勤時間中と寝る前に必ず最低1本は見ています。その中からお勧めのチャネルをいくつか紹介します。(ちなみに僕はTOEICのスコアが900点ぐらいで、英語の記事を読むのはあまり不自由しないけど喋るのが苦手、というレベル感です。)

1. Rachel & Jun

www.youtube.com

日本人のジュンさんとアメリカ人のレイチェルさんというカップルによる番組。(ご夫婦のようです)日本とアメリカの文化の違いなどを英語で紹介。ちなみにジュンさんの英語の発音はネイティブクラスです。個人的には2人の馴れ初めのエピソードが微笑ましたかったですね。(日本に留学にきたレイチェルさんがジュンさんに一目惚れする、というお話)

2. English with Lucy

www.youtube.com

ルーシーさんによるイギリス英語のチャネル。British Accentを学ぶならこのチャネルがおすすめ。もちろんアクセントだけじゃなくて、単語やフレーズを学ぶこともできます。内容もさることながらルーシーさんがとてもユーモラスなので見ていて楽しいです。スペイン語を勉強した経験から第二外国語を身につける大変さも知っており、自分の語学学習経験がレッスン内容に反映されているようです。

3. ETJ English

www.youtube.com

こちらもエリオットさんによるBritish Englishのチャネル。あまり凝った演出のない個人チャネルっぽい感じですが、口の動かし方がとてもはっきりしているので、発音を学ぶのにすごく良いです。(マコーレー・カルキンに似てるけど違いますw)

4. linguamarina

www.youtube.com

Marinaさんはロシア出身でアメリカのグリーンカードを取得し、LinguaTripというスタートアップをシリコンバーレーで起業してます。ロシア訛をなくしてネイティブのように喋れるようになるまでの自分の経験をもとに色々とアドバイスしてくれます。

5. Learn English with Steve Ford

www.youtube.com

ティーブさんのアメリカ英語のチャネル。毎回フレーズを独特のオリジナルソングにして流してくれるのでかなり印象に残ります。好き。

6. Real English With Real Teachers

www.youtube.com

ハーリーさんとチャーリーさんというプロ英語教師によるチャネル。お調子者のハーリーさんとイケメンのチャーリーさんの掛け合い漫才のようなレッスンが面白い。声出して笑ってしまいます。

しまった5つじゃなくて6つだったわ。だいたい10分ぐらいの動画なのでスキマ時間にさくっと見れます。あと設定で字幕も表示できる動画もあるので、聞き取れない時でも字幕付きで何度か見れば理解できるかと思います。

おまけ

正しい発音の仕方を理解するのにお勧めの本はこちら。 

英語耳[改訂・新CD版] 発音ができるとリスニングができる

英語耳[改訂・新CD版] 発音ができるとリスニングができる

 

 個人的にはネイティブらしい発音には、母音やL/Rの発音以上に子音の発音が大事だと思うのですが、その辺がばっちり解説されてます。CD付き

あと昔も今もお世話になっているのが、DUO。これは鉄板ですね。
iPhoneに入れて歩きながら聞いています。 

DUO 3.0

DUO 3.0

 

 

 

プロダクトマネージャーに訊く #10:ウォンテッドリー久保長さん

f:id:tannomizuki:20171221151502j:plain

— まず簡単に自己紹介をお願いできますでしょうか。社内での役割、仕事内容について教えてください

ウォンテッドリー株式会社執行役員エンジニアの久保長です。Wantedly Visitというサービスのプロダクト責任者を担当しています。

ウォンテッドリーには6年前に入社しました。その前は自分で創業したスタートアップでプロダクト開発をしていて、二年間で二社のスタートアップ立ち上げを経験しました。そのあと3人目のエンジニアとして入社しました。

— どんなスタートアップの会社をやられてたんですか?

一社目はiPadを使ったレジアプリのようなものを作っていました。iPadが出たての頃です。iPadが出たことで、タッチパネルのデバイスのコストが大きく下がったことや、当時iPhoneを使っていて非常に便利だったので、それを他のビジネスシーンでも活用できるのではと思ったのが始まりでした。

— スタートアップでのビジネスは上手く行ったのでしょうか?

あまり売れず、またサポートにも苦労しました。最初無料でタッチパネルを置けばいいと考えましたが簡単には置けず、また置いた後もネットワークの設定が分からない、ハードウェアの故障など想定しない問題も多発しました。 

— 良いものを作れば売れるわけではない、と

使ってもらうことは非常に難しいことです。自分の限られた時間を費やすわけですから。

プロダクトの初期フェイズは一番重要な価値にフォーカスしてそれを研ぎ澄ますことが必要だったり、それを受け入れてくれるお客さんにサービスを提供するべきですが、エンジニアになりたての頃はそれがわかっていませんでした。

ただこの失敗経験を通して、ただ機能を作るわけでなく、「どう使ってもらうか」「どう広めていくか」まで責任を持ちたいと思うようになりました。

— ウォンテッドリーのどういうところに興味を持って入社されたのでしょうか。

当時、ウォンテッドリーには僕以外に2人、川崎と相川というエンジニアがいました。その2人がスーパーエンジニアだったので、「この2人と一緒に働きたい、この2人に追いつきたい」という気持ちで入社しました。

もちろん『シゴトでココロオドル人をふやす』というサービスのコンセプトが、良い課題の捉え方だなと素直に思えたことも大きいです。「世の中には良いチームや会社がたくさんあるが見えていない」「個人がより大きなビジョンをもった活動に取り組む機会を増やしたい」 という気持ちがありました。

もう一つはビジネスとしての成功可能性ですね。スタートアップ2社目ではクリエイター向けのポートフォリオ・サービスを作りました。その時感じたのがマネタイズの難しさです。サービスが提供する価値への対価をもらうこととのバランスを考えることの重要性を感じていました。Wantedly Visit はユーザーが働きたいという企業を並べ気軽に訪問できるようになることで、企業の採用ニーズに応えることで対価をいただくという、とてもわかりやすいサービスモデルでした。

— そもそもどういうきっかけでウォンテッドリーの存在を知ったのですか?

そもそものきっかけは代表の仲との共通友人です 。友達経由でウォンテッドリーのことを教えてもらい応募しました。訪問すると、ちょうど新サービスを立ち上げるタイミングで、6人くらいでサービス構想のブレスト・ミーティングをしていました。

— ではブレストに参加したことがきっかけでウォンテッドリーで働かないかという話になったんですね。

はい。面接ではなく、いきなりブレストの参加することになりました。自分にも意見が聞かれるなと思って、なんて答えようか考えながらそこにいたのが懐かしいです。最初は、週一ぐらいの頻度で関わっていました。「チームマネジメントの参考になればいいな」ぐらいの気持ちで関わっていたんですが、関わり始めるとサービスの面白さがわかってくるし、学ぶことも多く、どんどん深く関わるようになり、その流れでそのまま入社しました。

— 自然と巻き込まれていった、と。

そうですね、まさにWantedly Visit流です。

— 正社員は現在何人くらいいらっしゃるんですか?

今は50人くらいです。半分以上がエンジニアです。テクノロジーでスケールするサービスを作ることを意識しています。

— 一つのプロダクトに対してどういうメンバー構成で開発を進めていますか?

僕が担当しているWantedly Visitは、10人のエンジニアと2人のデザイナーで開発を行っています。エンジニアは4つのチームに分かれていますが、デザイナーばチームを横断してタスクを受け持っています。

ユーザーと企業のVisit゙を増やすGrowthチーム、企業が社内の人や事業について発信していくFeedチーム、ユーザへのスカウトを改善するScoutチーム、そして海外版Wantedly を開発するInternationalチームです。それぞれのチームのリーダーが数字に責任を持って進める、という体制にしています。

人と人との繋がりを通してビジネスを加速していく

f:id:tannomizuki:20170802204705j:plain

Wantedly Visit について教えてもらえますか?

『シゴトでココロオドル人をふやす』という課題をテクノロジーによって解決することをミッションにしています。「働くのがあまり面白くない」と思っている人も多いんじゃないでしょうか。働く時間は一生の中でも多く、その時間が面白くないことはもったいないですよね。僕は田舎の高校に通っていたんですが、勉強ができる優秀な友達は皆んな医師を志望するんです。医師も良い職業ですが、他の選択肢を知らないままキャリアを選択している。例えば、ベンチャー企業に入社して世の中を変えるようなサービスを作る、というのも優秀な人にとっての選択肢の一つだと思うのです。でも大学に進学して卒業して就職してから始めて複数の選択肢があったことに気づく。僕もそうでしたが選択肢を知る機会がないんです。

世の中を変えるために突き進んでいくような会社に、良い人が普通に入っていける。そういうところがWantedly Visitの社会的な存在意義だと思っています。

ウォンテッドリーでは Wantedly Visit 以外にも様々なサービスを提供していますね。

人と人との繋がりを軸にして仕事を面白くしていくサービスを提供しています。別の言い方をすると、繋がりを通してビジネスを加速していく「ビジネスSNS」 を作ることを目指しています。例えば、名刺管理Wantedly Peopleを使えば、名刺を撮影するだけで簡単に人との繋がりを作っていける。チャットサービスWantedly ChatもビジネスSNSを実現するコンセプトの一環として提供しています。

—HR(人事領域)の会社、という認識はあまりないのですね。

Wantedly VisitについてはHRの要素が強いサービスですが、全社で見るとHRに 特化しているわけではありません。Wantedly Visitについても、企業の採用担当者のためのサービスというより、「気軽に話を聞きに行ける」「外からは見えにくい会社の中のことがわかる」というユーザー体験を大事にしているサービスです。

Wantedly Visit を他の転職サービスと比べた時の特徴は?

一番の特徴は、採用面接の前に「話を聞きに行く」というスタイルを確立したところだと思います。ユーザーからすると最初に企業への興味が高くない状態で、履歴書を出すのでなく、もっと気軽に企業に訪問できるようになったのは大きな違いだと感じています。
また、たくさんお金を払った企業が上位に表示されるわけでなく、ユーザーが応募したい、応援したいと思う募集が上位に表示されます。採用担当者は、自社をアピールする写真を撮ったり、面白いタイトルを考える必要があります。採用したいと思う人が魅力を感じてくれるような文章を書かないといけません。

 — ただ自分の会社の魅力を言語化するって難しいですよね。

難しいです。でもやっぱり社員全員が自社の魅力を語れる会社が強いと思うんですよ。
代表の仲が社員向けに゙書いたCulture Bookに、“レンガ職人”の話が書かれています。レンガを積む作業をしている人に「あなたは何の仕事をやっていますか?」と尋ねた時に、ある人は「レンガを積んでます」と答え、また別の人は「偉大なお城の門を作っているところです」と答えた、という話です。

「レンガを積んでいる」と答える人と「偉大なお城を作っている」と答える人とでは、仕事に対する意欲に大きな違いがあります。身の回りの社会人にどんな仕事をしているのか聞いた時に「レンガを積んでいる」と答える人がまだまだ多いんじゃないでしょうか。会社の魅力を社員が語れる、というのは「偉大なお城を作っています」と答えられる人が増えるということと同じだと思っています。

レンガを積む仕事よりは、偉大なお城を作る仕事のほうが絶対に楽しいはずです。僕らがやってることは単にユーザーと企業をマッチングすることではなく、『シゴトでココロオドル人をふやす』ことです。それがWantedly Visitの最大の意義だと思っています。

— 皆さんその難しさをどうやって乗り越えているんでしょうか。フォーマットにそ って書けば良いというわけではないと思いますが。

うまくいっている企業の口コミがモチベーションになっています。

自社の魅力をユーザーに伝えることができずに契約を終了してしまう顧客もいます。一方で、そうした企業の中にも他社の成功例を見て再度トライしてくださるケースも増えています。

ユーザーに魅力をうまく伝えられる企業が使ってくれれば良い、と考えているところはあります。ちょっと押しつけがましいんですが、我々は「こうあるべきだ」という思いが強いサービスを提供しています。企業の採用のあり方を変えていきたい、ユーザー・ファーストのサービスでありたい、と常に考えています。

— 海外展開も進められていますが、海外でも「なぜやるのか」とWhyを明確にするカルチャーはまだ無いんでしょうか?

海外でも旧来のジョブメディアは「なぜやるのか」がない職務定義だけのメディアが多いのですが、スタートアップ向けのメディアは事業やプロダクトへのパッションをまず書いたうえで職務定義を記載するという形式のサービスが増えてきています。

シンガポールでWantedly Visitの海外版の展開を進めていますが、同じコンセプトが海外でも通用するのではないかという手応えを感じているところです。

「全員がプロダクトマネージャー」が理想のチーム

— 久保長さんは入社直後はエンジニアとしてプロダクト開発に関わっていたわけですよね。プロダクトマネジメントについて意識されるようになったのはいつくらいですか?

2014年の9月に執行役員に選出され、プロダクト全体に責任があるという立場になってからです。

Wantedly Tech Book 1 の中で、プロダクトマネジメントの章の執筆を担当されていますね。数ページの中にすごくコンパクトにプロタクトマネジメントのエッセンス がまとめられていると感じました。

ありがとうございます。自分の体験を元に書いたので、一般的なプロダクトマネジメントの方法論として正しいか分かりませんが、自分が学んできたものを言語化してマッピングしたところTech Book に書いたような内容になりました。

f:id:tannomizuki:20171221151428j:plain

具体的にはユーザーをグロースさせていく方法、クライアントをグロースさせていく方法、0→1でプロダクトを作っていく方法、などまとめています。

— プロダクトを作るところまでではなく、その価値を伝えるところまでがプロダクトマネジメントであると書かれていますね。

プロダクトを「作って終わり」というのことがよくあります。ユーザーにプロダクトを使い続けてもらうのは本当に大変です。プロダクトを実際に多くのユーザーが使ってくれるようになるまでには、プロダクトを作るのにかけた時間の10倍くらい時間がかかるものだと思っています。ですからプロダクトを実際に使ってもらうことをプロダクトマネジメントのゴール設定にすべきです。 

— Tech Book には「プロダクトマネジメント」について書かれていますが、「プロダクトマネージャー」という言葉は出てきませんね。プロダクトマネージャーの役割を定義するとすれば、どのようなものになりますか?

プロダクトを目標のスピードで成長させ、技術面でも強いチームを作ることです。

何をどの期間で作るかは、開発の中身にも影響します。そのため、プロダクトリーダーが開発を理解することは必要だと考えています。また、強い開発チームがあれば最終的に改善の速度は上がり、いいエンジニアも集まります。

その上で、理想のプロダクトマネージャー像は、一人で全て把握してコントロールできる人というよりは、学習するチームを作ることができる人だと考えています。学習するチ ームとは、「プロダクト開発における意思決定ができる人」が育つということです。

— 「全員がプロダクトマネージャーであるべき」ということでしょうか。

はい、サービス開発するエンジニアはプロダクトマネージャーに近づいていくのが理想だと思っています。ユーザーに対して深い理解があり、自分が担当する機能に詳しくなっていくことです。

エンジニアに限らず、ビジネス側の人であってもプロダクトを知っている方が良いと思います。どの職能のメンバーも自分の担当分野だけでなくプロダクトの理解が深めることで、プロダクトチームとコミュニケーションしやすくなり、プロダクトのコンセプトがそれぞれの職務でも浸透するからです。

Facebookのグロースチームでは個々の社員がそれぞれ成果を競い合う文化がある、と聞いたことがあります。Wantedlyのグロースチームも一人で何でもできるようにしたいと考えています。開発も分析もマーケティン グも周りにサポートしてくれる人も基盤もある。そうしたチームを理想としています。

ユーザーは「機能」ではなく「結果」を求めている

— メンバーが企画した施策のレビューはするのでしょうか?

レビューは毎週の1on1でチームのリーダーと行なっています。プロダクトとしての価値の共有や開発期間の切り方や施策の結果の共有を行なっています。施策の期待値のフィードバックも行いますが、施策の意思決定は最後は自分でなくチームのリーダーにしてもらいます。

— 確かに自分で意思決定して結果に責任を持たないと成長につながらないと思います。

そうですね。ある程度ユーザー数の規模があるとA/Bテストもしやすいですし、 今はリーダーの裁量に任せて仮説検証を繰り返す、というやり方で進めやすいフェーズです。

— そうは言っても施策によっては売上にネガティブなインパクトが発生してしまう可能性がありますよね。プロダクトの不具合によって顧客に迷惑をかけてしまう可能性はありませんか?

不具合に関しては開発の基盤やフローを改善して起きにくい仕組みを作っています。
施策は顧客への大きなものは、リリース前に自分の確認や社内確認のフェイズを入れてリリースしています。

— メンバーやチームの裁量に任せる、という考え方を持つに至ったのはどういう 経緯でしょうか。企業文化に基づくものだとは思いますが、久保長さんご自身がそう考えるようになったきっかけはありますか?

プロダクトを作る上で開発の質も重要で、開発の質とプロダクトの質のバランスをとるためにはエンジニアリングに深い知識を持つ必要があります。その上で、エンジニアがプロダクトをマネジメントしていけるように育つ方が良いと思っています。

— 顧客のインサイトはどのようにして把握していますか?例えば Wantedly Visit だと企業の採用担当者が顧客になると思いますか。゙

ビジネスチーム全員がGitHubで開発進捗を把握できるissueが作れる文化を作っており、日々声が聞きやすくしています。

一方で、転職の感覚は人や企業によって大きく変わるので、顧客の声から意思決定するよりも、最終的にはデータを見て判断するようにしています。

— 採用担当者と個人とではどちらの要望を優先しますか?

個人です。従来のメディアが採用担当者に目線を向けているので、ユーザーに常に目線を向けようとしています。

— ただ採用企業と対面しているビジネスチームを通じて、機能追加のリクエストが来ることもあるのではないでしょうか

もちろんあります。機能リクエストは常に受け付けており、各チームに伝えます。
とはいえ、メインのKPIに影響しないものは取り組みにくいので、負債返済日、UX改善プロジェクト、営業に役に立つ数字出しコンテストのようなイベント形式で1-2日全員のリソースを一気に当てて改善します。

— 最終的には数字で判断、とのことですが、データ分析の環境が整っているということでしょうか。

ログデータはTreasure Dataを通して全てを収集し、BigQueryに入れて分析します。分析結果はDomoというBIツールで可視化しており、BigQueryだけでなくDBやGoogleスプレッドシートなどからもデータも可視化しています。また、A/Bテストの結果はリアルタイムに把握できる基盤があります。

— 組織づくりやチームビルディングする上で心がけていることはありますか?

1on1を通じた育成を重視しています。5人ルールという制度があり、リーダーは5人までメンバーを見ることができます。人数を絞ることで、一人一人としっかり1on1ができる、マネジメント以外にも時間をかけられるようにしています。
また、全社的に他のチームに自分の成果を伝えることを重視しています。Demo Day と呼んでいるイベントでは、取り組んだ施策はなぜ行なったのか、どのような成果を生み出したか全社員に向けて発表します。

— 文化形成を意識した組織づくりをしているということですね。

はい。最終的には文化が浸透しているチームの方が強く、プロダクト作りにも大きく関係してきます。

良いプロダクトを作るために重要な3つのこと

— 「メンバーにはフレームワークを伝える」といったお話がありましたが、久保長さんが考える「良いプロダクトを作る上で定石」のようなものがあれば教えてください。

「最短距離で最大のインパクトを出すこと」「学習し続けるチームを作ること」「今取り組むべきことを見極めること」の3つを心がけています。

— 具体的にどうすればいいのでしょうか。

「最短距離で最大のインパクト」を出すためには、アイディアをたくさん出してそのアイディアがどのくらいの確度で成功するのか数値で評価し、上から順に実施していくことです。これをどれだけ繰り返せるかです。

「学習し続けるチーム」にするためには、意思決定を行わせる、失敗できる土壌を作ることです。

「今取り組むべきことを見極める」はもっとも重要だけどすぐには結果が分かりにくいものです。大きな決断をした時には半年後くらいに自分の判断が正しかったのか振り返るようにしています。過去の意思決定を振り返ることで、「見極め力」を改善するようにしています。

— 社内のステークホルダーとはどのように調整を行っていますか?

代表の仲とは週一で1on1を行なっています。意思決定を行う必要がある時は、組織も小さいので関係者を集めて一気に決断するようにしています。また、連携が必要なチームのリーダーは定期的に1on1をするようにしています。 

— これからプロダクトマネンジメントを担当する人にお勧めの本があれば教えてください。

二つあります。一つが「イシューから始めよ」という安宅さんの本です。 

イシューからはじめよ―知的生産の「シンプルな本質」

イシューからはじめよ―知的生産の「シンプルな本質」

 

 この本には今取り組むべきこと、つまりイシューを見極めることが大事であると書かれています。イシュー度×アウトプットの質でソリューションの精度が決まる、と。だからイシュー度が高くないと、いかにアウトプットの質が高くても、ソリューションとしては失敗してしまいます。「今取り組むべきことを見極めること」もこの本に書かれていたことです。

もう一つは「考えなしの行動?」というデザイン思考関係の本です。プロダクトが意図しない使われ方をしている例がイラストで描かれていています。 

考えなしの行動?

考えなしの行動?

 

「ユーザーの変な使い方」は新しいソリューションのヒントであるということです。未解決の課題があり、ユーザー自身がそれを 解決する手段を生み出しているわけです。ユーザーが課題を認識していて、自ら解決する道具を作り、それが機能している。この三つが揃ってるということは、ソリュ ーションとして筋が良い、ということです。

— 最後に記事の読者にメッセージがありましたらお願いします。

ぜひ一度Wantedly Visitを使ってみてください。 もちろんウォンテッドリーに話を聞きに来ていただくことも大歓迎です!!

— ありがとうございました。

 

 

 

【Product Manager 1on1】参加者募集のお知らせ

現役プロダクトマネージャーとして活躍中の皆さんのお悩み相談会(1on1)を、2018年の11月末までに100回実施いたします。

時間:1h〜1.5h
場所:弊社会議室(渋谷駅徒歩5分)
時間帯:日中あるいは20:00ぐらいまで
ゴール:ご自身の悩みや課題についてお話を伺い、その過程で解決方法やNext Actionに気づいていただく
申込方法:TwitterのDMにてご連絡ください 下記のイベントページからお申込みください。

【2018/03/10追記】4月分の空き枠が残りわずかです。5月枠の追加をTwitterでお知らせしますので、ご興味のある方はフォローをお願いします。

一応書いておきますが、無料でお受けします。2017年12月2日現在、4名の方にお申込みいただき、2名の方と実際に1on1させていただきました。ご不明点があれば同じくTwitterのDMかMentionで聞いてください。

お聞きしたことは口外しません。話せる範囲、話したい範囲でお話しいただければ結構です。ただし、具体的なアドバイスは期待しないでください。もちろん私の知っている範囲で参考になりそうなことがあればお伝えしますが、対話を通じてご自身で問題を整理していただくことがこの1on1のゴールとなります。

【2017/12/03 追記】沢山の方からご連絡をいただいており、1on1実施まで1ヶ月くらいお待ちいただく可能性があります。申し訳ありません。ご連絡いただいた順に日程調整させていただきます。

なぜやるのか

なぜこの1on1をやるのか。理由は沢山あるのですが、いくつかピックアップしてご説明します。

約12年間プロダクトマネージャーとして「プロダクトを作る」ということに向き合ってきました。これからもプロダクトを作ることに向き合い続けたいと思いますが、最近様々なことをきっかけに、
・「プロダクトを作る人」を作る
・「プロダクトを作る組織」を作る
・「プロダクトを作る地域」を作る
といったことに貢献したい、という思いが強くなってきました。この1on1では「プロダクトを作る人」を支援できればと考えております。

実際、プロダクトマネージャーとして孤軍奮闘している人も多いと思います。
・相談したいけど相談相手がいない。
・社内でプロダクトマネージャーが自分だけしかいない。
・実質プロダクトマネージャーをやっているのだが、PM制度が明確に導入されていないので社内で動きづらい
などなど。そうした方のサポートができると幸いです。

また、これまで色々なプロダクトマネージャーの方の考え方をお聞きするために「PMインタビュー」を実施し、記事化してきたのですが、記事作成に時間がかかりどんなに頑張っても1年間に5人くらいしかお会いできない、というジレンマがありました。記事化することでプロダクトマネジメントに関する知見を日本の中で共有したい、という思いがあったのですが、記事化については一旦お休みし、とにかく沢山のPMの方とお話しすることに集中してみることにしました。

もう一つ。最近「コーアクティブ・コーチング」というコーチングのメソッドを習いました。自分のコーチング力を鍛える実践の場とさせていただきたい、という私自身の都合もあります。

いろいろ書きましたが、要は「面白そうだからやってみたい」の一言に尽きます。

私について(簡単な自己紹介)

ってお前誰やねんと思われる方も多い(というか殆ど)だと思いますので、簡単に自己紹介をしておきます。

早稲田大学理工学部卒業後、NTTに入社
・茨城の研究所に配属され、主にロボティクスの研究に従事
・NTTを約3年で退職し、数年間自分探しの旅にでる
・バーチャレクス・コンサルティングに入社し、コールセンター運営に関するシステム開発に従事
サイボウズでプロダクトマネージャーとして8年間勤務
・2014年6月よりビズリーチ勤務
・2016年より実行委員としてプロダクトマネージャーカンファレンスを開催

自分がスーパーすごいPMであるという認識は全くないのですが、それなりの年数に渡ってプロダクトマネジメントに従事してきたので、話し相手としては少しはお役に立てるのではないかと思います。

プライベートなことも少々。4人家族でと息子がいます。あとバイクと車が好きです。最近はオンライン英会話にはまっています。

その他やってみたいこと

1on1させていただいた人向けのミートアップをいつかやりたいと思っています。
また1on1に参加いただいた方同士の交流の場として、Facebookグループを用意する予定です。(10人くらいになってから?🤔)
こうした取り組みと合わせて、「プロダクトを作る地域」を作る、といったところまで実現できたらなーと思っております。

以上です。ぜひお気軽にご連絡ください。

関連エントリー

Frictionless Customer Experience の3原則

1. 顧客が欲しいと言う前に与えよ
2. プロダクトがユーザーの置かれている状況に合わせよ
3. ユーザーに画面やボタンをタッチさせるな

Face IDもApple Payも要はこれ。無くても困らないけど一度慣れると戻れない。意図と結果の間の手間をどれだけ減らせるか、いかに時間やお金を消耗させないか。

ガジェット以外の例だと、車のパワーシートが鍵のオーナーに合わせて自動的に記憶されたポジションに動くのもFCX。