PM としてアスタミューゼに転職して

はじめまして、PM として入社しました Gyopi です。
アスタミューゼでは複数の Webサービスや社内サービスを持ちながら、
Product Manager を専業でやっている人間がいませんでした。

そんな中入社した一人 PM からみたアスタミューゼと最近やったことのお話です。
（以下、PM は全て Product Manager のことを指します）

（経歴）Webエンジニアの経験を PM に

「Product Manager」とはどいういう役割かプロダクトやフェーズにより異なるかなと思いますが、

Product の魅力によりユーザーに得をさせる。
そのために、メンバーが魅力を作り上げやすい状況を作り出す。

というのがざっくりとした役目だと思っています。

私はキャリアの最初から PM だったわけではなく、
最初は Ruby on Rails で BtoB のサービス開発を行うエンジニアでした。

PM は直接的に開発者の領域を侵してはならないと思いますが、
少なからず開発知識があることは議論において役に立っている実感があります。
エンジニア時代の周囲の人々には今も感謝が絶えません。

また、前職にて新規サービスを立ち上げて拡大していく中で
Growth Hack の試みを行ったり大口顧客に法人営業を行ったり、
ユーザーのことを考え・ユーザーに直に接する機会も得られました。

事業の目線で物事を考える上では新規サービスでの Product Owner（PO）を務めた経験も大きいです。
サービスを拡大させる中で複数の立場を経験できたこと、
その中でもユーザーに直に接した経験は「ユーザーに得をさせる」の発想に至る原体験だと思います。

転職理由）プロダクトとの向き合い方を磨くために

幸いにも新規サービスは成長し、
事業側も開発側もアグレッシブなメンバーに恵まれていましたが、
最終的には５年ほど務めた前職からの転職を決断しました。

法人向けのサービスにやりがいを感じながら、事業として１つだけの領域で試行錯誤をすることに限界を感じていました。
携わっていたサービスが Google などのビッグプレイヤーが競合となるドメインにいたこともあり、より独自性の強いサービスに携わりたかったです。
とはいえ、やりきった達成感が故の転職でもあったように思います。

アスタミューゼへ決めた理由は、採用面接で今の上司から受けた会社やデータの説明が興味深かったから、というのが大きいです。
ロジックで考える条件もありますが、こういう人たちと働くのは面白いだろうと、面接を楽しく感じさせてもらえたことは確実にプラスに作用しました。
最初は別の職種で応募していながら、適性を踏まえて PM を推奨してくださったことも嬉しかったです。

また、以前から Scala で開発していることを知っていたので開発者目線でも以前から知っている会社でした。
転職してから全然プログラミングできてないな、という自戒も込めて敢えて初心を記しておきます。

転職してみて）アスタミューゼで自分に何ができそうか

流れの速い事業・プロダクトに携わっているということでもあるのですが、最初のキャッチアップが何より大変でした。
社内の打ち合わせで「アグリー」とか「ケイパビリティ」とネタではなく口にする人がいて、転職の実感を感じた次第です。
とはいえ総じて周りの方は優しくて、聞いたらなんでも教えてくれるし、ご飯にも誘ってくれるし、お陰様で慣れるのは早かった気がします。

専門用語が飛び交って会話が進むので「これはドメイン知識を得るのが大変だ」ということで少しずつ社内用語集を作りました。
用語集はたまに近くの部署の人に今でも共有することがあり、フットワーク軽く作ってよかったなと思っています。
その後、同じタイミングで入社した池田 (@yukung)が社内 Wiki を整備してくれたので情報共有はかなり前進しています。

アスタミューゼには開発面やインフラ、新規事業コンサルなど様々な経験・スキルを持つメンバーがいて本当に多種多様です。
プロダクトも人数の割に多いですし、何より新規も運用中のものもデータがとにかく多いです。
その中で都合よく一人 PM という立場を利用してフットワーク軽く様々な面に顔を出すことで、意外と気づきづらいチームやプロジェクトの滞りを解消できたらなと思っています。

これまでアスタミューゼのプロダクト設計はどちらかといえば解決策ドリブンのものが多かったようです。
データや社内の専門的知見が多種多様なことを考えると、それにも納得がいきます。
それを新しい Web サービスとしてソリューションだけでなく価値を試行錯誤し、チームみんなで成長していければいいなと考えています。

最近やったこと）サービスについてみんなで議論を

最近やったことの中から、Lean Canvas を書いてみたというエピソードを少し。
Lean Canvas はサービスを「誰のどんな課題を解決するためにどういった機能を届けるか」を固めるものですが、
やったことがないと書いてみることに高いハードルを感じてしまいがちです。

今までにメンバーを少し入れ替えながら何度かトライしてみました。
その中でも一番初めは少し見切り発車気味に進めましたが、
「意外にみんなで埋められる！」という実感を得ることができたのではないかと思っています。

検討を重ねる中で、サービスの何に着目していくかという次の分類を気にしながら取り組みました。
・CPF (Customer Problem Fit)
・PSF (Problem Solution Fit)
・PMF (Product Market Fit)
とはいえ、まだ CPF がひと段落という段階です。
各フェーズなどについてはまた別の記事でお話しできればと思います！

実装する機能や、KPI 達成の施作には日常の中で確実に注目していますが、
「どうしてこういった KPI に落としこまれるのか」は定期的に振り返らないといけないなと改めて感じました。
また、メンバーによってどれくらい詳しく言語化することで判断材料として納得がいくのか、などの特徴も出てきたかと思います。

他にもこの数カ月で開発スタイルがアジャイル・スクラム化されたり、
機能要件を User Story 形式にしはじめたり、
開発チームでモブプロとかはじめたり、
チームの成長がすごいので今から未来が楽しみです！