虚栄の評価基準
リーンスタートアップの青い本を読んでいる
「リーンにとってメトリクスはエッセンシャルだ」という話はこの本を読む前から目にしたり、聞いたりしていた。
「いいメトリクスってなんだろう?」という疑問を漠然と持っていたけど、リーンスタートアップを読んで以下のような印象を受けた。
真実のメトリクスにアカウンティングしろ
虚栄の評価基準とは
- 総顧客数
- 登録数
などの累計数値がなりやすい
爆発的に成長するためのUI/UX改善などの施策をやったときに、過去の決断で変わっているのか、施策で変わっているのかがわからない。 もちろん、ABスプリットテストをするなどすれば、判断できることもあるだろうけど。
紹介されているのはコホート分析、つまり顧客が最初に製品に触れた時期ごとに分別されたもので、1回使った、5回使った、有料登録した、などのファンネルの割合がどうなっているのかを見る。 1%で推移していないなら、改善は効果がないことがわかる。
どんな時にでもコホートを使え、というのも往々にして正しいと思うが、顧客の本当の行動をメトリクスにできているかどうかが重要なんだと思う。
そして、その分析ができていれば顧客の話を聞くという行動にたどり着ける
Ubuntuでintellij IDEAのインストール、アップデート
ランチャーのショートカット情報の更新などで迷ったのでメモ (2017.12.13追記)
jetbrainsからダウンロードしたtar.gzを解凍したディレクトリを配置して、ランチャー用のdesktopファイルを作成するだけです。
/usr/local/にファイルを配置するようにしています。
とにかくidea最高なので今すぐ使い始めるべき
むろん、pycharmやphpstorm,webstormでもいいです。
理由はいろいろあるけど、強力な補完機能だけでもメリットがコストを上回ってるのが直感的にわかります。
Djangoでformsetを使って、セレクトボックスを含むformにchoiceを注入する
これが必要になった理由
エディット画面で、セレクトボックスを持つformを複数個追加したい。
また、その時の選択肢には単純にchoiceにmodelのタイトルを出すのではなく、タイトルが設定されていない場合はmodelがグルーピングしているものをサマリーして出したい。
コード
モデルではstaticmethodで選択肢となる「タイトルのリスト」を作る関数を作っておく。
formとformsetではとりあえずchoicesを空に
viewsで作ったタイミングで注入する。理由としては、modelがmigrateされているの前提で処理を作ると最初からDockerなどでビルドするとエラーが出てしまう場合があるから
やってることはformsetの中身をイテレートするとformをいじれるのでそのときに設定してしまえ、という感じなのですが結構ごちゃっとしてて忘れそうなのでメモ
とりあえず、うまく行きました。 articleやarticle_groupが増えたとしても選択肢に出てきます。
データ分析、人工知能、機械学習などについて最近聞きかじっていること
タイトルの通り聞きかじって、感じていることを雑にアウトプットします。多少誤りがある場合もあるのでご容赦ください。
スマートホームの技術
Amazon alexaなどロボットやセンサーを使う時代が、未来ではなく、今の話として出てきている
企業がロボットやセンサーを使う、つまり大量のデータを使う時代である
人工知能、機械学習 その前に
www.slideshare.net
Developer Summit 2017の講演資料です。上のは直接は聞けてないけど、どちらも面白かった。
とにかく今の時代は機械学習だ人工知能だ、といったことを考えたくなるが、その応用の前段として、大量のデータを扱うためのデータ分析の基盤が必要。
データ分析の基盤としては企業がすでにもっているデータウェアハウスなどをバッチとして利用したり、ウェブやアプリのログやロボットのセンサーデータなどのストリーミングデータをアドホックに分析できることが必要である。
そのための技術基盤として、Apache Kefkaなどのproxy技術が活用されている。
また、データを生に近いままストアしておくための仕組みとしてHDFSなどでのData Lakeを構築するためにcassandraという分散DBがすでに多くの企業で利用されている。
Data Lake周りの話ではAWSのRedshift SpectrumというS3にデータをホストするだけでSQLライクな仕組みで検索できる仕組みが最近発表されてた。
こうしたデータ分析基盤を構築するノウハウはやってるところはかなり溜まってきており、人気のアプリ等のバックエンドを支えるチームには強さみを感じる。
データ分析を語る上でのスキルセット
結局はSQLベースの分析と何ら変わりがないからそのためにSQLの知識は必須となっている。
PythonのJupyter Notebookなどで生のSQLを書いて実行し、その結果をデータフレームとして読み込んでBIとして使える形のグラフとしてレポート出力することは既に日常茶飯事である。
Jupyter Notebookからはscikit-learnなどを利用してダイレクトにクラスタリングやそこからの機械学習系のライブラリに食わせることも可能。
結局のところ、機械学習や人口知能を語る上ではpythonなどのプログラミングの知識やSQLの知識は必須になってきていると思う。
また、biz側も継続的にレポートして出てくるデータと向き合う根気が必要なので、dev x data x bizの連携が密接に連動する組織作りが一番重要ではないか?
スタディサプリの講演の受け売りですが。
センサーデータと機械学習
みんなのPython勉強会で紹介されていたというH2O.aiマシーンラーニングのプラットフォームについてのお話です。
MAPRテクノロジー
データエンジニア マテウスさん
ソフトウェアエンジニア マシューさん
例としてロボットの動作の異常検知をあげる
異常があるとロボットの動きがおかしくなるが、本当は異常が起きていても人間の目で分からない場合もある。
そういう異常があるかどうかを機械学習を使えばリアルタイム表示できる。
具体的には、
- ロボットのセンサーデータをラズベリーパイに無線データで送る
- ラズベリーパイからデータを分析するためにAWSのクラスタに送る
- AWSのクラスタからの出力はARのヘッドセットに出力され、リアルタイムに確認できる
H2O.aiは2の部分のAWSクラスタで処理系として使われている部分である。
データでパターンを作り、パターンを予測できる。
データがちゃんとないとモデルは役に立たない。だからデータが重要。そしてそのための仕組みづくりが重要
Apache kafkaがREST API proxyとしてメッセージキュー処理を行うのだが、そのためのRESTリクエストの仕組みはpythonのrequestsモジュールでかんたんに実装できるとのこと。
機械学習を利用したシステム構築のの実際
最初はとにかくデータを観察する。だからデータ分析ができるためにjupyterなどでのプログラミング+アドホックなデータ分析は必須。
そして、どう活用するか考えて、モデルを作る、仮説を作る。
「異常が出たら予測がほしい」
仮説はとにかく素早く検証する。検討ではなく検証。
センサーを作った人と話して、新幹線などでも使われている加速度センサーを使うことにした
普通のデータ以外の異常データが出たらすぐにわかるようにしたい
教師なしでの学習を行い、正常系の動作から変わったときに異常かどうかを判断する
おかしく見えるけど本当におかしくはない状態もある。
予測が変わったらすぐに異常を出すのではなく、ちょっと待つようにしている
デモムービーで実践が紹介されていた
Q
教師あり 教師なし学習の差はどんなものがあるのか?
A
データによってアルゴリズムと問題を見て判断する。
クラスタリングなどは教師なしのほうがいいけども、基本的には、教師ありのほうが良い
教師ありが使えるなら使うべき
教師ありでラベルを付けるのがコストがかかる
作戦としては教師なしから教師ありを考えるべき
現場では基本的に正常系データしかないことが多い
Additional
最近ではGPUでの分析に対する顧客の要求が高まっているため、このプラットフォームでも全部で使える状態を構築中。(今は一部)
「Pysparkで始めるデータ分析」
BIと機械学習についてのお話 こちらもみんなのPython勉強会です。
PysparkはApache sparkをpythonを使って利用できる!
分析アプローチのパターン
健康診断アプローチ
BIや現状の見える化を行うためのもので、サマライズすることがメインの要求になる
例えば、「どういう顧客が製品を使っているのか」「どういう導線」探索的アプローチ
これはセンサーデータの例でも出てきたように、データの中身を探索するときに使う
基礎集計、機械学習、教師なし学習などで分類
実際のビジネスでは有料会員化のフローなどを考える。
「無料会員がどういう経緯を経て有料会員になったのか」などを探索して分析
離脱ユーザーのカムバックフローなども
UIUXのためのセグメンテーションで戦略を立てる
「女性にはこういうUIがうける」検証のためのデータ分析アプローチ
定量的な観測
仮説を立てて検証のフェーズで使う。
無料の会員を有料に遷移させるためにステップアップ施策
「通常1000円を300円で使えますよ」という施策を実行したときにどういう結果が出たのか観測する
データ分析ってどういう人がやるのか
- データエンジニア
- データサイエンティスト
- ビジネスアナリスト
- アプリ開発者
4ロールが協調してデータ分析を行う
Apache sparkとは、
大量データを分散並列インメモリのフレームワーク
大きなデータにたいしてトライアンドエラー。Hadoop単体では難しかったアドホックな分析が可能になっている
最近はGPUでの分析が話題になることも多いが、こちらも相当有名。
お題 ABテスト
pythonからsparkを使ってデモンストレーションを行う。
pysparkもpandasと同様にデータフレームを持っている
jupyter上でデータフレームとして読み込みを行う
得られる内容としては以下の通り
k-means法をつかってABの対象顧客を抽出
sparkではshowで先頭データを見ることができる
文字列のデータを扱うのは難しいので、MFの性別の文字を変換するなどしてコード化
なぜコード化が重要なのか -> 性別は2値だがアンケートなら数十になることもある
pysparkを使うと分散処理意識せずに使える
無作為抽出を色々工夫しながら行い、K-meansというクラスタリング ラベルデータはなく3分類する
性別利用頻度によるセグメンテーションとAB抽出
大事なのは機械学習でクラスタリングして、人がデータを見て意味づけする。
そこから次の施策を考えるための分析をアドホックに行うことができるということ。
抽出のための工夫などもプログラミングのスキルは必須なんだと思う。
感じていること
人工知能や機械学習は常に進化していて、ひょっとしたらプログラミングなどの領域も人工知能に置き換えられるかもしれない。
ただその中間地点として、ドメインに人工知能などを適応させる領域には常にプログラミングが必要になるんじゃないかと思う。
もう一つはdev x data x bizのチームビルディングが重要だということ。もちろん基盤も必要だろうけどそれよりもチーム。
アジャイル、顧客開発、リーン、仮説検証。それらのキーワードもしっかり自覚しておく必要があると感じている。
そういう感想をいろいろと感じられたという意味でこのPythonの勉強会やDevsumi2017に参加した意味は大きかったと思う。
結局のところ主体的に機械学習に取り組めていないという意味ではまだまだちょろあまな自覚はあるけれども。
DevLove関西『リンスタ関ヶ原 (新大阪の変)』に参加しました #Devkan
2017年3月18日にあったDevLove関西のイベントに参加しました。
東京に引っ越してからは初の参加です。
「正しいものを正しくつくる」
Guildworks 市谷 聡啓さんの話
感想
市谷さんの話は「頑張ればいいプロダクトマネージャーになれるかもって人」に聞いてもらうといいのではと思いました#DevKan
— hirokts (@hirokts) 2017年3月18日
市谷さんは価値の探索・検証が得意技でそのお話でした。
正しくないものを作り続けるのってソフトウェアエンジニアにとって不幸でしかないし、本当に考えないと。
新規サービス 食のつながりが世界を変えるFoodionの立ち上げ
クックビズ 要 徳幸さんの話
社内スタートアップとして開始したFoodionの話。料理のプロの人のインタビューサイトを作って、調理業界全体のキャリアのモチベーションを高めたい、というミッションがすばらしいと思いました。
タックマンモデルなど結構ハイコンテキストな現場の話で、「チームとは」みたいなのを深く考えさせられます。
スタートアップを陰ながら支えるときに心がけるべき5ヶ条
楽天の川島 淳美さんのお話です。
www.slideshare.net
この5か条本当に大事だと思う。
- 当事者意識を持つ
- 本質を追究する
- 「それ、絶対使う?」を意識する
- いい感じの木に タイヤブランコを 1週間で 作ってきてー!
- 関係者をトリコにする
4つ目の「いい感じの」とか「わかる(わかる)」です。
5つめのトリコにするというのもスライドにあるように「関係者以外に言いたくなる」ってならないとだめだなーと思いました。
ちょっと話がそれます。
当事者意識については、「圧倒的当事者意識」っていうキーワードを別の勉強会で聞いていてそれが気になっていました。
FB広告でそれが出てたHarvard business reviewを買いました。
読んだ感想、プラス元リクルートの人のお話を聞いた感じでは「で?」という問いを常に自分でし続けるのに近いのではないかと思います。
「で?(どうしたいの? どうするの? どうなったの?)」みたいな感じの問いをするある人が思い浮かびます。
当事者意識についてはその質問を自給自足し続けることがいいんじゃないかなと思いましたので実践します。
元ソフトウェア設計者の缶詰事業挑戦記録!〜「目的」は変えず「手段」を変えながらの事業作り〜
缶詰事業のベンチャーとして株式会社カンブライトを設立した井上 和馬さんのお話。
すごい。やばい。おもしろい。
絶対見学に行きたい。これ参画できたら絶対楽しいよ
という頭の悪い感想です。
SIerからの転身でも、本当にその領域にのめりこめば自分のスキルや今までやってきた改善が十二分に生かして仕事ができいるということがよくわかりました。
泥臭い時期の話も含めて本当に面白いです。スライド上がったのでぜひ見直してみたいです。
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ
リクルートテクノロジーズ 黒田 樹さんのお話
www.slideshare.net
とにかく一番聞きたかったやつです。 本当に学びしかない。
2年前のDevLOVE甲子園日本シリーズでお話を聞いたことがあったのですが、そこからさらに進化しています。 仮説を立てるときは逆回りにサイクルを考えるとか、別でうまくいっているプロダクトを輸入するときはどこのフィットが崩れるか仮説をたてるとか。 スライド上がるそうなのでメモをもう一度見直しながら、理解したいと思います。
ちょっと内容と関係ない感想。
Switchの初期不良を引き当てて、やっと修理から戻ってきたそうなのですがスライド作成中にどうしてもゼルダやってしまったとか。
ゼルダやりたいーーーー。
Switchいつまともに買えるんだろう。。。
全体の感想
とてもよかった。プロダクトとどう向き合うか、とか、スタートアップで実際にやるとどんなことをやるとどんな感じなのか?とかいろいろ考えさせられます。
自分としてはプロダクトへの向き合い方、エンジニアとしての在り方、チームをどう支えていくか、価値をどうやって早く届けるか・検証するか・フィットさせるかなどあらゆる学びがありました。
登壇者の皆さま、スタッフの皆さま、会場のMOTEXさま ありがとうございました!