ML_BearのKaggleな日常

元WEBマーケターのMLエンジニアがKaggleに挑戦する日々を綴ります

Kaggle Microsoft Malware コンペ振り返り

これはなに？

  • MalwareコンペはKernelやDiscussionから学ぶべき点が非常に多いコンペで、個人的にとてもコミュニティに感謝していました。(おかげさまでソロ銀メダルも取れました)
  • なので、終わったらコミュニティに恩返ししようと思ってKaggleのDiscussionに投下するべく Malware コンペの解法や工夫していた点をサラッと箇条書きにしていました。
  • が、コンペの最終結果がKaggleの歴史的に見ても大荒れの結果(参考)になってしまって、真面目に英訳するのが面倒になったのでブログにサクッと起こしたものです。
  • これから肉付けしたり加筆しようと思ってたものをほぼそのまま出したのでヌケモレ多数あります笑

Malwareコンペのきっかけ

  • Malwareの前はEloコンペをやっていましたが、1月下旬ごろからコンペに飽きていました。(その後raddar神が降臨して面白くなるのですが笑)
  • 気分転換がてらMalwareのデータ見たりして遊んでいましたが、上述の通りKernelやDiscussionが面白く勉強になっていました。
  • Eloはソロ銀取れたのですが結構Shake Up/Downが大きいコンペで、Kaggleの実績がほとんどない自分はフロックっぽくて嫌でした。
  • なので、フロック疑惑を晴らすのも兼ねて、Elo終了後の2週間でチャレンジすることにしました。
  • フロック疑惑を晴らすために出場したのに、Elo以上のShake Up/Downだったのでフロック疑惑は晴らせなかったのが残念です。
  • が、2個めの(ソロ)銀メダル取れたので、次に金メダル取ったらMasterになれます。そのステップアップが出来たのは嬉しかったです。

注意

  • 以下の内容は全てCV/PubLBでの話です (PriLBの後追い検証はしてません)
  • 雑記なのでCPMPさんのSolutionを読まれる方が勉強になると思います笑

特徴量エンジニアリング

ベース

  • 良さそうなKernelがあったので、基本的な特徴量はここから頂戴しました。

  • 今回、Train/Testで時系列でデータが分けられていました。さらに、このLBが完全時系列分断されている可能性があることを指摘しているKernelがあったため、特にバージョン系の特徴量の取扱に気をつけました。Trainデータ内の新し目のバージョンはまだマルウェアに感染していなくて、これから感染する、などの可能性もあるかなと思ったためです。

  • 具体的にはVersion系の扱いを以下の感じで処理しました
    • バージョン番号そのもの及び分割したものでTargetEncodingはしなかった
      • 古いバージョンだけ行ったり、丸めたバージョンで行ったりはしました。(が、あんまり効いてなかった気がします)
    • AvSigVersionは日付に変換して日付として処理を行った
      • 例: Train(or Test)の最新の日付までの差分(Latest AvSigVersion Date of TrainData - AvSigVersion Date)
      • CPMPさんのSolutionみてるとこの当たりにMagicFeatureあったみたいなのでたどり着けなくて悔しい
    • バージョンを古い順に並べ替えて、一番古いものから数えて出現頻度が何パーセンタイルに位置するか、なども効きました

Target Encoding

  • バージョン番号系以外はTargetEncodingを利用しました
  • Fearure Importance高めの特徴量では2個の掛け合わせでも行いました。
  • 個人的には効いていたと思っていましたが、CPMP Solutionでは効いてないと書いていたので、なにか間違っているかもしれません。

Cluster Distance Features

  • このKernel で出てきたクラスタ中心までの距離の特徴量もそこそこ使えました

  • 具体的には以下のようにして作って選別しました。20回ぐらい回して2-3個使えたかなぐらいでした。
    • LightGBMでFearure Importance高めの変数を20個ぐらいピックアップ
    • そのうち7個をランダムで選んでKMeans→クラスタ中心までの距離計測&特徴量化
    • LightGBMに投入して精度が下がらなかったら採用

KNN Features

  • Home Credit 1st Place Solutionで使われていた neighbors_target_mean_500 も作りました
  • 計算時間の都合で多くは作れなかったがいくつか採用した

LDA Features

  • 以下のような感じでLDAした特徴量はそこそこ効いていました
    • TrainデータとTestデータを結合
    • Fearure Importance高めの特徴量を2個づつ取ってきて以下のように処理
      • AVProductStatesIdentifierとCountryIdentifierの例
        • 各 AVProductStatesIdentifier で CountryIdentifier が何回現れるかカウント
        • LDAで AVProductStatesIdentifier のCountryIdentifier文脈でのトピックを算出

Validation

以下のKernelを参考に似た感じでやりましたが最後まで苦戦していました。うまく行った人のやり方聞きたいです。

Models

Base Models

概要

  • LightGBMはKernel Fork後自分でかなり書き換えましたが、FMは特徴量の入れ替えとコードの可読性改善以外ほとんどいじっていません。
  • 時間的制約…、と言いたいところですがDeepFMとかほぼ知識なくいじれなかった…。

詳細

  • LightGBM
    • base: Kernel
    • CV 0.7344 / pubLB: 0.697 / priLB: 0.645
    • 特徴量: 180個ぐらい
      • 120個ぐらい自分で足しました
      • 20-30個ぐらい削ったと思います
  • XDeepFM / NFFM
    • base:
    • 特徴量: 80個
      • 自分のLightGBMの特徴量をほぼそのまま使いたかった
      • が、GPUのメモリに載らなかったので上から80個選んだ
    • CV
      • NFFM: CV 0.73166 / pubLB: 0.690 / priLB: 0.628
      • XdeepFM: CV 0.72809 / pubLB: 0.692 / priLB: 0.660
        • これがPrivate最良モデル(金圏)ですが絶対に選ばないので後悔してません笑

その他のModel

  • Stacking用にRandomForest、LogisticRegression、XGBoost、CatBoostなど作りましたが結局使っていません。

Parameter Tuning

LightGBM

  • パラメータチューニングのノウハウがあまりないので、Optunaを使いました。
    • パラメータの意味は分かるが、どれくらい動かしたら良いかとかKaggleCoursera以上の知識がない
  • 経験ある人なら簡単にたどり着けたなのかもしれませんが、自分では絶対に設定しないようなパラメータにたどり着けてとても有用でした。 (LB +0.003)
  • 具体的なパラメータは以下のような感じでした

チューニング前

'num_leaves': 300,
'min_data_in_leaf': 75,
'boosting': 'gbdt',
'feature_fraction': 0.2,
'bagging_freq': 3,
'bagging_fraction': 0.8,
'lambda_l1': 0.1,
'lambda_l2': 0.1,
'min_child_weight': 50

チューニング後

'num_leaves': 1638,
'min_data_in_leaf': 1819,
'boosting': 'gbdt',
'feature_fraction': 0.202,
'lambda_l1': 50.300,
'lambda_l2': 41.923,
'min_child_weight': 8.56,

Stacking/Blending

  • 最終的にFinal Best Scoreとなったものは以下3モデルのRankAveragingでした (CV: 0.73616 / pubLB: 0.700 / priLB: 0.649)
    • LightGBM
    • XDeepFM
    • NFFM
      • これ不要なんだけど気づきようがありませんでした…
      • 抜いてたら金だった…
  • PublicLB最良モデルは↑に加えて以下をStackingしたものでした (CV: -- / pubLB: 0.701 / priLB: 0.647)
    • LightGBM*2
    • XDeepFM (Kernel そのまま)
    • NFFM (Kernel そのまま)
    • RandomForest / LogisticRegression
  • 最終Submitには上の2つを使いました
    • PubLB最良のものはKernelのデータを使っているが、Kernelの特徴量は保守的な補正が入っていない
    • なので、pubへのoverfitが怖かった。
    • そのため、自分が作った保守的な特徴量だけのモデルのシンプルなRankAveragingをもう一つのサブとして選んだ

余談: その他工夫した点

  • データが重かったのでモデルを組んだり特徴量のテストをする時はデータを1/4程度にサンプリングして使ってました
    • Trainデータ全量でモデルを走らせたのはわずか1週間前でした
    • この計算結果がコケたら諦める、というものが無事 pubLB 0.697 を出してアンサンブルKernelを抜いたときにはホッとしました

  • とにかくデータが重かったので特徴量作成はBigQueryを主としていました。
    • 僕の本職がデジタルマーケティング / PM なのでpandasよりもSQLのほうが慣れてるというのもありますが…笑
  • 以下の処理を自動化して寝ている間に特徴量テストが終わるように工夫した
    • 寝る前までにクエリ書いて保存しておく
    • テスターが以下の処理を勝手に行う
      • BigQueryに並列でクエリ投げる
      • pickleに保存する
      • pickle読み出してLightGBMに投入して採否判断
  • どうせLightGBMでコア数必要になる & とにかく時間がなかったので、データ処理は綺麗に書く方法を考えるより多コアで殴れるように工夫して書きました。
    • read_gbq的なコマンドのBigQueryからのデータ転送が遅いので下記のように並列化していました
import os
import glob
import joblib
import pandas as pd
from google.cloud import bigquery
from reduce_mem_usage import reduce_mem_usage

def bq_load(query, feature_name, exec_date):
    file_path = './features/{}/df_{}.pickle'.format(exec_date, feature_name)
    bq_client = bigquery.Client.from_service_account_json('/path/to/xx.json')
    df = bq_client.query(query).to_dataframe()
    df = reduce_mem_usage(df)
    df.to_pickle(file_path)

exec_date = '20190301'
queries = {}
for sql_file_path in sorted(glob.glob("./sql/{}/*".format(exec_date))):
    with open(sql_file_path) as f:
        query = f.read()
    feature_name = get_feature_name_from(query)
    queries[feature_name] = query

r = joblib.Parallel(n_jobs=32)(
    joblib.delayed(bq_load)(query, feature_name, exec_date)
    for feature_name, query in queries.items()
)
  • 以下のような並列処理のメソッドも多用しました
import numpy as np
import pandas as pd
from functools import partial
from sklearn.preprocessing import StandardScaler
from multiprocessing import Pool, cpu_count


def parallelize_dataframe(df, func, columnwise=False):
    num_partitions = cpu_count()
    num_cores = cpu_count()
    pool = Pool(num_cores)

    if columnwise:
        # 列分割の並列化
        df_split = [df[col_name] for col_name in df.columns]
        df = pd.concat(pool.map(func, df_split), axis=1)
    else:
        # 行分割の並列化
        df_split = np.array_split(df, num_partitions)
        df = pd.concat(pool.map(func, df_split))

    pool.close()
    pool.join()
    return df


def standard_scaling(sc, series):
    """ 列毎の正規化処理 """
    〜〜〜〜
    return scaled_series


sc = StandardScaler()
numerical_cols = [hoge, fuga, ...]
f = partial(standard_scaling, sc)
df_scaled = parallelize_dataframe(df, f, columnwise=True)

CPMP Solutionからの学び

(あとで追記するかも)

  • adversarial validation がしずらくなるようにデータを前処理した
    • CPMPさんの曰く
      • 当初のデータはAUC0.98でadversarial validation出来てしまう
      • データを前処理して0.7以下に抑えた
        • 例: EngineVersion を Freq Encodingする等
    • 「どれくらい前処理(すれば|しなくても)良いんだろう？」って思ってた解だ。なるほど…！
  • magic feature
    • 同じEngineVersionにおけるMax AvSigVersion と AvSigVersionとの差
      • LB: +0.020 らしい。すげぇ…。
      • 言われてみれば意味合いはなんとなく分かる(がたどり着けない)ので、分析のセンスとTry&Errorの手数の重要さがわかる。
  • Models
    • Single
      • LightGBM: pubLB 0.698
      • Keras: pubLB 0.696
    • Blend
      • Keras (w/ LightGBM preds): pubLB 0.698 (priLB 0.683!)
  • TargetEncodingは効かなかった
  • 外部データも効かなかった

総括

  • 大荒れのコンペでしたが、自分的には色々勉強になったし銀メダルゲット出来たので総じて良いコンペでした。
    • Malwareするまでは `adversarial validation' の概念すらしらなかったので隔世の感です…！
  • また、文頭にも書きましたがKernelやDiscussionでのコミュニティの暖かさにも感激したコンペでした。
    • 1st Placeの人も書いてるように @cdeotte @ogrellier @cpmpml あたりの投稿が非常に参考になりました。
  • 一旦一区切りだけど次は金メダル取れるように頑張りたいです。

プロダクトマネージャーを志す人におすすめの50冊 〜基礎体力養成編〜

この記事は Product Manager Advent Calendar 2018 の10日目の記事として書かれました。

まえがき

プロダクトマネージャの職責は比較的曖昧で、そのため「プロダクトマネージャーとは何か」という議論は混迷を極めます (その曖昧さがPMの本質だ、という話もあります)

と参考記事にもあるように、会社によってプロダクトマネージャーに求める職責に若干の差はあるものの、プロダクトマネジメントの業務は基本的には多岐に及びます。

その実務においては広範な知識が必要ですが、知的生産の基礎体力がない状態ではせっかく身につけた知識もフル活用できないでしょう。野球に例えると、良いバットを持っていても、それを使いこなすカラダが出来ていないとホームランが打てないようなものかと。

そこで今回は、プロダクトマネージャーを志す人におすすめしたい、知的生産の基礎体力を養成するための本をまとめてみました。

私自身、デジタルマーケティングの出自で、データアナリストの経験もあるので、そういった職種の方にも共通しておすすめできると思います。

個人的に必読だと思っているものに★をつけた以外は、あえておすすめ度は書いていません。

読書には時期がある。ほんとジャストミートするためには、時をまたねばならないことがしばしばある。

という大江健三郎氏の言葉がありますが、この本あわないかも、と思ったらその本は一旦捨てていただいて、気が向いたらそのうちまた読む、といったカジュアルな感じで読んでいっていただければと思います。

もくじ

基本的な心構えを知る

★イシューからはじめよ

  • 仕事の効率を劇的に向上させる本
  • 個人的に自己啓発本の頂点

★外資系コンサルの知的生産術

論理的思考力ばかり喧伝される現代で真に必要な知的生産技術とは何か

ザ・ゴール

「ボトルネック」の概念とその重要性を学ぼう

トヨタ生産方式

出版されて40年経った今でもAmazonランキングの上位に登場するお化けみたいな本

ユーザーの気持ちを知る大切さを知る

★創刊男の仕事術

リクルートで数々の新規事業立上を行った男の、ユーザーニーズを徹底的に知る技術を知ろう。

★ジョブ理論

あらゆるサービスや事業はユーザーの「ジョブ」を解決するために設計される

★リクルートのすごい構創力

数々の新規事業立上げを成功させるため、リクルートが行っている数々のしくみを知ろう。

江副浩正

  • リクルート創業者の伝記
  • 「かもめが翔んだ日」でも可

スープで行きます

SoupStockTokyo立上時の企画書が非常に秀逸

イノベーションを生み出す技術を知る

★ゼロ・トゥ・ワン

  • 至言がたくさん
  • 価値を創造する企業をどう立ち上げるか

★世界は落下している

Indeed 出木場さんの名言を紹介したKAIZEN sudokenさんのブログ記事

逆説のスタートアップ思考

  • このスライドの増補改訂版みたいな本
  • スライドみて合わなければ読まなくても良い

イノベーションのジレンマ

  • 巨大企業が新興企業の台頭を許す理由を知る
  • 新たなイノベーションを起こすヒントを得る

プロダクトマネジメント

★Inspired

最近、プロダクトマネジメント本は色々出てるけど取りあえずこれを読もう

Product Management Triangle

Hooked ハマるしかけ

熱心なファンがつくサービスの仕掛けを知ろう

フェイスブック 不屈の未来戦略

フェイスブックがどうやって世界No.1のSNSサービスに成長したか。

Startup Playbook

これまた本じゃないけど

がむしゃらにやる大切さを知る

★嫌われる勇気

  • タイトルはミスリード気味。食わず嫌いせずに読んでみて。
  • 原因論から脱却し、今まさに目の前にある現実に必死で向き合う大切さを知る。
  • ホリエモンの「ゼロ」でも代用可かも

渋谷ではたらく社長の告白

不格好経営

マーケティングや説得の技術を知る

USJのジェットコースターはなぜ逆に走ったのか

元USJ森岡さんがUSJを復活させた話

ドリルを売るには穴を売れ

タイトルの概念だけ理解できたらOK

経営戦略全史

辞書的に使うのが良いかと

影響力の武器 漫画版

  • 人が動かす6つの原則を知ろう
  • 個人的には漫画版で良いんじゃないかと

僕は愛を証明しようと思う

「非モテコミット」の概念を知りユーザーへの非モテコミットを回避しよう

アイデアを作る技術

★アイディアの作り方

30分で読めて一生使える

SPRINT

SPRINTそのものを行うことはあまりないしれないが、そこで使われているテクニックは使えるものが多い。

デザインの基礎を学ぶ

★ノンデザイナーズ・デザインブック

  • 必読
  • 美のセンスは体系化出来る。

スライド作成の技術

外資系コンサルのスライド作成術

スライド作成のところもよいが、「心がまえ」のセクションも良い

プレゼンテーションZEN

スライドは情報を詰め込むもの、という常識からの脱却。

経営の基礎を学ぶ

三枝さん3シリーズ

  • V字回復の経営
  • 戦略プロフェッショナル
  • 経営パワーの危機

V字回復の経営読んで合わなかったら他の2冊は読まなくて良い

経営学

クロネコヤマト創業者の伝記

会計基礎知識

決算書がスラスラわかる 財務3表一体理解法

  • 最低限のお金の勘定はできるように
  • この本の内容くらい理解できないと苦しい

マネジメント・チームビルディング

★Team Geek

こんな良いまとめもあるよ

学習する組織

  • 読むのに1ヶ月ぐらいかかる
  • 「迷ったときに読む」でも良いかも

ワーク・ルールズ！

Googleの人事制度や職場環境がどう設計されてきたのか知ろう

あなたのチームは機能してますか

チームビルディング状況のピラミッドが◎

論語と算盤と私

岡田監督インタビューの章だけでも是非

生き抜くコツを知る

★人生は、運よりも実力よりも「勘違いさせる力」で決まっている

  • 実力をつけるのと、実力を理解してもらう、のは違うこと。
  • 自分のマーケティングも頑張ろう

自分の強みを見つける

さあ、才能に目覚めよう

ストレングスファインダーやるだけでも可

プログラミング・機械学習の基礎

たのしいRuby

  • プログラミングしたことないなら
  • 単純作業はプログラムにやらせよう

Python機械学習プログラミング

  • コードはすべて飛ばして良い
  • どんな問題をどう解けるかを知ろう

ゼロから作るDeepLearning

プログラミングも数学も知らなくてもディープラーニングを理解できる本

仕事ではじめる機械学習

これ、AIでなんとかなりませんか、って言っちゃうPMにならないように。

色々な教養

お金2.0

「価値」あるものが徐々に変わってきていることを知ろう

暗号解読

  • 暗号技術の基礎知識
  • 小説としても面白い

アルゴリズムが世界を支配する

銃・病原菌・鉄

「構造が結果を支配する」

人生で大切なものがなにか迷ったときに読む

★イノベーション・オブ・ライフ

人生に本当の幸福をもたらしてくれるものはなにか。また、それを大事にすることの大切さを知ろう。

仕事は楽しいかね

迷ったときに読む

【イベントレポート】プロダクトマネージャー・カンファレンス2018

これは何

2018/11/06-07にベルサール秋葉原で開催された "プロダクトマネージャー・カンファレンス2018"(通称: pmconf / hashtag: #pmconfjp)のイベントレポです。

今回、pmconfに初めて参加したのですが、非常に学びが多かったのでまとめてみました。

丸二日間で29人の登壇者という規模感だったので全部は取り上げられず、自分の印象に残った部分のみの抜粋となります。詳細が気になる方は、イベントページに掲載されている全セッションのtogetterをご覧になると良いと思います。

今回のレポートは「講演をどう自分が受け取ったか」の "感想文" なので、講演者の意図と異なる点もあるかもしれません。その際はご容赦いただけると幸いです。(もしくは @naotaka1128 までご指摘下さい！)

あと、長くなりすぎたので明確に2日目後半の感想が雑な感じになってます…。(気が向いたら後日ちゃんと書き直します。)

1日目(11/06)

丹野さん基調講演

講演資料

ざっくりまとめ

今回のpmconfのテーマは「愛されるプロダクトを創ろう」。pmconf実行委員を代表し、メルペイ丹野さんがテーマの選定理由を講演されました。

「AARRRモデル/LTV/CAC」の概念を使い、愛されるプロダクトを創る必要性をシンプルに解説。初心者向けと題されていましたが、PM経験者の僕でも「なぜ愛されるプロダクトを創る必要があるのか」ってこんなに上手く説明できるんだー、と十分勉強になった講演でした。

なぜ愛されるプロダクトを創るのか

(SNSの発達などで情報取得コストが著しく下がったためか) 近年、AIDMAモデルよりもAARRRモデルが消費者行動により当てはまるようになってきている。

AARRRモデルではユーザーに愛されると以下の効用があり「LTV>CAC」を実現できれば加速的な成長が可能になる。

  • 継続利用が増え顧客生涯価値(LTV)が上がる
  • 紹介などで顧客獲得コスト(CAC)が下がる

逆に、ユーザーに愛されないと「LTV<CAC」となり、収益化にたどり着くことすらできなくなる可能性がある。

  • 継続利用が減り顧客生涯価値(LTV)が下がる
  • ネガキャンで顧客獲得コスト(CAC)が上がる

LTVを伸ばした好例は最近のAdobe。売り切りモデル(一括96000円)→サブスクリプションモデル(月960円)への転換を行うことでLTVを伸ばした。ただし、サブスクリプションモデルは一度売上が下がる(ので思い切った決断は必要)。

愛されるプロダクトを創ろう

愛されるプロダクトを創ることは

  • 顧客にとっての利用価値
  • 自社にとっての事業的価値

の両方を伸ばすことが出来る。ぜひ、愛されるプロダクトを作って、顧客価値と事業価値の両方を最大化していきましょう。

ノンピ 荒井さん & 及川さん

講演資料

ざっくりまとめ

nonpi荒井さんと及川さんのランチタイムセッション。nonpi荒井さんが携わられたGoogleの社食設計の話を伺って「社食設計もユーザー体験設計なんだな〜」ととても関心したので、抜粋してメモ。

「荒井さんはプロダクトマネージャーという肩書じゃないけど、実質的にプロダクトマネジメントやってるから連れてきた」と言って、こういうセッション組める及川さん素敵だ！

Googleの社員食堂は福利厚生？

Googleの社員食堂は単なる福利厚生ではなく、一緒に食事をすることでコミュニケーションを活性化してイノベーション創出も狙っている。Gmailはエンジニアが社食でくだらない話をしているときに思いついたらしい。

「コミュニケーションの促進」を目指して

Googleは渋谷にオフィスがあったときは社食がなく、六本木ヒルズに移転するときに社食を作ることになった。他のGoogleの社食の例に漏れず、六本木ヒルズの社食も「コミュニケーションの促進」を目的として設計された。

ご存知の通り、六本木ヒルズは眺めが良い。いい景色を眺めながら食事出来るようにするため、カウンター席を設けたくなるものだが、目的が「コミュニティの促進」なのでカウンター席とかは作らなかった。

食堂設計 = ユーザー体験設計

ユーザーの使いやすさという点でも色々工夫した。

  • 味噌汁の味: 人は活動すると水分を消化して塩分を求めるようになる。なので、「朝さっぱり⇔夜濃いめ」のように朝昼晩で味噌汁の味噌の配合を変えたりしていた。(すごい！)
  • 食べ残しを減らす: 自分で食べ残しを捨てさせて可視化した。50%ぐらい減った。(すごい！)
  • 健康の増進: フルーツなど健康に良いものは目に付きやすいところに置き、逆に、コーラなどは目のつきにくいところになど工夫した。
  • 設計の正しさの確認: サーベイやアンケート(手書き)で判断して随時改善した。

エウレカ 金田さん

講演資料

ざっくりまとめ

pairsの立ち上げから今までを振り返りながら、

  • 求められる価値が時代によって変化することを前提として
  • ユーザー価値を粘り強く考え続ける

ということの大切さをストーリー調で講演されたセッション。 表現は違うものの、後のpixiv清水さんのセッションとも重なるところが多く、愛されるプロダクトを作り続ける大切さを再確認できたセッションでした。

「海外ではやってるらしいよ」はバカにならない

pairsは「海外でオンラインデーティングアプリ流行ってるらしいよ」的なノリで話が持ち上がってスタートした。

  • ここで、ビジネス・サービスモデルに超革新的なものなんてない
  • → だから「海外ではやってるらしいよ」はバカにならない
  • → だから、真似する&きっちり横展開することは大事
  • → なので「きっちりパクる&マーケティングで競り勝つ」というスタイルを徹底し、成長し続けた。

ユーザーの求める価値の変化

pairsリリース前と今と比べると、自社の状況も、市場の環境も変わっている。それに応じてユーザーの求める価値も変化しているので、それに合わせてpairsは進化していく。

  • pairsリリース前
    • 出会いアプリが当たり前じゃない＆先行サービス多数だった
    • なので、「選べる・高くない・気軽・安心」を主要な提供価値に据え、他社を模倣しつつ成長してきた。
  • 今のpairs: 出会いアプリが当たり前になってきた＆日本でNo.1アプリになった
    • No.1なのでデータをたくさん持っている
    • なので、強みを活かし、(競合を見るのではなく)ユーザーの価値観の変化を吸収しながら今後成長していく。
    • 具体的には、選択肢が多すぎて選べない悩みをレコメンドで解決するなど

pixiv清水さん

講演資料

ざっくりまとめ

女子高生VTuberが男性の声で喋ってて最初はぎょっとしたけど、発表聞いてるうちに慣れてきて、人間の適応能力ってすごいね、っていうことを再認識したセッション(違)。

最初はなんじゃこりゃと思ったけど笑、ドメインにコミットする大切さと、清水さんご自身のドメインへの愛情が伝わってくるいい話でした。

「未来にあって当たり前のものを作る」

プロダクトを作るとは「未来にあって当たり前のものを作る」こと。「あって当たり前だけど今はまだない=穴がぽっかり空いているところ」を埋めていく。

穴の形は多種多様なので正確に把握していないとうまく埋められない。でも、穴は星の数ほどたくさんある。なので、近づいて範囲を絞ってどんな穴なのかを把握しないといけない。なので、ドメインを絞り込めば詳細を見よう。

そのためには、特定領域のプロフェッショナルになることが重要。誰よりもその領域について理解できていると、誰よりも一歩先を歩み続けることが出来る。

ただし、ドメインを絞り込むことと視野を狭めることは違う。特定の領域のみ見続けているだけでは埋めるべき穴を見誤る。埋めるべき穴は時代の変化とともに変わっていくのでそれを見落とさないようにしよう。(例: スマホの普及前と普及後)

愛を持って特定領域にコミットすること

ドメインにコミットし続けると愛着が湧いてくるし、その愛着はユーザーにも伝わる。その結果、ユーザーとのエンゲージメントも高まる。ぜひ、愛を持って特定領域にコミットしよう。

余談

シンプルすぎる感想で笑ってしまったw

ZOZO金山さん

講演資料

ざっくりまとめ

Vasilyがスタートトゥデイ(現: ZOZO)にMAされ、金山さんがスタートトゥデイテクノロジーズ(現: ZOZO Technologies)を急速に立ち上げされたときの組織づくりの話。オンボーディングを大変重視し、全力でコミットして行っているというのが素晴らしいと感銘を受けたセッションでした。

ちなみに登場が特徴的だった金山さん。Twitterや本しか拝見したことなかったので、こんなお茶目な方とは思っていなくて、その意味でも感銘を受けました笑。

オンボーディングこそ全て

人材、特にPMにおいては入社3-6ヶ月のオンボーディングのプロセスが最も大事。(誰をバスに乗せるかが重要なのは前提)

「活躍して初めて入社」ぐらいのマインドで部門のマネージャーが成果にコミットして並走する必要がある。PMは以下の要因で「愛され」なくなることも往々にしてあるので、「愛され」はじめることがとにかく重要。

  • PMのしごとは成果でしか見えることが出来ない
  • 意思決定や部門間調整が多く仕事を指定内容に見えちゃう
  • 上流の業務にいたり頻繁な意思決定の変更が多いので警戒されやすい

「花を持たす」

具体的にZOZOテクノロジーズでのオンボーディングは、以下の3STEPを経て「花を持たす」ことを徹底して行っている。

  1. 入社前にトップ-PM間で入社3ヶ月以内に達成する成果を明確にする
  2. トップがその成果にコミットし達成する
  3. 成果を社内に大きくアナウンスする

これをやるかやらないかで全然愛され方が違うはず。だから、今も昔もとにかくオンボーディングを重視している。

2日目(11/07)

folio 甲斐さん

講演資料

(資料公開なさそう？)

ざっくりまとめ

金融業界のPMは攻めと守りの天秤を取る必要があるのでとにかく大変、というのが自分の現職の体験にも通じることがあり、とても刺さったセッションでした。

folioの今と昔

folio開発は3ヶ月ぐらいでiPhoneアプリを出すつもりが、気がつくと2年かかって新しいiPhoneを製造していたイメージとのこと。(言い得て妙だ…。)

folioの単一プロダクト時代はそんなに論点はなかったが、ロボアドとLINEスマート投資という2つの新しいプロダクトをだしたら一気に複雑性が増した。今は、理想と現実のバランスを取りながら組織体制を考えている。

  • 理想
  • 現実
    • 単一バックログ／フロント&バックエンド密結合／兼務によるリソース取り合い
    • ビジネスKPI以外も重視する必要あり→複雑な優先順位になる
    • 複雑性によるオーナーシップの不明瞭さ

MoneyFoward 今井さん

講演資料

(資料公開なさそう？)

愛をお金に変えよう

SaaSをやるなら日本はいい環境だよ

今半弁当

2日目のご飯は僕が大好きな今半のお弁当だった！

SmartNews 宮田さん

講演資料

PDF

海外のPM系カンファレンスが勉強になった話

おまけ

2日とも、夜ごはんは「カラシビ」(辛さと痺れ)を食べることが出来て幸せでした。 秋葉原周辺最高！

1日めの夜ごはん

カラシビ味噌らー麺 鬼金棒

2日めの夜ごはん

雲林坊 秋葉原店