PMの越境から始まった挑戦 〜BtoB SaaSにおけるUXエンジニアリングの実践〜
はじめに
こんにちは。カミナシでPMをしている後藤といいます。
現在自分は新規領域の企画の立ち上げを担当しています。
PMとして従事しながらも、直近3ヶ月は仕様設計やチームマネジメント業務より、コードを書くことにより多くの時間を費やしてきました。
この記事では、通常のPMとしての枠を超えてなぜそのような挑戦をしてきたのか、そしてその実践を通して得られた具体的な学びについて共有したいと思います！
越境が必要になった訳
今まで自分はこの会社に入って、様々な企画にPMとして携わってきました。
BtoB SaaSのPMとして仕事を進める中で、従来のやり方では解決できない複数の課題に直面します。特に今回紹介する以下3つに頭を悩ませてました。
1. 現場で使われるSaaSの特殊性
弊社のSaaSは、食品工場や飲食店などの「1分1秒」を争う現場で活用されています。
その中でも特に重要なのが「初見での分かりやすさ」です。
現場では常に時間との戦いが続いており、操作の手間は即座に業務効率に影響を与えます。
使い方を覚えるまでに時間がかかるようなシステムは、現場に大きな負担をかけてしまいかねません。
現場の時間的な制約を考慮し、初見でも迷わない操作性を徹底的に追求する必要があります。
2. 従来の課題を発見するプロセスの限界
これまでは、アンケートやヒアリングからユーザーの声を集めました。
ただお客様との対話を通じて、以下のような課題に直面しました。
実際の現場での運用を通じて初めて見えてくる課題が数多くある
・タブレットの画面が小さく、ご高齢の方には全く文字が見えない
・工場の無線環境が不安定で、データの同期に時間がかかる など
お客様自身も、実際に使用してみて初めて運用上の具体的な課題に気付くことが多い
・これなら問題なく操作できると思った仕様でも、実際には予想以上に手間がかかる
・想定していなかった使用シーンでの不具合が発生する
企画段階では適切と判断されたものが、実運用では全く異なる評価になることも多々ありました。
3. PMとして感じた二つのジレンマ
この状況下で、PMとして二つのジレンマに直面します。
一方は、本番環境へのリリースに対する品質の責任です。
現場で実際に使われるシステムである以上、バグのない安定した動作は必須です。
セキュリティの確保も欠かせません。さらに、多くの人が同時に使用する環境では、パフォーマンスの最適化も重要な要素となります。
これらの品質を担保するには、どうしても十分な開発時間が必要になってきます。
しかしその一方でスタートアップという立場上、スピードも求められます。
市場環境は日々変化し、競合他社も着々と進化を続けています。
お客様のニーズも、私たちが想像する以上のスピードで変化していきます。
「品質は完璧だが、市場のニーズから外れている」というのは、最も避けなければならない状況です。
もっと現場にとってより良いものを作るため、アイデアを素早く試して改善できないだろうか？
勝つためには何でもやる。役割を超えてでもいいので、とにかく早く行動を起こして行かないといけない。
自分に必要だったのは、品質とスピードを両立させるアプローチでした。
UXエンジニアリングには様々な定義がありますが、私は「まず動くものを作って、すぐに現場で試し、改善を繰り返す方法」として取り組んできました。
完璧なものを作ろうとせず、とにかく使えるものを作って、お客様の声を聞きながら良くしていく。
そんな単純だけど大切なやり方を実践してきました！
お客様のビジネスを理解することから始める
まず動くものを作り形にしたい気持ちはありましたが、一度立ち止まり考えます。
なぜなら、これまでの経験から「表面的な改善」は、往々にして現場の本質的な課題を解決できないことを痛感していたからです。そこでまず
お客様の事業の仕組みと、現場の仕事の流れを深く理解すること
をとにかく考え尽くしました。
この考え方の大切さを実感したのは、ある食品工場での出来事でした。
最初は「システムの操作が遅い」という声を聞いて、画面の使いやすさを改善すれば良いと考えていました。でも、それは大きな間違いでした。
なぜその工場が取引先から選ばれているのか、どんな強みがあるのかを理解していく中で、「厳格な品質管理」がその工場の一番の強みだということが見えてきます。
実際に現場を見ると、各工程で求められる記録の正確さが非常に高く、それを確実に行うための手順が細かく決められていました。つまり、はじめ見えていた「操作が遅い」という課題は表面的なものであり、
厳格な品質管理を維持しながら、いかに効率良く記録するか
ということこそが、私たちが本来解決するべき本質的な課題だったのです。
この経験から、課題を正しく理解するための段階的な方法を学びました。
まずお客様の事業の本質を理解し、そこから現場で起きていることの本当の意味を読み解いていく。
そうすることで、表面的な改善に終わらない、本当の価値を提供できる解決策が見えてきます。
1. お客様のビジネスを理解する
・お客様は誰に向けて、どのようなサービスを提供しているのか
・そのサービスの中で、どのような強みを持っているのか
・その強みを保ち続ける上で、何が課題となっているのか
2. 課題の具体的な発生要因・原因を探り、解決策を考える
・その課題は日々の業務のどこで起きているのか
・現場では今どのような対処をしているのか
・どのような解決策を望んでいるのか
このような段階を踏んで得られた理解は、より本質的な解決策の検討へとつながっていきます。
UXエンジニアリングとして取り組んだこと
PMとしてUXエンジニアリングに踏み出した背景には、
現場の本当のニーズを素早く理解し、それを確実に製品に反映すること
がありました。ただ従来の開発プロセスでは時間がかかり、その間にも市場のニーズは変化してしまう可能性があります。
そこで、より直接的に現場と向き合い、素早く検証と改善を繰り返せる方法を模索してきました。
1. チームと共に仮説を磨き、検証を重ねる
まず最初に重要だと考えたのは、この取り組みをチーム全体の知見とすることでした。
一人のPMの検証で終わらせるのではなく、チーム全体で仮説を磨き、より良い解決策を見つけ出すことです。そこで、以下の3つの点を特に意識して活動しました。
検証する仮説を明確に定める
・以下点をとにかく言葉に尽くす
・解決すべき課題は何か
・なぜその課題が重要なのか
・どう解決できそうか
・成功の判断基準は何か
進捗を透明性高く共有する
・週次で進捗を共有
・想定外の結果は即座に共有
・チームで仮説を磨き直す
・次の一手を決める
現場の生きた情報を共有する
・チームメンバーとお客様と直接対話する機会を作成
・現場での発見や気づきの即時で共有
特に心がけたのは、「なぜその仮説を立てたのか」「なぜその検証方法を選んだのか」という背景情報の共有です。
単に結果だけを共有するのではなく、その判断に至った理由や現場での発見を伝えることで、チーム全体の理解が深めていくことを意識しました。
また、現場訪問の際は幅広くチームメンバーを招待しました。
実際のユーザーの反応を目の当たりにすることで、より本質的な課題が見えてきますし、解決策の方向性もチームで議論しやすくなります。
お客様の顔が見える状態で開発することで、より質の高いソリューションを生み出せると実感しています。
2. 作って、見せて、意見をもらい、すぐ直す
「画面デザインや設計を完璧に仕上げてから実装しよう」
これは、多くの場面でよく聞く言葉です。しかしあえてその常識に逆らうことにしました。なぜなら、
どんなに時間をかけて設計しても、実際の現場で使えるかどうかは、触ってみないと分からないこともあると信じている
からです。
そこで選んだアプローチは、「まず動くものを作って、実際に触ってもらう」という徹底的な実践を行いました。特に意識したのは以下の3点です。
現場ですぐ触れるものを作る
その場でフィードバックを得る
即座に改善して再確認する
仮説を立てて素早く試す。ダメならすぐ直してまた試す。
この繰り返しにより改善を進めてきました。
3. 開発速度も上げる
画面デザインの段階だけでは、実際の運用上の課題が見えづらいものです。
そこで、本物のシステムのように動く環境を、素早く作れる方法を探しました。
すでに世にある良いサービスを上手く組み合わせることで、通常なら数週間かかる開発環境の準備を、わずか数日で整えることができました。
今回はsupabaseというサービスを使いました。
開発スピードを上げるうえでかなり大きな助けとなりました…!
これにより、企画から実装、お客様への提供までを2週間程度で実現できました。
結果として本当に必要な改善に、より多くの時間を使えました。
システム開発では「早く作る」と「しっかり作る」はトレードオフになりがちです。
しかし、適切なツールを選ぶことで、その両立が可能だと分かりました。
システムの基盤部分は世のサービスを活用し、お客様に直接価値を届けるUI/UXの部分により注力する。
このメリハリをつけた開発スタイルにより、本質的な検証へ集中することが出来ました。
実践から得られた成果と気づき
今回取り組んだもののうち一つの取り組みでは、目に見える成果として形に出来ました。
3つの会社に協力いただき、現場での検証を重ねる中で、具体的な数字として効果が見えました。最も印象的だったのは、ある操作体験での作業時間の短縮です。
当初は31秒もかかっていた操作が、改善を重ねることでわずか7秒で完了できるようになりました。さらに、50人以上が同時に使用する大規模な現場でも、スムーズに運用できることが確認できました。
お客様からの声も、これまでの取り組みが間違っていなかったことを証明してくれました。 「これまでの案では現場で使えなかったけど、今回のものなら実際の業務で回せる」 この言葉は、チーム全体の大きな自信となりました。
一方で、現場での実践は新たな課題も明らかになりました。
現場ごとに異なるネット環境への対応
規模によって最適な使い方が変わること
想定外の使用シーンでの課題
机上では決して気づけなかったこれらの発見は、
現場に足を運び、実際に試してみたからこそ得られた学びでした。
この経験を経て、「現場の意見を聞き、すぐに改善に反映する」ことの重要性を改めて理解しました。
この学びは、すでに次の開発作業にも活かされています。
まとめ
BtoB SaaSの開発、特に現場で使用されるプロダクトにおいて、役割を超えた挑戦は時として必要不可欠です。
「役割の壁を作らない」「まずやる」「すぐやる！」という姿勢が、結果として大きな価値を生み出すと考えています。
もちろん、すべてのPMがエンジニアリングをする必要はありません。大切なのは、お客様により良い価値を届けるために自分にできることは何かを考え、即行動に移すことです。
皆さんも自分なりの「越境」を一緒に挑戦しましょう！