ku-sukeのブログ

Just another hatena blog

サービス運営時の料金設定に関する5つのポイント

先日、こんなtweetをしたらおもったよりRTされてしまったので、他にも過去の経験で値付けについて学んだことを書いてみたいと思います。多くは行動経済学の本とかに出てくると思うのですが、実例ベースで。

サービス設計で値付けに迷ったり、そもそも課金モデルにするか広告モデルにするか悩んでるときの一助となればと思います。

1.周囲の値段との「差」を意識して引きずられてしまう。

f:id:ku-suke:20170108005814p:plain

アンカリング効果というやつですね。ぼくがマーケティングの世界に興味を持ち始めたiPhoneアプリ黎明期に社内で話が出ていました。AppStoreで、有料アプリランキングに100円アプリが並んでいると、300円がすごく高く見えてしまう。

しかし、300円で買い切りで何年も使えるって普通に安いですよね。スタバのカフェラテより安いじゃないですか。

逆に、3千円の上コース、1500円のセット、900円の単品とか松竹梅で並べられると、1500円と900円の2択の時より1500円を選ぶ人が増えるようです。

なので、ユーザーがその製品カテゴリの価格にどのようなものを期待しているかどうかで、値付けは変えないといけません。

価格の方を動かせない(コスト構造上無理!)となると、サービス側の建付け、見せ方を変えて製品カテゴリの方をずらす必要があります。他のサービスと比較表に入れられないように逃げるのです。

2.ソシャゲは富の分配か?極端な客単価の差を生み出す時代

こちらが先のツイートになります。他の例では海外の月額系サービスで、数年前から「結構いい値段するな・・」「ちょっと高いな」と感じるようになったのですが、自身でも法人向けのASPサービスを何年か前に運営してみて、その理由に気づきました。

無料プランのユーザーを養うには、有料ユーザーに10人分は最低払ってもらわないと困るんです。無料ユーザだって最低限のサーバリソースと、問い合わせ対応などの人的コストがかかります。更に人数だって多いし、、、。そのコストは有料ユーザに払ってもらうしかありません。

なので、フリープランがない(○日間フリートライアルは別)サービスは、意外と価格の段階が緩やかなのですが、フリープランがあるサービスは、オトクな売れ筋プランを一歩超えると急激にボッタクリ感が出る気がします。

もちろん、それらの背景に対しては、ごく一部の大企業しか利用しない機能をわざわざ作ってあげてるんだからコレくらいは払ってね、というコストから逆算した設計ももちろんあると思いますが。

3.原価率は素人の肌感より低く押さえる。値付けには宣伝費を考慮しておくこと。

こちらは自身の運営ではないのですが、とある企業では月額3000円の商品の購入者を得るために、無料またはほぼ赤字の価格でまずはトライアル購入を獲得します。が、その獲得コストが1人あたり1万円弱とか広告費使っていたりします。

つまり、予測されるLTV1万円の場合に、それを少し下回る広告費でトライアル獲得できれば良いという考えです。LTVとは簡単にいうと課金額×継続率で、50%の確率で12か月毎月買ってくれるので、利益2万円として×50%の1万円という式になります。

この場合、12ヶ月3万6000円の売り上げで利益が2万円なので、原価は約1万6000円、44%です。製造以外にかかる費用が50%とすると純粋な原価は22%ですね。素人考えではぼったくりな気もしますが、業界によっては流通コストなどにより純粋な原価に22%もかけたら大赤字というところもあるでしょう。

広告費をどれくらい使うかと、単発ではなく継続した売り上げがどの程度入ってくるかも逆算して値付けをしないといけないのです。

4.割引ではなく追加でプレゼントする

売値1万円、原価5000円の商品を15%引きで売るのと、1万円に20%ポイントをつけるのはどちらがサービス運営側にとってお得でしょうか。

なお、資金決済法があるのでポイントは半年で消滅する、あるいは市価で20%相当の品でも構いません(ポイントを行使すると考えれば同じですね)。

  • 1万円の商品を15%割引にすると、売り上げ=8500円、利益3500円です。
  • 20%のポイントを提供すると、まず売り上げ1万円、利益5000円、会計上の負債が2000円になります。
    • その後、半年たって失効すると、負債が消えます。
    • ポイントではなくおまけを提供すると、2000円の商品の原価が利益から消えます。ここで原価が1000円の商品の場合利益が(5000-1000で)4000円になり、15%より提供側がお得になります。

 ここで重要なのは、見かけ上15%引きより20%プレゼントのほうが買う側からみて何となくお得そうに見えるのに、提供側からすると割り引くよりプレゼントしたほうがお得ということになります。

 しかも、ポイントの場合は会員囲い込みで再来訪の可能性が上がりますし、Dropboxみたいなデジタルサービスは、上限容量をひきあげても、上限いっぱいまで使うユーザは少ないので実際の原価負担は大幅に少ないと考えられます。

5.本質的な価値とお金を払う価値は違う事もある

以前、1万円の価値(と企業規模と業務システム)のはなし というエントリを書いたのですが、使いたいサービスがあっても企業でクレジットカードが使えないからちょっと、、という話です。

ここではサービスの価値(使いたいクラウド)と、お金を払う価値(日本の商習慣にマッチしている)が微妙に異なってるといえます。

また、個人的にシステムのコンサルをしていた時も、自分が楽勝だけど利益率が高い部分(たとえば簡単なプログラミング)と、自分がめっちゃ頑張るし価値があると考えてる部分(戦略立案と調査とか)に難色を示されて結局サービスでやったりといったことがありました。

顧客に理解してもらえないけど大事なポイントを無償あるいは安く提供するために、顧客が理解してお金を気持ちよく払ってくれる部分で多めに利益を確保するということが双方にとって幸せなのだなと感じました。

 

以上、商品のプライシングは難しいとよく言われますが、自分で感じたことを整理してみました。

2016年の振り返りと今年の抱負

あけましておめでとうございます。ことしは帰省せず家族でゆっくりと正月を過ごしています。昨日は東京観光しようとお台場行きました。空いていてよかったです。

2016年の振り返り

転職~東京に引っ越し

2016年1月から現職でお仕事を始めました、それに合わせて忙しい年始に引っ越しを強行しました。子供は小学1年生なので、昔住んでいた練馬区に着地しました。

最初に住んだ家の管理会社がとても残念な感じで、引っ越し搬入時にもらったカギでドアが開かない(交換忘れ)、掃除も微妙ということで波乱のスタートでした。

また、会社のほうも入社即インフルで、実質2月からのお仕事開始でした。

家を買った

前述のとおり管理会社の不信感MAXだったのと、東京の賃貸たけええええってなったのと、同一学区内に中古のマンションが出ていたこともあり、東京に引っ越しして1か月くらいで家を買いました。マイナス金利のおかげで勤続1か月でもローン通りました。

通勤は大阪時代よりかなり遠くなりましたが、1-2時間くらい早く退社できているのでトントンというところです。

久しぶりに新規事業チャレンジ

仕事内容は教育系の事業部の新規事業で、いわゆるβリリースが終わったフェーズのプロダクトのプロダクトオーナーを担当することになりました。人数構成としてプロデューサーというか企画側が多いなぁという印象で、前職だとプロデューサーが1人なんだけど、こちらは兼務も含み実質2人半くらいいる感じでした。

プログラムは外部パートナーさん製で、えいやで突貫工事したものだったので、それを内製巻取りするところからでした。よくプロダクトのフェーズで、0-1、1-10、10-100みたいな分け方があると思いますが、そういう意味では今のプロダクトは1-10のところで、1年間かけて1→7くらいまで持ってこれたと思います。割と一番得意なフェーズです。

チーム作りの変遷

新規事業ですが内製エンジニアの数も、3人くらいだったのが兼務などこみで15人くらいになりました。最初は属人化MAXで、最近はチームの安定化、自走化をめざしてそちらにリソースを割いています。アジャイルコーチにも来てもらってます。チーム作り自体はやる気のあるエンジニア勢に丸投げしてただけですが、彼らがやりたいといってきたときに、いいよと答えるbotとなっています。

基本的に新規事業というのは、コアメンバーが突如異動しちゃうリスクに常にさらされているので、スローガンは「(自分を含む)誰かがいなくなっても生き延びられるチームにしよう」ということを言い続けていました。

プロダクトマネージャとしての活動

プロダクトオーナーというのはスクラムの概念で、もう少し広いプロダクトマネージャというものにも領域を広げていて、pmjpのSlackでPMになるためのスキルセット勉強会というのをさせていただいたりしました。あとはこういうまじめな内容で100ブクマ超えてご機嫌な先日のエントリとか↓

blog.ku-suke.jp

本を出した

関係各位に根気強く付き合ってもらったアプリマーケティング本をリリースしました。これ関係で講師やコンサルのお仕事もいただきありがたい限りです。

 

スマートフォンアプリマーケティング 現場の教科書

スマートフォンアプリマーケティング 現場の教科書

 

 

2017年の抱負

わたしいま通信の大学院に通ってるのですが、なんとか卒業したいなということで冬休みも卒業研究の資料作りに追われています。

あとは本業のほうもいよいよ次のフェーズに進むので、しっかり定量目標にコミットすることと、引き続き限られたリソースの中でユーザーにとって良いものをお届けしたいです。

副業のほうも東京来てからコンサル、講師、システム系のご相談を中心にいくつかご依頼いただきましたが、ご協力できる範囲で引き続きお受けしていこうと思います。現職はやっぱり法人持ってるよー、つくったよーっていう人がちらほらいて、やっぱりすごいなーと思います。

総括としては、ことしは今まで学んだことを生かして、成果を上げる刈り取りの年にして、来年からまた種をまく、しっかりしゃがむための体力をつけたいと思います。

最後に、今年は慣れない環境の中、公私ともにたくさんの方に助けてもらいっぱなしでした。お礼を申し上げるとともに、今年もどうぞよろしくお願いいたします。

「基礎から学ぶ チーム開発の成功法則」を読んだ

 こちらの本を献本いただいたのでさっそく読んでみました。

基礎から学ぶ チーム開発の成功法則 (開発現場の教科書)

基礎から学ぶ チーム開発の成功法則 (開発現場の教科書)

 

 こんなんじゃだめだ!スクラム(or XXX)やらなきゃ!の前に

今年は会社にスクラムのPO研修受けさせてもらって無事POになったんですが、本業のほうはいま10人くらいの制作チームにまで成長して、Qごとにチーム運営方法を整備したり変えて行ったりと非常に大変な1年だったなと思っております。

また、いくつかの開発現場にコンサル的な形でおじゃまさせていただいて、特に東京だからかもしれませんが、いわゆる本書のような「チーム開発の運営」ができる人材というのはほとんどいないなと。

まだまだCIだったり、デザイナーとエンジニアとコラボしたりっていうのを「経験」として持っていて、かつ言語化できるひとというのは希少だと感じています。

そういう人がいない現場では何が起こるかというと「なんかわからんけどおかしい!!」という風になるわけです。その矛先は、無差別に新しい要件を持ってくる上の人だったり、逆に○○しかやりません!みたいに硬直化するメンバーだったり様々ですが、解決策がわからないと「この状況を打破するにはスクラムしかない」といった銀の弾丸思考になりがちです。

開発手法だけでなく、ツール、コミュニケーションまで踏み込んだ一冊

その点で本書は、チーム開発を取り巻く「やるべきこと」にどのようなものがあればいいのか、幅広い観点で書かれています。

Chapter 1 チーム開発の概要
チーム開発手法の概略と、開発手法を利用する上で何が重要であるかを解説します。
Chapter 2 チームの役割
チームに必要とされる人材とそれぞれの役割を説明し、チームの全体像を描けるように解説します。
Chapter 3 チーム開発に使うツール
数多く公開されている開発ツールから最低限必要なツールを紹介し、チーム開発への導入を解説します。
Chapter 4 チームでのデザイン制作
チームデザインで発生する各種作業の内容や、制作する成果物を解説します。
Chapter 5 コーディング
効率よく実装し品質を向上させる、コーディング方法やコードレビュー、ユニットテストの重要性などを解説します。
Chapter 6 自動化とリリース
ビルドからサービスのリリースに至るまで、継続的インテグレーションとデリバリー、プロモーションなどを解説します。
Chapter 7 チームのライフサイクル
チームのライフサイクルを解説し、高い生産性を誇る安定したチームを作成する術を解説します。
Chapter 8 チーム開発のフロー
サービスがリリースされるまでのフローを、自社開発と受託開発それぞれの視点から解説します。

 「コードレビューしたほうがいいよね」「Jenkins立てて自動化したほうがいいよね」「振り返りやったほうがいいよね」という一度は聞いたことがある、そしてやったほうがよさそう系の事が網羅されています。

さらにはツールにも言及されていて、Backlogを使うのか、Confluenceを使うのか、GithubWikiを使うのかといった点も、経験が少ないチームにはその入口として役に立つと思います。どうしてもツール導入には学習コストが伴うので、疑心暗鬼のまま進むと身につきにくいし。

プロデューサー・エンジニア・デザイナーがどうコラボするか

本書は幅広い内容を網羅した内容となっていますが、最後のChapter08を最初に読むのもいいかもしれないです。自社企画を進める場合や受託の場合など一通りの流れが書いてあって、それぞれの場合にどこを読めばいいかが示されています。

本書に興味を持つのは、現場に課題感を持つエンジニアだったりすることが多いと思うので、まずは視野を広げて、別の職種がどういう仕事をやっているかも俯瞰することが、ボトルネック改善の第一歩になるのではないでしょうか。

どうしても、強い危機感・課題感とぱっと目についた開発手法が組み合わさって、非常に狭い範囲での部分最適に陥ってしまうことが往々にあるので、本書のような全体を網羅した本を何度もパラパラとめくる、あるいはチームで輪読することで、自分たちがまずやるべきことが見えてくるのではないかと思います。

冬休みの読書にお勧めの一冊です!

 

基礎から学ぶ チーム開発の成功法則 (開発現場の教科書)

基礎から学ぶ チーム開発の成功法則 (開発現場の教科書)

 

 

 

HP Spectre x360(USモデル)買ったぞ、これはいいぞレビュー

 ついに届きました!HPのSpectre x360のUSモデル。最高です。

f:id:ku-suke:20161211184035j:plain f:id:ku-suke:20161211184047j:plain

開封の儀をしようと思ったけど、さっさと使ってしました。hpロゴが主張しなくてよい感じです。

重さは、個人的にはやや重いです。MacBook Air 2011からの乗り換えなので、約200g重くなりました。会社で使ってるVaio Pro 13 mk2と比べると体感でかなり重くなったイメージです。

スペックをおさらいすると

  • CPU Intel Core i7 7500U(Kaby Lake)
  • メモリ 16GB
  • SSD 512GB NVMe
  • USB Type-C x 2 / USB-3.0 x 1
  • 重量 1.29kg
 

f:id:ku-suke:20161211184102j:plain

ついにUSキーボードデビューしました。打鍵感はめちゃくちゃ良いです。シルバーで統一されているので、なんか一昔前のMacみたいなかんじです。PowerBook12インチってこんな感じでしたねw

トラックパッドもガラス製で、これがWindowsか・・というくらいなめらかです。上下だけでなく左右スクロールもなめらかです。キーボードレイアウトの右端にいろいろついているのはまだ慣れないですが、USキーボードはすぐになれました。ブラインドタッチもこれを機に習得してみようと思います。

f:id:ku-suke:20161211184122j:plain

なんか革製のスリーブもついています。まぁいいんじゃないでしょうか。

外で使ってみた

f:id:ku-suke:20161211184138j:plain

子供を英語の習い事に送って待っている間、マクドで時間を過ごします。左側に従来のUSB-3.0ポートがついているので、ちょっとしたiPhoneの充電など従来のケーブルが利用できてよいです。しばらくはまだケーブル買い替えずに済みそうなのと、ちょっと人に借りるときにも便利そうです。(右側はUSB Type-C×2、Thunderbolt 3対応)

f:id:ku-suke:20161211184148j:plain

せっかくなので2 in 1のフォームで使ってみました。完全にひっくり返して閉じてしまうタブレットモードは意外と重たく、画面の端を誤タップしてしまうので、そこまで使うかわかりませんが、気に入ったのがこのモードです。

画面が手前に表示されるので、最近視力の落ちてきたおじさんがKindleのコンテンツを読むのに適しています。だらだらできます。タブレットをスタンドに立てかける感じですね。13インチなので画面も文字サイズも大きいです。

意外とましになったWindowsの高解像度・フォント対応

前回の記事で、あと3年くらいはかかりそうと書いたWindowsの高解像度およびフォントが汚い問題ですが、ヒラギノが好きという要望が満たせない以外はわりと良好でした。

日常利用のアプリはほぼネイティブ化されており、フォントのレンダリングRetina対応されています。ChromeについてもデフォルトフォントをMSゴシックからメイリオに変えることで快適に使えます。(がしかしせっかくなのでEdgeつかってみてる)

 

 

【比較】USB-Cディスプレイはフィリップスの25インチがおすすめ(有線LAN付)

HPが米国ストアから転送屋さんに向けて出荷中なのですが、ディスプレイをどうするかずっと調べていて、USB Type-Cに対応しているディスプレイの中ではフィリップスの258B6QUEB/11がお手頃で良いのではないかと思っています。

 

f:id:ku-suke:20161204161211p:plain

まだまだ選択肢の少ないUSB Type-Cディスプレイ

2016年12月頭の状態では、発売が開始されているUSB Type-C接続のディスプレイは非常に少ないのが現実です。せっかくなので比較表作りますね。

製品名 EIZO FlexScan EV2780-BK LG 27UD88-W フィリップス 258B6QUEB/11 
サイズ 27インチ 27インチ 25インチ
価格(最安値) ¥94,753 ¥72,700 ¥52,169
発売日 2016/11/18 2016/4/15 2016/9/中旬
パネル種類 IPS AH-IPS IPS
解像度(規格) WQHD(2560x1440) 4K(3840x2160) WQHD(2560x1440)
応答速度 オーバードライブオフ:15ms(GtoG) 5ms(GtoG) 14ms(GtoG)
  オーバードライブ強:5ms(GtoG)   SmartResponse:5ms(GtoG)
コントラスト比 1000:01:00 1000:01:00 1000:01:00
拡張コントラスト比   5000000:1 20000000:1
輝度 350 cd/m2 350 cd/m2 350 cd/m2
視野角(上下/左右) 178/178 178/178 178/178
画素ピッチ 0.233 mm 0.155 mm 0.216 mm
消費電力 96 W 29 W 145 W
LEDバックライト LEDバックライト LEDバックライト W-LED システム
DVI    
D-Sub    
HDMI
USB
DisplayPort
スピーカー搭載  
音声出力端子
USB HUB
HDCP
ピボット機能
(画面回転)
スイーベル機能
(水平回転)
 
チルト機能
(垂直角度調節)
高さ調節機能
カラーマネジメント機能      
PBP  
VESAマウント
G-SYNC      
FreeSync    
MHL対応      
611.6 mm 615 mm 571 mm
高さ 545.2 mm 535 mm 511 mm
奥行き 245 mm 222.6 mm 244 mm
重量 8.1 Kg 6.2 Kg 7 Kg

オリジナル:kakaku.comの比較表

ちなみに、ASUSの15インチとか、モバイルタイプは除いています。また、Acerも27インチモデルでUSB Type-Cに対応したモデルを見かけたのですが日本では見つけることができませんでした。

パソコンへの給電(Power Delivery)の出力は異なる

意外とスペックシートに記載されていないのですが、USB-PDでMacBook が充電できる!とおもっても出力が全て同じわけではないのです。

たとえばEIZOFlex Scanは、画面の明るさをセーブした場合、30W(20V 1.5A)で給電可能ですが、明るさをセーブしない場合は15Wまでの給電となります。

15Wの場合、MacBook proだとCPUのぶん回し方によっては充電が追いつかないか、遅くなる可能性がありそうです。

その点、フィリップスの258B6QUEBは、60Wにまで対応しています。LGも、説明書に記載が見つからなかったのですが海外のレビューを見ると60Wに対応している模様です。

フィリップスの豊富なコネクションがすごい。有線LANポートも

フィリップスは25インチと一回り小さいのですが、とにかくケーブルの接続が豊富です。こちらの図をご覧ください。

 

f:id:ku-suke:20161204160952j:plain

ダイアグラムなのでサイズ感おかしいですが、だいたいなんでもつながります。デイジーチェーンのUSB Type-Cポートが存在しないくらいで、USB3.0x3、DisplayPort、そして極め付きは有線LANを搭載しています。

これ、かなり机というかノートPC/MacBookの周りスッキリしそうです。ぜんぶ液晶の裏面に刺してしまえばいいので。音質も2Wなので期待できないですが、3.5mmの出力があるので、USBあるいは3.5mmジャックでPCスピーカーを繋ぐと良さそうです。

Amazonで取り扱ってないのでNTT-X storeとかがいいんじゃないでしょうか。

nttxstore.jp

 

お買い物:HPのSpectre x360米国モデルを買った

f:id:ku-suke:20161128222513p:plain

メインマシンがMacBook AirのMid 2011なんですが、開発しないのでそこまで困ってなくてもそろそろ買い替え時ということで、Windowsに乗り換えることにしました。

ちなみに、いまのMacBookのスペックはSandy Bridge世代のi7(2677M)で、メモリ4GB、SSD256GBという当時ではultimateモデルと呼ばれるBTO機でした。ネットサーフィンくらいだとまったく問題ないです。

store.hp.com

Windowsにしました

 MacBook Proに買い替えても良かったのですが、最近のMSの頑張りとAppleMacBookに対する進化していない感も感じ、Windows機にすることにしました。すでに職場ではVaio Z Pro 13 mk2を使っており、使い勝手に関してはおおむね満足しています。

しいて言うなら、高解像度モニタへの対応が不十分なくらいですね。いわゆるRetina対応が許せるレベルになるのはあと3年はかかりそうな気がします。

ZenbookかSpectreか

僕の選定理由は、16GBメモリでi7U系で1.3kg以下、軽ければ軽いほうが良い。です。

当初夏ごろはRazorっていうゲーミングノートしか候補がなかったころに、ASUSからZenBook 3の発表がありました。こっそり某所でいち早く製品も触らせてもらい、トラックパッドのスムーズさとか軽さとかかなり気に入りました。

メモリ16GB積んでこの軽さ、まじスゲーな!と

 

しかし、いざ買うとなると、そろそろUSキーボードに乗り換えようかなとか、海外端末も見るようになりました。あと、MacBook Proを手にした人たちがいわゆるドングル地獄に陥っているのを見て、USB-C1ポートはちょっと不安だなーと。

f:id:ku-suke:20161128224154p:plain

あと同心円デザインとロゴのドヤ感があんまりでした。

2 in 1でいいんじゃないか

そうこうしているうちにKaby lake搭載モデルが出始め、Kaby lake搭載モデルで16GBメモリが搭載出来て、あまり重くないとなると以下に絞られました。

参考:The complete list of Intel Kaby Lake (Kabylake) portable laptops and ultrabooks

性能差がほとんどないようなのでKaby lakeにこだわる必要はないのですが、まぁ気持ちの問題ということで。

で、見ているうちにせっかくWindowsにするなら、Macにはない180度以上回転してタブレットっぽく使えるモードを活用しても面白いのではないか、と思うようになり、YogaかHPかでいうとHPのほうが頑丈そうなのでHPのSpectreにしました。キーボードの右端にPageUp/Downとかついてて間違いそうなのですが、この機会にブラインドタッチを覚えればいいかなと思いました。

あと、Windows勢にある、でかでかとしたロゴがうっとうしい問題が今回のモデルだとおとなしくなってるのでその点もとても好感を持ちました。

f:id:ku-suke:20161128230223p:plain

斜めの棒4本でhpと表現しているようです。HEWLETT PACKARDロゴも少し前にありましたが、こちらの方が好きです。

気になるスペックは以下の通りです。

Operating system

Windows 10 Home 64

Processor

Intel® Core™ i7-7500U (2.7 GHz, up to 3.5 GHz, 4 MB cache, 2 cores)

Processor technology

Intel Turbo Boost Technology

Graphics

Intel® HD Graphics 620 (up to 8.06 GB)

Display

13.3" diagonal FHD IPS UWVA WLED-backlit multitouch-enabled edge-to-edge glass (1920 x 1080)

Memory

16 GB LPDDR3-1600 SDRAM (onboard)

Hard drive

512 GB PCIe® NVMe™ M.2 SSD

Wireless

802.11ac (2x2) and Bluetooth® 4.2 combo

Power supply

45 W AC power adapter

Battery

3-cell, 57.8 Wh Li-ion

2 USB 3.1 Type-C™ Gen 2 (HP Sleep and Charge, Thunderbolt Gen 3); 1 USB 3.1 Gen 1 (HP Sleep and Charge); 1 headphone/microphone combo

Energy efficiency

ENERGY STAR® certified; EPEAT® Silver registered

HP Wide Vision FHD Camera with dual array digital microphone

Audio

Quad speakers; Bang & Olufsen

Special features

Webcam supports Windows Hello

Sensors

Accelerometer; Gyroscope; eCompass

Color

Natural Silver

Pointing device

HP Imagepad with multi-touch gesture support

Keyboard

Full-size island-style backlit

Dimensions (W X D X H)

12.03 x 8.58 x 0.54 in

Weight

2.85 lb

お値段は転送サービス利用料込みで15万円くらいに収まる予定。Macよりはやっぱ大幅に安いなぁ。本体がブラックフライデーで約1200ドル、転送に州税、送料、手数料あたりで160ドルくらいと予想。

新規機能要望をトリアージする10の質問

 どうも。プロダクトオーナーを普段やってるのですが、業務の何割かを占める、改善といいますか、エンハンスメントについて書きたいと思います。

前提として私のプロダクトはB2B2Cで、とある施設に導入いただき、そこのスタッフの方と一般のユーザーがアプリを利用してやり取りをするようなゆるめの業務システムです。エンジニア10名程度の小さめチームで、ゲーム・エンタメや基幹システムとは少し違うと思います。また、日々の改善なので新規企画とも違います。

○○機能を××してほしいです。

お客様や現場担当者からこのような要望を日々よくいただきます。その要望の中からチームのリソースを用いて最良の投資対効果を出すのがぼくの仕事なのですが、ご要望を頂いてチームに落とすまでプロダクトオーナーとして自ら行っている質問を言語化してみたいと思います。

■Clarify(クラリファイ・明確化・深掘り)

1.なんでそれがほしいと思ったの?

→たいていの場合、チームに寄せられる要望はすでに実現手段まで考えていただいていることが多いです。

例)「アプリのグローバルメニューに、AA機能を追加してください。

しかしながら、多くの場合で実現手段を考えるのはその道で食ってきてる我々のほうがよく知っているはずです。なので、実現手段を思いついた「理由」を深掘りするようにしましょう。

→「なぜAA機能を追加したいの?」→「よく使うからです」→「え、なんでその機能を頻繁に使ってるんですか」→「うちはXXだから、AA機能でZZしてるんです」→「いやーそれ確かにそういう使い方もできますけど、それだったらBB機能にCC用意したほうが嬉しかったりします?」→「たしかに!そのほうが最高ですね」みたいな事がよくあります。

背景にある課題や行動は、利用者のほうがプロであることも多いので、そこは利用者の行動を尊重しつつ、解決手段は作りてのプロが考えるというわけです。

■Volume(ボリューム・量・頻度)

次に、要望の真意がわかったら、同じような要望を持っている人がどの程度いるか考えます。ここはあくまで仮説ベースになりますが、ごくごく一部のユーザーのために全体の改善が滞ったりするとあまり良くないので(ときには必要ですが)量や頻度を見極めます。投資対効果の効果の量です。

2.それを希望している人はどれくらいいるの?

→まずその機能を使っているユーザの人数や割合をみます。できればデータで見ましょう。ヒアリングベースだと人間の肌感は意外とあてにならないことが多いからです。Analyticsなどで該当機能のPVをみたりデータベースの件数をとったりします。

→そして、その上で当該機能に要望を持っているユーザが何割くらいいるかを、こちらはヒアリングベースでアタリをつけます。

3.その行動をする頻度はどれくらい?

→1日3回使う機能が10%良くなる方が、1年に1回しか使わない機能が200%良くなるよりも嬉しいものです。また逆に、高頻度なものは下記の副作用にも慎重になる必要があります。

■Return(リターン・目標到達・効果)

投資対効果のうち効果の「質・方向性」です。

4.それを満たすことで我々の目指す世界に近づく?

→プロジェクトのビジョンや存在意義があるはずです。我々はXXを通して○○を支援し、ZZな社会を実現します!みたいなやつです。それと照らし合わせて方向性がずれていないかを考えます。

あまりいい例えが見つかりませんが、暗算力を向上するという存在意義があるのに、計算ドリルに電卓機能をつけてくれという要望は方向性がずれているといえるでしょう。

5.それを満たすことでビジネス成果が出る?

→リソースは有限なので、安定して長期に渡りこのプロジェクトが運営できるだけのビジネス成果を出す必要があります。それは会員登録数だったり、売上だったり。直接ではなくても「ユーザー満足度が高まることで解約数が減る」などとビジネス成果にどうつながるかは意識しましょう。

■Method(メソッド・手段)

では、やったほうが良さそうだ。となったらどう実現するかを考えます。ここはエンジニアさんに相談したりします。投資対効果の「投資」を最小化する方法を考えます。なんでもかんでも死ぬほど残業して解決するのはスマートではありません。

6.システム開発でしか解決できない?

→顧客がほしいのは1/4インチの穴が開けられるドリルではなく、1/4インチの穴である。というのは名言ですが、意外とマニュアルを整備するとか、シールを貼るとかQuick Fixのほうが実用性が高い場合があります。

7.どのような実装方法が考えられる?

→松竹梅で考えます。毎日使う機能であれば松案、あまり使わない機能だったり、ほしいと思っている割合がそこまで高くない改善なら梅案など使い分けます。

■Quality(クオリティ・品質)

作る方法がざっくり決まったら、念のため再検証します。本当にそれで良いんだっけ?と一度振り返りを行いましょう。UIUXデザイナーさんやマーケ担当にも場合によっては確認します。

8.改修したことによる副作用はない?

→そこに機能追加することで、初心者が迷うのでは?学習しなければいけないことが増えるのでは?構造が変わることによってマーケの計測値がブレるのでは?「出来ること」が増えることにより「やらなければいけないこと」が増えてしまうのではないか?保守性が下がって今後の開発がスローダウンするのではないか?

→さらに、あちらを立てればこちらが立たず、という改修もあると思います。だからといって管理画面で好きな方法を選べるようにしようなどと安易に逃げると、管理画面でお好みの設定を選ばないと使いづらい玄人向けシステムになってしまいます。

9.それは「あたり前品質」を満たしていない?

→ここまでで投資対効果が見えてきました。しかしながら投資対効果が低くても加点した方がいいものに「当たり前品質」を満たしているかがあります。ユーザーさんの期待値によって異なるのですが、これを満たしていないものは計測しにくいダメージをプロジェクトに与えていることが多いので、納得の行くロジックが思い浮かばなくても経験上加点するようにしています。

→たとえば0.1%のユーザーに致命的ではないエラー画面が出てしまう。投資対効果でいうとあまり高くないので、本来は「1年以内に直します」が妥当だったとしたら、加点して「3ヶ月以内に直します」に格上げすると言った具合です。

qiita.com

■そして最後に

10.今までの話を総合して、投資対効果の度合いは他の課題と比べてどう?

ここまででだいたい投資対効果が見えてくるので、今までに積み上がっている作業タスクとくらべて優先度付がなされ、チームに落とされます。

 

(ボーナス!)11.とは言えたまにはウェットな判断も

個人的には、チームメンバーとの関係性とか日本的なウェットさも好きなのでたまに判断を捻じ曲げます。

もってくる営業さんの熱意に負けて要望をえこひいきしたり、この要望をやるのはこのエンジニアで、彼の現在の興味とも合致するから優先度あげちゃっていいやといった、やりすぎると良くないけど適度(10%以下くらい)にそういう「余裕」も入れたいなと。

だって、あくまで仮説だしどこまでいっても完璧な判断はないから、チームが楽しく働けるほうが総合的にいい仕事できる気がするんよね。

ブコメなどでツッコミお待ちしております。