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

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

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

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

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

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

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

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

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

カタログ作成

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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