見出し画像

大企業と共にSaaSを創るコンサルタントの1年

Furukado

こちらは、MNTSQ Advent Calendar 2022の23日目の記事です。

前回はデザイナー樫村さんの「ドメイン知識が必要なBtoB企業に転職したらオンボーディングがとにかく手厚くて助かった話」という記事でした。MNTSQ（モンテスキュー）が創業時から力を入れ、最近一段とアップデートされたオンボーディングについて詳細に書かれた内容になっていますので、ご興味ある方はぜひこちらもご覧ください。

はじめに

こんにちは、MNTSQの古角（@furukado）です。
2022年1月にコンサルタントとして入社し、早1年が経とうとしています。

立ち向かうissueはどれも経験したことがない難しいものばかりで、時にもがき苦しみ、常に楽しく、一瞬で過ぎていったエキサイティングな1年間でした。

本記事では、受託型コンサルティングを手掛けていた私が、SaaSスタートアップで「プロダクトに向き合い、大企業と共にSaaSを創った1年間」の仕事とその魅力（のごく一部）をお伝えできればと思います。
（入社当時の想いや前職の経験については、入社エントリをご覧ください）

MNTSQの未来に期待してくださるユーザー

まずは前提として、MNTSQを導入いただくユーザーとは誰か、について簡単に書いていきます。

MNTSQは、大企業向けにCLM（Contract Lifecycle Management - 全社向け契約業務サービス）を提供しています。従来の業務にMNTSQをアドオンするだけで一瞬で業務が効率化 / 高度化される夢のようなプロダクトではなく、MNTSQを前提にデジタル最適化された業務プロセスを再設計し、オペレーションに馴染ませる必要があります。

つまり、長い時間をかけて構築されてきた大企業の業務プロセスやシステムの絵姿を、ゼロから見直すことに他なりません。またそのプロジェクトをリードする法務部 / 知財部にとっては未知の試みで、大きな意思決定と全社を巻き込む推進力を要するものです。システム導入さえ経験されたことがないような方がほとんどです。

こうした多大なコストを払ってまでMNTSQを導入してくださる理由の一つは、まさに今、契約業務を変革をしなくてはならないという強い意志と危機感があるためだと考えています。全社のデジタル化 / DXの潮流が契約業務の領域にも及び、契約の作成 / 審査 / 管理というオペレーションへのペインが経営課題としてフォーカスされているという状況にあります。

そしてもう一つの理由は、MNTSQの未来に共感・期待していただいているためだと考えています。正直MNTSQは、まだまだプロダクトもオペレーションも未成熟な状態です。そんな中で、「すべての合意を、フェアにする」 というVisionへの共感やそこに向けて仮説検証を高速で回し続けることへの期待が、導入の意思決定を後押ししていると考えています。
（Visionについての詳細はCEO板谷のForbes記事もご覧ください）

「プロダクトをアップデートし続ける」というコンサルタントの提供価値

このようなユーザーに対して、「プロダクトをアップデートし続ける」ことこそが、MNTSQにおけるコンサルタントの最大の提供価値だと考えています。コンサルタント個人が持つ課題解決やコミュニケーションスキルなどではなく、「プロダクト」というのがポイントです。

MNTSQのプロダクトマネジメント / 開発は、PdMやエンジニアのみに任せるのではなく、全メンバーが業務特性や経験を生かしてコラボレーションしながら深く従事しているという特徴があります。（詳しくはPdM竹内さんのnoteもご覧ください）

その中で、導入や運用支援をリードするコンサルタントは、ユーザーに最も近い立場として契約業務やそこに存在する課題、プロダクトへのFeedbackなどを最前線でキャッチできます。それを自らの深い課題仮説 / 価値仮説に照らし合わせながら、解決によるインパクトや解決方法を検討し、プロダクトに還元していく役割を主に担っています。

参考：社内ポータルの「コンサルドメインのありたい姿」に書かれている一部。
私が社内で最も好きな文章の一つです

また私個人としては、これらの経験を通じてプロダクトを創ることに一層強い関心を抱き、今年10月にリリースした新プロダクト「MNTSQ 案件管理」において、ユーザーストーリーマップの作成 / 業務要件の定義 / 仕様策定 / 開発優先順位の検討などの、一般的にはプロダクトマネジメントと称される業務にも深く関わってきました。

プロダクトを大企業に届けるという難しさ

一方で、大企業にプロダクトを届け、業務変革を実現することの難しさを痛感する1年でもありました。以下では、コンサルタント・PdM・エンジニアを中心とするメンバーでの議論であがったデリバリーコミュニケーションに関する課題の一部をご紹介します。

  • issueの粒度がユーザー課題と開発タスクのどちらであるか統一されていないので、完了判定がユーザー価値になっていないことがある

  • 各コンサルや顧客単位でissueがあがってくるが、課題の汎用度 / 緊急度を見渡しての優先度判断が難しい

  • 対応期日に対する温度感 / 認識が開発と対面でズレていることがある

  • 対面メンバーからの様々な確認 / 問合せが様々なパスで飛んでいる結果、複数人対応による非効率、PdMやエンジニアの時間を相当に要する/分断するなどが発生している

  • ・・・ etc.

現在はこれらの課題を基に、新たな組織の立ち上げやオペレーション構築に取り組むなど、改善に向けた打ち手を打ち始めている状況です。改善の成果が結実してきたら、また記事が出せればと思っています。

他方、これらの議論 / 検討を通じて、MNTSQが挑戦しているエンタープライズSaaSのプロダクトマネジメントやデリバリーにおけるベストプラクティスが世の中ではまだ確立されていないということも徐々に分かってきました。裏を返せば、MNTSQがそのリーディングカンパニーになれる可能性を十分に秘めているということだと考えています。

おわりに

MNTSQにはこうしたエキサイティングな環境があり、チャレンジを一緒にしていくメンバーを募集しています。
もしこの記事を通してMNTSQに少しでもご興味を持っていただけた方がいましたら、DM（@furukado） / カジュアル面談等でお話しさせていただけますと嬉しいです。

そして、最終日はついにCEO板谷の「“検索” と “推薦” で社会をフェアにする」です。こちらもお楽しみに！


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