新卒2年目からはじめるエンタープライズSaaSのプロダクトマネジメント
このnoteは、「MNTSQで過ごした私のこの1年の取り組み」、「私がMNTSQでこの1年力を入れたこと」をテーマとしたMNTSQ Advent Calendar 2022の6日目の記事です。
前回はデザイナー・クボスケさんの「スタートアップに入ってひとりめデザイナーがやったいろいろ」という記事でした。
2021年春に大学院を修了して社会人になった私ことトリノメは、2022年7月に転職し、MNTSQ株式会社（もんてすきゅーと読みます）にPdMとしてジョインしました。
この記事では、社会人2年目の新米PdMがMNTSQに入社した経緯と、半年間社内の新機能立ち上げに関わる中で見えてきたプロダクトマネジメントの輪郭について言語化してみたいと思います。
想定している読者
事業立ち上げに関わっている方
スタートアップで事業開発やプロダクト開発に関わっている方
若手PdMの方
MNTSQを知って、転職先として検討している方
「あいつ最近全然SNSを更新しないけど生きてる？」と私を気にしてくれた友人・知人
サービス企画大好き大学院生がMNTSQに入るまで
改めまして、トリノメタケウチです。
私は、2021年3月に東京大学大学院を修了し、少人数のHRベンチャーでサービスデザイナーとして社会人1年目を過ごし、22年7月からMNTSQ株式会社で新プロダクト開発のPdMを担当しています。
ハードウェアからソフトウェアまで、幅広く企画や開発に関わった学生時代
大学院ではプラスチックの成形技術を利用した新しい製造技術の基礎研究をしていました(いわゆる理系院生という属性でした)。
ものづくり領域の中でも、私が特に興味を持っていたのは企画段階で、
「ユーザーが抱えているペインは何か？」
「どのように行動変容を促すとペインが解決されるか？」
「行動変容を媒介するプロダクトはどのような形であるべきか？」
というような問いを設定し、それを解くプロセスに面白さを感じていました。
学生が参加できるビジネスコンテストやアイデアコンテストなどに出場する中で、アイデアを形にする能力が必要だと感じた私は、大学院と並行して夜間に専門学校に通い、工業デザインを学びました。
また、実務、特にソフトウェア領域の肌感も持ちたかった私は、ダブルスクールとさらに並行して、自然言語処理技術に強みを持つSaaSスタートアップにインターン生として入社し、事業開発とプロダクトデザイン、コミュニケーションデザインの経験も積む機会を得ました。
ハード・ソフトの両領域においてプロダクトマネジメントやデザインに関わる中で、
「ユーザーの日常に馴染み、いつの間にか1ランク上の生活や仕事ができるようになるサービス」を「1ランク上の状態(ビジョン)を定義し、そこに至るまでのプロセスをサービスの体験に落としこむ」というところが自分がワクワクするポイントなのだと気づくことができ、新しいサービスやプロダクトのUXデザインを担当できる職場を探し、就職が決まりました。
キャリアの初手からサービスの立ち上げをする難しさ
1社目で経験したのは社員5人程度の小規模なベンチャーでした。
採用領域のコンサルティングが本業の会社でしたが、KPI管理や候補者の入社を促すアトラクトシナリオの構築などの面で特徴的なノウハウがあり、そのノウハウをデジタルプロダクトに載せることで、スケーラブルなサービス・事業にしたいという野望がありました。
サービスデザイナーとして入社した私は、エンタープライズ内の新規事業立ち上げのコンサルティング事業をパートナー企業のチームに属する形で進めつつ、HR TechのSaaSプロダクトとtoCプロダクトの立ち上げを行いました。
このダブルワーク状態は社会人生活にも慣れていなかった私にとって、相当ハードなものでしたが、非常に学びが多く、とても有意義だったと感じています。
コンサルティング事業でチームメンバーと共同する中で、ユーザーメンタルモデルマップやビジネスモデルキャンバスなどの基本的なツールの使い方を習得しつつ、自社サービス開発にそれらを適用することでPoCスコープで開発すべきプロダクトの機能を定義したりといったナレッジの還元ができていたためです。
また、自社サービス開発においては、専任のデザイナーやエンジニアがいなかったためUIデザインや設計・実装についても私が担当することになり、拙いながらもアプリケーションの構造や外部リソースの活用についてイメージを持つことができました。
一方で、ある程度の規模のユーザーに中期的に使ってもらわないとサービス・プロダクトへのニーズが検証できない現実と、エンタープライズにおいては社内稟議を通過させるために、スタートアップにおいては資金欠乏で倒産しないために、短期間小規模での仮説検証が求められることとのギャップに悩むようになりました。悩む中で、「サービス立ち上げ時の仮説の精度を高める方法を言語化する」ことが重要であるという意識が強くなり、そのための初手として「立ち上がったサービスをきちんとグロースさせるために必要な能力を体得する」ことが必要であると考えるようになり、そのような環境を求めて転職活動を始めました。
そんな中で出会ったMNTSQですが、以下の4点で他の選択肢より魅力的に映り、ジョインすることを決めました。
プロダクトのコンセプトレベルでは顧客に刺さっているが、詳細なUXレベルではまだまだチューニングの余地がありそうだったこと
契約書と自然言語処理技術の相性がよく、DXを体現できるプロダクトになる可能性が高いこと
機械学習という確率的に品質を担保するプロダクトのUXをビジネス水準に高めていくという挑戦的な取り組みをしていること
何よりも自分よりポテンシャル面でも経験面でも優れているメンバーが揃っており、頭をフル以上に回転させることが求められそうだったこと
以降では、入社して私が関わっているプロダクトやプロダクトマネジメント業務についておもしろさや難しさをご紹介していきたいと思います。
MNTSQにおけるプロダクトマネジメント
まず、事業とプロダクトについて記載し、その後にプロダクトを成立させるためにどのようなマネジメントがおこなわれているかを記載したいと思います。
MNTSQの事業とプロダクト
MNTSQは企業の契約業務全般を支援する「MNTSQ CLM」というSaaSプロダクトを提供しています。
本プロダクトを利用することで、契約締結前の交渉から、締結後失効するまでの契約ライフサイクルを包括的に管理することができ、社内の法務・契約ナレッジを再利用可能な形で一元的に集約し、契約プロセスを高速化することが可能です。
また、機械学習・自然言語処理エンジンによる契約書などの自動解析により、法務リスクの可視化および管理の高度化を支援します。
私はそのプロダクト体系の中で、2022年10月にリリースした、契約締結前の審査・交渉プロセスを支援する「MNTSQ案件管理」という機能のプロダクトマネジメントを担当しています。
入社後1.5ヶ月程度で先輩PdMから引き継ぎ、開発のプロジェクトマネジメントおよび、ユーザーからのフィードバックをもとに業務要件の整理や開発ロードマップのアップデートなどを担当する中で感じた、今のMNTSQのプロダクトマネジメントの特徴をいくつかあげたいと思います。
(実はここに記載できなかったものとして、「機械学習を活用したプロダクトマネジメント」という観点があるのですが、こちらはもう少し自分の知見を深めてから別途記事にしたいと思います。)
MNTSQのプロダクトマネジメント組織
MNTSQにおけるプロダクトマネジメントの行われ方を見るには、まずその役割分担から見ていただくのがよいと思います。
PdM界隈でよく使われるDan Schmidtによるプロダクトマネジメント・トライアングルを参考に、私がMNTSQ内の役割分担を可視化したのが上の図です。
まず目につくのは、PdMのみで担っている領域がないことです。
特に、デザイナーやエンジニアはもちろん、導入PJを主導して顧客社内の業務オペレーションを提案したり、導入後の継続的な支援を行うCSチームメンバーと協働するシーンが非常に多いです。
常に各PJで顧客に伴走しているCSチームにはユーザーに関する一次情報が濃密に蓄積されており、新機能開発を行う際に必ず開発チームに伴走してもらうようにしています。
入社したての私が新機能開発のプロダクトマネジメントにおいて、細かな仕様に関する意思決定を積み重ねられたのは、伴走してくれるCSチームあってのことだと思います。
次に目につくのはユーザー×ビジネスの領域の主担当としてPdMが登場しないことです。
MNTSQの特徴として、プロダクト解像度の高い対面チームの層が厚いことが挙げられます。
プロダクトの現状をきちんと理解した上で、顧客やユーザーの期待値をきちんとすり合わせてくれるので、PdMがビジネス的な観点で顧客の対面に立つ必要が全くない状態になっています。
また、商談ログなどは全て全社公開されていますし、対面チーム内で適切にフィルタリングされたフィードバックも返ってくるので、顧客やユーザーの期待値を正しく把握することが可能です。
もちろん、ここに記載されているのはあくまで必ず登場する主要なメンバーのみで、案件や機能ごとに必要なメンバーが巻き込まれたり、自主的にプロダクトマネジメントに参加しています。
特に、ドメインエキスパートである法務経験者はほぼ全てのプロジェクトに1名以上が参加するような進行をしています。
こうして改めてプロダクトマネジメント組織を見てみると、全メンバーが深くプロダクトマネジメントに食い込んでいることが分かります。
なかなかないことだと思いますが、現メンバーの半分以上がMNTSQ以前のキャリアの中で事業開発やプロダクト開発の形でプロダクトマネジメントに関わった経験があるため、開発やデリバリーについて解像度の高い議論がしやすい環境になっています。
最も密にコミュニケーションするエンジニアやデザイナーもPMやPO、ボードの経験のあるメンバーなので、しばしば私自身の存在意義を見失いそうになるほど、プロダクトマネジメントに長けています。
ここから挙げる3つのMNTSQのプロダクトマネジメントの特徴は、そんなMNTSQの組織構造をふまえてPdMとして働く中で感じているものになります。
エンタープライズの基幹業務向けのプロダクトマネジメント
MNTSQの検討および導入は、おおよそ半年から1年ほどかけて進んでいくことが多いです。
したがって、ご提案するのは現在のプロダクトで実現できる業務だけではなく、利用開始までに提供開始予定の機能を活用した業務になります。
これは、ユーザーに未来を見せるという意味でPdMとしては非常にワクワクするところである一方で、プロジェクトマネジメント上はシビアな部分もあります。
また、想定する業務もその組織規模に比して大きくなるほか、すでに利用されている他サービスとの連携も重要になってくることから、SMB向けプロダクトや非基幹系プロダクトと比べた際の機能要求水準は高い傾向にあります。
さらに、組織規模や組織間の連携が非常に多岐にわたることから、プロダクト仕様やオペレーションの変更に相応のコミュニケーションや準備期間を要することも挙げられます。多くのSaaSのような、まずはMVPをリリースして細かく改善していくという開発フローは必ずしも適さないことが特徴的です。
こうしたエンタープライズ向け特有のサービス性質に対応するため、実装前のプロトタイプによるユーザーヒアリングや、提供前のQAテストの実施、CSチームを通じたリリーススケジュールについての顧客コミュニケーションなどを重視して開発を進めています。
立ち上げフェーズならではのプロダクトマネジメント
1つ上の項でも記載したように、顧客の導入決定時には、まだ提供機能の開発中であるということもあり、私の担当している「MNTSQ案件管理」はまさに「商談・導入を進めながら開発する」やり方で開発と導入が進みました。
ユーザーから想定以上の水準の要望が出てくるとヒヤッとしたりするのですが、この進め方をしたことで、リリースまでに業務要件への認識をアップデートし、よりユーザーの実務に即した機能提供ができるようになったものがいくつもあります。
特に、業務要件の想定プロセスからデザイナーがFigmaで構築したプロトタイプを用いたユーザーヒアリングやトライアルは、新しいフィードバックを得る上で非常にワークしており、改めてビジュアルプロトタイプの有効性を感じました。
ユーザージャーニーと対応する機能群・プロトタイプを半年〜1年程度のスパンでスライスして管理することにより、既存ユーザーに対しても、検討中の顧客に対してもどのように業務が良くなっていくのか、プロダクトが進化していくのかを想像しやすくなるのではないかと思っており、顧客・ユーザーとのコミュニケーションの一環として進めようとしています。
スタートアップならではのプロダクトマネジメント
自分自身が意外と大変だったこと、組織をスケールさせていくにあたって意識しておくべき観点だっと思ったので、挙げています。
MNTSQはドキュメント文化を掲げている組織なので、大抵の検討経緯はCloseされたGitHub Issueを見たり、Google Driveを確認することで参照できるのですが、それでも細かいニュアンスは拾えないこともよくあります。
当たり前の結論にはなるものの、関わっているメンバーとできるだけ密にコミュニケーションする機会を持つことがワークしており、重要だなと考えています。
入社当初は、忙しそうな他メンバーに話しかけるのを躊躇うことが多かったのですが、話しかけることで業務要件や実装の仕様について理解が急速に深まったので、もっと早く話すようにしていたら...…と思いますし、最近は新しくジョインしてくるメンバーにはできるだけ積極的に話しかけにいき、話しやすい雰囲気をつくることを意識するようにしています。
MNTSQにはスタートアップらしからぬ月間の半分は出社しようというルールがあるのですが、出社していることでリモート時よりもメンバーに話しかけやすくなっています。
15分くらいホワイトボードの前で議論することで、疑問が解消することも多く、孤独感も覚えにくいので、ちょっと通勤は面倒なものの、いいルールだなと思っています。
これからのMNTSQのプロダクトマネジメント
約半年間をMNTSQで過ごす中で、周囲の仲間と「これからこういう部分が重要になってくるから頑張っていきたいね」とよく話すことがあり、PdM目線で整理したものを2つ挙げたいと思います。
業務を守る機能開発と業務を変える機能開発のバランスを管理する
入社してからの数ヶ月でも、MNTSQの顧客のフェーズが変わってきていることを実感しています。
これまでは、法務業務の「質」を高める機能への期待値の高さから導入が決まるケースが多かったようですが、よりオペレーションに寄り添うことで業務の「効率」を高める機能への期待値が高まっています。
イノベーター理論でいうところの、イノベーター顧客が多かったフェーズから、アーリーアダプター、アーリーマジョリティが増えるフェーズへと移行しているのではないかと考えています。
顧客のニーズの変化と並行して、導入フェーズから本格利用フェーズへと移行する顧客・ユーザーが増えたこともあり、当初よりも業務想定が変わったり、機能へ求められる品質の水準も高まってきており、緊急度も増しています。
これからのMNTSQでは、スタートアップの限られたリソースの中で、「必要な業務をスムーズに遂行できるように支援する機能」と「業務のあり方そのものをドラスティックに改善する機能」とをバランスよく開発していくことが最重要トピックであり、顧客やユーザーからのフィードバックを積極的にもらいながら、より本質的なユーザーストーリーを見極め、ベストプラクティスを更新し続けていきたいと思っています。
「全社でプロダクトマネジメント」の思想を組織のスケールに順応させる
プロダクトの機能やユーザーが増えるにしたがって、MNTSQでは積極的に採用が進んでいます。私が入社した後にジョインしたメンバーも10名を超えており、今後も組織のスケールがどんどん大きくなっていく計画です。
その際に、セクショナリズムを起こさずに、全メンバーがプロダクトをよくするために領域横断的にコミットする文化を体現し続けることが非常に重要になってくると思います。
新しいメンバーを迎えた際に、これまでの経験やWillをもとに既存メンバーとどのようなコラボレーションができるか多面的に捉え、領域横断的かつ有機的な小チームをたくさんつくっていくことができるように、プロダクトマネジメントのハブとして貢献していければと思っています。
これからのわたし
MNTSQ入社時に考えていた「サービス立ち上げ時の仮説の精度を高める方法を言語化する」、「立ち上がったサービスをきちんとグロースさせるために必要な能力を体得する」という2つの目標について、半年間はたらく中で解像度が少しずつ高まってきているので、少しブレイクダウンして言語化したいと思います。
ユーザーの業務やアクションを時系列的に体験することでドメイン特有のペインを捉えられるようにする
非常に当たり前のことなのですが、ユーザーがどんな文脈の中で業務や日々の生活を送っているのかについて深く理解することが、立ち上げ・グロースの両面で必要であると痛感しています。
例えば、契約審査については、営業部のユーザーは審査依頼しておしまい！というわけではなく、事前の契約交渉の努力の成果として契約書のドラフトを法務審査に回していますし、審査後には社内上申・稟議や契約締結、さらには契約台帳への登録などの様々なプロセスが待っています。
それぞれのプロセスの中で、異なるステークホルダーに向けて異なるプロトコルでドキュメントを作成し、合意を形成していく必要があります。
上の例では、事業部ユーザーを例に取りましたが、法務部や知財部などの審査を受け付ける側のユーザーや、各部門の管理者、システム管理者も非常に複雑な業務に取り組んでいます。
ユーザーがどのような人間関係とオペレーション・プロトコルの中で動いているか、ということに真摯に向き合い、矜持やペインをすくいあげていくことが、使われるプロダクトを活用する上で重要だと感じています。
MNTSQでは、Onboardingの一環として、リーガルメンバーのサポートを受けながら法務部ユーザーになりきってパートナー企業との契約審査を担当するというトレーニングがあります。
このトレーニングを経験したことで、契約審査時にナレッジを瞬時に参照できる重要性がよく体感できましたし、審査依頼者が審査に必要な参考資料を最初に揃えてくれないことによる審査の進めにくさについても気持ちを持つことができました。
このようなユーザーを理解する活動を社内外のドメインエキスパートに協力を仰ぎながら拡大させていきたいと思っています。
ユーザーの行動を俯瞰し、何をやるべきでないか捉えられるようにする
ユーザーの理解と共感と並行して重要性を強く感じているのが、「そもそもユーザー行動がどうあると(ユーザー or 企業 or 社会にとって)全体最適なのか」という俯瞰的な目線で、ユーザーの行動をよりシンプルな方向に導くことです。
例えば、MNTSQを導入いただいた企業の中にも、複数のデータベースで契約情報を並行管理しているため、何度も同じ情報の入力を手動で行っていた、というようなケースがいくつもありました。
このようなケースでは、複数の部門で分担して作業を進めていることも多く、ひとりひとりのユーザーや業務シーンに寄り添った目線だけでは、課題の存在に気がつけないこともしばしばあります。
ユーザージャーニーやデータフロー図、シーケンス図などを利用して、情報の流れを整理する中で行動をシンプルに削ぎ落とし、より負荷の低い業務や行動を提案するということができるようになればと思っており、各フレームワークやツールの活用レベルを高めていきたいです。
ユーザーが2回目にそのサービスを使う理由を提供できるようにする
使われ続けるサービスになるためには、2回目に使おうと思われるかどうかが非常に重要だと感じています。
たとえば、MNTSQが提案しているナレッジマネジメントという機能コンセプトは、「業務の質を何段階も上げることができる」一方で「なくても契約審査や契約管理業務はある程度できてしまう」ため、ユーザーが真にメリットを感じることがないと使われなくなってしまうという難しさがあります。
特にユーザーの関心が高い1回目の利用で、どれだけ「適切なナレッジをユーザーに渡すことができる(プロダクトだと直感してもらえる)か」が重要だと私は考えています。
このためには、ユーザーにとって適切なナレッジとは何かを業務シーンごとに整理し、機械学習・自然言語処理エンジンをチューニングしていくことはもちろんですが、UIやインタラクションの面からも対応することができます。
より自己制御感を持ってナレッジにアクセスしたり、情報をナレッジ化して他のユーザーと共有するにはどのような体験であるべきかを定義し、UIやインタラクションを改善するとともに、機能追加や改善時に体験のトーンを一定に保つ仕組みをつくる取り組みをデザイナーやエンジニアと協力して進めていますが、獲得した知見を言語化してナレッジ化できればと思っています。
システムのアーキテクチャを正しく理解し、自分でも設計できるようにする
非エンジニア出身PdMとしては習得のROIが低いと優先度を下げていたアーキテクチャへの理解ですが、B2Bのデータを大量に扱うプロダクトのPdMを担うには非常に重要度が高いと考えるようになりました。
特に、
現状のユーザーの業務フローをドラスティックに変える提案や機能を検討する
業務・機能の要件から開発工数の見積を行う際の精度を高める
ために必須な能力であり、情報設計をデザイナーと協働して進めるシーンや、提案業務オペレーションをCSメンバーと構築するシーンでも、アーキテクチャを理解した上で、プロダクトが扱うオブジェクトやアクティビティを可視化していくことが有効であると実感しています。
数年前に話題になり、近年採用されることの多いOOUIの考え方はUXデザイン観点でもとても参考になりますが、UIに閉じない情報設計全般の概念をオブジェクトを軸として整理し、システムアーキテクチャに反映させていく部分の経験値を蓄積していきたいと思っています。
MNTSQのメンバーと話してみませんか？
全社員がプロダクトマネジメントを主導できる能力を持っていると言っても過言ではないMNTSQですが、社名の読みにくさも相まって会社やプロダクトの知名度がまだまだ低いのが課題です。
読者のみなさまとプロダクトマネジメントやスタートアップビジネスについて熱く語りたいなと思っていますので、お気軽にカジュアル面談をお申し込みください！
オンラインイベントやオープンオフィスなども実施しておりますので、もしよければ下記の採用ページや参考情報情報もご覧ください！
MNTSQアドベントカレンダー2022、次回の投稿は、コンサルタントとして先月入社した北野にバトンを渡します！お楽しみに！
MNTSQのプロダクトマネジメントに関する参考情報
この記事が気に入ったらサポートをしてみませんか？