Entrepreneurial Regression

2ヶ月ぶりの更新です。
書きたいことは色々あったのですが春学期は死ぬ程忙しかったので
中々書けませんでした。笑
とりあえず一週間前に無事MBAを卒業しました。
最終学期の授業の成績はまだ全部出てないので
厳密にはまだ卒業出来てるのかわかってませんが、
きっと大丈夫…なはずです 笑

卒業/MBA総括関連の話はまた次回以降書きますが、
卒業して時間がたっぷりできたので、
まずはこれまで溜まっていた書きたいことを書いていこうと思います。

今学期は(facebookでそういう話ばかりしてたので 笑)
MBAのキャンパスで友達に会うとHealth Analyticsの話をよく聞かれました。
この授業が、今学期がMBA生活の中で一番忙しかった主原因なのですが、笑
その分学びも多かったので、たまにはMBA行ってる人らしく、
その学びのいくつかを備忘の意味も含めて書いてみようと思います

Regression in Agile Setting

はい出ましたアジャイル 笑
まぁタイトルのチャラさは置いておいて、
今回のメイントピックは、regression(回帰分析)です。

まずはregressionを知らない人向けに超簡単にregressionの説明をします。
(Wikipediaのリンクを貼って終わりにしようと思ったのですが、
Wikipediaの説明、専門用語が多過ぎて小難しかったのでやめました 笑)

Regression – Basics

regressionは一言で言うと
「2つ以上の要素の関係性を方程式で表す」方法のことです。
例えば東京の気温と湿度のデータ(何度の時に湿度何%だったか)をいっぱい集めて
そのたくさんのデータを元に東京の気温と湿度の関係を

湿度(%) = a + b × 気温(℃)

という方程式で表しますというのがregressionです。
ただ、東京に住んだ方なら想像がつきやすいかもしれませんが
同じ気温でも、例えば梅雨と秋では湿度が全然違うので
上記方程式で一意に気温から湿度を求めることはほぼ不可能です。
なので、イメージとしては下記図のように
複数のデータの点たちから”一番無難な”(誤差の合計が最も少ない)線を引いて、
その線の方程式を求めるという感じです。
linear regression example
上記図から明らかかもしれませんが、regressionは発想として
「方程式にあてはめれば全ての点がピンポイントで当たる」ではなく
「方程式を使ってだいたい全体的に近い予測をする」ものです。
なので、この引いた線が全体的に
どのくらい実際の点に近いかを測るための値があって、
その値を元にregressionの全体的な精度を判断します。
その値の中で最も有名なのがR^2(決定係数)です。
R^2は普通のregressionでは0〜1の間の値をとり、
1に近い程regressionの精度が高いと判断します。
また、引く線も必ずしも直線とは限らず、
下記図のように気温の二乗や三乗、ルートやログ等を使うことで
曲線にすることも可能です。
Screen Shot 2015-06-19 at 10.30.00 PM

…と、基本はこんな感じです。

UCLAのMBAでもregressionは
Statistics, Data Analytics, Marketing Analytics, Customer Analytics
等の授業で習ったのですが、
全ての授業で、数万件単位のデータセットでregressionを行って
教科書通りで誰が見ても正しい、”綺麗な分析”をするという
“大企業で特に真価を発揮する”使い方を扱っていました。

What I mean by “agile”

上記使い方ができるのは、大量データを集められることが大前提です。
多くの場合、それは自前なり他人の(API等含め)なり、
ある程度のユーザーベースのある製品が既に存在することを意味します。
また多くの場合、使用するデータに相関があることは既にわかっていて
いかに多次元のモデルを使って予測の精度をあげるかが焦点になります。

ところがHealth Analyticsでは、プロジェクトの内容が
「まだ世の中に存在しないヘルスケア製品を作る」だったので、
データを大量に集められる製品は存在せず
データに相関があることもわかってなかったので
そもそも大前提の仮説の方向性が信じるに足るかどうかを立証することが
焦点でした。
なのでMBAで習ったregressionと同じモデルを使ってはいるのですが、
結構モデルの改善の仕方や解釈の仕方は違いました。

…と、ここまでが非常に長い前置きです。笑
基本的にHealth Analyticsでは教授は何も教えないので
某六本木/虎ノ門にあるワークスなんとかとか言う会社と同じで
全部試行錯誤して自分で勝手に学ぶのですが、笑
そんな試行錯誤してる中、なんとなく上記違いに気付いて
それに応じて学んだことがいくつかあるので、つらつらと書いてみます。

Takeaways

  • Power of Linear Model
    データ数の少ない段階においてLinear Modelは強力です。
    僕らの使ったデータセットでも多次元モデルはoverfittingしてしまい
    使い物にならなかったです。
    これはLinear Modelは直線なので2点を結ぶ線は一通りしかないのに対し
    多次元モデルでは曲線なので2点を結ぶ線が何通りもあることに
    起因してます。なので多次元モデルでは使用データが少ないと、
    ほとんどの点に近いところまで線が来れるので
    全体の傾向を掴むよりも既存の個別の点に集中し過ぎてしまい
    regressionの精度を表す値(R^2等)が異様に高くなり、そのわりに
    新しいデータで同じモデルを試すと全然見当違いの予測になります。
    Linear Modelは直線ゆえに単純で精度も粗いですが、
    曲線(多次元モデル)の方がより正確に近似できるケースでも、
    多くの場合(曲線程ではないにしろ)相関の有無が判断が出来るレベルでの
    近似はできます。
    なのでProof of Conceptの段階ではLinear Modelは非常に有効です。
    また、当たり前ですが上記Overfittingしたモデルの誤用を避ける意味で
    Validation(作ったモデルをモデリングに使ってないデータでテストし
    その結果を精度の判断に使うこと)も超重要です。
    当たり前/超重要の割に意外と忘れられがちで、
    Health AnalyticsでもValidationしてなかったチームが2チームいて
    教授にピッチでボコボコにされてましたし
    他の授業で扱った某投資銀行が発表したカントリーレポートにも
    明らかにValidatonしてないモデルが載ってたりしました 笑
  • Power of Weighting
    上記Linear Modelと結構密接に関係しているのですが、
    そもそも曲線で近似すべきところを直線で近似すると
    下図のように精度がいいところと精度が悪いところがでてきます。
    Screen Shot 2015-06-19 at 8.37.13 PM
    低い値と高い値になればなる程精度が悪くなる傾向があるのですが、
    ここで考えるべきなのは、
    「はたして全ての値の精度が等しく大事なのだろうか?」
    ということです。
    先ほどの気温と湿度の例で言うと
    例えば0%も20%もどっちもカラッとしてると感じるし
    80%も100%もどっちもムシムシしてると感じるけど
    40%と60%では湿度の体感が劇的に変わるのであれば
    80%のところを間違えて100%と予測してしまうことは
    40%のところを間違えて60%と予測してしまうより
    どうでもいいことかもしれません。
    もしそうなのであれば、regressionの際に
    50%に近い点をより重要視して
    25%未満や75%以上の点を軽視する方が、
    より意味のある予測になります。
    weighting、僕らのプロジェクトでもとても役に立ちました。
  • Power of Classification
    これも上記に関連しているのですが、Weightingと同じロジックで、
    もし高い値と低い値の予測があまり重要ではなく、
    かつ予測精度も低いのであれば、
    最終的なアウトプットは予測した値を直接出すことをやめて
    特定のThreshold(湿度の例だと50%とか)を設定して
    その値より高いか低いかを表示した方が
    アウトプット自体の精度が圧倒的に高くなります。
    Thresholdを一個だけおいて高/低で表したり
    二個おいて高/中/低で表したりというアウトプットの単純化も、
    特にHealth AnalyticsのプロジェクトのようなProof of Conceptの段階では
    非常に有効でした。
    それに伴って精度判断に使う値も、
    regressionの線全体の精度を測るR^2よりも
    Classificationの結果の精度判断に使うconfusion matrix
    重視するようになりました。
  • One more thing… Beat the invisible giants
    もう一個の学びは若干番外編なのですが、
    「Computer Scienceの大学院生も必ずしもData Savvyとは限らない」
    ということでした 笑
    チームはボク以外にComputer Scienceの大学院生が2人いたのですが
    2人ともregressionをちゃんと理解してませんでしたし、
    feature selectionもできませんでした。笑
    おかげでモデリングの全部をボク1人で担当できたので、
    (同じ理由でモバイルアプリもボクが1人で作りました 笑)
    とてもよかったですが… 笑
    他のプロジェクトには明らかにちゃんと出来てる人もいましたが、
    40人中4,5人という印象でした。
    ほぼ全員Machine Learningの授業履修者だったはずなのですが…笑
    ということでまた一つ
    「きっとComputer Scienceの人達は全員超凄いんだろうな〜」
    という見えない巨人の幻想が消えました。笑

ということで、Health Analyticsのテクニカルな学びでした。
少ないデータでいかにコンセプトを証明するかという観点で
モデルを選んだり、input featureを絞ったりするのは新しい経験でしたが、
たぶん今後、同じように新しい製品を作る際に頻繁に行うことになる
気がするので、大事な学びだったと思います。
Health Analyticsは今まで受けてきた授業の中で
一番InnovativeでEntrepreneurialだったので
テクニカル以外の部分でもうちょっと深い学びもある気がしますが、
それはまた考えを整理してから別途ログにしてみようと思います。

Catalog Creation

テック業界でMBAに人気の仕事の一つにプロダクトマネージャがあります。
MBAで人気の仕事の割に、実際にMBAに入ってみると
関連バックグラウンドを持った人が少ないなーとか、
授業が的外れだなーとか
思う機会が多いです。

そういうことを感じながら2年間過ごしてきて
プロダクトマネージメントを勉強するには
コンピュータサイエンスの方がバックグラウンド的には適切なんだろうなー
と思うようになったのですが、
Health Analyticsでコンピュータサイエンスの人達のピッチを見たり
一緒にチームでロードマップ考えたりしてると
コンピュータサイエンスもコンピュータサイエンスで問題あるなー
と思うようになりました 笑

プロダクトマネージャは、ビジネスの知識とエンジニアリングの知識の両方を
結構ちゃんと知ってる必要があるので、
やっぱりどっちも知ってる人じゃないとダメなんだなー
というのも一つの理由で、
確かに純粋なMBAの人は市場規模の計算に終始し
テクニカルチャレンジやテクニカルフィージビリティのところで
言ってることわけわかんないことが多いですし、
コンピュータサイエンスの人は、インプリメンテーションに終始し
マーケット感覚(それ誰が使うの?)がないことが多いです。
…もちろんどちらの学校にもそういうことがちゃんと出来る人も少数いますが。

ですが、それ以上にMBA、コンピュータサイエンスに共通して
解決しようとしてる問題の本質は何で、そのアイディアはそれをどう解決するのか
ということを考えるスキルのある人が少ないなーと感じます。
そしてそれを教える授業も、UCLAにはボクの知る限りほとんどないです。

で、ボクは結構このスキルが、プロダクトマネジメントにとって
一番大事なんじゃないかレベルで重要な気がしています。

学校でこのスキルを勉強したい場合は
アイディアのピッチやデモがある授業をとりまくったり
授業外のそういう機会に飛び込んで
実践から副次的にフィードバックを貯めていくしか術はなさそうです。

「てか偉そうに語っているけど、そんなお前はどうなんだよ」
という話になるのは自然な流れだと思いますが 笑
ボクもあんまりそのスキルないです。笑

が、謙虚をやめて書くと 笑
一応前職でそういうことを考える仕事をたくさんさせてもらえたおかげで
バックグラウンドのないMBAの人達やコンピュータサイエンスの人達と比べると
アドバンテージがあるなーと感じます。

ということで前置きがハイパー長くなりましたが 笑
今回は前職でやってた「そういうことを考える仕事」である
カタログ作成という作業について書いてみようと思います。

カタログ作成

「カタログ」は前職で勤めていたワークスアプリケーションズの社内用語です。
カタログは読んで字のごとく製品のカタログです。
普通の製品カタログと何が違うかというと、書くタイミングと対象です。
ワークスでは製品を作る前にエンジニアが書きます。
書いたカタログを元に
(多くの場合は)それを書いたエンジニアが製品開発をしていきます。
そして一般的な製品カタログとは異なり、
社外のお客さん向けではなく社内のエンジニア向けです。

カタログにはユースケースと言って
誰がどんな時に使うことを想定していて、そこにどんなメリットがあるのか
をまず記載し、
そのユースケースに記載したメリットを最大限実現するための機能を
優先度の高い順に記載していきます。

と、これだけ書くととっても簡単そうで
「なんだ、それくらい書かなくても私もやってるわ」
と思う人も多そうですが、
意外と奥が深いです。

例えば、
商品を納入したけど期日までに入金が入らなかった注文の一覧を
月次でまとめて印刷する機能のカタログのユースケースとして、
「経理担当者が月末に使うことを想定していてこの機能によって
商品を納入したけど期日までに入金が入らなかった注文の一覧データ
を紙で見ることができる」
って書くとボツです 笑

上記のケースではまず一番初めに
「なんでこの経理担当者わざわざ紙で見たいの?紙マニアなの?」
という疑問が浮かびますね。
たぶん多くの場合経理担当者の人は紙マニアではないので 笑
紙で出力したいのには他の理由があるはずです。
例えば、この経理担当者は月次で未入金の注文について
経理担当者の上司からの承認をもらっていて
上司にハンコをもらうために紙で出力する必要がある。とか。

とすると、今度は
「なんでこの上司ハンコつきたいの?ハンコマニアなの?」
と思いますね。
わざわざ紙に出力してハンコをもらわなくても
そのデータを承認する機能があれば
わざわざ経理担当者が紙に印刷して上司のとこまで行く手間が省けますし
使う紙も減ってエコですし。プリンタの混雑も減りますし。

これを聞いて「あ、確かに」となる場合はたぶん印刷する機能よりも
承認する機能を作るべきで、作る機能が変わります。
逆に「いやいや言ってることはわかるんすけど、
うちの上司おじいさんなのでパソコン使えないんですよねー」
という場合はじゃあ確かに紙で印刷する必要あるかもね
となります。

もしこれが理由で月次でまとめて印刷する機能を作るのであれば
印刷の出力フォーマットにはハンコをつく場所を想定しているべきですし
文字も大きく見やすくデータがまとまっている必要もあるかもしれません。

次に
「てかそもそもこの上司はなんで未入金データの承認をしたいの?
未入金マニアなの?」とか
「なんで毎日じゃなくて月末なの?月一出社なの?」
という疑問が浮かんでくるので、なんで承認してるのか調べます。
調べていく上で、根本的なニーズがわかり、
例えばどの項目を元に承認するのかとか
どういう単位でどういう順でデータが表示されてるべきとか
機能のあるべき姿が見えてきます。

…というように問題の根っこをちゃんと理解するために
カタログを書きます。

ここで注意が必要なのは、一番初めに書いたユースケース
「経理担当者が月末に使うことを想定していてこの機能によって
商品を納入したけど期日までに入金が入らなかった注文の一覧データ
を紙で見ることができる」
でもカタログは書けてしまうし、
疑問を持たない人にはこれをみて
「ふーん、そうかもね。いいんじゃない?」
と思ってしまえることです。
それを元に
「よーし、じゃあスペースを最大限利用して
なるべくたくさんの情報を出力するようにして
一枚当たりの情報量がなるべく多くなるようにしよう」
と作ってしまうと、
「何この機能?全く使えないんだけど?」
となってしまうかもしれません。

ということでカタログ作成、レビューが鍵だと思います。
ちゃんとカタログをレビューできる人と一緒に議論することで
まだわかってないことが何なのかわかり、
より明確なカタログにブラッシュアップされていきます。
同時に自分自身にも同じ視点が養われていくので
初めから問題の根っこを掴んで、それをどう解決するかが
高い精度で描けるようになります。
経験則的にはこのスキルを初めから持ってる人って
ほぼいないと思うので、
このスキルを得るためには
人生のどこかのフェイズで
これに似た経験をする必要がある気がします。

そしてMBAに来て、このスキルって超重要だし
希少価値高いなーと思うようになったんですが、
同時に色々なプロダクトに触れる中で
このスキルって結構domain knowledge関係ないよね
と思うようになりました。
多分、一個の分野/製品でこれができるようになったら
どの分野/製品でも同じことが同じレベルでできると思います。

ということで、自分の興味ある分野かどうか関係なく
アイディアからプロダクト作る系の授業をとって
そこでピッチして経験ある人からフィードバックをもらう
というのは結構MBAの人こそやるべきことなのかもなー
とおぼろげに思いました。

実はその辺も含めてUCLAのMBAのテック関連のプログラム強化を
水面下で工作中なのですが、笑
それも何か動きがあったら学校の宣伝がてら書こうと思います。

Spring Quarter -Final Quarter Ever

さて、先週から最終学期である2年生の春学期が始まりました。
今までMBAのアカデミックにはどちらかというと否定的だったのですが、
今学期は2個程非常に楽しみな授業を履修することができました。
今回はその2つの授業を紹介してみます。

Critical Milestones in Preparing for Life of Leadership

UCLA Andersonで一番人気の授業です。Deanが教えてます。
UCLAでは選択授業はbiddingといって
毎学期もらえる1000ポイントの持ち点をそれぞれとりたい授業に賭けて、
賭けた点が高かった順に授業にenrollされていくというシステムなのですが、
この授業は履修できた人の中での最低biddingポイントが2200ポイントでした。
人気の理由は、ゲストスピーカー陣の豪華さにあります。
この授業では毎週ゲストスピーカーが来て、
それぞれの週のトピックについてQ&Aで色々答えてくれるのですが、
まー来る人たちがアツい。笑
テック業界からはツイッターやグーグルのCEOが、
エンタメ業界ではドリームワークスやソニーエンターテイメントのCEOが
他にも誰もが知ってる会社の社長さん達が来て
それぞれの週のトピックについて自身の体験を語ってくれます。
超パーソナルな話や、メディアに出来ない話とかも
惜しげもなく披露してくれるので、授業履修時にNDAにサインを求められます。笑
ボクも「この授業で聞いた内容を授業外で話さない」
というNDAにサインしてるので、
彼らがどんな話をしてくれたかは残念ながらブログに書けませんが、
今日のドリームワークスのCEOの話も、
聞きながら鳥肌が立つくらいすごかったです。
とっても久しぶりにMBAに来て良かったと授業面から思いました。笑
エリックシュミットがどんな話をしてくれるのか、とっても楽しみです!笑

Health Analytics

今学期履修している楽しみな授業の二つ目は
コンピュータサイエンスの大学院の授業、Health Analyticsです。
これは先学期のMachine Learningの教授が教えている
プロジェクトベースの授業で、
中間、期末一切なしの一つのプロジェクトのみで成績が決まるという
非常に男らしい(笑)授業です。
ヘルスケアには今のところ興味のないボクですが、
教授が初回の授業でこの授業をヘルスケアの分野でやる理由を語ってくれました。

この授業の目的は、ヘルスケアの世界にイノベーションを起こすことです。
「ヘルスケア業界のこれまでのイノベーションの変遷とこれから」
のようなレクチャーをしてイノベーションを起こす人材を育てよう
…みたいなかったるいことはしません。
この授業内でイノベーションを起こすことを目的としています。
なので授業の主軸はプロジェクト1本です。

プロジェクト内容は
「未だ存在しない特許取得可能なヘルスケア製品を作ること」で、

  • アナリティクスの要素を含むこと
  • 何かしらのセンサーを使うこと
  • 実際に動く製品を作ってデモをすること

が条件です。

インターネットの世界ではアイディアが考え尽くされていて
未だ存在しない製品のアイディアを考えるのは難しいです。
これが15年、20年前だったら
まだAmazonのようにシンプルなアイディアでも
世界を変えるアイディアになったのですが、
もうそのような簡単にアイディアが生み出せる時代は終わりました。

ヘルスケアの世界では、
今がそのインターネットにおける15年、20年前なのです。
去年のこの授業で生まれたWearSensもアイディア自体は非常に単純です。
アルゴリズムも、そこまで単純ではないながらも
(CS大学院生である)キミ達でも作れるレベルです。
ではなぜそんな単純な製品がこれまで作られてなかったのか?
それは、
ヘルスケアアナリティクスという世界がまだ始まったばかりだからです。
スマートフォン、ウェアラブルを初めとしたモバイルが浸透し始め
今、アクセスできるデータが圧倒的に増えたところで、
ようやく世界はこの膨大なデータを使って何ができるか
考え始めたところなのです。
だからこの授業で、今まで存在しなかった製品を作ることは可能で、
事実これまでこの授業から画期的な製品が多く生まれています。
恐らく今後、より多くのスキルを持った人が機会に気付いて
アイディアを製品化していくので、5年後には
ヘルスケアも今のインターネットのような状態になるでしょう。
今、このタイミングしかないのです。

この授業は簡単じゃないのはもちろんですが、
プロジェクトも”授業用の”プロジェクトではありません。
実際に世界にインパクトを与えるものになるし、
実際に多くの命を救うものになります。
というかそういうプロジェクト以外は承認しません。

なので本気じゃない人はこの授業をとらないでください。
本気の人は、この授業を通して凄い経験ができると思います。

ということで、アツさがどこまで伝わったかわかりませんが、笑
ボクはこういうことをしにMBAに来たつもりだったので、
最後の最後で念願のこういう授業がとれてよかったです。
2回目の授業がすでにアイディアのピッチだったのですが、
教授は
「それは面白くない」
「それは既にある」
「それは技術的に簡単だからダメ」
「それは技術的に無理そう」
とビシバシフィードバックをしてました。
ボクらのチーム含め何個かはその場でプロジェクトの承認を得たのですが
ボクが面白そうと思ったチームのアイディアは、
実現したらホントに多くの人の命を救うことになるものだったので
聞いてるだけでワクワクしてしまいました。
ちなみにこの授業も特許取得を前提としているのでNDAがありました。
授業内で話されたアイディアは授業外で話すことはできません。
特許申請後は話すことが出来ると思うのですが、
それまではこのブログでもシェア出来なそうです。


ということで最終学期にして初めて
イメージしていた通りのMBAライフを送ることができそうなので
ワクワクしているところですが、笑
実際どうなるかは書ける範囲で書いていこうと思いまーす!