初心者PdMがゼロイチでプロダクトを立ち上げるまで - 筐体メンテナンス業務のDXプロダクト
こんにちは！
Hiyamaと申します。
「デジちゃいむ」というサービスを運営しているWASD Inc.（ワスド株式会社）でプロダクトマネージャー（以下、PMと表記）の仕事をしています。
昨年の7月頃から主力サービスである「デジちゃいむ」に加わる新しいプロダクトの開発に取り組んでおり、
ちょうどこの2月から「デジちゃいむメンテナンス」として正式リリースに辿り着くことができました。
今回は私のPMとして初めての大きな仕事であるデジちゃいむメンテナンスの立ち上げ経緯についてお話できればと思います！
デジちゃいむメンテナンスとは？
主にアミューズメント施設を対象として、ゲームやプライズ筐体にまつわる故障や不具合の修理業務をDXするプロダクトです。
店舗でのスタッフ呼び出しや接客を助ける既存プロダクト「デジちゃいむ」に機能を追加する形で提供されます。
ニッチな分野に聞こえるかも知れませんが（笑）、アナログな業務が今も多く残されており、既にデジちゃいむをお使い頂いているお客様から強い熱意を持って要望を受け開発に至りました。
初期の失敗 - 戦略肥大
今年2月に正式リリースとなったデジちゃいむメンテナンスですが、私が関わり始めた初期には何度かの方向転換があり、また手痛い失敗もあったため、まずはそのお話をしたいと思います。
企画段階においてはFigma上で画面遷移図等のドキュメントを作成して要件の整理を進めていきましたが、この時の問題点はヒアリング不足から現場理解が浅く、顧客のニーズに優先順位がつけられていなかったということです。
この頃のデジちゃいむメンテナンスには、「こんな機能を提供したい」という様々なコンセプトがありました。
故障をイシューとして管理する
イシューの対応者をアサインする機能
お客様からのクレームを不調レポートとして蓄積
不調レポートを担当者が仕分けし対処が必要な場合メカニックへ修理依頼
故障による損失額を予想して算出
故障履歴からのデータ分析
メカニックがエリアを巡回するルートをサジェスト
これらの機能は全てお客様との対話の中で挙がったものではあるのですが、この時の設計はこれら全てのアイデアをまぜこぜにしたものとなっており、初期リリースとしては開発工数が大きすぎ、またプロダクトとしての価値の軸が不鮮明なものになってしまっていました。
さらに複雑化した機能が現場で働くスタッフには親和していなかったり、機能は多いものの一つ一つの機能を見るとそもそも要求を満たせていなかったりと問題が多く、初期のバージョンはお客様にあまり受け入れられない結果になりました。
その時なりに頑張って作っていたものですが、今見るとドメイン理解不足が明らかです……笑
ちなみに私はデザイナー出身のため、この図は自分で作っています。
ただここまでなら、モックベースで顧客と対話しながら設計を固めていくという初期の進め方としてはそこまで間違ってはいないように思えます。
ここで起きてしまった大きな失敗は、「試作段階から開発を巻き込みすぎた」ということです。
実はこの設計が失敗だったことが分かる前から、既に開発チームがDB設計やフロントの開発に動き始めてしまっており、大きく手戻りを発生させる結果となってしまいました。
勿論技術検証という作業もあるためある程度初期から開発が並走することは必要なのですが、まだプロダクトの形が固まりきっていない時期から大規模に開発が進んでいる状況は防がなければいけませんでした。
ことBtoBプロダクトにおいてはモックアップやプロトタイプだけでもある程度精度のある検証が可能なため、まずはPM&デザインチームのみで検証を進め確度を高めてから開発側に卸す、という動きが正しいかなと今では思っています。
バーニングニーズの特定
以上の失敗を踏まえて現場理解の不足を痛感したため、ここから顧客ニーズを正確に捉えることに心血を注いでいきました。
お客様とのMTGでは「あったら便利な機能アイデアは何ですか？」（What）と聞くのではなく、 「普段の業務フロー」や「どこに困っているか」（Why）を重点的に質問することを意識し、現場の解像度を高める作業を行いました。
「機能ではなく課題から考えよ」ですね。
この作業の結果、現在お客様が抱えているバーニングニーズが
店内のコミュニケーション
店外にいるメカニックとのコミュニケーション
筐体故障履歴の管理
の3点であることを突き止めます。
これらのニーズに1対1対応する形で機能を想定し、それを初期の開発スコープに定めました。
さらに現場スタッフでも使いやすいシンプルなプロダクトにする必要から、 初期のコンセプトの中にあった担当者やインシデント毎の状態管理という概念を捨て、 ファジーさを許容するコミュニケーションツールとしてMVPを定義しました。
MVP定義時にはここに載っている基本的な要件はほぼ固まっていました
実際に使うスタッフは忙しい業務の中で、現場からスマートフォンを使ってサービスに参加するため、想像力を働かせ業務に親和する形でのデザインが必要です。
これらの経過を経て作成されたモックをお客様にお見せした所好評で、ここから本格的に開発をスタートさせることになります。
世のPMの皆さんにとっては耳タコかと思うのですが、とにかく顧客と話すこと、そしてその時の質問の仕方が重要だということを改めて学んだのでした。
ここで明確な現場理解とシンプルなMVPを得たことで、デジちゃいむメンテナンスは非常に地に足のついた（特に華やかさはなくとも、何らかの課題を現に解決している、Valuableな）プロダクトになったと思います。
後に、導入して頂いたお客様にその理由をお聞きした所「ふつうに使えるから」とのお声を頂きました。
これは飾り気のない言葉ですが（笑）、現場で使って貰えるプロダクトの目指すべき姿が内包されているように思っています。
開発とビジネスを繋ぐ橋としてのPM
前章のMVP設計をどうするか？は大きな岐路でしたが、ここから先はおおよそ一本道だったように思います。
ここから先にPMとしてやった仕事を列挙すると、
まず開発サイドの仕事は
仕様書の作成
開発チームにビジネス状況を逐次展開
の2点が大きなものでした。
エンジニアは顧客の声を直接聞いているわけではないため、
「これ、作って意味あるの？」「今我々は何を作っているの？」という心境に陥りがちです。
情報格差によるプロジェクトの失速を防ぐため、逐次ビジネスの状況を共有することを意識していました。
ビジネスサイドの仕事は
PoCに必要な段取り（準備や説明会など）
アンケートやデータ分析でPoCの進行状況をチェック
並行して新規顧客への営業活動
ビジネスチームが独立して営業しに行ける体制を作る
営業資料作成
セールスロジック（現場の課題と、それをどう解決しようとしているのか？）のドキュメント化
デモ環境の整備
お客様向けマニュアルの作成
社内勉強会の開催
などです。
ここで学んだことは、新規の商材はビジネスメンバーのキャッチアップが難しく売りに行きづらいので、その場合はPM自らが営業をしたり、営業のための基盤を整えてあげることも必要ということでした。
「作って終わり」になってしまうと誰もそれを売りに行くことができないので、初期の頃は作った人が営業もやってしまおうということですね。
勿論PMの他にビジネスサイドにPOやPMMがいる場合は分業した方が理想ですが、 人数の少ないスタートアップ、ましてまだ顧客基盤のない新規プロダクトであれば「結局なんでもやる」というシーンが多くなるのは恐らくあるあるなのかなと（笑）。
PM自身が顧客に繰り返しプロダクトの説明をし、そこにビジネスサイドのメンバーに同席してもらうことによってみんなの理解が深まっていったように思います。
PMという仕事は様々な言葉で表現されますが、今回の仕事を通じて私が見つけたPM像を自分の言葉で表すなら「顧客、開発、ビジネスの間に立ち、ビジョンを元にプロダクトを前に進める人」となるでしょうか。
これは恐らくPMに関する本を読めばすぐに言える範囲のフレーズだと思いますが、実際に仕事をした経験から腹落ちできたことが自分にとっては大きな収穫でした。
グロースを目指して
2月1日に正式リリースとなり実際にご契約も頂いているデジちゃいむメンテナンスですが、よく言われるようにプロダクトはリリースからが本番であり、ビジネス面・機能面両サイドでのグロースを考える必要があります。
ビジネス面としては、今はまだN=1の状況となっているものの、店舗拡大・数社でのトライアルが進行中で、まさにこれから成長フェーズと言った所でしょうか。
元々はアミューズメント施設を想定して作ったプロダクトですが、一般化すると「機材を用いてお客様にサービスを提供する業務」と言い換えることができますので、他業種への展開もあり得るかも知れません。
機能面では、PoCにご協力頂いた店舗様へのアンケートやインタビュー・データ分析を通じて現在どこまでの価値を提供できているのか？どこからはできていないのか？が判明してきており、これからどの方面を強化すべきかを模索している段階です。
0→1から1→10への飛躍ということで、PMとしてはますます面白いフェーズに入ってきたと感じています。
まとめと残った課題
ここまでデジちゃいむメンテナンスの企画からリリースまでの顛末をお話しました。
改めて言えることは、
「経営層が（方針は示した上で）PMに意思決定を一任してくれたので、非常に動きやすかった」
ということです。
ビジネスサイドから開発サイドまで一気通貫して自由に活動することができたため、自分としても非常に良い経験ができ、また成果物であるプロダクトにも一本の軸を通すことができたように思います。
経営層やチームメンバー、協力してくれたお客様に大変感謝しています。
一方で課題感が残った部分もあります。
PMが開発サイドに卸す情報として、 「今作るべきモノの仕様書を書く」ことはできたのですが、「未来を示すこと」はハードルが高かったという感覚がありました。
今後どういう展開を想定しているかによって、どこに拡張性を持たせるか等、技術設計の判断が変わってくることがあります。
この点については今回はPMとして上手く情報共有をすることができず、後から機能追加をする際に手戻りを発生させてしまうシーンがありました。
これについては今の所、DB設計をPMが適宜レビューするようにしたことで、ある程度回避ができています（PMが考える未来像と技術設計を擦り合わせる行程）。
ただ、理想は未来像をチームメンバー全員が共有できることだと思っているため、方法については検討中です。どなたか良いナレッジがあれば教えて下さい……！
また、プライシングについては経営マターの色が強いため私はほぼ参加しなかったのですが、プロダクトの情報を最も持っているのはPMなため、今後新規プロダクト開発があれば関わりを持ちたいなと考えています。
プロダクトがもたらすことのできる価値のモデル化、定量化ができればそこから適正価格を割り出すこともできますが、これが中々難しく苦戦している所です。
ということでまだまだ沢山の課題はありますが、今後もデジちゃいむメンテナンスや、本体のデジちゃいむを通じてより良い価値を提供できるようPMとして研鑽していきたいと思っております！
この記事を読んでデジちゃいむやワスドに興味を持ってくれた方は是非お気
軽にご連絡ください。
それでは、最後までお読みいただきありがとうございました！
この記事が気に入ったらサポートをしてみませんか？