見出し画像

ヤフーから製造業スタートアップへ転職したプロダクトマネージャーが半年経って思うこと

こんにちは、キャディ株式会社 プロダクトマネージャーの笹口です。

2019年6月1日にキャディへジョインし、間もなく半年が経とうとしています。いわゆる大企業に属するヤフーからスタートアップであるキャディに入って色々と学んだこと・感じたことがあったので、この機会にまとめておこうと思います。

今後スタートアップへの転職を考えられる方やプロダクトマネージャーの皆さまにとって、少しでもお役に立てれば幸いです!

自己紹介

私は2009年に社会人になり、今年で11年目。キャディが4社目になります。

1社目:常駐派遣SE(Java, C#)
2社目:株式会社ミスミで社内SE、からの事業部で商品開発担当
3社目:ヤフーで検索広告のプロダクトマネージャー
4社目:キャディ

これまで1社あたり大体3~4年くらいのスパンで環境を変えてきました。いずれも比較的大きな規模の会社で、スタートアップとしてはキャディが初めてです。

転職の経緯についてはwantedlyに記事を書いてもらいました。

キャディでやってきたこと

エンジニア→ビジネス→プロダクトマネージャーと経験してきて、いざキャディにプロダクトマネージャーとして入社した私ですが、普段は大体こんなことをしてます。

・担当する原価計算プロダクトの要件定義
・現場で動いているプロトタイプのメンテ
・デザイナーと二人三脚でのUI開発
・プロジェクトマネージメント
・プロダクトのオンボーディング施策の検討と実行
・関係各所との定期・不定期のミーティング
・課題の抽出と整理、優先度づけ
・中長期のプロダクト戦略について思考、ディスカッション

プロダクトマネージャーをされている方からみれば、おそらく「いわゆるプロダクトマネージャーの業務内容」っていう感じなのではないでしょうか。

入社から1~2ヵ月は4月に立ち上がった新規事業の方にも50%強リソースを割いており、その期間はプロダクトマネージャーとしてのアウトプットがあまり出ませんでした。結果CEO・CTOと相談してそちらからは身を引かせてもらい、今の状態に至ります。(キャディのプロダクトマネジメントはCEO直下なので上司はCEOです)

入社当初、とにかく必要ならなんでもやる気概で臨み、実際にそのように行動したつもりですが、色々やろうとした結果フォーカスすべきことが見え、今はそこにフォーカスしています。

爆速の方向転換

ここで最初の学びです。大企業であっても、例えば新規事業立ち上げチームを設けてエースを異動させてリーダーにしてみたり、かたや事業を整理して組織自体も集約して大部屋化を図ったりと、事業や組織は拡張と集約を波のように繰り返すものだと思います。その過程で、徐々に次のコアな事業へと全体がピボットしていきます。

スタートアップは、このペースがめちゃくちゃ速いです。

キャディについていえばまだ創業2年、シリーズAを終えたフェーズであり、当たり前といえば当たり前なのですが、日々キャッシュを溶かしながらスケールを目指しているわけで、そのためには何にフォーカスすべきなのか、最速で有力な仮説にたどり着く必要があります。

なので、とにかく爆速で仮説を実証しにかかり、これじゃないとわかれば一気に次の戦略へと舵を切ります。このスピード感がまさにスタートアップという感じで、バリューにもあるとおり「一丸」となって突き進んでいます。

画像2

が、これが実は結構プロダクトマネージャーにとってはきつい状況を生みます。

それは、事業の方向転換にかかるリードタイムと、プロダクト開発のリードタイムの差分によって生まれます。

プロダクトの開発には通常、小さなプロダクトであっても1~3カ月ほどはかかります。この時間が、今のキャディにとっては長すぎるのです。そのため、開発着手時に実現したかったコアバリューが、開発中に全社的に優先度が下がってしまうといった状況を生みます。下手すれば数ヵ月分の開発リソースを無駄にしかねない、プロダクトマネージャーにとっては非常にシビアな問題です。

目下この問題へは色々とトライしている最中なので、いずれまたnoteにまとめられたらと思っていますが、なるべく中期的な目線でコアバリューを捉えること、戦略の転換にも耐えうるアーキテクチャなどがベタですが主要な打ち手になってくるのではと思っています。

ボトルネックがない

画像3

スタートアップならでは問題として、「鶏卵問題」があげられます。やりたいことはある、しかしそのために必要なものが全然足りていないため、やらないといけないことが全方位に同じ重要度で発生します。

例として、1件目の受注をどう受けるか、があげられます。案件がなければ、パートナー工場は相手にしてくれません。しかし、パートナー工場がいなければ受注を受けてもモノが作れません。

この時、仮にパートナーネットワークが既に構築できていれば、事業的なボトルネックは受注獲得になります。一方でもし案件が潤沢にあった場合、ボトルネックはパートナー工場の開拓になります。

つまりボトルネックは、あるアウトプットを生み出すために必要なコンポーネントがある程度揃った状態で初めて生まれます。何もなければ、ボトルネックもないわけです。

プロダクトで解決すべき課題を見つけるとき、ボトルネックがあれば優先度は自ずと高まります。しかしスタートアップにおいては、ボトルネックがない状態で課題の優先度をつける必要に迫られます。

ベストプラクティスの重要性

前職までは、恥ずかしながらあまり他社の成功事例を研究したり、他業界について勉強したりといったことにあまり重きを置いてきませんでした。私自身が不勉強だったというのももちろんあるのですが、大企業では割とそれでやれてしまっていた、というのもあります。

他社や他業界のベストプラクティスを知っていたとしてもそれを応用する機会は多くなく、どちらかといえば自分たちの事業に関係あるフィールドについて深く知っていく方がバリューを出しやすい状況が多かったと思います。

しかしながら、スタートアップにおいてベストプラクティスを知っていることは非常に重要です。なぜなら、スタートアップには回り道や本来避けられたはずの失敗をしている余裕がないからです。他社が同じように苦しんだ問題を知り、その解決法を知ってハックすることの重要性は、大企業とは比較にならないほど大きいと感じています。

オペレーション構築でもプロダクト開発でも組織づくりでも、先人の知恵を大いに学び、巨人の肩に立って戦う必要があります。

プロダクトマネージャーにとっての共通項

とはいえ、プロダクトマネージャーとして働く上で、これまでと変わらないこともいくつか見えてきました。

その一つがプロダクトマネージャーの必要性です。当初は、創業期のスタートアップはCEOやCTOがプロダクトに関して細かいところまで見られるフェーズなのだから、プロダクトマネージャーの必要性は低いのではないか?と思っていました。

しかし、たとえスタートアップであっても、関係部署によってプロダクトに実現して欲しい要求は様々でその間には調整役が必要ですし、テックとビジネスの間にたって両方の言語で語れる存在の重要性は変わりません

むしろCEOやCTOと極めて近い位置で議論しながらプロダクトに責任を持つプロダクトマネージャーの存在は、経営層の負荷を適切に下げ、事業をスケールしていく上で欠かせないピースであると思います。

コンウェイの法則に抗う

これで最後になりますが、コンウェイの法則というものがあります。Robert C.Martinの著書、『Clean Architecture』でも触れられている概念であり、メルヴィン・コンウェイが提唱している法則です。

【コンウェイの法則】
システム設計は、組織のコミュニケーション構造を反映したものになる

要は、「システムを設計していると、その時の組織構造=コミュニケーション構造になっているので、その構造をシステムの構造にもコピーしたくなる」という話です。

例えば、営業が案件を受注したら営業事務がそれを台帳に登録し、その台帳を元に調達部門の担当者が発注書を印刷してFAXする、というオペレーションをシステム化するとき、

・営業事務機能
・調達部門機能

という観点で機能を定義してしまうことです。

これの何が良くないかというと、組織変更の都度システム改修が必要になってしまう点です。しかもかなり大きな改修になります。これが進むと、「システム改修コストが高いから組織構造を変えるのはやめておこう」という判断にも繋がりかねず、企業から競争力を奪う要因になりかねません。

特にスタートアップでこれをやらかすと完全にアウトです。スタートアップにとって組織変更は日常茶飯事であり、ここにコストがかかってしまうと会社にとって非常に重たい足枷になります。スタートアップではコンウェイの法則に本当に気を付けて要件定義をしていく必要があります。

しかし、気を抜くとそれをやってしまうリスクが同時に存在するのもスタートアップといえます。

なぜなら、コンウェイに抗う手段として有効なのは、各部門が担う業務を個々の機能として捉え、機能カットで要件定義することだからです。

スタートアップでは各部門の業務も刻々と変わります。なので、会社全体がどのような機能の集合として業務が成り立っているのか非常に把握しづらくなります。

そんな中でMECEに要件を切ろうとするとき、組織カットで切ってしまえば簡単にMECEになるため、常にその誘惑に晒されるのです。そこで踏ん張って、機能単位で業務を分析し、要件定義にまで落とすことがプロダクトマネージャーには求められます。

最後に

以上です。最後までお読み頂きありがとうございました。また何か気づきがあれば適宜まとめていこうと思っています。

Twitterもやっていますので、もしよろしければフォローお願いします。

また、キャディでは一緒に働く仲間を募集しています!ご興味ある方はいつでも気軽にご連絡下さい。

ありがとうございました。

この記事が気に入ったらサポートをしてみませんか?