hikoharu's PM blog

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

PMがいなくてもプロダクトが成長していく世界とは

はじめに

プロダクトマネージャーは責任が大きく、やりがいがある一方で「自分がいないとプロダクトの成長が止まる」というプレッシャーに追われがちです。

組織として、PMなしでもプロダクトを継続的に成長させるにはどうすべきかを考えていきます。

多くの組織が抱える課題

多くの組織の課題としてBizサイド、Devサイドのコミュニケーションや期待値、納得感の問題というのがあると思います。

Bizサイド

  • エンジニアリング、開発フローなどがわからず、バックログの管理をするのが難しい。大きな工数がかかる
  • 期待してくれているほど開発者がオーナーシップ持ってくれない
  • エンジニアからの事業、プロダクトに対して前のめりな提案がなくて、何かモヤモヤする
  • 開発速度が妥当かどうか、わからない。何か遅いと感じる

Devサイド

  • 事業、プロダクトとして何が価値で、どうなったら成功なのかがわからない
  • なぜ、いつまでに開発するのかが腹落ちしてなくて、納得感がない

この手の問題は、20人ほどのスタートアップから、100人超えの企業まで本当にどこにいっても起きているな、、、と感じています。

こういう時に大体PMをDevの手前にロードバランサー的に置くことで一時的には解決します。

ですが、組織間のコミュニケーションのマイナスを0にする期待に対して、PMというロールを置いただけで、一時的に問題が解決しても、組織全体のケイパビリティとしては何も変わっていないという問題があります。 (そして大体PMが孤独で誰も苦労をわかってくれないため疲れて退職する、、、)

この問題に対して、組織として対応していくためにはどうすればいいか考えていきます。

PMなしでも回る組織にしていくためには

最初はPMに集約しますが、徐々にBiz,Dev含めた1つのチームとして課題発見〜機能リリースまでを継続的に行えるようになることが大事です。

これをしないと、待っているのはPMを挟まないと何も進まない、PMがボトルネックになる世界です。

前提として、そこそこコミュニケーションが取れている組織だと、PMがいなくても、

  • プロダクト開発の優先度を決める
  • なぜそれをやるのかを説明して納得感を醸成する

ともに50〜60点くらいは取ることができると思います (時々、優先度や期待値調整がずれて炎上したり。納得感のないまま開発が進んでコンディション悪化したりする)

PMが入ると基本的にここを100点に持っていくことができます。

ただ、ずっと100点を取り続けてもボトルネックになってしまうので、PMは自分なしでも、チームとして95点くらいは取れるように持っていく取り組みをすべきだと思っています。

この辺りはチームを育てる、ピープルマネジメントのマネージャーとかとも共通する概念の気がしています。

具体的に何をする?

シンプルなのですが、即効性があり効果的なのはとにかくステークホルダー間の対話を促すということ

雑に飲み会やイベントとかやったところで、求めている対話は生まれないので ゴールをプロダクトのWhy,Whatについて透明度高く議論できると置きます。

チームには

  • マーケ得意な人
  • P/L引くの得意な人
  • 業務フロー詳しい人
  • ユーザーインサイト引き出す人

など、色々な専門性を持った人がいるかと思います。 その中でプロダクトって特にToC向けとかだと、対話する場所としてちょうどいいんですよね。皆興味あるし、理解しやすく、意見も出しやすい。

これを実現するために、最初はPMが間に入って

Devに対しては

といったビジネス、ユーザーの状況を

Bizに対しては

といったエンジニアリングを伝えていきます。

この時にただ事実を話す。データを見せるのではなく、PM主導でそれぞれの立場に合わせて翻訳した上で、解釈を付けて話すのが重要です。

そして互いに理解する取っ掛かりを作って、対話を促していきます。 (これをやるにはビジネス、ユーザー、エンジニアリングを広く理解している必要があり、結局プロダクトマネジメントトライアングルは大事ということですね)

プロダクトマネジメントトライアングルと各社の PM の職責と JD – Taka Umada – Medium

色々な組織の問題を見たり、聞いたりしていると、ユーザー、事業状況に詳しい人が知らない人を情報格差でマウンティングしやすい構造、それに伴って同じチーム内にも関わらず、発注者と受注者のような関係になってしまっていることが多いと感じます。

この状況から、それぞれが専門分野を持ちつつも、プロダクトのWhat,Whyという場所では、共通言語で会話していくようにしていきます

最終的な決定権はPMが持ちますが、PMの意見、決定に対しても立場問わずオープンに議論していけるようになったらゴールは近いです。

コツとしては1回で伝えようとせず、根気強く対話していくこと。 メインの業務の中で関わらない知識なので、内容よりもとにかく頻度が大事です。

上記以外にも

  • Biz,PM,Devの関係の質が高く、期待値が合っている
  • 事業上、どこに集中するかが明確になっている
  • 開発リソースの配分が事業戦略に最適化されている
  • プロダクトの成功が定義され、定性、定量で測定できている

…etc (それぞれが重厚なテーマなので、また個別で書いていきたい)

などの条件を揃えることができれば、PMなしでもプロダクト改善は進んでいくと思います。 プロダクト改善施策に関して、100点は難しいとしても95点くらいの決断は移譲してチームでやれるかなと思っています。

上記を私はプロダクトを改善するエンジンと捉えていて、PMはプロダクトだけでなく、このエンジンを作っていくことこそ重要だなと思います。

※注意

上記は事業が安定してきて、それなりに会社としてリソースに余裕ができてきた時の話です。 事業フェーズが進んでいくにつれて、1つ1つのプロダクト改善施策が事業、会社に与えるリスクは小さくなっていきます。

スタートアップなど、フェイズによってはプロダクトのWhatにおいて、100点取り続けないと死ぬみたいな世界もあるかと思うので、そういうところは別かなと

チームに移譲できたら、PMいらなくない?

そんなことはないです。そもそも事業の注力領域やチーム編成も結構なスピードで変わっていく中で、上記をキープし続けるのが非常に難しい。 部分的、一時的にできるようになってから、完全に根付かせるまでは長い時間がかかるので、継続して取り組む必要があります。

そして何よりPMの役割って、すごく抽象化すると変化の仕掛けを作ることだと思っています。

プロダクトマネージャーはどう評価されるべき?元Google PM対談|河合敬一×及川卓也 | キャリアハック

ビジネス、テクノロジー、ユーザーを俯瞰して見た時にそれなりの規模の組織、プロダクトって成熟してきているように見えても、どこかに局所的な10倍の成長余地がまだきっとあるはずで、それを発見するのにPMのリソース使うべきだなと思います。

もう少し体系立てるとPMの施策には大きく

  • バケツの穴を塞ぐ
  • バケツそのものを大きくする

という2つの種類があると思っています。

(下記に非常によくまとめてくれている)

PMって何してんの? プロダクト開発の4ステップ|つるちゃん|note

この中でチームが自律して行えるようにしていくのは、バケツの穴を塞ぐことまでで、バケツそのものを大きくするのは、何かしらの発想の転換、きっかけが必要だと思っています。

それは

  • 新しいテクノロジーをプロダクトに取り入れられないか検討
  • ユーザーに対して定性、定量で向き合って、新しいインサイトを探す
  • 新しいマーケットを開拓する

みたいに、不確実性が高いところに腰を据えて一定時間かける必要があるなと

そういったところに常に自分のリソースを一定貼れるように、組織やフローなどを整えてプロダクトを改善するエンジンを作っていくべきなんだと思います。

プロダクトマネージャーは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. どう考えても時価よりも安い金額で株をもらっている=>これって贈与じゃね?ということで贈与税の対象になる

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

最後に

結局は

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

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

事業を進める中で

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

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

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