プロダクト関連の本を読んだ

Hidden Technical Debt in Machine Learning Systems にも書かれているように、システム全体に対して、機械学習コンポーネントはほんの一部という話はよく言われるようになってきたと思う。 同様に、プロダクトに対して、機械学習を使った機能も(重要ではあるが)一部でしかないので、もう少しプロダクト全体について学んだ方が良いかなと思い、プロダクトマネジメントとかその周辺の本を読んでみた。

とりあえず、以下の本を読んでみた。プロダクトというより組織っぽい話も多かったけど、気になったところをメモ。

プロダクト・レッド・オーガニゼーション

セールス主導型組織とは異なり、プロダクトを主軸においたプロダクト主導型組織になるためのガイド本。

  • オンボーディング体験
    • プロダクトを使ってもらうにはオンボーディングが重要
    • ユーザーがプロダクトの明確な価値を認識し、長期的な関わりを始めるポイントを「アハ・モーメント」と呼んでいる
      • slackの場合、1チームで2000通のメッセージを送信したあたりらしい
    • オンボーディング設計におけるアドバイス
      • プロダクトではなく、ユーザーに焦点を当てる
      • ユーザーを価値あるものへと早く導く
      • ペルソナによるセグメント化
      • 進捗ゼロという状態を作らない
  • 長期の顧客維持状況の計測
    • カスタマーヘルススコアを構築して計測
    • Rapid7チームの例だと
      • 短期: プロダクトの定着状況、サポート体験、購買行動
      • 中期: カスタマーサクセスマネージャーからの情報、カスタマーマネージャーによるやりとり、NPS
      • 長期: ITエコシステム、セキュリティ成熟度、プロダクト認証
  • プロダクトの成功は機能の定着に依存
    • 機能定着率など機能に関する計測をする

プロダクト・レッド・グロース

プロダクト主導型組織の成長戦略であるプロダクト・レッド・グロースについて書かれた本。オンボーディングの話が多くあっておもしろかった。

  • プロダクト・レッド・グロースとは、ユーザー獲得、アクティベーション、リテンションをプロダクトそのものが担うという手法
  • プロダクト・レッド・グロースを取り入れるということは、事業に関わる全てのチームがプロダクトに影響を与える
  • ユーザーの4タイプ
    • ミッション・インポッシブル、ルーキー、ベテラン、スポイルド
    • スポイルドユーザーを増やせると良い

  • コアユーザーと解約ユーザーの利用パターンを比べることで、バリューメトリクスをみつける
  • プログレスバー
    • すでに一部完了していると、完了させようとするモチベーションが上がるというのがおもしろかった

      効果的なプログレスバーは最初から一部完了した状態にしてある。まったくゼロから始めるのではなく、すでに途中まで済んでいると感じさせることで、早く最後まで完了させたいという欲求を高められる。

  • ツールチップ
    • これもついやってしまいそうなことだけど、注意しないといけなそうだなと思った
      • オンボーディング・ツールチップは、ユーザーが有意義な価値を得るために必要な手順を案内するために使おう。
      • 人々がソフトウェアを使うのは、暇だからでも、ボタンをクリックして回るのが楽しいからでもない。
  • 価格帯を改善することで、ARPUが20%改善した
    • 不必要に設定された価格帯は取り除く
    • 人は選択肢が多いほど、選択をしない可能性が高くなる
    • プライシングのオプションを3つ以下に抑える
  • チャーンの種類
    • カスタマーチャーン: 一定期間中に失ったユーザー数
    • レベニューチャーン: 一定期間中に失った売上額
    • アクティビティチャーン: 解約リストがあるとされるユーザー数

プロダクトマネジメントのすべて

プロダクトマネージャーのやることや必要なスキルについて広く浅く書かれた本。全体を広く知れて、個人的には読みやすかった。

  • プロダクトの4階層としてCore, Why, What, Howを決める
    • 上から順番に決めるわけではなく、上から下へ、下から上へと行ったり来たりしながらブラッシュアップする
    • リーンキャンバスとのも書いてあってわかりやすかった

  • プロダクトの大切なものランキング
  • プロダクトの品質について
    • 狩野モデルによる品質の分類
      • あたり前品質: 備わっていて当たり前。ないと不満が大きくなる
      • 一元的品質: あるなしではなく、良し悪しで満足度が変化する。「性能」「一元的」と言われる理由
      • 魅力品質: 差別化要因となりうる品質。なくても困らないが、あれば満足を与えうる
    • 機械学習による機能も前だと魅力品質だったかもしれないけど、最近だと一元的品質になっているのかな

とりあえず広く浅くで読んでみたので、次はもう少し深ぼってみてもいいかなと感じた。

SVMs with Problem Context Aware Pipeline を試した

社内でやっているGunosyDMという論文読み会で少し前に Enhancing SVMs with Problem Context Aware Pipeline という論文を読んだ。シンプルで分かりやすかったので少し手元のデータを使って実験してみた。

論文について

論文の概要としては

  • DNNは計算コストが高い。一方、 SVMは計算コストは低いが、複雑なタスクだと性能が悪い
  • タスクを分解し複数のSVMを使うことで、複雑な問題も扱えるようになる
  • パラメータなどを自動で学習することで、DNNと競える性能を出した


アプローチの概要としては

  • データを特徴量を利用してkmeansなどでk個のデータに分割する
  • 分割したデータそれぞれに対してSVM分類器を学習し、k個のSVM分類器を生成する
    • 分割するとデータが不均衡になりやすいので、データ拡張で均衡になるようにする
    • 特徴量選定なども分類器ごとに行う
  • 推論時はk個のデータの重心ベクトルと比較し、どのSVM分類器で判定するかを決め、そのSVM分類器で推論する

f:id:skozawa:20220123134438p:plain

もう少し詳しい説明は scrapbox のほうに書いている。
scrapbox.io

実験

コードも公開されていたので、手元にあるタスクに適用してみた。試したのは去年の言語処理学会に出した扇情的な記事判定タスク。

扇情的な記事判定に向けた定義作成とアノテーション
data.gunosy.io


SVM with Problem Context Aware Pipelineのコードは以下においてある。論文では、Aspects Based Sentiment Analysisという感情分析のタスクを解いている。

whole_pipeline.py ではデータをk分割して、k個のSVMで学習・推論している。論文だとハイパラのチューニングやFeature Selectionもやっているが、whole_pipeline.py ではやっていない。論文のメインはデータ(タスク)を分解してそれぞれに問題を解くところにあるので、whole_pipeline.py でも十分そうな気がしたので今回はこれを使って試した。

結果としては以下のようになって、そこまで性能向上は見られなかった。Task2のほうが難しいタスクというのもあり性能の向上が多少見れた。データと特徴量をNLPの論文のときと少し変えているので、NLPの論文よりベースの性能がやや低い。学習データが1,300件程度しかないため、そもそも分割するほどデータ量がなく、元論文だと10分割しているが、このデータだと3分割が限界だった。元論文でもデータ数が少ないと効果が低いので、もっとデータ量や特徴量を多くするか、もう少しタスク分解が明確なタスクじゃないと効果は低いのかもしれない。

Task 判定するラベル Model Precision Recall F1-score
Task1 SEXUAL, VULGAR SVM 0.905 0.779 0.837
SVM with PCAP 0.883 0.779 0.828
Task2 OFFENSIVE, CLICKBAIT SVM 0.780 0.271 0.403
SVM with PCAP 0.800 0.305 0.442


実験コードを公開してくれているとサクっと試せるのでありがたい。あと、DeepじゃなくてSVMというのもあり、試すのも楽だった。

失敗の科学を読んだ

年末年始にいくつか本を読んでいたが、失敗の科学という本が面白かった。


内容的には、失敗をしたときにきちんとその失敗から学びましょうというものだが、実際に大きな失敗をすると人や組織はその失敗を隠してしまったり、失敗を仕方ないものとして学ぼうとしない傾向があり、その現象をクローズドループ現象と呼んでいる。

航空業界ではオープンループがうまく回っているが、医療業界はクローズドループになってしまっていることや、心理療法士はフィードバックをきちんともらえないから経験が当てにならないなどが書いてあって面白かった。

おもしろかった点をいくつかあげておく

  • 努力が判断を鈍らせる
    • 努力や労力をかけているほど、失敗したときにその失敗を受け入れることが難しく、解釈を変えて失敗したことを無かったことにしてしまう
  • 進んで失敗する
    • 仮説検証の際に、正しそうなルールばかりを検証するのではなく、あえて失敗しそうなルールでも検証することも大事
    • これはすごく大事だなと感じた。仕事で分析をするとき、最初に仮説を立ててから分析を始めることが多いけど、どうしてもその仮説が正しいことを示すデータを探しがちな気がする。その仮説に反する分析もしなくちゃなと思った。あと、よくよく考えると統計的検定は帰無仮説を棄却しているのでまさにこの考えなんだなと思った。
  • ボトムアップ式の試行錯誤の重要性
    • 技術の実用化は「研究 + 科学理論 -> 新たなテクノロジー -> 実用化」というトップダウン式の流れと考えられがちだが、実際にはボトムアップ式の試行錯誤から実用化され、理論はあとからということも多い
    • これはまさにDeep Learningとかがその流れだなと感じる。
  • スケアード・ストレートプログラム
  • 脳は一番「直感的」な結論を出す
    • 脳は一番単純で一番直感的な結論をだす傾向がある。航空事故の調査官は10件中9件は「操縦士のミス」だと考えるらしい。
    • 自分にとって都合が良い、単純な結論を出しやすいのはそうだなと感じるので、気をつけたいなと思う。


失敗から学ぶという当たり前に思えそうなことでも実際にはなかなか難しいんだなと思った。
仕事でも気をつけてないといけないことが学べておもしろかった。


今日でブログ開設から10年らしい。あんまり記事は書いてないけど。

2022年

今年はもう少しアウトプットしようかなと思い、だいぶ久しぶりの日記。

去年はなんとなくまったり無理せずな1年だった。
今年はもう少し頑張ろうかなということで、今年の目標は

  • アウトプット
    • 最近は企業ブログにたまに書くくらいであまりアウトプットできてないので、もう少しアウトプットできるようにしたい
    • 質にこだわるとアウトプットできなくなりそうなので質はあまり気にせずに
  • チャレンジ
    • 新しいことを含め視野を広げていきたい

年末年始はチームトポロジーを読んだり、最近ちゃんとした分析の必要性がでてきたので改めて数理モデル入門あたりを読んでいた。

2017年振り返り

2017年を振り返る。

2017年目標 - skozawa's blog

  1. 手を動かす、行動する
    • VPSを移行したかったので、ansible触ってみたり、pythonで少しアプリ作ってみたりした。apacheからnginxになってある程度モダンにできたのでよかった。
    • あとは転職がらみで、いくつかの会社に話を聞かせてもらいに行ったりできたのはよかった。
  2. 自己投資
    • そんなにできなかった気がするけど、東京に引っ越すタイミングで色々買い替えたので、まあいいかな
  3. 次の5年
    • ビジネス、プロダクトへの貢献に対して、自分ができる/したいことを考えて、動けた1年だったかなと思う。


今年はなんといっても転職が一番大きな出来事だった。年始あたりから考えつつ、いくつか話を聞かせてもらいにいったりもして、最終的に今の会社にさせてもらった。転職後でまだまだインプットが多い状態だけど、今のところ、自分なりには良い選択だったんじゃないかなと思ってる。まあ、あとは自分次第。

今年は決断した1年だったけど、今年の決断が良かったかどうかがわかるのは来年以降なので、また来年がんばろう。あとはせっかく東京にきたので、東京を楽しみたい。

はてなを退職しました

正式には2017年10月15日付での退職ですが、9月29日が最終出社日でした。
はてなには2012年4月に新卒で入社して5年半、濃密な時間を過ごさせてもらいました。大変お世話になりました、ありがとうございました。

はてなでの5年

はてなでは、アプリケーションエンジニアとして5年半過ごしました。はてなブログはてなブックマークMackerelMiiverseBrandSafe はてな家電会議PINGAなどなど、C向け自社サービスから、B向け自社サービス、受託まで、多くのサービス開発に関わりました。はてなのエンジニアの中でも関わったサービス数は多い方でいろいろと経験させてもらいました。

最初の2年くらいは、はてなブログMiiverseはてなスペースMackerelと、いくつかのプロジェクトに関わり、エンジニアとして少しずつ成長させてもらいました。この2年でコードの品質やWebの知識など、多少はまともなエンジニアになれたんじゃないかと思います。

その次は、はてなブックマークで2年くらいテックリード*1(当時はそういう役割はなかったけど)として開発しました。ちょうど10周年のタイミングだったので、10周年企画をやり、そのいくつかを担当しました。中でも、トピック機能や関連記事機能は開発していて楽しかったですし、YAPC(前夜祭)やはてなエンジニアセミナーでも発表してよい経験になったなと思います。

最後のほうは、家電会議のリリースをしたり、PINGAのリニューアルをしたり、BrandSafe はてなのリニューアルをしたりしました。

他には、シニアエンジニアをさせてもらい、特に何かをしたわけではないですが、エンジニアのキャリアを考えたり、組織について考えたり、少し違う角度からエンジニアについて考えれたのはよかったです。

はてなに入ったときはまだ上場前で、今より人数も半分くらいだったので、そこからだんだん会社っぽくなっていくところを中からみれたのは良かったなと思います。といっても、上場で変わったことはそんなになく、総じて働きやすい環境で、周りの人たちも優秀だし、技術に対する理解もある会社なので、はてなで働けて良かったなと思いますし、Webアプリケーションエンジニアにとって魅力ある会社だと思います。

次の5年

5年というのを1つの大きな区切りと考えていた(博士 前期+後期の期間という意味合い)ので、昨年末あたりから、次のことを考え始めました。

5年前を振り返って、やりたいことが変わったかというと、あまり変わっていなくて、研究成果(最新である必要はない)をサービスにいれてエンドユーザに届けたい、それにより新しい価値が提供できるといいなと思っています。あと最近は、テキスト・データとユーザの行動・思想をつなげることに興味があったり、文章の質や面白さに興味があります。

これをはてなで出来ているかというと、少しは出来ていますが、専門性(自然言語処理)を活かすよりは、純粋なWebアプリケーションエンジニアとして働くほうが貢献度が高いので、やりたいこととビジネスモデルがあまりマッチしていないなーという気がしていました(あくまで主観ですが)。アプリケーションエンジニアとして、はてなに貢献していくイメージはある程度つきますし、数年後には今の状況も変わりそうにも見えるので、はてなに残るという選択肢もありましたが、自分なりの1つの区切りだったのでわがままを言って、別の環境に行かせてもらうことにしました。


ということで、次ですが、2017年10月16日より Gunosyのデータ分析部で働かせてもらいます。
「情報を世界中の人に最適に届ける」という理念や、データ駆動でありデータ分析が強いこと、また最近ではクリックベイト対策などの研究開発もしていることなど、はてなとはまた違った環境なので、いろいろと楽しみです(もちろん新しい環境への不安もありますが)。

おわりに

はてなの皆様、5年半の間、お世話になりました、はてなで働くことができたのは本当によかったと思っています。ありがとうございました、そして、今後ともよろしくお願いします。

PyCon JP 2017に参加した

PyConJP 2017に参加してきた。トークを応募していたので、本当はトークできたらよかったけど、落ちてしまったので、聴講のみの参加。


聞いてある程度覚えているものを。

  • 野球を科学する技術〜Pythonを用いた統計ライブラリ作成と分析基盤構築
    • slide
    • 野球の分析をするために、scrapy, Airflow, Jupiterなどを使って、分析基盤を作った話。分析基盤の話が半分、野球の話が半分だった。
    • 結構な分析基盤をちゃんと作っていてすごい。分析基盤の方に興味があったけど、思ったよりさらっと話していた。Airflowが気になったのだけど、ブログを見てという感じだった。scheduler, workerをGUIで管理できるらしくて良さそうだけど、設定はやや複雑だったり、依存ライブラリがかなり多いらしい。
  • 機械学習におけるデータの再現性について
    • slide
    • 機械学習タスクを複数人で取り組むと、再現性が問題になる。実験の再現性はデータの再現性に縛られるので、ちゃんとデータの再現性を担保したい。そのためにはコードでデータの取得ができるようにしておけるとよさそうなので、そのためのツールを作ったという話。ツール部分はサブで、メインは問題提起をしたいとのことだった。
    • 問題にしている部分はすごく共感できる。データのバージョン管理とかしてるのかと思ったけど、その部分はこれからみたいだった。
  • SREエンジニアがJupyter+BigQueryでデータ分析基盤をDev&Opsする話
    • slide
    • データ分析基盤とデータ分析の文化についての話。いろんな要望に応えていったら、システムが複雑になり、エンジニアチームの負荷も大きくなってしまったので、モデルとビューをちゃんと分離して、分析基盤を作った。ビューは部署ごとに適切なものを用意。
    • 今回のPyConJPで自分が聞いたなかでは一番面白い発表だった。現実と向き合いつつ、着実に分析基盤とそれを活用する文化を作っていくすごくいい話だった。


PyConJPは3年ぶり2度目の参加。思ってたより初心者向けの解説的な発表が多かった気がする。