`Inspired: 顧客の心を捉える製品の創り方` を読んだ
読んだ本
- 作者: マーティケイガン
- 出版社/メーカー: 株式会社 マーレアッズーロ
- 発売日: 2015/02/07
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
気になった部分をピックアップ
第6章:プロダクトマネージャの条件
技術の進歩は急速なので、プロダクトマネージャーは、新しい技術を短期間で身につけることや、新しい分野で問題の解決に取り組むことが得意でなければならない。私がプロダクトマネージャーの候補者をインタビューするときは、すでに身につけているものは何かを見るのではなく、今までやってきた製品開発で、何を学ばなければならなかったか、学ぶのにどのぐらいの時間がかかったか、そして、身につけた知識をどのように活用したかを見るようにしている。
Engineer出身であると必然的にクリアしなければならない課題なのでEngineer的思考が十分に生かせるなーと感じた
第7章:プロダクトマネージャを管理する
ネットプロモータースコア(NPS)
普段ネットサービスを使っててよく出てくるアレである。この指標がプロダクトマネージャの評価基準になりえるのは初めて知った。コレ系はSaasとして取り入れたいなぁーと感じた。でもあまり世の中に無い気がする。
すべてのユーザが直感的に回答できるし、回答内容も全社的に共有して問題無いし、やるべきだなーと思った次第。
第11章:製品の市場性評価
顧客を理解するという点からは、財務部門が持っている情報はものすごく役に立つのだ。 財務部門の人間というのは、だいたいはかなりもの静かであり、プロダクトマネージャーのデスクまでやって来て製品機会について説いたりするようなタイプではない。だいたいは、プロダクトマネージャーのほうが、彼らのところに出向かなければならない。
この本を読まなければ気づかなかった視点でした。財務部門で扱うデータは提供しているWEBサービスでは出てこないが、とても情報の信頼度が高いものが集まっている(支払状況・今までの取引の記録・信用度等々)。顧客を理解する上ではとても有効な情報だなーと思った。
何に活かすという明確な形にはなりづらいけど、頭に入れておくという意味で良いと思った。
また、人のタイプ的にプロダクトマネージャーからアクションすべしという所も納得感あった。
第13章:製品理念
プロダクトマネージャーは、意思決定のプロセスと理由付けをみんなに完全に見えるようにしておくことだと思う。プロダクトマネージャーは、直感だけに頼っているとチームのみんなから思われるようではダメだ。プロダクトマネージャーの設定した目標と目的、それらの優先順位、プロダクトマネージャーがそれぞれの選択肢をどう評価したか、といったことについては、チームのメンバー全員にわかるようにしておかなければならない。
議論が紛争している時こそ、決断しなければいけなし、決断したら100%その決断にコミットをみんながしなければいけないし、でもそこにはある程度の納得感が必要。その一役に見える化しておく事。
普段からわかりきった事でもなるべく丁寧にプルリクに説明やら背景やらを書くことにしてレビューしてもらっているが、同じことだなぁーと感じた。
第15章:ユーザモニター制度
プロダクトマネージャーは、ユーザーとの面談、ユーザビリティテスト、ユーザーモニター制度での打合せなど、自分が担当する製品に直接関係のあるものなら何であっても出席するべきだ、と私は思っている。
当たり前だけど専任でやる前提での話。ユーザに直接ヒアリングできる機会ほど有効な時間はなし、関連するMTGに参加して洞察力を磨く事も重要だなと思った。結局参加するMTGに意味があったが無かったなどは臨む心構えで変わったりする時ある。
第18章:製品仕様はどうあるべきかを考える
製品仕様の大半は、ハイファイプロトタイプとするべきだ。
Sprintを区切ってやるべきだし、何度も作り直し前提だし、デザイナーを含めた実際に手を動かせる開発者をいかに早く巻き込めるかが重要かもしれない。
早く巻き込む事で生じる人件費等のコストは必要経費だし、そうしないと良い製品開発はできないという事なんだと思った。最近だとハイファイプロトタイプを支援するツール類も充実してきているし、前よりも低コストで実現可能だと思うのでやるべきですね。
第21章:製品仕様の検証
フィージビリティ(実現可能性)の検証
ユーザビリティ(使いやすいかどうか)の検証
価値(買いたいと思ってもらえるかどうか)の検証
特に目新しい内容では無いけど、やっぱり基本的な部分なので改めて大切だなと思いながら読んだ
第29章:大きい会社でもイノベーションは不可能ではない
私が知る限りでイノベーションを起こすいちばん手っ取り早い方法の1つは、実際のユーザーが自社の製品やライバルの製品を使ってみようとするところを、じっくり観察する(そしてユーザーの話に耳を傾ける)ことである。こういう観察を何回かやれば、ユーザーの不満や期待のパターンが見えてくるだろう。
自分たちのプロダクトではなく競合他社のプロダクトを使ってるところを観察するの事の重要性はこの本で初めて知ったし、低コストで実現できるなーと思った。
ひたすら自分たちのプロダクトについて色々と考えていたけど、競合他社のプロダクトをうまく使うことは考えつかなかったなぁ
第32章:特別仕様には要注意
特別仕様の何が悪いのだろうか?製品を作る会社は、顧客の要求をあるべき製品要求と取り違えることで、まず間違いなく道を踏み外す。
この言葉の理由には下記3つ簡単に記されていた
- 顧客にとっては、実際にそのものを目にするまでは、自分が何を必要としているのかを理解するのはとても難しい
- 顧客はどんな技術が可能であるかを知らない
- 顧客は共通のテーマを確認するために顧客同士が交流することはめったにない
特別仕様を飲み込めば大口の契約という目の前のメリットに惑わされることなく、常に本質を求めて行かなけれいけないなぁーと感じたけど、実際の経営者の立場からすると会社の経済状況が思わしくないと色々と考えが存在するだろうなと感じた。
CEOレベルの明確な意思表示が必要とも書いてあったけど、会社としての意思決定レベルの話ですね。
個人向けインターネットサービス製品で大切なこと
でも、顧客サポートの費用を抑えることが大事なのではなく、サービスを利用する顧客にすばらしい体験をしてもらうことが目的なのだ。
最近はカスタマーサービスに力を入れる企業も当たり前に増えて来たし、また改めてZappos.comの本を読みたくなった。日本の企業でも従業員の7割がカスタマーサポートの企業もあるし、サポートエンジニアの重要性も高まってきていると個人的に感じているし、そーいう流れなんだろうなと。
最後に
読みやすい本でした。いろいろな人が読める本だと思った。
勉強会:GCPUG Shonan vol.13 続・移行話 にたまたま参加させて貰った
はじめに
- いつも藤沢で利用しているコワーキングスペースで今日も作業しようかなと思ったら本当に偶然にGCPUGが行われていた
- なんか良さげな話をしていて、主催者のお気遣いを頂き参加させて貰った😃
勉強会概要
発表
Parse.comからGCPへ移行した話 ~完結編~ @tache_jp さん
- 一年がかりの移行プロジェクトかぁ
- オープンソース化されたParseサーバを動かしながら移行していった話
- 多くのバグを踏みながら対応していった話
- GCPのauto scalerの話は良かったなぁー。CPU基準で主にscaleすると言っていたけどメモリバウンドのサーバ群の場合とかどうするんだろうってちょっと気になった
- ロックオン上等とか…3ヶ月以内に収益化しなきゃいけないとかツライっすね…
- 元ネタはこのへんかな
GKEの話 @sinmetal さん
- kubernetes,GCP,Firebaseを使ったアプリケーションの構成の話
- Remoteでちょっと聞きにくく…資料をもとに見直したいなぁ🙏🏼
最後感想とか
社内勉強会でHTML Cacheの構成の話をした
その時の資料
備考
- 最近であればRoute53からドメインのAレコードをAWS Cloudfrontに向けて、originサーバにLB経由でアプリケーションサーバみたいな構成がありうる
- けどキャッシュを更新したいタイミングでなるべく早くクリアしたい場合の時にこまる😰
- globalにあるエッジロケーションのキャッシュデータをクリアするのに20minぐらいはかかるとのことらしい
- けどキャッシュを更新したいタイミングでなるべく早くクリアしたい場合の時にこまる😰
参考
勉強会:pixiv Night #02 - 画像処理技術 に参加した時のメモ
勉強会概要
発表
Blenderを使ってCUIベースで3D画像処理する by haya (15min)
- 下記のピクシブfactoryで使われている画像処理にBlenderを使ってる話
実はブログに詳しく書いてあるとのこと。このあたりかな
平面的なもの(Tシャツ)にディスプレイスメントマッピングと質感、パースで全然違和感なかった
- 画像処理する前に一度元画像からリサイズしてから、変換や合成をしている
- 元画像は容量的に重すぎて処理に時間がかかりすぎてしまう為
pixivFACTORYの画像処理周りについて何か話す by redcap97 (10min)
ピクシブfactoryで使われている画像処理の話
画像を変換するのに各フォーマット毎に別の処理をしている
- png … ImageMagickを使ってる
- pdf … rubyのprawnを使ってpdfを生成
- svg … potraceを利用して変換
小説の画像から空白を取り除く画像処理 by 496 (10min)
- 下記のサービスで活用されている様子
小説から本文を抜き出したい…
主なポイントは
- 行間隔
- 段組み
- 文字間隔
どれも自己相関、周波数解析で抽出している様子
JPEGのブロックノイズとはなにか? by harukasan (10min)
- cgo内での処理が多いらしい
- ImageFluxの中身がだいたい知れて良かった
- ストリーム処理でバッファ分をメモリ確保するだけなので効率的
go-thumber に ImageMagick をつなげた話 by yoya (5min)
- go-thumberをスマニューでそのまま活用しようとしたけどforkしてカスタマイズしたのがyoya-thumber
- ImageMagickは処理の前に一度メモリに載せる(=遅いし、マシーンスペックは必要)
- proxyを通してhttp経由で画像変換を提供
- nginxのproxy_cache経由で返却
- 1パツ目のアクセスはキャッシュが無いので負荷がデカイ
- オンデマンドでサムネイル画像を返却する仕組みのツラさも良く分かる…
ImageMagickの中身をすごく詳しくてびっくりした
halide-langについて by saturday06 (5min)
これから使っていきたいライブラリ
C++の画像処理ライブラリだけど言語と言っている by 公式
- Halide
a language for image processing and computational photography
- Halide
- ffmpeg(libswscale)からhalideへ乗り変えを検討
まとめ
- 画像処理深い…😅
- 少し軽いノリで参加させてもらったけど、話がdeep過ぎてあまりついて行けなかった😨
- 画像変換は今自分たちも課題があるけど、自前のコア技術として持つまでのフェーズではないから、OSSやこのあたりのSaaSをうまく活用していきたいなと思った
- ImageMagickってすごく昔からあるけど、取って代わるプロダクトってまだ出てきてないんだなぁーと感じた
- 画像処理系をメインに仕事をしている人はもちろんだけど、傍らでやってるエンジニアにとっても少しでも中身を知るキッカケになって良かった。
- 色々理解出来なかった部分をググって少しでも知ることができて良かった😄
- Streamingで画像処理をする話とか、へーそうやって軽くして多くの処理をしようとしているのかーと思った
勉強会:データ分析基盤Night #1に参加してきた
概要
発表
「リブセンスのデータ分析基盤の全貌」yusaku omasa(taise)
- ビーコンの活用か
- 無いとビジネス上困るからスタートしているので(あきらかなニーズがあるので)当然使われるシステムなったと言うのは良いな
- Cookieを最大限活用しているのがポイント
- 実装側がJavaScriptのコードを一行読み込めば良いと言う気軽さは良いな
「Rettyのデータ分析基盤について(仮)jp_taku2
- AthenaとBigQueryを主に活用して構築している
- 機械学習の基盤まで整っているので感じでより奥深いなーと思った
「Gunosyのデータ分析/ログ基盤の全容」atsushi morimoto
- 攻めの為のデータ基盤、守りの為のデータ基盤と言うような分類があった
- 守りの為のデータ基盤、タスクはなるべく自動化を図って人の手を介さないようにしている
- いかに多くの時間を攻めの為に使えるように回すかがポイント!!
- 完璧なログ設計は難しくて、どこかで差異が出てしまってそれをどこで(API?コンバーター?で)カバーするか?みたいな話はよく分かる…
- カバーすればするほど複雑性が出てしまい、後からjoinしたエンジニアに申し訳なくなるパターン
- デロリアンというオフラインテストはへーそこまでやるんだーと思った
- 過去ログからアルゴリズムを変更してAパターンだったらどのようなデータ抽出なるか、Bパターンだったらどのようなデータ抽出になるか等々
- これをもっと気軽にできるとproductの精度増しそう🤔
まとめ的なもの
- やっぱりみな頑張ってBigQueryに移行している感じだった
- 発表を聞かせてもらってもUIの為のデータ分析と言うのはABテストというものでひと括りになってしまってて、どちらかと言うとみなCVを上げるためのデータ分析基盤と言う印象が残った
- UIやUX改善に焦点を当てたデータ分析基盤、分析方法というのに興味を持ったし、色々考えていきたいなと思った💪🏽
- 事業インパクトがそれなりに大きいので、それぞれ専属チームで担当していた
- 1人とか2人とかでやれる業務範囲ではないなーと思った
- 逆に1人 or 2人でも出来るデータ分析基盤構築と分析といった感じのライトにできる事始め的な内容なら紹介出来るかもと思った😅
- お疲れ様でした👏🏽
Googleデータスタジオを使って見てBIツールについて考えた
はじめに
下記の記事でちょっと触れてて現状の業務に少し導入してみた。
tsuyoshi-nakamura.hatenablog.com
数日後、下記のニュースが出てヨッシャー無料で使いまくれるじゃないかと思ってもっと業務に取り入れてやってみた analytics-ja.googleblog.com
ほとんど数値は隠してますが、下記のような感じで使ってました
example
1
2
3
このあたりのBIツールに関して思うこと
世の中にはBIツール系はたくさんありますが、今の業務と照らし合わせて考えてみる。
現在PCとスマホのブラウザ版でのサービスを提供している状況で考えるとwebのアクセスログが一番重要だったりする。
UIを改善してみたり、Designを変えてみたり、メルマガのセグメントを変えて見たりという日々の改善の効果測定はGoogle Analyticsから取るデータが一番指標になる。
そのアクセスログ系のデータとDBなどにストアしているデータをかけ合わせて数値を追える事が一番重要だなと感じてる
そういった視点で考えると繋ぎこむ事ができるデータソースにGoogle Analyticsがある事が重要だなーと思っている。
以上を踏まえて最近のBIツールを見てみる
Re:dash
- 直接Google Analyticsには繋ぎこむ事は出来ない
- Google AnalyticsのデータAPIで取得して一度Spreadsheetに落としてから活用する感じになる
- OSSでの提供なので自身が管理するネットワーク内のサーバにインストールして内部のDBに対してSQL投げてデータが取れる
Amazon QuickSight
- 直接Google Analyticsには繋ぎこむ事は出来ない
- 主にAWS内にあるデータに対して簡単に分析が出来るのが特徴
- RDS,RedShift,S3,Kinesis,EMRとかこの辺に色々データが溜まってると非常に便利だと思う
Tableau
- 直接Google Analyticsに接続出来る様子
- もちろんMYSQLなどのデータにもつなげてSQLを投げれる
Google Data Studio
- 直接Google Analyticsに接続出来る
- ただDBへの接続が出来るけど、セキュリティ周りの設定項目があまり出てこなかったのでちょっと心配
まとめ
Tableau
は周りでの評価も高いし、一番良いんだろうなと感じてる。セキュリティ周りも少し調べた感じだとしっかり考慮されてる感あったし、安心して使えそう- ただ当然有料
Google Data Studio
は無料で使えてGoogle Analyticsのデータも自由に使えるので👍だと思ってる- いきなりお金のかかるツールの導入って決済者目線で言うとちょっとok出しづらいと思ってる
- 使ってみたいと思う人も本当に活用しきれるか不安でもあるし、失敗した時の事考えるとちょっと止めとこうっと思ったりする
- 無料のもので出来る事はたくさんあって、まづはそこで活用してみて、もっとこういう情報を分析する必要があって、その分析が進むとこういった施策が打てて….といった所まで使い込んで見るとよいと思う
- そうすると本当に自分たちのチームにとって必要なツールで必要な投資かどうか自信を持って言えると思う
- 有料の額にもよる部分もあるけど、こういった思考、実際にやってみた後の評価・判断が出来る事が自体が良い経験だったりするし😁
xhprofとphp-quick-profilerを使って改善した話
対象のシステム
はじめに
- PHPを使っててPHP重いなーとかサーバのメモリ使いすぎだよなーとかいろんな不満を抱えていました
- PHP自体はそこまで古くないのになーとかFWのversionも上げてるしなーとかざっくり思って見たり
- でもPHPが本当に原因なのかなーっと疑問を感じながらずっと過ごしてた
- チームの他のエンジニアが
pmap
を使ってプロセス (群) のメモリマッピングを表示してくれて、anon
という匿名メモリー?へのメモリ割り当てが多く存在する事が分かった。
んーこれは少々ばかりDeep Driveして向き合わねばならん
まずは調査
Newrelicを使ってるんですが、契約のplanとNewrelic側の対応FWでfulephpが非対応になってて、詳細が分からずという状態だったので別の解析ツールが必要だったので色々ググった
ただ、一つのツールだけではちょっと分かりづらく、結局下記の2つのツールを活用することがよさげと思って試した
- xhprof
- fuelphpのprofiling
- fuelphp特有のものではなく、
php-quick-profiler
なんですが - Particletree » PHP Quick Profiler
- fuelphp特有のものではなく、
その他
xhgui
使うとxhprof
の結果を見やすい用に表示してくれるGUIツールなんですが、ストレージにMongoDB使ってて自分の環境ではうまく動かず一旦断念…
調査結果~考案
自分のローカルマシンで調査しました
一応色々数値自体は隠しておきます。🙇🏽
php-quick-profiler
- どの画面でprofilingしてもMemory Usedが高い😨
- アクセスをさばく時に毎度通るロジックの部分が怪しいと分かった
xhprofのグラフから
一番ボトルネックになってる箇所を見つけた。下記グラフの赤くなってる箇所
- でもここFWのcore部分で手つけづらい…😨
- その手前の赤マルで記した部分がアクセスの度に必ず通過するメソッドで黄色くなって指摘されてた
- ここに改善の余地があるのではないかと考えた🤔
xhprofの表から
EWall%
でソートして表示しています
項目
Calls
… 呼びされて回数Incl Wall Time
… その関数全体の処理時間IWall%
… 全体の実行時間に対する割合Excl Wall Time
… その関数から呼ばれた関数の実行時間を除外した、関数の純粋な処理時間EWall%
… 全体の実行時間に対する割合(関数の純粋な処理時間 version)
赤で囲った部分はExcl Wallの%で、わりと高いと指摘されてる。且つ手の入れやすい部分。アクセスがある度に動くロジックの部分でもある。
xhprofのグラフの赤マルで囲ったfunctionだった🙄
こいつを改善できれば良いんじゃないかと思った🤔
それより上位はPHPのネイティブ関数の部分だったり、そのPHPのネイティブ関数をFWのcoreクラスで使ってたりでちょっと深い部分。
ここを改修となると影響範囲が大きいのでちょっと一旦パス。
以上を踏まえて主な対策方針
- アクセスされる度に動く共通のロジックの部分を見直した方が効果が高いのでやろう
- いきなりFWのCore部分に手をいれるとそれなりのリスクがあるので、Coreから切り離せる部分がまずは良いだろう
対策した内容
- アクセスがある度に毎回動くクラスAがfuelphpの
Autoloader
に設定されていて、クラスAはCoreクラスをextendしていたが、extendを止めた- xhprofの表の赤で囲ったfunctionです
- なぜかと言うと
- 親クラスのメソッドを全く使っていなかったので必要無いだろうと
- fuelphpの仕様で
Autoloader
で設定されてるクラスを辿り、_init
メソッドが存在した場合はそれを動作させるみたい。つまり、クラスAの親クラスの_init
メソッドが毎回動いていた- 無駄な処理で且つ、中身を見ると結構重そうな処理だった…😰
preg_match
関数じゃなくても良い部分はstrpos
に置き換えた- 下記の公式に書いてるように
strpos
で置き換え可能な場合は置き換えた方が早くなるよって - PHP: preg_match - Manual
Tip Do not use preg_match() if you only want to check if one string is contained in another string. Use strpos() instead as it will be faster.
- 下記の公式に書いてるように
cookieを活用して
preg_match
の判定する場面を減らした- どうしても
preg_match
を使わなければ行けない部分はあって、cookieを活用することで効率的に処理するようにした
- どうしても
対策してみた結果
Newrelic
😀
Latency
😀
CPUの数値
😀
LoadAverage
😀
もちろん
xhprof,php-quick-profilerの数値も改善が見られました😀
まとめ
- 施策を3つほどやりましたが、結局は
アクセスがある度に毎回動くクラスA
のチューニングが一番効果が高かった🙌 - xhprofで指摘された処理の中で一番遅く時間が掛かってるものをチューニングしたのが良かった(FWのcoreを除外して) 😀
- あえてcore部分を一度除外したことで影響範囲も限定されるし、リードタイム短くリリースまでいける❗❗何気にここ良かったと思ってる😀
- やっぱり時間を取って絶対改善するという心意気重要💪🏽
- 思ったよりもいろんな数値の改善が見られたのでインスタンスのタイプ一つ下げれるなぁーと思った
- このシステムが動いているサーバは4台あるので削減できる金額も結構でかく見えると思われる💰
- やった事はそんなに難しい事ではないので早くやればよかったという結果論😅
- どんどん改善していきましょー🚀