hikoharu's PM blog

プロダクトマネジメントについて考えていること。twitter: @hikoharu06

プロダクトマネージャーはSlack(ゆとり)が大事

はじめに

プロダクトマネージャーをやっていると楽しい一方で、MTGや問い合わせ多くて、忙しすぎるという声をよく聞きます。

そこで本来集中すべきことは何かと、それを阻害する忙しさにどう対処するべきかまとめてみました。

PMの実態

組織内でPMが大変そうと思われる。周りからなりたくない職種と思われるのは危ないサインだと思います。

プロダクトマネージャーというとミニCEOと呼ばれたり、花形とか言われますが、実態としては割と忙殺されていて、職場でも「あの人すごいと思うんだけど、なりたいかと言われると、、、」 みたいに見られているのが多いんじゃないかと思います。

PMが忙しいパターンとそれぞれについて、どうやったらPMのゆとりを作れるかを考察します。

なお、自分がやって成果が出たというものばかりではなく やりたい or 改善中のものも含まれています

よくあるケースと処方箋について

PMが全部把握したいマンになっているケース

バックログのタスクの進捗は全部自分が把握していないと気がすまないし、MTGに全て参加しないと気がすまないタイプ とりあえずプロダクトに関わるから、、という理由でMTG参加依頼が大量に飛んでくる

一日がMTGとslackのメンションをさばくので気づけば終わっている、、、

処方箋
  • まず意識としてPMは主役ではなく、支える存在だという自覚を持ちましょう。プロダクトの全責任を取る役割だとしても、全てをPMが知ったり、やる必要はありません。
  • 組織内のPMの役割としてやること、やらないことを明確にしましょう
PMがタスク持ちすぎなケース

エンジニアに開発に集中してほしいばかりに、必要以上にエンジニアの仕事を巻き取っているケース

問い合わせだったり、プロジェクトマネジメントだったりがよくあるケース

処方箋
  • 開発チームを自己組織化していくように働きかけていきましょう
  • 開発チームとPMの期待値合わせをしましょう。本来は開発チームがやるべきタスクをPMがやっていると思っていても、その認識は双方で異なっているかもしれません。
  • 危なくなったら、単一障害点になる可能性があると開発チームに話しましょう
PMがコミュニケーションのハブになっているケース

PMはロール上色々な情報が入ってくるし、元々コミュニケーションが得意な人が多い。そこで「あいつに言ったら、背景もわかっているしよしなにやってくれる」的な見られ方で必要以上にハブとして使われているケース

特にデザイナー、Biz、Devの間や、異なる職能の開発チームの間に入ることが多いと思います

処方箋

大体こういう問題が起きるのは職能別組織(サーバーサイド、クライアント、インフラなどで開発チームが分かれている。マーケ組織も別)になっていて、ドメインと組織の見え方が違う時に起きます。

なので事業部組織に移行することで、一定の効果を見込めるのですが、PMのコミュニケーションコストの問題は解決しても、他の部分でトレードオフがあるのと、何より時間がかかり、PMの力だけで何とかできる問題でもないので、ここではもう少し地に足着いた方法を説明します。

直接解決できるというものではないのですが、第一歩としてはPMの仕事、やりたいと思っていることを周りに理解してもらうということです。 いわゆる関係の質の向上ですね

PMってただでさえ何者なのか明確でなく、加えて事業、組織によって役割全然違うので、職種に対する周囲の理解のハードルが非常に高いんですね。

PMという職種に何を期待すればいいかが皆わからないので、結果として他の職種に期待できないことを依頼せざるを得ないみたいな構造になっているという仮説です。

なので

  • PMは組織の中でどういう役割で、どうバリューを出していこうと考えているか
  • 実際に日頃何を考えて、どういう仕事をしているか

を明確にして、理解を助けるだけでも改善の方向に向かっていくと思っています。(ここ検証中)

実際に今やっていること

  • PMに関するドキュメント(ポエム的なもの)を発信していきましょう
  • 自分の分報でも、作業用スレッドでもいいので、積極的に取り組んでいること、考えていることをslackなどで実況中継していきましょう。思考プロセスを全て文字に起こして、見てもらうのが大事

おわりに

プロダクトマネージャーはプロダクトの全責任を負う人 という言葉が拡大解釈されて、何でもプロダクトマネージャーに任せればいいやというのは危ないサインです。

プロダクトマネージャーは、おそらくプロダクトに関して一番必要な情報を持っていて正確な判断をできる確率が高いと思います。

そこに判断を寄せるというのはある種正しいとは思うのですが、

これはプロダクトマネージャーが単一障害点になる可能性があるのと、組織として各メンバーにオーナーシップが生まれにくいという構造をトレードオフとして選択しているとも言えます。

スタートアップなどで人数が少ないうちは良いと思うんですが、10→100フェーズで組織が50人とか超えてくると、このトレードオフは厳しいなと、、

とはいえサッカーとかだと成熟したチームでも、特定のキーマンにボールを集中させるということもあるので、組織によって最適解は異なるという話になってしまいますが

ちなみにこの記事が大変わかりやすいです

プロダクトマネージャーは攻守の要(ボランチ)だと思う - Quest PM

ただどんな状況でも言えるのが、プロダクトマネージャーやっていると情報集まってくるし、重要な決断をすることが多いので、ついつい全能感を感じがちで、「俺がいないとプロダクトの進捗が止まる」 みたいなこと思ってしまうことが多いです。

そういう時には自戒をこめて、下記を思い出すようにしています。

エンジニアがいないと何も作れず、営業がいないと何も売れない、デザイナーがいないとプロダクトはわけのわからないものになる。
しかしプロダクトマネージャーがいない世界では、みんながその隙間を埋め、なんとかやっていきます。
プロダクトマネージャーはいなくてもいいのです。
長い目で見ればプロダクトマネジメントが成否を分けますが、プロダクトマネジメントは、
ほかには合うところがなかった変わり者と不合格者の集まりです。

世界で闘うプロダクトマネージャーになるための本 より

あと、もう一つプロダクトマネージャーとして肝に命じておくべきことが

グロースしていく中でプロダクトも組織もどんどん形を変えていきます。それによってこれまで上手くいっていたものが、組織が大きくなって上手くいかなくなるといった問題が大量に起こります。

プロダクトマネージャーというロールは他に比べて解決策の引き出しがとても多いのが特徴だと思います。

だからこそ、同じことをずっとやっていてはダメで、常に余裕を持って新しい問題を探し続けていないと、プロダクト全体の進化が遅くなってしまうと思います。

プロダクトに対してオーナーシップを持って、何でもやるというマインドを持ちつつも、やらないことを増やしていく(チームを強くして、移譲していく)。そしてそのslack(ゆとり)で新しいフェーズの問題を見つけ、解決していくのがPMの重要なミッションなのではないかと

プロダクトマネージャーはプロダクトのWhat,Whyを扱い、プロダクトを作っていくが実は
プロダクトを改善するエンジンを作ることこそが最も大事なのかもしれない

PMはスタートアップCEOに学べ!200枚超えスライドで贈る馬田隆明の白熱教室 | CAREER HACK

What,Whyを決めるというのはエンジンの中の1つの役割にすぎません。エンジンを設計して、どの部分をPM自身が担っていくかはとても重要なテーマです。

スタートアップがCTOを探すときに用意しておくべき、1つの質問とその答え

最近スタートアップをやっている知人から「今、CTO探していてて、、」と聞かれることが多いです。

大体フェーズはseed期で

  • アクセラレーションプログラムでCTO見つけてきたら出資すると言われた
  • 人脈で出資までは取り付けたがプロダクトを内製開発していきたい
  • 受託で生まれたキャッシュで自社プロダクトを内製開発したい

みたいな状況がほとんどです。

スタートアップで技術アドバイザー的なことを副業でしているというのもあり、最初は現在の状況とか、どういったことがやりたいのか細かくヒアリングしていたりしたのですが、大体の場合、結局同じところに収束することに気づきました。 どこに収束するかというと

「そのエンジニアが、メルカリやクックパッドといった大企業ではなく、自分でサービスを作るわけでもなく、
あなたの会社でやる理由は何なのか?」

ということ

紹介を求めている以上は、これに対する解は欲しいな、、、と思います。 今エンジニアは超売り手市場なわけですし

主観が大分入ってますが、いくつか回答パターンとNG,OKをメモしておこうと思います。

NGな例

「エンジニアリング以外は僕が全部やるから、コード書くのに集中できるよ」

全部やったことがあるのかと聞きたい。メッチャ辛いし、そもそもできないと思う。さらに、仮にこれを魅力に感じるエンジニアがいたとして、おそらく趣向性がスタートアップ向きでないと思います。この体制で成功するのはなかなか難しいですね、、、

ビジネスモデルが〜」

本当に面白そう(もしくは画期的)と思ったなら、自分で個人開発なり、会社を作ってやります。あなたとやる理由にはならないかなと

「0から全部自分でプロダクト作れるよ」

個人で開発します。

OKな例

顧客接点がある

特定領域toBとかで決裁者の人脈があり、販路を確保できそうなケース。 大体顧客の深いところのニーズを捉えて、ヒアリングできる環境もできている。 プロダクトさえ作れば、とりあえずはお金を払って使ってくれるユーザーが確保できそうというのはとても大きいです。

人柄

これかよと思うかもしれませんが、結局はここが大事。 エンジニアリングができても、自分一人だと何かをアップデートするような大きなものは作れないだろうということは皆薄々わかっています。また一人だとモチベーションが続かないということも ユーザーの気持ちがわかる原体験があって、情熱持って一緒にやれる人はどんなテーマであれエンジニアからすると魅力的に映ります。

おわりに

スタートアップは何かしらの取っ掛かりがあることと、その可能性を信じて情熱を持って進んでいけるチームがある以外は、アイデアが素晴らしかろうが、マーケットがあろうが、あまり意味はないんじゃないかなと個人的に思っています。

現在、エンジニアはかつてない売り手市場 というわけで、周りに「〜なエンジニアを紹介して、、、」と聞く時には、一行でいいので

「メルカリやクックパッドといった大企業ではなく、自分でサービスを作るわけでもなく、あなたの会社でやる理由は何なのか?」

に対する自分が思う解を添えてみましょう。 メッセージ送る時も1行でもいいので、最後に添えると紹介率がアップするかもと思います。

10→100フェーズにおける組織におけるプロダクトマネージャーの役割とは

はじめに

10→100フェーズのプロダクトに関わる中で

  • プロダクトマネージャーの役割とは?
  • プロダクトマネージャーとして資質を伸ばす、成長するには?

というのを最近考えていて、そのまとめです。

プロダクトマネージャーの役割とは?

プロダクトマネージャーの役割とは何なのか?ネットで調べたり、色々な人がよく言うのは

  • ミニCEO
  • 売れるプロダクトを見つけ出す(考える)人
  • プロダクトの全てに責任を持つ人

とかが多いかなと思います。 いずれも プロダクトの企画〜運用、全てに責任を持つ というコンテキストが見え隠れするのですが、現場で働く中であんまりしっくりきていなくて、理由を考えてみました

その1 プロダクトの全てに責任を持てない

プロダクトの全責任を持てるというのは、結構限定された状況じゃないかなーという気がしています。その状況とは

  • プロダクトとしてテクノロジーが第一の成長ドライバーとなっている
  • 組織が十分に小規模、かつ全員と信頼関係を築けている

という場合だと思います。

まず成長ドライバーがテクノロジーではなく、コンテンツ(動画、記事など)や営業パワーだったりすると、はたしてプロダクトマネジャーがそこまで権限を持てるのかという疑問があります。

当たり前ですけど、成長ドライバーとなる要素をハンドリングする人が最も権限を持つべきで、そこがテクノロジーでない場合、全責任を持つべきではありません。

もちろん、「じゃあ、どこまでがプロダクトなのか?」という疑問ももちろんあり、例えば、下記のような要素とかはグレーゾーンですね

  • コミュニティ
  • サポート
  • セールス
  • マーケティング
  • 説明文やドキュメント
  • 調達
  • リソース
  • 広告
  • コンテンツ

組織、事業の状況と何よりプロダクトマネージャーの資質、志向性によって範囲は変わりますよね

ちなみに上記とかは全部ひっくるめてプロダクトだろ!いう論理もあると思うのですが、そういう時はプロダクトマネージャーでなくプロデューサー、事業責任者というロールの方がスッキリします。

※なおプロダクトマネージャーがアジャイルでいうプロダクトオーナーに近い(要はバックグランドがエンジニア)という前提でバックログとして開発案件の管理が主業務という前提で書いています。

その2 売れるプロダクトを見つけ出すケースはそんなにない

本当に昨今のスタートアップ企業が発信力を上げているというのもあり、基本的に全て0→1前提(0からプロダクトを開発してリリースする)で語られることが多いのですが、現実世界で圧倒的に多いのは既存の事業なりプロダクトがあって、その中の1つのモジュールを新規にリリースする場合だったりするんですよね

いわばPMFには到達していて、そこからエンハンスするケース(といっても完全に延長線なわけではなく、ターゲットは違ったりしますが)

PMFに向けてひたすら全力で仮説検証を回すというよりかは、どちらかというと持続的な成長のための仕組みづくりとかの方が優先度高かったりします。

組織もプロダクトと考える https://techblog.timers-inc.com/entry/org_as_product

プロダクトマネージャーとして、どこに責務を持つか?

基本の形は下記だと思います

f:id:hikoharu06:20190108152913p:plain

個人的にプロダクトマネジメントのバイブルだと思っているInspiredに書かれたことを参考にしており

になるのかなと

自分なりの解釈ですがプロダクトのAARRRモデルにおいて

  • Acquisition(ユーザー獲得)
  • Referral(紹介)

においてプロダクトにとっての成功を定義して、実行するのがプロダクトマーケティング

  • Activation(利用開始)
  • Retention(継続)
  • Revenue(収益の発生)

においてプロダクトにとっての成功を定義して、実行するのがプロダクトマネジメント

と考えるとイメージしやすいかと思います。

事業として実現したいことがあって、その手段がプロダクト、上記2つだけだとそこに責務を持つ人がいないので、 上位にプロデューサーがいるという構図になります。

この基本形がありつつ

  • プロダクトの性質
  • 本人の資質
  • 組織的な成熟度

によって兼務したりが発生するんだと思います。 (スタートアップとかだとほぼ例外なくプロデューサーとプロダクトマネジメントが兼務)

なので、最低限

  • プロデューサーとコミュニケーションした上で、事業を理解してプロダクトのWhy,Whatを決めることができる
  • プロダクトのWhy,Whatを伝えて、エンジニアが納得感を持って開発を進められる状態にする

がプロダクトマネージャーの役割となります。

そこから資質と志向性によって、マーケティングにも手を出したり、事業戦略にも手を出したりしていくわけですね。

そして、このWhy,Whatを決める部分で いかに引き出しをたくさん持って、インパクトの強いプロダクトのWhatを定義できるか というのが プロダクトマネージャーの腕の見せどころかと思っています。

この記事のアートとサイエンスの掛け算という表現がとても気に入っています https://questpm.hatenablog.com/entry/2018/10/08/assign_priority?utm_source=feed

プロダクトマネージャーとして資質を伸ばす、成長するには?

シンプルに 打席に立つ回数を増やす 以外にないと思います。多彩な状況に置かれて判断を下していくことで 引き出しが多くなり、判断軸も出来上がっていくのだと思っています。

ということもあり、とにかく副業でもサイドプロジェクトでも、1つでも多くのプロダクトに関わってWhatを定義するということを最近意識してやっています。

ただ、実行している中でどういう打席に立つか というのは結構重要で プロダクトとしての

  • 仮説
  • 検証
  • 検証による学び

を1周しないと打席としてはノーカウントかなと思います。

要は

  • リリース前にバックログの整理や推進だけやって、リリース後は別のプロジェクトに行く
  • リリースしてないけど、ユーザーインタビューとかして仮説検証している

とかだとノーカウントということですね。

必ずしもプロダクトの一番最初の企画から関わる必要はないと思いますが、とにかくリリースして、リリース後の反応を元に試行錯誤を繰り返さないと何の意味もないと思います。 より高次元の大きな仮説に関われるので、企画の初期段階からいるに越したことはないかと思いますが

リリースすることの重要性 http://yuzutas0.hatenablog.com/entry/2018/12/25/170000

さいごに

自分もまだまだですが、プロダクトマネージャーって組織だったり、事業だったりに応じて求められるスキル、役割が変わるので、明確な定義はないと思っています。 とはいえ皆悩んでいるのは、Google先生の結果からもある程度わかっているので、 こういう場合は〜なタイプのプロダクトマネージャーが必要 というのがある程度パターンとして定義できるといいのかなと思っていたりします。

f:id:hikoharu06:20181230163025p:plain

プロダクトマネージャー目線でAdobe Max2018参加してきた

先日ロサンゼルスで開催された2018年度のAdobe MAXに参加してきたので、その感想 自分はXDやイラレをバリバリ使ってデザイン起こすというよりは、ツールを使ってエンジニアも含めて、チーム内でどういったコラボレーションをしていくかに興味があり、 またプロダクトマネージャーとしてAdobeのプロダクト、ビジネスがどういう思想で行われているかも興味があったので、そこら辺をまとめました。

Adobe MAXとは

年に一度開催されるAdobeの新製品の発表を中心にしたカンファレンスです。

カンファレンスの特徴として基調講演以外にも

  • 映画監督、アニメーターといった著名なクリエイターの講演がある
  • ワークショップなどが豊富で、Adobeの社員と共にプロトタイプ作成、各種ツールの効果的な使い方を学べる といったコンテンツが用意されています。

キーノート 会場の様子。今年の来場者数は1万4000人らしいです。 f:id:hikoharu06:20181209235631j:plain

キーノート冒頭で

Adobeのこれからの方針として

クリエイティビティが人にも場所にも、手段にも縛られないような世界にしていきたい。

一部の専門的なクリエイティブだけが使えても意味がないし、デスクの前だけ使えるのでも不十分

インターフェイスもキーボードやマウスだけではなく、音声など多様なものを用意したい。

全人類のクリエイティビティを引き出すような製品を作っていきたい

というメッセージがありました。

それを受けて、Adobeの今後のサービスは

  • ACCELERATE
  • LIBERATE
  • DRIVE の3つをコンセプトとして強く打ち出していきたいという発表がありました

以下それぞれの詳細です。

ACCELERATE

Adobeの製品を使った場合の作業スピードの高速化

具体的にはAdobe Senseiを使ったサジェスト、作業のアシストなどです。

ここ数年で強化されている点で、単純作業をツールが代行し、クリエイターが本来やるべきクリエイティブな作業に集中できるようにするというのを

今後もさらに継続していくというメッセージがありました。

LIBERATE

クリエイティブを場所、手段の制約から開放する

マルチデバイス対応により、いつでもどこでもAdobeの製品を使えるようにすることはもちろん、複数のツールを使う作業においては

単純にツールを切り替えてやるのではなく、異なるツール同士の機能をシームレスに使うことができるというものです。(PhotoShopillustratorなど)

DRIVE

AR、音声インターフェイスといった新技術への対応

スマートスピーカーを始めとして次々と新技術が生まれていく中で、

Adobeの製品を使って作れるコンテンツも、進化していく技術に対応したものにしないといけないという方針です。

キーノートでもXDで作成したプロトタイプをスマートスピーカーインターフェイスとして操作するデモや、ARコンテンツを使ったデモが行われていました。

個人的に、今回のカンファレンスで一番強く推されていたのはLIBERATEだと思っており

2019年に向けてAero,Rush,Geminiといった新製品が発表されたのですが、それらは全てデフォルトで

iPhone,iPad,PCのマルチデバイスに最適化されてリリースされます。

それぞれのプロダクトのデモがあったのですが、どれも「アイデアが思いついたら移動中など、どこでも制作できる。制作したものはリアルタイムでCreative Cloudにアップロードされるので、続きはデスクで」という価値をアピールしていました。

さらに新規のプロダクトだけマルチデバイスかなと思っていた所に、PhotoShop CC for iPadが発表されました。

どういうことかというとこれまで、30年間積み上げてきたPhotoShopを機能はそのまま、iPadに最適化した全く新しいものとしてリリースするということです。

おそらく秘伝のタレ状態になっているレガシーなソースコードを置き換えていくのはエンジニア目線からしてもとてつもなく大変なプロジェクトではと思います。Adobeのマルチデバイスに対する本気さを感じました。。。

このプロジェクトについてはAppleとしっかり協力して進めているらしく、Appleバイスプレジデントの方がゲストとして登壇し、両者のパートナーシップを強調していました。

PhotoShopの移行する機能の洗い出しの様子。わからないが大変そう、、、

f:id:hikoharu06:20181209235705j:plain

AdobeAppleが同じ壇上に立つ様子に、会場も大盛り上がりでした

f:id:hikoharu06:20181209235801j:plain

ずっとFlash時代からAdobeAppleの間にはある種の溝があったと思っていたので、感慨深い光景だなと思いながら見ていました。

セッションやワークショップなど、もうちょっとディープな情報はこちらにまとめました

https://tech.recruit-mp.co.jp/event/post-17345/

https://tech.recruit-mp.co.jp/event/post-17379/

プロダクトマネジメントにおける事業理解について、NETFLIXの事例を考えてみた

最近0→1以降のフェーズでプロダクトマネジメントする上で最も重要なのは事業、ドメイン理解だと思っています。

PMというただでさえよくわからない業務の本質は、

事業の価値や戦略を理解した上で、全体最適を維持する。 その上で、何かしらの専門性(エンジニアリング、グロースハックなど)を発揮して事業のHOWであるプロダクトを作って事業を加速させること

だと思っています。 それをするには、結局「この事業の価値は何だっけ?」、「今ビジネス的に何が最重要なんだっけ?」という問いに常に答えれないといけない訳です。

NETFLIXの最強人事戦略~自由と責任の文化を築く~

を読んで、そこら辺が書かれていて面白かったのでまとめます。

Googleとの企業文化の違い

イメージ的にNETFLIXと近い企業としてGoogleがあるなと思っていたのですが 読んでみると両者は根底の部分が違っていて

  • Googleの事業はとても多様。そして採用ではメンバーの創造性を何より重視する。アイデアを出してもらい、それを事業にできるから
  • NETFLIXは基本プロダクトが1つ。事業上必要なことが厳格に決まっていて、メンバーに高度な事業の理解と貢献を求める

どちらが優れているという話ではないのですが、NETFLIXは事業に対して必要な業務、人材の定義が徹底していると感じました

実際のエピソードとして、事業として検索に力を入れたいが、Facebook広告に固執する超優秀なエンジニアに対して、退職を推奨するという、、、 Googleとかであれば、配置転換などでやらせてもらえそうだなと

他にも象徴的なエピソードが

  • 人事考課は時間のムダ。なぜなら事業KPIのどれにも紐付かないから
  • 人事にも事業理解を求める。人事が事業理解をし、チームに必要な人材を採用する。事業が成功した時は「私があのチームを作った」と感動して号泣する

などが興味深かったです。

自由と責任と事業理解

本のタイトルにもなっている「自由と責任の文化」というのは、

  • 組織として透明性が担保された状況(全従業員が事業の現状と今後の戦略について理解している)
  • 事業理解をもとに自分のミッションの明確化(=責任)
  • ミッションを果たすために邪魔な制約は会社として全て取り払う(=自由)

ということなのかなと解釈しました。

自分の好きな技術を何でもやっていいということでは決してなく、やるべきことは事業戦略として厳格に決まっている。 そこがスタートラインにあった上で、徹底的に情報アクセスのハードルを下げて、自由と責任を持って事業戦略に基づいたミッションにコミットできるということなのかなと

ここらへんは自分のPMとしてのバックグラウンドのバイアスが思いっきりかかっているので、あくまで1つの解釈として読んでもらえれば

従業員のモチベーションは不要なのか

後半で従業員エンゲージメントに対しても真っ向否定していて、「まるで従業員のやる気不足が原因のような言い方だ。やる気のない従業員を解雇して好業績になるなら、とっくに他のところも成功している」これは「なるほど」と思うところがある一方、かなりのパワーワードだなと 笑

この背景としては、すでに上述していますがNETFLIXはプロダクトは1つ、さらに事業としてのビジョン、やることを明確にしている さらにアメリカのジョブディスクリプション文化(総合職とかではなく、明確に職務が規定されている)とも重なって、 完璧に事業戦略〜1人1人のミッションがつながっているからで、組織マネジメントの1つの完成形だと思いました。

つまりは採用のタイミングで完全にミッションが事業戦略からの逆算で決まる&人事、現場がそれを理解しているので求職者にブレなく伝えられている。 という前提になるので、モチベーションは関係ないと

日本だとそもそもジョブディスクリプションを厳格にできない、風土の問題も大きいし、そもそも厳格にしてしまうとポジションがクローズした時に解雇が発生するが それができないという事情があります。 事業理解など参考になる部分は多かった一方で、前提が違うので日本でそのままやるのは難しいなと感じました。

https://www.amazon.co.jp/dp/B07GWJCBVP/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1

エンジニアでもわかる、スタートアップの株をもらう時に注意すべきこと

これは何?

最近スタートアップの立ち上げに関わることになり、ありがたいことに株をある程度持たせてくれるということになったが いかんせんファイナンス周りが全くわからないエンジニアなので、ヤバいことにならないように最低限の知識を勉強してみた

背景

知人と3ヶ月くらい、「事業やりたいよね」と水面下で色々考えていて、運良くVCから出資をもらってGOできることになった。

登記とか大変なので、知人が元々持っていた会社(塩漬けされていて、ただの箱状態)を復活させる計画で進めました。

最初こんな感じだったのを

株主 持株比率
CEO 40%
友達A 40%
友達B 20%
  1. 全株をCEOが引き取る
  2. CTOに株を付与
  3. VCが出資
株主 持株比率
CEO 70%
CTO(僕) 10%
VC 20%

ということで、上記のような形にしようとしました。

考えたこと

ぶっちゃけ10%の株やると言われても、それが高いのか低いのか全然わからない(第一印象はCEOに比べて少なすぎだろと思いました 笑)

色々考えて、出資するかどうかを決めるための論点としては

  • 出資する金額が妥当か(株を取得する時に〜十万か払う必要がある)
  • 創業者間の株の割合は妥当か
  • 出資することによるリスクはないか

があるかなと思い、各観点で起業している知り合いとかに聞きながら、考えていきました。

出資する金額が妥当か

結論としては

いくらくらい払えば、しっかり会社にコミットしていけるか

という点で決めるべきだと思いました。

ぶっちゃけこの時点では株価なんてあってないようなもので、ステークホルダーの話し合いで決まるものなので、 1円にも100円にもすることが可能です。 なので極限まで支払う金額を少なくすることもできるのですが、その時に問題になるのは

果たして1円払った株を持っているということで、モチベーションを保てるか

という点です。 他のメンバーと取得価格がそれほど変わらず、上記が自分なりに納得いっているのであれば金額は妥当と言えると思います。

創業者間の株の割合は妥当か

現状はCEOが僕より7倍、株を持っている。仮に事業がうまく行って2年後に3億とかで買収されたとして 税金とか考えないと

  • CEO:約2億
  • CTO(僕):約3000万

が株を譲渡することで現金として入ることになります。

CEOはセミリタイアが見える金額に対して、僕はマンションも変えない金額、、、 ここはかなり議論したところなのですが、結論として最初の割合でいくことになりました。

前提として、この段階の持株比率は創業者間の話し合いで決まるもの。VC、エンジェルにアドバイスを求めることはあっても、とやかく言われることではありません。

ということで話したのですが、決め手になったのが会社の資本に関するクリティカルな意思決定には2/3の株の保有が必要だということ

あともう一度調達する可能性があり、持株比率が薄まることを考慮すると70%はギリギリのラインということでこの割合でいくことにしました。

ぶっちゃけここの割合に関して正解はないと思うので、上記みたいな制約の中で、EXITなどの出口のイメージを持って、それに納得して始められるかが全てだと思います。

出資することによるリスクはないか

  • 出資した金額以上を失うことはないか
  • ロックアップなど、自由を奪われるようなことはないか

というのが怖くて調べてみましたが、考慮するのはVCが出資する際の契約書で 「数年後に買値の〜倍で株を買い戻す」とか異常なことが書かれていなければ大丈夫とのことでした。

思わぬ落とし穴

と色々書いたのですが 結果として、このスキームは使わずに新会社を登記することにしました。 理由は贈与税、、、

どういうことかというと、

  1. CTO(僕)が出資して株を取得(1株あたり10円くらいとする)
  2. その後にVCが出資する(1株あたり100円くらい計算で出資)
  3. 出資した瞬間会社の株価が10倍、つまり時価総額が10倍になる
  4. どう考えても時価よりも安い金額で株をもらっている=>これって贈与じゃね?ということで贈与税の対象になる

ということです。もし指摘されると個人で支払わないといけないので、さすがにリスクが大きいよねということで 今回新しく登記する方向で進めました。

最後に

結局は

納得感を持って始められるか

ということが全てだと思っています。 出資という形でお金をいただく以上、中途半端に途中で投げ出すことは許されないと思っているので

事業を進める中で

モチベーションが上下するであろうことを見越して、コミットし続けられるような設計をする

ということができればいいかと思います。

これからエンジニアが創業メンバーとしてスタートアップに入るということも増えてくると思いますが、 ネットで色々と調べたところ、あまりにこういったケースの情報がなかったので 何かの役にたてばと思い、まとめさせていただきました。

中小企業のM&A、留職事情について調べてみた

最近新規事業として大企業から中小企業に留職(留学の社会人版)する事業を検討していて、周辺事情について調べてみた

背景

日本に380万社あるといわれている中小企業は後継者不足がとにかく深刻。ざっと試算ではこの中で100万社ほどが 社長が60歳以上&後継者不在だと言われている。当然この中には黒字企業も含まれている

中小企業のM&Aについて

上記のような問題があるので、ここ数年で中小企業と個人のM&Aが盛んになってきた。M&Aというと企業がやるもので 数百億のディールとかイメージしてしまうが、中小の場合は数百万レベルでM&Aできるものも多く存在する。 ただ当然だけど、購入しようと思っても個人が中小企業を探すの大変だから最近多くのプラットフォームができてきている。

https://macloud.jp/

https://www.tranbi.com/

https://fundbook.co.jp/

あとはこの辺りのテーマについてドンピシャな本がある

要約すると

  • 老後不安だろうし、頑張って資本家になろう
  • とはいえ0→1企業は難しいしリスク高い
  • 飲食店経営もレッドオーシャンでおすすめしない
  • 後継者不足の中小企業を経営するのがおすすめ
  • 中小は普段大企業で当たり前にやっているような業務効率改善(Excel使うとかのレベル)ができていないから、普通に大企業で働いて自然に身についたスキルで十分貢献できる

https://www.amazon.co.jp/dp/B07C21NBMM/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1

事業検討について

事業検討していく中で、それなりのキャリアの人が中小企業で働くにしても、会計、人事とかの専門知識ないと厳しいかなーと思っていたのですが、中小の業務の実情が結構レトロそうなのでいわゆる真ん中くらいの普通の層でも大企業でしっかり業務プロセスの仕組みを学んでいれば中小企業で業務改善などで活躍できるかもというのは新鮮だった

本だと上のTRANBIとかM&A仲介サイト使って探すの進めてるものの、相当ハードル&リスク高いと思うので、実際やる前に一度体験するという留職は中小側にもニーズありそう (実際、本でもリスク把握のためのデューデリジェンスと社員との信頼関係を作るためにまず2年位は役員で働くこと勧めている)

留職だと現状は大企業とベンチャーを結ぶこういうのがある。

http://loandeal.jp/

留職考える上で難しいのは、派遣元企業、派遣先企業、社員のどこにピン留めするか。 それぞれのニーズ想定すると

  • 派遣元企業

    • 中間層派遣して、メッチャ優秀になって帰って来てほしい
    • 最悪優秀にならなくてもいいから、さっさと退職させて代謝良くしたい
  • 派遣先企業

    • 大企業のノウハウ知りたい。業務改革したい
    • 後継者欲しい
    • お金はあんまりかけたくない
  • 社員

    • 経営者やってみたい(ここは老後ゆっくりしたい層と、暇だし肩書欲しいし働きたい層で結構違う)
    • とはいえ年で老後もあるし、金銭的なリスクは最小限に押さえたい

上のローンディールとかは派遣元の「中間層派遣して、メッチャ優秀になって帰って来てほしい」にフォーカスしてる気がする(しかもメインターゲットは30代)。 中小企業の後継者不足&黒字倒産にピン留めするならどういう座組みがいいか要検討。