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だったので
テクニカル以外の部分でもうちょっと深い学びもある気がしますが、
それはまた考えを整理してから別途ログにしてみようと思います。

CTO Material

この前友人のhirogwaさんと話の流れで、
最近のMBAでよくある、
テック経験のない人の始めるテックスタートアップの
CTOのイケてない確率の高さについて雑談したので、
その辺を主にMBA関連の人向けに説明してみようと思います。

注1: ただの独断と偏見です。笑

注2: 基本的に、エンジニアリングのバックグラウンドがない人が
MBA在籍中に始めたSoftware/Internet Service系のスタートアップ
を想定して書いてます。

注3: 知ってる人の数的にアメリカ中心で持った印象です。

注4: エンジニア等テックバックグランドのある人には
多分当たり前過ぎるので「あるあるー」と共感してもらった後に
rebuildのこのエピソードを聞いたり
この辺の記事を読んだりしてください。笑

MBAでよく見かけるCTOの選び方

1. テックのトレンドをたくさん知っている

たまにテック企業のMBA採用も(ビジネスサイドは)
初めのHRスクリーニングでこんなこと気にしてる会社もありますが 笑
CTOをこの観点のみで選ぶと多分終わります 笑
このタイプの人達はフィージビリティを考えないまま
あれこれ最新のツール/ソリューションの提案をしてきます。
多くの場合、
最新のツールを使う=イノベーティブ=いいこと
というのが彼らの使うロジックなので
エンジニアは振り回され疲弊します。

2.コードがすごい書ける

これも1.と同様で基準の一つとしてはよいのですが、
これだけでCTOを選ぶと多分苦労します。
CTOの仕事のメインは、(スタートアップ超初期を除けば)
コード書くことではないので、
コードがすごい書けるけどCTOのコアの仕事をしたことがない人だと
CTOとしては正常に機能しないかもしれません。


こういう選び方をしてしまう背景には

ウェブサービスやソフトウェアプロダクトを作るということ
=コードを書くこと→コードが書ける人がCTOがいい!

作るプロダクトをイケてる感じにする
=最新のトレンドを使う。→最新のトレンド知ってる人がCTOがいい!

という発想が、CEOの頭の中にあるからなんじゃないかなーと思います。
こう考えてしまうのは、ボクが思うに
プロダクトを作るというのはどういうことを意味するのか
に関しての理解がないことに起因してる気がするのですが、
経験なしにプロダクトを作ることがどういうことなのか
想像するのは至難の業です。
そして、それがテックバックグランドを持ってないファウンダーが
CEOをやる時に叩かれる根本的な原因だと思います。

が、バックグラウンドがあろうがなかろうが、
やりたくなってしまったものは仕方がないことので 笑
とりあえず下記は知っておいた方がいいと思います。

ソフトウェアエンジニアリング

プロダクトを作るという作業で一番イメージしやすいのがコーディングですが、
プロダクトを作ること=コーディングではないです。
ソフトウェアエンジニアリングについてちゃんと書こうとすると
スーパー長くなってしまうので、そういうのはまた今度にしますが、
ハイレベルなところだけ超簡単に書くと
ソフトウェアエンジニアリングは大きく分けて

  • 要件定義:できるべきことを決める
  • 設計:要件をどう実現するか決める
  • コーディング:設計に応じたプログラムを作る
  • テスト:要件が実現しているか確かめる
  • 運用保守:出来た製品を使っていくことの管理

というタスクがあります。
世の中には色々な開発手法があり、
開発手法によってそれぞれのタスクをまわすサイクルが違ったり
タスクの単位が違ったりしますが、
製品/サービスを作って世に出してユーザーに使ってもらう
という過程で、エンジニアサイドではこの5つはほぼ必ず通ることになります。なのでCTOは上記全てのタスクについて体で分かっている必要があります。
全てのタスクについて分かっていないと、例えば
「この設計をすると運用フェイズでこういうことが起こった時に問題が起きそう」
といったタスクを跨いだ潜在的な問題に気付けないです。

CTOの仕事

では、CTOは何する人なのか、ですが、
CTOは基本的にはエンジニアサイドの物事を決める人だと思います。
大企業で言うところのTech PM+PMOの職務兼任的なイメージです。
システムの全体デザイン(どういう仕組みで動くか)を決めたり、
開発体制/手法を決めたり、
運用保守の仕組みを決めたり。
プロダクト全体の要件定義もCEO等他のステークホルダーと恊働ですが、
CTO主導で行われるべきだし、
設計もエンジニアと恊働ですがCTO主導だと思います。

スタートアップの超初期ではCTOもコーディングすることが多いですが
それはCTOの職務だからではなく、
単純にエンジニアリングのリソースが足りないからです。
別にそれ自体は全くもって悪いことではないですし
むしろ普通のことですが、
近視眼的にコーディングスキルだけ注目してCTOを採ると
どこかのタイミングで運用まわらなくなったり
すごい複雑な仕組みのわりに
ユーザーのメリットがいまいちないプロダクトになってしまったり
中長期的に困ることになる可能性が多分にあるので、
気をつけた方がいいです。

じゃあCTOにどんな人を採ればいいのか

CTO as Tech PM + PMO

ソフトウェアエンジニアリングを全部経験した人を採りましょう。
コーディングも最新のトレンドも
自分達の作ろうとしてるプロダクトのビジョンを理解してシステムデザイン/開発手法等の全体像に落とし込んだ上で
そのコードやトレンドが
その中のどのピースになるのか/ピースとしてどういう意味があるのか
考えて意思決定できる人がCTOになるべきだと思います。
あと個人的には
プロダクトライフサイクルの各フェイズも
経験している必要があると思います。
スタートアップだからといって新製品開発に特化した人だと
ライフサイクル後期に露見する問題を設計段階で予見するのは
難しいかもしれません。

またエンジニアリングチームをリードする際、
エンジニア経験のない人が「〜することに決めたから」
というと、たとえそれが正しい決断だとしても
エンジニア達からは
「え〜、あいつやったこともねぇくせに何言ってんだよ〜、
これだからトップがエンジニアじゃないってダメなんだよ〜」
と言いたくなりがちですが、
エンジニア経験のある人が同じことを言った場合は
「あ〜、まぁあの人が言うんだから
きっとこっちのチャレンジも織り込んだ上での決断だろう」
と思われやすくなります。
(…まぁもちろん人柄とかエンジニアとしてのスキルとか
色々他にも影響与える要素はありますが)

ちなみにエンジニアの中にも色々なタイプがあって
例えばコーディング等特定のタスクを専門でやってきた人、
大企業で既に確立しているプロダクトをやった等の
プロダクトライフサイクル後ろ側だけやってきた人、
その逆でローンチフェイズのスタートアップを渡り歩いて
プロダクトライフサイクルの前側だけやってきた人等々。
なので同じエンジニアでもしっかり見極める必要があります。
で、こういうこと言うと
「そんなの全部やってきた人なんていないよ〜」
と思われるかもしれません。
まぁ実際数は少ないと思いますが 笑
別にその全部について
スーパースターエンジニア並に出来る必要はなく、
その全部について、意思決定(上述の人がついてくるとこまで含めて)
が出来るだけの能力があればよいかと思います。

CTO as Communication Bridge

ビジネスサイドが分かる人を採りましょう。
ソフトウェアエンジニアリングの中で全部のタスクが大事ですが、
その中でも特に要件定義と設計は大事です。
要件定義/ロードマップ作成は
ビジネスとしての重要性とエンジニアリングの大変さ
のバランスをとりながら行われるべきで、
CEOがビジネスのことしか分からなくて
CTOがエンジニアリングのことしか分からないと
議論は平行線を辿ります 笑
またシステムデザイン等いろいろな意思決定のJustificationも
それぞれがビジネス的にどういう意味があるのか
きっちり伝えられる人じゃないと、
予算やその他のリソースの振分の議論ができません。
例えばQA(テスト)チームを作るタイミングの話をする時に
1)バグのもたらすユーザーとビジネスへの潜在的なインパクトと
2)QAチームを置くことによってどの位回避できるのかの試算と
3)QAチームを置くコストが分からないと
QAチームを置こうかどうか判断できないと思いますが
ビジネスバックグラウンドしかないCEOが分かるのは
せいぜい3)だけで
CTOが1)と2)の答えを出す必要があるのですが、
テックバックグラウンドしかない場合は
1)のビジネスへのインパクトまでは分からないかもしれません。

ちなみに
CEOがMBA仕込みのコミュニケーション能力で打破する
というのは相当非現実的だと思います。
まず現実にそういうことができている
ビジネスバックグラウンドオンリーのCEOを
未だかつて見たことがないのと 笑
どんなに相手からものを引き出すのがうまかったとしても
引き出すものがそもそもない場合は引き出せないからです。


ということで実際あんまりCTOに適した人って
そこらへんにゴロゴロいる感じではないと思います。笑
なので、もし見つけたらしっかり捕まえるのが大事なのと
あるいは足りない部分を意識的に育てる感じでやっていくのも
いいかもしれません。
スタートアップは時間が勝負のことが多いので
あまり悠長にはやってられないかもしれませんが。

Catalog Creation

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

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

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

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

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

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

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

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

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

カタログ作成

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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