「これ本当に必要？」と問い続け、MVPのスコープを絞る。プロダクトの“資産価値”を重視するカミナシが実践していること

時間もリソースも限られているスタートアップでのプロダクト開発では、最小限かつ本質的な価値を持つ機能、いわゆるMVP（Minimum Viable Product）を見極めることが重要です。しかし、それは簡単なことではありません。「この機能を作れば顧客が買ってくれる」という目先のニーズにとらわれ、プロダクトの方向性を見失うケースも少なくないのです。

そうした中、年間3,100回以上の現場訪問から拾い上げた情報と、開発組織の定義した仮説を組み合わせて「コアの機能」を導き出しているのが、現場DXプラットフォーム「カミナシ」を提供する株式会社カミナシ。

本当に必要なものだけを作る――。言うは易く、実行は極めて難しいその判断を、なぜ彼らはブレずに下せるのでしょうか。同社の取締役CTOである原トリさんと、「カミナシ 設備保全」のプロダクトマネージャーである右田涼さんに、MVP開発の方針を聞きました。

• keyboard_arrow_down MVPは「あったらいいな」を削り切ってこそ生み出せる
• keyboard_arrow_down 「顧客の声」「理論や経験則」両方を起点に
• keyboard_arrow_down 個社カスタマイズを避ける。SaaSとしての“資産性”を追求
• keyboard_arrow_down 「小さく作る」は仕組みから

――先日、原トリさんは「カミナシと、質とスピード – MVP にこだわり、アジリティを獲得する」という、顧客のニーズを捉えて高速にプロダクトを改善する考え方をまとめた記事を公開されていました。現場のプロダクトマネージャーのみなさんは、どのようにMVPを定義しているのでしょうか？

右田：考え方として、まずは「そもそも本当にその機能は必要なのか？」と疑うところから始めます。最近リリースした予備品管理の機能も、まさにその発想で検討を進めました。

予備品管理とは、設備や機械のメンテナンス・安定稼働のために必要な部品を保持し、その保管場所や在庫状況を把握しておく業務です。この業務について現場の方々にヒアリングしたところ、「ベテランでなければ部品を見つけられない」「誰かが使った後に報告がないと、他の人が欠品に気づけない」といった、明確な課題が多数挙げられました。

こうした課題が放置されると、設備が停止した際に必要な部品が見つけられず、復旧に時間がかかってしまいます。その結果、最終的には顧客の業務に甚大な影響を与えかねません。つまり、予備品管理という業務には明確なペイン（抱えている課題や不満）が存在しており、「機能を作らない」という判断には至らなかったんです。

次に私たちは、「多くのお客さまに共通して求められている最小限のニーズは何か？」を見極め、「このポイントさえ押さえれば、業務が最低限きちんと回る」というラインを丁寧に定義しました。そして、そこから漏れる「あったら便利」「あれば嬉しい」といった要望は、思い切って削ぎ落とす。そうすることで、本質的な価値に集中した機能設計を進めました。

――その逆に、あえて作らなかった、あるいは簡略化した事例はありますか？

右田：設備カルテという機能があります。これは、設備ごとに使用部品や修繕履歴、部品の交換履歴などを管理するものです。

この機能を開発する際、ある顧客から「設備のマニュアルを添付できるようにしてほしい」という要望が挙がりました。それに対して実際に作ったのは「画面の入力欄にクラウドストレージのURLを貼り付けるだけ」という仕様の機能でした。

この要望をそのまま受け取った場合「ファイルアップロード機能を作ろう」と考えてしまうかもしれません。しかし、膨大なファイルをすべてカミナシのシステムに移管するとしたら、ファイルの総容量が読めず、サービスの価格設計も複雑になる可能性があります。顧客にとっても、すべてのマニュアルをアップロードする作業の負担は大きい。

そこで、複数の顧客の現場でマニュアル管理の様子を見てみたところ、各社がGoogleドライブ、SharePoint、OneDriveなど、さまざまなストレージでマニュアルを管理していることがわかりました。

ならば、ストレージのURLさえ貼り付けられれば、顧客は今あるストレージをそのまま使え、私たちもストレージ容量を気にせずに済む。こうした仕様で顧客の課題を解決できたのは、プロダクトの初期フェーズとしては合理的だったと思います。

もちろん、セキュリティなどの事情からストレージを利用していない顧客も一定数いるので、今はそうした顧客のユースケースを改めて整理し、対応を検討しています。

――現場に何度も足を運ぶからこそ、「最低限何があればいいのか」がクリアになるのですね。

右田：そうですね。カミナシでは、プロダクトマネージャー自身が顧客と頻繁に会うようにしています。これは他の職種のメンバーも同様です。私も多い時期は月に7〜8回ほど現場に足を運んでいます。

私自身は「設備保全」という領域について専門的な知識を持っていませんでした。だからこそ、現場の方に直接教えてもらうのが一番早いです。実際に現場を見て、業務の流れを教えてもらうことで、ユースケースやペインをより具体的にイメージできるようになります。

さらに、そうして得た知見は開発チームにもきちんと伝えるようにしています。現場訪問の翌営業日には、メンバー向けにLT（ライトニングトーク）を届け、「どの企業を訪問して、現地でどんな話があったか」を共有しているんです。

――カミナシではなぜそれほど、顧客の声を聞く文化が醸成されているのでしょうか？

右田：カミナシは会社のバリュー（価値観）として「現場ドリブン」を掲げており、その文化の影響は大きいと思います。全社員の合計で、年間3,100回ほど現場に足を運んでいます。それくらい「現場に行くのが当たり前」という会社です。

原：カミナシはカスタマーサクセスにもかなり力を入れていて、プロダクトが顧客の事業にとってプラスになるように伴走し続けてきました。これまで築いてきた顧客との関係性があるからこそ、何かを提案した際に快く受け入れていただけるという面があります。この関係性が、会社の財産になっています。

ただ、注意しなければならないのは、プロダクト開発において「顧客の声を聞くのが常に正解」ではないということです。既存の業務フローをなぞってそのままシステムに落とし込むだけでは、大きなブレイクスルーは生まれにくいですからね。

これとは別のアプローチとして、プロダクト開発のセオリーや自分の経験則などに基づいて仮説を立てる動きも必要です。どちらか一方の発想だけでは行き詰まるので、「顕在的なニーズを起点にする」と「理論や経験則を起点にする」の両方が必要だと思います。

――昨年にリリースされた、1つのアカウントであらゆるカミナシ製品にログインできる「カミナシ ID管理」はまさに後者のアプローチでしたね。

原：そうですね。マルチプロダクトのSaaSを展開していくのであれば、いずれIDの統合が課題になることは明らかです。そして、こうした製品は「統合が必要になったタイミング」になってから動き出しても遅いんですよね。だからこそ、このタイミングでやるべきだと判断しました。

――プロダクトの方向性について、社員同士が建設的な議論を進めるには、どんな工夫が大切だと思いますか？

原：これはSaaSを前提とした話になりますが、「この機能を作れば、この顧客に売れる。売上が伸びる」といった意見が出たときに、それがそのままプロダクトの意思決定につながってしまう組織では、健全な議論は生まれにくいと思います。

大事なのは、そういった意見が出たときに「その機能は他のすべての顧客にも価値があるか？」という視点で、話し合えるかどうかです。そうした文化がないと、「売れそうな機能は全部作る」という方針になり、仕事の余白がなくなって組織が疲弊します。

また、プロダクトの価値は、売上という短期的な指標だけで測れるものではありません。たとえば、日常的に使われる機能を丁寧に増やしていくことでユーザーの利用頻度が上がり、結果的にチャーンレート（解約率）が下がるというような、長期的・間接的な価値もあります。

だからこそプロダクト開発では、「定量化しやすい価値」と「定量化しにくい価値」の両方をフラットに捉えたうえで、会社のミッションやビジョン、プロダクトの中長期的な方向性などと照らし合わせて、納得感のある重みづけをしていくことが大切だと思います。

右田：私も「カミナシ 設備保全」の開発チームで、“SaaSとしての資産性”についてよく話しています。「この機能はストック資産としてプロダクトに積み上がっていくのか？ 短期的な成果だけを目指していないか？」という視点です。

この考え方を大事にしているからこそ、基本的には個社対応のようなカスタマイズを行わない方針にしています。そして、チームの全員でプロダクトのビジョンについての共通認識を持てているので、それにそぐわない要件が挙がってきた場合には「これ、必要かな？」と冷静になって立ち止まれる体制ができています。

他にも組織作りに関連した話をすると、「カミナシ 設備保全」ではOKR（Objectives and Key Results）もセールスやカスタマーサクセス、開発組織のメンバーたちが一緒になって設定しています。この取り組みも、関係者全員の認識を合わせる上で役立っていますね。

――プロダクトや機能をリリースした後、どのような方法で効果測定をしていますか？

右田：まずは、定性的な声を集めることを重視しています。機能をリリースした後に、顧客に電話やメールで感想を聞いたり、カスタマーサクセスの定例ミーティングにデザイナーやエンジニアと一緒に同席したりしています。

「カミナシ 設備保全」は導入企業がまだそれほど多くはないので、数字だけを見ても十分な傾向がつかみにくいことがあります。だからこそ、一社ごとの反応を丁寧に拾っていくほうが、実際の使われ方や改善ポイントを把握しやすいと感じています。最近は導入社数も増えてきたので、徐々に定量データも参考にし始めていますが、あくまで補完的な扱いですね。

――リリース後の反応が予想と違っていた場合、軌道修正はどのように行っていますか？

右田：前提として、MVPは「検証を行うために出すもの」だと捉えています。つまり、「この機能が絶対に正解だ」と考えているわけではなく、そもそも間違っている可能性もあるという前提で取り組んでいます。リリース前の段階で、「ここには不確実性がある」「こういった理由で使われないリスクがある」「リリース後はこの基準で成果を判断する」といった情報を整理し、関係者と合意した上でリリースしています。

原：プロダクトを作り込みすぎると、捨てる判断がしにくくなるし、途中でプランを変えづらくなります。だからこそ、MVPは小さく作るべきですし、それによって変化への柔軟性を持たせることが大事だと思います。

右田：私たちはプロダクト開発の計画を立てる際、「数カ月先までは抽象度高く見通しを立てつつ、直近の数週間は詳細までクリアに考える」といった具合に、時間軸ごとに解像度を変えて考えるようにしています。つまり、大きな軸さえぶれていなければOKという“変化を前提にした進め方”が、チームの共通認識として根付いているんです。だからこそ、みんな柔軟に軌道修正ができています。

――非常に納得感がありますね。最後に、小さく作って改善していく開発スタイルを目指すプロダクトマネージャーやエンジニアに向けて、意識しておくべき姿勢や考え方を教えてください。

右田：プロダクト作りの肝は、改善のイテレーションを回し続けることだと思っています。そして、その頻度を上げるには、1回あたりのイテレーションの期間を短くするしかありません。すると必然的に、最初から大きく作らないという発想が染みついていくと実感しています。

原：たとえば完成まで半年かかるようなものがある場合でも、「半年かけて一気に出すのではなく、数週間単位で出していく方法はないか」をまずは模索すべきだと思っています。細かな改善を高頻度で出していくと、途中で「この部分はそれほど優先しなくてもいい」とか、「むしろ他の領域のほうが重要だ」といった気付きが得られるんですよね。

そうした学びは、ユーザーインタビューや機能の利用状況、書籍やWebサイトに掲載された知識など、さまざまなインプットから生まれてきます。総じて、プロダクトを小さく作って継続的に改善していくことは、「早く学ぶ」ための近道になると思っています。

取材：中薗昴、光松瞳
執筆：中薗昴
編集：光松瞳
撮影：山辺恵美子